On Thu, Jan 27, 2011 at 9:24 PM, Matus Chochlik <chochlik@gmail.com> wrote:
On Thu, Jan 27, 2011 at 1:52 PM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Thu, Jan 27, 2011 at 8:16 PM, Artyom <artyomtnk@yahoo.com> 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