On Thu, Jan 27, 2011 at 10:37 PM, Artyom <artyomtnk@yahoo.com> wrote:
From: Dean Michael Berris <mikhailberis@gmail.com>
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