Initialising map member without copy

[Jerry Coffin]

[ ... ]

But in my specific case, there is no complex resource management to speak
of: an object is part of the map and that's all. The use of smart pointers
is just a work-around for the fact that the gcc implementation of std::map
does two gratuitous copy operation when inserting via operator[]. Not a big
problem here: my objects are tens to hundreds of kB, therefore the use of a
smart pointer is negligible. But in general I don't see why you would have
to use smart pointers when there are no smarts required, or why you have to
implement a copy constructor when all you do is just insert into and erase
from a map, but never copy the map or anything like that. Keeping copy
constructors up-to-date is tedious and error prone after all.

But you _do_ want the smart pointer to add some intelligence. You want
it to implement copy on write, so the copies involved in putting the
item into the container are cheap, but the object still gets destroyed
when there are no more references to it.

The smart pointer should (normally) eliminate the requirement for a copy
constructor in the underlying object. The most you typically do is
declare a (private) copy constructor, but never implement it. This
allows the compiler to diagnose any code that does anything that would
result in the expensive copies you're trying to eliminate.

 

[James Kanze]

James Kanze schrieb:

Don't start rumours. The destructor will be called. You have
to set the 'moved' object into a self consistet state
(null-pointers, for example), so that you don't run into
undefined behaviour when the destructor will be called.

OK. Sorry about that. I'll admit that about all I know about
this is that the proposal exists, and that its motivation is to
solve this sort of performance problem. Since I've never
actually had such performance problems, it's not been an
important proposal from my point of view, and I've not followed
it at all.

 

[Thomas J. Gritzan]

OK. Sorry about that. I'll admit that about all I know about
this is that the proposal exists, and that its motivation is to
solve this sort of performance problem. Since I've never
actually had such performance problems, it's not been an
important proposal from my point of view, and I've not followed
it at all.

Its not just an optimisation.

The standard containers will be changed so that storing non-copyable but
moveable objects in it will be possible (the containers will be non
copyable then). Think about std::vector<std::fstream>, for example. Or for
storing polymorphic objects in a std::vector<std::unique_ptr<T>>, without
the (sometimes unneeded) overhead of shared_ptr<>. GUI widget, thread
objects, sockets, entity objects in general, are non-copyable.

 

[Paul Brettschneider]

Its not just an optimisation.

The standard containers will be changed so that storing non-copyable but
moveable objects in it will be possible (the containers will be non
copyable then). Think about std::vector<std::fstream>, for example. Or for
storing polymorphic objects in a std::vector<std::unique_ptr<T>>, without
the (sometimes unneeded) overhead of shared_ptr<>. GUI widget, thread
objects, sockets, entity objects in general, are non-copyable.

Hallelujah!

I hope the next version of C++ lives up to its promises:
Moving of object (vs. deep copy+destroy), simple containers with
non-copyable objects, automatic type determination for variables and
concepts. All things I really long for.