Discussion :

[saidus]

Bonjour a tous !!
est il possible de redimensionner un tableau ??!!
j'ai la situation suivante :
je veux a partir d'une table de base de donnee recuperer le nbre de ligne (nbr) puis allouer de l'espace memoire (variable double * tt = new double[nbr] sous forme d'un tablau, apres ca je recupere les valeur de la table DB ( tt[i] = MyQuerytotal->Value;)
jusqu'ici c'est bon !!
je veux assigner les valeur de tt dans dba
en prenant en compte que je veux redimensionner le tableau dba
c.a.d
si tt contient 5 element => dba redevient 5

est it possible de faire ca !!!
Merci

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
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
59
60
61
62
63
64
65
66
67
 
   String      leg[7];
   const char *lab[7];
   double      dta[10];
   //double  *tt;
 
 
//---------------------------------------------------------------------------
__fastcall TFormMain::TFormMain(TComponent* Owner)
        : TForm(Owner)
{
      _control87(MCW_EM, MCW_EM);
}
//---------------------------------------------------------------------------
void __fastcall TFormMain::Quit1Click(TObject *Sender)
{
        Close();
}
//---------------------------------------------------------------------------
void __fastcall TFormMain::Button1Click(TObject *Sender)
{
   int i = 0 ;
   int nbr = MyQuery->RecordCount;
   double * tt = new double[nbr];
 
   MyQuery->First();
   while(!MyQuery->Eof)
   {
       leg[i] = MyQuerytypeglobal->Value;
       tt[i] = MyQuerytotal->Value;
       MyQuery->Next();
       i++;
   }
  memcpy(dta,tt,nbr);
  for(int j=0;j< nbr ;j++){
       LBox1->Items->Add(dta[j]);
     //  tt[j] = dta[j];
  }
 
  int f = sizeof(leg)/sizeof(leg[0]);
  for(int j=0;j<f;j++)
  {
      lab[j] = leg[j].c_str();       // lab[j] = new char[leg[j].Length()+1];
  }
 
 
 
Screen->Cursor = crHourGlass;
 
    PieChart *c = new PieChart(500, 300, Chart::goldColor(), -1, 1);
    c->addTitle("Vente dans le Segment A00 en 2005", "LuCon.ttf", 14)->setBackground(Chart::metalColor(0xff9999));
    c->setPieSize(250, 120, 100);
    c->set3D();
    c->setLabelLayout(Chart::SideLayout);
    c->setLabelStyle()->setBackground(Chart::SameAsMainColor,Chart::Transparent, 1);
    c->setLineColor(Chart::SameAsMainColor, 0x0);
    c->setStartAngle(135);
    c->setData(DoubleArray(dta,sizeof(dta)/sizeof(dta[0])), StringArray(lab, sizeof(lab)/sizeof(lab[0])));
    c->makeChart("q.bmp");
    delete c;
 
   // delete[] dta;
 
Screen->Cursor = crDefault;
Image1->Picture->LoadFromFile("q.bmp");
 
}

[Gilles Louïse]

est il possible de redimensionner un tableau ?

En principe, on ne peut pas redimensionner un tableau avec le couple new/delete, il faut soit utiliser malloc qui a son realloc (utilisation très critiquée en C++ mais ça marche), soit refaire un nouveau new à la nouvelle dimension et recopier l'ancien et en libérant l'ancienne mémoire (usine à gaz), soit utiliser la technique des liste chaînées, soit surdimensionner au départ le tableau pour éviter d'avoir à le redimensionner, soit encore utiliser des composants de la VCL comme TList dont chaque pointeur pointerait un double. Tout dépend du contexte exact.

À bientôt
Gilles

[Patrick Seuret]

Il est aussi possible d'utiliser les vector de la STL. Pas très intuitifs pour commencer, mais assez souples à l'utilisation.

[Argol_Medusa]

utiliser malloc qui a son realloc (utilisation très critiquée en C++ mais ça marche)
Gilles

J'ai entendu dire cela plusieur fois.
Pour quelle raison cette méthode est-elle critiquée exactement ?

En Borland C++ Builder je n'ai jamais eu l'occasion de tester, il y a peut-etre autre chose de plus approprié, mais du temps des 486dx avec le turbo C++ de Borland, c'était LA méthode que tout le monde utilisait, et qui ne posait aucun problème à ma connaissance

[Laurent Gomila]

http://c.developpez.com/faq/cpp/?pag...NTEURS_realloc

[Gilles Louïse]

J'ai entendu dire cela plusieurs fois.
Pour quelle raison cette méthode est-elle critiquée exactement ?

Il n'y a pas de raison véritablement objective hormis un purisme exacerbé.

Comme dans les tous domaines, vous avez des intégristes, ce sont en général ceux qui développent le moins et qui restent dans les très hautes sphères de la théorie pure, un peu à la manière des professeurs d'harmonie en musique qui ne composent pratiquement pas mais qui font de la théorie.

Pour ma part, étant donné que le C++ est en surensemble du C, je ne vois aucun inconvénient à utiliser la triade malloc/realloc/free : il est absolument certain que ça marche eu égard à la compatibilité ascendante allant du C au C++. Il faut simplement que vous soyez sûr, au moment du realloc, que la mémoire a bien été allouée précédemment par malloc. Dans les très grands programmes avec énormément de modules, vous n'avez en général qu'un pointeur et vous pouvez ne pas savoir comment a été allouée la mémoire. Donc un realloc est risqué. Mais si vous êtes certain que la mémoire a été allouée par malloc, ça marchera.

À bientôt
Gilles

[Luc Hermitte]

Ces fonctions C ne pas prévues pour fonctionner directement sur des objets. Elles ne sont adaptés que sur les types POD -- Si ça ce n'est pas objectif...

<zone subjective>
Après, il y a des gens qui ne sont pas génés par un code hétérogène. Moi assez. Car un coup il faut attraper des exceptions, un coup tester à null -- null qui fait au passage que les new se marient mieux avec le RAII. Il est facile d'utiliser le mauvais couple (pour raison d'inattention, fatigue ou autre). Les fonctions C sont plus verbeuses et demandent des informations que le compilo devrait être à même de trouver par lui même. Cela peut demander d'utiliser deux bibliothèques pour surveiller les allocations -- quand on fait ça à la main.

Bref, toutes sortes de choses qui font que je ne vois pas d'intérêt aux fonctions C ... en C++. Pour le realloc, je préfère 100 fois le vecteur qui me lèvera une exception en cas de redimensionnement impossible -- et de là à ce que des SL intelligemment conçues utilisent realloc et autres memmove pour les types POD...
</>

PS: tout le C n'est pas repris en C++ -- je précise pour les non initiés qui liraient tes propos, car je sais que tu es au courant Bon d'accord, sorti des VLA, pas de grosse différence pour les tableaux dynamiques de types POD dont on parle ici.

[Gilles Louïse]

Ces fonctions C ne pas prévues pour fonctionner directement sur des objets. Elles ne sont adaptés que sur les types POD -- Si ça ce n'est pas objectif... :P

Ici, l'internaute veut une suite de "double", ce n'est donc pas un réel objet C++, il veut pouvoir avoir une zone variable, dans ce cas un malloc/realloc/free me paraît acceptable.

Pour le realloc, je préfère 100 fois le vecteur qui me lèvera une exception en cas de redimensionnement impossible -- et de là à ce que des SL intelligemment conçues utilisent realloc et autres memmove pour les types POD...

Admettons mais il faut déjà maîtriser les syntaxes des vecteurs, ce n'est pas forcément le cas de tout le monde. Est-ce nécessaire pour une suite de "double"? Est-ce un grand programme ou un petit?
Le realloc aussi indique très clairement si oui ou non la mémoire a pu être allouée. De plus, si le pointeur est NULL, on a realloc=malloc, ce qui fait qu'on peut toujours utiliser le realloc même la première fois sans distinction. Il suffit pour cela que le pointeur soit initialisé à NULL au départ.

Dans l'absolu, je sais bien que c'est vous qui avez raison. Mais dans le cadre d'un petit programme (où donc on ne travaille pas en équipe) et d'une suite de nombres standard du C (qui ne sont donc pas encore des objets au sens du C++), ce ne sera pas un grand crime que d'utiliser malloc/realloc/free.

C'est un des grands malheurs du C++ de n'avoir pas été foutu d'avoir une sorte de "renew" qui eût été l'équivalent du realloc, si utile dans les programmes. Obligé de faire des pieds et des mains pour avoir une zone variable alors que c'est le B A BA de la programmation. Et en plus de se faire quasiment engueuler à chaque fois (LOL).

À bientôt
Gilles

[Laurent Gomila]

C'est un des grands malheurs du C++ de n'avoir pas été foutu d'avoir une sorte de "renew" qui eût été l'équivalent du realloc, si utile dans les programmes. Obligé de faire des pieds et des mains pour avoir une zone variable alors que c'est le B A BA de la programmation

Comme dit dans la FAQ, l'approche C++ des zones mémoires dynamiques, c'est std::vector ; il ne faut donc pas chercher un quelconque renew, std::vector l'intègre directement sans se poser de question.

