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.,
> Sorry, I miss it. Good discussion. And now we have my example with compilation
>> 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 acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk