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