Discussion :

[disturbedID]

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 )) nul chances de payer par MasterCard, Amercian Express, Paypal, ou je ne sais quelle bourgeoiserie du monde riche.


Merci.

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

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

[disturbedID]

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.

[hpfx]

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 )

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

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.

[NiamorH]

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 . J'espère juste que mon point de vue sera compris.

[koala01]

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:

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"

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 ... Le découragement viendra vite dans de telles circonstances

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

CQFD

[disturbedID]

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

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

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 :

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?

[koala01]

C'est la taille en octet...

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

[disturbedID]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 )

[koala01]

Et que penser, pour la partie

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

d'une traduction sous la forme de

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

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

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

[NiamorH]

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.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Alp]

En effet, en faisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

*(t+i) = val;

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

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

[JolyLoic]

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.

[NiamorH]

En effet, en faisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[koala01]

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

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

[disturbedID]

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

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

tout d'suit 'mssieu :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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?

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

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

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

[koala01]

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

tout d'suit 'mssieu :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

Mot mémoire?

Non, cela ne veut strictement rien dire

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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 :

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

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 ... du coup, est-ce vraiment nécessaire

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

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

[disturbedID]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Mot mémoire?

Non, cela ne veut strictement rien dire

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

[koala01]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Arrghh... tu veux vraiment m'assassiner

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

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

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

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

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