Discussion :

[solitrion]

Bonjour tout le monde
je voulais faire un programme qui va agrandir la taille d'un tableau dont que je ne saisi pas par exemple 0, voici le code :

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
#include <stdlib.h>
// pour modifier la taille d'un tableau , possibilité d'utiliser resize de vector, ici on utilise realloc qui doit être utilisé avec malloc
//ici m est un pointeur , si m=null , realloc joue le rôle de malloc , et si b*sizeof = 0 elle joue le rôle de free
using namespace std;
 
int main()
{
   int b=0,x;
   int *T,*m=NULL;
   T=(int*) malloc (b*sizeof(int));// allocation dynamique
   cin>>x;// lire avant le test
   while (x!=0)
    {
       T[b]=x;
       b++;
       m=(int *)realloc((int *)T,(b)*sizeof(int));// reallocation  
   T=m;
   m=NULL;//rendre m null pour refaire realloc
   cin>>x;
   }
 
    return 0;
}

le probl�me est que lors de l'ex�cution ,d'ailleurs il n'y a pas d'erreur de compilation, apr�s que je saisi par exemple 6 nombres, l'ex�cution s'arr�te me disant que �a a cess� de fonctionner.
Est-ce que vous avez un id�e d'o� vient le probl�me ?

merci �norm�ment

[Davidbrcz]

Je laisse koala pondre une prose de 3km et je me contente de te donner l'essentiel :
* Change de cours et/ou prof. C'est du C compil� avec un compilateur C++, ce n'est pas du C++.
* std::vector est ec que tu recherches.

[EpiTouille]

Bonjour

D�j� au d�but, T est allou� de 0 blocs <=> ton malloc de 0
quelques lignes plus loins, tu lui assignes une valeurs

Code :

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

T[b]=x;

valgrind nous indiques d�j� un

Invalid write of size 4

[jblecanard]

* Change de cours et/ou prof. C'est du C compil� avec un compilateur C++, ce n'est pas du C++.

Il n'a pas forc�ment le choix ! Malheureusement, il existe un certains nombre de disciplines ou des enseignants qui ne sont pas informaticiens doivent donner des cours d'info. Ca donne ce genre de m�lange b�tard entre C et C++ souvent.

La r�ponse de EpiTouille est correcte.

J'ajouterai qu'en C++ on n'utilise pas malloc normalement.

Pour un tableau dont la taille est connue � la compilation, on utilise:

Code :

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

1
2
3
T* tab = new T[taille];
//...
delete[] tab;

Ou mieux, en C++11:

Code :

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

1
2
3
std::array<T, taille> * tab = new std::array<T, taille>;
//...
delete tab;

Si la taille n'est pas connue � la compilation mais � l'ex�cution, ou si le tableau est amen� � changer de taille, il te faut utilise std::vector. En C++14, on aura std::dynarray pour les tableaux dont la taille ne change pas une fois qu'il est cr��.

Attention au pi�ge:

Code :

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

1
2
3
4
5
 size_t taille = 0;
std::cin >> taille;
T* tab = new T[taille];
//...
delete[] tab;

C'est un exemple ou la taille est connue � l'ex�cution uniquement. Ce code compile (et fonctionne) avec GCC, mais c'est une extension de GCC, ce n'est pas standard. A �viter au possible. Il se peut que Visual Studio accepte aussi ce code, mais clang le refuse, � juste titre.

Merci � GL pour la correction sur ce paragraphe faux.

[Bousk]

Bonsoir,

pas mieux que Davidbrcz.
Faute de mieux, si on veux faire de l'allocation dynamique, on utilise au moins new/new[] et delete/delete[].

[gl]

Pour un tableau dont la taille est connue � la compilation, on utilise:

Code :

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

1
2
3
T* tab = new T[taille];
//...
delete[] tab;

Ou mieux, en C++11:

Code :

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

1
2
3
std::array<T, taille> * tab = new std::array<T, taille>;
//...
delete tab;

Ou, si la taille est connue � la compilation, tout simplement

Code :

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

T tab[taille];

Code :

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

std::array<T, taille> tab;

Sauf cas particulier, le new/delete ici n'apporte rien.

Si la taille n'est pas connue � la compilation mais � l'ex�cution, ou si le tableau est amen� � changer de taille, il te faut utilise std::vector. En C++14, on aura std::dynarray pour les tableaux dont la taille ne change pas une fois qu'il est cr��.

Ou new[], m�me si effectivement std::vector est la plupart du temps tr�s largement pr�f�rable.

Attention au pi�ge:

Code :

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

1
2
3
4
5
 size_t taille = 0;
std::cin >> taille;
T* tab = new T[taille];
//...
delete[] tab;

C'est un exemple ou la taille est connue � l'ex�cution uniquement. Ce code compile (et fonctionne) avec GCC, mais c'est une extension de GCC, ce n'est pas standard. A �viter au possible. Il se peut que Visual Studio accepte aussi ce code, mais clang le refuse, � juste titre.

Ce code compile et fonctionne car il est correct (c'est le r�le de new[]. Je pense que tu confonds avec les "VLAs", c'est � dire des tableaux statiques dont la taille n'est connue qu'� l�ex�cution soit :

Code :

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

1
2
3
 size_t taille = 0;
std::cin >> taille;
T tab[taille];

Mais je suis d'accord que c'est � �viter et qu'il faut privil�gier std::vector, std::array et autre conteneur RAIIsant.

[ManusDei]

Si je me souviens bien, realloc alloue une m�moire faisant la bonne taille, puis copie toutes les donn�es de l'ancien tableau dans le nouveau, non ?
(pas terrible question perf, si c'est fait r�guli�rement)

[jblecanard]

Sauf cas particulier, le new/delete ici n'apporte rien.

Oui, mais je montre en C++ ce qu'il fait en C, une allocation dynamique.

Ce code compile et fonctionne car il est correct (c'est le r�le de new[]. Je pense que tu confonds avec les "VLAs", c'est � dire des tableaux statiques dont la taille n'est connue qu'� l�ex�cution.

En effet !

[M�dinoc]

Si je me souviens bien, realloc alloue une m�moire faisant la bonne taille, puis copie toutes les donn�es de l'ancien tableau dans le nouveau, non ?
(pas terrible question perf, si c'est fait r�guli�rement)

Seulement si n�cessaire. S'il est possible d'agrandir le buffer in-place (ex. parce qu'il n'y a rien derri�re), realloc() le fera sur la plupart des impl�mentations.
Par contre, avec new[]+delete[], il faut toujours allouer un nouveau buffer et copier toutes les donn�es de l'ancien tableau.
Ce qui rend realloc() plus performant. Et avec std::copy plut�t que memcpy()*

Et bien s�r, si l'on veut explicitement utiliser realloc() pour ce gain de performance, on n'a pas trop le choix: Il faut utiliser malloc() et free() avec, car new[]/delete[] ne sont pas compatibles avec realloc() et n'ont pas d'�quivalent.

*certains objets non-POD peuvent faire des trucs bizarres impliquant leur propre adresse dans leur constructeur(s) et destructeur (par exemple, s'enregistrer dans une liste et se d�senregistrer quand ils sont d�truits). Ou tout simplement, des objets peuvent contenir un pointeur vers un buffer qu'ils copient (sinon, les deux objets font un delete[] du m�me pointeur lors de leur destruction, causant un comportement ind�fini). R�sultat, impossible de les copier simplement avec memcpy().