Boost C++ Libraries: Ticket #10514: Cannot copy const sub_range to non-const

attachment set

Thu, 18 Sep 2014 04:26:12 GMT

attachment → sub_range_test.cpp

Test case

status changed; resolution set

Neil Groves — Mon, 02 Feb 2015 01:18:55 GMT

status new → closed
resolution → invalid

The propagation of const-ness is the rationale for having sub_range in addition to iterator_range. Please see: http://www.boost.org/doc/libs/1_57_0/libs/range/doc/html/range/reference/utilities/sub_range.html

If you do not wish to propagate const-ness please use iterator_range instead.

status changed; resolution deleted

Mon, 02 Feb 2015 02:27:40 GMT

status closed → reopened
resolution invalid

Replying to neilgroves:

The propagation of const-ness is the rationale for having sub_range in addition to iterator_range. Please see: http://www.boost.org/doc/libs/1_57_0/libs/range/doc/html/range/reference/utilities/sub_range.html

If you do not wish to propagate const-ness please use iterator_range instead.

It appears to me that const is being propagating incorrectly in this case. At the very least, const is being propagated in a way that is inconsistent with how it is normally propagated with the standard containers. Consider the analogous example using just std::vector:

std::vector<int> v(10);
const std::vector<int> & v_ref = v;
std::vector<int> u = v_ref;

This compiles just fine because there is no problem copying a const int to an int. To the point: it doesn't matter that v_ref uses const_iterators.

(So, I may have framed the problem incorrectly in my initial description. The problem isn't that const_iterators are being used at all; the problem is that sub_range seems to insist that the lhs use const_iterators just because the rhs does.)

status changed

Neil Groves — Mon, 02 Feb 2015 09:05:54 GMT

status reopened → new

I didn't comprehend initially that the snippet of code posted compiled with 1.55. I apologise for not understanding this despite you correctly putting the severity as regression.

Upon closer inspection this does appear like it ought to compile but not for the reasons you described. It is indeed intended for a const sub_range to return const_iterator. The strange issue is that const_iterator is not converting to iterator. This might be related to a problem in Boost 1.57 where Boost.Range had some specialisations of Boost.Iterator and Boost.Iterator had the namespace changed for the class specialised within Boost.Range. If it is related to this, then the "develop" and "master" branch of Boost.Range already contain a fix.

I have to do my day job for a bit, but I'll get back to looking at this as soon as I can. I don't have any Microsoft C++ compilers other than the free ones anymore. Hopefully this will show up on Clang or GCC when I try them.

Depending on the urgency of this defect, you may wish to pull the branches to see if they solve the problem. I'm aiming to look at this again later tonight.

Neil Groves — Mon, 02 Feb 2015 20:28:45 GMT

Okay, I added a unit test for the scenario provided to the develop branch and it compiles cleanly. I believe that the problem has already been fixed. I think it is related to the missed template specialisation due to a mismatch between my specialisation and the changed namespace in Boost.Iterator.

I will not close the defect just yet. I'll watch this test cycle, and look closely at the MSVC regression tests. Hopefully these will pass, and I can just do a simple merge for release 1.58 to add this test case to ensure this doesn't happen again.

Sorry for the hassle.