Boost

Download

boost@lists.preview.boost.org

February 2014

129 participants
132 discussions

[range] Can iterator_range also model Random Access Range?
by Mostafa 01 Feb '14

01 Feb '14

It seems that iterator_range can properly model any refinement of the Forward Range concept. Is that right? The reason I ask is that this is not very clear from the documentation, and I had to deduce this from both the iterator_range API and the Random Access Range concept definition. (See documentation at: range/reference/utilities/iterator_range.html) Thanks, Mostafa

3 6

Range Adapters (map_keys, map_values) cause undefined behavior (segv, etc) when applied to R-Values, especially in the context of BOOST_FOREACH
by Igor Lubashev 01 Feb '14

01 Feb '14

Hi! I've filed a ticket (https://svn.boost.org/trac/boost/ticket/9578) for this issue two weeks ago, but I see no action there. Does anyone else think that this (see subj) is a problem? To spare the trouble of following the link, here is the essence of the problem, as I see it. (The ticket has a simple test case attached.) When applied to r-values (for example, maps returned by value from a function), adapters do not make a copy of the r-value but just capture a reference to it. This makes the returned range_iterator dangerous, if it is used after the r-value (the temporary) is destroyed. In particular, the following use causes undefined behavior on all compilers I'd tested on: g++ (4.1.2, 4.4.3, 4.6.3) and Visual Studio (15 [VC9], 16 [VC10]). BOOST_FOREACH(const string &s, return_map_by_value() | map_keys) ... Note that the following works fine (since BOOST_FOREACH takes care of differentiating between l-values and r-values and does the right thing to r-values): BOOST_FOREACH(const MapType::value_type &v, return_map_by_value()) ... It seems that boost::range::adapters need to do a similar thing to what BOOST_FOREACH is does to identify r-values and make a copy (which the compiler is likely to optimize away). Any comments are welcome! Thanks, - Igor

3 3

Jump to page: