Livre pour débuter le C ?

[pascal.p...@gmail.com]

Bonjour à toutes et à tous,
quel livre me conseilleriez vous sur le langage C, plutot orienté microcontroleurs...
Je précise que je suis technicien en électronique, et que j'ai quand meme des notions de programmations...
J'ai vu rapidement le langage en BTS, mais il m'a toujours rebuté, même si je reste persuadé qu'il est puissant, versatile, portable, enfin bref bourré de qualités connues et reconnues...
Sinon, à part ça, vous allez vous moquer de moi, mais j'ai commencé à "bidouiller" en BASIC à la fin des années 80 sur le Commodore C64 de mon frère... En plus le "Basic V2" du C64 n'était deja pas une référence !
Un peu plus tard, j'ai bidouillé en Visual Basic 1.0, puis en Quick Basic 4.5, ...
En BTS je me suis éclaté en assembleur 68705 et 68HC11... Et pour la suite, plus grand chose, à mon grand regret !
J'ai déja posté un message à ce sujet sur fr.sci.electronique, beaucoup m'ont conseillé le K&R, ou le ANSI C.
Merci par avance de votre aide !

[JKB]

Le Fri, 24 Aug 2012 00:31:31 -0700 (PDT),
pascal.p...@gmail.com <pascal.p...@gmail.com> écrivait :

Naon... On t'a conseillé le K&R corrigé ANSI. Il existe deux
versions du K&R, le K&R présentant le C originel et le K&R
présentant le C Ansi.

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

[Marc Boyer]

Le 24-08-2012, pascal.p...@gmail.com <pascal.p...@gmail.com> a écrit :
> Bonjour à toutes et à tous,
> quel livre me conseilleriez vous sur le langage C, plutot orienté microcontroleurs...

C'est un sujet de discussions longues et complexes.
Pour aller vite, le livre K&R version C ANSI est le "moins mauvais",
mais tout apprentissage livresque doit se doubler d'un peu de support
humain, et ce groupe est un lieu possible d'échange.

> J'ai vu rapidement le langage en BTS, mais il m'a toujours rebuté, même si je
> reste persuadé qu'il est puissant, versatile, portable, enfin bref bourré
> de qualités connues et reconnues...

Il est aussi bourré de défauts, bien connus maintenant avec le temps.
Mais aucun langage n'est parfait, et celui là a fait ses preuves.

> Sinon, à part ça, vous allez vous moquer de moi, mais j'ai commencé à
> "bidouiller" en BASIC à la fin des années 80 sur le Commodore C64 de mon frère...
> En plus le "Basic V2" du C64 n'était deja pas une référence !

Tu vas réveiller des nostalgiques.
Moi, ce fut le BASIC d'Alice, dans le milieu des années 80. Mais
j'étais très mauvais ;-)

> En BTS je me suis éclaté en assembleur 68705 et 68HC11...

Disons que dans la famille des langages reconnus, le C est
ce qui se rapproche le plus d'un assembleur.

Marc Boyer
--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet

[Stephane Legras-Decussy]

Le 24/08/2012 09:31, pascal.p...@gmail.com a �crit :
>

alors si d�ja confront� au C tu as �t� rebut�, je ne conseille
pas le K&R qui est exact, rigoureux et ... rebutant.

il faut un bouquin d'approche sympathique pour ne pas �tre
d�gout� et pour *s'amuser*

une fois qu'on a exp�riment� quelque chose et vu que �a marchait, on
peut relire ce qu'en dit le K&R pour avoir les subtilit�s.

en fait pas besoin de bouquin, ce cours en ligne est excellent et le
taux d'erreur est tr�s bon ...

http://www.siteduzero.com/tutoriel-3-14189-apprenez-a-programmer-en-c.html

en orient� microcontroleur, ce qui est mon cr�neau aussi, je te
conseille les controleurs Atmel et l'outil de dev fourni ...

[Tonton Th]

On 08/24/2012 08:56 PM, Stephane Legras-Decussy wrote:

> http://www.siteduzero.com/tutoriel-3-14189-apprenez-a-programmer-en-c.html

Qui contient un certain nombre d'approximations assez douteuses...

--

Nous vivons dans un monde �trange/
http://foo.bar.quux.over-blog.com/

[Pascal06]

On Aug 24, 8:56 pm, Stephane Legras-Decussy <ad...@facebook.com>
wrote:
> Le 24/08/2012 09:31, pascal.pellizz...@gmail.com a crit :

>
>
>
> alors si d ja confront au C tu as t rebut , je ne conseille
> pas le K&R qui est exact, rigoureux et ... rebutant.
>
> il faut un bouquin d'approche sympathique pour ne pas tre
> d gout et pour *s'amuser*
>
> une fois qu'on a exp riment quelque chose et vu que a marchait, on
> peut relire ce qu'en dit le K&R pour avoir les subtilit s.
>
> en fait pas besoin de bouquin, ce cours en ligne est excellent et le
> taux d'erreur est tr s bon ...
>

> http://www.siteduzero.com/tutoriel-3-14189-apprenez-a-programmer-en-c...

>
> en orient microcontroleur, ce qui est mon cr neau aussi, je te
> conseille les controleurs Atmel et l'outil de dev fourni ...

Bonsoir,
Merci pour ce conseil...
J'ai effectivement regardé le site du "0", j'ai meme imprimé le
bouquin...
Mais je me suis presque fait incendié (sur fr.sci.electronique) en
parlant de ça !
D'ou ma question ici...

[Stephane Legras-Decussy]

Le 24/08/2012 22:19, Tonton Th a �crit :

>
>
> Qui contient un certain nombre d'approximations assez douteuses...
>

c'est mieux que d'�tre d�gout� et d'abandonner.

quand on est � l'aise on cherche les erreurs en comparant
avec le K&R ...

[Pascal06]

Bonjour,
je suis entièrement d'accord avec toi. Je préfère m'y remettre
doucement, plutôt que d'être encore une fois rebuté. Je n'ai pas envie
d'être un puriste non plus !
Déjà qu'à la base je ne comprends l'utilité de ces satanés ";" en fin
de ligne ! On est plus en 1960 !

[Tonton Th]

On 08/25/2012 04:31 AM, Stephane Legras-Decussy wrote:

>> Qui contient un certain nombre d'approximations assez douteuses...
>>
>

> c'est mieux que d'être dégouté et d'abandonner.

Gni ?

> quand on est à l'aise on cherche les erreurs en comparant
> avec le K&R ...

Dans ce cas, pourquoi ne pas commencer dès le début
en apprenant des notions exactes ?

--

Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/

[Erwan David]

Stephane Legras-Decussy <ad...@facebook.com> écrivait :

> Le 24/08/2012 22:19, Tonton Th a écrit :
>>
>>
>> Qui contient un certain nombre d'approximations assez douteuses...
>>
>

> c'est mieux que d'être dégouté et d'abandonner.

EN quoi est-il plus simple de faire commencer le hello world par
int main(void) plutôt que int main() ?

Le premier est correct, le second utilisé sur le site est faux.


--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé

[Stephane Legras-Decussy]

Le 25/08/2012 10:31, Tonton Th a écrit :
>
> Dans ce cas, pourquoi ne pas commencer dès le début
> en apprenant des notions exactes ?
>

parce qu'on apprend pas à compter en maternelle en parlant
d'entiers naturels et de leur construction selon von neumann ...

[Marc Espie]

In article <k1ac4p$j69$1...@speranza.aioe.org>,
Stephane Legras-Decussy <ad...@facebook.com> wrote:
>Le 25/08/2012 10:31, Tonton Th a �crit :
>>
>> Dans ce cas, pourquoi ne pas commencer d�s le d�but

>> en apprenant des notions exactes ?
>>
>

>parce qu'on apprend pas � compter en maternelle en parlant

>d'entiers naturels et de leur construction selon von neumann ...

Ouais, mais on n'y apprend pas non plus que 2+2=5...

[Stephane Legras-Decussy]

Le 25/08/2012 12:04, Erwan David a �crit :
> Stephane Legras-Decussy<ad...@facebook.com> �crivait :
>
>> Le 24/08/2012 22:19, Tonton Th a �crit :

>>>
>>>
>>> Qui contient un certain nombre d'approximations assez douteuses...
>>>
>>

>> c'est mieux que d'�tre d�gout� et d'abandonner.

>
> EN quoi est-il plus simple de faire commencer le hello world par

> int main(void) plut�t que int main() ?
>
> Le premier est correct, le second utilis� sur le site est faux.

parce qu'il faudrait expliquer "void" qui est tr�s compliqu� quand on
est seulement � ce niveau du cours.


en pratique, cette absence de void, �a va provoquer quoi ?

[Stephane Legras-Decussy]

Le 25/08/2012 13:18, Marc Espie a �crit :

>
> Ouais, mais on n'y apprend pas non plus que 2+2=5...

quoique pour des grandes valeurs de 2, on y arrive presque...


sans rire on apprend qu'on ne peut pas faire 2-3 ... et puis
plus tard, en 5�me on apprend qu'on peut.

�a n'a jamais traumatis� personne ... si ?



plus tard on apprend qu'un carr� est toujours positif... et un jour
on apprend que i^2 = -1 ...

etc etc

[Marc Espie]

In article <k1adsn$n4h$1...@speranza.aioe.org>,

Stephane Legras-Decussy <ad...@facebook.com> wrote:
>Le 25/08/2012 13:18, Marc Espie a �crit :
>>
>> Ouais, mais on n'y apprend pas non plus que 2+2=5...
>
>quoique pour des grandes valeurs de 2, on y arrive presque...
>
>
>sans rire on apprend qu'on ne peut pas faire 2-3 ... et puis
>plus tard, en 5�me on apprend qu'on peut.
>
>�a n'a jamais traumatis� personne ... si ?

tu confonds des trucs qu'on n'apprend pas tout de suite avec des trucs
completement faux...

c'est un peu ca le probleme avec le site du zero: certains des idiomes qui
y sont enseignes sont totalement non portables de facon gratuite.

Autant ne pas rentrer trop dans les details, je comprend, autant remplacer
du code correct et pas plus complique par du code qui ne marche que sur
certaines machines, c'est un peu cretin...

[Marc Espie]

In article <k1acl4$k9h$1...@speranza.aioe.org>,

Mais n'importe quoi. Suffit de dire qu'on met void (rien) pour bien indiquer
que la fonction n'a pas de parametres. Pas besoin d'aller plus loin dans
les explications !

Ouh, que c'est complique !

[Erwan David]

Stephane Legras-Decussy <ad...@facebook.com> �crivait�:

> Le 25/08/2012 12:04, Erwan David a �crit :
>> Stephane Legras-Decussy<ad...@facebook.com> �crivait :
>>
>>> Le 24/08/2012 22:19, Tonton Th a �crit :
>>>>
>>>>
>>>> Qui contient un certain nombre d'approximations assez douteuses...
>>>>
>>>
>>> c'est mieux que d'�tre d�gout� et d'abandonner.
>>
>> EN quoi est-il plus simple de faire commencer le hello world par
>> int main(void) plut�t que int main() ?
>>
>> Le premier est correct, le second utilis� sur le site est faux.
>
> parce qu'il faudrait expliquer "void" qui est tr�s compliqu� quand on
> est seulement � ce niveau du cours.

Mais non, on dit void c'est pour dire qu'il n'y a pas d'arguments.

>
> en pratique, cette absence de void, �a va provoquer quoi ?
>

Que certains compilateurs vont refuser le programme. et alors "pourquoi
�a marche pas chez moi ?" va �tre nettement plus compliqu� � expliquer.

--
Le travail n'est pas une bonne chose. Si �a l'�tait,
les riches l'auraient accapar�

[Francois Lafont]

Bonjour,

Toujours sur le site du zéro, il y a un autre « cours » sur le langage
C, qui n'est pas encore terminé d'ailleurs. C'est ici :

http://www.siteduzero.com/tutoriel-3-702219-le-langage-c.html

