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().