September 13, 2014
>> Smart pointers are rarely used, most C++ stuff is done by value.
>
> Strings too?

 Two string types are used.

-std::string type: by value, has smaller buffer optimization, used at startup/logging, and for any dynamic strings with unbounded possible values

-immutable string handles: by value. When created it looks up into a hash to find or create that string. Two immutable strings with the same value, will always use the same pointer(like Lua). These are never destroyed, they are intended as handles.
September 13, 2014
On Saturday, 13 September 2014 at 12:05:59 UTC, po wrote:
>>> Smart pointers are rarely used, most C++ stuff is done by value.
>>
>> Strings too?
>
>  Two string types are used.
>
> -std::string type: by value, has smaller buffer optimization, used at startup/logging, and for any dynamic strings with unbounded possible values

Are you sure? From basic_string.h:

	_CharT*
	_M_refcopy() throw()
	{
#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
	  if (__builtin_expect(this != &_S_empty_rep(), false))
#endif
            __gnu_cxx::__atomic_add_dispatch(&this->_M_refcount, 1);
	  return _M_refdata();
	}  // XXX MT
September 13, 2014
> Are you sure? From basic_string.h:
>
> 	_CharT*
> 	_M_refcopy() throw()
> 	{
> #ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
> 	  if (__builtin_expect(this != &_S_empty_rep(), false))
> #endif
>             __gnu_cxx::__atomic_add_dispatch(&this->_M_refcount, 1);
> 	  return _M_refdata();
> 	}  // XXX MT

 COW is just an implementation detail of GCC's crappy string.

 Microsoft string for instance, does not do COW, it uses a 15 byte SBO. And you can also just replace it with your own string type(EASTL)
September 13, 2014
On 9/13/14, 9:13 AM, Kagamin wrote:
> On Saturday, 13 September 2014 at 12:05:59 UTC, po wrote:
>>>> Smart pointers are rarely used, most C++ stuff is done by value.
>>>
>>> Strings too?
>>
>>  Two string types are used.
>>
>> -std::string type: by value, has smaller buffer optimization, used at
>> startup/logging, and for any dynamic strings with unbounded possible
>> values
>
> Are you sure? From basic_string.h:
>
>      _CharT*
>      _M_refcopy() throw()
>      {
> #ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
>        if (__builtin_expect(this != &_S_empty_rep(), false))
> #endif
>              __gnu_cxx::__atomic_add_dispatch(&this->_M_refcount, 1);
>        return _M_refdata();
>      }  // XXX MT

C++11 makes all refcounting implementations of std::string illegal. -- Andrei
September 13, 2014
On Saturday, 13 September 2014 at 19:34:10 UTC, Andrei Alexandrescu wrote:
> C++11 makes all refcounting implementations of std::string illegal. -- Andrei

#facepalm
September 13, 2014
On Saturday, 13 September 2014 at 19:34:10 UTC, Andrei Alexandrescu wrote:
> C++11 makes all refcounting implementations of std::string illegal. -- Andrei

Ah, so lifetime management can be rolled on top of string if needed? Hmm... makes sense.
September 13, 2014
"Kagamin" <spam@here.lot> wrote:
> On Saturday, 13 September 2014 at 19:34:10 UTC, Andrei Alexandrescu wrote:
>> C++11 makes all refcounting implementations of std::string > illegal. -- Andrei
> 
> Ah, so lifetime management can be rolled on top of string if needed? Hmm... makes sense.

No, it's all eager copy. std::string is thoroughly botched. A good inexpensive lesson for us. -- Andrei
September 14, 2014
On Saturday, 13 September 2014 at 21:46:45 UTC, Andrei Alexandrescu wrote:
> No, it's all eager copy. std::string is thoroughly botched. A good
> inexpensive lesson for us. -- Andrei

I mean possible lifetime management options are:
1. string&
2. string*
3. shared_ptr<string>
4. weak_ptr<string>
5. unshared_ptr<string> (not interlocked; does something like this exist?)

This way string is just like any other object. It's C++ after all, the foot must be shot.
September 14, 2014
Am 14.09.2014 10:27, schrieb Kagamin:
> On Saturday, 13 September 2014 at 21:46:45 UTC, Andrei Alexandrescu wrote:
>> No, it's all eager copy. std::string is thoroughly botched. A good
>> inexpensive lesson for us. -- Andrei
>
> I mean possible lifetime management options are:
> 1. string&
> 2. string*
> 3. shared_ptr<string>
> 4. weak_ptr<string>
> 5. unshared_ptr<string> (not interlocked; does something like this exist?)
>
> This way string is just like any other object. It's C++ after all, the
> foot must be shot.

You forgot a few other ones:

6. string::c_str() (let char* botch string internals)
7. shared_ptr<string>&
8. shared_ptr<string>*
9. weak_ptr<string>&
10. weak_ptr<string>*
11. unique_ptr<string>&
12. unique_ptr<string>*

Just because some one these don't make sense semantically, I am willing to bet someone out there is writing them now.

And I did leave out the move variations, as the list is already quite long.


--
Paulo


September 14, 2014
> I mean possible lifetime management options are:
> 1. string&
> 2. string*
> 3. shared_ptr<string>
> 4. weak_ptr<string>
> 5. unshared_ptr<string> (not interlocked; does something like this exist?)
>
> This way string is just like any other object. It's C++ after all, the foot must be shot.

 Exactly, you can compose string with the semantics you want!
 You are making C++ look good:) Although I can't recall ever actually wrapping a string in shared_ptr/weak_ptr/unique_ptr...

>6. string::c_str() (let char* botch string internals)

It returns a const char* so you would have to cast const away to do that--