Disponibilité de "Solution Guide, Thinking C++"

Bonjour,

Tout d'abord je m'excuse si je ne poste pas dans la bonne section, mais je n'ai point vu de section dédiée aux livres sur ce forum (Et c'est bien dommage ;) )

Ceci étant dit, ma question est : existe-t-il une version physique du livre "Annotated Solution Guide for Thinking C++" en vente en magasin en France?

Car étant où je suis (c'est à dire un bled pourri (rhoo c'est méchant :lol:)) nul chances de payer par MasterCard, Amercian Express, Paypal, ou je ne sais quelle bourgeoiserie du monde riche.


Merci.

Salut,

Une équipe de bénévoles du forum travaille pour l'instant à la traduction du volume 1, qui est finie et en cours de relecture.

Si j'ai bien compté, il reste 38 chapitres qui nécessitent une relecture (tu trouvera l'état d'avancement ici), et une version pdf du bouquin *devrait* être disponible assez rapidement après la fin de la relecture (mais comme ce n'est pas moi qui m'occuperai de cela, et que le responsable n'a sans doute pas que cela à faire... je n'oserais lui mettre une pression supplémentaire pour connaître la date de parution finale :roll:)

Si tu t'en sens le courage et les capacités pour participer à la relecture, il n'est pas trop tard pour s'impliquer dans le projet via le forum qui est consacré à la traduction :D

Je tiens a vous félicité tout d'abord pour le travail accomplis sur cette traduction dont j'avais effectivement connaissance (et où je participe un petit peu a la re-relecture ;) ). Mais je ne parle pas de ce livre qui est lui disponible gratuitement, mais de l'inaccessible "Guide des Solutions", d'exercices qu'on trouve à la fin de chaque chapitre de THK CPP et qui lui coûte 12$.

Comme une version papiers existe pour Thinking C++, je me demande s'il n'est pas de même pour le "Guide des solutions" pour les raisons évoquée plus haut.

Citation:

---

Envoyé par koala01

Salut,

Une équipe de bénévoles du forum travaille pour l'instant à la traduction du volume 1, qui est finie et en cours de relecture.

Si j'ai bien compté, il reste 38 chapitres qui nécessitent une relecture (tu trouvera l'état d'avancement ici), et une version pdf du bouquin *devrait* être disponible assez rapidement après la fin de la relecture (mais comme ce n'est pas moi qui m'occuperai de cela, et que le responsable n'a sans doute pas que cela à faire... je n'oserais lui mettre une pression supplémentaire pour connaître la date de parution finale :roll:)

Si tu t'en sens le courage et les capacités pour participer à la relecture, il n'est pas trop tard pour s'impliquer dans le projet via le forum qui est consacré à la traduction :D

---

excellent travail de traduction, un grand bravo.
si je peux me permettre une toute petite remarque, dans le chapitre 16.4 (http://bruce-eckel.developpez.com//l...&chapitre=16.4)
la phrase suivante "The Stack as a template" à été traduite en "Stack comme template". peut être que "Stack en tant que template" aurait été mieux ?. (ca se discute?)
bon c'est juste en passant hein, tout le reste est super (même si j'ai pas fini d elire là).
Merci.

Il me semble assez improbable d'imaginer qu'un développeur (qui se respecte) ne maîtrise pas "un minimum" l'anglais technique. Lire un bouquin en anglais, notamment de C++, est un excellent exercice pour mieux se familiariser avec quelques nouvelles expressions ou mots de vocabulaire, peut-être jusque là non compris mais sur lesquels on avait fait l'impasse. Il ne me viendrait pas à l'idée de lire une traduction française lorsque j'ai le choix avec la VO. C'est comme se limiter aux sources fr sur le web sans pouvoir tirer partie des pages en anglais. Quelque part, je trouve que c'est ne pas rendre service aux gens que de leur mâcher le travail, surtout quand on sait que la plupart des employeurs (en prog, mais pas uniquement) exigent un niveau minimum d'anglais.

Maintenant je ne dénigre pas le travail effectué et le courage de ceux qui bossent dessus, et je ne cherche pas du tout à m'attirer les foudres de ces derniers :king:. J'espère juste que mon point de vue sera compris.

Ton point de vue est compris (en ce qui me concerne, en tout cas), mais j'espère en retour que tu comprendra l'idée sous-jacente qui a incité à effectuer la traduction:

Citation:

---

Il est déjà assez "pénible" de s'initier à quelque chose sans que la langue utilisée ne présente une barrière supplémentaire

---

Bien sûr, "dans un monde parfait", tous ceux qui voudraient s'initier au C++ auraient des connaissances en anglais suffisantes pour, en tout cas, comprendre "la majeure partie" du bouquin en VO, et à ce moment là, l'idée même d'en profiter pour améliorer sa maîtrise de l'anglais devient intéressante.

Cependant, le fait d'utiliser un livre à vocation technique pour améliorer sa compréhension d'une langue n'est envisageable que si on dispose déjà au préalable des connaissances suffisante pour comprendre ce dont traite le bouquin...

Et dans cette histoire, les grands oubliés sont donc "ceux qui ne connaissent pas la langue et qui n'ont pas les connaissances technique" :P

Et voilà... Tout le monde ne maîtrise pas suffisemment l'anglais pour envisager de lire un bouquin qui, en gros, doit atteindre plusieurs centaines de pages, et, si on ne comprend déjà pas ce qu'on lit, on aura d'autant plus de mal à comprendre les explications données par ce qu'on lit :P... Le découragement viendra vite dans de telles circonstances:roll:

C'est la raison pour laquelle le fait de disposer d'un bouquin à vocation technique dans sa langue maternelle est de nature à fournir une aide considérable à toute personne intéressée par le fait de s'initier (ou de se perfectionner) dans la technique traitée :D

CQFD

Ben tant qu'a faire, en attendant de mettre la main sur l'inaccessible "Guide des solution", Je vais vous embêter ici avez les exercice :lol:

Bon alors Chapitre 3, Exo 26 : Je mets l'énoncé ici

Citation:

---

Define an array of int. Take the starting address of that array and use static_cast to convert it into an void*. Write a function that takes a void*, a number (indicating a number of bytes), and a value (indicating the value to which each byte should be set) as arguments. The function should set each byte in the specified range to the specified value. Try out the function on your array of int.

---

En français aussi :

Citation:

---

Définissez un tableau d'ints Prenez l'adresse du premier élément du tableau et utilisez l'opérateur static_cast pour la convertir en void*. Ecrivez une fonction qui accepte un void*, un nombre (qui indiquera un nombre d'octets), et une valeur (qui indiquera la valeur avec laquelle chaque octet sera affecté) en paramètres. La fonction devra affecter chaque octet dans le domaine spécifié à la valeur reçue. Essayez votre fonction sur votre tableau d'ints.

---

Ben c'est clair la je ne comprend même pas l'énoncé, surtout ce "nombre" sensé indiquer "un nombre d'octets" est-ce que c'est la longueur de ce que pointe void* ou bien un octet parmi d'autre dans ce que pointe void* a qui on assignera la variable "valeur" qui sera donc de type char?

C'est la taille en octet...

Il n'y a rien à faire, il faut toujours disposer de la taille d'un tableau ;):roll:

Oui je sais bien pour la taille d'un tableau, mais si c'est comme ça on affectera la même valeur octet par octet a tout le tableau? Je suis pas vraiment convaincu, je voyais plutôt ça du genre, affecte l'octet i du tableau avec la valeur x.

En suivant ton idée la fonction ressemblerai a ça :

Code:

---

1 2 3 4 5 6

void f(void* tab, int lon, char val) { char *t = static_cast<char*>(tab); for (int i = 0; i < lon; i++) t[i] = val; }

---

J'ai bon?

Quoi qu'il en soit je trouve l'exo vraiment mal formulé (et non mal traduit attention ;) )

Et que penser, pour la partie

Citation:

---

The function should set each byte in the specified range to the specified value.

---

d'une traduction sous la forme de

Citation:

---

La fonction va initialiser chaque octet dans la limite spécifiée à la valeur spécifiée

---

qui a l'avantage, outre d'être plus "juste", de mieux préciser les choses :question:

50% de la réponse, et plus, se trouvent généralement dans la question, si elle est bien posée ;):D

Et donc, oui, la fonction présentée répond à cette question.

Je voudrais juste voir la préparation du travail et son appel pour remplir l'ensemble d'un tableau, mettons, de 7 entiers :roll:

On comprends peut-être mal la question aussi parce que l'utilité d'une telle fonction ne saute pas aux yeux. Quiconque a lu quelque part qu'en C++ que le cast en void est mal, et lit aujourd'hui l'énoncé, se demande s'il a effectivement bien compris ce qu'on lui demande.

Citation:

---

Envoyé par disturbedID

Code:

---

1 2 3 4 5 6

void f(void* tab, int lon, char val) { char *t = static_cast<char*>(tab); for (int i = 0; i < lon; i++) t[i] = val; }

---

---

Pour simplifier ton code, il y a moyen d'éviter l'utilisation d'un indice pour accéder aux cases de t.

En effet, en faisant :

Code:

---

*(t+i) = val;

---

Mais bon ce n'est qu'un détail.

Sinon, void* en C++, c'est pas recommandé...

Je suis un peu surpris par cet exercice, et surtout par le fait qu'il apparaisse au chapitre 3, qui, à moins que les chapitres soient énormes, est quand même le début du bouquin...

A part ça, traduire le mot byte par octet peut enduire en erreur, bien que je n'ai pas de meilleure traduction à proposer. En effet, octet est connoté étymologiquement avec le nombre 8, alors qu'un byte peut avoir un autre nombre de bits.

Citation:

---

Envoyé par Alp

En effet, en faisant :

Code:

---

*(t+i) = val;

---

---

Non, en parlant d'indices, je pensais plutôt à une solution sans utiliser de variables intermédiaires (int i ou autres). Mais comme il s'agit d'un exercice je vais pas montrer la solution pour le moment.

Citation:

---

Envoyé par JolyLoic

A part ça, traduire le mot byte par octet peut enduire en erreur, bien que je n'ai pas de meilleure traduction à proposer. En effet, octet est connoté étymologiquement avec le nombre 8, alors qu'un byte peut avoir un autre nombre de bits.

---

Je n'avais pas "percuté" dessus, mais +1 :king:

Citation:

---

Envoyé par NiamorH

Non, en parlant d'indices, je pensais plutôt à une solution sans utiliser de variables intermédiaires (int i ou autres). Mais comme il s'agit d'un exercice je vais pas montrer la solution pour le moment.

---

Il y a deux choses à ne sans doute pas perdre de vue pour ta solution:

1. L'optimisation prématurée est la pire des choses
2. Le fait de partir sur des hypothèse fausses dues à un comportement remarqué sur un système donné mais basé sur des comportement non spécifiés ou indéfinis est le meilleur moyen de "faire tout foirer" si les conditions changent

C'est la raison pour laquelle j'aimerais voir l'appel de cette fonction lors de l'utilisation d'un tableau de, mettons, 7 entiers ;)

Houla beaucoup d'éléments neuf depuis hier.
Mais commençons tout de suite par

Citation:

---

Envoyé par koala01

j'aimerais voir l'appel de cette fonction lors de l'utilisation d'un tableau de, mettons, 7 entiers

---

tout d'suit 'mssieu :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

const int taille = 7;   int main(int argc, char* argv[]) { int tab[taille]; void* pt = static_cast<void*>(tab); f(pt, taille*sizeof(int), 0); for (int i = 0; i < taille; i++)//En plus, juste pour vérifier. cout << *(tab+i) << " "; cout << endl; }

---

Citation:

---

Envoyé par koala01

Et que penser, pour la partie
Citation:
The function should set each byte in the specified range to the specified value.
d'une traduction sous la forme de
Citation:
La fonction va initialiser chaque octet dans la limite spécifiée à la valeur spécifiée
qui a l'avantage, outre d'être plus "juste", de mieux préciser les choses

---

Oui c'est ça aussi qui me gêneait, surtout ma méconnaissance du mot "range" que je croyais l'équivalent de "rang" en français. Peut être que "tranche" a la place de "limite" aurait été plus clair aussi?

Citation:

---

Envoyé par JolyLoic

A part ça, traduire le mot byte par octet peut enduire en erreur, bien que je n'ai pas de meilleure traduction à proposer. En effet, octet est connoté étymologiquement avec le nombre 8, alors qu'un byte peut avoir un autre nombre de bits.

---

Mot mémoire?

Citation:

---

Envoyé par NiamorH

Citation:
Envoyé par Alp Voir le message
En effet, en faisant :
Code :

*(t+i) = val;

Non, en parlant d'indices, je pensais plutôt à une solution sans utiliser de variables intermédiaires (int i ou autres). Mais comme il s'agit d'un exercice je vais pas montrer la solution pour le moment.

---

Sans utiliser d'index (i entre autre) du tout je vois pas. Si tu parles plutôt de ne pas utiliser d'index i lors de l'affectation je vois ça :

Code:

---

1 2	for (int i = 0; i < lon; i++,t++) *t = val;

---

Mais bon c'est un peu ce noyer dans un verre d'eau :D

Pas loin, effectivement c'est à base d'incrémentation du pointeur. (On ne se sert pas du pointeur ou de la taille du tableau plus loin dans la fonction donc c'est Ok) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

const int taille = 7; void f(void* tab, int lon, char val) { char *t = static_cast<char*>(tab); while(lon--) { *t = val; ++t; } } int main(int argc, char* argv[]) { int tab[taille]; void* pt = static_cast<void*>(tab); f(pt, taille*sizeof(*tab), 0); return 0; }

---

Dans ce cas là, je ne crois pas faire de comportement indéfini. Cette écriture est tout de même moins lourde qu'un for, pas tout à fait mais presque aussi lisible mais en tout cas plus simple à écrire. De plus, elle économise le recours à une variable temporaire. Alors quand on peut se le permettre (c'est pas toujours le cas) autant le faire.

Mais ta solution est très bien. J'aurais simplement fait mon sizeof sur la premiere case pointée (pas sur le pointeur!) afin de ne pas avoir de soucis lors du changement de type du tableau.

Early optimisation is the root of all evil, je le connais aussi ;), mais ce dicton ne prend pas tout son sens ici mais plutôt dans les optimisations qui touchent à la conception.

Citation:

---

Envoyé par disturbedID

Houla beaucoup d'éléments neuf depuis hier.
Mais commençons tout de suite par

tout d'suit 'mssieu :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

const int taille = 7;   int main(int argc, char* argv[]) { int tab[taille]; void* pt = static_cast<void*>(tab); f(pt, taille*sizeof(int), 0); for (int i = 0; i < taille; i++)//En plus, juste pour vérifier. cout << *(tab+i) << " "; cout << endl; }

---

---

Ok... au moins, tu n'as pas pris le risque de faire une hypothèse sur la taille d'un entier... C'était la grosse erreur à éviter ;)

Citation:

---

Oui c'est ça aussi qui me gêneait, surtout ma méconnaissance du mot "range" que je croyais l'équivalent de "rang" en français. Peut être que "tranche" a la place de "limite" aurait été plus clair aussi?

---

Aussi...

Citation:

---

Mot mémoire?

---

Non, cela ne veut strictement rien dire :P

Un byte est défini comme étant la plus petite unité allouable, et doit au minimum être de taille suffisante pour représenter tous les caractères.

L'astuce, c'est qu'il existe des architectures basées sur des "bytes" de 6 bits, et que l'on ne peut donc pas limiter la traduction à celles qui utilisent des bytes de 8 :D

Citation:

---

Sans utiliser d'index (i entre autre) du tout je vois pas. Si tu parles plutôt de ne pas utiliser d'index i lors de l'affectation je vois ça :

Code:

---

1 2	for (int i = 0; i < lon; i++,t++) *t = val;

---

---

Personnellement, je n'apprécie que médiocrement l'idée d'incrémenter autre chose que le compteur dans une boucle pour... Je trouve que cela nuit à la lisibilité, sans apporter grand chose.

Mais ce n'est là qu'un avis strictement personnel ;)

Citation:

---

Envoyé par NiamorH

Pas loin, effectivement c'est à base d'incrémentation du pointeur. (On ne se sert pas du pointeur ou de la taille du tableau plus loin dans la fonction donc c'est Ok) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

const int taille = 7; void f(void* tab, int lon, char val) { char *t = static_cast<char*>(tab); while(lon--) { *t = val; ++t; } } int main(int argc, char* argv[]) { int tab[taille]; void* pt = static_cast<void*>(tab); f(pt, taille*sizeof(*tab), 0); return 0; }

---

---

Les trois types de boucles étant intervertibles à loisir, sous réserve d'adaptations éventuelles, cela revient strictement au même...

Je trouve, mais ce n'est là aussi qu'un avis perso, que, tant qu'à faire, il est préférable d'utiliser une boucle itérative ("pour") chaque fois que c'est faisable...

Finalement, une boucle itérative n'est le plus souvent qu'une boucle "tant que" pour laquelle on dispose d'un compteur sur lequel sera effectué le test... Et il se fait que dans le cas du problème exposé, on dispose de tout ce qui peut permettre de mettre un compteur en place ;)

Le résultat au niveau de l'exécutable sera, en outre, relativement semblable... donc :roll:
Dans ce cas là, je ne crois pas faire de comportement indéfini. Cette écriture est tout de même moins lourde qu'un for, pas tout à fait mais presque aussi lisible mais en tout cas plus simple à écrire. De plus, elle économise le recours à une variable temporaire. Alors quand on peut se le permettre (c'est pas toujours le cas) autant le faire.

Citation:

---

Mais ta solution est très bien. J'aurais simplement fait mon sizeof sur la premiere case pointée (pas sur le pointeur!) afin de ne pas avoir de soucis lors du changement de type du tableau.

---

En tant qu'adaptation de l'énoncé, oui...

Mais étant donné qu'ici l'énoncé parle clairement d'utiliser un int... Le mieux est l'ennemi du bien :D... du coup, est-ce vraiment nécessaire :question:

Citation:

---

Early optimisation is the root of all evil, je le connais aussi ;), mais ce dicton ne prend pas tout son sens ici mais plutôt dans les optimisations qui touchent à la conception.

---

C'est bien de cela que je parle...

Mais il touche aussi à toutes les optimisations qui touchent à la manière d'écrire un code.

Le deuxième principe du programmeur devrait toujours rester de veiller à écrire un code source le plus lisible possible, car

Citation:

---

Un code source est écrit une fois, lu souvent

---

Il vaut mieux perdre une fois 1 seconde à l'écriture, et gagner 1 seconde à chaque lecture que l'inverse... Cela optimise le temps du développeur :roll:

Moi j'aime bien la solution de NiamorH, ça fait très ASM 8-)
Et on peux encore la faire tenir sur une ligne cette fonction, avec :

Code:

---

1 2 3 4

void f(void* t, int l, char v) { while(l--) *(static_cast<char*>(t)+l) = v; }

---

de quoi donner des boutons a Koala01 :D

Citation:

---

Envoyé par koala01

Citation:

---

Envoyé par disturbedID

Mot mémoire?

---

Non, cela ne veut strictement rien dire :P

---

En tout cas ce n'est pas de l'avis du Laboratoire Lorrain de Recherche en Informatique et ses Applications
Plus sérieusement je me souvient de ce terme dans les cours du Motorola 68000 ou mot désignait plutôt un emplacement de 16bits.

Mais moi je trouve que ça convient bien comme traduction, car le mot est le plus petit ensemble d'une phrases (comme le byte) composés de lettres (de bits) mais qui peut être de longueur variable (composé de plus ou moins de bits).

byte ~= mot? J'en parlerais ce soir a Robert :aie:

Citation:

---

Envoyé par disturbedID

Moi j'aime bien la solution de NiamorH, ça fait très ASM 8-)
Et on peux encore la faire tenir sur une ligne cette fonction, avec :

Code:

---

1 2 3 4

void f(void* t, int l, char v) { while(l--) *(static_cast<char*>(t)+l) = v; }

---

de quoi donner des boutons a Koala01 :D

---

Arrghh... tu veux vraiment m'assassiner :question: :evilred::kill:

Citation:

---

En tout cas ce n'est pas de l'avis du Laboratoire Lorrain de Recherche en Informatique et ses Applications
Plus sérieusement je me souvient de ce terme dans les cours du Motorola 68000 ou mot désignait plutôt un emplacement de 16bits.

---

La mémoire, d'un point de vue purement électronique, ce n'est qu'une série d'interrupteurs qui sont mis en position "on" ou "off", et qui sont capables de garder leur état...

Du point de vue du développeur, c'est le regroupement de plusieurs interrupteurs auxquels on peut accéder si on connait l'adresse...

Il n'y a donc aucune corrélation possible entre un byte et le terme mémoire, à moins de parler d'une adresse mémoire ;) (et encore, ce serait plutôt de parler du contenu d'une adresse mémoire

Citation:

---

Mais moi je trouve que ça convient bien comme traduction, car le mot est le plus petit ensemble d'une phrases (comme le byte) composés de lettres (de bits) mais qui peut être de longueur variable (composé de plus ou moins de bits).

byte ~= mot? J'en parlerais ce soir a Robert :aie:

---

Sauf erreur, le terme WORD représente déjà un groupement de byte, un peut comme un mot est un groupement de caractères :P

Bien que je ne puisse pas l'affirmer avec certitude, il me semble que sur de nombreuses implémentation, 1 WORD= 2 bytes, et, qu'en plus, ce n'est défini que pour windows :P

Décidément, à moins de disposer d'un terme générique identique, il me semble que le mieux reste de parler de byte, même en francais :roll:

J'avais pas pensé a poser la question avant mais, j'ai remarqué qu'on préfère toujours les expression du type

Code:

---

*(tableau+index)

---

que

Code:

---

tableau[index]

---

c'est pas la même chose?

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 ;)

Citation:

---

Envoyé par disturbedID

Et on peux encore la faire tenir sur une ligne

---

La, pour le coup, c'est illisible :lol:

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?

Citation:

---

Envoyé par Alp

En effet, en faisant :

Code:

---

*(t+i) = val;

---

Mais bon ce n'est qu'un détail.

---

Bizarre j'ai toujours cru que *(t+i) était plus rapide?
*************************************************
@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 subliminal

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.

---

Je peux vous dire que si j'avais une MasterCard y a bien longtemps que j'aurai craqué :aie:

exemple d'exercices le n°1 du chapitre 4 :

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.

---

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.

ou encore cette exercice complètement inutile :

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

---

sans commentaire :roll:
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. :(

Citation:

---

Envoyé par disturbedID

Non on incrémente pas le pointeur on fait l'addition avec "lon". Mais bon c'est tellement illisible :mouarf:

---

Ah oui exact.

Citation:

---

Envoyé par disturbedID

en plus d'être sûrement moins rapide vu qu'on fait un cast a chaque fois

---

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

Citation:

---

Envoyé par disturbedID

Oui c'est ça aussi qui me gêneait, surtout ma méconnaissance du mot "range" que je croyais l'équivalent de "rang" en français. Peut être que "tranche" a la place de "limite" aurait été plus clair aussi?

---

Range, je traduirai par "intervalle".
L'équivalent de tranche serait plutôt qquelque chose comme "slice"

Citation:

---

Envoyé par NiamorH

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.
Par contre tu fais une addition et moi une simple incrémentation.

---

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

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

Citation:

---

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.

---

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'execution

Code:

---

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

*** glibc detected *** ./exo22: free(): invalid pointer: 0xb7e2a164 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7d4cd65] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7d50800] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7f15d81] /usr/lib/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1d)[0xb7ef190d] /usr/lib/libstdc++.so.6(_ZNSsD1Ev+0x51)[0xb7ef37b1] ./exo22[0x8048ec4] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7cf9050] ./exo22(__gxx_personality_v0+0x41)[0x8048a61] ======= Memory map: ======== 08048000-0804a000 r-xp 00000000 16:43 2310435 /home/riad/Programmation/cpp/testString/exo22 0804a000-0804b000 rw-p 00001000 16:43 2310435 /home/riad/Programmation/cpp/testString/exo22 0804b000-0806c000 rw-p 0804b000 00:00 0 [heap] b7b00000-b7b21000 rw-p b7b00000 00:00 0 b7b21000-b7c00000 ---p b7b21000 00:00 0 b7ce2000-b7ce3000 rw-p b7ce2000 00:00 0 b7ce3000-b7e27000 r-xp 00000000 16:42 621387 /lib/tls/i686/cmov/libc-2.6.1.so b7e27000-b7e28000 r--p 00143000 16:42 621387 /lib/tls/i686/cmov/libc-2.6.1.so b7e28000-b7e2a000 rw-p 00144000 16:42 621387 /lib/tls/i686/cmov/libc-2.6.1.so b7e2a000-b7e2d000 rw-p b7e2a000 00:00 0 b7e2d000-b7e37000 r-xp 00000000 16:42 457878 /lib/libgcc_s.so.1 b7e37000-b7e38000 rw-p 0000a000 16:42 457878 /lib/libgcc_s.so.1 b7e38000-b7e39000 rw-p b7e38000 00:00 0 b7e39000-b7e5c000 r-xp 00000000 16:42 621391 /lib/tls/i686/cmov/libm-2.6.1.so b7e5c000-b7e5e000 rw-p 00023000 16:42 621391 /lib/tls/i686/cmov/libm-2.6.1.so b7e5e000-b7f46000 r-xp 00000000 16:42 1766046 /usr/lib/libstdc++.so.6.0.9 b7f46000-b7f49000 r--p 000e8000 16:42 1766046 /usr/lib/libstdc++.so.6.0.9 b7f49000-b7f4b000 rw-p 000eb000 16:42 1766046 /usr/lib/libstdc++.so.6.0.9 b7f4b000-b7f51000 rw-p b7f4b000 00:00 0 b7f64000-b7f67000 rw-p b7f64000 00:00 0 b7f67000-b7f81000 r-xp 00000000 16:42 1520740 /lib/ld-2.6.1.so b7f81000-b7f83000 rw-p 00019000 16:42 1520740 /lib/ld-2.6.1.so bff96000-bffac000 rw-p bff96000 00:00 0 [stack] ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso] Abandon (core dumped)

---

et dès que je commente le delete tout marche au poile.
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é :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

int main(int argc, char* argv[]) { ifstream in("main.cpp"); Stash tabDyn; tabDyn.initialize(sizeof(string*));   //Fichier->Stash string line; while(getline(in, line)) tabDyn.add(new string(line));   //Affichage du fichier string *ligne; for(int i = 0; i < tabDyn.count(); i++) { ligne = (string*) tabDyn.fetch(i); cout << *ligne << endl; delete ligne; } tabDyn.cleanup();; }

---

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.

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 add

Code:

---

int Stash::add(const void* element)

---

prend 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:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

void main(int argc, char* argv[]) { ifstream in("main.cpp"); Stash tabDyn; tabDyn.initialize(sizeof(string*));   //Fichier->Stash string line; while(getline(in, line)) { string *tempLine = new string(line); tabDyn.add(&tempLine); }   //Affichage du fichier string *ligne; for(int i = 0; i < tabDyn.count(); i++) { ligne = *((string**) tabDyn.fetch(i)); cout << *ligne << endl; delete ligne; } tabDyn.cleanup();; }

---

Donc pour répondre a miles, non tabDyn.cleanup() ne fais pas tout, car, et ça tu ne pouvais pas le savoir :

Code:

---

1 2 3 4 5 6

void Stash::cleanup() { if(storage != 0) { //cout << "freeing storage" << endl; delete []storage; } } ///:~

---

Elle ne fais que supprimer le tableau de char qui stockait les éléments.

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 :)