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

From: Pavol Droba (droba_at_[hidden])
Date: 2005-05-11 07:11:50

On Wed, May 11, 2005 at 02:27:43PM +0300, Peter Dimov wrote:
> Pavol Droba wrote:
> 
> >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).
> 
> I'd name it strlen, actually. And I wouldn't fall back to end(); a string 
> type should be marked as such by providing an appropriate overload for 
> strlen (and strbegin/strend).

I think that this is not a reasonable way of thinking. It is not up to 
library developer to restrict a user in this way.
For instance it is quite frequent to use vector<char> as a storage
for textual data. Why would you like to restrict a usage of string-oriented
algorithms for this particular container.

> 
> >So far it seems easy. But there is a catch as usualy. There are
> >generic facilities like FOREACH, that iterate over an arbitrary range.
> 
> It would be perfectly reasonable for a language-level foreach to omit the 
> trailing zero when iterating over a character literal. But I don't think 
> that this case is possible to detect. I wouldn't be surprised if it is, 
> though, given the current wizardry in BOOST_FOREACH (somehow exploiting the 
> fact that literals are const but convertible to char*.)
> 
> But this is a special case. In general, when you see char[4] (or 
> wchar_t[4]), you have absolutely no license to replace the 4 with undefined 
> behavior.

It is not a special case at all. Exactly the same goes for StringAlgo library
and I'm sure that for almost everything, that relies on Boost.Range.

As I see it the problem has not been spotted because until now, the only
real test case for Boost.Range in Boost was StringAlgo library (correct me
if I'm wrong). And the current behaviour is perfectly reasonable in its context.

I'm pretty sure, that another requirement on container classes, that are supposed
to be used via Range interface is inacceptable. 

What exactly you don't like on my second proposal? It allows user to decide
what he/she intends to do.

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.

Regards,
Pavol