problem comparing shared_ptr pointers
Why is the shared counter used to compare shared_ptr objects, and not the container pointer? Until revision 1.24, the container pointer was used to compare shared_ptr objects, see http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/shared_ptr.hpp?r1=1.23&r2=1.24 . This introduced a change in shared_ptr behaviour and introduced a case where (p1 < p2 && p1 == p2) is true where p1 and p2 are two shared pointers, see the included example. Was this change in behaviour intentional, and is this behaviour documented anywhere? Example: struct A {}; struct deleter1 { template<class T> void operator()(T*) const {} }; struct deleter2 { template<class T> void operator()(T*) const {} }; int main() { A* a = new A(); boost::shared_ptr<A> p1(a, deleter1()); boost::shared_ptr<A> p2(a, deleter2()); std::cout << "p1 < p2 = " << (p1 < p2) << std::endl ; std::cout << "p1 == p2 = " << (p1 == p2) << std::endl ; } Output: p1 < p2 = 1 p1 == p2 = 1 -- Valentin Samko - http://val.samko.info
Valentin Samko wrote:
Why is the shared counter used to compare shared_ptr objects, and not the container pointer?
Please see http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1590.html
Hello Peter, Sunday, October 2, 2005, 6:24:32 PM, you wrote: PD> Valentin Samko wrote:
Why is the shared counter used to compare shared_ptr objects, and not the container pointer?
PD> Please see PD> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1590.html Thanks. Was the option of checking first if the contained pointer is equivalent considered? i.e. px != rhs.px && pn < rhs.pn -- Valentin Samko - http://val.samko.info
Apologies if this has been discussed before. Looking at config/auto_link.hpp no version information is included for the Intel compiler. May I ask the rationale for it? The reason is that I've just compiled boost with intel 9 and both lib and dll filenames include the version number. Unfortunately I can't make use of the auto link feature since BOOST_LIB_TOOLSET for intel does not include the version number. Why not ifdef in terms of __INTEL_COMPILER as in the VC case? Cheers, Goncalo __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
The reason is that I've just compiled boost with intel 9 and both lib and dll filenames include the version number. Unfortunately I can't make use of the auto link feature since BOOST_LIB_TOOLSET for intel does not include the version number.
Why not ifdef in terms of __INTEL_COMPILER as in the VC case?
Historically we've only had one intel toolset, so whatever compiler version you used you would end up with the same lib names. You can now control the name of the toolset part of the lib name, by defining BOOST_LIB_TOOLSET, for example if you add: #define BOOST_LIB_TOOLSET "intel-9_0" to boost/config/user.hpp then the autolinking code will try to use that name rather than the default "iw". Hopefully if you then compile your libs with the (undocumented) "intel-9_0" toolset the names should then match up. Does this help? John.
Hopefully if you then compile your libs with the (undocumented) "intel-9_0" toolset the names should then match up.
Does this help?
Yes. Thank you. Goncalo __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
participants (4)
-
Goncalo N M de Carvalho -
John Maddock -
Peter Dimov -
Valentin Samko