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: