[ptr_map] Warning about returning address of local variable

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[ptr_map] Warning about returning address of local variable

Boost - Users mailing list
I'm not sure if this a potential bug/problem or just a benign warning,
but when using the map_values range adaptor with a ptr_map container I
get a warning about returning an address of a local variable. It seems
benign as the expected processing happens, but this type of warning
generally doesn't sound like a good thing.

The following useless code will trigger it.

#include <boost/ptr_container/ptr_map.hpp>
#include <boost/range/algorithm.hpp>
#include <boost/range/adaptors.hpp>

struct sample
{
     int        value;
};

typedef boost::ptr_map<int, sample> themap;

int main()
{
     themap        data;
     int            key = 5;

     data.insert(key, new sample);
     boost::for_each(data | boost::adaptors::map_values, [](sample* s)
     {
         s->value = 10;
     });

     return 0;
}

I'm using Visual Studio 2017. I also have conformance mode
(/permissive-) turned on for stricter language compliance in case it
makes a difference.

As an aside, I was a little surprised when trying out this little sample
that the inclusion of the above headers is enough to require linking
with the boost regex library. I figure it's probably a reference in the
adaptors somewhere. It's not a big deal. These lib files are normally
available anyway.


--
Bill


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [ptr_map] Warning about returning address of local variable

Boost - Users mailing list
Den 02-03-2018 kl. 23:09 skrev Bill Buklis via Boost-users:
> I'm not sure if this a potential bug/problem or just a benign warning,
> but when using the map_values range adaptor with a ptr_map container I
> get a warning about returning an address of a local variable. It seems
> benign as the expected processing happens, but this type of warning
> generally doesn't sound like a good thing.

It's slightly complicatated, but it is from the range library the
warning is generated. ptr_map<> defines its iterator reference as
something which is not a reference:

   ptr_container_detail::ref_pair<F,S>

where S is a pointer. The range lib is then parsing such a ref_pair<> by
value and returning a reference to the second member.

I think this is a bug, sort of, not in the range library, but in ptr_map
that creates a fake reference type that is not a real reference type.

The reason that ref_pair is used is to avoid exposing the value type as
pair<Key,void*>, so it's an artifact of the code-generation
optimization. Perhaps this is the final nail in the coffin for this
approach and we need to store T* instead of void*.

I'm curious if you can provoke a crash under heavy optimization? Or if
you're lucky that because your lambda takes a pointer by copy that you
escape problems.

> As an aside, I was a little surprised when trying out this little sample
> that the inclusion of the above headers is enough to require linking
> with the boost regex library. I figure it's probably a reference in the
> adaptors somewhere. It's not a big deal. These lib files are normally
> available anyway.


Yes, the tokenized adaptor is based on regexes:

https://www.boost.org/doc/libs/1_66_0/libs/range/doc/html/range/reference/adaptors/reference/tokenized.html

-Thorsten

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users