CODEWITHSUNDEEP
c++stl
Ashot
Ashot

Reputation: 10959

Do stl containers use implicit sharing?

Its known that Qt widgets use implicit sharing. So I am interested if stl containers std::vector, std::string use implicit sharing too.

If no, why? Since it is very useful.

And if the answer is yes, how we can ascertain in it? I need simple C++ stl program which shows that stl containers use implicit sharing. It doesn't do deep copy when is copied.

Upvotes: 10

Views: 2418

Answers (4)

Johannes Overmann
Johannes Overmann

Reputation: 5151

STL containers do not use implicit sharing. They always have plain value semantics.

The reason is runtime performance: In multithreaded programs (potentially but not necessarily running on multicore hosts) the locking overhead of the housekeeping data (e.g. reference counting, locking while copying before writing) by far outweighs the overhead of a plain value copy, which has no special threading implications at all. It is expected that programs which would suffer from copying around huge std::maps implement explicit sharing to avoid the copying.

In fact in the very early days of STL std::string did use implicit sharing. But it was dropped when the first multicore CPUs came up.

Upvotes: 2

Yakov Galka
Yakov Galka

Reputation: 72489

No. They cannot. When you try to modify the contents of the container, or even calling a mutable begin() on it, it would imply a potential copy-on-write and thus invalidate all references and iterators to the container. This would be a hard to debug situation, and it is prohibited.

Although std::string is technically not a container, it is still prohibited to do copy-on-write since C++11:

References, pointers, and iterators referring to the elements of a basic_string sequence may be invalidated by the following uses of that basic_string object:
...
— Calling non-const member functions, except operator[], at, front, back, begin, rbegin, end, and rend.

[string.require]

... Since it is very useful.

Heh, what for? Passing by reference almost always solves all 'performance problems'. Atomic ref-counts are inherently non-scalable on multi-processors machines.

Upvotes: 12

marko
marko

Reputation: 9159

Aside from the objections raised by others to CoW behaviour in containers, here are a few more. These all fall into the category of behaviour that defies convention, and will therefore cause bizarre bugs from unsuspecting developers.

Exceptions

Allowing CoW would means that innocuous mutation operations on a container can fail with exceptions when they wouldn't otherwise. This would be a particular hazard with operator[] on either a std::vector or std::string

Threading

One might reasonable expect to be able to copy construct a container with the express purpose of handing it off to another thread without worrying about concurrency thereafter. Not so with CoW.

Upvotes: 5

Artem Sobolev
Artem Sobolev

Reputation: 6069

As it's noticed in similar question:

The C++ standard doesn't prohibit or mandate copy-on-write or any other implementation details for std::string. So long as the semantics and complexity requirements are met an implementation may choose whatever implementation strategy it likes.

I think, same is true for std::vector

Also, you may be interested in this topic: How is std::string implemented

Upvotes: 3

Related Questions