🚀 go-pugleaf

> Dan Holmsand <dan@et.se> writes:
> >Is operator.() banned from the standards discussion?

I'm really sorry for reopening this old wound, but many thanks anyway
for all the answers.

My reason for asking was my own "discovery" that the STL containers and
algorithms are clearly overrated - sure, they are very efficient indeed
for simple objects with trivial constructors. However, if you consider
a vector<vector<string> >, and insert a new element at the beginning of
the outer vector, the resulting code is clearly less than efficient
(copy constructing all the strings of all the vectors is everything
but efficient).

That's why I was hoping for smart references to come to the rescue when
needed, say by redefining the original vector as
vector<smart_ref<vector<string> > >, to gain the speed benefit of a
faster copy constructor, while not having to rewrite all the code
involved.

#pragma dream on

Another way out would be the ability (and now I am dreaming again, I
know) to tell the standard algorithms how to move an object from one
location in memory to another (as opposed to copying them), say by
means of a couple of simple functions - "move" and "uninitialized_move"
(corresponding to the copy functions), whose default implementation
would be to copy construct an object in a new place, and destroy its
copy in the old location. That function could easily and safely be
specialized for, say, vector<T, Allocator> and string, to be a simple
copying of pointers. I guess that nearly all copy constructors could be
optimized in this way, given that the old copy is guaranteed not to be
destroyed nor used in the future.

In effect, a standardized "move" function would give the language the
"move constructor" that the auto_ptr seems to be needing.

That should make, for example, the reshuffling of vectors and sorting
of containers efficient for "move aware" objects with nontrivial
constructors.

#pragma dream off

However, the real solution for me will be to ALWAYS use "pointers" in
collections, since I can always, easily, and without rewriting
everything change from one smart pointer (say, my current favourite,
the fabulous gc_ptr<T> :-) to another (containing, say, a real T if the
profiler says I can live with the copying overhead).

The fact that I can do this, without losing any efficiency and without
making any hacks in the standard algorithms, has a great deal to say in
favour of the proposed standard.

Thanks again,

Dan Holmsand
Affdrsvdrlden
dan@et.se
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]