Et puis, entre nous, quel est le cas où l'on doit faire des pieds et des mains entre ces 2 là ?

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
double* tab = malloc(5 * sizeof(double));
 
for (int i = 0; i < taille; ++i)
{
    tab = realloc(tab, i * sizeof(double));
 
    if (!tab)
        throw std::bad_alloc();
 
    tab[i] = 50.0 * i;
}
 
...
 
if (tab)
    free(tab);

Code :

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

1
2
3
4
std::vector<double> tab;
 
for (int i = 0; i < taille; ++i)
     tab.push_back(50.0 * i)

[Gilles Louïse]

Comme dit dans la FAQ, l'approche C++ des zones mémoires dynamiques, c'est std::vector ; il ne faut donc pas chercher un quelconque renew, std::vector l'intègre directement sans se poser de question.

Merci, à apprendre par coeur.

J'ai toujours trouvé les syntaxes des vecteurs assez imbuvables mais il faut s'y résoudre coûte que coûte, vos excellents exemples le prouvent.

À bientôt
Gilles

[Luc Hermitte]

Ces fonctions C ne pas prévues pour fonctionner directement sur des objets. Elles ne sont adaptés que sur les types POD -- Si ça ce n'est pas objectif...

Ici, l'internaute veut une suite de "double", ce n'est donc pas un réel objet C++, il veut pouvoir avoir une zone variable, dans ce cas un malloc/realloc/free me paraît acceptable.

Tout à fait. C'est la question initiale. Ce qui ne m'empêche pas de penser qu'il est bon d'en préciser les limitations.

Pour le realloc, je préfère 100 fois le vecteur [...]

Admettons mais il faut déjà maîtriser les syntaxes des vecteurs, ce n'est pas forcément le cas de tout le monde. Est-ce nécessaire pour une suite de "double"? Est-ce un grand programme ou un petit?
Le realloc aussi indique très clairement si oui ou non la mémoire a pu être allouée.

Il faut en effet apprendre une autre syntaxe pas si compliquée que cela. Bien plus abordable, AMHA, que les idiomes consacrés à une gestion correcte de la mémoire quand on repose sur malloc/realloc/free.
De plus, avec realloc, si cela a foiré, il faut désallouer. Et la fuite de mémoire est à la porté de tout le monde. Regarde le code de Loulou. Le bon code aurait été (de ce que je lis du man et de la doc sur dinkumware) (à moins que je sois celui qui est dans les choux ...) :

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
double* tab = malloc(5 * sizeof(double));
 
for (int i = 0; i < taille; ++i)
{
    double * ttemp = realloc(tab, i * sizeof(double));
 
    if (!ttemp) {
        free(tab); // là, sinon fuite!
        throw std::bad_alloc();
    }
    tab = ttemp;
    tab[i] = 50.0 * i;
}
...
if (tab)
    free(tab);

Et encore, ici on triche, on utilise des exceptions. On aurait souffert à vouloir rendre le code SESE (single entry / single exit), chose qui devient limite une nécessité en l'absence d'exceptions et de RAII.

Dans l'absolu, je sais bien que c'est vous qui avez raison. Mais dans le cadre d'un petit programme (où donc on ne travaille pas en équipe) et d'une suite de nombres standard du C (qui ne sont donc pas encore des objets au sens du C++), ce ne sera pas un grand crime que d'utiliser malloc/realloc/free.

C'est acceptable si on accepte d'écrire du code simple qui au fond est buggué -- parce que l'on a voulu le programme simple. Ecrire du code correct est bien évidemment possible, mais l'effort requis n'est pas le même.

C'est un des grands malheurs du C++ de n'avoir pas été foutu d'avoir une sorte de "renew" qui eût été l'équivalent du realloc, si utile dans les programmes. Obligé de faire des pieds et des mains pour avoir une zone variable alors que c'est le B A BA de la programmation.

Quand même. Je ne fournis absolument pas le même effort avec les deux techniques. Les deux techniques demandent un minimum de connaissances, mais l'effort requis, le code final, et la maintenabilité finale ne sont pas comparables.
Autrement, il y a un article très intéressant, connexe à ce sujet, dispo depuis la FAQ sur le site de Stroustrup -> "pourquoi il faut enseigner le C++ comme un langage à part entière"

Et en plus de se faire quasiment engueuler à chaque fois (LOL).

Bââhhh. On a été sages cette fois.

[Gilles Louïse]

C'est acceptable si on accepte d'écrire du code simple qui au fond est buggué

Le problème de ces conversations oiseuses, c'est toujours l'arrivée au grand galop d'une forme d'intégrisme du côté de la théorie pure.

