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

From: Pavol Droba (droba_at_[hidden])
Date: 2005-05-11 03:17:01

On Wed, May 11, 2005 at 12:27:45AM +0300, Peter Dimov wrote:
> Pavol Droba wrote:
> 
> >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.
> 
> This is pretty much what I was saying. Looking for a NULL terminator is 
> only acceptable when you know that you are dealing with NULL-terminated 
> strings.
> 
> If I'm writing generic code that works on C arrays, I'll use N as the size 
> of T[N]. If I'm writing generic code that works on strings, I'll use N-1 or 
> strlen. I won't use the Range library in either of these cases because it 
> tries to guess which one I need. 
> 

Actualy I think, that Range works pretty well for string applications. 
But I'm all in favor to make things more consistent.

What about introducing str_end() functions. The default implementation 
would fall-back to end(), but it can be overriden for special cases
(like char[]).
If we go this way however, we must remove direct suppor for null-terminated
strings like char* and leave it only to str_end(). Since otherwise there
will still be a bit of confusion.
Naturaly, there will be need for str_size, and possibly str_begin (for consistency).

So far it seems easy. But there is a catch as usualy. There are generic facilities
like FOREACH, that iterate over an arbitrary range.
Question is "what is an arbitrary range?". If we split the range interface into
two distinct groups, same will have to be done for FOREACH and any such facility.
And things can get even worse if by change we come up to another range branch.

Let's try another approach then. It is possible to create an adaptor, 
that will create an iterator_range out of a problematic range.

So if you instead of direclty passing the value, you will encapsulate it first
and pass it like this:

char[] ch={'h', 'e', 'l', 'l', 'o', 0 ,'b', 'y', 'e'};

array(str) // array like approach -> result [hello\0bye]
str(ch)    // string like approach -> result [hello]

Advantage of this is that it leave open most of the future possibilities,
disadvantage is that it requires more writting. However, this conversion
can be hidden inside the library function, if its intention is unambigous.

Having this facility at hand we can decide what will be default for the plain range.
I'm in favor of the current approach since it is used more frequently IMHO.

Regards,
Pavol