STL iterator issue in signals::detail::named_slot_map_iterator on MS VisualStudio?
Hi, I'm trying to compile a code sample using boost signals on Windows using Visual Studio 2008, that works fine on Linux using gcc. My application crashes at the first time a signal's operator() method is called, and it seems that the issue is with some STL-related iterator magic. The application breaks in named_slot_map.hpp, in the call to boost::signals::detail::named_slot_map_iterator::init_next_group(), basically in operator== of class _Tree_nod, in file xtree - probably an MS STL implementation. basically it breaks here: #if _HAS_ITERATOR_DEBUGGING if (this->_Mycont == 0 || this->_Mycont != _Right._Mycont) { _DEBUG_ERROR("map/set iterators incompatible"); _SCL_SECURE_INVALID_ARGUMENT; } #else I tried to search on the issue, and found this thread: https://lists.secondlife.com/pipermail/sldev/2008-July/010867.html this even specifying _SECURE_SCL=0 doesn't help. I'm using boost 1.35.0, linking againts libboost_signals_vc90-mt-1_35. at the time of the call, actually there are no listeners bound to the signal. Is this an issue with boost::signals? or with MS VS? Akos
This is most commonly generated by comparing iterators from different containers. That's what the "incompatible" means. Also, a default constructed iterator is considered to be from a different container to any initialized iterator. E.g., comparing an iterator from begin() and a default constructed iterator will generate this exception. I would check the origin of the iterators on which you are callling operator ==. At 11:22 AM 8/18/2008, you wrote:
Hi,
I'm trying to compile a code sample using boost signals on Windows using Visual Studio 2008, that works fine on Linux using gcc. My application crashes at the first time a signal's operator() method is called, and it seems that the issue is with some STL-related iterator magic.
The application breaks in named_slot_map.hpp, in the call to boost::signals::detail::named_slot_map_iterator::init_next_group(), basically in operator== of class _Tree_nod, in file xtree - probably an MS STL implementation. basically it breaks here:
#if _HAS_ITERATOR_DEBUGGING if (this->_Mycont == 0 || this->_Mycont != _Right._Mycont) { _DEBUG_ERROR("map/set iterators incompatible"); _SCL_SECURE_INVALID_ARGUMENT; } #else
I tried to search on the issue, and found this thread: https://lists.secondlife.com/pipermail/sldev/2008-July/010867.html this even specifying _SECURE_SCL=0 doesn't help.
I'm using boost 1.35.0, linking againts libboost_signals_vc90-mt-1_35. at the time of the call, actually there are no listeners bound to the signal.
Is this an issue with boost::signals? or with MS VS?
Akos _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Alan M. Carroll wrote:
This is most commonly generated by comparing iterators from different containers. That's what the "incompatible" means. Also, a default constructed iterator is considered to be from a different container to any initialized iterator. E.g., comparing an iterator from begin() and a default constructed iterator will generate this exception. I would check the origin of the iterators on which you are callling operator ==.
Well, I see - but how? it's not that I'm creating these iterators, these seem to be boost::signals internal details - as the namespace says as well, boost::signals::detail::named_slot_map_iterator... Akos
participants (2)
-
Alan M. Carroll -
Ákos Maróy