Re: [Boost-users] [multi_index] Problem of scope with the replace in static data structure

12 Feb 2009

      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