Boost logo

Boost :

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

On Thu, Jan 27, 2011 at 10:37 PM, Artyom <artyomtnk_at_[hidden]> wrote:
>> From: Dean Michael Berris <mikhailberis_at_[hidden]>
>> By this logic, interprocess'  containers shouldn't be called vector,
>> map, list, set, unordered_set,  unordered_map. That doesn't make sense.
> They are intendant to remain in interprocess namespace and have
> same functionality as standard list/set etc.

Actually, it's going to move to Boost.Containers IIRC -- but that's
largely beside the point I know.

> This is different case.

Yes I realize that now after recalling that it is after all following
and somewhat backporting the C++0x interface to C++03 for the
containers and allocators.

>> And IMHO std::string's current interface can be  deprecated by a
>> suitably convinced standard committee.
>> 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.
> Deprecated, not changed in backward incompatible way.

Right. I realize that as well. :)

>> std::string can be  deprecated if the standards body agree that there's
>> cause for it to be  deprecated. And the different name is frankly  just
>> unnecessary.
> It may be deprecated, not removed become broken. Personally I
> don't think that immutability worth breaking 95% of existing code.
> So just call it boost::text, boost::unicode_string, boost::immutable_string
> or whatever you want, but boost::string is bad idea.

Right. Maybe `istring` would be succinct enough to convey the idea.

Let me think about that a little bit more -- and if others have better
ideas than `istring` I'd love to hear them. :)

Dean Michael Berris

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