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>> writes:
>> This came up just recently, e.g.,
> 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

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at