On Tue, Nov 25, 2014 at 5:40 PM, Filip Konvička
Is this related to the issue I reported here?
Looking more into this issue, I found this bug report from 2 years ago that describes what I think is the underlying problem: https://svn.boost.org/trac/boost/ticket/7630
Given that the issue (bug?) involves a use case as simple as the one described by OP, many people might be bothered by it. Not everyone will know to ask on this list. Worse still, some might invest time in uselessly reporting the same issue all over again. For these reasons, I strongly agree with OP in suggesting that a *big warning sign* should be included in the Boost Range 2.0 documentation about this issue:
"Thou shalt not use boost range adaptors on rvalue containers in C++11 range-based for loops."
If the note is already there, then it is not prominent enough.
Regarding solutions or workarounds, the last post by neilgroves in the bug report is from 9 months ago, suggesting he has a solution. Are there any updates on that?
Thanks for the links. As Neil said earlier in this thread, there is currently no good solution; I guess we've got to live with that.
To be honest, I still think that the design of the range-based for loop is strange. This problem applies also to other use cases than those involving Boost.Range. I understand why the temporaries get destroyed, but is there a rationale for that from the language design perspective? Isn't it more intuitive to let the temporaries live until the loop finishes? Maybe this is a question that I should ask somewhere else.
By the way, does anyone have a link to Eric's proposal?
Thanks, Filip
I think [ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4128.html ] is the latest proposal. Lee