2

We know compilers can reuse identical constant string literal to save memory efficiently. This optimization is optional for compilers.

Two string literals have the same pointer value?

const char *s1 = "HELLO";
const char *s2 = "HELLO";

s1 and s2 can have same address. They have the same address in many compilers. For example, both are pointing to the address 0x409044.

Well.

The question in my mind is, why std::string dosen't try to has same advantage? And it doesn't try to just wrap std::string around that address.

const std::string ss1("HELLO");
const std::string ss2("HELLO");

cout << (void*) ss1.c_str() << endl;
cout << (void*) ss2.c_str() << endl;

ss1 and ss2 have two distinct addresses.

Is it technically impossible? Prohibited by the language? Or the developers of implementations of the standard library just don't want it?

Community
  • 1
  • 1
masoud
  • 55,379
  • 16
  • 141
  • 208
  • 2
    I *think* this is forbidden by the C++11 Standard, because such copy-on-write implementations of `std::string` would cause problems in a multithreaded environment – Andy Prowl May 06 '13 at 17:10
  • 1
    @AndyProwl: Seems logical, would you please show the paragraph if it's possible? – masoud May 06 '13 at 17:12
  • See [this Q&A](http://stackoverflow.com/questions/12199710/legality-of-cow-stdstring-implementation-in-c11) – Andy Prowl May 06 '13 at 17:12
  • @Andy can you give a paragraph number in the standard? – Cole Tobin May 06 '13 at 17:25
  • i had a similar question some time ago - and got a lot of interesting discussion http://stackoverflow.com/questions/2312860/correct-idiom-for-stdstring-constants – pm100 May 06 '13 at 17:34

2 Answers2

5

The C++ standard library classes by and large all implement strong value semantics, which means that each object owns all its data, and so the lifetime of the object is easy to reason about. While a reference-tracking implementation might be possible, it would come at a considerable complexity cost, and that doesn't fit the "don't pay for what you didn't ask for" philosophy of C++.

There have long been discussions about non-owning string-like classes (something like string_ref and array_ref, if you want to search for it), which would only be views on existing strings. This would put the burden on the user to ensure that the lifetime of the underlying shared data fits the application. It might become part of the standard in the future, but search around for existing implementations if you're interested.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
0

One reason for this behaviour might be the memory management of the objects:

The std::string objects are responsible for their character arrays. That implies that the arrays are deleted in the std::string destructor - and such an array should only be deleted once.

In C char arrays declared as

const char* bla = "blabla";

are - or should never be - freed.

Baby Groot
  • 4,637
  • 39
  • 52
  • 71
Thomas Wiegert
  • 1