Discussion :

[Gonath]

Bonjour,


je viens ici pour comprendre pourquoi la fonction malloc pourrait me provoquer des erreurs d'executions.

je m'explique :

j'ai un code g�n�rant des tableaux de dimensions 1 et de dimensions 2 de mani�re dynamique. Ces tableaux font partis d'une classe que je nome AGO. Lors de l'utilisation du programme, je cr�e un objet de AGO qui cr�e dans son constructeur les tableaux voulus selon les dimensions pass�es en param�tres.

A chaque utilisation, je recr�e un nouvel objet AGO. A la premi�re utilisation, il n'y a aucun probl�me. A la seconde utilisation, mon programme plante. En remontant dans le code, j'ai pu constater que les lignes contenant la fonction malloc en sont responsable.

Le programme ne demande pas beaucoup de m�moire, au plus quelques ko par tableau, donc cela ne peut etre un d�bordement. (au fait je pr�viens que je suis un d�butant du malloc).

donc voici les deux lignes responsables :

// on cr�e le vecteur de demande
v = (signed int *) malloc(sizeof(signed int)*m);

// on cr�e le vecteur d'erreur
e = (signed int *) malloc(sizeof(signed int)*m);

la variable m a toujours la m�me valeur. (donc l� ce n'est pas du dynamique mais c'est juste pour v�rifier si je peux faire plusieurs fois la m�me op�ration).

Le plantage est significatif apr�s une deuxi�me cr�ation d'objet AGO voir parfois � la troisi�me ou quatri�me. Par contre, avec les lignes suivantes du code :

a = (bool**) malloc(n * sizeof(bool*));
for(unsigned int i = 0; i < n; i++)
a[i] = (bool*) malloc(m * sizeof(bool));

le plantage se fait obligatoirement � la seconde fois. (la variable n est fix�).

Pourriez vous me conseillez concernant la fonction malloc etc. Cela me pose quelques probl�mes pour d�velopper et cela m'ennuie d'avoir un programme instable.

merci pour vos futures r�ponses !

[wiztricks]

En g�n�ral, c'est un peu plus bavard que "plante".
Ca dit quoi?
- W

[Noxen]

malloc()/free() en C++ c'est le mal, new/delete c'est mieux

Les std::vector aussi c'est bien.

Faudrait voir quel est le message d'erreur que tu obtiens.

Avec new[] et delete[] :

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
 
#ifndef AHO_H
#define AGO_H
 
class AGO
{
private:
	int* _V;
	int size_v;
 
	int* _E;
	int size_e;
 
	bool** _A;
	int size_a1;
	int size_a2;
public:
	AGO(int v, int e, int a1, int a2):
	  _V(0), _E(0), _A(0), size_v(v), size_e(e), size_a1(a1), size_a2(a2)
	{
		_V = new int [size_v];
		for(int i = 0; i < size_v; ++i)
			_V[i] = 0;
 
		_E = new int [size_e];
		for(int i = 0; i < size_e; ++i)
			_E[i] = 0;
 
		_A = new bool*[size_a1];
		for(int i =0; i < size_a1; ++i)
		{
			_A[i] = new bool[size_a2];
			for(int j = 0; j < size_a2; ++j)
				_A[i][j] = false;
		}
	}
 
	~AGO()
	{
		for(int i = 0; i < size_a1; ++i)
			delete[] _A[i];
		delete[] _A;
 
		delete[] _E;
 
		delete[] _V;
	}
 
	/* Divers acesseurs et méthodes */
};
 
#endif

[Gonath]

Et bien je viens juste de modifier mon code pour enlever les malloc. J'y ai donc mis des new � la place. Mais m�me plantage. Par contre, pour un quelconque message, je n'ai absolument rien. A part quand j'ai employ� le debuggeur de wxdevcpp, il m'a mis une erreur de segmentation. (probl�me souvent du � des mauvais pointeurs mal g�r�s je suppose). Je cherche de ce cot� l�. Mais je ne maitrise vraiment pas le d�buggeur (mea culpa).

[wiztricks]

je suspecterais plut�t un pb c�t� assignation dans a et a[i] que dans malloc, mais un coup de debugger devrait r�gler ��
- W

[Gonath]

Oui mais pourquoi cela marche pour la premi�re fois, et non pour les fois suivantes ? C'est surtout cela ma question... Car tout fonctionne bien pour la premi�re fois.

[wiztricks]

c'est pour r�pondre � ce genre de questions invraisemblable qu'on a invent� les debugger
- W

[Aszarsha]

Parce que la premi�re fois tu tombe dans une page m�moire allou�e au programme, les suivantes non ?

[Gonath]

Lorsque j'utilise les breakpoints du debugger, donc en faisant pas � pas l'execution, il n'y a pas de probl�me apparemment. Il fonctionne correctement.

[wiztricks]

Jetez les breakpoints et remplacez les par des printf des adresses d'affectations
&a[i], i, n
- W

[Gonath]

Normalement, new doit se d�brouiller pour trouver de l'espace m�moire, surtout que mon programme ne prend vraiment pas bcp (1Mo) et que j'ai suffisement de place. Donc normalement, il ne devrait pas avoir d'erreur d'allocation de m�moire.

[Davidbrcz]

Il faudra qu'on m'explique pour continuer � utiliser new[] alors que la bonne solution � �t� donn�e (std::vector).

[JolyLoic]

Il est clair que la bonne solution est � base de vector. Il n'emp�che qu'un malloc ne doit pas "planter" sans raisons. Un exemple complet qui reproduise le probl�me permettrait probablement de lui tordre le cou une bonne fois pour toute, avant de basculer vers la bonne solution l'esprit all�g�.

[Gonath]

oui mais pour un vector n'est-il pas plus lent ? ou bien il n'est lent que pour la cr�ation, apr�s, il est bon et efficace ?

[Davidbrcz]

Du point de vue fanatique:

std::vector c'est le bien !

A la facon yoda :

std::vector dans tes programmes tu utilisera !

Nan le vector n'est gu�re (pas ?) plus lent qu'un tableau brut, mais avec des dizaines de fonctions en plus.

PS: +1 � Loic.

[JolyLoic]

R�ponse courte : Non.

R�ponse longue :

Il est plus lent qu'un tableau statique (mais ce n'est pas l� ton cas, sinon std::tr1::array remplirait ce r�le), et peut dans certains cas �tre plus lent qu'un tableau variable C (pas disponible en C++, aucun �quivalent en terme de performances).

Il peut dans certains cas �tre plus lent qu'un tableau � la C allou� dynamiquement, s'il est mal utilis� (pas de reserve alors qu'on connais d�s le d�but la taille finale, s'il est pass� par copie � une fonction, options de compilations permettant de d�tecter des erreurs restant dans le code final...).

Un tableau � la C allou� dynamiquement peut �tre plus lent s'il est mal utilis�, ce qui peut arriver facilement (mauvaise strat�gie de croissance si la taille n'est pas connue d�s le d�but (une bonne strat�gie est relativement complexe � mettre en place)).

Un vector est infiniment plus souple, simple, s�r. Les d�s sont largement pip�s en faveur de std::vector.

[Aszarsha]

Les d�s sont largement pip�s en faveur de std::vector.

Sous entendre qu'il y a une once de hasard dans ce choix est quelque peu pervers...

[loufoque]

malloc peut retourner un pointeur nul.
Tu ne traites �videmment pas ce cas.

[wiztricks]

malloc peut retourner un pointeur nul.
Tu ne traites �videmment pas ce cas.

Oui mais, originellement:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
 a = (bool**) malloc(n * sizeof(bool*));
for(unsigned int i = 0; i < n; i++)
a[i] = (bool*) malloc(m * sizeof(bool));

le plantage se fait obligatoirement � la seconde fois. (la variable n est fix�).

Donc OK, s'il y avait des tests, nous pourrions ne pas nous poser de questions stupides, mais si nous faisons confiance � l'auteur �� plante lorsqu'on alloue a[1].
Comme n ne devrait pas �tre modifi�, c'est "strange".
- W

[loufoque]

C'est quoi l'int�r�t de faire �a, au fait, plut�t que d'allouer un bloc contig� de n x m bools ?