stl::vector - Page 4

Un peu des deux en fait, mais oui la plus grosse part des emmerdes vient de l'implémentation J2EE.

void Solver::addForbiddenVertex(int v1){
	cout << "iciiiiii:v1=" << v1 << endl;
	forbiddenVertex.push_back(v1-1);
	cout << "ici2" << endl;
	
}

plante :-/

on obtient:

iciiiiii:v1=5
Erreur de segmentation

déclaration du vector est:

protected:
vector<int > forbiddenVertex;		// liste des noeuds interdits pour devenir des sites

mais l'appelle de addForbiddenVertex se fait sur une classe qui en dérive:

solver = new RellinSolver(grp,genereZjlDebut,false);
solver->addForbiddenVertex(v1);

RellinSolver dérive de Solver.

Une idée?

Ton constructeur doit appeler le constructeur de la classe parent à travers un initialisateur de membre:
RellinSolver() : Solver() {...}

C'est le cas.

Hmmm, forbiddenVertex devraît être initialisé correctement alors... As-tu essayé d'obtenir un backtrace avec GDB?

Je vais voir. (si j'y arrive)

Ca plante à la ligne 604 de stl_vector.h

if (this->_M_impl._M_finish != this->_M_impl._M_end_of_storage)
dans

void
      push_back(const value_type& __x)
      {
        if (this->_M_impl._M_finish != this->_M_impl._M_end_of_storage)
          {
            this->_M_impl.construct(this->_M_impl._M_finish, __x);
            ++this->_M_impl._M_finish;
          }
        else
          _M_insert_aux(end(), __x);
      }

le backtrace est :
(gdb) bt
#0  0x080aa523 in std::vector<int, std::allocator<int> >::push_back (this=0x70, __x=@0xbfdae6f4) at /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_vector.h:604
#1  0x080a8b77 in Solver::addForbiddenVertex (this=0x0, v1=5) at Solver.cpp:40
#2  0x0809f2d3 in Engine::addForbiddenVertex (this=0x88430d0, v1=5) at Engine.cpp:28
#3  0x0809692b in openFiles () at main.cpp:132
#4  0x08097256 in main (argc=2, argv=0xbfdaec34) at main.cpp:233

this=0x70

On peut voir la déclaration de RellinSolver et Solver ? Ainsi que les constructeurs ?

C'est déjà le this=0x0 dans #1 le problème. Le this=0x70 est le résultat de 0x0 + offsetof(Solver,forbiddenVertex).

Bref, c'est Engine.cpp:28 qui passe un pointeur nul, le bogue n'est pas dans le morceau de code que tu nous as montré.

Oui, je l'ai vu aussi, mais pour une raison mystérieuse, je ne peux pas éditer mes posts (dans le même genre de trucs à la con, Mes Sujets s'ouvre dans la page courante - toujours pas compris pourquoi, mais doit sans doute y avoir une bonne raison).

RellinSolver::RellinSolver(GraphLoc* bGrp,bool bGenereZjlDebut,bool bTimPrime):
	 Solver(bGrp,bGenereZjlDebut,bTimPrime){
...
}

/*!
	addForbiddenVertex : force un noeud a ne pas etre un site dans la solution
*/
void Engine::addForbiddenVertex(int v1){
	solver->addForbiddenVertex(v1);		// on delegue ca a la classe qui va resoudre
}

class Engine{
public:
	Engine(GraphLoc* bGrp,SolveType bSolveType);
	~Engine();
	
	void solve();
	void genZjlDebut(){ genereZjlDebut = true; }
	
	void addMandatoryVertex(int v1);
	void addForbiddenVertex(int v1);
	
private:
	GraphLoc* grp;	// contient la topologie du reseau et les donnees du probleme
	Solver* solver;
	
	bool genereZjlDebut;	// force la generation des contraintes sur les z_jl de maniere non-dynamique
	bool doMonteCarlo;		// determine les x_ij fractionnaires en entier avec des tirage au sort
	bool verbose;
	SolveType solveType;
	double alpha_a;
	double alpha_t;
	
	
	void solveRellinSFA();
};

