Re: [boost] copy on write for std containers

Subject: Re: [boost] copy on write for std containers
From: Peter Foelsche (foelsche_at_[hidden])
Date: 2010-12-04 19:11:20

"Simonson, Lucanus J" <lucanus.j.simonson_at_[hidden]> wrote in message 
news:26E9B811E137AB4B95200FD4C950886BB6A15442_at_orsmsx507.amr.corp.intel.com...
> Peter Foelsche wrote:
> > I wrote a couple of lines and replaced std::set and std::map with
> some
> > copy-on-write-wrappers
> > and I got a dramatic speed improvement with the last gcc 4.5. I
> think.
> >
> > My code was using recursive functions iterating over a tree
> returning
> > and setting such objects.
> >
> > I looked and it seems there is nothing like this in boost!
> >
> > Ideally this should be an template argument for the std containers.
>
> No.  The problem you have solved is not general and furthermore it is
> not the right solution.  Rather than pass containers by value and
> return by value it is standard practice to pass by const reference
> and make a copy when you are aware that you want to modify a copy.
> To return a container pass it by non-const reference and populate it,
> which avoids copy on return.  Finally there is iterator semantics
> which also allow efficient usage of the STL.  The solution to this
> performance problem is to use the STL correctly in the first place.
> Your code would be faster still without the extra level of
> indirection and extra memory allocations of the wrapper.

The container returned was in fact a container containing other containers.
Thus I might have saved making a copy of the outer container by passing the 
object by address
(are you actually using non-constant references to obfuscate your code?)
the inner containers still would need to be copied.

Anybody know in which cases the compiler optimizes away
or does not optimize away the call to the copy-constructor
when returning an object by value?

I still think that something like this should be available in some library 
for people,
which cannot write such a wrapper in a few minutes by themselves.