Boost logo

Boost Users :

Subject: Re: [Boost-users] Boost range changes [1.37.0]
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2008-11-20 04:26:45

Tomas Puverle skrev:
> Thorsten,
> Thanks for the reply. See comments inline.
>> The change has happened long ago. It was a design mistake to try to make
>> a range of singular iterators valid since it adds overhead also for
>> those that don't need it.
> When you say "overhead", are you speaking of size or speed?
> Was this overhead demonstrated by some particular use case?
> Does this mean you may be also removing the "singular" flag at some point?

Its only there in debug builds.

> Is there a supported way of constructing valid empty ranges? I can't see that
> there's a way to do it.
>> Your use-case is new to me, but seems quite ok. But making
>> boost::iterator_range as a mixture of a range and boost.optional seems
>> like a bad idea.
> I feel that by the same token, you could say that a default constructed
> std::vector<T> is a bad idea. I really like using Boost.Range but I think this
> new behaviour is a big shortcoming. I also never saw any mention of these
> breaking changes on boost.devel...
>> template<class Range>
>> void foo(boost::optional<const Range &> r_)
>> {
>> if (r && !r_->empty()) {...}
>> }
>> might be an idea?
> IMHO, this is obfuscated. There is a difference between an empty range and a
> range which is optional.

An there is a difference betweeen an empty range and a singular range.

You can always add the extra state...just derive from iterator-range an
implement it. If boost::iterator_range did it, there would be no way of
getting rid of the overhead.


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at