Re: [Boost-Users] Re: graph destructor and resizing in general

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-12-10 10:05:45

On Sunday 09 December 2001 09:22 am, hicks wrote:
> Having read about traits recently, I wonder if it shouldn't look like this:
>
> // default class
>
> struct ctor_types
> {
>     struct empty {}; // no tor called, no code executed; can optimize
>     struct trivial {}; // default constructor can be called for single
> element, and that can be copied
>     struct volatile {}; // default constructor must be called seperately
> for each element
>                     // and destructor should not be called after
> container internal copy operation (e.g. vector resize)
> };
> Note that STL currently defaults to ctor_type::trivial,
> whereas a call to new T[n] preforms what is indicated by volatile.
> Because of this, some classes are not safe to use with STL.

This is explicitly stated as part of the CopyConstructable requirements. 
Besides, if one has a user-defined type with such a strange copy constructor, 
vector resizing, for instance, would be impossible.

As a side note, the mapping between your vocabulary here and the SGI standard 
template library is:
Yours <-> SGI
empty <-> trivial
trivial <-> CopyConstructible
volatile <-> no equivalent SGI term

> (These must be a less coding intensive way to do this)

Not that I've found, unfortunately; however, one can often lump traits 
together into larger concepts, and arrange the concepts in a concept lattice 
to minimize the typing required. 

In this case, the compiler can sometimes fill in the traits. For instance, if 
a constructor or destructor does nothing, the "empty" (or SGI "trivial") 
property can be asserted; however, the compiler cannot generally tell whether 
a constructor meets your "trivial" or "volatile" requirement, so it must 
assume the worst.

> but some classes which are not currently STL safe would also become
> compatible with STL by defining ctor_type as ctor_types::volatile.
> (Such classes allocate memory to pointers on construction
> and simply copy the pointers during a copy operation.
> Obviously STL uncouth but common in practice, no?)

I'm not sure this is a good thing; classes that aren't CopyConstructable are 
strange beasts, and one must be _extremely_ cautious in their use. For 
instance, they can't be returned or passed by value, can never be safely held 
in a std::vector, and generally cause migraines because they _look_ like they 
are CopyConstructable but they don't _act_ like it.

I'd be happy to see this type of object go gently into that good night. I'm a 
big fan of the "a type must be either CopyConstructable or Noncopyable." If 
my name was Scott Meyers, I'd put that in a book :)

        Doug