Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++Builder Discussion :

Redimensionner un tableau [Débat]


Sujet :

C++Builder

  1. #1
    Membre régulier Avatar de saidus
    Homme Profil pro
    Inscrit en
    octobre 2004
    Messages
    163
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 163
    Points : 87
    Points
    87
    Par défaut Redimensionner un tableau
    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");
     
    }
    Dhukmucmur Vernedh

  2. #2
    Membre chevronné
    Avatar de Gilles Louïse
    Profil pro
    Inscrit en
    mars 2002
    Messages
    421
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mars 2002
    Messages : 421
    Points : 1 879
    Points
    1 879
    Par défaut Re: Redimensionner un tableau
    Citation Envoyé par saidus
    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

  3. #3
    Membre averti

    Profil pro
    Inscrit en
    juin 2005
    Messages
    350
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : juin 2005
    Messages : 350
    Points : 437
    Points
    437
    Par défaut
    Il est aussi possible d'utiliser les vector de la STL. Pas très intuitifs pour commencer, mais assez souples à l'utilisation.

  4. #4
    Membre actif Avatar de Argol_Medusa
    Homme Profil pro
    Ingénieur Radiofréquences
    Inscrit en
    août 2005
    Messages
    201
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Radiofréquences
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : août 2005
    Messages : 201
    Points : 224
    Points
    224
    Par défaut Re: Redimensionner un tableau
    Citation Envoyé par Gilles Louïse
    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
    Désolé, on savait pas que c'était impossible, alors on l'a fait

  5. #5
    Rédacteur
    Avatar de Laurent Gomila
    Profil pro
    Développeur informatique
    Inscrit en
    avril 2003
    Messages
    10 651
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2003
    Messages : 10 651
    Points : 16 455
    Points
    16 455

  6. #6
    Membre chevronné
    Avatar de Gilles Louïse
    Profil pro
    Inscrit en
    mars 2002
    Messages
    421
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mars 2002
    Messages : 421
    Points : 1 879
    Points
    1 879
    Par défaut Re: Redimensionner un tableau
    Citation Envoyé par Argol_Medusa
    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

  7. #7
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2003
    Messages
    5 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2003
    Messages : 5 259
    Points : 10 777
    Points
    10 777
    Par défaut
    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.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  8. #8
    Membre chevronné
    Avatar de Gilles Louïse
    Profil pro
    Inscrit en
    mars 2002
    Messages
    421
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mars 2002
    Messages : 421
    Points : 1 879
    Points
    1 879
    Par défaut
    Citation Envoyé par 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... :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.

    Citation Envoyé par Luc Hermitte
    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

  9. #9
    Rédacteur
    Avatar de Laurent Gomila
    Profil pro
    Développeur informatique
    Inscrit en
    avril 2003
    Messages
    10 651
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2003
    Messages : 10 651
    Points : 16 455
    Points
    16 455
    Par défaut
    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)

  10. #10
    Membre chevronné
    Avatar de Gilles Louïse
    Profil pro
    Inscrit en
    mars 2002
    Messages
    421
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mars 2002
    Messages : 421
    Points : 1 879
    Points
    1 879
    Par défaut
    Citation Envoyé par Loulou24
    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

  11. #11
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2003
    Messages
    5 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2003
    Messages : 5 259
    Points : 10 777
    Points
    10 777
    Par défaut
    Citation Envoyé par Gilles Louïse
    Citation Envoyé par 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.

    Citation Envoyé par Gilles Louïse
    Citation Envoyé par Luc Hermitte
    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.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  12. #12
    Membre chevronné
    Avatar de Gilles Louïse
    Profil pro
    Inscrit en
    mars 2002
    Messages
    421
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mars 2002
    Messages : 421
    Points : 1 879
    Points
    1 879
    Par défaut
    Citation Envoyé par 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.

    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

  13. #13
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2003
    Messages
    5 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2003
    Messages : 5 259
    Points : 10 777
    Points
    10 777
    Par défaut
    Citation Envoyé par Gilles Louïse
    Citation Envoyé par 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.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

Discussions similaires

  1. Redimensionnement de tableau
    Par corwin dans le forum Tableaux - Graphiques - Images - Flottants
    Réponses: 1
    Dernier message: 06/02/2007, 20h27
  2. Redimensionner un tableau dynamique
    Par WebPac dans le forum Delphi
    Réponses: 6
    Dernier message: 18/01/2007, 16h23
  3. Comment redimensionner un tableau dynamique ?
    Par Mickey.jet dans le forum Langage
    Réponses: 13
    Dernier message: 07/09/2006, 18h16
  4. [Excel-VBA]Redimensionnement de tableau
    Par marsupilami34 dans le forum Macros et VBA Excel
    Réponses: 11
    Dernier message: 28/08/2006, 17h16
  5. [Tableaux] redimensionner un tableau
    Par falcon dans le forum Langage
    Réponses: 6
    Dernier message: 23/11/2005, 09h38

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo