Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at