[ptr_map] Warning about returning address of local variable
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
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/ad... -Thorsten
participants (1)
-
Bill Buklis -
Thorsten Ottosen