On Tue, Nov 25, 2014 at 5:40 PM, Filip Konvička <filip.konvicka@logis.cz> wrote:

Is this related to the issue I reported here?
https://svn.boost.org/trac/boost/ticket/10789

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