J'avais pas pensé a poser la question avant mais, j'ai remarqué qu'on préfère toujours les expression du typequeCode:*(tableau+index)
c'est pas la même chose?Code:tableau[index]
Version imprimable
J'avais pas pensé a poser la question avant mais, j'ai remarqué qu'on préfère toujours les expression du typequeCode:*(tableau+index)
c'est pas la même chose?Code:tableau[index]
Perso, je préfère l'expression avec les braquets...
Mais cela revient en effet à la même chose:
D'un coté, avec les braquets, tu dis "je veux l'élément à l'indice index", et de l'autre, tu dis "je veux ce qui se trouve à l'adresse (début du tableau+(index*taille de l'élément) ) "
Et comme, l'indice index correspond à l'adresse du début du tableau + (index * taille de l'élément)...
Maintenant, il faut savoir qu'il y a quelques situations dans lesquelles l'un est préférable à l'autre (mais sans fournir l'index, alors)...
Tous les conteneurs de la STL qui ne fournissent pas un accès aléatoire aux éléments (donc, en gros, tous à l'exception de std::vector) et qui forcent l'utilisation d'un iterateur nécessitent le recours à (*iterateur) pour accéder au contenu.
On peut donc estimer que l'utilisation de la syntaxe *(tableau +index) assure une meilleure homogénéité d'écriture... Mais c'est un avis que je ne partage pas forcément ;)
La, pour le coup, c'est illisible :lol:Citation:
Envoyé par disturbedID
EDIT : je pense d'ailleurs que tu oublies l'incrémentation du pointeur donc pas faisable en une seule ligne.
Si t[i] = *(t+i) pourquoi ce message alors?
Bizarre j'ai toujours cru que *(t+i) était plus rapide?Citation:
Envoyé par Alp
*************************************************
@NiamorH : Non on incrémente pas le pointeur on fait l'addition avec "lon". Mais bon c'est tellement illisible :mouarf: (en plus d'être sûrement moins rapide vu qu'on fait un cast a chaque fois. Donc je garde ta solution)
Il n'y a que peu de raisons que ce soit le cas, à défaut de pouvoir certifier qu'il n'y en a aucune :D
Mes essais persos montrent qu'un code simple dans lequel le seul changement est la tranfsormation d'un acces en tab[i] en un acces en *(tab+i) produit exactement le même code assembleur, sous réserve, évidemment, d'utiliser les même options d'optimisation.
Et, dans l'ensemble, ce n'est pas *si* étonnant que cela: le jeu d'instruction reste malgré tout (relativement :question:) limité, même si on demande explicitement d'utiliser le jeu des processeurs les plus récents :roll:
Il est donc *relativement* logique que deux codes suivant exactement la même logique générale pour mener à un résultat identique fourniront une succession d'instructions processeurs identique ;)...
Maintenant, comprenons nous bien: je me base ici sur mes observations personnelles en utilisant mon compilateur (gcc 4.2.1 en l'occurrence).
Il n'est pas impossible que de "vieux" compilateurs (et donc moins "techniquement au point") ou que d'autres compilateurs puissent avoir des résultat différents. Et c'est la principale raison de l'"extrême prudence" de mes propos ;) :P
Merci :ccool:
Je tiens a signaler quand même que Mr. Bruce Eckel, malgré son formidable travail a bien joué son coup, avec quelque fois des exercices sans grandes indications et où on ne voit même pas le but recherché, il arrive a bloqué le lecteur désireux de connaître la solution (souvent bête), avec juste en dessus le petit message subliminalJe peux vous dire que si j'avais une MasterCard y a bien longtemps que j'aurai craqué :aie:Citation:
Solutions to selected exercises can be found in the electronic document The Thinking in C++ Annotated Solution Guide, available for a small fee from http://www.BruceEckel.com.
exemple d'exercices le n°1 du chapitre 4 :Et il ne donne même pas la déclaration de puts, comme si c'était évident qu'elle retourne un int (et si vous mettez void a la place ou quelque chose d'autre ça ne marchera pas). Et pire encore il ne dit même que c'est avec le compilateur c que ça doit marcher. Il abandonne complètement son lecteur.Citation:
# In the Standard C library, the function puts( ) prints a char array to the console (so you can say puts("hello")). Write a C program that uses puts( ) but does not include <stdio.h> or otherwise declare the function. Compile this program with your C compiler. (Some C++ compilers are not distinct from their C compilers; in this case you may need to discover a command-line flag that forces a C compilation.) Now compile it with the C++ compiler and note the difference.
ou encore cette exercice complètement inutile :sans commentaire :roll:Citation:
(Challenging) Modify FloatingAsBinary.cpp so that it prints out each part of the double as a separate group of bits. You’ll have to replace the calls to printBinary( ) with your own specialized code (which you can derive from printBinary( )) in order to do this, and you’ll also have to look up and understand the floating-point format along with the byte ordering for your compiler (this is the challenging part).
Au mieux ça t'apprend a Googler mais ça te fais perdre du temps :P
Je me console en me disant que la pauvreté et la meilleur école. :(
Ah oui exact.Citation:
Envoyé par disturbedID
Alors le static_cast est fait à la compilation, normalement il n'y a aucune perte de rapidité significative à l'éxécution. dynamic_cast est le seul cast où il y a perte de perfs.Citation:
Envoyé par disturbedID
Par contre tu fais une addition et moi une simple incrémentation.
Peut-on parler d'une simple incrémentation pour un pointeur vers un entier?
En fait, une incrémentation ne peut que difficilement être autre chose que "simple"...
Sémantiquement parlant, le terme incrémentation signifie "ajouter 1 à la valeur de"...
Cela signifie que, si tu as une variable numérique qui vaut 4 et que tu l'incrémente, elle ne peut pas valoir autre chose que... 5 :roll:
La seule nuance au niveau des pointeurs est que le fait de les incrémenter fournit l'adresse à laquelle l'élément suivant du type géré par le pointeur *devrait* théoriquement se trouver.
Range, je traduirai par "intervalle".Citation:
Envoyé par disturbedID
L'équivalent de tranche serait plutôt qquelque chose comme "slice"
Un cast d'un entier en entier plus petit, ou entre flottant et entier, n'est pas fait "à la compilation" et affecte les performances (surtout côté flottant<-->entier).Citation:
Envoyé par NiamorH
Seuls le reinterpret_cast<> et le const_cast<> n'ont d'effet qu'à la compilation...
Tu as raison, durant la compil, un static_cast génère un peu de code, mais très optimisé, notamment des affectations qui, si elles sont effectuées sur des objets, peuvent entraîner l'appel du constructeur par copie. Sur les types de base ça reste très léger, peut-être plus lourd quand même que la différence entre addition et incrémentation, je ne sais pas.
Bonjour tout le monde,
Attention le poste risque d'être un peu longuet je m'en excuse.
Je suis à l'exo 22 du chapitre 4.
N.B : Stash = sorte de tableau dynamique. Stack = Pile ( ;) )
Exo terminé mais y a quelque chose qui me gêne, c'est que si je décide de supprimer les chaîne allouée dynamiquement avec delete je rencontre une très longue erreur à l'executionCitation:
Créez un Stack qui contient des Stashes. Chaque Stash contiendra 5 lignes d'un fichier passé en entrée. Créez les Stashes en utilisant new. Chargez le contenu d'un fichier dans votre Stack, puis réaffichez-le dans sa forme origninale en extrayant les données de la structure Stack.
et dès que je commente le delete tout marche au poile.Code:
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
Dont j'ai cerné le problème (j'ai supprimer la pile) et la il s'agit juste d'utiliser le stash pour copier les lignes une à une. puis de les afficher et j'ai le même problème. Je pose la solution du problème simplifié :
Voila c'est vraiment pas compliqué. Ca se passe au niveau de "delete ligne" (avant dernière). si je libère pas les string tout marche bien, sinon ça foire.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Il faut savoir que Stash à été écrite et présentée par l'auteur lors du chapitre 4. Si vous voulez que je poste ici le Stash.cpp et Stash.h y a pas de problème.
Si vous trouvez le message trop long où voulez plus de précisions n'hésitez pas.
Théoriquement la désallocation, c'est ton tableau qui la fait, donc je ne vois pas trop ce qui se passe du tout :koi:
@miles : On voulant te répondre, j'ai revu la fonction add de la class Stash, et j'ai enfin compris mon erreur et compris ce qui s'est passé, je m'explique :
1- La classe Stash n'est qu'un tableau de char, dont on spécifie la taille du type qu'elle est sensé stocker a l'initialisation. Et la fonction addprend donc un pointeur vers l'élément qu'on veut ajouter. Or moi qui voulais stocké un pointeur vers un string je n'envoyais qu'un...pointeur vers un string alors qu'il fallait envoyer un pointeur vers un pointeur de string. Même chose pour la valeur a retourner. Donc la version corrigée :Code:int Stash::add(const void* element)
Donc pour répondre a miles, non tabDyn.cleanup() ne fais pas tout, car, et ça tu ne pouvais pas le savoir :Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Elle ne fais que supprimer le tableau de char qui stockait les éléments.Code:
2
3
4
5
6
Maintenant que c'était il passé avant, et bien tout simplement en envoyant un pointeur vers un string, l'élément copié dans le tableau était le string, qui, et je viens de le remarquer ne tient que sur 4 octet et qui est donc un genre de référence vers la vrai structure stockée quelque part dans la mémoire. Donc j'avais apparement la même valeur que maintenant suaf que le delete ne marchais pas avant vu qu'on ne supprimé pas avant un vrai pointeur (en tout cas pas déclaré en tant que tel).
Je sais pas si vous comprenez :lol:
Si je me suis trompé n'hésitez pas.
En tout cas Merci miles.
J'ai pas tout saisi, mais si tu as une erreur de moins, tant mieux :)