Il fait doublon avec le tutoriel évoqué précédemment et les auteurs
expliquent pourquoi ils ont quand même souhaité faire un autre tutoriel
sur le langage C. Les explications sont ici :

http://www.siteduzero.com/tutoriel-50-702219-p1-le-langage-c.html#r98893

Une des raisons invoquées, je cite : « Le deuxième aspect est que le
tutoriel contenait des inexactitudes voire des erreurs. »

Je ne sais pas si ce cours est meilleur que le précédent (je n'ai pas de
compétences suffisantes en C, loin de là), mais en tout cas il passe le
test du « void » avec succès :

http://www.siteduzero.com/tutoriel-3-702248-rencontre-avec-le-c.html#ss_part_2

--
François Lafont

[Alexandre Bacquart]

On 08/25/2012 08:34 AM, Pascal06 wrote:
> D�j� qu'� la base je ne comprends l'utilit� de ces satan�s ";" en fin

> de ligne ! On est plus en 1960 !

Pr�cis�ment. C'est la raison pour laquelle il a �t� d�cid� en C (d�but
des ann�es 1970) d'en finir avec l'antique paradigme de la fin de ligne
s�parateur d'instructions (encore qu'il me semble que C ne soit pas le
premier � avoir introduit cette notion).

�tant donn� que tu n'as jamais fait que du BASIC (ou de l'assembleur),
il n'est pas �tonnant que cela te d�range. BASIC a d'ailleurs persist�
avec l'ancien paradigme jusqu'� plus soif !

La v�rit�, c'est qu'utiliser un symbole (';' en l'occurrence) comme
s�parateur d'instructions permet au programmeur de formater son code
comme il l'entend :

int main(void)
{
printf("Hello, World!\n");
return 0;
}

peut tout aussi bien s'�crire :

int main(void) { printf("Hello, World!\n"); return 0; }

ou encore :

int
main(void) {
printf("Hello, "
"World!"
"\n")
;
return
0; }

Approuv� par n'importe quel compilateur C saint d'esprit. C'est tout de
suite plus flexible. La fin de ligne est trait�e comme n'importe quel
caract�re white-space (espace, tabulation, FF, etc...).

Seule exception � la r�gle, le pr�processeur :

#define SEED 42

o� l�, effectivement, la fin de ligne signale la fin de l'instruction.
R�gle qu'on peut d'ailleurs outrepasser avec '\' :

#define SEED \
42


--
Alexandre

[Alexandre Bacquart]

On 08/24/2012 11:25 PM, Pascal06 wrote:
> On Aug 24, 8:56 pm, Stephane Legras-Decussy<ad...@facebook.com>
> wrote:
>> Le 24/08/2012 09:31, pascal.pellizz...@gmail.com a crit :
>>
>>
>>
>> alors si d ja confront au C tu as t rebut , je ne conseille
>> pas le K&R qui est exact, rigoureux et ... rebutant.

Exact et rigoureux sont loin d'�tre des adjectifs... rebutants pour un
tel langage.

>> il faut un bouquin d'approche sympathique pour ne pas tre
>> d gout et pour *s'amuser*

Il ne me semble pas que l'OP ait beaucoup envie de s'amuser. �a tombe
bien d'ailleurs, les compilateurs C manquent cruellement d'humour.

>> une fois qu'on a exp riment quelque chose et vu que a marchait, on
>> peut relire ce qu'en dit le K&R pour avoir les subtilit s.
>>
>> en fait pas besoin de bouquin, ce cours en ligne est excellent et le
>> taux d'erreur est tr s bon ...
>>
>> http://www.siteduzero.com/tutoriel-3-14189-apprenez-a-programmer-en-c...
>>
>> en orient microcontroleur, ce qui est mon cr neau aussi, je te
>> conseille les controleurs Atmel et l'outil de dev fourni ...
>
> Bonsoir,
> Merci pour ce conseil...

Mouais, bon.

> J'ai effectivement regard� le site du "0", j'ai meme imprim� le
> bouquin...

Diantre, au prix des cartouches d'encre !

Sinon, heu... un tutoriel, ce n'est pas un bouquin.

> Mais je me suis presque fait incendi� (sur fr.sci.electronique) en
> parlant de �a !

> D'ou ma question ici...

Huhuhu ! J'ai vu le troll venir d�s ton tout premier post, mais c'est
pas ta faute. Le sujet du "bouquin pour apprendre le C" est assez
fameux. Il revient � peu pr�s... une fois par an. Et � chaque fois c'est
la m�me rengaine, � savoir :

1. L'ind�tr�nable et incontournable K&R. Peu p�dagogique et patati et
patata, c'est vrai. Mais une tr�s bonne r�f�rence (autrement dit : pas
blind� d'erreurs). Cela tient en grande partie au fait que les auteurs
originaux sont aussi les auteurs du langage, et aussi que ce bouquin a
�t� pendant plus de 10 ans... la seule et unique r�f�rence (il pr�c�de
la premi�re normalisation d'autant). Ces 2 arguments ne sont toutefois
pas une raison suffisante pour en faire un bon livre p�dagogique. Cr�er
des langages, �crire des bouquins et enseigner sont 3 activit�s bien
diff�rentes.

Un autre probl�me du K&R, c'est que malgr� les r�-�ditions, il n'est pas
tr�s � jour avec les derni�res normes et pas du tout avec la derni�re en
date, � savoir celle de 2011 (C11, mais � ce niveau, je serais �tonn�
qu'il existe un bouquin quelconque). La pr�c�dente norme date de 1999
(C99) et m�me celle-l�, il me semble que la derni�re �dition du K&R
fran�ais (2004) n'en parle pas (quant au K&R anglais, la derni�re
�dition date de... 1988 ! autrement dit, la derni�re �dition anglophone
date d'avant la premi�re normalisation).

Est-ce que c'est si grave ? Pas vraiment en fait. La norme ne change
plus tellement au point de rendre le K&R obsol�te. Le monde de C �volue
assez lentement (une r�vision de la norme tous les 10 ans ~). La norme
C11 est en fait un b�b� tout beau tout neuf et encore assez peu
exploit�e. Les programmeurs C ne sont pas du genre sur les
starting-blocks mais plut�t dans les gradins � regarder les plus
t�m�raires se casser la gueule avec un certain amusement (faut bien
qu'ils rigolent un peu parfois). Ils sont peu enclins � adopter les
nouveaut�s tant qu'elles n'ont pas vraiment fait leur preuves. Ce genre
de choses prend du temps.

Sinon, il y a aussi le "Harbison & Steele" assez souvent cit�, mais je
ne le connais pas. Cependant, je ne me souviens pas avoir lu de
critiques n�gatives � son sujet, c'est s�rement qu'il doit valoir
quelque-chose. On dit qu'il est plus � jour que le K&R vis � vis des
derni�res "nouveaut�s" de C (ce qui n'est pas un exploit vous me direz).


2. Le site du z�ro (ou n'importe quel autre
"tuto-kikoo-lol-apprend-C-en-3-minutes").

Pour que tu comprennes bien la situation (rapport aux �meutes que tu
d�clenches en en parlant). Chaque ann�e on y a droit au site du z�ro !
Oui, m�me ici sur les terres sacr�es de f.c.l.c. Donc on ne peut pas y
�chapper, quoiqu'on en dise, qu'on le descende, qu'on l'allume, qu'on
l'atomise, qu'on l'�jecte sur Mars � coup de pied au cul... il y a
toujours, *TOUJOURS* un martien qui d�barque pour nous le revendre. Et
dans la foul�e, un �lu local intervient, en substance : "c'est tr�s
mauvais et blablabla". Syst�matique.

Il suffit d'ailleurs de taper "language C" dans le moteur que tout le
monde conna�t pour comprendre que c'est de toute �vidence LA r�f�rence
francophone pour s'initier au C sur le r�seau de r�seaux.

L'explication des �meutes, c'est que s'il existe un langage qui n'est
pas fait pour les d�butants, c'est bien C. Non pas qu'il soit si
difficile � aborder, mais il demande en principe des ann�es pour �tre
ma�tris�. C'est un langage syst�me, il t'ouvre toutes les portes y
compris celle de la pi�ce avec un gros bouton rouge.

D'autre part, le temps passant et les paradigmes de programmation ayant
quelque peu �volu�, on peut dire que certaines pratiques courantes en C
sont assez pass�es de mode. Sa biblioth�que standard expose encore des
fonctions qui auraient d� �tre rel�gu�es aux oubliettes depuis la nuit
des temps (voire n'auraient jamais d� exister, comme le machiav�lique et
n�anmoins si s�duisant gets(), pour ne citer que lui). C a aussi une
f�cheuse tendance � donner de mauvaises habitudes un peu g�nantes quand
on passe � d'autres langages (et pas que C++).

Tout ceci est totalement incompatible avec le concept de tutoriel qui
fait figure de chien dans un jeu de quilles. Voil� pour les rires,
quolibets, voire �meutes d'experts. Ici, comme les rares endroits o�
l'on peut trouver des experts en C, tu auras � peu pr�s le m�me genre de
r�actions : "H� ho ! On parle de l'illustre et inf�me C bordel ! Faut
arr�ter la d�conne l� hein !". Bon, ils seront moins grossiers, mais le
coeur y sera. C'est un sujet de choix pour des enfilades interminables
(et non-termin�es). D'ailleurs, comme tu peux le constater, �a a d�j�
commenc� (mais c'est bien, �a met un peu d'ambiance dans ces lieux
poussi�reux).

Mon avis (tout � fait personnel), c'est qu'au fond, on a beau �tre un
vieux de la vieille du C pour qui les tutoriels sur ce langage ne sont
rien d'autre que des attrapes nigauds d'une m�diocrit� sans nom, ce
tutoriel l� n'est pas aussi mauvais que ceux qui ne prennent pas
toujours la peine d'y jeter leur oeil averti veulent bien le faire
croire. Certes, un puriste y trouvera toujours quelque-chose � redire,
mais il ne s'y attardera gu�re non plus (�tant � priori expert, il n'a
pas besoin de tutoriel, lui). Cependant il faut rester honn�te : il y a
plusieurs tutoriels en fran�ais sur le net pour le C, aussi h�r�tique
que ce concept puisse para�tre. Et celui-l� est peut �tre bien le
meilleur d'entre tous. Car si les grands-sages-experts ici bas le
descendront avec une facilit� d�concertante, dans les faits ils auront
beaucoup de difficult�s � te proposer mieux.

Bref, plus on conna�t le C, plus l'id�e de tutoriel est contre-nature.


3. Le site d'Emmanuel (http://www.bien-programmer.fr/index.php). Ce
n'est pas un vulgaire tutoriel et on y apprend pas � faire des trucs
rigolos d�s le premier programme, certes. �a manque cruellement
d'empathie pour le pauvre d�butant, certes (c'est pas dans la nature du
personnage ;)). Mais apr�s tout on est pas l� pour rigoler. C'est
surtout assez formel, pr�cis et *correct* (ce qui est rare) et plein de
bon conseils pour �viter les mauvaises habitudes. Et il y a quand-m�me
une initiation. Et en fran�ais.

Petit message pour Emmanuel : tu devrais peut-�tre lancer un appel �
cotisations pour le r�f�rencement de ton site... enfin bon, vu les news,
peut-�tre que tu t'en fous et que tu pr�f�res s�vir sur developpez.com
jusqu'� nouvel ordre :)


4. f.c.l.c : le forum ici pr�sent. C'est vrai qu'il a l'air mort le
bled, mais c'est un leurre pour tromper l'ennemi. Tous les grabataires
francophones experts du C sont l�, tapis dans l'ombre, pr�ts � bondir
sur le premier semi-d�butant qui aurait l'audace de r�pondre une
connerie � la moindre question (et m�me ceux qui r�pondent bien de toute
fa�ons, ils trouvent toujours une bonne raison de contredire un truc,
aussi s�r qu'un bon vieux compilo qui te les brise pour un b�te
point-virgule oubli�). Ne *jamais* h�siter � poser des questions de
parfait d�butant ici. M�me souvent... �a risques pas de saouler, au
contraire, �a mettra un peu de vie dans cette pension de retraite !


5. Pour finir, les plus mauvais tutoriels qui soient pour s'initier au
C, les normes ISO (enfin les derniers drafts du pauvre plut�t) :

C99
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

C11
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

Un bon moyen pour d�gouter le petit fr�re qui te fait de l'ombre.



--
Alexandre

[Marc Espie]

In article <50390241$0$16477$426a...@news.free.fr>,

Alexandre Bacquart <tek512D...@free.fr> wrote:
>Le monde de C �volue assez lentement (une r�vision de la norme
>tous les 10 ans ~).

Ca, ca veut rien dire. Le 'une revision toutes les dix ans', c'est le
principe pour tous les langages normalises par l'ISO, que ce soit C,
Fortran, ou C++.

Ces deux-la ont bouge bien plus que C !

Typiquement, il y a eu un gros blocage sur fortran, suivi par un putsch
qui a donne d'enormes modifs vers 2000.

Quant a C++, la norme 2011 revolutionne totalement les usages du langage
par rapport a C++98...

(je laisse quelqu'un de plus feru nous dire ce qu'il en est de common-lisp...)

[Jean-Marc Bourguet]

Erwan David <er...@rail.eu.org> writes:

> Stephane Legras-Decussy <ad...@facebook.com> �crivait�:
>
>> Le 24/08/2012 22:19, Tonton Th a �crit :

>>>
>>>
>>> Qui contient un certain nombre d'approximations assez douteuses...
>>>
>>

>> c'est mieux que d'�tre d�gout� et d'abandonner.

>
> EN quoi est-il plus simple de faire commencer le hello world par

> int main(void) plut�t que int main() ?
>
> Le premier est correct, le second utilis� sur le site est faux.

R�f�rence, SVP.

Je pr�f�re la premi�re forme, mais dire que la seconde est fausse c'est
aller un peu loin.

Pour moi, le premier d�finit main comme une fonction retournant un int et
sans param�tre et la d�clare de la m�me mani�re, la seconde d�finit main
comme une fonction retournant un int et sans param�tre mais la d�clare
comme une fonction retournant un int avec des param�tres non sp�cifi�. �a
ne fait une diff�rence que dans le cadre de l'IOCCC quand on appelle main
de mani�re r�cursive, si on appelle main avec des param�tres, �a ne doit
pas compiler dans le premier cas, �a doit dans le second, mais l'ex�cution
est un comportement ind�fini.


En passant, je vous rappelle que m�me dans la seconde �dition de K&R, c'est
simplement

main()
{
}

avec des fonctions qui sont parfois d�clar�es � l'int�rieur des fonctions
qui les appellent.

A+

--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org

[Erwan David]

Jean-Marc Bourguet <j...@bourguet.org> écrivait :


> Pour moi, le premier définit main comme une fonction retournant un int et
> sans paramètre et la déclare de la même manière, la seconde définit main
> comme une fonction retournant un int et sans paramètre mais la déclare
> comme une fonction retournant un int avec des paramètres non spécifié. Ça
> ne fait une différence que dans le cadre de l'IOCCC quand on appelle main
> de manière récursive, si on appelle main avec des paramètres, ça ne doit
> pas compiler dans le premier cas, ça doit dans le second, mais l'exécution
> est un comportement indéfini.
>

Résumons, le premier est correct, le deuxième est une forme batarde
entre la verion d'avant la normalisation et celle d'après

> En passant, je vous rappelle que même dans la seconde édition de K&R, c'est
> simplement
>
> main()
> {
> }


> avec des fonctions qui sont parfois déclarées à l'intérieur des fonctions
> qui les appellent.
>

Tu as certainement une version préhistorique du K&R, qui parle de la
version pré-normalisation.

[Marc Espie]

In article <87wr0mo...@news.bourguet.org>,

Jean-Marc Bourguet <j...@bourguet.org> wrote:
>Erwan David <er...@rail.eu.org> writes:
>
>> Stephane Legras-Decussy <ad...@facebook.com> �crivait�:
>>
>>> Le 24/08/2012 22:19, Tonton Th a �crit :
>>>>
>>>>
>>>> Qui contient un certain nombre d'approximations assez douteuses...
>>>>
>>>
>>> c'est mieux que d'�tre d�gout� et d'abandonner.
>>
>> EN quoi est-il plus simple de faire commencer le hello world par
>> int main(void) plut�t que int main() ?
>>
>> Le premier est correct, le second utilis� sur le site est faux.
>
>R�f�rence, SVP.

ISO/IEC 9899:1999

5.1.2.2.1 Program startup

The function called at program startup is name main [...]
It shall be defined with a return type of int and with no parameters:
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any
names may be used [...]):
int main(int argc, char *argv[]) { /* ... */ }

or equivalent, or in SOME OTHER IMPLEMENTATION-DEFINED MANNER.

(emphase mienne).

tu as donc deux facons de declarer main() conformes. Le reste est dependant
de l'implementation...

beaucoup de compilo reconnaissent les vieilles declarations "K&R" (chez
qui main() est licite). Mais c'est au mieux obsolescent...

[Jean-Marc Bourguet]

Erwan David <er...@rail.eu.org> writes:

> R�sumons, le premier est correct, le deuxi�me est une forme batarde
> entre la verion d'avant la normalisation et celle d'apr�s

Ce qui ne la rend pas fausse.

> Tu as certainement une version pr�historique du K&R, qui parle de la
> version pr�-normalisation.

J'ai la 41i�me impression dat�e de d�cembre 2006 de la deuxi�me �dition,
celle qui a un tampon rouge "ANSI C" dessus. J'avais une impression
ant�rieure que je ne retrouve plus, mais je suis certain n'avoir jamais
poss�d� de premi�re �dition, j'ai commenc� le C suffisemment t�t pour
m'�tre frott� � du code K&R mais trop tard pour acheter autre chose que la
deuxi�me �dition.

Je ne dis pas que main n'est pas parfois d�fini autrement que

main() { ... }

mais je viens de regarder, je n'ai pas vu de cas (ce qui est pire que dans
mon souvenir, je croyais qu'ils avaient modifi�s au moins les premi�res
occurences). J'ai par contre compt� 17 occurences de main d�fini comme
ci-dessus.

