Bonjour,
Je recherche le titre d'un livre sur le langage C qui a du être publié
vers 1985. Le livre était spiralé avec, si mes souvenir sont bons, une
couverture bleue.
Bonjour,
Je recherche le titre d'un livre sur le langage C qui a du être publié
vers 1985. Le livre était spiralé avec, si mes souvenir sont bons, une
couverture bleue.
Bonjour,
Je recherche le titre d'un livre sur le langage C qui a du être publié
vers 1985. Le livre était spiralé avec, si mes souvenir sont bons, une
couverture bleue.
Je pense qu'il s'agit de
Donald ALCOCK, /Illustrationg C (ANSI, ISO C version)/, CUP.
Le livre possède une couverture très souple bleu ciel et en effet le livre est
spiralé. Par contre l'année d'édition est 1992.
Un livre qui dans son titre se réfère à la Norme ne peut être un mauvais
ouvrage. Le dit-ouvrage est assez original en ce que
1°) la typographie est calligraphique (mais sobre sauf les caractères capitales
style 3D).
2°) Chaque page ou double page est un chapitre.
3°) Le livre est tissé de petits dessins et diagrammes faits à la main avec
parfois un petit trait d'humour, par exemple l'auteur dessine un petit cafard
dans un encart qui contient un programme incorrect; ces petits dessins sont
souvent des bulles de texte vers du texte. Aujourd'hui (et sans doute à
l'époque), on peut faire ça avec du pstricks et je m'étonne d'ailleurs que cette
possibilité
n'ait pas été vraiment utilisée dans les ouvrages à caractère didactique. Par
ailleurs, on trouve dans l'ouvrage d'Alcock des petits dessins pour analyser
l'état de la mémoire et en
particulier les liaisons définies par des pointeurs, ce qui n'a rien de très
original. Là encore pstricks voire un genre ascii-art comme -ed- aime utiliser
convient parfaitement.
Donc, cet ouvrage est assez unique dans son genre. Avec le recul, je me rends
compte que ses explications sont souvent rigoureuses et justes. Hélas, je trouve
l'ouvrage ne tient pas ses promesses du point de vue de la solidité des
explications, au demeurant il sous-exploite les possibilités en matière de
pédagogie graphique. Et comme beaucoup d'ouvrages sur le C, il dispense des
explications abstraites, pour donner une image, c'est un peu comme si en POO on
travaillait avec des classes sans jamais voir aucune instance, ou si tu faisais
de la géométrie sans faire aucun dessin (ça s'est fait, cf. Bourbaki).
Et justement comme j'aime bien me
faire comprendre, voici un exemple de ses abstractions. Dans le chapitre
"Déclarations" (autre défaut de l'ouvrage : pas de vraie numérotation des
chapitres ni des paragraphes ce qui a pour conséquence une mauvaise navigation)
page 37, je lis :
Each declaration applies as far as the end of the current file (the "scope" of
the declaration). But in a block of program within this scope, a contradictory
declaration may "hide" the original (the visibility). Scope and visibility are
further described below.
Quand j'ai lu ça pour la première fois, et que j'avais 6 mois d'apprentissage du
C derrière moi, je suis resté sur ma faim et j'ai d'ailleurs écrit dans la marge
: "pas très clair". Et en relisant l'extrait, c'est en effet peu clair pour
celui qui ne connait pas car le lecteur peut partir dans multiples directions.
D'abord les explications données apparaissent en début d'ouvrage (page 37 sur
214) et donc le lecteur n'est pas censé être familier avec le jargon : block,
scope, visibility. Mais la plus grosse erreur que commet l'auteur c'est de
n'illustrer son propose d'aucun exemple (le texte que j'ai cité ci-dessus
s'arrête là où j'ai cité, il passe ensuite à un autre paragraphe).
Ensuite, la définition donnée de "scope" est vague (c'est une définition comme
ça "en passant") et incorrecte. Ensuite, le vocabulaire employé ("hide") est
totalement incompréhensible (noter que "hide" a parfois un sens moral de
dissimulation et noter que "hide" est employé ici à l'actif et non au passif :
"être caché par" ce qui bien sûr peut surprendre parce quand on a jamais vu
cela, on ne peut imaginer qu'une declaration a un rôle actif). A "contradictory
declaration" est une mauvaise expression car elle laisserait en fait penser à
une erreur (la présence d'une "contradiction" est la plupart du temps le signe
d'une erreur ou d'une impossibilité). Pareil, pour "visibility", la définition
n'est pas précise, elle est donnée comme ça, "en passant" et l'auteur semble
opposer "scope" et "visibility" ce qui est une erreur, cf. la Norme qui dit :
the identifier is visible (i.e., can be used) only within a region of program
text called its scope.
Et la fin de l'extrait que j'ai cité ci-dessus, c'est vraiment le ponpon. Je
traduis la situation : "je vous ai donné une explication complètement
incompréhensible mais je vais vous expliquer ça bien plus loin seulement je vous
dis pas où". Et en effet, j'ai beau chercher "plus bas", je ne trouve aucune
explication à ce propos. Heureusement, l'auteur mentionne "scope" dans l'index
ce qui renvoie à la page 74 mais hélas, les explications données sont à nouveau
assez médiocres (encore une fois, parce qu'il parle de manière abstraite).
L'auteur est coutumier de ce genre d'échappatoire car toujours page 37 mais
quelques lignes plus loin il nous dit :
"The difference between _declaration_ and _definition_ are semantic rather than
syntatic. The differences are, in fact, more complicated than suggested above,
and are further described in chapter 5"
Je peux vous dire que lorsque j'ai lu ça, je n'ai pas du tout apprécié d'être
renvoyé ailleurs. Quelques remarques :
1°) "The difference between _declaration_ and _definition_ are semantic rather
than syntatic." Je pense que c'est discutable. Et de toute façon, mon point de
vue est que, dans un premier tant, le débutant s'en fout complètement de ce
genre de glose jargonnesque et s'y référer ne fait que rendre encore plus
difficile l'apprentissage (ça oblige à apprendre la métalangue et la langue).
2°) "more complicated than suggested above" : ça par contre, je trouve ça bien,
trop souvent les auteurs omettent de signaler qu'ils ne donnent qu'une vue
partielle et qui va mettre du temps à être complète. Mais bien sûr, il ne faut
pas que l'auteur en reste là.
3°) Au moins, il précise _où_ se fait la référence. Mais c'est assez vague, ce
qu'il appelle le chapitre 5 est une suite de leçons assez hétérogènes et dont
aucun des titres ne fait mention de "déclaration" ou "definition".
Bref, un ouvrage ayant une approche formelle peu classique mais qui tombe dans
les mêmes errements et les mêmes approximations que la majorité des ouvrages à
facture plus traditionnelle.
Sinon, mon exemplaire n'est pas à vendre (pour info, je l'avais trouvé
d'occasion via amazon.com en février 2006 pour 30 USD hors frais de port).
Je pense qu'il s'agit de
Donald ALCOCK, /Illustrationg C (ANSI, ISO C version)/, CUP.
Le livre possède une couverture très souple bleu ciel et en effet le livre est
spiralé. Par contre l'année d'édition est 1992.
Un livre qui dans son titre se réfère à la Norme ne peut être un mauvais
ouvrage. Le dit-ouvrage est assez original en ce que
1°) la typographie est calligraphique (mais sobre sauf les caractères capitales
style 3D).
2°) Chaque page ou double page est un chapitre.
3°) Le livre est tissé de petits dessins et diagrammes faits à la main avec
parfois un petit trait d'humour, par exemple l'auteur dessine un petit cafard
dans un encart qui contient un programme incorrect; ces petits dessins sont
souvent des bulles de texte vers du texte. Aujourd'hui (et sans doute à
l'époque), on peut faire ça avec du pstricks et je m'étonne d'ailleurs que cette
possibilité
n'ait pas été vraiment utilisée dans les ouvrages à caractère didactique. Par
ailleurs, on trouve dans l'ouvrage d'Alcock des petits dessins pour analyser
l'état de la mémoire et en
particulier les liaisons définies par des pointeurs, ce qui n'a rien de très
original. Là encore pstricks voire un genre ascii-art comme -ed- aime utiliser
convient parfaitement.
Donc, cet ouvrage est assez unique dans son genre. Avec le recul, je me rends
compte que ses explications sont souvent rigoureuses et justes. Hélas, je trouve
l'ouvrage ne tient pas ses promesses du point de vue de la solidité des
explications, au demeurant il sous-exploite les possibilités en matière de
pédagogie graphique. Et comme beaucoup d'ouvrages sur le C, il dispense des
explications abstraites, pour donner une image, c'est un peu comme si en POO on
travaillait avec des classes sans jamais voir aucune instance, ou si tu faisais
de la géométrie sans faire aucun dessin (ça s'est fait, cf. Bourbaki).
Et justement comme j'aime bien me
faire comprendre, voici un exemple de ses abstractions. Dans le chapitre
"Déclarations" (autre défaut de l'ouvrage : pas de vraie numérotation des
chapitres ni des paragraphes ce qui a pour conséquence une mauvaise navigation)
page 37, je lis :
Each declaration applies as far as the end of the current file (the "scope" of
the declaration). But in a block of program within this scope, a contradictory
declaration may "hide" the original (the visibility). Scope and visibility are
further described below.
Quand j'ai lu ça pour la première fois, et que j'avais 6 mois d'apprentissage du
C derrière moi, je suis resté sur ma faim et j'ai d'ailleurs écrit dans la marge
: "pas très clair". Et en relisant l'extrait, c'est en effet peu clair pour
celui qui ne connait pas car le lecteur peut partir dans multiples directions.
D'abord les explications données apparaissent en début d'ouvrage (page 37 sur
214) et donc le lecteur n'est pas censé être familier avec le jargon : block,
scope, visibility. Mais la plus grosse erreur que commet l'auteur c'est de
n'illustrer son propose d'aucun exemple (le texte que j'ai cité ci-dessus
s'arrête là où j'ai cité, il passe ensuite à un autre paragraphe).
Ensuite, la définition donnée de "scope" est vague (c'est une définition comme
ça "en passant") et incorrecte. Ensuite, le vocabulaire employé ("hide") est
totalement incompréhensible (noter que "hide" a parfois un sens moral de
dissimulation et noter que "hide" est employé ici à l'actif et non au passif :
"être caché par" ce qui bien sûr peut surprendre parce quand on a jamais vu
cela, on ne peut imaginer qu'une declaration a un rôle actif). A "contradictory
declaration" est une mauvaise expression car elle laisserait en fait penser à
une erreur (la présence d'une "contradiction" est la plupart du temps le signe
d'une erreur ou d'une impossibilité). Pareil, pour "visibility", la définition
n'est pas précise, elle est donnée comme ça, "en passant" et l'auteur semble
opposer "scope" et "visibility" ce qui est une erreur, cf. la Norme qui dit :
the identifier is visible (i.e., can be used) only within a region of program
text called its scope.
Et la fin de l'extrait que j'ai cité ci-dessus, c'est vraiment le ponpon. Je
traduis la situation : "je vous ai donné une explication complètement
incompréhensible mais je vais vous expliquer ça bien plus loin seulement je vous
dis pas où". Et en effet, j'ai beau chercher "plus bas", je ne trouve aucune
explication à ce propos. Heureusement, l'auteur mentionne "scope" dans l'index
ce qui renvoie à la page 74 mais hélas, les explications données sont à nouveau
assez médiocres (encore une fois, parce qu'il parle de manière abstraite).
L'auteur est coutumier de ce genre d'échappatoire car toujours page 37 mais
quelques lignes plus loin il nous dit :
"The difference between _declaration_ and _definition_ are semantic rather than
syntatic. The differences are, in fact, more complicated than suggested above,
and are further described in chapter 5"
Je peux vous dire que lorsque j'ai lu ça, je n'ai pas du tout apprécié d'être
renvoyé ailleurs. Quelques remarques :
1°) "The difference between _declaration_ and _definition_ are semantic rather
than syntatic." Je pense que c'est discutable. Et de toute façon, mon point de
vue est que, dans un premier tant, le débutant s'en fout complètement de ce
genre de glose jargonnesque et s'y référer ne fait que rendre encore plus
difficile l'apprentissage (ça oblige à apprendre la métalangue et la langue).
2°) "more complicated than suggested above" : ça par contre, je trouve ça bien,
trop souvent les auteurs omettent de signaler qu'ils ne donnent qu'une vue
partielle et qui va mettre du temps à être complète. Mais bien sûr, il ne faut
pas que l'auteur en reste là.
3°) Au moins, il précise _où_ se fait la référence. Mais c'est assez vague, ce
qu'il appelle le chapitre 5 est une suite de leçons assez hétérogènes et dont
aucun des titres ne fait mention de "déclaration" ou "definition".
Bref, un ouvrage ayant une approche formelle peu classique mais qui tombe dans
les mêmes errements et les mêmes approximations que la majorité des ouvrages à
facture plus traditionnelle.
Sinon, mon exemplaire n'est pas à vendre (pour info, je l'avais trouvé
d'occasion via amazon.com en février 2006 pour 30 USD hors frais de port).
Je pense qu'il s'agit de
Donald ALCOCK, /Illustrationg C (ANSI, ISO C version)/, CUP.
Le livre possède une couverture très souple bleu ciel et en effet le livre est
spiralé. Par contre l'année d'édition est 1992.
Un livre qui dans son titre se réfère à la Norme ne peut être un mauvais
ouvrage. Le dit-ouvrage est assez original en ce que
1°) la typographie est calligraphique (mais sobre sauf les caractères capitales
style 3D).
2°) Chaque page ou double page est un chapitre.
3°) Le livre est tissé de petits dessins et diagrammes faits à la main avec
parfois un petit trait d'humour, par exemple l'auteur dessine un petit cafard
dans un encart qui contient un programme incorrect; ces petits dessins sont
souvent des bulles de texte vers du texte. Aujourd'hui (et sans doute à
l'époque), on peut faire ça avec du pstricks et je m'étonne d'ailleurs que cette
possibilité
n'ait pas été vraiment utilisée dans les ouvrages à caractère didactique. Par
ailleurs, on trouve dans l'ouvrage d'Alcock des petits dessins pour analyser
l'état de la mémoire et en
particulier les liaisons définies par des pointeurs, ce qui n'a rien de très
original. Là encore pstricks voire un genre ascii-art comme -ed- aime utiliser
convient parfaitement.
Donc, cet ouvrage est assez unique dans son genre. Avec le recul, je me rends
compte que ses explications sont souvent rigoureuses et justes. Hélas, je trouve
l'ouvrage ne tient pas ses promesses du point de vue de la solidité des
explications, au demeurant il sous-exploite les possibilités en matière de
pédagogie graphique. Et comme beaucoup d'ouvrages sur le C, il dispense des
explications abstraites, pour donner une image, c'est un peu comme si en POO on
travaillait avec des classes sans jamais voir aucune instance, ou si tu faisais
de la géométrie sans faire aucun dessin (ça s'est fait, cf. Bourbaki).
Et justement comme j'aime bien me
faire comprendre, voici un exemple de ses abstractions. Dans le chapitre
"Déclarations" (autre défaut de l'ouvrage : pas de vraie numérotation des
chapitres ni des paragraphes ce qui a pour conséquence une mauvaise navigation)
page 37, je lis :
Each declaration applies as far as the end of the current file (the "scope" of
the declaration). But in a block of program within this scope, a contradictory
declaration may "hide" the original (the visibility). Scope and visibility are
further described below.
Quand j'ai lu ça pour la première fois, et que j'avais 6 mois d'apprentissage du
C derrière moi, je suis resté sur ma faim et j'ai d'ailleurs écrit dans la marge
: "pas très clair". Et en relisant l'extrait, c'est en effet peu clair pour
celui qui ne connait pas car le lecteur peut partir dans multiples directions.
D'abord les explications données apparaissent en début d'ouvrage (page 37 sur
214) et donc le lecteur n'est pas censé être familier avec le jargon : block,
scope, visibility. Mais la plus grosse erreur que commet l'auteur c'est de
n'illustrer son propose d'aucun exemple (le texte que j'ai cité ci-dessus
s'arrête là où j'ai cité, il passe ensuite à un autre paragraphe).
Ensuite, la définition donnée de "scope" est vague (c'est une définition comme
ça "en passant") et incorrecte. Ensuite, le vocabulaire employé ("hide") est
totalement incompréhensible (noter que "hide" a parfois un sens moral de
dissimulation et noter que "hide" est employé ici à l'actif et non au passif :
"être caché par" ce qui bien sûr peut surprendre parce quand on a jamais vu
cela, on ne peut imaginer qu'une declaration a un rôle actif). A "contradictory
declaration" est une mauvaise expression car elle laisserait en fait penser à
une erreur (la présence d'une "contradiction" est la plupart du temps le signe
d'une erreur ou d'une impossibilité). Pareil, pour "visibility", la définition
n'est pas précise, elle est donnée comme ça, "en passant" et l'auteur semble
opposer "scope" et "visibility" ce qui est une erreur, cf. la Norme qui dit :
the identifier is visible (i.e., can be used) only within a region of program
text called its scope.
Et la fin de l'extrait que j'ai cité ci-dessus, c'est vraiment le ponpon. Je
traduis la situation : "je vous ai donné une explication complètement
incompréhensible mais je vais vous expliquer ça bien plus loin seulement je vous
dis pas où". Et en effet, j'ai beau chercher "plus bas", je ne trouve aucune
explication à ce propos. Heureusement, l'auteur mentionne "scope" dans l'index
ce qui renvoie à la page 74 mais hélas, les explications données sont à nouveau
assez médiocres (encore une fois, parce qu'il parle de manière abstraite).
L'auteur est coutumier de ce genre d'échappatoire car toujours page 37 mais
quelques lignes plus loin il nous dit :
"The difference between _declaration_ and _definition_ are semantic rather than
syntatic. The differences are, in fact, more complicated than suggested above,
and are further described in chapter 5"
Je peux vous dire que lorsque j'ai lu ça, je n'ai pas du tout apprécié d'être
renvoyé ailleurs. Quelques remarques :
1°) "The difference between _declaration_ and _definition_ are semantic rather
than syntatic." Je pense que c'est discutable. Et de toute façon, mon point de
vue est que, dans un premier tant, le débutant s'en fout complètement de ce
genre de glose jargonnesque et s'y référer ne fait que rendre encore plus
difficile l'apprentissage (ça oblige à apprendre la métalangue et la langue).
2°) "more complicated than suggested above" : ça par contre, je trouve ça bien,
trop souvent les auteurs omettent de signaler qu'ils ne donnent qu'une vue
partielle et qui va mettre du temps à être complète. Mais bien sûr, il ne faut
pas que l'auteur en reste là.
3°) Au moins, il précise _où_ se fait la référence. Mais c'est assez vague, ce
qu'il appelle le chapitre 5 est une suite de leçons assez hétérogènes et dont
aucun des titres ne fait mention de "déclaration" ou "definition".
Bref, un ouvrage ayant une approche formelle peu classique mais qui tombe dans
les mêmes errements et les mêmes approximations que la majorité des ouvrages à
facture plus traditionnelle.
Sinon, mon exemplaire n'est pas à vendre (pour info, je l'avais trouvé
d'occasion via amazon.com en février 2006 pour 30 USD hors frais de port).
Merci pour la longue réponse. Malheuseusement, ce n'est pas le bon
livre. En fait, j'ai oublié de préciser que c'était un livre en français
Merci pour la longue réponse. Malheuseusement, ce n'est pas le bon
livre. En fait, j'ai oublié de préciser que c'était un livre en français
Merci pour la longue réponse. Malheuseusement, ce n'est pas le bon
livre. En fait, j'ai oublié de préciser que c'était un livre en français
Bonjour,
Je recherche le titre d'un livre sur le langage C qui a du être publié
vers 1985. Le livre était spiralé avec, si mes souvenir sont bons, une
couverture bleue.
Merci,
Olivier.
Bonjour,
Je recherche le titre d'un livre sur le langage C qui a du être publié
vers 1985. Le livre était spiralé avec, si mes souvenir sont bons, une
couverture bleue.
Merci,
Olivier.
Bonjour,
Je recherche le titre d'un livre sur le langage C qui a du être publié
vers 1985. Le livre était spiralé avec, si mes souvenir sont bons, une
couverture bleue.
Merci,
Olivier.
Ne pourrait-ce être "Clefs pour C" de François Piette ? Il date de 1987,
est spiralé, mais la couverture est grise, et non bleue.
Hmm ?
Ne pourrait-ce être "Clefs pour C" de François Piette ? Il date de 1987,
est spiralé, mais la couverture est grise, et non bleue.
Hmm ?
Ne pourrait-ce être "Clefs pour C" de François Piette ? Il date de 1987,
est spiralé, mais la couverture est grise, et non bleue.
Hmm ?