Je cherche un tutoriel imprimable sur le web pour apprendre le C avant
d'acheter un bouquin "de référence".
Je suis débutant en programmation mais je connais les scripts shell
(linux), le HTML ou encore un peu de PHP.
Quel tutoriel imprimable me conseillez-vous pour débuter ? Les 560 pages
de celui du site du zéro
(http://www.siteduzero.com/tuto-29-8-0-apprenez-a-programmer-en-c.html)
découragent un peu mon imprimante, même avec le recto-verso
automatique... Mais le style me plaît ! Existe-t-il quelque chose dans
le même esprit mais en plus condensé ?
Pour un main() sans return, l'accolade terminale du bloc de définition de la fonction doit jouer le rôle d'un return sec mais quid de la valeur de retour ?
De tête, ce doit être 0, la valeur de EXIT_SUCCESS. A confirmer.
Faux.
C'est le cas en C++, mais pas en C, et il y a explicitement un paragraphe de la norme qui explicite la difference (sachant qu'en C++, main n'est de toutes facons PAS une fonction comme les autres).
Comme le dit candide, c'est un `retour sec'. Sur la plupart des archis, les retours de valeurs entieres simples se font dans un registre du processeur. On recupere alors la valeur qui se trouvait dans le registre au moment du retour de la fonction, c'est-a-dire n'importe quoi.
Et pour faire plaisir a candide, qui sinon va encore fait chier que lui, tout ce qui l'interesse, c'est la norme, et pas les mecanismes de telle machine en particulier, la norme classe explicitement tout ceci en undefined behavior... bref, c'est une faute si on a un des prototypes standards de main.
Le seul cas ou ca n'en est pas une, c'est que la norme prevoit egalement que main() peut disposer de prototypes non-standards (qui doivent etre definis par l'implementation). C'est prevu pour autoriser les appels a la Unix, ou il traine un 3e parametre qui permet d'acceder a l'environnement, mais ca peut permettre a des implementation de definir un void main() (qui rappelons-le, n'a rien a faire dans un enseignement du C standard et portable).
In article <slrngbdeco.5so.Marc.Boyer@ubu.enseeiht.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
Pour un main() sans return, l'accolade terminale du bloc de définition
de la fonction doit jouer le rôle d'un return sec mais quid de la valeur
de retour ?
De tête, ce doit être 0, la valeur de EXIT_SUCCESS. A confirmer.
Faux.
C'est le cas en C++, mais pas en C, et il y a explicitement un paragraphe
de la norme qui explicite la difference (sachant qu'en C++, main n'est
de toutes facons PAS une fonction comme les autres).
Comme le dit candide, c'est un `retour sec'. Sur la plupart des archis,
les retours de valeurs entieres simples se font dans un registre du
processeur. On recupere alors la valeur qui se trouvait
dans le registre au moment du retour de la fonction, c'est-a-dire n'importe
quoi.
Et pour faire plaisir a candide, qui sinon va encore fait chier que lui,
tout ce qui l'interesse, c'est la norme, et pas les mecanismes de telle
machine en particulier, la norme classe explicitement tout ceci en
undefined behavior... bref, c'est une faute si on a un des prototypes
standards de main.
Le seul cas ou ca n'en est pas une, c'est que la norme prevoit egalement
que main() peut disposer de prototypes non-standards (qui doivent etre
definis par l'implementation). C'est prevu pour autoriser les appels a la
Unix, ou il traine un 3e parametre qui permet d'acceder a l'environnement,
mais ca peut permettre a des implementation de definir un void main()
(qui rappelons-le, n'a rien a faire dans un enseignement du C standard et
portable).
Pour un main() sans return, l'accolade terminale du bloc de définition de la fonction doit jouer le rôle d'un return sec mais quid de la valeur de retour ?
De tête, ce doit être 0, la valeur de EXIT_SUCCESS. A confirmer.
Faux.
C'est le cas en C++, mais pas en C, et il y a explicitement un paragraphe de la norme qui explicite la difference (sachant qu'en C++, main n'est de toutes facons PAS une fonction comme les autres).
Comme le dit candide, c'est un `retour sec'. Sur la plupart des archis, les retours de valeurs entieres simples se font dans un registre du processeur. On recupere alors la valeur qui se trouvait dans le registre au moment du retour de la fonction, c'est-a-dire n'importe quoi.
Et pour faire plaisir a candide, qui sinon va encore fait chier que lui, tout ce qui l'interesse, c'est la norme, et pas les mecanismes de telle machine en particulier, la norme classe explicitement tout ceci en undefined behavior... bref, c'est une faute si on a un des prototypes standards de main.
Le seul cas ou ca n'en est pas une, c'est que la norme prevoit egalement que main() peut disposer de prototypes non-standards (qui doivent etre definis par l'implementation). C'est prevu pour autoriser les appels a la Unix, ou il traine un 3e parametre qui permet d'acceder a l'environnement, mais ca peut permettre a des implementation de definir un void main() (qui rappelons-le, n'a rien a faire dans un enseignement du C standard et portable).
Thierry B.
--{ Marc Boyer a plopé ceci: }--
Marrant: chez moi, seuls 7 et 10 ne donnent pas de somme exacte. J'ai une Linux/gcc avec un x86 (Pentium 4...)
gcc flotte.c Pour n=5 somme-1.0=-0.000000 (%f) Pour n=5 somme-1.0=-1.110223e-16 (%e) Pour n=6 somme-1.0=-0.000000 (%f) Pour n=6 somme-1.0=-1.110223e-16 (%e)
gcc -O4 flotte.c Pour n=5, somme exacte Pour n=6, somme exacte
gcc version 4.0.3 (Debian 4.0.3-1) Pentium II (Deschutes)
J'peux scripter un truc plus approfondi, si yen a qui veulent :) Et si je retrouve ce $%#*}{ de cable série, je boote la ss20.
-- http://la.buvette.org/tech/
--{ Marc Boyer a plopé ceci: }--
Marrant: chez moi, seuls 7 et 10 ne donnent pas
de somme exacte. J'ai une Linux/gcc avec un x86
(Pentium 4...)
gcc flotte.c
Pour n=5 somme-1.0=-0.000000 (%f)
Pour n=5 somme-1.0=-1.110223e-16 (%e)
Pour n=6 somme-1.0=-0.000000 (%f)
Pour n=6 somme-1.0=-1.110223e-16 (%e)
gcc -O4 flotte.c
Pour n=5, somme exacte
Pour n=6, somme exacte
gcc version 4.0.3 (Debian 4.0.3-1)
Pentium II (Deschutes)
J'peux scripter un truc plus approfondi, si yen a qui veulent :)
Et si je retrouve ce $%#*}{ de cable série, je boote la ss20.
Marrant: chez moi, seuls 7 et 10 ne donnent pas de somme exacte. J'ai une Linux/gcc avec un x86 (Pentium 4...)
gcc flotte.c Pour n=5 somme-1.0=-0.000000 (%f) Pour n=5 somme-1.0=-1.110223e-16 (%e) Pour n=6 somme-1.0=-0.000000 (%f) Pour n=6 somme-1.0=-1.110223e-16 (%e)
gcc -O4 flotte.c Pour n=5, somme exacte Pour n=6, somme exacte
gcc version 4.0.3 (Debian 4.0.3-1) Pentium II (Deschutes)
J'peux scripter un truc plus approfondi, si yen a qui veulent :) Et si je retrouve ce $%#*}{ de cable série, je boote la ss20.
-- http://la.buvette.org/tech/
onyxs
espie a écrit le 28/08/2008 à 17h15 :
In article , Marc Boyer wrote:
On 2008-08-28, Antoine Leca wrote:
En news:, Marc Boyer va escriure:
Prenons "Programmer en langage C avec exercices corrigés", édition de 1997, Eyrolle, §1.1 main(){ ... } Tiens, pas de type de retour de main...
Eh oui, c'est C90, pas du C99 ; ce qui somme toute n'est pas trop surprenant pour un livre publié en 1997 (et dont on peut penser que le §1.1 fut écrit dans les premiers, donc plusieurs années avant).
Argh... C'est vrai que je suis nul sur les différentes versions du C.
Bah, c'est pas grave, ca ne presente sommes toutes que peu d'interet. Je subodore que les gens qui se souviennent de cette subtilite sont essentiellement ceux qui ont peste pendant quelques heures suite a ce changement, devant corriger divers fichiers d'entetes et autres, ou ayant eu moult soucis a compiler certains logiciels.
Moi, le coup de l'implicit int m'avait bien gonfle lorsque j'avais du compiler des trucs sous un sunos qui n'avait que de vieux entetes X11 non encore corriges...
Eh bien, je n'ai pas tout relu à l'instant, mais il me semble bien que le seul ouvrage qui n'ait été attaqué par personne dans ce fil, c'est :
C programming : a modern approach, par J. N. King
ça le rend plutôt alléchant...
espie a écrit le 28/08/2008 à 17h15 :
In article ,
Marc Boyer wrote:
On 2008-08-28, Antoine Leca wrote:
En news:, Marc Boyer va escriure:
Prenons "Programmer en langage C avec exercices corrigés",
édition de 1997, Eyrolle, §1.1
main(){
...
}
Tiens, pas de type de retour de main...
Eh oui, c'est C90, pas du C99 ; ce qui somme toute n'est pas trop surprenant
pour un livre publié en 1997 (et dont on peut penser que le §1.1
fut écrit
dans les premiers, donc plusieurs années avant).
Argh... C'est vrai que je suis nul sur les différentes versions du C.
Bah, c'est pas grave, ca ne presente sommes toutes que peu d'interet.
Je subodore que les gens qui se souviennent de cette subtilite sont
essentiellement ceux qui ont peste pendant quelques heures suite a ce
changement, devant corriger divers fichiers d'entetes et autres, ou ayant
eu moult soucis a compiler certains logiciels.
Moi, le coup de l'implicit int m'avait bien gonfle lorsque j'avais du
compiler des trucs sous un sunos qui n'avait que de vieux entetes X11
non encore corriges...
Eh bien, je n'ai pas tout relu à l'instant, mais il me semble bien que le seul ouvrage qui n'ait été attaqué par personne dans ce fil, c'est :
Prenons "Programmer en langage C avec exercices corrigés", édition de 1997, Eyrolle, §1.1 main(){ ... } Tiens, pas de type de retour de main...
Eh oui, c'est C90, pas du C99 ; ce qui somme toute n'est pas trop surprenant pour un livre publié en 1997 (et dont on peut penser que le §1.1 fut écrit dans les premiers, donc plusieurs années avant).
Argh... C'est vrai que je suis nul sur les différentes versions du C.
Bah, c'est pas grave, ca ne presente sommes toutes que peu d'interet. Je subodore que les gens qui se souviennent de cette subtilite sont essentiellement ceux qui ont peste pendant quelques heures suite a ce changement, devant corriger divers fichiers d'entetes et autres, ou ayant eu moult soucis a compiler certains logiciels.
Moi, le coup de l'implicit int m'avait bien gonfle lorsque j'avais du compiler des trucs sous un sunos qui n'avait que de vieux entetes X11 non encore corriges...
Eh bien, je n'ai pas tout relu à l'instant, mais il me semble bien que le seul ouvrage qui n'ait été attaqué par personne dans ce fil, c'est :
C programming : a modern approach, par J. N. King
ça le rend plutôt alléchant...
Jean-Marc Bourguet
(Marc Espie) writes:
In article , Marc Boyer wrote: >> Pour un main() sans return, l'accolade terminale du bloc de définition >> de la fonction doit jouer le rôle d'un return sec mais quid de la valeur >> de retour ? > > De tête, ce doit être 0, la valeur de EXIT_SUCCESS. A confirmer.
Faux.
C'est le cas en C++, mais pas en C, et il y a explicitement un paragraphe de la norme qui explicite la difference (sachant qu'en C++, main n'est de toutes facons PAS une fonction comme les autres).
C99 s'est aligne sur le C++:
5.1.2.2.3 Program termination
1 If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument;10) reaching the } that terminates the main function returns a value of 0. If the return type is not compatible with int, the termination status returned to the host environment is unspecified.
-- 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:
In article <slrngbdeco.5so.Marc.Boyer@ubu.enseeiht.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
>> Pour un main() sans return, l'accolade terminale du bloc de définition
>> de la fonction doit jouer le rôle d'un return sec mais quid de la valeur
>> de retour ?
>
> De tête, ce doit être 0, la valeur de EXIT_SUCCESS. A confirmer.
Faux.
C'est le cas en C++, mais pas en C, et il y a explicitement un paragraphe
de la norme qui explicite la difference (sachant qu'en C++, main n'est
de toutes facons PAS une fonction comme les autres).
C99 s'est aligne sur le C++:
5.1.2.2.3 Program termination
1 If the return type of the main function is a type compatible with int, a
return from the initial call to the main function is equivalent to calling
the exit function with the value returned by the main function as its
argument;10) reaching the } that terminates the main function returns a
value of 0. If the return type is not compatible with int, the termination
status returned to the host environment is unspecified.
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
In article , Marc Boyer wrote: >> Pour un main() sans return, l'accolade terminale du bloc de définition >> de la fonction doit jouer le rôle d'un return sec mais quid de la valeur >> de retour ? > > De tête, ce doit être 0, la valeur de EXIT_SUCCESS. A confirmer.
Faux.
C'est le cas en C++, mais pas en C, et il y a explicitement un paragraphe de la norme qui explicite la difference (sachant qu'en C++, main n'est de toutes facons PAS une fonction comme les autres).
C99 s'est aligne sur le C++:
5.1.2.2.3 Program termination
1 If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument;10) reaching the } that terminates the main function returns a value of 0. If the return type is not compatible with int, the termination status returned to the host environment is unspecified.
-- 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
In article , Jean-Marc Bourguet wrote:
(Marc Espie) writes:
In article , Marc Boyer wrote: >> Pour un main() sans return, l'accolade terminale du bloc de définition >> de la fonction doit jouer le rôle d'un return sec mais quid de la valeur >> de retour ? > > De tête, ce doit être 0, la valeur de EXIT_SUCCESS. A confirmer.
Faux.
C'est le cas en C++, mais pas en C, et il y a explicitement un paragraphe de la norme qui explicite la difference (sachant qu'en C++, main n'est de toutes facons PAS une fonction comme les autres).
C99 s'est aligne sur le C++:
5.1.2.2.3 Program termination
1 If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument;10) reaching the } that terminates the main function returns a value of 0. If the return type is not compatible with int, the termination status returned to the host environment is unspecified.
Donc, d'ici 10 ans, ca sera utilisable. Pour info, le `mode' par defaut du gcc que j'ai sous la main est conforme a C90, pas C99... si je specifie -stdÉ9, effectivement, ca fonctionne...
In article <pxbhc95ytge.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> wrote:
espie@lain.home (Marc Espie) writes:
In article <slrngbdeco.5so.Marc.Boyer@ubu.enseeiht.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
>> Pour un main() sans return, l'accolade terminale du bloc de définition
>> de la fonction doit jouer le rôle d'un return sec mais quid de la valeur
>> de retour ?
>
> De tête, ce doit être 0, la valeur de EXIT_SUCCESS. A confirmer.
Faux.
C'est le cas en C++, mais pas en C, et il y a explicitement un paragraphe
de la norme qui explicite la difference (sachant qu'en C++, main n'est
de toutes facons PAS une fonction comme les autres).
C99 s'est aligne sur le C++:
5.1.2.2.3 Program termination
1 If the return type of the main function is a type compatible with int, a
return from the initial call to the main function is equivalent to calling
the exit function with the value returned by the main function as its
argument;10) reaching the } that terminates the main function returns a
value of 0. If the return type is not compatible with int, the termination
status returned to the host environment is unspecified.
Donc, d'ici 10 ans, ca sera utilisable. Pour info, le `mode' par defaut
du gcc que j'ai sous la main est conforme a C90, pas C99... si je specifie
-stdÉ9, effectivement, ca fonctionne...
In article , Marc Boyer wrote: >> Pour un main() sans return, l'accolade terminale du bloc de définition >> de la fonction doit jouer le rôle d'un return sec mais quid de la valeur >> de retour ? > > De tête, ce doit être 0, la valeur de EXIT_SUCCESS. A confirmer.
Faux.
C'est le cas en C++, mais pas en C, et il y a explicitement un paragraphe de la norme qui explicite la difference (sachant qu'en C++, main n'est de toutes facons PAS une fonction comme les autres).
C99 s'est aligne sur le C++:
5.1.2.2.3 Program termination
1 If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument;10) reaching the } that terminates the main function returns a value of 0. If the return type is not compatible with int, the termination status returned to the host environment is unspecified.
Donc, d'ici 10 ans, ca sera utilisable. Pour info, le `mode' par defaut du gcc que j'ai sous la main est conforme a C90, pas C99... si je specifie -stdÉ9, effectivement, ca fonctionne...
Erwan David
(Marc Espie) écrivait :
Donc, d'ici 10 ans, ca sera utilisable. Pour info, le `mode' par defaut du gcc que j'ai sous la main est conforme a C90, pas C99... si je specifie -stdÉ9, effectivement, ca fonctionne...
Et attention, si on va dans l'embarqué on trouve du
"The latest release of MIPS® SDE is 6.06.00 based on gcc3.4."
Donc là faut ajour 7 ou 8 ans de plus...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
espie@lain.home (Marc Espie) écrivait :
Donc, d'ici 10 ans, ca sera utilisable. Pour info, le `mode' par defaut
du gcc que j'ai sous la main est conforme a C90, pas C99... si je specifie
-stdÉ9, effectivement, ca fonctionne...
Et attention, si on va dans l'embarqué on trouve du
"The latest release of MIPS® SDE is 6.06.00 based on gcc3.4."
Donc là faut ajour 7 ou 8 ans de plus...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Donc, d'ici 10 ans, ca sera utilisable. Pour info, le `mode' par defaut du gcc que j'ai sous la main est conforme a C90, pas C99... si je specifie -stdÉ9, effectivement, ca fonctionne...
Et attention, si on va dans l'embarqué on trouve du
"The latest release of MIPS® SDE is 6.06.00 based on gcc3.4."
Donc là faut ajour 7 ou 8 ans de plus...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Erwan David
(Marc Espie) écrivait :
Donc, d'ici 10 ans, ca sera utilisable. Pour info, le `mode' par defaut du gcc que j'ai sous la main est conforme a C90, pas C99... si je specifie -stdÉ9, effectivement, ca fonctionne...
Et attention, si on va dans l'embarqué on trouve du
"The latest release of MIPS® SDE is 6.06.00 based on gcc3.4."
Donc là faut ajouter 7 ou 8 ans de plus...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
espie@lain.home (Marc Espie) écrivait :
Donc, d'ici 10 ans, ca sera utilisable. Pour info, le `mode' par defaut
du gcc que j'ai sous la main est conforme a C90, pas C99... si je specifie
-stdÉ9, effectivement, ca fonctionne...
Et attention, si on va dans l'embarqué on trouve du
"The latest release of MIPS® SDE is 6.06.00 based on gcc3.4."
Donc là faut ajouter 7 ou 8 ans de plus...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Donc, d'ici 10 ans, ca sera utilisable. Pour info, le `mode' par defaut du gcc que j'ai sous la main est conforme a C90, pas C99... si je specifie -stdÉ9, effectivement, ca fonctionne...
Et attention, si on va dans l'embarqué on trouve du
"The latest release of MIPS® SDE is 6.06.00 based on gcc3.4."
Donc là faut ajouter 7 ou 8 ans de plus...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Jean-Marc Bourguet
Erwan David writes:
(Marc Espie) écrivait :
Donc, d'ici 10 ans, ca sera utilisable. Pour info, le `mode' par defaut du gcc que j'ai sous la main est conforme a C90, pas C99... si je specifie -stdÉ9, effectivement, ca fonctionne...
Optimiste :-)
Et attention, si on va dans l'embarqué on trouve du
"The latest release of MIPS® SDE is 6.06.00 based on gcc3.4."
Donc là faut ajouter 7 ou 8 ans de plus...
Mais pour ce qui concerne ce point particulier -- absence de return dans main -- je ne me fais pas trop de soucis pour les applications embarquées :-)
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Erwan David <erwan@rail.eu.org> writes:
espie@lain.home (Marc Espie) écrivait :
Donc, d'ici 10 ans, ca sera utilisable. Pour info, le `mode' par defaut
du gcc que j'ai sous la main est conforme a C90, pas C99... si je specifie
-stdÉ9, effectivement, ca fonctionne...
Optimiste :-)
Et attention, si on va dans l'embarqué on trouve du
"The latest release of MIPS® SDE is 6.06.00 based on gcc3.4."
Donc là faut ajouter 7 ou 8 ans de plus...
Mais pour ce qui concerne ce point particulier -- absence de return dans
main -- je ne me fais pas trop de soucis pour les applications
embarquées :-)
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Donc, d'ici 10 ans, ca sera utilisable. Pour info, le `mode' par defaut du gcc que j'ai sous la main est conforme a C90, pas C99... si je specifie -stdÉ9, effectivement, ca fonctionne...
Optimiste :-)
Et attention, si on va dans l'embarqué on trouve du
"The latest release of MIPS® SDE is 6.06.00 based on gcc3.4."
Donc là faut ajouter 7 ou 8 ans de plus...
Mais pour ce qui concerne ce point particulier -- absence de return dans main -- je ne me fais pas trop de soucis pour les applications embarquées :-)
-- 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
In article , Erwan David wrote:
(Marc Espie) écrivait :
Donc, d'ici 10 ans, ca sera utilisable. Pour info, le `mode' par defaut du gcc que j'ai sous la main est conforme a C90, pas C99... si je specifie -stdÉ9, effectivement, ca fonctionne...
Et attention, si on va dans l'embarqué on trouve du
"The latest release of MIPS® SDE is 6.06.00 based on gcc3.4."
Tu sais, on est toujours sur gcc 3.3 sur OpenBSD... entre autres parce qu'on trouve que les versions plus recentes se foutent du monde cote vitesse de compilation et consommation memoire.
In article <m2d4jtdlsj.fsf@minuetto.depot.rail.eu.org>,
Erwan David <erwan@rail.eu.org> wrote:
espie@lain.home (Marc Espie) écrivait :
Donc, d'ici 10 ans, ca sera utilisable. Pour info, le `mode' par defaut
du gcc que j'ai sous la main est conforme a C90, pas C99... si je specifie
-stdÉ9, effectivement, ca fonctionne...
Et attention, si on va dans l'embarqué on trouve du
"The latest release of MIPS® SDE is 6.06.00 based on gcc3.4."
Tu sais, on est toujours sur gcc 3.3 sur OpenBSD... entre autres parce
qu'on trouve que les versions plus recentes se foutent du monde cote
vitesse de compilation et consommation memoire.
Donc, d'ici 10 ans, ca sera utilisable. Pour info, le `mode' par defaut du gcc que j'ai sous la main est conforme a C90, pas C99... si je specifie -stdÉ9, effectivement, ca fonctionne...
Et attention, si on va dans l'embarqué on trouve du
"The latest release of MIPS® SDE is 6.06.00 based on gcc3.4."
Tu sais, on est toujours sur gcc 3.3 sur OpenBSD... entre autres parce qu'on trouve que les versions plus recentes se foutent du monde cote vitesse de compilation et consommation memoire.
Wykaaa
Marc Boyer a écrit :
On 2008-08-27, candide wrote:
BOn, je préviens tout de suite que les les deux livres de Delannoy dont tu parles, à savoir :
(i) Programmer en Langage C, Eyrolles (1997), (ii) Le livre du C premier langage, Eyrolles (1994 & 2002),
sont pour moi de mauvais livres d'un point de vue de la qualité pédagogique et je ne les connais que très mal.
Tout pareil pour moi ;-)
Pareil pour ses "Exercices en Langage C". Moi, le livre de Delannoy auquel je me réfère est le suivant
Prenons "Programmer en langage C avec exercices corrigés", édition de 1997, Eyrolle, §1.1 main(){ ... } Tiens, pas de type de retour de main...
Oui, pour moi c'est inexcusable en effet. Dans son livre "Langage C", on trouve aussi de tels exemples d'emploi de main() à de nombreuses reprises. C'est d'autant plus étonnant que l'auteur dit lui-même, pages 820-821 :
"[L'en-tête de la fonction main()] ne peut toutefois s'écrire que sous l'une des deux formes suivantes, la seconde étant indispensable lorsqu'on souhaite récupérer les informations fournies par l'environnement :
int main(void) /* forme usuelle */ int main(int nbarg, char *argv[]);"
Et il ajoute, ce qui est contestable :
"on rencontre souvent des formes différentes, théoriquement hors norme :
main() /* théoriquement hors norme mais généralement accepté */ int main() /* théoriquement hors norme mais généralement accepté */
ces en-têtes sont cependant acceptés par toutes les implémentations, quitte à provoquer un message d'avertissement (warning)."
Néanmoins, pour me faire l'avocat du diable, voici le /hello word/ de K&R2 :
------------------------------ 8<----------------------------------- In C, the program to print ``hello, world'' is #include <stdio.h> main() { printf("hello, worldn"); } ------------------------------ >8 -----------------------------------
Oui, ça ne leur rend pas honneur.
Mais c'est comme ça partout dans le K&R qui, je le répète en persistant et en signant est UN TRES MAUVAIS LIVRE, en tout cas, certainement pas un livre pour débutant en C !
Je passe sur l'indentation étrange de l'exemple du §1.9
if (op == '+') printf("leur somme est : %d", n1+n2) ; else printf("leur produit est : %d", n1+n2) ;
Bon OK, mais ça c'est une question de style,
Hein ? C'est quoi ce style ? Rien n'est aligné.
C'est tout sauf du style. ce n'est pas de l'indentation étrange, c'est de la non indentation...
le tout est d'être constant dans ces choix (je n'ai pas vérifié en l'espèce).
Ca l'est pas, je te rassure.
liste chainée. Déjà, pas de type liste, on manipule directement les chainons. Mais surtout, dans tous les exos corrigés, on a un seul malloc (solution de l'exo 11.1) qui fait un cast (transtypage) de la valeur de retour, et pas de test de la valeur de retour de malloc. La page avant, pas de test de valeur de retour de fopen... Pas un seul free, pas un seul realloc dans les exemples...
Oui, pas terrible en effet. Je vérifie dans son bouquin (iii) cité ci-dessus où il y a un chapitre complet là-dessus : il teste bien malloc() dans ses exemples, il libère, il donne un exemple de realloc. Au passage, j'ai noté que dans ce même chapitre, son traitement des listes chaînées est beaucoup trop succint. Dans ses "Exercices corrigés en langage C", il teste le retour de fopen().
OK
Le seul qui traite correctement de ces structures de données en C, c'est le livre de Philippe Drix "Langage C - Norme ANSI, vers une programmation orientée objet". Tout les autres codent en C comme des cochons les structures de données polylithiques : arbres, listes, ensembles, etc.
[snip]
Marc Boyer a écrit :
On 2008-08-27, candide <candide@free.invalid> wrote:
BOn, je préviens tout de suite que les les deux livres de Delannoy dont
tu parles, à savoir :
(i) Programmer en Langage C, Eyrolles (1997),
(ii) Le livre du C premier langage, Eyrolles (1994 & 2002),
sont pour moi de mauvais livres d'un point de vue de la qualité
pédagogique et je ne les connais que très mal.
Tout pareil pour moi ;-)
Pareil pour ses
"Exercices en Langage C". Moi, le livre de Delannoy auquel je me réfère
est le suivant
Prenons "Programmer en langage C avec exercices corrigés",
édition de 1997, Eyrolle, §1.1
main(){
...
}
Tiens, pas de type de retour de main...
Oui, pour moi c'est inexcusable en effet. Dans son livre "Langage C", on
trouve aussi de tels exemples d'emploi de main() à de nombreuses
reprises. C'est d'autant plus étonnant que l'auteur dit lui-même, pages
820-821 :
"[L'en-tête de la fonction main()] ne peut toutefois s'écrire que sous
l'une des deux formes suivantes, la seconde étant indispensable
lorsqu'on souhaite récupérer les informations fournies par l'environnement :
int main(void) /* forme usuelle */
int main(int nbarg, char *argv[]);"
Et il ajoute, ce qui est contestable :
"on rencontre souvent des formes différentes, théoriquement hors norme :
main() /* théoriquement hors norme mais généralement accepté */
int main() /* théoriquement hors norme mais généralement accepté */
ces en-têtes sont cependant acceptés par toutes les implémentations,
quitte à provoquer un message d'avertissement (warning)."
Néanmoins, pour me faire l'avocat du diable, voici le /hello word/ de K&R2 :
------------------------------ 8<-----------------------------------
In C, the program to print ``hello, world'' is
#include <stdio.h>
main()
{
printf("hello, worldn");
}
------------------------------ >8 -----------------------------------
Oui, ça ne leur rend pas honneur.
Mais c'est comme ça partout dans le K&R qui, je le répète en persistant
et en signant est UN TRES MAUVAIS LIVRE, en tout cas, certainement pas
un livre pour débutant en C !
Je passe sur l'indentation étrange de l'exemple du §1.9
if (op == '+') printf("leur somme est : %d", n1+n2) ;
else printf("leur produit est : %d", n1+n2) ;
Bon OK, mais ça c'est une question de style,
Hein ? C'est quoi ce style ? Rien n'est aligné.
C'est tout sauf du style. ce n'est pas de l'indentation étrange, c'est
de la non indentation...
le tout est d'être constant
dans ces choix (je n'ai pas vérifié en l'espèce).
Ca l'est pas, je te rassure.
liste chainée. Déjà, pas de type liste, on manipule
directement les chainons. Mais surtout, dans tous les
exos corrigés, on a un seul malloc (solution de l'exo 11.1)
qui fait un cast (transtypage) de la valeur de retour,
et pas de test de la valeur de retour de malloc.
La page avant, pas de test de valeur de retour de fopen...
Pas un seul free, pas un seul realloc dans les exemples...
Oui, pas terrible en effet. Je vérifie dans son bouquin (iii) cité
ci-dessus où il y a un chapitre complet là-dessus : il teste bien
malloc() dans ses exemples, il libère, il donne un exemple de realloc.
Au passage, j'ai noté que dans ce même chapitre, son traitement des
listes chaînées est beaucoup trop succint. Dans ses "Exercices corrigés
en langage C", il teste le retour de fopen().
OK
Le seul qui traite correctement de ces structures de données en C, c'est
le livre de Philippe Drix "Langage C - Norme ANSI, vers une
programmation orientée objet".
Tout les autres codent en C comme des cochons les structures de données
polylithiques : arbres, listes, ensembles, etc.
Prenons "Programmer en langage C avec exercices corrigés", édition de 1997, Eyrolle, §1.1 main(){ ... } Tiens, pas de type de retour de main...
Oui, pour moi c'est inexcusable en effet. Dans son livre "Langage C", on trouve aussi de tels exemples d'emploi de main() à de nombreuses reprises. C'est d'autant plus étonnant que l'auteur dit lui-même, pages 820-821 :
"[L'en-tête de la fonction main()] ne peut toutefois s'écrire que sous l'une des deux formes suivantes, la seconde étant indispensable lorsqu'on souhaite récupérer les informations fournies par l'environnement :
int main(void) /* forme usuelle */ int main(int nbarg, char *argv[]);"
Et il ajoute, ce qui est contestable :
"on rencontre souvent des formes différentes, théoriquement hors norme :
main() /* théoriquement hors norme mais généralement accepté */ int main() /* théoriquement hors norme mais généralement accepté */
ces en-têtes sont cependant acceptés par toutes les implémentations, quitte à provoquer un message d'avertissement (warning)."
Néanmoins, pour me faire l'avocat du diable, voici le /hello word/ de K&R2 :
------------------------------ 8<----------------------------------- In C, the program to print ``hello, world'' is #include <stdio.h> main() { printf("hello, worldn"); } ------------------------------ >8 -----------------------------------
Oui, ça ne leur rend pas honneur.
Mais c'est comme ça partout dans le K&R qui, je le répète en persistant et en signant est UN TRES MAUVAIS LIVRE, en tout cas, certainement pas un livre pour débutant en C !
Je passe sur l'indentation étrange de l'exemple du §1.9
if (op == '+') printf("leur somme est : %d", n1+n2) ; else printf("leur produit est : %d", n1+n2) ;
Bon OK, mais ça c'est une question de style,
Hein ? C'est quoi ce style ? Rien n'est aligné.
C'est tout sauf du style. ce n'est pas de l'indentation étrange, c'est de la non indentation...
le tout est d'être constant dans ces choix (je n'ai pas vérifié en l'espèce).
Ca l'est pas, je te rassure.
liste chainée. Déjà, pas de type liste, on manipule directement les chainons. Mais surtout, dans tous les exos corrigés, on a un seul malloc (solution de l'exo 11.1) qui fait un cast (transtypage) de la valeur de retour, et pas de test de la valeur de retour de malloc. La page avant, pas de test de valeur de retour de fopen... Pas un seul free, pas un seul realloc dans les exemples...
Oui, pas terrible en effet. Je vérifie dans son bouquin (iii) cité ci-dessus où il y a un chapitre complet là-dessus : il teste bien malloc() dans ses exemples, il libère, il donne un exemple de realloc. Au passage, j'ai noté que dans ce même chapitre, son traitement des listes chaînées est beaucoup trop succint. Dans ses "Exercices corrigés en langage C", il teste le retour de fopen().
OK
Le seul qui traite correctement de ces structures de données en C, c'est le livre de Philippe Drix "Langage C - Norme ANSI, vers une programmation orientée objet". Tout les autres codent en C comme des cochons les structures de données polylithiques : arbres, listes, ensembles, etc.
