Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-27 09:07:24

On Thu, Jan 27, 2011 at 9:24 PM, Matus Chochlik <chochlik_at_[hidden]> wrote:
> 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.
>

See, but then boost::string can very well be a typedef to
boost::strings::string -- I don't see why calling it 'string' is such
a bad thing.

And the only way BTW an std::string would be replaced is if the
replacement does things in a different way -- otherwise what's the
point of replacing std::string if it's the same (in my assertion,
broken) 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.

Huh? std::auto_ptr was dropped in favor of std::unique_ptr. They
didn't need to deprecate auto_ptr but they chose to do that and
introduce unique_ptr in its place.

> 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.
>

Silently breaking at runtime is just unacceptable. Breaking at compile
time is way better.

> 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.
>

So what's wrong with deprecation again? And what makes std::string so
different from std::auto_ptr when they're both defined in the standard
library? I don't see the point you're trying to make.

>>
>> 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 :)
>

Well that remains to be seen right? :)

>>
>> 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".
>

Deprecation wasn't about frequency of usage. It was about fixing
things that were deemed broken.

-- 
Dean Michael Berris
about.me/deanberris