Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk