|
Boost : |
From: Pavol Droba (droba_at_[hidden])
Date: 2005-05-11 09:05:18
On Wed, May 11, 2005 at 04:11:59PM +0300, Peter Dimov wrote:
> Pavol Droba wrote:
>
> >To sumarize, I fully understand you concerns, but you have to try to
> >understand mine.
>
> >>From the perspective of string processing, that current approach is
> >>perfectly legal
>
> >and I dare to say, that it is on par with usage you trying to achive.
> >So let's try to come to some solution, that will be acceptable for
> >both parties.
>
> I am not interested in compromises or acceptability to "both parties". If I
> were designing a string library, I wouldn't attempt to redesign a
> lower-level range library so that it fits my needs. I can easily implement
> whatever hacks make sense at my level rather than pushing them a level down.
>
> That's just my opinion, of course. I may be wrong.
>
It is hard to argue if the other party is not trying to understand.
You are trying to leverage the purity of design to the actual usefulnes.
It is nice goal, but it is not suitable for real people.
We can make Range library to work as you request, but it would make it fully
unusable on string literals.
And correct me if I'm wrong, but from the C++ programmer perspecive, char[]
is in 90% cases used as a string literal.
Arbitrary character array is used mostly as legacy api interface. For all
other usages, there is std::vector and alike.
I'm not saying that the current design is perfect, but until now, nobody has
shown any complaints nor reported any problems.
Given the fact, that Boost.Range is in CVS for a year I consider it as small proof,
that it is not broken that much.
Now a small remark towards the string library. I strogly suggest that you look
more closely to Boost.Range and Boost.StringAlgo and the way they are tied togheter.
StringAlgo is not a "string" library, rather an "algorithm" library. It can deal with
any container that Range supports.
Since Boost.Range is interfacing with a container, me as a library writter have a
limited number of oportunies to introduces "hacks". Not mentioning that I don't want to.
So it is up to Boost.Range to handle this issues. I will gladly make any fixes in the
StringAlgo lib to accomodate a possible changes in the Range interface. However,
it must be officialy possible.
As I have already stated, I don't think, that StringAlgo library is somehow special
in this regard.
Any library that will use Range will be affected. I pretty sure, that majority of
users will be suprised by the fact that statement:
a_generic_algorith("hello")
will process "hello\0" rather then "hello"
Best Regards,
Pavol
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk