Discussion :

[totodu34]

Bonjour a tous,
je débute en c++ et je teste les conteneurs <vector>.
J'ai un soucis avec mon code, je n'ai pas de problème à la compilation mais lorsque je l'exécute j'ai : EXC_BAD_ACCESS et je ne comprend pas pourquoi...

voici mon code en espérant que vous pourrez m'aider. Par avance Merci.

main.cpp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#include <iostream>
#include "ClasseA.h"
 
int main (int argc, char * const argv[]) {
    B b;
	b.setB(10);
	b.setB(20);
	b.setB(25);
	std::cout << "b[0]" << b.GetB(0) << std::endl;
	B c;
	c.setB(1);
	c.setB(2);
	c.setB(3);
	A a(&b);
	a.setA(c);
	std::cout << "a[0]" << std::endl;
	for (unsigned i=0; i<a.GetA(0).tailleB(); i++) {
		std::cout << a.GetA(0).GetB(i) << std::endl;
	}
 
    return 0;
}

ClasseB.h

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
#include <vector>
 
class B{
public:
	B();
	B(const B &b);
	float GetB(unsigned i) const;
	void setB(float F);
	unsigned tailleB()const;
protected:
	std::vector<float> _vF;
};

ClasseB.cpp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include "ClasseB.h"
 
B::B():_vF(0){}
 
B::B(const B &b):_vF(b.tailleB()){
	for (unsigned i=0; i<b.tailleB(); i++) {
		_vF.push_back(b.GetB(i));
	}
}
 
float B::GetB(unsigned i)const{
	return _vF.at(i);
}
 
void B::setB(float F){
	_vF.push_back(F);
}
 
unsigned B::tailleB()const{
	return _vF.size();
}

ClasseA.h

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
#include "ClasseB.h"
 
class A{
public:
	A(B *b);
	B GetA(unsigned i);
	void setA(B b);
protected:
	std::vector<B> *_vB;
};

ClasseA.cpp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#include "ClasseA.h"
 
//A::A():_vB(0){}
 
A::A(B *b){
	std::vector<B> *tmp;
	tmp->push_back(*b);
	_vB=tmp;
	//_vB->push_back(*b);
}
B A::GetA(unsigned i){
	return _vB->at(i);
}
void A::setA(B b){
	_vB->push_back(b);
}

[Arzar]

Bonsoir !
Tu n'as pas de debuggeur ? C'est assez pratique pour trouver ce genre d'erreur. En passant le debuggeur sur ton code j'obtiens :

Run-Time Check Failure #3 - The variable 'tmp' is being used without being initialized.

à la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
A::A(B *b){
	std::vector<B> *tmp;
--->	tmp->push_back(*b);
	_vB=tmp;
	//_vB->push_back(*b);
}

suite à un appel de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

a.setA(c);

Je pense que tu as toutes les infos en main maintenant.

[arash]

change A::A(B *b) a :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
A::A(B *b){
	std::vector<B> *tmp;
        tmp = new std::vector<B>();
        tmp->push_back(*b);
	_vB=tmp;
	//_vB->push_back(*b);
}

[jblecanard]

Salut !

Même pas besoin de débuggueur, ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
	std::vector<B> *tmp;
	tmp->push_back(*b);

Est assuré de planter. Comme le dit si bien Arzar, tu tentes de déréférencer un pointeur qui n'a pas été initialisé et qui pointe au hasard dans la mémoire...

Plusieurs remarques:
- Pourquoi utiliser un pointeur de vector dans la classe A ? Ca n'a pas d'utilité, un vector simple comme dans B suffit amplement.
- Stocker des pointeurs est risqué, surtout si tu ne fais pas d'allocation dynamique. Il faut bien que tu apprennes le mécanisme d'allocation de mémoire (new, delete, allocation sur la pile), comment il fonctionne et comment les pointeurs se comportent. Ca fait partie des bases du C++ qu'il faut travailler.
- Dans le constructeur de A, tu n'as pas besoin d'un pointeur, tu peux utiliser une référence (et même une référence const dans ce cas)
- Tu n'as pas déclaré ni implémenté les destructeurs. C'est très mal, tu seras fouetté.
- Tu effectues des copies de B. Cela ne pose pas de problème dans le cas précis, mais n'oublie pas que tu fais usage du constructeur par copie par défaut.

Voici une implémentation de A, avec un pointeur de vector pour te montrer le principe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
class A{
public:
	A(B const & b);
  virtual ~A();
	B GetA(unsigned i);
	void setA(B const & b);
protected:
	std::vector<B> *_vB;
};
 
A::A(B const & b) : _vB(0)
{
  _vB = new std::vector<B>(); // Allocation dynamique
  if(_vB)
    _vB -> push_back(b);
}
 
A::~A()
{
  if(_vB)
    delete _vB; // Destruction du vecteur alloué dynamiquement
}
 
B A::GetA(unsigned i)
{
	return _vB->at(i); // Pointeur pas testé !
}
 
void A::setA(B const & b)
{
  _vB->push_back(b); // Pointeur pas testé !
}

Et voici une version sans le pointeur, qui est inutile dans ton cas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
class A{
public:
	A(B const & b);
  virtual ~A();
	B GetA(unsigned i);
	void setA(B const & b);
protected:
	std::vector<B> _vB;
};
 
A::A(B const & b)
{
  _vB.push_back(b);
}
 
A::~A()
{
}
 
B A::GetA(unsigned i)
{
	return _vB.at(i); // Pas de pointeur, tranquille le chat
}
 
void A::setA(B const & b)
{
  _vB.push_back(b); // Pas de pointeur, tranquille le chat
}

[Steph_ng8]

Bonjour.

Juste histoire d'être sûr...

- Tu n'as pas déclaré ni implémenté les destructeurs. C'est très mal, tu seras fouetté.

Ceci semble contredire la FAQ (en tout cas pour la classe A).
Quand dois-je définir un destructeur ?
Que conclure de la forme canonique orthodoxe de Coplien ?

Alors à quel saint faut-il se vouer ?

[jblecanard]

C'est exact, on peut, lorsqu'on sait ce qu'on fait, ne pas écrire de destructeur.

Mais ce n'est pas un bon conseil à donner à un débutant.

[oodini]

Alors à quel saint faut-il se vouer ?

Au droit, qu'on a tendance à négliger.

[Steph_ng8]

@jblecanard Ok.

@oodini Euh... Pardon ???

[koala01]

Salut,

C'est exact, on peut, lorsqu'on sait ce qu'on fait, ne pas écrire de destructeur.

Mais ce n'est pas un bon conseil à donner à un débutant.

Non, au contraire...

Le premier conseil à donner à un débutant, c'est KISS (Keep It Simple, Stupid)

Il faudrait d'ailleurs donner au PO le conseil de... virer son constructeur par copie, parce que:

1- inutile, vu que std::vector est copiable et que le compilateur est parfaitement en mesure d'en fournir un qui fera exactement ce que l'on attend de lui

2- devrait plutot utiliser les liste d'initialisation

3- pourrait etre bien plus efficace en utilisant, par exemple, le constructeur de vecteur prenant deux itérateur sous la forme de _vf=std::vector<float>(other._vf.begin(), other._vf.end()) (par exemple )

De manière générale, il n'y a absolument pas lieu d'imposer la création manuelle des "big four" (à vrai dire, il serait presque préférable de les interdire ) dés le moment où

1- il n'y a pas d'allocation dynamique
2- il n'y a pas de relation d'héritage publique
3- tous les membres sont copiable

[Steph_ng8]

Ah, je préfère ça...

[jblecanard]

Il faudrait d'ailleurs donner au PO le conseil de... virer son constructeur par copie, parce que:
1- [...]
2- [...]
3- [...]

Heu, vu qu'il utilise déjà les constructueurs par copie par défaut, je ne comprend pas le sens de la remarque ?
Edit : Effectivement, il y en a pour la classe B. Et je suis d'accord avec le fait qu'il faille le virer et/ou utiliser la liste d'initialisation.

Non, au contraire...

Le premier conseil à donner à un débutant, c'est KISS (Keep It Simple, Stupid)

Pour avoir moult fois fait coder en C++ des gens dont ce n'était pas et dont ça ne sera jamais le métier, je ne suis pas du tout d'accord avec ça, en qui concerne le destructeur (je ne parle pas du reste). Ajouter le destructeur explicitement est trivial et est une bonne habitude à prendre qui rappelle au codeur comment fonctionne le cycle de vie d'un objet, alors que son absence a tendance à lui faire oublier ce mécanisme (notamment pour les développeurs venant du java).

[Steph_ng8]

De manière générale, il n'y a absolument pas lieu d'imposer la création manuelle des "big four" (à vrai dire, il serait presque préférable de les interdire ) dés le moment où

1- il n'y a pas d'allocation dynamique
2- il n'y a pas de relation d'héritage publique
3- tous les membres sont copiable

Je n'ai pas tilté sur le coup, mais si je comprends bien les raisons 1 et 3, j'ai plus de mal pour la deuxième.
Excepté pour le destructeur qu'il faut déclarer explicitement virtuel, je ne vois pas pourquoi il faudrait absolument écrire les autres à la main s'ils ont le comportement par défaut.

Et est-ce que la... « règle » édictée plus haut reste valable si on utilise le mot-clé default du C++11 (pour les quatre fonctions... enfin disons les six) ?

[jblecanard]

Excepté pour le destructeur qu'il faut déclarer explicitement virtuel

Déjà, cette seule raison suffit à justifier (2)

Mais, aussi lorsque tu fais des copies, ça devient compliqué lorsqu'il y a de l'héritage entre les objets. En général, on n'autorise la copie que si les objets ont le même type statique. Il est donc courant d'interdire la copie des classes parentes dans ce cas. Que Koala veuille bien me reprendre si je me trompe sur ce point. Regarde cet exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
class A
{
  int m_member1; // Sémantique 1
};
 
class B : public A
{
  int m_member2; // Sémantique 2
};
 
class C : public A
{
  std::string m_member3; // Sémantique 3
};
 
int main(int argc, char* argv[])
{ 
  B b;
  C c;
  A a1(b); // Compile à cause de l'héiritage public sur A
  A a2(c); // Compile à cause de l'héiritage public sur A
  return 0;
}

Tu vois le problème de laisser les possibilités de copie par défaut sur A ?

Il y a aussi la sémantique d'entité/valeur des objets qui peut entrer en ligne de compte, mais on s'éloigne trop du sujet là

[Steph_ng8]

Tu vois le problème de laisser les possibilités de copie par défaut sur A ?

Non, pas vraiment...

Le constructeur par copie de la classe A ne va s'occuper que de la « couche » A des objets b et c, non ?
Et qu'est-ce que ça aurait changé de définir explicitement un constructeur par copie ?


Autre chose, je crois avoir lu quelque part que le constructeur par défaut implicite appelle le constructeur par défaut des variables membres, sauf pour les variables de type basique, qu'il laisse [Edit]non[/Edit] initialisées.
Déjà, est-ce vrai ?
Si c'est le cas, et donc que l'on est obligé de définir un constructeur par défaut explicite, cela nécessite-t-il de définir les trois autres fonctions, même si les 3 conditions présentées plus haut sont réunies ?

[jblecanard]

Non, pas vraiment...
Le constructeur par copie de la classe A ne va s'occuper que de la « couche » A des objets b et c, non ?
Et qu'est-ce que ça aurait changé de définir explicitement un constructeur par copie ?

Oui, tu tronques des données. Qu'est ce qui te dis que l'objet ne perd pas sa cohérence dans ce cas ? Le principe de Liskov ne te protège pas de ça.

Autre chose, je crois avoir lu quelque part que le constructeur par défaut implicite appelle le constructeur par défaut des variables membres, sauf pour les variables de type basique, qu'il laisse initialisées.
Déjà, est-ce vrai ?
Si c'est le cas, et donc que l'on est obligé de définir un constructeur par défaut explicite, cela nécessite-t-il de définir les trois autres fonctions, même si les 3 conditions présentées plus haut sont réunies ?

Oui, c'est le cas. Non, tu peux définir simplement le constructeur explicitement et laisser les autres définitions se faire par défaut.

[Steph_ng8]

Oui, tu tronques des données. Qu'est ce qui te dis que l'objet ne perd pas sa cohérence dans ce cas ? Le principe de Liskov ne te protège pas de ça.

D'accord, mais ça change quoi avec un constructeur par copie explicite ?

Oui, c'est le cas. Non, tu peux définir simplement le constructeur explicitement et laisser les autres définitions se faire par défaut.

Ok.

[jblecanard]

Peut être ce code sera-t-il encore plus parlant (je l'ai écrit alors je le poste ^^).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
#include <iostream>
#include <cmath>
 
struct Point
{
  double x;
  double y;
 
  Point(double iX, double iY) : x(iX), y(iY)
  {}
};
 
class Longueur
{
protected:
  double m_longueur; // Sémantique 1
 
public:
  Longueur() : m_longueur(0)
  {}
 
  virtual double CalculerLongueur()
  {
    return m_longueur;
  }
 
};
 
class Segment : public Longueur
{
  Point p1;
  Point p2;
  bool m_longEstCalculee;
 
public:
  Segment(double iX1, double iY1, double iX2, double iY2) : p1(iX1,iY1), p2(iX2,iY2), m_longEstCalculee(false)
  {}
 
   virtual double CalculerLongueur()
   {
     if( ! m_longEstCalculee)
     {
       m_longueur = std::sqrt( (p1.x - p2.x)*(p1.x - p2.x) + (p1.y - p2.y)*(p1.y - p2.y) );
       m_longEstCalculee = true;
     }
     return m_longueur;
   }
};
 
 
 
int main(int argc, char* argv[])
{
  Segment s(0.,0.,2.,0.);
  Longueur l(s); // Usage du constructeur par copie par défaut
  std::cout << l.CalculerLongueur() << " != " << s.CalculerLongueur() << std::endl;
  return 0;
}

D'accord, mais ça change quoi avec un constructeur par copie explicite ?

Tu le déclares en private et tu ne l'implémentes pas. Il n'est donc pas utilisable et le code qui tentera de s'en servir ne compilera pas.

[Steph_ng8]

Tu le déclares en private et tu ne l'implémentes pas. Il n'est donc pas utilisable et le code qui tentera de s'en servir ne compilera pas.

Dans ce cas, le problème n'est pas que le constructeur par copie soit implicite, mais plutôt qu'il existe un constructeur par défaut copie public.

Mais maintenant, je vois où tu veux en venir.

Désolé d'avoir pollué ton topic, totodu34 !

[jblecanard]

Dans ce cas, le problème n'est pas que le constructeur par copie soit implicite, mais plutôt qu'il existe un constructeur par défaut public

Je comprend mieux le malentendu. Quand je dis "explicite", je veux dire explicite en français au sens où l'on définit explicitement le constructeur, pas au sens C++ explicit.

[Steph_ng8]

Oui, moi aussi...