Re: [boost] Re: Re: Formal Review: FOREACH macro

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