Version imprimable
Si l'on considère une fonction quelconque faisant une opération sur un string,
par exemple une lecture de fichier, à un moment on peut utiliser soit :
char *tampon;
soit
char tampon[long=une valeur suffisante];
pour stocker les données sur lesquelles on va travailler...
quelle est la différence ? Laquelle on utilise généralement et pourquoi?
Merci d'avance...
utilise char* tampon qd la taille de la zone que tu vas allouer est variable.Citation:
Envoyé par maz
utilise char tampon[n] qd la taille de ta string est fixe, neammoins evite dans ce cas là de déclarer à l'interieur de tes fonctions des chaines de caractères trop longues sinon tu risques d'exploser ta mémoire.
Quelques liens pour t'aider à comprendre:Citation:
Envoyé par maz
http://emmanuel-delahaye.developpez....s.htm#pile_tas
allocation de mémoire
Le premier cas est un pointeur non-initialisé. Je ne vois pas comment une fonction de lecture standard pourrait l'utiliser sans provoquer un comportement indéfini, vu que sa valeur est indéterminée. Par contre, un tableau de char d'une taille raisonnable, oui, c'est fait pour.Citation:
Envoyé par maz
3 ème cas que tu n'as pas évoqué :
Donner une valeur valide au pointeur, par exemple en y stockant l'adresse d'un bloc alloué avec malloc().
On utilise une taille fixe quand on connait la taille à la compilation, ou si la taille est raisonnable (pas plus d'une centaine de char).
On utilise la mémoire allouée dans les autres cas.
Je n'aurais pas dit mieux.
Cependant, il y a tout de même quelque chose qui me tracasse, et c'est le côté "magique" que la plupart des profs de C (mais pas tous, hein !) donnent au "char *"... comme si c'était un type super-spécial, alors qu'il s'agit d'un vulgaire pointeur sur un caractère.
Je te donnerais un autre conseil, si tu me le permets. Dès que tu peux utiliser des vecteurs (ou des tableaux), automatiques ou non, fais-le.
En effet, si, par exemple après avoir initialisé la variable "char *tampon" par un appel à malloc(), tu accèdes aux éléments à la façon d'un vecteur (comme "tampon[i]" pour avoir le i_ème caractère), celà permet en général de rendre les choses plus compréhensibles, car on peut mieux apprécier la juste représentation physique de la chose. Surtout que, en général, il est fortement conseillé, d'après les fabricants de processeurs, de procéder de la sorte pour des questions d'optimisations, plutôt que via des pointeurs.
http://emmanuel-delahaye.developpez.....htm#char_star :DCitation:
Envoyé par InOCamlWeTrust
[] vs *, ça dépend complètement de l'implémentation. On ne peut affirmer quelque chose que si on a fait des mesures dans des conditions décrites et reproductibles.Citation:
En effet, si, par exemple après avoir initialisé la variable "char *tampon" par un appel à malloc(), tu accèdes aux éléments à la façon d'un vecteur (comme "tampon[i]" pour avoir le i_ème caractère), celà permet en général de rendre les choses plus compréhensibles, car on peut mieux apprécier la juste représentation physique de la chose. Surtout que, en général, il est fortement conseillé, d'après les fabricants de processeurs, de procéder de la sorte pour des questions d'optimisations, plutôt que via des pointeurs.
C'est vrai que ca peut être "plus parlant"Citation:
Envoyé par InOCamlWeTrust
??? sauf erreur de ma part, une expression telle que A[i] est interprétée et transcrite par le compilateur par *(A+i).Citation:
...Surtout que, en général, il est fortement conseillé, d'après les fabricants de processeurs, de procéder de la sorte pour des questions d'optimisations, plutôt que via des pointeurs.
Le compilateur ne s'interresse qu'à l'adresse des variables !
On ne peut absolument pas utiliser char * Tampon pour stocker des caractères.Citation:
Envoyé par maz
Non. A[i] est SEMANTIQUEMENT parlant équivalent à *(A + i)... mais au niveau compilation, il peut y avoir une grande différence, et ce à cause des modes d'adressage du processeur.Citation:
Envoyé par diogene
Lorsque je parlais d'accéder aux valeurs d'un vecteur via la notation "vecteur" en tant qu'optimisation, je me réferrais surtout aux machines x86. On pourra faire des tests (mais avec les optimisations du compilateur activées) et/ou on pourra aussi aller voir ce qu'en pensent des fabricants comme AMD (lire leur manuel des optimisations).
Avec un compilateur recent et performant et avec des options d'optimisation correctement reglees, le code genere a une assez grande probabilite d'etre le meme pour les deux notations.Citation:
Envoyé par InOCamlWeTrust
On s'en fout... Sauf bouse innommable, le compilateur fait ce qu'il faut...Citation:
Envoyé par InOCamlWeTrust
Oui, enfin, ici, on fait du C. L'écriture du code assembleur optimisé est confié au compilateur qui n'est pas fait par des bras cassés... Un programmeur C du 21 ème siècle n'a que faire de ces détails, on est plus dans les années 1970...Citation:
Lorsque je parlais d'accéder aux valeurs d'un vecteur via la notation "vecteur" en tant qu'optimisation, je me réferrais surtout aux machines x86. On pourra faire des tests (mais avec les optimisations du compilateur activées) et/ou on pourra aussi aller voir ce qu'en pensent des fabricants comme AMD (lire leur manuel des optimisations).
Si tu connaissais le document en question, tu saurais ce dont je parle.Citation:
Envoyé par Emmanuel Delahaye
C'est, je crois, dans la norme (et d'un point de vue non sémantique) et cela n'a sans doute pas échappé à ceux qui ont écrit le compilateur (que rien ne permet de supposer débiles ou incompétents au point d'ignorer les modes d'adressages du processeur cible)Citation:
Envoyé par InOCamlWeTrust
+1Citation:
Envoyé par Emmanuel
c'est vrai, hélas pour mes artères :cry:Citation:
Envoyé par Emmanuel
De quel document parles-tu ?Citation:
Envoyé par InOCamlWeTrust
De celui-ci :
http://www.amd.com/us-en/assets/cont...docs/25112.PDF
... Chapitre 2.
Cependant, je suis d'accord : un compilateur qui sait bien optimiser engendrera un code proche pour *(A + i) et A[i], mais rien ne nous l'assure, et du fait que le code présente une addition explicite et que je n'ai aucune garantie quant à la façon de compiler (de manière générale), je préfère éviter ce genre de chose (surtout que je ne trouve pas ça lisible du tout).
Ce document (qui me semble apres une lecture rapide assez interessant) decrit en gros les optimisations possibles pour une famille de processeurs, de ce fait :Citation:
Envoyé par InOCamlWeTrust
- ce qui est dit n'est valable que pour les processeurs en question
- il n'y a pas de relation bijective entre le code source et l'executable. Un bon compilateur devrait generer, dans les meme conditions, le meme code pour les deux notations. C'est d'ailleurs ce qui est dit dans le document en question :
Citation:
Source-code transformations interact with a compiler’s code generator, making it difficult to control the generated machine code from the source level.
A ce moment la, il faut faire des mesures. Et si effectivement les deux notations ne sont pas equivalentes, il convient d'utiliser la plus adapte (ou de changer de compilateur si c'est possible). C'est d'ailleurs la encore ce qui est dit dans le document :Citation:
Envoyé par InOCamlWeTrust
Citation:
Compare the performance of
your code after implementing a source-code transformation with the performance of the original code
to be sure that there is an improvement.
Sur le point de la lisibilite, je te rejoins. Je trouve que A[i] est, sauf cas particulier, plus lisible que *(A + i).Citation:
Envoyé par InOCamlWeTrust
Concernant "l'optimisation", lorsqu'il y a une difference de vitesse significative (donc lorsque les deux notations ne produisent pas le meme code executable), ca depends des compilateurs. D'ailleurs sur ce point, le document ne tranche pas reelement la question:
mais aussiCitation:
Using array notation makes the task of the optimizer easier by reducing possible aliasing.
Citation:
Depending on the compiler and the specific source code, it is possible for pointer-style code to compile into machine code that is faster than that generated from equivalent array-style code.
On est d'accord, à ceci près que la plupart des conseils donnés dans le Chapitre 2 (celui consacré au C) s'étendent également à d'autres familles de processeurs. On peut voir cette partie comme un ensemble de règles assez portables exploitant les caractéristiques des compilateurs intelligents actuels, mais aussi des caractéristiques présentes dans tous les processeurs modernes (voir ce qui est dit à propos du "parallèlisme explicite").