Subject: Re: [boost] [Range] Confusing result of iterator_range::size()
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-11-03 05:13:19
On Thu, Nov 3, 2011 at 1:54 AM, Thorsten Ottosen <
> 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
>>> 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.
Well, okay, sure, *some* code is going to break. Do you have actual code
(i.e., not contrived examples) that you predict would fail?
Given that this has come up twice in the last month, I think it's worth
discussing the fallout from such a change. If one were to redesign
boost::iterator_range all over again, is there an argument *against* making
size() return an unsigned type?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk