Re: [boost] [concept_check] Some issues

Subject: Re: [boost] [concept_check] Some issues
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-12-11 16:54:22

Robert Kawulak wrote:
> > From: Stewart, Robert
>
> > The purpose of an Assignable archetype is to test that a type
> > that is assignable, but possibly neither default nor copy
> > constructible, satisfies the concept.  That is, the
> > Assignable concept checker should not impose *any* other
> > criteria on its parameterizing type.
>
> I guess you could've misunderstood what I ask for - it's not making the
> extra special functions public but rather removing them completely. This
> allows for composition while still it's not making the archetypes looser
> than required.

That leaves them for the compiler to generate.  The generated special functions will be public, unless you suppress them otherwise, so the archetype would be looser than it should be.  Am I speaking from ignorance of the actual classes in BCCL?

> The actual code I use is:
>
>   template <typename T = int>
>   class null_archetype
>   {
>       null_archetype();
>       null_archetype(const null_archetype &);
>       null_archetype & operator = (const null_archetype &);
>       ~null_archetype();
>   };
>
>   template < typename Base = null_archetype<> >
>   struct copy_constructible_archetype : public Base
>   {
>       copy_constructible_archetype(
>           const copy_constructible_archetype &);
>       ~copy_constructible_archetype();
>   };
>
>   template < typename Base = null_archetype<> >
>   struct assignable_archetype : public Base
>   {
>       assignable_archetype & operator = (
>           const assignable_archetype &);
>   };
>
> How is assignable_archetype<> default or copy constructible
> now? It's not unless you combine it - for example only
> assignable_archetype<copy_constructible_archetype<>> is both
> assignable and copy constructible.

Ah, here you've suppressed the compiler's ability to generate a default constructor, copy constructor, or copy assignment operator because the corresponding special functions are private in the base.  Nice.

> In comparison, the current implementation of the classes is:
>
>   template <class T = int>
>   class null_archetype {
>   private:
>     null_archetype() { }
>     null_archetype(const null_archetype&) { }
>     null_archetype& operator=(const null_archetype&) { return *this; }
>   public:
>     null_archetype(detail::dummy_constructor) { }
>   };
>
>   template <class Base = null_archetype<> >
>   class copy_constructible_archetype : public Base {
>   public:
>     copy_constructible_archetype()
>       : Base(static_object<detail::dummy_constructor>::get()) { }
>     copy_constructible_archetype(const copy_constructible_archetype&)
>       : Base(static_object<detail::dummy_constructor>::get()) { }
>     copy_constructible_archetype(detail::dummy_constructor x) : Base(x)
> { }
>   };
>
>   template <class Base = null_archetype<> >
>   class assignable_archetype : public Base {
>     assignable_archetype() { }
>     assignable_archetype(const assignable_archetype&) { }
>   public:
>     assignable_archetype& operator=(const assignable_archetype&) {
> return
> *this; }
>     assignable_archetype(detail::dummy_constructor x) : Base(x) { }
>   };
>
> Now:
> - assignable_archetype<copy_constructible_archetype<>> is not copy
> constructible,
> - assignable_archetype<default_constructible_archetype<>> is not default
> constructible,
> - copy_constructible_archetype<> is also default constructible,
> - assignable_archetype<> is also destructible (which it doesn't
> necessarily
> have to be).
>
> Either I'm overlooking something or the current implementation is simply
> wrong and needs to be fixed.

We may be overlooking some special cases the authors were accounting for, but it seems to me your proposal is sound.

> > > > Even if so, not all combinations are possible.
> > >
> > > Could you give an example of an impossible combination?
> >
> > The OP's!  Seriously, my point is that making a particular archetype
> > restrict its interface might generally prevent certain combinations.
>
> But why you'd want to prevent certain combinations at all?

Because doing so produced bad results, though it appears that result is not necessary.

> Is there anything wrong with combining archetypes?

No, not if doing so does the right thing.  Any implementation should strive to disable invalid combinations, even if invalid solely because of language or implementation limitations.

> > In order to make the Assignable archetype neither default nor
> > copy constructible, to ensure that the concept checker
> > doesn't require those capabilities, it cannot be combined
> > with CopyConstructible's or DefaultConstructible's
> > archetypes, at least not as the derivate.
>
> Sorry, but could you give a code example? I still don't see
> your point.

Obviously, I was arguing WRT the current implementation, not to one you had not yet shown and I didn't understand you to be proposing.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.