Re: avoid the use of default constructors in stl_algo.h

[Gunter Winkler <guwi17 at gmx dot de>]

Am Mittwoch, 14. Februar 2007 19:17 schrieb Mws:

> if you construct the forward_iterator like it is implemented it is
> contructed _once_ during the whole operation.
> the only thing done afterwards is using the assignment operator to
> adjust its content.
>
> in your case the object is constructed through the copyconstructor
> during each cylce of the while loop and destructed afterwards.
>
> so the first implementation you found in the stl sources is more
> optimised than yours.

Ok, I understand that point. However the question is what is more 
expensive? Can imagine a situation where the assignment (to a possibly 
default constructed) iterator is less expensive than the 
copy-constructor?

my only example is an iterator that stores a few references/pointers and 
an index. 

class pair_iterator {
  T * d1;
  T * d2;
  size_t  idx;
...
}

if I disallow the default constructor I can use

pair_iterator & operator= (pair_iterator & other)
{ idx = other.idx; }

if I allow the default constructor (which can in no way initialize d1 
and d2 to something useful) I would have to write

pair_iterator & operator= (pair_iterator & other)
{ d1 = other.d1; d2 = other.d2; idx = other.idx; }

which does exactly the same as the usual copy constructor.

Thus the open question is: How expensive are default cons, copy cons, 
assign and destruct for "typical" iterators?

I usually have trivial default cons. and trivial destructor, similar 
copy and assignment operations.

The second question is: Should the algorithms enforce the existence of 
default constructors - which prohibits some optimizations of later 
assignments - or not?

As a compromise it would be easy to change all default constructions to 
copy constructions.



mfg
Gunter