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

From: hicks (hicks_at_[hidden])
Date: 2001-12-09 09:22:02

Thanks for replying.

Douglas Gregor wrote:

>On Saturday 01 December 2001 10:41 am, you wrote:
>
>>I want to make this explanation short so I will skip details.
>>In a nutshell, during destruction or resize, a destructor
>>is explicitly called from a loop for each element which has
>>been constructed. Obviously this is desireable much of the time,
>>but it is true even if the element type has an *empty* destructor.
>>This can take a lot of unecessary time, like 10's or even a few 100
>>milliseconds, which can make a big difference in, say, inspection
>>software used in an industrial production line.
>>
>
>This isn't really a problem with the specification of std::vector, but is a 
>quality-of-implementation issue. If one knows that the destructor is trivial, 
>one can compile a version of the destruction/resize code that does not 
>contain a destruction loop.
>
>In any case, I believe the solution is this:
>
>template<bool> truth_type {};
>
>template<typename InputIterator>
>inline void destruct_elements_in_range(
>		InputIterator first, 
>                             InputIterator last,
>		truth_type<true>)
>{
>  // The elements in the range have trivial destructors, so do nothing
>}
>
>template<typename InputIterator>
>inline void destruct_elements_in_range(
>		InputIterator first,
>		InputIterator last,
>		truth_type<false>)
>{
>  typedef typename std::iterator_traits<InputIterator>::value_type T;
>  for(; first != last; ++first) {
>    T* victim = &(*first);
>    victim->~T();
>  }
>}
>
>template<typename T>
>class vector {
>private:
>  void destruct_elements() {
>  destruct_elements_in_range(begin(), end(),
>	truth_type<boost::has_trivial_destructor<T>::value>());
>  }
>};
>
>The user will generally need to add a specialization for any type with a 
>trivial destructor (or some compilers may support this, eventually).
>
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.

struct dtor_types
{
    struct empty {}; // no tor called, no code executed; can optimize
    struct volatile {}; // default desstructor must be called seperately 
for each element
};
Note that STL currently defaults to dtor_type::volatile

// default class_tor_triaits using current STL defaults
template <class T> class_tor_triaits
{
      typedef  ctor_types::trivial ctor_type;
      typedef  dtor_types::volatile dtor_type;   
};

// specializations
template <int> class_tor_triaits
{
      typedef  tor_type::empty ctor_type;
      typedef  tor_type::empty dtor_type;   
};
etc. ....
(These must be a less coding intensive way to do this)

Finally in the user code

template <MyClass> class_tor_triaits
{
      typedef  ctor_types::volatile ctor_type;
      typedef  dtor_types::empty dtor_type;   
};

template <MyOtherClass> class_tor_triaits
{
      typedef  ctor_types::empty ctor_type;
      typedef  dtor_type::empty dtor_type;   
};

Now containers for class T can query class_tor_traits<T>
to decide how to proceed with initialization and destruction.
If this were implemented, not only would optimization become possible,
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?)

Cheers
    Craig Hicks
    Engineer, KGK Tokyo

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