Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2008-11-23 10:01:02

Tomas Puverle wrote:

> By the same logic, we should never be able to build any compound types which
> have any members which could potentially be in some invalid state.

Obviously, any compound type with a member in an invalid state is in an 
invalid state too.

> When I default construct a string class, it has some internal representation
> with a char pointer, which doesn't necessarily point to any valid memory.

The default-constructed state of a string class is a perfectly valid 
state, that's totally unrelated.
You can perform most operations on a an empty string.

> I really have not idea what you're referring to.  There is nothing about
> iterator_range in the C++ standard.  We can choose to define the semantics any
> way we choose.

iterator_range works with standard iterators.
So if the standard says the iterators cannot be used, the range cannot 
be used either. Hence the asserts.

>> In your specific case it's not a problem, but iterator_range aims at 
>> being generic.
> 
> Generic means that it's applicable to a wide variety of types.  Cutting out
> support for a subset of valid types for no good reason = less generic.

It's not cutting out specific ranges, it just requires you to explicitly 
initialize all ranges before using them, to ensure you're not doing 
something wrong.
It might prove verbose however, and that could be a valid reason not to 
do that checking altogether.

> This, what is happening now on this mail topic is very typical of this mailing
> list and this is what makes it so hard to try be involved.  By now, I could have
> written ten range implementations and fixed all of my code.  Instead, I'm
> spending time trying to get this (IMHO important) component somehow integrated
> back into boost. 

What I've been saying is purely my opinion and doesn't represent that of 
Boost or anything. It's not like I'm part of Boost anyway.

The one that will make the decision of changing Boost.Range to reflect 
your desires or not is most likely the maintainer of that library and my 
opinion on this matter matters little. I was just trying to say I 
personally thought those asserts had their use.

Getting rid of asserts is a perfectly valid choice, but reverting to the 
old behaviour certainly isn't IMHO.