Douglas Gregor wrote:
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.
I think it is possible to be more specific about the kind (can't use the word class here) of class I intend to represent by volatile. It contains only values by member, and pointers to memory which it has allocated on construction or in an explicit "init (or open, or allocate)" type of call, which are explicitly freed in its destructor, or in an explicit "destroy (or close, or free)" type of call. It has only the default copy operator. A struct with no member functions, which contains pointers to allocated memory, and for which there exist helper functions to allocate and delete the memory associated with the pointers, fits this description, and is exactly what is found in a lot C style programming. I think that being able to use STL in a shop full of C style programs and programmers is a good thing. It lowers the threshold for entry into the STL and C++ style of programming. Its not only code, but human back-compatability which must be considered. Vector resizing is not impossible for such a structure. How to: Default copy is made (exactly copy of values and pointers) and no destructor is called afterwards. That's what I meant when I said "destructor should not be called after copy operation". /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. The fact that they can't be held safely in std::vector is exactly the problem I wanted to address.
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.
Does SGI or Boost have a trait assigned for all predefined types? struct predefined_type_true {}; struct predefined_type_false {}; // default template <class T> struct predefined_type_traits { typedef predefined_type_false predfined_type; }; // the predefines char, unsigned char, int, long, etc. template <int> struct predefined_type_traits { typedef predefined_type_true predfined_type; }; etc ...
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.
This is quite true. "volatile" would require a manual assignment of trait.
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 :)
I think that is the correct conclusion ... given infinte dealines and a universal desire to adopt STL programming in a single gulp. Only if we live in a less than ideal world is there any reason to do otherwise.
Doug
Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
[Non-text portions of this message have been removed]