Hello Joaquín, today I faced some problem, when debugging the code. namespace mi = boost::multi_index; typedef mi::multi_index_container < vx_type , mi::indexed_by < mi::hashed_unique<mi::tag<vx_hash>, hash_extractor, dummy_hasher> , mi::ordered_non_unique<mi::tag<vx_kind>, kind_extractor > > > some_t; When created a view for vx_hash tag and going to change the invalid iterator like view.end(). Dereferencing view.end() fails as awaited, but this code which calls my TypeModifier: view.modify(view.end(), my_modifier); This will result in my_modifier call with dereferenced iterator, which contains badly initialized object. My environment VC++ 2005 Express, boost 1.34.1 With Kind Regards, Ovanes
----- Mensaje original ----- De: Ovanes Markarian <om_boost@keywallet.com> Fecha: Martes, Noviembre 20, 2007 4:57 pm Asunto: [Boost-users] [multi-index] dereferencing the end iterator Para: boost-users@lists.boost.org
Hello Joaquín,
today I faced some problem, when debugging the code. [...] When created a view for vx_hash tag and going to change the invalid iteratorlike view.end(). Dereferencing view.end() fails as awaited, but this code which calls my TypeModifier:
view.modify(view.end(), my_modifier);
This will result in my_modifier call with dereferenced iterator, which contains badly initialized object. [...]
Calling modify(end(),...) is illegal just as dereferencing end() is, but that does not mean that you can expect a crash when doing so: as you're invoking undefined behavior anything can happen. If you want to make sure that these illegal operations are properly detected and reported in a predictable way, take a look at Boost.MultiIndex safe mode: http://boost.org/libs/multi_index/doc/tutorial/debug.html#safe_mode (Don't forget to turn it off in release mode). Hope this helps, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquin, but you could use an assert in the debug version? That would be of great help. I did not call modify(view.end(), ...). But my iterator was invalid, which I wrongly initialized before. The call is just a further test to find out why I got the wrong object instance in the modifier. In this case to produce an assertion failure is probably of great help to the developer. Many thanks, Ovanes On 11/20/07, "JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> wrote:
----- Mensaje original ----- De: Ovanes Markarian <om_boost@keywallet.com> Fecha: Martes, Noviembre 20, 2007 4:57 pm Asunto: [Boost-users] [multi-index] dereferencing the end iterator Para: boost-users@lists.boost.org
Hello Joaquín,
today I faced some problem, when debugging the code. [...] When created a view for vx_hash tag and going to change the invalid iteratorlike view.end(). Dereferencing view.end() fails as awaited, but this code which calls my TypeModifier:
view.modify(view.end(), my_modifier);
This will result in my_modifier call with dereferenced iterator, which contains badly initialized object. [...]
Calling modify(end(),...) is illegal just as dereferencing end() is, but that does not mean that you can expect a crash when doing so: as you're invoking undefined behavior anything can happen.
If you want to make sure that these illegal operations are properly detected and reported in a predictable way, take a look at Boost.MultiIndex safe mode:
http://boost.org/libs/multi_index/doc/tutorial/debug.html#safe_mode
(Don't forget to turn it off in release mode). Hope this helps,
----- Mensaje original ----- De: Ovanes Markarian <om_boost@keywallet.com> Fecha: Martes, Noviembre 20, 2007 7:43 pm Asunto: Re: [Boost-users] [multi-index] dereferencing the end iterator Para: boost-users@lists.boost.org
Joaquin,
but you could use an assert in the debug version? That would be of great help.
I did not call modify(view.end(), ...). But my iterator was invalid, which I wrongly initialized before. The call is just a further test to find out why I got the wrong object instance in the modifier.
In this case to produce an assertion failure is probably of great help to the developer.
It is not possible AFAICS to determine whether an iterator is invalid without providing the iterator type with some additional bookkeeping info, which is precisely what the safe mode does. Without this extra info I don't have anything to assert about... I think the docs should stress more the advantages of setting the safe mode on. If you haven't done it yet I encourage you to do it. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Ok, now it's clear. But is it so difficult to do the way some other Boost Libs do or STL implementations. If _DEBUG is defined the safe mode with assertions is turned on... Or are there some other disadvantages (like extremely slow compilation speed)? With Kind Regards, On 11/20/07, "JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> wrote:
----- Mensaje original ----- De: Ovanes Markarian <om_boost@keywallet.com> Fecha: Martes, Noviembre 20, 2007 7:43 pm Asunto: Re: [Boost-users] [multi-index] dereferencing the end iterator Para: boost-users@lists.boost.org
Joaquin,
but you could use an assert in the debug version? That would be of great help.
I did not call modify(view.end(), ...). But my iterator was invalid, which I wrongly initialized before. The call is just a further test to find out why I got the wrong object instance in the modifier.
In this case to produce an assertion failure is probably of great help to the developer.
It is not possible AFAICS to determine whether an iterator is invalid without providing the iterator type with some additional bookkeeping info, which is precisely what the safe mode does. Without this extra info I don't have anything to assert about...
I think the docs should stress more the advantages of setting the safe mode on. If you haven't done it yet I encourage you to do it.
Best,
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
----- Mensaje original ----- De: Ovanes Markarian <om_boost@keywallet.com> Fecha: Martes, Noviembre 20, 2007 8:56 pm Asunto: Re: [Boost-users] [multi-index] dereferencing the end iterator Para: boost-users@lists.boost.org
Ok, now it's clear. But is it so difficult to do the way some other Boost Libs do or STL implementations. If _DEBUG is defined the safe mode with assertions is turned on...
<pedantic>The standard way is checking for !defined(NDEBUG)</pedantic>
Or are there some other disadvantages (like extremely slow compilation speed)?
There is a noticeable runtime penalty: operations that are constant time become linear with the number of iterators pointing to a given element etc. I took the decision not to include this overhead by default --seeing now how little safe mode seems to be used, meybe I made the wrong choice. But I'm very conservative with regard to changes in the lib, such as making safe mode the default in debug mode. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (2)
-
"JOAQUIN LOPEZ MU?Z" -
Ovanes Markarian