Re: [Boost-users] [range] functor defined result_type with no &, causing temporary variable warnings on VS

Subject: Re: [Boost-users] [range] functor defined result_type with no &, causing temporary variable warnings on VS
From: Nick Stokes (randomaccessiterator_at_[hidden])
Date: 2015-03-23 10:39:30

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_at_[hidden]>
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