Boost.Ranges 2.0 algorithms accepting a const reference
Hi, the Boost.Ranges (v 1.43) documentation suggests that for each algorithm there is a version accepting a reference to a range and a version accepting a const reference to a range (which in my case would be useful for the "non-const reference to temporary object problem" when dealing for example with a boost::iterator_range<std::vector<double>::iterator> range). However the code (take for instance the reverse algorithm) does not seems to include the const reference version. Am I missing something, is the documentation incorrect, or it has been decided against the const reference version? Thank you in advance for your help. Stefano
Le 08/07/2010 22:30, Stefano Peluchetti a écrit :
Hi,
the Boost.Ranges (v 1.43) documentation suggests that for each algorithm there is a version accepting a reference to a range and a version accepting a const reference to a range (which in my case would be useful for the "non-const reference to temporary object problem" when dealing for example with a boost::iterator_range<std::vector<double>::iterator> range).
However the code (take for instance the reverse algorithm) does not seems to include the const reference version.
Am I missing something, is the documentation incorrect, or it has been decided against the const reference version?
reverse modifies its input, therefore it only takes a non-const range.
Mathias Gaunard <mathias.gaunard <at> ens-lyon.org> writes:
Le 08/07/2010 22:30, Stefano Peluchetti a écrit :
Hi,
the Boost.Ranges (v 1.43) documentation suggests that for each algorithm there is a version accepting a reference to a range and a version accepting a const reference to a range (which in my case would be useful for the "non-const reference to temporary object problem" when dealing for example with a boost::iterator_range<std::vector<double>::iterator> range).
However the code (take for instance the reverse algorithm) does not seems to include the const reference version.
Am I missing something, is the documentation incorrect, or it has been decided against the const reference version?
reverse modifies its input, therefore it only takes a non-const range.
Ok, but for instance find does not necessarly modify the input, and still there is only the version accepting the non-const reference. This is in contrast with the "Introduction" section of the documentation which stresss that both versions of find have to be implemented due to the forwarding problem. Moreover, iterator_range beheaves like stl iterators (and const_iterators, depending on the template argument used) and as such a const iterator_range<std::vector<double>::iterator> will behave like a mutable range (and the range_iterator class knows this). Please notice this is in contrast with the sub_range class (something I personally find a bit confusing :P).
This is in contrast with the "Introduction" section of the documentation which stresss that both versions of find have to be implemented due to the forwarding problem.
You are entirely correct. The reverse function is missing the const overload, and this will cause a problem when returning a temporary to a constant range that has mutable elements. A workaround, which I expect you have already thought of, would be to hold a const reference to the range in a variable and pass this into reverse. I shall put a correction into the trunk as soon as possible. I shall also review all of the algorithm functions for similar mistakes. I apologize for my oversight and for any inconvenience this has caused.
Moreover, iterator_range beheaves like stl iterators (and const_iterators, depending on the template argument used) and as such a const iterator_range<std::vector<double>::iterator> will behave like a mutable range (and the range_iterator class knows this).
Please notice this is in contrast with the sub_range class (something I personally find a bit confusing :P).
This is deliberately in contrast. The iterator_range class wraps an iterator to model a Range Concept. The sub_range wraps a Range, or Container while preserving const-ness of the underlying Range. Regards, Neil Groves
You are entirely correct. The reverse function is missing the const overload, and this will cause a problem when returning a temporary to a constant range that has mutable elements. A workaround, which I expect you have already thought of, would be to hold a const reference to the range in a variable and pass this into reverse.I shall put a correction into the trunk as soon as possible. I shall also review all of the algorithm functions for similar mistakes.I apologize for my oversight and for any inconvenience this has caused.
No need to apologize really, thank you for your work :) I was just wondering whether I missed some fancy boost preprocessor programming that would automatically add the const reference versions. And in my case no inconvenience caused because, among other things, it is the case that visual studio is usually happy to take references to temporaries...
This is deliberately in contrast. The iterator_range class wraps an iterator to model a Range Concept. The sub_range wraps a Range, or Container while preserving const-ness of the underlying Range.
Yes that makes sense, I just did not get this immediately by reading the documentation. It is easy to get confused because constness for containers and iterators mean different things, and in a sense here we are mixing them a bit. Thank you again for your kind reply. Regards
Regards,Neil Groves
_______________________________________________ Boost-users mailing list Boost-users <at> lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Sun, Jul 11, 2010 at 5:37 PM, Stefano <pelux@ngi.it> wrote:
You are entirely correct. The reverse function is missing the const overload, and this will cause a problem when returning a temporary to a constant range that has mutable elements. A workaround, which I expect you have already thought of, would be to hold a const reference to the range in a variable and pass this into reverse.I shall put a correction into the trunk as soon as possible. I shall also review all of the algorithm functions for similar mistakes.I apologize for my oversight and for any inconvenience this has caused.
The correction to the temporary lifetime issues is committed to the trunk
along with a lot of new test cases. This has introduced some regressions for compilers that can't seem to pick the appropriate const versus non-const overloads. I am working on removing the regression while preserving the capability of working with temporaries. I hope this helps. Regards, Neil Groves
Neil Groves <neil <at> grovescomputing.com> writes:
The correction to the temporary lifetime issues is committed to the trunk along with a lot of new test cases. This has introduced some regressions for compilers that can't seem to pick the appropriate const versus non-const overloads. I am working on removing the regression while preserving the capability of working with temporaries.I hope this helps.Regards,Neil Groves
Thank you again for your help!
On Wed, Jul 14, 2010 at 10:25 PM, Stefano <pelux@ngi.it> wrote:
Neil Groves <neil <at> grovescomputing.com> writes:
The correction to the temporary lifetime issues is committed to the trunk along with a lot of new test cases. This has introduced some regressions for compilers that can't seem to pick the appropriate const versus non-const overloads. I am working on removing the regression while preserving the capability of working with temporaries.I hope this helps.Regards,Neil Groves
Thank you again for your help!
You are very welcome. I believe that the problem is completely tacked on the trunk and that the regressions are now all fixed for all compilers. I am waiting for the regression tests to cycle on the trunk before requesting a merge to the trunk. This fix might therefore be allowed into the next release of Boost. Thank you for your defect report. Regards, Neil Groves
participants (4)
-
Mathias Gaunard -
Neil Groves -
Stefano -
Stefano Peluchetti