Les fonctions sont g�n�ralement d�clar�es en dehors des fonctions o� elles
sont utilis�es. Mais au moins p 163 et p 187, ce n'est pas le cas. (C'est
l�g�rement mieux que dans mon souvenir, je n'ai pas trouv� de cas avec des
fonctions de la lib standard et je pensais qu'il y en avait; mais je n'ai
pas tout regard� non plus).

[Jean-Marc Bourguet]

es...@lain.home (Marc Espie) writes:

> In article <87wr0mo...@news.bourguet.org>,
> Jean-Marc Bourguet <j...@bourguet.org> wrote:
>>Erwan David <er...@rail.eu.org> writes:
>>
>>> Stephane Legras-Decussy <ad...@facebook.com> �crivait�:
>>>
>>>> Le 24/08/2012 22:19, Tonton Th a �crit :
>>>>>
>>>>>
>>>>> Qui contient un certain nombre d'approximations assez douteuses...
>>>>>
>>>>
>>>> c'est mieux que d'�tre d�gout� et d'abandonner.
>>>
>>> EN quoi est-il plus simple de faire commencer le hello world par
>>> int main(void) plut�t que int main() ?
>>>
>>> Le premier est correct, le second utilis� sur le site est faux.
>>
>>R�f�rence, SVP.
>
> ISO/IEC 9899:1999
>
> 5.1.2.2.1 Program startup
>
> The function called at program startup is name main [...]
> It shall be defined with a return type of int and with no parameters:
> int main(void) { /* ... */ }
> or with two parameters (referred to here as argc and argv, though any
> names may be used [...]):
> int main(int argc, char *argv[]) { /* ... */ }
>
> or equivalent, or in SOME OTHER IMPLEMENTATION-DEFINED MANNER.

^^^^^^^^^^^^^

> (emphase mienne).
>
> tu as donc deux facons de declarer main() conformes. Le reste est dependant
> de l'implementation...

int main() est �quivalent � int main(void) pour ce qui concerne la
d�finition. (C'est l'aspect d�claration qui est diff�rent). Si tu penses
que le *or equivalent* ne concerne que la deuxi�me forme, il me faut savoir
quel est ton raisonnement et pourquoi main serait un cas particulier sur ce
point.

[Marc Espie]

In article <87ipc6o...@news.bourguet.org>,

Le "or equivalent" est explicite par une note de bas de page, qui indique
que c'est l'utilisation d'un type equivalent a int, ou d'une declaration
equivalente de char *argv[] qui peut etre presente...

[Jean-Marc Bourguet]

Qu'est-ce qui te fait penser que le "and so on" de la note exclus `int
main() {}` comme d�finition �quivalente � `int main(void) {}` alors que
c'est le cas pour toutes les autre fonctions?

[Tonton Th]

On 08/25/2012 01:24 PM, Stephane Legras-Decussy wrote:

>> EN quoi est-il plus simple de faire commencer le hello world par
>> int main(void) plut�t que int main() ?
>>
>> Le premier est correct, le second utilis� sur le site est faux.
>
> parce qu'il faudrait expliquer "void" qui est tr�s compliqu� quand on
> est seulement � ce niveau du cours.

Peut-�tre est-ce toi qui n'arrive pas � comprendre...

> en pratique, cette absence de void, �a va provoquer quoi ?

Une insulte du compilateur ?

[Stephane Legras-Decussy]

Le 26/08/2012 00:29, Tonton Th a �crit :

>
>
> Peut-�tre est-ce toi qui n'arrive pas � comprendre...

simplement je me souviens parfaitement de ma 1�re minute
confront� au C, j'avais 15 ans en 87 ... void �a faisait pas envie
esth�tiquement ...

>
>> en pratique, cette absence de void, �a va provoquer quoi ?
>
> Une insulte du compilateur ?
>

excellent, tr�s formateur les warning, ce sera son 1er et pas son
dernier ...

[Stephane Legras-Decussy]

Le 25/08/2012 13:56, Marc Espie a écrit :
>
> Autant ne pas rentrer trop dans les details, je comprend, autant remplacer
> du code correct et pas plus complique par du code qui ne marche que sur
> certaines machines, c'est un peu cretin...

je serais curieux d'un exemple réel de machine où int main() ne
marche pas ...

le site du zéro n'est pas parfait mais c'est ce que se fait
de mieux dans le genre sympathique.

mon 1er cours d'info en fac, polycopié de 200 pages hyper dense
police courrier sur le Scheme. Probablement hyper exact et rigoureux.

45 étudiants le 1er cours, 5 étudiants au 2ème.

on dira ce qu'on voudra sur ce document, c'est un echec.

[Jean-Marc Bourguet]

Tonton Th <t...@la.bas.invalid> writes:

>> en pratique, cette absence de void, �a va provoquer quoi ?
>
> Une insulte du compilateur ?

Sur quelle base? La seule que je vois ce sont des warnings demandant
sp�cifiquement � v�rifier des choix stylistiques (genre Wstrict-prototypes,
-Wold-style-definition avec gcc). C'est pas que je ne les recommanderais
pas aux d�butants (bien au contraire, si je donnais un cours ils auraient �
trafiquer pour ne pas les utiliser), c'est que c'est stylistique et sans
effet sur main.

[Jean-Marc Bourguet]

Stephane Legras-Decussy <ad...@facebook.com> writes:

> Le 25/08/2012 13:56, Marc Espie a �crit :

>>
>> Autant ne pas rentrer trop dans les details, je comprend, autant remplacer
>> du code correct et pas plus complique par du code qui ne marche que sur
>> certaines machines, c'est un peu cretin...
>

> je serais curieux d'un exemple r�el de machine o� int main() ne
> marche pas ...

Je voudrais moi un raisonnement montrant que c'est conforme de le refuser.

> le site du z�ro n'est pas parfait

int f() {} utilis� dans le m�me tutorial me g�ne d�j� plus, �a emp�che le
compilateur de v�rifier que f est bien appel�e sans arguments. Et le
simple fait que je ne voudrais pas montrer �a fait que je montrerai int
main(void) parce que je me vois mal expliquer pourquoi int main() {} main
int f(void) {}.

[Jean-Marc Bourguet]

Stephane Legras-Decussy <ad...@facebook.com> writes:

> Le 25/08/2012 13:56, Marc Espie a �crit :

>>
>> Autant ne pas rentrer trop dans les details, je comprend, autant remplacer
>> du code correct et pas plus complique par du code qui ne marche que sur
>> certaines machines, c'est un peu cretin...
>

> je serais curieux d'un exemple r�el de machine o� int main() ne
> marche pas ...

Je voudrais moi un raisonnement montrant que c'est conforme de le refuser.

> le site du z�ro n'est pas parfait

int f() {} utilis� dans le m�me tutorial me g�ne d�j� plus, �a emp�che le
compilateur de v�rifier que f est bien appel�e sans arguments. Et le
simple fait que je ne voudrais pas montrer �a fait que je montrerai int

main(void) parce que je me vois mal expliquer pourquoi int main() {} mais

[Anonyme]

Le samedi 25 août 2012 18:50:09 UTC+2, Alexandre Bacquart a écrit :
> 2. Le site du z�ro (ou n'importe quel autre
>
> "tuto-kikoo-lol-apprend-C-en-3-minutes").
Est-il nécessaire de stigmatiser toute sa communauté en se basant simplement sur les dires d'un tutoriel mis avant ? Loin de moi l'idée de revendiquer l'entière bonne qualité du site en question, mais il faut tout de même avouer qu'il subsiste parallèlement des discussions intéressantes qui n'ont pas à être dénigrées.

[Alexandre Bacquart]

On 08/26/2012 05:25 PM, Anonyme wrote:
> Le samedi 25 ao�t 2012 18:50:09 UTC+2, Alexandre Bacquart a �crit :
>> 2. Le site du z�ro (ou n'importe quel autre
>>
>> "tuto-kikoo-lol-apprend-C-en-3-minutes").
> Est-il n�cessaire de stigmatiser toute sa communaut� en se basant simplement sur les dires d'un tutoriel mis avant ?

C'est du sarcasme anti-experts... j'aime bien les titiller :) En v�rit�,
je ne me complais pas dans cette id�e selon laquelle un tutoriel C est
n�cessairement mauvais. Mais j'en comprend les origines car C tol�re
assez mal le laxisme, il faut se m�fier de tout.

J'irai m�me plus loin : j'ai appris le C � une �poque o� il n'y avait
peu ou prou que le K&R � se mettre sous la dent. Et ce n'est pas
forc�ment un cadeau pour s'initier au C. Pour les bonnes habitudes,
peut-�tre, mais pour l'apprentissage, non. Pourtant, je connaissais d�j�
bien plusieurs assembleurs, ce qui est cens� faciliter la t�che.

Aujourd'hui, je pense que j'aurais pr�f�r� avoir un bon tutoriel sous la
main. Certains passages du K&R m'ont vraiment fait froncer les
sourcils... j'ai oubli� lesquels depuis, mais je me souviens tr�s bien
avoir pass� du temps sur les BBS � chercher d'autres sources de
documentation.

> Loin de moi l'id�e de revendiquer l'enti�re bonne qualit� du site en question,

Tu as s�rement constat� que je ne le critique pas. Comme je l'ai dis
plus loin, je consid�re que c'est le moins pire (jusqu'� ce qu'on me
prouve le contraire).

Pour le pire que j'ai vu en fran�ais (assez r�cent d'ailleurs) :
http://www.allprogramation.blogspot.fr/
L�, tout � coup, le site du z�ro passe pour un v�ritable joyau. Quand
les experts tombent sur ce genre d'horreurs, faut pas trop s'�tonner
qu'ils aient la rage d�s qu'on parle de tuto...

> mais il faut tout de m�me avouer qu'il subsiste parall�lement des discussions int�ressantes qui n'ont pas � �tre d�nigr�es.

Je ne fr�quente pas le site, je n'ai donc pas d'opinion sur les
discussions parall�les qui s'y d�roulent.


--
Alexandre

[JKB]

Le Sat, 25 Aug 2012 04:31:55 +0200,
Stephane Legras-Decussy <ad...@facebook.com> écrivait :

> Le 24/08/2012 22:19, Tonton Th a écrit :
>>
>>
>> Qui contient un certain nombre d'approximations assez douteuses...
>>
>

> c'est mieux que d'être dégouté et d'abandonner.
>
> quand on est à l'aise on cherche les erreurs en comparant
> avec le K&R ...

Et on doit faire une thérapie de 20 ans pour s'en sortir...

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

[JKB]

Le Sat, 25 Aug 2012 17:15:02 +0000 (UTC),
Marc Espie <es...@lain.home> écrivait :

> In article <50390241$0$16477$426a...@news.free.fr>,
> Alexandre Bacquart <tek512D...@free.fr> wrote:

>>Le monde de C évolue assez lentement (une révision de la norme

>>tous les 10 ans ~).
>
> Ca, ca veut rien dire. Le 'une revision toutes les dix ans', c'est le
> principe pour tous les langages normalises par l'ISO, que ce soit C,
> Fortran, ou C++.
>
> Ces deux-la ont bouge bien plus que C !

Pour le Fortran, ce n'était pas difficile. Il fallait procéder par
petits pas pour ne pas faire peur aux dinosaures avec des écailles
dont je suis. Le premier pas date de 1984 avec l'introduction des
structures (qui n'ont jamais été normalisées), et de 1988/1990 avec
l'introduction du format libre...

> Typiquement, il y a eu un gros blocage sur fortran, suivi par un putsch
> qui a donne d'enormes modifs vers 2000.
>
> Quant a C++, la norme 2011 revolutionne totalement les usages du langage
> par rapport a C++98...

Ce n'était franchement pas du luxe vus les aberrations de la STL et
les const char * qui traînaient un peu partout...

[Marc Espie]

In article <slrnk3m9f...@rayleigh.systella.fr>,

JKB <j...@koenigsberg.invalid> wrote:
>> Quant a C++, la norme 2011 revolutionne totalement les usages du langage
>> par rapport a C++98...
>
> Ce n'était franchement pas du luxe vus les aberrations de la STL et
> les const char * qui traînaient un peu partout...
>
> JKB

Marrant, ca c'est juste les mini-corrections. La revolution, c'est les
rvalue references, et tout ce que ca permet d'eviter en terme de copies
inutiles...

[Wykaaa]

Pascal06 a �crit :
> On 25 ao�t, 04:31, Stephane Legras-Decussy <ad...@facebook.com> wrote:
>> Le 24/08/2012 22:19, Tonton Th a crit :

>>
>>
>>
>>> Qui contient un certain nombre d'approximations assez douteuses...

>> c'est mieux que d' tre d gout et d'abandonner.
>>
>> quand on est l'aise on cherche les erreurs en comparant
>> avec le K&R ...
>
> Bonjour,
> je suis enti�rement d'accord avec toi. Je pr�f�re m'y remettre
> doucement, plut�t que d'�tre encore une fois rebut�. Je n'ai pas envie
> d'�tre un puriste non plus !

> D�j� qu'� la base je ne comprends l'utilit� de ces satan�s ";" en fin
> de ligne ! On est plus en 1960 !

Justement, c'est ce qui permet de ne pas se prendre la t�te avec des
ambigu�t�s. Les langages � la syntaxe laxiste ou farfelue (je pense en
particulier � Python et ses d�limitation de bloc d'instruction par
l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
dans un langage de programmation, et je suis sp�cialiste des langages et
des compilateurs/interpr�teurs) sont nuisibles � la qualit� du code et
contraires aux principes du g�nie logiciel (software engineering).
En C, on met un ; � la fin de chaque instruction (et non en fin de ligne
comme tu le dis. Ce n'est pas la m�me chose !) sans se poser de question
et c'est bien mieux ainsi. Il y a d�j� assez de pi�ges dans le langage
comme cela (avec les if (a=b) au lieu de if (a==b), par exemple, ou la
fameuse �quivalence pointeur/tableau qui a oblig� � inventer le delete
[] en C++).
Le sommet c'est quand m�me les espaces autoris�s dans les mots cl�s en
Fortran mais, � l'�poque (en 1953-54), la th�orie des automates et des
langages n'�tait pas encore bien d�velopp�e.

[Wykaaa]

Marc Espie a �crit :
> In article <k1adsn$n4h$1...@speranza.aioe.org>,
> Stephane Legras-Decussy <ad...@facebook.com> wrote:
>> Le 25/08/2012 13:18, Marc Espie a �crit :
>>> Ouais, mais on n'y apprend pas non plus que 2+2=5...
>> quoique pour des grandes valeurs de 2, on y arrive presque...
>>
>>
>> sans rire on apprend qu'on ne peut pas faire 2-3 ... et puis
>> plus tard, en 5�me on apprend qu'on peut.
>>
>> �a n'a jamais traumatis� personne ... si ?
>
> tu confonds des trucs qu'on n'apprend pas tout de suite avec des trucs
> completement faux...
>
> c'est un peu ca le probleme avec le site du zero: certains des idiomes qui
> y sont enseignes sont totalement non portables de facon gratuite.

Le site du z�ro porte bien son nom, on peut le dire. C'est un site
infr�quentable pour apprendre la programmation "propre".

[Wykaaa]

Jean-Marc Bourguet a �crit :

> Stephane Legras-Decussy <ad...@facebook.com> writes:
>
>> Le 25/08/2012 13:56, Marc Espie a �crit :
>>> Autant ne pas rentrer trop dans les details, je comprend, autant remplacer
>>> du code correct et pas plus complique par du code qui ne marche que sur
>>> certaines machines, c'est un peu cretin...
>> je serais curieux d'un exemple r�el de machine o� int main() ne
>> marche pas ...
>
> Je voudrais moi un raisonnement montrant que c'est conforme de le refuser.
>
>> le site du z�ro n'est pas parfait
>
> int f() {} utilis� dans le m�me tutorial me g�ne d�j� plus, �a emp�che le
> compilateur de v�rifier que f est bien appel�e sans arguments. Et le
> simple fait que je ne voudrais pas montrer �a fait que je montrerai int
> main(void) parce que je me vois mal expliquer pourquoi int main() {} mais
> int f(void) {}.
>
> A+
>

+1

[JKB]

Le Mon, 27 Aug 2012 11:04:41 +0000 (UTC),
Marc Espie <es...@lain.home> écrivait :

On est parfaitement d'accord. Mais tu admettras tout de même que des
fonctions de la STL qui demandaient explicitement un cast en const
char * dans un langage qui avait défini un objet string, ça faisait
désordre...

[JKB]

Le Mon, 27 Aug 2012 13:08:27 +0200,
Wykaaa <wyk...@yahoo.fr> écrivait :
> Pascal06 a écrit :

>> On 25 août, 04:31, Stephane Legras-Decussy <ad...@facebook.com> wrote:
>>> Le 24/08/2012 22:19, Tonton Th a crit :
>>>
>>>
>>>
>>>> Qui contient un certain nombre d'approximations assez douteuses...
>>> c'est mieux que d' tre d gout et d'abandonner.
>>>
>>> quand on est l'aise on cherche les erreurs en comparant
>>> avec le K&R ...
>>
>> Bonjour,

>> je suis entièrement d'accord avec toi. Je préfère m'y remettre
>> doucement, plutôt que d'être encore une fois rebuté. Je n'ai pas envie
>> d'être un puriste non plus !
>> Déjà qu'à la base je ne comprends l'utilité de ces satanés ";" en fin

>> de ligne ! On est plus en 1960 !
>

> Justement, c'est ce qui permet de ne pas se prendre la tête avec des
> ambiguïtés. Les langages à la syntaxe laxiste ou farfelue (je pense en
> particulier à Python et ses délimitation de bloc d'instruction par

> l'indentation qui est bien la chose a plus stupide que j'ai jamais vue

> dans un langage de programmation, et je suis spécialiste des langages et
> des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
> contraires aux principes du génie logiciel (software engineering).

Dans mes bras ;-)

> En C, on met un ; à la fin de chaque instruction (et non en fin de ligne
> comme tu le dis. Ce n'est pas la même chose !) sans se poser de question
> et c'est bien mieux ainsi. Il y a déjà assez de pièges dans le langage

> comme cela (avec les if (a=b) au lieu de if (a==b), par exemple, ou la

> fameuse équivalence pointeur/tableau qui a obligé à inventer le delete
> [] en C++).

De toute façon, tout compilo un tant soit peut évolué devrait râler
sur if (a=b) et demander if ((a=b)).

> Le sommet c'est quand même les espaces autorisés dans les mots clés en
> Fortran mais, à l'époque (en 1953-54), la théorie des automates et des
> langages n'était pas encore bien développée.

Ce n'est le cas qu'en format fixe. Essaye un peu en format libre
pour voir ;-)

[Wykaaa]

Jean-Marc Bourguet a �crit :

Je suis agac�, d�s qu'on discute de livres sur le C, des r�f�rences
constantes au K&R, g�n�ralement pour l'encenser.
Je persiste et signe : le K&R est un des plus mauvais livres qui existe
sur le langage C (� part le delannoy :
http://www.amazon.fr/Langage-C-Claude-Delannoy/dp/2212111231, � �viter
absolument). La plupart des exemples montrent tout ce qu'il ne faut pas
�crire si l'on veut respecter les principes de bonne programmation (code
de qualit�). Je lutte depuis plus de 35 ans maintenant contre l'id�e que
le K&R est le bouquin qu'il faut. NON, NON et NON ! Le K&R est un
bouquin NUL pour apprendre le C !
Pour moi, le meilleur livre sur le langage C est le livre d'Harbison et
Steele : http://www.amazon.com/Reference-Manual-5th-Edition/dp/013089592X
Sinon, il y a, en fran�ais, le livre de Philippe Drix :
- http://livre.fnac.com/a1097476/Philippe-Drix-Langage-c-norme-ansi

[Wykaaa]

Alexandre Bacquart a �crit :
> On 08/24/2012 11:25 PM, Pascal06 wrote:
>> On Aug 24, 8:56 pm, Stephane Legras-Decussy<ad...@facebook.com>
>> wrote:
>>> Le 24/08/2012 09:31, pascal.pellizz...@gmail.com a crit :
>>>
>>>
>>>
>>> alors si d ja confront au C tu as t rebut , je ne conseille
>>> pas le K&R qui est exact, rigoureux et ... rebutant.
>
> Exact et rigoureux sont loin d'�tre des adjectifs... rebutants pour un
> tel langage.
>
>>> il faut un bouquin d'approche sympathique pour ne pas tre
>>> d gout et pour *s'amuser*
>
> Il ne me semble pas que l'OP ait beaucoup envie de s'amuser. �a tombe
> bien d'ailleurs, les compilateurs C manquent cruellement d'humour.
>
>>> une fois qu'on a exp riment quelque chose et vu que a marchait, on
>>> peut relire ce qu'en dit le K&R pour avoir les subtilit s.
>>>
>>> en fait pas besoin de bouquin, ce cours en ligne est excellent et le
>>> taux d'erreur est tr s bon ...
>>>
>>> http://www.siteduzero.com/tutoriel-3-14189-apprenez-a-programmer-en-c...
>>>
>>> en orient microcontroleur, ce qui est mon cr neau aussi, je te
>>> conseille les controleurs Atmel et l'outil de dev fourni ...
>>
>> Bonsoir,
>> Merci pour ce conseil...
>
> Mouais, bon.
>
>> J'ai effectivement regard� le site du "0", j'ai meme imprim� le
>> bouquin...
>
> Diantre, au prix des cartouches d'encre !
>
> Sinon, heu... un tutoriel, ce n'est pas un bouquin.
>
>> Mais je me suis presque fait incendi� (sur fr.sci.electronique) en
>> parlant de �a !
>> D'ou ma question ici...
>
> Huhuhu ! J'ai vu le troll venir d�s ton tout premier post, mais c'est
> pas ta faute. Le sujet du "bouquin pour apprendre le C" est assez
> fameux. Il revient � peu pr�s... une fois par an. Et � chaque fois c'est
> la m�me rengaine, � savoir :
>
> 1. L'ind�tr�nable et incontournable K&R. Peu p�dagogique et patati et
> patata, c'est vrai. Mais une tr�s bonne r�f�rence (autrement dit : pas
> blind� d'erreurs). Cela tient en grande partie au fait que les auteurs
> originaux sont aussi les auteurs du langage, et aussi que ce bouquin a
> �t� pendant plus de 10 ans... la seule et unique r�f�rence (il pr�c�de
> la premi�re normalisation d'autant). Ces 2 arguments ne sont toutefois
> pas une raison suffisante pour en faire un bon livre p�dagogique. Cr�er
> des langages, �crire des bouquins et enseigner sont 3 activit�s bien
> diff�rentes.
>
> Un autre probl�me du K&R, c'est que malgr� les r�-�ditions, il n'est pas
> tr�s � jour avec les derni�res normes et pas du tout avec la derni�re en
> date, � savoir celle de 2011 (C11, mais � ce niveau, je serais �tonn�
> qu'il existe un bouquin quelconque). La pr�c�dente norme date de 1999
> (C99) et m�me celle-l�, il me semble que la derni�re �dition du K&R
> fran�ais (2004) n'en parle pas (quant au K&R anglais, la derni�re
> �dition date de... 1988 ! autrement dit, la derni�re �dition anglophone
> date d'avant la premi�re normalisation).
>
> Est-ce que c'est si grave ? Pas vraiment en fait. La norme ne change
> plus tellement au point de rendre le K&R obsol�te. Le monde de C �volue
> assez lentement (une r�vision de la norme tous les 10 ans ~). La norme
> C11 est en fait un b�b� tout beau tout neuf et encore assez peu
> exploit�e. Les programmeurs C ne sont pas du genre sur les
> starting-blocks mais plut�t dans les gradins � regarder les plus
> t�m�raires se casser la gueule avec un certain amusement (faut bien
> qu'ils rigolent un peu parfois). Ils sont peu enclins � adopter les
> nouveaut�s tant qu'elles n'ont pas vraiment fait leur preuves. Ce genre
> de choses prend du temps.
>
> Sinon, il y a aussi le "Harbison & Steele" assez souvent cit�, mais je
> ne le connais pas. Cependant, je ne me souviens pas avoir lu de
> critiques n�gatives � son sujet, c'est s�rement qu'il doit valoir
> quelque-chose. On dit qu'il est plus � jour que le K&R vis � vis des
> derni�res "nouveaut�s" de C (ce qui n'est pas un exploit vous me direz).

>
>
> 2. Le site du z�ro (ou n'importe quel autre
> "tuto-kikoo-lol-apprend-C-en-3-minutes").
>

> Pour que tu comprennes bien la situation (rapport aux �meutes que tu
> d�clenches en en parlant). Chaque ann�e on y a droit au site du z�ro !
> Oui, m�me ici sur les terres sacr�es de f.c.l.c. Donc on ne peut pas y
> �chapper, quoiqu'on en dise, qu'on le descende, qu'on l'allume, qu'on
> l'atomise, qu'on l'�jecte sur Mars � coup de pied au cul... il y a
> toujours, *TOUJOURS* un martien qui d�barque pour nous le revendre. Et
> dans la foul�e, un �lu local intervient, en substance : "c'est tr�s
> mauvais et blablabla". Syst�matique.
>
> Il suffit d'ailleurs de taper "language C" dans le moteur que tout le
> monde conna�t pour comprendre que c'est de toute �vidence LA r�f�rence
> francophone pour s'initier au C sur le r�seau de r�seaux.
>
> L'explication des �meutes, c'est que s'il existe un langage qui n'est
> pas fait pour les d�butants, c'est bien C. Non pas qu'il soit si
> difficile � aborder, mais il demande en principe des ann�es pour �tre
> ma�tris�. C'est un langage syst�me, il t'ouvre toutes les portes y
> compris celle de la pi�ce avec un gros bouton rouge.
>
> D'autre part, le temps passant et les paradigmes de programmation ayant
> quelque peu �volu�, on peut dire que certaines pratiques courantes en C
> sont assez pass�es de mode. Sa biblioth�que standard expose encore des
> fonctions qui auraient d� �tre rel�gu�es aux oubliettes depuis la nuit
> des temps (voire n'auraient jamais d� exister, comme le machiav�lique et
> n�anmoins si s�duisant gets(), pour ne citer que lui). C a aussi une
> f�cheuse tendance � donner de mauvaises habitudes un peu g�nantes quand
> on passe � d'autres langages (et pas que C++).
>
> Tout ceci est totalement incompatible avec le concept de tutoriel qui
> fait figure de chien dans un jeu de quilles. Voil� pour les rires,
> quolibets, voire �meutes d'experts. Ici, comme les rares endroits o�
> l'on peut trouver des experts en C, tu auras � peu pr�s le m�me genre de
> r�actions : "H� ho ! On parle de l'illustre et inf�me C bordel ! Faut
> arr�ter la d�conne l� hein !". Bon, ils seront moins grossiers, mais le
> coeur y sera. C'est un sujet de choix pour des enfilades interminables
> (et non-termin�es). D'ailleurs, comme tu peux le constater, �a a d�j�
> commenc� (mais c'est bien, �a met un peu d'ambiance dans ces lieux
> poussi�reux).
>
> Mon avis (tout � fait personnel), c'est qu'au fond, on a beau �tre un
> vieux de la vieille du C pour qui les tutoriels sur ce langage ne sont
> rien d'autre que des attrapes nigauds d'une m�diocrit� sans nom, ce
> tutoriel l� n'est pas aussi mauvais que ceux qui ne prennent pas
> toujours la peine d'y jeter leur oeil averti veulent bien le faire
> croire. Certes, un puriste y trouvera toujours quelque-chose � redire,
> mais il ne s'y attardera gu�re non plus (�tant � priori expert, il n'a
> pas besoin de tutoriel, lui). Cependant il faut rester honn�te : il y a
> plusieurs tutoriels en fran�ais sur le net pour le C, aussi h�r�tique
> que ce concept puisse para�tre. Et celui-l� est peut �tre bien le
> meilleur d'entre tous. Car si les grands-sages-experts ici bas le
> descendront avec une facilit� d�concertante, dans les faits ils auront
> beaucoup de difficult�s � te proposer mieux.
>
> Bref, plus on conna�t le C, plus l'id�e de tutoriel est contre-nature.
>
>
> 3. Le site d'Emmanuel (http://www.bien-programmer.fr/index.php). Ce
> n'est pas un vulgaire tutoriel et on y apprend pas � faire des trucs
> rigolos d�s le premier programme, certes. �a manque cruellement
> d'empathie pour le pauvre d�butant, certes (c'est pas dans la nature du
> personnage ;)). Mais apr�s tout on est pas l� pour rigoler. C'est
> surtout assez formel, pr�cis et *correct* (ce qui est rare) et plein de
> bon conseils pour �viter les mauvaises habitudes. Et il y a quand-m�me
> une initiation. Et en fran�ais.
>
> Petit message pour Emmanuel : tu devrais peut-�tre lancer un appel �
> cotisations pour le r�f�rencement de ton site... enfin bon, vu les news,
> peut-�tre que tu t'en fous et que tu pr�f�res s�vir sur developpez.com
> jusqu'� nouvel ordre :)
>
>
> 4. f.c.l.c : le forum ici pr�sent. C'est vrai qu'il a l'air mort le
> bled, mais c'est un leurre pour tromper l'ennemi. Tous les grabataires
> francophones experts du C sont l�, tapis dans l'ombre, pr�ts � bondir
> sur le premier semi-d�butant qui aurait l'audace de r�pondre une
> connerie � la moindre question (et m�me ceux qui r�pondent bien de toute
> fa�ons, ils trouvent toujours une bonne raison de contredire un truc,
> aussi s�r qu'un bon vieux compilo qui te les brise pour un b�te
> point-virgule oubli�). Ne *jamais* h�siter � poser des questions de
> parfait d�butant ici. M�me souvent... �a risques pas de saouler, au
> contraire, �a mettra un peu de vie dans cette pension de retraite !
>
>
> 5. Pour finir, les plus mauvais tutoriels qui soient pour s'initier au
> C, les normes ISO (enfin les derniers drafts du pauvre plut�t) :
>
> C99
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
>
> C11
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
>
> Un bon moyen pour d�gouter le petit fr�re qui te fait de l'ombre.
>
>
>
J'aime assez ton discours ;-)

Wykaaa (un expert langage qui a d�velopp�, en �quipe, un compilateur C
et qui vient de se... r�veiller)

[Marc Boyer]

Le 27-08-2012, Wykaaa <wyk...@yahoo.fr> a écrit :
> Pour moi, le meilleur livre sur le langage C est le livre d'Harbison et
> Steele : http://www.amazon.com/Reference-Manual-5th-Edition/dp/013089592X

Oui, mais dans mon souvenir, c'est un livre de *références*.
Ca permet à qui sait déjà programmer en C de retrouver les subtilités
de la norme. Ca ne me semble pas un langage pour apprendre à programmer.

> Sinon, il y a, en français, le livre de Philippe Drix :
> - http://livre.fnac.com/a1097476/Philippe-Drix-Langage-c-norme-ansi

Je prends note.

Marc Boyer
--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet

[Richard Delorme]

Le 27/08/2012 13:08, Wykaaa a écrit :

> Les langages à la syntaxe laxiste ou farfelue (je pense en

> particulier à Python et ses délimitation de bloc d'instruction par

> l'indentation qui est bien la chose a plus stupide que j'ai jamais vue

> dans un langage de programmation, et je suis spécialiste des langages et

> des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
> contraires aux principes du génie logiciel (software engineering).

Je comprends que l'on puisse ne pas apprécier le principe de
délimitation de blocs par l'indentation de Python, mais je le comprends
en tant qu'opinion ou goût personnel. Or là j'ai l'impression que tu as
des faits à avancer. Aussi je pose la question : En quoi est-ce nuisible
à la qualité du code et contraire aux principes du génie logiciel ?

--
Richard

[Wykaaa]

Richard Delorme a écrit :

Parce que l'indentation ne peut être exprimée correctement en BNF et
qu'une simple erreur dans l'indentation peut produire un gros bogue que
et que l'analyseur syntaxique ne peut pas faire tous les contrôles
nécessaires.
Dans le langage naturel, tu l'exprime comment l'indentation (lier des
phrases qui se suivent entre elles snas conjonction de coordination) ?
Par le ton. C'est ce qui se produit avec les blocs d'instructions par
indentation en Python. Ca ne fait pas partie à prpoprement parlé du
langage (qu'il soit naturel ou artificiel). C'est "extra syntaxique".

J'espère avoir été clair pour te montrer que ce n'est pas par goût
personnel mais que c'est antinomique avec la notion de langage (surtout
formel mais pas que) mais ce n'est pas évident à expliquer sans formalisme.

[Jean-Marc Bourguet]

Wykaaa <wyk...@yahoo.fr> writes:

> Richard Delorme a écrit :
>> Le 27/08/2012 13:08, Wykaaa a écrit :
>>
>>> Les langages à la syntaxe laxiste ou farfelue (je pense en
>>> particulier à Python et ses délimitation de bloc d'instruction par
>>> l'indentation qui est bien la chose a plus stupide que j'ai jamais vue
>>> dans un langage de programmation, et je suis spécialiste des langages et
>>> des compilateurs/interpréteurs) sont nuisibles à la qualité du code et
>>> contraires aux principes du génie logiciel (software engineering).
>>
>> Je comprends que l'on puisse ne pas apprécier le principe de délimitation
>> de blocs par l'indentation de Python, mais je le comprends en tant
>> qu'opinion ou goût personnel. Or là j'ai l'impression que tu as des faits
>> à avancer. Aussi je pose la question : En quoi est-ce nuisible à la
>> qualité du code et contraire aux principes du génie logiciel ?
>>
> Parce que l'indentation ne peut être exprimée correctement en BNF

Avoir le lexeur qui génère des symboles indent/outdent me semble une
technique évidente.

> et qu'une simple erreur dans l'indentation peut produire un gros bogue

D'après mon expérience, quand l'indentation et les accolades ne
correspondent pas dans un programme en C, l'indentation est beaucoup plus
souvent juste que les accolades. Je comprends donc très bien qu'on tente de
faire de l'indentation la source de la structuration plutôt qu'une simple
aide à la lecture, même si je n'ai pas assez écrit (ni surtout maintenu en
groupe) de Python ou d'Haskell pour avoir un avis éclairé.

> que et que l'analyseur syntaxique ne peut pas faire tous les contrôles
> nécessaires.

A quoi tu penses? (Comparé à un "end if" ou un "end func toto", je vois
quels contrôles supplémentaires sont possibles, c'est comparé à un "}" que
je ne vois pas).

[Damien Wyart]

> > > Je comprends que l'on puisse ne pas apprécier le principe de
> > > délimitation de blocs par l'indentation de Python, mais je le
> > > comprends en tant qu'opinion ou goût personnel. Or là j'ai
> > > l'impression que tu as des faits à avancer. Aussi je pose la
> > > question : En quoi est-ce nuisible à la qualité du code et
> > > contraire aux principes du génie logiciel ?

> > Parce que l'indentation ne peut être exprimée correctement en BNF

* Jean-Marc Bourguet <j...@bourguet.org> in fr.comp.lang.c:

> Avoir le lexeur qui génère des symboles indent/outdent me semble une
> technique évidente.

C'est en effet ce qui est expliqué ici :
http://docs.python.org/reference/lexical_analysis.html#indentation

Et la grammaire officielle contient bien la notion d'indentation :
http://docs.python.org/reference/grammar.html

> > [...] que et que l'analyseur syntaxique ne peut pas faire tous les

> > contrôles nécessaires.

> A quoi tu penses? (Comparé à un "end if" ou un "end func toto", je
> vois quels contrôles supplémentaires sont possibles, c'est comparé
> à un "}" que je ne vois pas).

Pareil, je veux bien que Wykaaa détaille un peu plus ce point...

--
DW

[JKB]

Le Mon, 27 Aug 2012 21:27:47 +0200,
Richard Delorme <abu...@nospam.fr> écrivait :

Parce qu'il n'y a rien qui ressemble plus à une tabulation qu'une
suite d'espaces et que le résultat est catastrophique.

[Wykaaa]

Damien Wyart a écrit :

>>>> Je comprends que l'on puisse ne pas apprécier le principe de
>>>> délimitation de blocs par l'indentation de Python, mais je le
>>>> comprends en tant qu'opinion ou goût personnel. Or là j'ai
>>>> l'impression que tu as des faits à avancer. Aussi je pose la
>>>> question : En quoi est-ce nuisible à la qualité du code et
>>>> contraire aux principes du génie logiciel ?
>
>>> Parce que l'indentation ne peut être exprimée correctement en BNF
>
> * Jean-Marc Bourguet <j...@bourguet.org> in fr.comp.lang.c:
>> Avoir le lexeur qui génère des symboles indent/outdent me semble une
>> technique évidente.
>
> C'est en effet ce qui est expliqué ici :
> http://docs.python.org/reference/lexical_analysis.html#indentation

On voit bien que ce trait de langage complique inutilement l'analyse et
rend le code, à priori correct, erronné.

>
> Et la grammaire officielle contient bien la notion d'indentation :
> http://docs.python.org/reference/grammar.html
>
>>> [...] que et que l'analyseur syntaxique ne peut pas faire tous les
>>> contrôles nécessaires.
>
>> A quoi tu penses? (Comparé à un "end if" ou un "end func toto", je
>> vois quels contrôles supplémentaires sont possibles, c'est comparé
>> à un "}" que je ne vois pas).
>
> Pareil, je veux bien que Wykaaa détaille un peu plus ce point...
>

Le parenthésage par accolades, il n'y a pas plus simple.

Il faut considérer les langages de Dyck (voir :
http://fr.wikipedia.org/wiki/Langage_de_Dyck)
On voit que c'est très facile de vérifier que c'est bien parenthésé,
même s'il y a plusieurs sortes de parenthèses. C'est pour cela que, dans
un langage "bien foutu", les paires d'accolades ou les couples begin/end
(comme en Pascal ou Ada) sont les plus adéquats pour délimiter des blocs
d'instructions. De plus, il n'y a pas la règle (absurde) de ne pas faire
chevaucher l'indentation sur plusieurs lignes par des "backslahes". On
peut disposer les instructions comme on veut sur plusieurs lignes sans
ambiguïté.
Voilà ;-)
J'espère avoir répondu à vos questions.

[Jean-Marc Bourguet]

Wykaaa <wyk...@yahoo.fr> writes:

> Damien Wyart a écrit :
>>>>> Je comprends que l'on puisse ne pas apprécier le principe de
>>>>> délimitation de blocs par l'indentation de Python, mais je le
>>>>> comprends en tant qu'opinion ou goût personnel. Or là j'ai
>>>>> l'impression que tu as des faits à avancer. Aussi je pose la
>>>>> question : En quoi est-ce nuisible à la qualité du code et
>>>>> contraire aux principes du génie logiciel ?
>>
>>>> Parce que l'indentation ne peut être exprimée correctement en BNF
>>
>> * Jean-Marc Bourguet <j...@bourguet.org> in fr.comp.lang.c:
>>> Avoir le lexeur qui génère des symboles indent/outdent me semble une
>>> technique évidente.
>>
>> C'est en effet ce qui est expliqué ici :
>> http://docs.python.org/reference/lexical_analysis.html#indentation
>
> On voit bien que ce trait de langage complique inutilement l'analyse et
> rend le code, à priori correct, erronné.

Ah, tu parles de l'implementation, pas de l'utilisation.

C'est rien comme probleme par rapport a faire fonctionner correctement
les attributs en Ada ou les typedefs en C. Et je ne parle pas de la
syntaxe du C++ qui dans le genre merite une categorie a part.

[Manuel Pégourié-Gonnard]

JKB scripsit :

> Le Mon, 27 Aug 2012 21:27:47 +0200,
> Richard Delorme <abu...@nospam.fr> écrivait :

>> Je comprends que l'on puisse ne pas apprécier le principe de
>> délimitation de blocs par l'indentation de Python, mais je le comprends
>> en tant qu'opinion ou goût personnel. Or là j'ai l'impression que tu as
>> des faits à avancer. Aussi je pose la question : En quoi est-ce nuisible
>> à la qualité du code et contraire aux principes du génie logiciel ?
>
> Parce qu'il n'y a rien qui ressemble plus à une tabulation qu'une
> suite d'espaces et que le résultat est catastrophique.
>

Il me semble que c'est à ça que sert l'option -t de l'interpréteur
python.

(Sans parler du fait que les éditeurs décents ont des options pour ça,
par exemple 'set list' sous vim.)

--
Manuel Pégourié-Gonnard - http://people.math.jussieu.fr/~mpg/

[JKB]

Le Tue, 28 Aug 2012 10:42:45 +0200 (CEST),
Manuel Pégourié-Gonnard <m...@elzevir.fr> écrivait :

Ce n'est pas parce qu'il y a des moyens de contourner la chose que
ce n'est pas un choix que je qualifie de débile. J'ai des souvenirs
de scripts d'installation qui se baugeaient lamentablement sur de
telles erreurs.

Ce qui me dérange certainement le plus, c'est qu'on mélange avec
cette histoire d'indentation le fond et la forme, ce qui ne devrait
jamais être le cas. Lorsque tu écris un truc comme :

begin
sldkfjsldkj
lsdkfjsldkfjlsk
slkdfjlskdfjlk
end

ton bloc est parfaitement délimité et explicitement délimité.
L'indentation est alors plus une hygiène de vie et une bonne
habitude de codage.

[Wykaaa]

Jean-Marc Bourguet a écrit :

> Wykaaa <wyk...@yahoo.fr> writes:
>
>> Damien Wyart a écrit :
>>>>>> Je comprends que l'on puisse ne pas apprécier le principe de
>>>>>> délimitation de blocs par l'indentation de Python, mais je le
>>>>>> comprends en tant qu'opinion ou goût personnel. Or là j'ai
>>>>>> l'impression que tu as des faits à avancer. Aussi je pose la
>>>>>> question : En quoi est-ce nuisible à la qualité du code et
>>>>>> contraire aux principes du génie logiciel ?
>>>>> Parce que l'indentation ne peut être exprimée correctement en BNF
>>> * Jean-Marc Bourguet <j...@bourguet.org> in fr.comp.lang.c:
>>>> Avoir le lexeur qui génère des symboles indent/outdent me semble une
>>>> technique évidente.
>>> C'est en effet ce qui est expliqué ici :
>>> http://docs.python.org/reference/lexical_analysis.html#indentation
>> On voit bien que ce trait de langage complique inutilement l'analyse et
>> rend le code, à priori correct, erronné.
>
> Ah, tu parles de l'implementation, pas de l'utilisation.

Oui. Désolé mais c'est mon réflexe d'implémenteur de compilateurs...

>
> C'est rien comme probleme par rapport a faire fonctionner correctement
> les attributs en Ada ou les typedefs en C. Et je ne parle pas de la
> syntaxe du C++ qui dans le genre merite une categorie a part.
>
> A+
>

Les attributs en ADA c'est pas la mort. Par contre les typedef en C,
c'est débile car cela oblige à faire des aller-retours entre l'analyse
lexicale et l'analyse syntaxique alors que ces 2 phases devraient
s'enchaîner en séquence comme dans tout bon compilo qui se respecte. Il
y a aussi le cas du PL/1 avec les déclarations qui peuvent se situer
après leur utilisation et les tableaux de "labels" (étiquettes) qui
rendent la grammaire non totalement "context-free".

Je suis d'accord avec toi sur le C++ qui est vraiment très à part...
C'est le seul langage que je connaisse qui possède des mots-clés avec
des "_" mais ceci n'a rien à voir avec notre discussion...

[Wykaaa]

JKB a écrit :

On ne peut qu'acquiécer à 100% à tes remarques, en particulier sur le
mélange de la forme et du fond , ce qui est un comble pour un langage
formel car cela mélange la syntaxe et la sémantique, d'où les ambiguïtés
dans certains cas.

[Jean-Marc Bourguet]

Wykaaa <wyk...@yahoo.fr> writes:

> Jean-Marc Bourguet a écrit :

>> Ah, tu parles de l'implementation, pas de l'utilisation.
>
> Oui. Désolé mais c'est mon réflexe d'implémenteur de compilateurs...

>> C'est rien comme probleme par rapport a faire fonctionner correctement
>> les attributs en Ada ou les typedefs en C. Et je ne parle pas de la
>> syntaxe du C++ qui dans le genre merite une categorie a part.
>

> Les attributs en ADA c'est pas la mort.

J'ai pas dit ca. Mais il me semble que les implementer demande du
feedback du parseur vers le lexeur (de memoire, c'est ce qu'on avait
dans notre parseur VHDL, en general VHDL est plus complexe de l'Ada a
parser mais il ne me semble pas qu'il y ait une difference sur ce
point), ce qui ne me semble pas etre le cas pour rendre l'indentation
significative.

> Par contre les typedef en C, c'est débile car cela oblige à faire des
> aller-retours entre l'analyse lexicale et l'analyse syntaxique alors
> que ces 2 phases devraient s'enchaîner en séquence comme dans tout bon
> compilo qui se respecte.

Sans parler du petit jeu pour arriver a parser des choses comme

typedef int foo; typedef int foo;
void f() { void f() {
struct foo { ... }; struct foo { ... };
int foo; foo i;

[Tonton Th]

On 08/28/2012 12:57 PM, Wykaaa wrote:

> Par contre les typedef en C, c'est débile car cela oblige à faire des
> aller-retours entre l'analyse lexicale et l'analyse syntaxique alors que
> ces 2 phases devraient s'enchaîner en séquence comme dans tout bon
> compilo qui se respecte.

Sans compter que lors de la lecture d'un code inconnu, l'abus
de typedef nécessite aussi de trops nombreux aller-retours entre
les .h et les .c concernés.

--

Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/

[Richard Delorme]

Ok, la difficulté n'est donc pas du côté de l'utilisateur du langage,
mais dans son implémentation. Je préfère que ce soit de ce côté que de
l'autre.

Une petite citation, qui montre que l'idée d'utiliser l'indentation
n'est antérieure à Python, et dans de grands esprits :

We will perhaps eventually be writing only small modules which are
identified by name as they are used to build larger ones, so that
devices like indentation, rather than delimiters, might become feasible
for expressing local structure in the source language.

–Donald E. Knuth, “Structured Programming with goto Statements”,
Computing Surveys, Vol 6 No 4, Dec. 1974


--
Richard

[Richard Delorme]

Le 28/08/2012 08:19, JKB a écrit :
> Le Mon, 27 Aug 2012 21:27:47 +0200,
> Richard Delorme <abu...@nospam.fr> écrivait :

>> Je comprends que l'on puisse ne pas apprécier le principe de
>> délimitation de blocs par l'indentation de Python, mais je le comprends
>> en tant qu'opinion ou goût personnel. Or là j'ai l'impression que tu as
>> des faits à avancer. Aussi je pose la question : En quoi est-ce nuisible
>> à la qualité du code et contraire aux principes du génie logiciel ?
>
> Parce qu'il n'y a rien qui ressemble plus à une tabulation qu'une
> suite d'espaces et que le résultat est catastrophique.
>

C'est drôle d'apprécier l'indentation au point d'indenter ses messages
dans Usenet, et de la détester dans un langage qui l'impose... ;-)

--
Richard
"Est fou celui qui cherche la logique au fond de l'âme humaine."
O'brother - frères Cohen.

[wykaaa]

Le 28/08/12 18:41, Richard Delorme a écrit :

Je ne me rappelais plus que Donald Knuth (que j'admire) avait émis cette
idée, qui plus est, dans un article que je connais pourtant bien (il est
vrai que c'est un long article !). D'un autre côté, on était dans les
années 70 et on ne savait pas encore tout ce que l'on sait sur les
aspects qualité du logiciel (Mac Call, ça date de 77...)

[Francois Lafont]

Le 28/08/2012 19:57, wykaaa a écrit :

> D'un autre côté, on était dans les
> années 70 et on ne savait pas encore tout ce que l'on sait sur les
> aspects qualité du logiciel (Mac Call, ça date de 77...)

Moi qui croyait que les idées de Knuth étaient atemporelles... ;-)


--
François Lafont

[Erwan David]

Richard Delorme <abu...@nospam.fr> écrivait :

> Le 28/08/2012 08:19, JKB a écrit :
>> Le Mon, 27 Aug 2012 21:27:47 +0200,
>> Richard Delorme <abu...@nospam.fr> écrivait :
>
>>> Je comprends que l'on puisse ne pas apprécier le principe de
>>> délimitation de blocs par l'indentation de Python, mais je le comprends
>>> en tant qu'opinion ou goût personnel. Or là j'ai l'impression que tu as
>>> des faits à avancer. Aussi je pose la question : En quoi est-ce nuisible
>>> à la qualité du code et contraire aux principes du génie logiciel ?
>>
>> Parce qu'il n'y a rien qui ressemble plus à une tabulation qu'une
>> suite d'espaces et que le résultat est catastrophique.
>>
>
> C'est drôle d'apprécier l'indentation au point d'indenter ses messages
> dans Usenet, et de la détester dans un langage qui l'impose... ;-)

Pas qui l'impose : qui lui donne une sémantique, et différente de
l'effet visuel obtenu.

5
6

Pour moi 5 et 6 sont indentés différements, pour python ils sont
indentés de même manière...



--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé

[JKB]

Le Tue, 28 Aug 2012 18:49:09 +0200,

Richard Delorme <abu...@nospam.fr> écrivait :
> Le 28/08/2012 08:19, JKB a écrit :
>> Le Mon, 27 Aug 2012 21:27:47 +0200,
>> Richard Delorme <abu...@nospam.fr> écrivait :
>
>>> Je comprends que l'on puisse ne pas apprécier le principe de
>>> délimitation de blocs par l'indentation de Python, mais je le comprends
>>> en tant qu'opinion ou goût personnel. Or là j'ai l'impression que tu as
>>> des faits à avancer. Aussi je pose la question : En quoi est-ce nuisible
>>> à la qualité du code et contraire aux principes du génie logiciel ?
>>
>> Parce qu'il n'y a rien qui ressemble plus à une tabulation qu'une
>> suite d'espaces et que le résultat est catastrophique.
>>
>
> C'est drôle d'apprécier l'indentation au point d'indenter ses messages
> dans Usenet, et de la détester dans un langage qui l'impose... ;-)

C'est surtout une habitude héritée de l'Underwood (que les moins de
vingt ans ne peuvent pas connaître) avec une tabulation au début du
paragraphe et vim qui la garde pour la ligne suivante...

[Richard Delorme]

Je ne comprends pas. On peut indenter comme on veut, mais il faut une
certaine cohérence quand même. Les deux indentations que tu montres ne
peuvent pas être présente dans le même bloc ; 5 et 6 ne sont donc pas
indentés de la même manière :

>>> def f():
... 5
... 6
File "<stdin>", line 3
6
^
IndentationError: unexpected indent

--
Richard

[Pascal06]

Non, vraiment, je suis impardonnable.
Je viens de retrouver un fichier daté de Décembre 2006 sur mon PC, que
j'avais téléchargé ici:
http://uuu.enseirb.fr/~kadionik/enseirb/e2/E3%20E/langageCembarque_enseirb.pdf

[Marc Boyer]

Le 29-08-2012, Pascal06 <pascal.p...@gmail.com> a écrit :
> Non, vraiment, je suis impardonnable.
> Je viens de retrouver un fichier daté de Décembre 2006 sur mon PC, que

>r j'avais téléchargé ici:
> http://uuu.enseirb.fr/~kadionik/enseirb/e2/E3%20E/langageCembarque_enseirb.pdf

Et dès qu'on entre dans les détails arrivent les premières erreurs:
p38: short utilise deux octets en mémoire
p39: "Le type char désigne un nombre entier signé codé sur 1 octet."

[Pascal06]

On 29 août, 13:12, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid>
wrote:

> Le 29-08-2012, Pascal06 <pascal.pellizz...@gmail.com> a écrit :

>   Et dès qu'on entre dans les détails arrivent les premières erreurs:
> p38: short utilise deux octets en mémoire
> p39: "Le type char désigne un nombre entier signé codé sur 1 octet."
>
>  Marc Boyer

Ah ouaiiiii carrément !
Punaise ça craint !

[Stephane Legras-Decussy]

Le 29/08/2012 13:12, Marc Boyer a écrit :
>
> Et dès qu'on entre dans les détails arrivent les premières erreurs:
> p38: short utilise deux octets en mémoire
> p39: "Le type char désigne un nombre entier signé codé sur 1 octet."
>

aïe ...

autant être faux par omission ça passe selon moi, mais là
le détail technique inutile et faux, ça tue ...

[JKB]

Le Wed, 29 Aug 2012 05:13:15 -0700 (PDT),
Pascal06 <pascal.p...@gmail.com> écrivait :

Oui, ça craint. Là, sous la main, tout de suite, j'ai un compilo C
dont le int est sur deux octets, le short sur 1 et le char, j'ai de
la chance sur 1 (manque de bol, il est non signé). Tout ce que la
norme dit, c'est :

sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <=
sizeof(long long)

Quant aux char, ils sont signés ou non selon l'humeur du compilo.
Personnellement, je force toujours le compilo à utiliser des
unsigned char. D'autres utilisent toujours des signed char, mais le
tout est de savoir ce qu'on manipule pour éviter les problèmes.

Coder en C en méconnaissant cela revient à s'exposer plus ou moins
tôt à de graves déconvenues allant d'une erreur de calcul à
l'explosion d'Ariane 5 au décollage.

[Marc Espie]

In article <slrnk3s4d...@rayleigh.systella.fr>,

JKB <j...@koenigsberg.invalid> wrote:
>Le Wed, 29 Aug 2012 05:13:15 -0700 (PDT),
>Pascal06 <pascal.p...@gmail.com> écrivait :
>> On 29 août, 13:12, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid>
>> wrote:
>>> Le 29-08-2012, Pascal06 <pascal.pellizz...@gmail.com> a écrit :
>>
>>>   Et dès qu'on entre dans les détails arrivent les premières erreurs:
>>> p38: short utilise deux octets en mémoire
>>> p39: "Le type char désigne un nombre entier signé codé sur 1 octet."
>>>
>>>  Marc Boyer
>> Ah ouaiiiii carrément !
>> Punaise ça craint !
>
> Oui, ça craint. Là, sous la main, tout de suite, j'ai un compilo C
> dont le int est sur deux octets, le short sur 1 et le char, j'ai de
> la chance sur 1 (manque de bol, il est non signé). Tout ce que la
> norme dit, c'est :
>
> sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <=
> sizeof(long long)
>
> Quant aux char, ils sont signés ou non selon l'humeur du compilo.
> Personnellement, je force toujours le compilo à utiliser des
> unsigned char. D'autres utilisent toujours des signed char, mais le
> tout est de savoir ce qu'on manipule pour éviter les problèmes.

Moui. Enfin, si tu utilises bien "octet" dans son acception moderne de
"8 bits" (tu serais bien capable de jouer sur les mots, vilain), ce
compilo n'est pas conforme.

5.2.4.2.1: Size of integer types:
SHRT_MAX +32767
ca va etre dur a rentrer dans 8 bits...

[Jean-Marc Bourguet]

Il y a une autre? (Byte oui, mais octet?)

> (tu serais bien capable de jouer sur les mots, vilain), ce
> compilo n'est pas conforme.
>
> 5.2.4.2.1: Size of integer types:
> SHRT_MAX +32767
> ca va etre dur a rentrer dans 8 bits...

Mais sur 2 octets comme affirme, ca passe tres bien :-)

[JKB]

Le Wed, 29 Aug 2012 14:04:44 +0000 (UTC),
Marc Espie <es...@lain.home> écrivait :

Je ne dis pas qu'il est conforme (vue la tronche du processeur, ça
m'étonnerait), je répondais simplement à une remarque ironique.

> 5.2.4.2.1: Size of integer types:
> SHRT_MAX +32767
> ca va etre dur a rentrer dans 8 bits...

D'autant que sur le compilo en question, cette valeur est fixée à
127. Mais comme personne ne l'utilise, ce n'est pas bien grave :-(

[Marc Boyer]

Le 29-08-2012, Pascal06 <pascal.p...@gmail.com> a écrit :

> On 29 août, 13:12, Marc Boyer <Marc.Bo...@cert.onera.fr.invalid>
> wrote:
>> Le 29-08-2012, Pascal06 <pascal.pellizz...@gmail.com> a écrit :
>
>>   Et dès qu'on entre dans les détails arrivent les premières erreurs:
>> p38: short utilise deux octets en mémoire
>> p39: "Le type char désigne un nombre entier signé codé sur 1 octet."

> Ah ouaiiiii carrément !
> Punaise ça craint !

J'ai du mal à évaluer si ta remarque est à prendre au premier ou au
second degrès.

Soit tu considères que ce n'est pas grave de savoir si c'est signé
ou pas, ou la taille que ça prends, tu veux juste avoir des codes
qui tombent en marche, et n'importe quel tutorial conviendra.

Soit tu veux un code qui fait ce qu'il est sensé faire même
si tu changes de compilateur, d'OS, et il vaut mieux éviter
de faire des hypothèses fausses (ou parfois vraies).

[Stephane Legras-Decussy]

Le 29/08/2012 14:57, JKB a écrit :
>
>
> sizeof(char)<= sizeof(short)<= sizeof(int)<= sizeof(long)<=
> sizeof(long long)
>
>

le égal est important, j'ai vu des machines où
tous les sizeof sont egaux.

en embarqué (par exemple), on peut devoir faire des manip 'octet', il
faut juste savoir que ce n'est plus de "vrai" C.

[Francois Lafont]

Le 29/08/2012 07:53, Richard Delorme a écrit :
> Le 28/08/2012 20:24, Erwan David a écrit :
>> Richard Delorme <abu...@nospam.fr> écrivait :

>>> C'est drôle d'apprécier l'indentation au point d'indenter ses messages
>>> dans Usenet, et de la détester dans un langage qui l'impose... ;-)
>>
>> Pas qui l'impose : qui lui donne une sémantique, et différente de
>> l'effet visuel obtenu.
>>
>> 5
>> 6
>>
>> Pour moi 5 et 6 sont indentés différements, pour python ils sont
>> indentés de même manière...
>
> Je ne comprends pas. On peut indenter comme on veut, mais il faut une
> certaine cohérence quand même. Les deux indentations que tu montres ne
> peuvent pas être présente dans le même bloc ; 5 et 6 ne sont donc pas
> indentés de la même manière :
>
>>>> def f():
> ... 5
> ... 6
> File "<stdin>", line 3
> 6
> ^
> IndentationError: unexpected indent

Oui moi aussi je n'ai pas compris. Il y a un truc qui m'échappe dans ce
qu'a dit Erwan.


--
François Lafont

[Samuel DEVULDER]

Le 30/08/2012 11:20, Francois Lafont a écrit :

>>>>> def f():
>> ... 5
>> ... 6
>> File "<stdin>", line 3
>> 6
>> ^
>> IndentationError: unexpected indent
>
> Oui moi aussi je n'ai pas compris. Il y a un truc qui m'échappe dans ce
> qu'a dit Erwan.

Si je peux ajouter mon grain de sel. Je pense qu'il fait référence aux
pbs de taille de tabulation. Ainsi sur certains outils ou terminaux le
tab vaut 8 espaces, et pour d'autres 4. Au final les chaines (\s=espace
\t=tab)

\s\s\s\s\s\s\s\s5
et:
\t6

représentant la même indentation seront affichées par un terminal (ou
par un outil d'édition) comme:

^ 5
^ 6
ou:
^ 5
^ 6

C'est à dire comme n'ayant pas "visuellement" la même indentation. Ca ne
change pas la sémantique du code (les niveaux d'indentations sont
identiques: 1 tabulation), mais peut induire une erreur de lecture chez
l'humain.

Le problème est lié aux mélange des conventions \s ou \t et n'est pas
propre à python puisque même en C on peut se retrouver avec une
indentations visuellement foireuses dans ce cas. A ce moment là les '{'
peuvent aider; mais je pense que lorsqu'un humain relis un code, il ne
regarde pas les accolades au 1er coup et se fie aux indentations en
priorité. Un code écrit sans indentation est considéré comme illisible:

if(test1){
if(test2) {
codeA();
if(test3)
codeB();
else
codeC();}
else
codeD();}
else
codeE();

sam.

[Antoine Leca]

Stephane Legras-Decussy écrivit :

> en embarqué (par exemple), on peut devoir faire des manip 'octet', il
> faut juste savoir que ce n'est plus de "vrai" C.

Je ne sais pas ce que tu entends par « manip 'octet' », mais je ne vois
pas pourquoi ce ne serait pas du « "vrai" C »...

Certes le code C logique (celui qu'il faut écrire) ne sera peut-être pas
strictement conforme en ce sens qu'il faudra peut-être faire des
impasses sur certaines architectures exotiques, et donc une éventuelle
(et théorique) compilation de ce programme sur une de ces machines
pourrait ne pas fonctionner... mais je ne suis pas sûr que ce soit
important au final pour la manipulation des dits octets.

De plus, si tu prends la précaution de masquer les résultats avec 0x255
avant de stocker dans des variables unsigned char, ce qui ne coûte que
le temps de l'écrire car la plupart des compilateurs qui optimisent vont
éliminer l'opération, alors les manipulations les plus courantes
resteront strictement conformes et donc --je suppose-- du vrai C.


Maintenant, si le code fait l'hypothèse que la machine est petit ou
gros-boutienne, et manipule directement 4 octets d'un coup au travers
d'un long, effectivement ce n'est pas (plus) du vrai C...


Antoine

[Marc Boyer]

Le 31-08-2012, Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> a écrit :
> Le problème est lié aux mélange des conventions \s ou \t et n'est pas
> propre à python puisque même en C on peut se retrouver avec une
> indentations visuellement foireuses dans ce cas. A ce moment là les '{'
> peuvent aider; mais je pense que lorsqu'un humain relis un code, il ne
> regarde pas les accolades au 1er coup et se fie aux indentations en
> priorité. Un code écrit sans indentation est considéré comme illisible:
>
> if(test1){
> if(test2) {
> codeA();
> if(test3)
> codeB();
> else
> codeC();}
> else
> codeD();}
> else
> codeE();

Sauf que n'importe quel outil sait regarder les séparateurs et
générer l'indentation (avec le style qui plait au lecteur: ANSI,
K&R, GNU...)

Avec python, le style est imposé par le langage.

Ca ne fait pas un argument pour ou contre, mais ça invalide
la comparaison.

[Tonton Th]

On 09/07/2012 02:39 PM, Marc Boyer wrote:

> Sauf que n'importe quel outil sait regarder les séparateurs et
> générer l'indentation (avec le style qui plait au lecteur: ANSI,
> K&R, GNU...)

omg = trolldi("Il manque le Whitesmiths dans la liste !");

[Samuel DEVULDER]

Le 07/09/2012 14:39, Marc Boyer a écrit :

>> (...); mais je pense que lorsqu'un _humain_ relis un code, il ne

>> regarde pas les accolades au 1er coup et se fie aux indentations en

>> priorité. Un code écrit sans indentation est considéré comme _illisible_:

>>
>> if(test1){
>> if(test2) {
>> codeA();
>> if(test3)
>> codeB();
>> else
>> codeC();}
>> else
>> codeD();}
>> else
>> codeE();
>
> Sauf que n'importe quel outil sait regarder les séparateurs et
> générer l'indentation (avec le style qui plait au lecteur: ANSI,
> K&R, GNU...)

Oui, mais je parlais du point de vue de la lisibilité _humaine_. Les
outils se débrouillent très bien avec les changements de convention dans
les tabulations. (Les exemples ci dessus montrent notamment que python
différencie parfaitement le mis-alignement lors de ces mélange et que le
mélange de \t et \s ne gène absolument pas le parseur.)

> Avec python, le style est imposé par le langage.

Mon propos n’était pas un pb de style mais un pb de mélange de
convention de tabulations. Cela n'est propre à aucun langage car tous
ont ce problème.

> Ca ne fait pas un argument pour ou contre, mais ça invalide
> la comparaison.

Il n'y a ni pour ni contre. Mon point de vue ne cherchait pas à comparer
les langages eux-même, mais je signalais que le pb soulevé par Erwan
était le mélange de convention de tabulation et cela est problématique
pour tous les langages lors de la relecture par l'interface
chaise-clavier (bref, par nous autres pauvres humains).

sam.

[Stephane Legras-Decussy]

Le 31/08/2012 12:54, Antoine Leca a écrit :
>
> Maintenant, si le code fait l'hypothèse que la machine est petit ou
> gros-boutienne, et manipule directement 4 octets d'un coup au travers
> d'un long, effectivement ce n'est pas (plus) du vrai C...
>

c'est exactement ce à quoi je pensais...