|
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 about.me/deanberris
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk