From: Maxim Yegorushkin on
On 07/11/09 02:04, tohava wrote:
> On Nov 6, 1:21 am, ShaunJ<sjack...(a)gmail.com> wrote:
>> avoided? Do any implementations of STL implement copy-on-write
>> semantics for string or vector?
>
> I'm not 100% sure, but I think STLPort implements string with CoW.

Current STLPort-5.2.1 and STLPort 4 bundled with the latest Sun C++
compilers do not not use CoW. One most disappointing feature of STLPort
std::string is that the default constructor allocates storage, in other
words, a memory allocation is performed even for empty strings.

GNU std::string uses CoW. I hear that the standard interface of
std::string can not be possibly satisfied by a CoW implementation of
std::string, nevertheless I find CoW implementations of std::string the
most practical.

GNU C++ library also provides another string class
__gnu_cxx::__versa_string, which does not do CoW and I've heard that
there are plans to make it the default std::string implementation in the
future, although the CoW std::string implementation will still be
available under a different name.

--
Max

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: yeroen on
> copy-on-write doesn't work well with threads so nobody uses it much
> anymore.


It is perfectly possible to combine CoW and threads when the CoW
classes use atomic-reference counting. This is precisely how the Qt
framework provides fully reentrant implementations of string,
container, and other implicitly shared classes.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Jeff Flinn on
Do any implementations of STL implement copy-on-write
> semantics for string or vector?

MSVC(VC6)/Dinkumware used to do COW for std::string, but found that
small string optimization provided better overall performance.

Jeff

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: SG on
On 7 Nov., 03:04, ShaunJ <sjack...(a)gmail.com> wrote:
> On Nov 6, 2:27 pm, Seungbeom Kim <musip...(a)bawi.org> wrote:
> > ShaunJ wrote:
>
> > > {
> > > string s(100, 'x');
> > > vector<int> v(100);
> > > map<string, vector<int>> m;
> > > m.insert(make_pair(s, v));
> > > }
>
> > make_pair creates a new pair object and returns it by value, so "in
> > principle" s and v will be copied. Of course, the compiler is allowed to
> > perform any optimizations that doesn't change the observable behavior,
> > so there's no "guarantee" that the copies will be made.

Since s and v are lvalues they will be copied. Now, if that means that
all the characters of that string object are duplicated is another
questions and depends on whether the implementation uses CoW or not.
Recent libstdc++ Versions still use CoW (in a thread-safe way) for
std::string. I'm not sure about std::vector. Probably not.

> > In C++0x you will be able to use make_pair(T1&&, T2&&) and "move" s and
> > v, avoiding the copies. As far as I know, the syntax will probably be
> > m.insert(make_pair(move(s), move(v))) (with all std:: omitted).
>
> "In principle" then, would m.insert(pair<string, vector<int>>(s, v));
> avoid making a copy?

No. They have to be copied since s and v are lvalues. Bug again, that
doesn't imply that the string's elements are copied (due to CoW). But
CoW is not mandated, only a possibility.

In C++0x you will be able to write

m.emplace(move(s), move(v));

without having to worry about any copying. The pair object will be
directly constructed "into the map" using its templated constructor
that forwards the rvalues references of move(s) and move(v) to the
constructors of std::string and std::vector.

> I had been treating make_pair as a syntatic nicety, but completely
> equivalent to the constructor of pair.

I think it's safe to say that is is if your compiler supports RVO
(return value optimization) and inlining. You can expect make_pair to
be as efficient as a direct constructor call. If you're concerned
about the performance you could do something like this:

if (m.find(s)==m.end())
m[s].swap(v);

This will create a pair with a copied string as key and a default-
constructed vector. The new vector is immediately swapped with v.

Cheers,
SG

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Jeff Schwab on
Jeff Flinn wrote:
> Do any implementations of STL implement copy-on-write
>> semantics for string or vector?
>
> MSVC(VC6)/Dinkumware used to do COW for std::string, but found that
> small string optimization provided better overall performance.

How does that preclude CoW for non-small strings?

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]