This question is a followup from a multi_index discussion at http://lists.boost.org/boost-users/2015/03/84028.php. Joaquin explained the situation very accurately, so I am including his explanation following my summary below for context (I hope this does not constitute top posting :) In summary the problem is: struct Foo { int i; } struct GetIntMem { typedef int result_type; const int& operator()(const Foo& f) const { return f.i ; } }; aFooRange | boost::adaptors::transformed( GetIntMem() ); yields "warning C4172: returning address of local variable or temporary" in VS 2012 and 2013, with Boost 1.49. There is no warning with Boost 1.56. Is this construct safe with Boost 1.49? In the context of multi_index, the key extractor type is the "GetIntMem". Please see below for details. On Fri, Mar 20, 2015 at 5:33 AM, Joaquin M Lopez Munoz <joaquin@tid.es> wrote:

Please don't top-post:

http://www.boost.org/community/policy.html#quoting

Sure. Sorry. Thanks for the link, useful info.

So, to sum up the top-posted chain of posts of yours, boost::multi_index::member<Class,Type,PtrToMember> publicizes its result type as

typedef Type result_type;

yet its call operator overloads return Type& or const Ttype&, and this results in some warnings in VS 12 / Boost 1.49 when used in combination with boost::adaptors::transform.

So, whatever the problem is, it does not belong in Boost.MultiIndex, since member merely defines result_type in accordance with the requirements of the Key Extractor model:

http://www.boost.org/libs/multi_index/doc/reference/ key_extraction.html#key_extractors

I mean, defining result_type in whatever way (or not defining it at all) is not an error per se; it is Boost.Range assumptions on this typedef that might be problematic. Unfortunately, the documentation for boost::adaptors::tranform(rng,fun)

http://www.boost.org/libs/range/doc/html/range/reference/ adaptors/reference/transformed.html

do not mention what the requirements on fun are, whether it is mandatory that a result_type be present and how this is handled by Boost.Range. I suggest you initiate a new discussion with [range] in the subject line showing the problem you found. I suspect this is related to boost:result_of

http://www.boost.org/libs/utility/utility.htm#result_of

which Boost.Range seems to use internally, but only the author can tell. Also, if the problem does not show in Boost 1.56 you might be encouraged to simply upgrade and move on.

Thanks Joaquin. I could not describe the problem any better than what you have above, so I hope you don't mind that I re-purposed this thread. The question is possibly is rather moot at this point, as the issue does not manifest in Boost 1.56 (possibly earlier). However, it'd be interesting to understand why, and at least make sure using 1.49 this way is safe (I am stuck with that version for the time being). Thanks very much if you followed along this far, and sorry as I fear this post ended up more convoluted that it needs to be :P Nick