Chercher un livre sur le C avec certains critères.
200 réponses
Francois
Bonjour à tous,
Je débute dans le C et personnellement j'apprends surtout avec les
livres. J'ai commencé "Livre du C premier langage" de Delannoy (je
précise que j'avais quand même des petites notions de programmations,
même si, à mon sens, j'étais [ et suis encore ? ] vraiment ce qu'on
appelle un débutant).
Je suis en train de lire le K&R (deuxième édition) qui est bien sûr
beaucoup plus difficile. C'est du concentré, mais quand on y regarde de
prêt, c'est quand assez précis et bien fait. Ceci étant, il y a des
choses qui ne me satisfont pas complètement.
Je trouve que ce livre à une approche trop éloignée de la machine
(comment une donnée est encodée ? comment se passe l'histoire du signed
ou unsigned du point de vue de la machine etc.). Je m'explique.
Bien sûr, le langage C est un langage abstrait de "haut niveau" qui se
doit (en principe) de ne pas faire référence à la machine. Donc c'est
normal qu'un livre sur le C ne parle pas (trop) des problèmes qui
dépendent de l'architecture. Ceci étant, j'aimerais savoir si un tel
livre existe malgré tout. Un livre qui expose le langage C et qui
n'hésite pas de temps en temps à parler de ce qui se passe dans la
machine (bien sûr, justement, ce qui se passe dépend de la machine et
n'est pas universel, mais le livre pourrait présenter les choses sur
seulement une architecture "classique" par exemple). Bon, si je pouvais
éviter les circuits électroniques et compagnie quand même, ça serait
bien. Qu'on me dise que "le complément à 2 fait que l'addition devient
plus simple pour l'ordinateur puisqu'il suffit de faire une addition
classique" me suffit amplement. Une preuve de cela en passant des
explications sur des circuits électroniques peut-être me serait un peu
indigeste.
Bref, j'espère avoir été clair sur cette sorte de compromis que je
recherche (existe-t-il ?). Vous pouvez aller voir cette discussion (où
mon pseudo est sisco)
Ou alors, ca me parait plus important d'evoquer les regles d'aliasing de type, qui sont elles *vraiment* tordues.
Peux-tu me rappeller ce que tu appelles "aliasing" ?
En Fortran, il y a un vrai type tableau. Ca permet aux physicien de faire la nique au gens du C avec des optimisations `impossibles' en C, parce qu'on ne sait pas trop si deux pointeurs correspondent a la meme zone memoire ou pas (aliasing).
Les normes recentes (je sais plus si c'est deja en C89) introduisent un De memoire, oui.
typage fort: deux pointeurs de types differents ne peuvent pas correspondre a la meme zone memoire, et donc le compilo a le droit de faire des optimisations assez tordues. [...]
(comme on est en C, quand meme, la notion de type different est assez tordue, puisqu'on regarde dans le pointeur pour savoir a quoi on a vraiment affaire comme donnee... ainsi un struct { int a } *p et un int *q ont parfaitement
le droit de pointer sur la meme zone memoire, le systeme unifie egalement signed/unsigned,
Tu es sur sur ou n'est-ce que la technique utilisees par les compilateurs pour eviter de tout casser (ca ne correspond pas a ce que j'avais cru comprendre)
Pour le struct vs. int *, oui, je suis sur. Sinon tu invalides toute technique d'OO a la C classique. Comment tu veux faire fonctionner sockaddr, par exemple ?
et considere que tout acces a travers un (signed/unsigned/) char * ou un void * peut etre aliase par n'importe quoi.)
Ca correspond a ma memoire mais les acces a travers void* sont rares :-)
Pas directement, mais tu peux avoir un transtypage sur un appel de fonction... a la memcpy.
In article <pxb4pbdwo7d.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> wrote:
espie@lain.home (Marc Espie) writes:
In article <slrnftch7o.610.Marc.Boyer@ubu.enseeiht.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
Ou alors, ca me parait plus important d'evoquer les regles d'aliasing
de type, qui sont elles *vraiment* tordues.
Peux-tu me rappeller ce que tu appelles "aliasing" ?
En Fortran, il y a un vrai type tableau. Ca permet aux physicien de faire
la nique au gens du C avec des optimisations `impossibles' en C, parce
qu'on ne sait pas trop si deux pointeurs correspondent a la meme zone
memoire ou pas (aliasing).
Les normes recentes (je sais plus si c'est deja en C89) introduisent un
De memoire, oui.
typage fort: deux pointeurs de types differents ne peuvent pas correspondre
a la meme zone memoire, et donc le compilo a le droit de faire des
optimisations assez tordues.
[...]
(comme on est en C, quand meme, la notion de type different est assez tordue,
puisqu'on regarde dans le pointeur pour savoir a quoi on a vraiment affaire
comme donnee... ainsi un struct { int a } *p et un int *q ont
parfaitement
le droit de pointer sur la meme zone memoire, le systeme unifie egalement
signed/unsigned,
Tu es sur sur ou n'est-ce que la technique utilisees par les compilateurs
pour eviter de tout casser (ca ne correspond pas a ce que j'avais cru
comprendre)
Pour le struct vs. int *, oui, je suis sur. Sinon tu invalides toute
technique d'OO a la C classique. Comment tu veux faire fonctionner
sockaddr, par exemple ?
et considere que tout acces a travers un (signed/unsigned/) char * ou un
void * peut etre aliase par n'importe quoi.)
Ca correspond a ma memoire mais les acces a travers void* sont rares :-)
Pas directement, mais tu peux avoir un transtypage sur un appel de
fonction... a la memcpy.
Ou alors, ca me parait plus important d'evoquer les regles d'aliasing de type, qui sont elles *vraiment* tordues.
Peux-tu me rappeller ce que tu appelles "aliasing" ?
En Fortran, il y a un vrai type tableau. Ca permet aux physicien de faire la nique au gens du C avec des optimisations `impossibles' en C, parce qu'on ne sait pas trop si deux pointeurs correspondent a la meme zone memoire ou pas (aliasing).
Les normes recentes (je sais plus si c'est deja en C89) introduisent un De memoire, oui.
typage fort: deux pointeurs de types differents ne peuvent pas correspondre a la meme zone memoire, et donc le compilo a le droit de faire des optimisations assez tordues. [...]
(comme on est en C, quand meme, la notion de type different est assez tordue, puisqu'on regarde dans le pointeur pour savoir a quoi on a vraiment affaire comme donnee... ainsi un struct { int a } *p et un int *q ont parfaitement
le droit de pointer sur la meme zone memoire, le systeme unifie egalement signed/unsigned,
Tu es sur sur ou n'est-ce que la technique utilisees par les compilateurs pour eviter de tout casser (ca ne correspond pas a ce que j'avais cru comprendre)
Pour le struct vs. int *, oui, je suis sur. Sinon tu invalides toute technique d'OO a la C classique. Comment tu veux faire fonctionner sockaddr, par exemple ?
et considere que tout acces a travers un (signed/unsigned/) char * ou un void * peut etre aliase par n'importe quoi.)
Ca correspond a ma memoire mais les acces a travers void* sont rares :-)
Pas directement, mais tu peux avoir un transtypage sur un appel de fonction... a la memcpy.
candide
On 11 mar, 07:46, "Thierry B." wrote:
architectures différentes. Et pour aller dans le concret, une vieille Sun genre ss20, ça se trouve à pas cher[1], et ça rend modeste sur la "portabilité" du code que tu écris :)
Ou, j'ai bien pensé à faire ce genre de chose (merci du tuyau pour le ss20 que je ne connaissais pas, je vais chercher) mais le problème est que je vais galérer un max pour installer un OS là-dessus puis installer tous les outils pour faire du C. Non pas tellement que ce soit spécialement dur, c'est une question de temps et de pas mal de temps lorsqu'on n'est pas initié.
En fait, je me tourne plutôt vers des solutions cross-compilateur (si quelqu'un a des tuyaux ou des conseils là-dessus à propos de quelque chose de FACILEMENT installable et utilisable) genre PIC ou alors compilateur pour calculatrice TI, Casio ou HP.
On 11 mar, 07:46, "Thierry B." <t...@prout.stex.invalid> wrote:
architectures différentes. Et pour aller dans le concret, une
vieille Sun genre ss20, ça se trouve à pas cher[1], et ça rend
modeste sur la "portabilité" du code que tu écris :)
Ou, j'ai bien pensé à faire ce genre de chose (merci du tuyau pour le
ss20 que je ne connaissais pas, je vais chercher) mais le problème est
que je vais galérer un max pour installer un OS là-dessus puis
installer tous les outils pour faire du C. Non pas tellement que ce
soit spécialement dur, c'est une question de temps et de pas mal de
temps lorsqu'on n'est pas initié.
En fait, je me tourne plutôt vers des solutions cross-compilateur (si
quelqu'un a des tuyaux ou des conseils là-dessus à propos de quelque
chose de FACILEMENT installable et utilisable) genre PIC ou alors
compilateur pour calculatrice TI, Casio ou HP.
architectures différentes. Et pour aller dans le concret, une vieille Sun genre ss20, ça se trouve à pas cher[1], et ça rend modeste sur la "portabilité" du code que tu écris :)
Ou, j'ai bien pensé à faire ce genre de chose (merci du tuyau pour le ss20 que je ne connaissais pas, je vais chercher) mais le problème est que je vais galérer un max pour installer un OS là-dessus puis installer tous les outils pour faire du C. Non pas tellement que ce soit spécialement dur, c'est une question de temps et de pas mal de temps lorsqu'on n'est pas initié.
En fait, je me tourne plutôt vers des solutions cross-compilateur (si quelqu'un a des tuyaux ou des conseils là-dessus à propos de quelque chose de FACILEMENT installable et utilisable) genre PIC ou alors compilateur pour calculatrice TI, Casio ou HP.
Jean-Marc Bourguet
(Marc Espie) writes:
(comme on est en C, quand meme, la notion de type different est assez tordue, puisqu'on regarde dans le pointeur pour savoir a quoi on a vraiment affaire comme donnee... ainsi un struct { int a } *p et un int *q ont parfaitement
le droit de pointer sur la meme zone memoire, le systeme unifie egalement signed/unsigned,
Tu es sur sur ou n'est-ce que la technique utilisees par les compilateurs pour eviter de tout casser (ca ne correspond pas a ce que j'avais cru comprendre)
Pour le struct vs. int *, oui, je suis sur.
Je ne sais plus a quoi je pensais a ce moment.
Sinon tu invalides toute technique d'OO a la C classique. Comment tu veux faire fonctionner sockaddr, par exemple ?
Par contre ici, je ne vois pas de raison pour laquelle un sockaddr peut etre aliase par un sockaddr_un par exemple si on ne voit pas d'union rassemblant les deux.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
espie@lain.home (Marc Espie) writes:
(comme on est en C, quand meme, la notion de type different est assez tordue,
puisqu'on regarde dans le pointeur pour savoir a quoi on a vraiment affaire
comme donnee... ainsi un struct { int a } *p et un int *q ont
parfaitement
le droit de pointer sur la meme zone memoire, le systeme unifie egalement
signed/unsigned,
Tu es sur sur ou n'est-ce que la technique utilisees par les compilateurs
pour eviter de tout casser (ca ne correspond pas a ce que j'avais cru
comprendre)
Pour le struct vs. int *, oui, je suis sur.
Je ne sais plus a quoi je pensais a ce moment.
Sinon tu invalides toute technique d'OO a la C classique. Comment tu veux
faire fonctionner sockaddr, par exemple ?
Par contre ici, je ne vois pas de raison pour laquelle un sockaddr peut
etre aliase par un sockaddr_un par exemple si on ne voit pas d'union
rassemblant les deux.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
(comme on est en C, quand meme, la notion de type different est assez tordue, puisqu'on regarde dans le pointeur pour savoir a quoi on a vraiment affaire comme donnee... ainsi un struct { int a } *p et un int *q ont parfaitement
le droit de pointer sur la meme zone memoire, le systeme unifie egalement signed/unsigned,
Tu es sur sur ou n'est-ce que la technique utilisees par les compilateurs pour eviter de tout casser (ca ne correspond pas a ce que j'avais cru comprendre)
Pour le struct vs. int *, oui, je suis sur.
Je ne sais plus a quoi je pensais a ce moment.
Sinon tu invalides toute technique d'OO a la C classique. Comment tu veux faire fonctionner sockaddr, par exemple ?
Par contre ici, je ne vois pas de raison pour laquelle un sockaddr peut etre aliase par un sockaddr_un par exemple si on ne voit pas d'union rassemblant les deux.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Antoine Leca
En news:, candide va escriure:
On 9 mar, 12:21, Marc Espie wrote:
a une epoque mon test favori de validite d'un bouquin de C, c'etait la representation des entiers. Tout bouquin qui te dit que les entiers font 32 bits (sans preciser quoi que ce soit) est nocif.
Oui mais là tu prends un exemple vraiment caricatural.
Pourtant l'exemple est très probant. Et s'il n'est plus aussi vrai aujourd'hui (parce qu'à la fois les auteurs nocifs et Microsoft se sont aperçus qu'ils existaient aussi parfois des entiers de 64 bits), ce que décrit Marc est très exact : avec de petits tests simples il est possible d'écarter plus de moitié des ouvrages. Ou des programmes, d'ailleurs : dans un passé un peu plus ancien, le syndrôme que décrit Marc s'appelait « All the computers are Vaxen. » (tous les ordinateurs sont des Vax, l'ordinateur sur lequel la quasi totalité des étudiants américains du début des années 1980 ont appris le lanage C...)
Il y a beaucoup d'ouvrages qui ne rentrent dans cette catégorie et dont la qualité de l'exposition est très médiocre.
C'est vrai aussi. L'un n'empêche pas l'autre.
Au demeurant, on peut aller assez loin dans l'apprentissage du C standard sans avoir besoin de connaître la valeur de sizeof(int)
Ce n'est pas là le problème. En fait, un bon bouquin (de débutant) sera celui qui ne mentionne PAS qu'un entier fait XX bits, parce que cette donnée n'est pas utile pour apprendre à programmer en C : on en arrive à ce que dis Marc (celui qui le dit est nocif) et à ce que tu dis (il n'y a pas besoin de le savoir).
Antoine
En news:3e5f94ff-1ae0-411d-8324-da8cfeda2e06@p73g2000hsd.googlegroups.com,
candide va escriure:
On 9 mar, 12:21, Marc Espie wrote:
a une epoque mon test favori de validite d'un bouquin
de C, c'etait la representation des entiers. Tout bouquin qui te dit
que les entiers font 32 bits (sans preciser quoi que ce soit) est
nocif.
Oui mais là tu prends un exemple vraiment caricatural.
Pourtant l'exemple est très probant.
Et s'il n'est plus aussi vrai aujourd'hui (parce qu'à la fois les auteurs
nocifs et Microsoft se sont aperçus qu'ils existaient aussi parfois des
entiers de 64 bits), ce que décrit Marc est très exact : avec de petits
tests simples il est possible d'écarter plus de moitié des ouvrages.
Ou des programmes, d'ailleurs : dans un passé un peu plus ancien, le
syndrôme que décrit Marc s'appelait « All the computers are Vaxen. » (tous
les ordinateurs sont des Vax, l'ordinateur sur lequel la quasi totalité des
étudiants américains du début des années 1980 ont appris le lanage C...)
Il y a beaucoup d'ouvrages qui ne rentrent dans cette catégorie et
dont la qualité de l'exposition est très médiocre.
C'est vrai aussi. L'un n'empêche pas l'autre.
Au demeurant, on peut aller assez loin
dans l'apprentissage du C standard sans avoir besoin de connaître la
valeur de sizeof(int)
Ce n'est pas là le problème.
En fait, un bon bouquin (de débutant) sera celui qui ne mentionne PAS qu'un
entier fait XX bits, parce que cette donnée n'est pas utile pour apprendre à
programmer en C : on en arrive à ce que dis Marc (celui qui le dit est
nocif) et à ce que tu dis (il n'y a pas besoin de le savoir).
a une epoque mon test favori de validite d'un bouquin de C, c'etait la representation des entiers. Tout bouquin qui te dit que les entiers font 32 bits (sans preciser quoi que ce soit) est nocif.
Oui mais là tu prends un exemple vraiment caricatural.
Pourtant l'exemple est très probant. Et s'il n'est plus aussi vrai aujourd'hui (parce qu'à la fois les auteurs nocifs et Microsoft se sont aperçus qu'ils existaient aussi parfois des entiers de 64 bits), ce que décrit Marc est très exact : avec de petits tests simples il est possible d'écarter plus de moitié des ouvrages. Ou des programmes, d'ailleurs : dans un passé un peu plus ancien, le syndrôme que décrit Marc s'appelait « All the computers are Vaxen. » (tous les ordinateurs sont des Vax, l'ordinateur sur lequel la quasi totalité des étudiants américains du début des années 1980 ont appris le lanage C...)
Il y a beaucoup d'ouvrages qui ne rentrent dans cette catégorie et dont la qualité de l'exposition est très médiocre.
C'est vrai aussi. L'un n'empêche pas l'autre.
Au demeurant, on peut aller assez loin dans l'apprentissage du C standard sans avoir besoin de connaître la valeur de sizeof(int)
Ce n'est pas là le problème. En fait, un bon bouquin (de débutant) sera celui qui ne mentionne PAS qu'un entier fait XX bits, parce que cette donnée n'est pas utile pour apprendre à programmer en C : on en arrive à ce que dis Marc (celui qui le dit est nocif) et à ce que tu dis (il n'y a pas besoin de le savoir).
Antoine
Antoine Leca
En news:47d3e16e$0$21149$, Michel va escriure:
Les tutos, c'est du délire complet tellement il y a d'inepties la- dendans.
Et alors ? Ceux qui les appliquent vont vite apprendre leurs valeurs, exactement de la même manière que les lecteurs de livres apprennent à jauger la valeur des livres après en avoir lu deux ou trois sur un sujet, ou les étudiants après avoir suivis quelques cours.
Si quelqu'un pense savoir tout d'un sujet après avoir lu UN tutoriel, ou après avoir lu UN livre, ou après avoir suivi UN cours, nous sommes tous d'accord pour dire qu'il s'expose à des surprises, et les utilisateurs de ses programmes à des déconvenues.
Même après 10 ans d'expérience en C, je n'osais pas encore faire de formations dignes de ce nom à mes clients.
Tu répondais à quelqu'un qui soutenait que les forums permettaient surtout de limiter l'inhibition ; il semble que vous soyez sur la même ligne...
En fait, je crois que je n'ai jamais rencontré [en tant qu'élève] de formateur informatique qui ait plus de 10 ans d'expérience dans le sujet enseigné.
Et heureusement, car sinon on aurait seulement maintenant les premières formations sur <insérez ici le nom de la technique des années 1994-97 que vous préférez>.
Alors des gosses de 16 ans...
Les gosses de 16 ans d'aujourd'hui ont... 16 ans d'expérience des automates électroniques (OK, disons 13, avant ils ne touchent pas trop souvent aux boutons du magnétoscope pour passer le D****y en boucle ;-) )
Antoine
En news:47d3e16e$0$21149$7a628cd7@news.club-internet.fr,
Michel va escriure:
Les tutos, c'est du délire complet tellement il y a d'inepties
la- dendans.
Et alors ? Ceux qui les appliquent vont vite apprendre leurs valeurs,
exactement de la même manière que les lecteurs de livres apprennent à jauger
la valeur des livres après en avoir lu deux ou trois sur un sujet, ou les
étudiants après avoir suivis quelques cours.
Si quelqu'un pense savoir tout d'un sujet après avoir lu UN tutoriel, ou
après avoir lu UN livre, ou après avoir suivi UN cours, nous sommes tous
d'accord pour dire qu'il s'expose à des surprises, et les utilisateurs de
ses programmes à des déconvenues.
Même après 10 ans d'expérience en C, je n'osais pas
encore faire de formations dignes de ce nom à mes clients.
Tu répondais à quelqu'un qui soutenait que les forums permettaient surtout
de limiter l'inhibition ; il semble que vous soyez sur la même ligne...
En fait, je crois que je n'ai jamais rencontré [en tant qu'élève] de
formateur informatique qui ait plus de 10 ans d'expérience dans le sujet
enseigné.
Et heureusement, car sinon on aurait seulement maintenant les premières
formations sur <insérez ici le nom de la technique des années 1994-97 que
vous préférez>.
Alors des gosses de 16 ans...
Les gosses de 16 ans d'aujourd'hui ont... 16 ans d'expérience des automates
électroniques (OK, disons 13, avant ils ne touchent pas trop souvent aux
boutons du magnétoscope pour passer le D****y en boucle ;-) )
Les tutos, c'est du délire complet tellement il y a d'inepties la- dendans.
Et alors ? Ceux qui les appliquent vont vite apprendre leurs valeurs, exactement de la même manière que les lecteurs de livres apprennent à jauger la valeur des livres après en avoir lu deux ou trois sur un sujet, ou les étudiants après avoir suivis quelques cours.
Si quelqu'un pense savoir tout d'un sujet après avoir lu UN tutoriel, ou après avoir lu UN livre, ou après avoir suivi UN cours, nous sommes tous d'accord pour dire qu'il s'expose à des surprises, et les utilisateurs de ses programmes à des déconvenues.
Même après 10 ans d'expérience en C, je n'osais pas encore faire de formations dignes de ce nom à mes clients.
Tu répondais à quelqu'un qui soutenait que les forums permettaient surtout de limiter l'inhibition ; il semble que vous soyez sur la même ligne...
En fait, je crois que je n'ai jamais rencontré [en tant qu'élève] de formateur informatique qui ait plus de 10 ans d'expérience dans le sujet enseigné.
Et heureusement, car sinon on aurait seulement maintenant les premières formations sur <insérez ici le nom de la technique des années 1994-97 que vous préférez>.
Alors des gosses de 16 ans...
Les gosses de 16 ans d'aujourd'hui ont... 16 ans d'expérience des automates électroniques (OK, disons 13, avant ils ne touchent pas trop souvent aux boutons du magnétoscope pour passer le D****y en boucle ;-) )
Antoine
Antoine Leca
En news:, candide va escriure:
Effectivement, K&R ne définit pas précisément ce qu'est une bibliothèque au point qu'on pourrait penser que bibliothèque > bibliothèque standard.
Cela reflète l'âge du livre, et en particulier le fait qu'il précéde la mise au point de l'architecture actuelles des bibliothèques (et particulièrement les bibliothèques dites dynamiques) telles qu'on les rencontre aujourd'hui sur les systèmes des ordinateurs « classiques » (= avec MMU).
D'ailleurs, c'est aussi vrai pour le langage C : on y trouve le mécanisme (saugrenu) des static/extern, qui est parfaitement adapté à la compilation séparée telle qu'elle a été mise au point pour le système Unix... et il manque un niveau pour les « objets partagés », ce qui oblige trop souvent à des contortions sans nom (cf. libtool, ou http://people.redhat.com/drepper/dsohowto.pdf).
Naturellement, une bibliothèque est pour eux une abstraction, on ne dira jamais qu'une bibliothèque est un fichier archive,
Mmmm. Certes avec Unix tout est un fichier... mais enfin l'implémentation la plus courante (et la plus logique) d'une bibliothèque logicielle prend la forme d'un répertoire.
Et je ne vais pas raconter ici les contortions auxquelles Unix (et à sa suite DOS puis Windows) a dû se livrer pour faire rentrer les bibliothèques dans des fichiers...
on ne parlera pas de bibliothèques dynamiques (ça existait à l'époque)
Ce qui existait à l'époque n'a pas grand chose à voir avec ce que tu utilises aujourd'hui. Et ce qui existait ne risquait pas de fonctionner facilement sur le PDP11/45 qui leur a servi à étalonner leur livre, ou même sur les 11/70 de leurs premiers lecteurs :+).
Juste après la sortie du K&R et de V7, le point focal du développement d'Unix s'est déplacé de la côte Est à la côte Ouest, avec l'arrivée de vmunix alias BSD, puis le contrat Arpa (=sockets) ; tandis que sur la côte Est restait AT&T comme gardien du temple, assis sur SIII puis SV et... le K&R. Mais si les gens de Berkeley ont bien écrit des manuels etc., ils n'ont jamais pris la main sur l'évolution du langage C, qui est resté dans le giron d'AT&T, plus attaché à la portabilité, ce qui a donné la norme ANSI puis ISO.
À mon sens, c'est pour cela que le K&R a été divinisé : par faute de successeur-remplaçant. Il est intéressant de remarquer qu'il n'y a rien d'équivalent pour Unix, les papiers de Thomson et Ritchie ont eu des successeurs, je citerais au « hasard » le bouquin de Bach (qui a influencé un certain L. Torvalds) et celui de McKusick et consorts.
Antoine
En news:b4bcc53d-3f62-4365-b1c3-0c0f96c4cefe@n36g2000hse.googlegroups.com,
candide va escriure:
Effectivement, K&R ne définit pas précisément ce qu'est une
bibliothèque au point qu'on pourrait penser que bibliothèque > bibliothèque standard.
Cela reflète l'âge du livre, et en particulier le fait qu'il précéde la mise
au point de l'architecture actuelles des bibliothèques (et particulièrement
les bibliothèques dites dynamiques) telles qu'on les rencontre aujourd'hui
sur les systèmes des ordinateurs « classiques » (= avec MMU).
D'ailleurs, c'est aussi vrai pour le langage C : on y trouve le mécanisme
(saugrenu) des static/extern, qui est parfaitement adapté à la compilation
séparée telle qu'elle a été mise au point pour le système Unix... et il
manque un niveau pour les « objets partagés », ce qui oblige trop souvent à
des contortions sans nom (cf. libtool, ou
http://people.redhat.com/drepper/dsohowto.pdf).
Naturellement, une bibliothèque est pour eux une
abstraction, on ne dira jamais qu'une bibliothèque est un fichier
archive,
Mmmm. Certes avec Unix tout est un fichier... mais enfin l'implémentation la
plus courante (et la plus logique) d'une bibliothèque logicielle prend la
forme d'un répertoire.
Et je ne vais pas raconter ici les contortions auxquelles Unix (et à sa
suite DOS puis Windows) a dû se livrer pour faire rentrer les bibliothèques
dans des fichiers...
on ne parlera pas de bibliothèques dynamiques (ça existait à
l'époque)
Ce qui existait à l'époque n'a pas grand chose à voir avec ce que tu
utilises aujourd'hui. Et ce qui existait ne risquait pas de fonctionner
facilement sur le PDP11/45 qui leur a servi à étalonner leur livre, ou même
sur les 11/70 de leurs premiers lecteurs :+).
Juste après la sortie du K&R et de V7, le point focal du développement
d'Unix s'est déplacé de la côte Est à la côte Ouest, avec l'arrivée de
vmunix alias BSD, puis le contrat Arpa (=sockets) ; tandis que sur la côte
Est restait AT&T comme gardien du temple, assis sur SIII puis SV et... le
K&R. Mais si les gens de Berkeley ont bien écrit des manuels etc., ils n'ont
jamais pris la main sur l'évolution du langage C, qui est resté dans le
giron d'AT&T, plus attaché à la portabilité, ce qui a donné la norme ANSI
puis ISO.
À mon sens, c'est pour cela que le K&R a été divinisé : par faute de
successeur-remplaçant.
Il est intéressant de remarquer qu'il n'y a rien d'équivalent pour Unix, les
papiers de Thomson et Ritchie ont eu des successeurs, je citerais au «
hasard » le bouquin de Bach (qui a influencé un certain L. Torvalds) et
celui de McKusick et consorts.
Effectivement, K&R ne définit pas précisément ce qu'est une bibliothèque au point qu'on pourrait penser que bibliothèque > bibliothèque standard.
Cela reflète l'âge du livre, et en particulier le fait qu'il précéde la mise au point de l'architecture actuelles des bibliothèques (et particulièrement les bibliothèques dites dynamiques) telles qu'on les rencontre aujourd'hui sur les systèmes des ordinateurs « classiques » (= avec MMU).
D'ailleurs, c'est aussi vrai pour le langage C : on y trouve le mécanisme (saugrenu) des static/extern, qui est parfaitement adapté à la compilation séparée telle qu'elle a été mise au point pour le système Unix... et il manque un niveau pour les « objets partagés », ce qui oblige trop souvent à des contortions sans nom (cf. libtool, ou http://people.redhat.com/drepper/dsohowto.pdf).
Naturellement, une bibliothèque est pour eux une abstraction, on ne dira jamais qu'une bibliothèque est un fichier archive,
Mmmm. Certes avec Unix tout est un fichier... mais enfin l'implémentation la plus courante (et la plus logique) d'une bibliothèque logicielle prend la forme d'un répertoire.
Et je ne vais pas raconter ici les contortions auxquelles Unix (et à sa suite DOS puis Windows) a dû se livrer pour faire rentrer les bibliothèques dans des fichiers...
on ne parlera pas de bibliothèques dynamiques (ça existait à l'époque)
Ce qui existait à l'époque n'a pas grand chose à voir avec ce que tu utilises aujourd'hui. Et ce qui existait ne risquait pas de fonctionner facilement sur le PDP11/45 qui leur a servi à étalonner leur livre, ou même sur les 11/70 de leurs premiers lecteurs :+).
Juste après la sortie du K&R et de V7, le point focal du développement d'Unix s'est déplacé de la côte Est à la côte Ouest, avec l'arrivée de vmunix alias BSD, puis le contrat Arpa (=sockets) ; tandis que sur la côte Est restait AT&T comme gardien du temple, assis sur SIII puis SV et... le K&R. Mais si les gens de Berkeley ont bien écrit des manuels etc., ils n'ont jamais pris la main sur l'évolution du langage C, qui est resté dans le giron d'AT&T, plus attaché à la portabilité, ce qui a donné la norme ANSI puis ISO.
À mon sens, c'est pour cela que le K&R a été divinisé : par faute de successeur-remplaçant. Il est intéressant de remarquer qu'il n'y a rien d'équivalent pour Unix, les papiers de Thomson et Ritchie ont eu des successeurs, je citerais au « hasard » le bouquin de Bach (qui a influencé un certain L. Torvalds) et celui de McKusick et consorts.
Antoine
candide
On ne flanque pas le premier volume du tome un des oeuvres de Bourbaki au CP. Je le sais, mon aine est au CP.
Tiens, j'avais surévalué ton âge (à moins que CP ce ne soit Classes Prépas ? ;) )
On ne flanque pas le premier volume du tome un des oeuvres de Bourbaki au
CP. Je le sais, mon aine est au CP.
Tiens, j'avais surévalué ton âge (à moins que CP ce ne soit Classes
Prépas ? ;) )
On ne flanque pas le premier volume du tome un des oeuvres de Bourbaki au CP. Je le sais, mon aine est au CP.
Tiens, j'avais surévalué ton âge (à moins que CP ce ne soit Classes Prépas ? ;) )
candide
Tient, on commence l'année en disant qu'il ne faut pas de variable globale, et à la fin de l'année, quand on faut un mini purify, qui surcharge malloc/calloc/free, ben, on en utilise...
En effet le discours académique selon lequel il ne faut pas utiliser de variables globales (quand ce discours n'est pas accompagné d'une aversion violente contre elles, ahem, visez mon regard) à de quoi surprendre quand on voit la masse de code professionnel rempli de variables globales.
Tient, on commence l'année en disant qu'il ne faut pas de variable
globale, et à la fin de l'année, quand on faut un mini purify,
qui surcharge malloc/calloc/free, ben, on en utilise...
En effet le discours académique selon lequel il ne faut pas utiliser de
variables globales (quand ce discours n'est pas accompagné d'une
aversion violente contre elles, ahem, visez mon regard) à de quoi
surprendre quand on voit la masse de code professionnel rempli de
variables globales.
Tient, on commence l'année en disant qu'il ne faut pas de variable globale, et à la fin de l'année, quand on faut un mini purify, qui surcharge malloc/calloc/free, ben, on en utilise...
En effet le discours académique selon lequel il ne faut pas utiliser de variables globales (quand ce discours n'est pas accompagné d'une aversion violente contre elles, ahem, visez mon regard) à de quoi surprendre quand on voit la masse de code professionnel rempli de variables globales.
espie
In article <47d6ee00$0$10344$, candide wrote:
En effet le discours académique selon lequel il ne faut pas utiliser de variables globales (quand ce discours n'est pas accompagné d'une aversion violente contre elles, ahem, visez mon regard) à de quoi surprendre quand on voit la masse de code professionnel rempli de variables globales.
Il faut faire de la resistance active contre les variables globales.
Elles foutent tres souvent le bordel, et rendent tres souvent le code illisible.
De mon point de vue une variable globale doit etre pesee, et justifiee. Il faut qu'il y ait de tres tres bonnes raisons (de lisibilite et de performances, le plus souvent) pour avoir des variables globales.
Si on remonte un peu, conceptuellement, une variable globale, c'est une implementation tres naive d'un singleton, et en fait il y a pas mal de cas ou ce qu'on prenait pour une instance unique doit etre dedouble quand on perfectionne le code. Et la, plus on attend, plus ca fait mal.
Il y a dans la bibliotheque standard au moins une variable globale (ou assimilee) qui pose plein de problemes, c'est errno. Quant aux gens qui font des choses rigolotes avec stdin et stdout et tous les problemes que ca peut poser...
In article <47d6ee00$0$10344$426a34cc@news.free.fr>,
candide <c-candide@wanadoo.fr> wrote:
En effet le discours académique selon lequel il ne faut pas utiliser de
variables globales (quand ce discours n'est pas accompagné d'une
aversion violente contre elles, ahem, visez mon regard) à de quoi
surprendre quand on voit la masse de code professionnel rempli de
variables globales.
Il faut faire de la resistance active contre les variables globales.
Elles foutent tres souvent le bordel, et rendent tres souvent le code
illisible.
De mon point de vue une variable globale doit etre pesee, et justifiee.
Il faut qu'il y ait de tres tres bonnes raisons (de lisibilite et de
performances, le plus souvent) pour avoir des variables globales.
Si on remonte un peu, conceptuellement, une variable globale, c'est
une implementation tres naive d'un singleton, et en fait il y a pas mal
de cas ou ce qu'on prenait pour une instance unique doit etre dedouble
quand on perfectionne le code. Et la, plus on attend, plus ca fait mal.
Il y a dans la bibliotheque standard au moins une variable globale (ou
assimilee) qui pose plein de problemes, c'est errno. Quant aux gens
qui font des choses rigolotes avec stdin et stdout et tous les problemes
que ca peut poser...
En effet le discours académique selon lequel il ne faut pas utiliser de variables globales (quand ce discours n'est pas accompagné d'une aversion violente contre elles, ahem, visez mon regard) à de quoi surprendre quand on voit la masse de code professionnel rempli de variables globales.
Il faut faire de la resistance active contre les variables globales.
Elles foutent tres souvent le bordel, et rendent tres souvent le code illisible.
De mon point de vue une variable globale doit etre pesee, et justifiee. Il faut qu'il y ait de tres tres bonnes raisons (de lisibilite et de performances, le plus souvent) pour avoir des variables globales.
Si on remonte un peu, conceptuellement, une variable globale, c'est une implementation tres naive d'un singleton, et en fait il y a pas mal de cas ou ce qu'on prenait pour une instance unique doit etre dedouble quand on perfectionne le code. Et la, plus on attend, plus ca fait mal.
Il y a dans la bibliotheque standard au moins une variable globale (ou assimilee) qui pose plein de problemes, c'est errno. Quant aux gens qui font des choses rigolotes avec stdin et stdout et tous les problemes que ca peut poser...
candide
À mon sens, c'est pour cela que le K&R a été divinisé :
Content d'observer que tu fais toi aussi ce constat.
À mon sens, c'est pour cela que le K&R a été divinisé :
Content d'observer que tu fais toi aussi ce constat.
