Forward declaring standard library classes

[Chris Jefferson]

Paolo Carlini wrote:

> Theodore Papadopoulo wrote:
>
>> In each container add a :
>> typedef {true_type,false_type} swappable;
>>
> People, while working on such (very interesting!) ideas, are you
> aware of the closely related proposal from Dhruv? I think this
> is the latest version:
>
>    http://gcc.gnu.org/ml/libstdc++/2004-07/msg00076.html
>
> Paolo.
>
> P.S. ... but I sincerely hope that you can work out something
> simpler, as a start... ;)

It's all very complex!

For those who are interested, here is what I believe the current options 
are (without extra compiler support..)

1) One thing we want to do in <algorithm> is to have two objects a and b 
which are already constructed and copy the current object in b to a, 
while leaving b in a consistant state. This isn't too difficult, I do 
this with a moveto(a,b) function, which is currently always implemented 
by a=b or swap(a,b). This in some cases creates a tiny inefficency to 
just doing lots of swaps, but saves doubling the amount of code :)

2) The other problem, which occurs in <algorithm> is constructing a new 
object based on an old one. My currently perfered way of doing this 
would be to write something like:

Class a = move(b); where move wraps 'b' in an class of type "move_type", 
which can decay back to b for classes which don't understand it, but 
also a could make use of the move_type object if it knows about it. 
However this would require changing the public interface of these classes...

For both built-in types and STL containers, this is not going to be much 
less efficent than writing:
Class a; moveto(a,b); as assuming we intend to leave b in a consistant 
state we need to "build the relevant bits" anyway. However, this will be 
very inefficent for classes which are neither a) built in (so the moveto 
can get optimised away) or b) have an efficent implementation of moveto...

3) The final problem, as contained in <vector> is that sometimes we want 
to simply move an object, so don't care about leaving the old version in 
a valid state. We could in theory write a function of the type 
destroy_move(a,b) which would create an object at &a and at the same 
time deal with destroying the object at &b. However apart from in 
std::vector I'm not sure how useful this would be..

The main problem I think is that I can't see any way of a) keeping 
int,float,etc. as efficent as possible (vital), b) optimising the STL 
containers and c) Making sure we don't produce a 2x slowdown in 
user-written classes where construction+copy can't be optimised away but 
which lack an efficent swap function e) adding another constructor to 
all the classes in the STL which accepts an object wrapped in a 
"move_type" and e) not writing almost every function twice. At the 
moment we are giving up b) which is unacceptable, but I'm not sure which 
out of c), d) or e) should be the one we give up on... I would like to 
give up on e), I think adding a "move" constructor would keep things 
reasonably clean and much faster, while at the same time not destroying 
the performance of user classes.

Chris