Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-27 07:52:33

On Thu, Jan 27, 2011 at 8:16 PM, Artyom <artyomtnk_at_[hidden]> wrote:
>> From: Dean Michael Berris <mikhailberis_at_[hidden]>
>> To: boost_at_[hidden]
>> 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_at_[hidden]> 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