Re: Initialising map member without copy
Roland Pibinger wrote:
On Sun, 02 Mar 2008 10:33:55 +0100, Paul Brettschneider wrote:
Of course there are uses for smart pointers in containers, I don't really
understand where Roland is coming from either.
shared_ptr is a resource manager which destructs one dynamically
allocated object (in the normal case). It's not a lightweight resource
manager because each shared_ptr internally needs a dynamically
allocated refernce counter.
Using shared_ptr for a container is like using an oven in each room
instead of a central heating.
The overhead is negligible in many (most?) cases.
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[].
This is not a gcc problem but the basic STL design philosphy. STL
works with values, only with values.
Oh, really? Does it say anywhere that insertion via operator[] must or
should do two copies? If not, then IMHO it's a QOI rather than a design
issue.
It's easy to initialise a std::pair in place without copy (ignore the
alignment issues):
#include <iostream>
#include <map>
#include <string>
class Test {
std::string x;
private:
Test &operator=(const Test &t);
Test(const Test &t) : x(t.x) { throw "Copy!\n"; };
public:
Test() : x("Some content") { std::cout << "Default!\n"; };
~Test() { std::cout << "Destroy!\n"; };
void test() { std::cout << x << "\n"; };
};
typedef std::pair<std::string, Test> pair_t;
int main()
{
char mem[sizeof(pair_t)];
pair_t &test = *(new(mem) pair_t());
test.second.test();
test.~pair_t();
return 0;
}
So I have to wonder why the gcc libraries aren't doing something like this.
Especially considering that std::pair is internal to the library, so it can
play all kind of dirty tricks not available to the application.
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.
Your 'objects' probably are objects in the sense of OO, not values.
That's the problem. Try to figure out the difference between copyable
values and non-copyable objects.
I understand that for full use of STL you need copyable values. But I don't
see why, when using only a subset, in my case insertion into and deletion
from a map, it shouldn't work with non-copyable objects. As it is, I have
to use boost::ptr_map which does much more than needed for my simple
use-case.