Boost logo

Boost Users :

Subject: Re: [Boost-users] [multi_index] iterating over keys and "extracting" key extractors
From: Nick Stokes (randomaccessiterator_at_[hidden])
Date: 2015-03-19 14:45:38


Sorry for being vague about versions. This was with Boost 1.49. Both
Visual Studio 2012 and 2013 generates the warning. Clang 3.5.0 and g++
4.7.2 do not. They all compile fine at the end.

Also I just tried with Boost 1.56. There is no warning in either
compiler! Strangely, the result_type typedef in key extractor is still
non-& in this version. Perhaps Boost.Range changed...

Any explanation of what may have changed and why not having a & in
result_type works would be greatly appreciated.

Thanks many,

On Thu, Mar 19, 2015 at 2:20 PM, Nick Stokes <randomaccessiterator_at_[hidden]
> wrote:

> ... forgot to add, if I use a custom functor which does include the & in
> result_type, like:
>
> struct FooName { typedef const string& result_type; result_type
> operator()(const Foo& f) const { return f.name;} };
>
> in the same ranged for as above:
>
> for( string& s : foos.get<1>() | boost::adaptors::transformed( FooName() )
> ) ..
>
> then there is no warning from the compiler.
>
>
> On Thu, Mar 19, 2015 at 2:17 PM, Nick Stokes <
> randomaccessiterator_at_[hidden]> wrote:
>
>> There is a problem... I noticed, when used as follows with boost::range,
>>
>>
>> for( string& s : foos.get<1>() | boost::adaptors::transformed(
>> m.get<1>().key_extractor() ) )
>> ...
>>
>> Visual Studio 2012 generates an ugly warning " warning C4172: returning
>> address of local variable or temporary", and compiles. It also compiles on
>> clang and gcc (sorry for not being too specific with versions, modern
>> ones). But this is suspicious enough so I poked around a little bit.
>> Sure enough, the key_from_value (the return type of key_extractor()) is a
>> functor which is like
>>
>> template< .. class Value .. >
>> struct key_from_value {
>> typedef Value result_type; // not Value&
>>
>> Value& operator()( Foo&.. ) const { .. }
>>
>> };
>>
>> So isn't result_type being a non-reference type a problem here, given
>> operator() is returning &?
>>
>> Regards,
>> Nick
>>
>> On Thu, Mar 19, 2015 at 9:09 AM, Nick Stokes <
>> randomaccessiterator_at_[hidden]> wrote:
>>
>>> Thanks Joaquín
>>>
>>> On Wed, Mar 18, 2015 at 3:45 PM, Joaquin M Lopez Munoz <joaquin_at_[hidden]>
>>> wrote:
>>>
>>>> Nick Stokes <randomaccessiterator <at> gmail.com> writes:
>>>>
>>>> >
>>>> > Q1: Is there a builtin in way in MI to iterate over keys rather
>>>> > than elements? I.e. the iterator's value type will be that of the
>>>> > key, not the element.
>>>>
>>>> No, there's none. Some iterator adaption is needed as you mention
>>>> below.
>>>>
>>>> > Q2: Is there a way to obtain the type of key extractors given a
>>>> > multi index container? (it is related to Q1, as this sort of a
>>>> > thing could be passed to boost::transform iterator to obtain an
>>>> > alternative answer for Q1)
>>>>
>>>> auto beg=boost::make_transform_iterator(
>>>> foos.get<1>().begin(),foos.get<1>().key_extractor()),
>>>> end=boost::make_transform_iterator(
>>>> foos.get<1>().end(),foos.get<1>().key_extractor());
>>>>
>>>> std::copy(
>>>> beg,end,std::ostream_iterator<std::string>(std::cout," "));
>>>>
>>>> Joaquín M López Muñoz
>>>> Telefónica
>>>> _______________________________________________
>>>> Boost-users mailing list
>>>> Boost-users_at_[hidden]
>>>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>>>
>>>
>>>
>>
>



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net