Information in map lost after function return

[rcijvat]

Hi all,

I have something going on that I don't quite understand. I have the following code:

void CPlexAdaptor::addVar(Var *v) {
	pair<map<Var *, IloNumVar>::iterator, bool> p = 
		this->varMapping.insert(pair<Var *, IloNumVar>(v, IloNumVar(this->env, v->lb, v->ub, this->convertVarType(v->type))));
	if(!p.second) {
		//p.second false, so this var already existed...
		cout << "> Var added twice in CPlexAdaptor.addVar: " << v->toString() << "\n"; 
	}
}

In this method, an instance of IloNumVar gets instantiated and immediately inserted into a map that also is a member of the class. However, after the function finishes, the entry in the map "forgets" the just instantiated IloNumVar, since it displays uninstantiated values... Does anybody have an idea on what might be causing this behaviour?

Thanks in advance!

[clanmjc]

Sounds like copy constructor for IloNumVar is the culprit (My first guess based on your description).

Help me understand.

However, after the function finishes, the entry in the map "forgets"

Does this mean that while in the function this->varMapping actually does contain a copy of the newly created temporary IloNumVar in the map? Can you confirm that after insertion, if second is true, that the element that was inserted contains the expected values.

[rcijvat]

Hi clanmjc,

Yes it does. In my case second is always true and before the function finishes, the inserted IloNumVar contains the expected values.

[clanmjc]

since it displays uninstantiated values

What do you mean? Are you checking the object itself? Is it being "Printed" by some other member/function? How does this "display" occur, paste relevant code?

[rcijvat]

Visual studio debug mode.. From experience I know that it is not always right, but it actually makes sense this time, since some functions that use the IloNumVar objects throw exceptions...

[clanmjc]

It almost sounds as if you are looking at container A during insertion, then looking at container B. The way you describe it at least. If this is serially executed, and you insert into your container, then after insertion verify that it was actually inserted. Then, function returns and you immediately look at your object container (the same object, the same container) and the contents of said container is not the same as what you just confirmed it as, then, maybe you are leaving out some details that can help with this.

How did you discover this?
Is the debugger wrong, have you tried using the object?
Have you verified you are looking at the same object, look at the address's?

Have you implemented the copy constructor at all, completely and without causing dangling/mangled references. Is there allocated memory in IloNumVar? Is it possible that it appears to be copied correctly, but then when the temporary object goes out of scope and the destructor is called it does some cleanup that inadvertently creates the scenario you have described?

[rcijvat]

Hi all, thanks a lot for the help, but I have found the problem :) The Var pointer that the addVar method receives is a pointer to an element of a vector. Now the problem is that, when I expand this vector, the pointer invalidates whenever the vector expands itself... so there it is.

I would still like to work with pointers to these elements. Is anyone else aware of a good approach to do this? Working with a list-like datastructure isn't good for my application, since I perform a lot of entry accesses.

I have used a deque now, as it comes closest to vector as possible. There is probably a constant overhead for using the methods that a vector also has, but i'll take this for granted.

[clanmjc]

The Var pointer that the addVar method receives is a pointer to an element of a vector.

Instead of having a pointer to an element of a vector, why not have the vector hold pointers to an object. Then you can pass around Var pointers, that point to the same object that was pointed to by the vector element, and when the vector expands pointers to the object itself are not invalided, even though the vector pointers may very well be. (well iterators to these vector pointers).