Il faut être bien malheureux pour dire qu'un code qui utilise malloc/realloc/free en C++ "au fond est buggué".

L'astuce pour obtenir gain de cause, c'est de transférer le centre de gravité du problème ailleurs que là où il est.

L'internaute parle de "double", on lui répond objet du C++.

L'internaute parle d'un tableau qui est simplement susceptible d'être agrandi, on pousse le problème à l'extrême en prenant pour hypothèse que l'allocation pourrait être refusée.

Avec nos ordinateurs riches de centaines de MO, ce ne sera jamais le cas dans la pratique. D'ailleurs, une application réserve d'elle-même d'office une certaine quantité de mémoire (je crois que ça tourne autour d'un MO par défaut avec C++ Builder) en sorte que dans le cadre d'une application standard, on ne teste même pas le code retour des fonctions allouantes, on prend pour hypothèse certaine que la mémoire a été allouée correctement. Il faudrait manipuler d'énormes tableaux pour que l'allocation mémoire soit refusée, ce n'est pas du tout la question d'origine de l'internaute.

Je vous rassure, la technique de réponse et de dramatisation est la même chez les puristes en harmonie musicale et la technique d'intimidation est également toujours la même à savoir celle que j'ai indiquée : transférer le centre de gravité du problème ailleurs que là où il est.

Que ne ferait-on pas pour paraître avoir raison?

À bientôt
Gilles

[Luc Hermitte]

C'est acceptable si on accepte d'écrire du code simple qui au fond est buggué

Le problème de ces conversations oiseuses, c'est toujours l'arrivée au grand galop d'une forme d'intégrisme du côté de la théorie pure.

Hum. Laissons Godwin et ses points où il est.

Il faut être bien malheureux pour dire qu'un code qui utilise malloc/realloc/free en C++ "au fond est buggué".

Il arrive parfois que je fasse attention aux mots que je tape. Là, le "simple", n'était pas là par hasard. En revanche, je n'ai certes pas repondu toujours et encore ces mêmes explications sur le choix entre :
- un code simple incorrect ("buggué" était peut-être bien un mot malheureux, OK, mea culpa)
- un code compliqué correct
- un code simple correct.

Premier cas, c'est les mallocs (ou autres fonctions d'allocations de ressources, qui ne sont pas toujours très bien encapsulées) sans vérification de succès des allocations. Deuxième cas, c'est la version avec tous les tests qui n'est pas terrible à maintenir. Troisième cas, c'est en passant par un objet qui fait abstraction de détails bas niveau comme la gestion de la mémoire associée au tableau dynamique et extensible que l'on souhaite gérer.

L'astuce pour obtenir gain de cause, c'est de transférer le centre de gravité du problème ailleurs que là où il est.

L'internaute parle de "double", on lui répond objet du C++.

Oui, l'OP parle au départ de doubles, puis de "Pour quelle raison cette méthode est-elle critiquée exactement ?". Et là effectivement, on parle de choses qui sortent du cadre de simple objets POD.

L'internaute parle d'un tableau qui est simplement susceptible d'être agrandi, on pousse le problème à l'extrême en prenant pour hypothèse que l'allocation pourrait être refusée.

Mais une allocation peut être refusée! Je suis désolé, mais cela fait parti des choses à prendre en compte sur les environnements sur lesquels je bosse. (que ce soit à cause de conditons aux limites atteintes (serveurs où la RAM est très chère, où quantités de process doivent tourner des semaines entières sans que les uns puissent entrainer la chute des autres), ou calculs numériques avec beaucoup de données (ce qui n'est pas incompatible avec le "bosser avec des doubles")). (Désolé pour cette disgression, c'est juste pour dire n'est pas que du pinaillage de théoricien!)

Mais certes, son problème est très certainement plus simple. Et il n'a peut être pas besoin de trop se prendre la tête avec des allocations refusées.
Mais j'en reviens à ce sur quoi je veux insister et qui visiblement passe à la trappe dans mes explications.

Entre montrer à un débutant un code simple qui est incorrect et qui sera fonctionnera parfaitement 95% du temps, un code compliqué qui fonctionnera correctement 99.9% du temps, et code simple qui fonctionnera correctement 99.9% du temps -- le 0.1%, c'est parce qu'il faut encore intercepter quelques exceptions. Pourquoi persister à montrer le premier et dire que les autres sont inutiles, relèvent du pinaillage, ou que sais-je encore ?

NB: je n'ai fais que paraphraser à ma sauce l'article auquel j'avais fait allusion plus haut.

Cordialement.