Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2011-01-27 08:24:22

On Thu, Jan 27, 2011 at 1:52 PM, Dean Michael Berris
<mikhailberis_at_[hidden]> wrote:
> On Thu, Jan 27, 2011 at 8:16 PM, Artyom <artyomtnk_at_[hidden]> wrote:
>>
>> So it shouldn't be "string" as C++ already has one.
>>
>
> By this logic, interprocess' containers shouldn't be called vector,
> map, list, set, unordered_set, unordered_map. That doesn't make sense.

No, because there are *std*::vector & co and there
are *interprocess*::vector & co and I've never heard
that there was an intention to replace the former
with the latter. However there *is* an intention to
replace (in my view extend) std::string.

>
> Like I said (pretty much over and over), I see no need for a
> boost::string implementation to retain backward compatibility
> interface-wise to std::string. As in 0 need especially because it's a
> different string implementation period.

IMO zero (as in 0) backward compatibility => zero (as in 0)
chance of adoption by the standard.
People (including me) who have proposed to just switch
to UTF-8 have met a lot of resistance, just because that would
break some things at run time. And I personally believe that
most (more than 50%) use-cases of string are encoding-agnostic
so it would not basically break anything.

If the standard commission somehow adopted the completely
different string you propose, that would totally *W*H*A*C*K*
pretty much all existing C++ code. std::string is not std::auto_ptr.

>
>
> And IMHO std::string's current interface can be deprecated by a
> suitably convinced standard committee.

And IMHO this will happen only if you, besides the new
string, have also invented a mind-control death-ray :)

>
> It's like std::auto_ptr being deprecated along with the interfaces of
> dozens of other libraries. If boost::string is a really well
> implemented string that does things really really well, then I don't
> see why std::string can't be deprecated in favor of an arguably better
> but certainly different string paradigm.

No, std::auto_ptr is/was nowhere near std::string when considering
the "frequency of usage".

>>
>> 1. Make it fully backward compatible with std::string
>> 2. Call it by different name.

+1

BR,

Matus