Re: [boost] [Range] Confusing result of iterator_range::size()

Subject: Re: [boost] [Range] Confusing result of iterator_range::size()
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2011-11-03 04:54:43

Den 03-11-2011 09:12, Sergey Voropaev skrev:
> Jeffrey Lee Hellrung, Jr.<jeffrey.hellrung<at>  gmail.com>  writes:
>
>>
>> This came up just recently, e.g.,
>>
>> http://comments.gmane.org/gmane.comp.lib.boost.devel/224758
> Sorry, I miss it. Good discussion. And now we have my example with compilation
> error.
>>
>> I think the end result was an agreement that
>>
>> typedef typename boost::make_unsigned<  difference_type>::type size_type
>>
>> would be a valid definition of size_type, so the only argument against
>> making the change that I can see is breaking existing code (probably
>> unlikely...?) and...inertia.

Well, its /not/ unlikely that it will break code.

> I did not find authors of "Range" in the discussion. I am afraid your fix will
> be missed. It is good idea to write formal bug. Can you do it?

I think the most obvious reason we (probabl me) did it like that is that
iterator traits have no notion of unsigned types.

The above make_signed<> thing could work, but still it will break code.

The min() example that fails to compile is tricky. Even if we make it 
unsigned, size_types may differ (e.g. a 32 bit unsigned int and a 64 bit 
size_t).

One could change min/max to use mpl::identity<T>::type to avoid a second 
conflicting type deduction, but then you get a warning inside
min/max instead. In the end this means that you might as well make the 
conversion up-front, in your call to min/max.

-Thorsten