class RellinSolver : public Solver {
public:
	RellinSolver(GraphLoc* bGrp,bool bGenereZjlDebut,bool bTimPrime);
	~RellinSolver();
	void solve();

	vector<IloNumVarIndexe >& getxEdgeArr(){ return xEdgeArrNum;}
	vector<IloNumVarIndexe >& getxVertArr(){ return xVertArrNum;}

	vector<IloNumVar >& getd_j_a(){ return d_j_aNum;}
	vector<IloNumVar >& getd_j_b(){ return d_j_bNum;}
	vector<IloNumVar >& gete_j_a(){ return e_j_aNum;}
	vector<IloNumVar >& gete_j_b(){ return e_j_bNum;}
	
private:
	void generateConstraints();
	IloNumVarIndexe* getX_ij(int i,int j);
	
	/****	 variables de decision pour le relache lineaire ******************************/
		vector<IloNumVarIndexe > xEdgeArrNum;
		vector<IloNumVarIndexe > xVertArrNum;
		
		vector<IloNumVar > d_j_aNum;		// nombre de port type "acces" necessaires sur chaque site
		vector<IloNumVar > d_j_bNum;		// nombre de port type "backbone" necessaires sur chaque site
		vector<IloNumVar > e_j_aNum;		// nombre de cartes type "acces" necessaires sur chaque site
		vector<IloNumVar > e_j_bNum;		// nombre de cartes type "backbone" necessaires sur chaque site
	/**********************************************************************************/
};

class Solver {
public:
	Solver(GraphLoc* bGrp,bool bGenereZjlDebut,bool bTimPrime);
	virtual ~Solver();
	virtual void solve();
	
	IloEnv getenv(){return env;}
	IloCplex getcplex(){return cplex;}
	
	
	virtual vector<IloNumVarIndexe >& getxEdgeArr(){}
	virtual vector<IloNumVarIndexe >& getxVertArr(){}

	virtual vector<IloNumVar >& getd_j_a(){}
	virtual vector<IloNumVar >& getd_j_b(){}
	virtual vector<IloNumVar >& gete_j_a(){}
	virtual vector<IloNumVar >& gete_j_b(){}
	
	vector<vector<IloNumVarIndexe> >& getz_jl(){ return z_jl;}

	void addMandatoryVertex(int v1);
	void addForbiddenVertex(int v1);
	
	
private:

protected:

...


	/****	forcer les variables de decision : interdiction et obligation  **************/
	vector<int > mandatoryVertex;		// liste des noeuds qui _doivent_ etre des sites
	vector<int > forbiddenVertex;		// liste des noeuds interdits pour devenir des sites
	/**********************************************************************************/
	

	
};

solver->addForbiddenVertex(v1); => solver est NULL à cet endroit.

ok :s

merci

Un pointeur membre doit être alloué explicitement quelque part (dans le constructeur par exemple), il n'est pas construit automatiquement comme un objet membre.

et la mémoire doit être libérée explicitement. Je sais bien que c'est pas ton fort la gestion de la mem, donc si tu as besoin d'aide n'hésite pas.

oui non mais avouez que c'est trompeur.... c'est dans la fonction de l'objet soi-disant pas alloué que ca plante, quand on fait appel à un truc qui utilise une variable membre de cette classe... On peut difficilement faire plus piégeux.

C'est parce que la méthode n'est pas virtuelle. Si elle était virtuelle, ce serait tout de suite l'accès à la vtable qui causerait le segfault (c'est pour ça qu'en Java tu as la NullPointerException tout de suite à l'appel d'une méthode de null, toutes les méthodes non-statiques en Java sont virtuelles (sauf dans des cas avec final où tu ne remarques pas la différence)). Une méthode non-virtuelle est comme une fonction non-objet qui prend le pointeur this comme son premier (ou dernier, ça dépend de l'implémentation) argument.

Ouép, et tant que tu n'accèdes pas aux variables membre (ou héritées), la fonction va marcher impeccable, ce qui peut faire que ça va planter plus loin.
Tu peux te faciliter la vie en ajoutant un assert(this); au début de toute fonction membre d'une classe. Ca fera planter dès l'entrée de la fonction quand compilé en mode debug