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).

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

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

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... 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

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!