
While this isn't strictly related to the development of boost, I believe it may be interesting to developers of boost, and I would also be very interested in hearing any opinions (good and bad) from users and developers of boost. I am currently in the process of implementing all applicable (sort, rotate, partition, etc..) functions in the C++ standard library using only calls to iter_swap. Obviously for those classes with expensive copies and cheap swaps (list, vector, map, set, etc) this is a big win, however it unfortunatly can be slightly slower for classes and types which fall on the basic definition of swap. Therefore there will be an implementation-specific type trait defined (name to be decided) which can be defined to enable the swapping versions of functions. I'm implementing much of this for my own personal usage, but I hope to submit the code to libstdc++-v3 (g++'s implementation of the c++ standard library). While this may not be quite as general as the ideas of "move symantics", it has the advantage of being implementable now, and providing some significant improvements. I would be interested in knowing if anyone has any comments, and also should such code be implemented in g++ if boost would be willing to add the compiler-specific extra information to mark any classes with efficent swap as such. Note: I am aware there are various ways of trying to approximate if someone has specialised swap, such as checking for a swap member function. However at least at first, it is my belief such a library should probably be strictly op-in. Thank you, Chris

Chris Jefferson writes:
I am currently in the process of implementing all applicable (sort, rotate, partition, etc..) functions in the C++ standard library using only calls to iter_swap. Obviously for those classes with expensive copies and cheap swaps (list, vector, map, set, etc) this is a big win, however it unfortunatly can be slightly slower for classes and types which fall on the basic definition of swap. Therefore there will be an implementation-specific type trait defined (name to be decided) which can be defined to enable the swapping versions of functions.
I'm implementing much of this for my own personal usage, but I hope to submit the code to libstdc++-v3 (g++'s implementation of the c++ standard library).
May be also STLPort?
While this may not be quite as general as the ideas of "move symantics", it has the advantage of being implementable now, and providing some significant improvements.
Not to undermine your effort, but "move semantics" is implementable now as well. -- Aleksey Gurtovoy MetaCommunications Engineering

Aleksey Gurtovoy wrote:
Chris Jefferson writes:
I'm implementing much of this for my own personal usage, but I hope to submit the code to libstdc++-v3 (g++'s implementation of the c++ standard library).
May be also STLPort?
I'm not against it :)
While this may not be quite as general as the ideas of "move symantics", it has the advantage of being implementable now, and providing some significant improvements.
Not to undermine your effort, but "move semantics" is implementable now as well.
I had been thinking about that as well. My personal implementation looks alot like: a) Add a new type_trait called moveable. b) Add a function called move_wrap, where you construct objects you want to move like: Class b, c=move_wrap(d); b=move_wrap(c); Where move_wrap passes it's parameter straight through if the type_trait moveable is false, and wraps it in a class called MoveWrap if moveable is true (which can then be used in the constructors of Class). The advantage of just writing a swapping library is that it isn't going to involve adding new constructors / destructors based on a templated-based implementation of moveable, which might be incompatable with other people's definition of moveable. Chris
participants (2)
-
Aleksey Gurtovoy
-
Chris Jefferson