Hi Joaquim, I saw what you meant, and I have changed... But still if I use the same graph_h, still I got the same problem: Here it is my solution for the Graph constructor: Graph(const Graph &g) : _rangeBegin(g._rangeBegin), _rangeEnd(g._rangeEnd), _nodeRep(g._nodeRep), _nodeNameRep(g._nodeNameRep), _localPropRep(g._localPropRep), _globalPropRep(g._globalPropRep){ //_nodeRep::_uniqueName* Initialization pair rangeNodeIt; nodeMapIt tmpNodeIt; rangeNodeIt.first = g._nodeRep.begin(); rangeNodeIt.second = g._nodeRep.end(); while (rangeNodeIt.first != rangeNodeIt.second){ _nodeRep.insert(nodeMap( &*(_nodeNameRep.find(rangeNodeIt.first->_uniqueName->_name)), rangeNodeIt.first->_timestamp, rangeNodeIt.first->_node)); ++rangeNodeIt.first; } } I've debugged, but I didn't see anything suspicious anymore... Did you see something else? thanks, Rodrigo -------- Original-Nachricht --------

Datum: Wed, 11 Feb 2009 18:26:33 +0100 Von: joaquin@tid.es An: Rodrigo Dias Ferreira Betreff: Re: [multi_index] Problem of scope with the replace in static data structure

Rodrigo Dias Ferreira escribió:

...

Hi Joaquim,

...

Can you please test the following? In your //Test of the commit section, rather than reuse graph_h please use a different variable to do the after-commitChanges check:

[...]

Does this make any difference?

Yes, it worked, if I instantiate another object (like graph_h2). After that I have done some more Debug to try to find the reason, but I still don't understand, because inside the constructor it finds the Nodes, when I use the same object (graph_h)... Inside the overloaded operator-> does not work anymore, even I am using the _localGraph in both stretch of codes. So if it was the assignment of the _localGraph, it should not work with the constructor also, isn't true?

What happens when you do *not* use graph_h2 is that, upon reassigning graph_h in

graph_h = Graph_h(it);

the previous value of graph_h is destroyed, and presumably this leaves some dangling pointer/iterator when it shouldn't.

I've examined your code in search for candidates to potential dangling pointers/iterators and found something a little suspicious: Graph contains the following two member variables:

uniqueNameTable _nodeNameRep; nodeIndex _nodeRep;

where uniqueNameTable is a container of uniqueNodeNameStruct's and nodeIndex is a container of nodeMaps pointing to uniqueNodeNameStruct's in _nodeRep, right? If so, default copy semantics of Graph is flawed; consider:

Graph g2; { Graph g1; // g1._nodeRep elements point into g1._nodeNameRep g2=g1; // g2._nodeRep elements point into g1._nodeNameRep } // g1 is destroyed // g2._nodeRep elements point to destroyed objects

See what I mean? Pointers inside _nodeRep are not reassigned on copy. Does the copy constructor of Graph take this issue into account?

If this leads nowhere, you can always try setting up Boost.MultiIndex safe mode:

http://boost.org/libs/multi_index/doc/tutorial/debug.html#safe_mode

and see if some safe mode assertion is triggered.

Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

-- ************************************************* Rodrigo Dias Ferreira Master Student of Computational Engineering Technische Universität Dresden - Germany E-mail: rodrigodias@gmx.de ************************************************* Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a