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

From: hicks (hicks_at_[hidden])
Date: 2001-12-12 03:49:27

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_at_[hidden]>
> 
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
>
>
>
>
>

[Non-text portions of this message have been removed]