From: Pavol Droba (droba_at_[hidden])
Date: 2005-05-10 15:40:40
On Tue, May 10, 2005 at 10:53:16PM +0300, Peter Dimov wrote:
> Thorsten Ottosen wrote:
> >"Peter Dimov" <pdimov_at_[hidden]> wrote in message
> >>>If you think this is a problem, you should discuss it with Thorsten.
> >>I'm not looking forward to that.
> >Please do anyway. If you think there is a major problem in the
> >defaults of the Range library, please say so.
> I think that defining size( T[N] ) as N or N-1, depending on whether T is a
> character type, will cause problems in generic code and preclude the
> widespread use of the library.
> Looking at the actual contents of the array for a NULL terminator can be
> even worse, as it may easily lead to undefined behavior.
> In addition, this definition will not adapt well if other character types
> are added as part of Unicode-ification, in particular, if these character
> types are typedefs.
> I, for one, will be avoiding the library because of these issues. "Do the
> right thing" is a design principle that I usually advocate, but in this
> specific case I believe that doing the predictable and consistent thing is
Actualy I'm the author of this idea so I can give an explanation.
I came up to this problem when I was adopting first version of container_traits
(predecessor of Boost.Range) to use with StringAlgo library.
While playing with different range type I have found an unexpected behaviour
when a parameter was of this type:
Actual type of str is char so it also contains terminating zero. And this is
the actual problem.
If we apply the default behavior, on this type (ie, range will include this terminator),
it will make char useless.
More importantly, it will differ from the behaviour of char* and wchar_t*, std::basic_string
and probably any possible string class.
So I'm not sure what is consistent and predicable, but from the user perspective,
char is first of all a string constant. So it should be threated like a string not
like an 'array'.
I consider it very unexpected when boost::end("hello") will not designate end of "hello"
rather end of "hello\0"
Yet I understand you reservations, but the only way out of this problem would be to
define different boost::end() for string ranges. I'm not sure if this is an acceptable way.
However I can see a way how to resolve a problem with future unicode character classes.
Simple trait class can do the job nicely.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk