On Thu, Jan 27, 2011 at 8:16 PM, Artyom <artyomtnk@yahoo.com> wrote:
From: Dean Michael Berris <mikhailberis@gmail.com> To: boost@lists.boost.org Sent: Thu, January 27, 2011 1:22:17 PM Subject: Re: [boost] [string] proposal
On Thu, Jan 27, 2011 at 7:06 PM, Artyom <artyomtnk@yahoo.com> wrote:
Then don't call this thread [boost][string] proposal and don't call it boost::string
Why not? If it's different from std::string why wouldn't boost::string be a proper name?
Because as you mentioned below, many things from boost go to std, i.e. shared_ptr, function, bind and many others.
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.
<emphasis> [snip] I would say exactly that: std::string is broken and it doesn't deserve to be the string implementation that C++ programmers have to use. </emphasis>
You think it is broken, others:
- Some think it is fine. - Some think its API may be improved keeping it backward compatible - Some think that algorithms that use string may be improved. - And some do think it is broken
Okay, so that's important because... ? 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. To those who think std::string is fine, then keep using it! To those who think its API may be improved and keep it backward compatible then good luck with that. The algorithms improvement, sure we always need better algorithms. And to those who think it's broken like me, then let's do something about it.
Who gave you the monopoly on what `string` should mean? :P
Nobody gave me a monopoly, however such monopoly had given to C++ standard committee that had defined what string means in C++'s standard namespace.
It is fine have other strings but IMHO they should not be called boost::string.
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.
Seriously though, the point is this: Boost has an opportunity to influence some, if not a big part of the C++ community at large. What would be the point of doing another string that everybody else has done before when there's a chance that a different take on it can be potentially better than what's already there?
Different not better as better is a matter of taste - I personally love std::string, especially GCC's implementation with COW.
To each his own then. ;)
I mean seriously, the world has flex+yacc -- imagine if Joel thought to himself and said "well, it works, that's fine, but it's ugly and I can deal with it so...
Believe me you don't want to start Spirit vs Yacc+Bison :-)
You missed the point. The point I was making was that Spirit has its place in Boost because it does something different from the norm. It was developed with one thing in mind: make defining parsers in pure C++ using an embedded DSL possible. It's a different way of doing it and whether it's better is not relevant -- that it's there and being used by people no matter how many/few is what's important. For the record though I personally think the Spirit way is the better way, but of course that's IMHO.
still the one best implementation of a shared pointer is the one in Boost.
Yes and now it is in Tr1! And if you want string to come to tr1 you need either:
1. Make it fully backward compatible with std::string 2. Call it by different name.
Nope, I disagree with both. 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. HTH -- Dean Michael Berris about.me/deanberris