From: Pavol Droba (droba_at_[hidden])
Date: 2005-05-10 15:40:40
Hi,
On Tue, May 10, 2005 at 10:53:16PM +0300, Peter Dimov wrote:
> Thorsten Ottosen wrote:
> >"Peter Dimov" <pdimov_at_[hidden]> wrote in message
> >news:00a101c550d8$39178d50$6401a8c0_at_pdimov2...
> >>
> >>>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
> better.
>
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:
char str[]="Hello"
Actual type of str is char[6] 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.
Regards,
Pavol