Demande d'explication au sujet d'une ligne du type "pointer = (type *)fonction(paramètr es...);".
6 réponses
Didier Forfait
Bonjour à tous et merci d'avance pour votre aide. Ce message est d'ordre
didactique.
Je me forme au langage C et la bibliothèque (n)curses. Je travaille
actuellement avec le howto ncurses. A la page suivante
http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/panels.html#PANELBROWSING
il se trouve un listing nommé "Example 15. Panel Window Browsing
Example". Dans celui-ci il y a la ligne "top = (PANEL
*)panel_userptr(top);". La question est la suivante : la fonction
renvoie visiblement un pointeur (puisque "top" est déclaré comme tel) et
"PANEL" est un type... Mais pourquoi y-a-t'il des parenthèses englobant
le couple "PANEL *" ? Serais-ce pour "protéger" la structure PANEL ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Eric Levenez
Le 29/09/07 18:14, dans <46fe79e5$0$2697$, « Didier Forfait » a écrit :
Je me forme au langage C et la bibliothèque (n)curses. Je travaille actuellement avec le howto ncurses. A la page suivante http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/panels.html#PANELBROWSING il se trouve un listing nommé "Example 15. Panel Window Browsing Example".
Les codes de cette pages sont... heu, comment dire... très spéciaux, pour rester poli.
Pour cette exemple 15, il manque un "include <string.h>" pour que ça compile. Il faut aussi mettre "int main(void)".
Dans celui-ci il y a la ligne "top = (PANEL *)panel_userptr(top);". La question est la suivante : la fonction renvoie visiblement un pointeur (puisque "top" est déclaré comme tel) et "PANEL" est un type... Mais pourquoi y-a-t'il des parenthèses englobant le couple "PANEL *" ? Serais-ce pour "protéger" la structure PANEL ?
La fonction panel_userptr retour un pointeur générique de type "void *", le "(PANEL *)" est ce que l'on appelle un cast et permet de transformer ce pointeur générique en pointeur vers le type PANEL. Dans mon K&R sur le C, cette notion est expliquée dans le chapitre 2.
Ce cast est d'ailleurs inutile car il peut masquer un problème d'include (voir la faq sur le langage C à propos de la fonction malloc, §12.1).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 29/09/07 18:14, dans <46fe79e5$0$2697$426a74cc@news.free.fr>, « Didier
Forfait » <didier.forfait@free.fr> a écrit :
Je me forme au langage C et la bibliothèque (n)curses. Je travaille
actuellement avec le howto ncurses. A la page suivante
http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/panels.html#PANELBROWSING
il se trouve un listing nommé "Example 15. Panel Window Browsing
Example".
Les codes de cette pages sont... heu, comment dire... très spéciaux, pour
rester poli.
Pour cette exemple 15, il manque un "include <string.h>" pour que ça
compile. Il faut aussi mettre "int main(void)".
Dans celui-ci il y a la ligne "top = (PANEL
*)panel_userptr(top);". La question est la suivante : la fonction
renvoie visiblement un pointeur (puisque "top" est déclaré comme tel) et
"PANEL" est un type... Mais pourquoi y-a-t'il des parenthèses englobant
le couple "PANEL *" ? Serais-ce pour "protéger" la structure PANEL ?
La fonction panel_userptr retour un pointeur générique de type "void *", le
"(PANEL *)" est ce que l'on appelle un cast et permet de transformer ce
pointeur générique en pointeur vers le type PANEL. Dans mon K&R sur le C,
cette notion est expliquée dans le chapitre 2.
Ce cast est d'ailleurs inutile car il peut masquer un problème d'include
(voir la faq sur le langage C à propos de la fonction malloc, §12.1).
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 29/09/07 18:14, dans <46fe79e5$0$2697$, « Didier Forfait » a écrit :
Je me forme au langage C et la bibliothèque (n)curses. Je travaille actuellement avec le howto ncurses. A la page suivante http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/panels.html#PANELBROWSING il se trouve un listing nommé "Example 15. Panel Window Browsing Example".
Les codes de cette pages sont... heu, comment dire... très spéciaux, pour rester poli.
Pour cette exemple 15, il manque un "include <string.h>" pour que ça compile. Il faut aussi mettre "int main(void)".
Dans celui-ci il y a la ligne "top = (PANEL *)panel_userptr(top);". La question est la suivante : la fonction renvoie visiblement un pointeur (puisque "top" est déclaré comme tel) et "PANEL" est un type... Mais pourquoi y-a-t'il des parenthèses englobant le couple "PANEL *" ? Serais-ce pour "protéger" la structure PANEL ?
La fonction panel_userptr retour un pointeur générique de type "void *", le "(PANEL *)" est ce que l'on appelle un cast et permet de transformer ce pointeur générique en pointeur vers le type PANEL. Dans mon K&R sur le C, cette notion est expliquée dans le chapitre 2.
Ce cast est d'ailleurs inutile car il peut masquer un problème d'include (voir la faq sur le langage C à propos de la fonction malloc, §12.1).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Didier Forfait
Eric Levenez wrote:
Le 29/09/07 18:14, dans <46fe79e5$0$2697$, « Didier
Je me forme au langage C et la bibliothèque (n)curses. Je travaille actuellement avec le howto ncurses. A la page suivante http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/panels.html#PANELBROWSING il se trouve un listing nommé "Example 15. Panel Window Browsing Example".
Les codes de cette pages sont... heu, comment dire... très spéciaux, pour rester poli.
Pour cette exemple 15, il manque un "include <string.h>" pour que ça compile. Il faut aussi mettre "int main(void)".
Dans celui-ci il y a la ligne "top = (PANEL *)panel_userptr(top);". La question est la suivante : la fonction renvoie visiblement un pointeur (puisque "top" est déclaré comme tel) et "PANEL" est un type... Mais pourquoi y-a-t'il des parenthèses englobant le couple "PANEL *" ? Serais-ce pour "protéger" la structure PANEL ?
La fonction panel_userptr retour un pointeur générique de type "void *", le "(PANEL *)" est ce que l'on appelle un cast et permet de transformer ce pointeur générique en pointeur vers le type PANEL. Dans mon K&R sur le C, cette notion est expliquée dans le chapitre 2.
Ce cast est d'ailleurs inutile car il peut masquer un problème d'include (voir la faq sur le langage C à propos de la fonction malloc, §12.1).
Bon sang, mais c'est bien sûr ! Le "cast" ! Cela explique tout.
Merci pour ta célérité et la clarté de tes explications. En ce qui concerne le code de l'howto, sur ma station la compilation passe correctement, même si gcc râle un peu au sujet d'une déclaration implicite de strlen()... Par contre, tu parle de "mon K&R"... qu'est-ce donc qu'un "K&R" ? Je suis allé sur ton site, mais je n'ai pas trouvé les documents dont tu me parle. Peux-tu m'en dire plus. Merci d'avance. Cordialement.
Eric Levenez wrote:
Le 29/09/07 18:14, dans <46fe79e5$0$2697$426a74cc@news.free.fr>, « Didier
Je me forme au langage C et la bibliothèque (n)curses. Je travaille
actuellement avec le howto ncurses. A la page suivante
http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/panels.html#PANELBROWSING
il se trouve un listing nommé "Example 15. Panel Window Browsing
Example".
Les codes de cette pages sont... heu, comment dire... très spéciaux, pour
rester poli.
Pour cette exemple 15, il manque un "include <string.h>" pour que ça
compile. Il faut aussi mettre "int main(void)".
Dans celui-ci il y a la ligne "top = (PANEL
*)panel_userptr(top);". La question est la suivante : la fonction
renvoie visiblement un pointeur (puisque "top" est déclaré comme tel) et
"PANEL" est un type... Mais pourquoi y-a-t'il des parenthèses englobant
le couple "PANEL *" ? Serais-ce pour "protéger" la structure PANEL ?
La fonction panel_userptr retour un pointeur générique de type "void *", le
"(PANEL *)" est ce que l'on appelle un cast et permet de transformer ce
pointeur générique en pointeur vers le type PANEL. Dans mon K&R sur le C,
cette notion est expliquée dans le chapitre 2.
Ce cast est d'ailleurs inutile car il peut masquer un problème d'include
(voir la faq sur le langage C à propos de la fonction malloc, §12.1).
Bon sang, mais c'est bien sûr ! Le "cast" ! Cela explique tout.
Merci pour ta célérité et la clarté de tes explications.
En ce qui concerne le code de l'howto, sur ma station la compilation
passe correctement, même si gcc râle un peu au sujet d'une déclaration
implicite de strlen()...
Par contre, tu parle de "mon K&R"... qu'est-ce donc qu'un "K&R" ?
Je suis allé sur ton site, mais je n'ai pas trouvé les documents dont tu
me parle. Peux-tu m'en dire plus.
Merci d'avance.
Cordialement.
Le 29/09/07 18:14, dans <46fe79e5$0$2697$, « Didier
Je me forme au langage C et la bibliothèque (n)curses. Je travaille actuellement avec le howto ncurses. A la page suivante http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/panels.html#PANELBROWSING il se trouve un listing nommé "Example 15. Panel Window Browsing Example".
Les codes de cette pages sont... heu, comment dire... très spéciaux, pour rester poli.
Pour cette exemple 15, il manque un "include <string.h>" pour que ça compile. Il faut aussi mettre "int main(void)".
Dans celui-ci il y a la ligne "top = (PANEL *)panel_userptr(top);". La question est la suivante : la fonction renvoie visiblement un pointeur (puisque "top" est déclaré comme tel) et "PANEL" est un type... Mais pourquoi y-a-t'il des parenthèses englobant le couple "PANEL *" ? Serais-ce pour "protéger" la structure PANEL ?
La fonction panel_userptr retour un pointeur générique de type "void *", le "(PANEL *)" est ce que l'on appelle un cast et permet de transformer ce pointeur générique en pointeur vers le type PANEL. Dans mon K&R sur le C, cette notion est expliquée dans le chapitre 2.
Ce cast est d'ailleurs inutile car il peut masquer un problème d'include (voir la faq sur le langage C à propos de la fonction malloc, §12.1).
Bon sang, mais c'est bien sûr ! Le "cast" ! Cela explique tout.
Merci pour ta célérité et la clarté de tes explications. En ce qui concerne le code de l'howto, sur ma station la compilation passe correctement, même si gcc râle un peu au sujet d'une déclaration implicite de strlen()... Par contre, tu parle de "mon K&R"... qu'est-ce donc qu'un "K&R" ? Je suis allé sur ton site, mais je n'ai pas trouvé les documents dont tu me parle. Peux-tu m'en dire plus. Merci d'avance. Cordialement.
Eric Levenez
Le 30/09/07 17:33, dans <46ffc1b6$0$17517$, « Didier Forfait » a écrit :
En ce qui concerne le code de l'howto, sur ma station la compilation passe correctement, même si gcc râle un peu au sujet d'une déclaration implicite de strlen()...
Ce n'est pas qu'un simple warning, c'est une erreur de compilation. Cela compile sur certaines architectures mais cela a des chances de planter sur d'autres. Il faut que toutes les fonctions que l'on utilise soient déclarées pour que les types passés et retournés soient du bon type et de la bonne taille.
Supposons une fonction qui attend un long long et que l'on passe un int. Supposons encore que l'on oublie le prototypage. Il y aura un warning à la compilation, et la déclaration implicite utilisera un int au lien de caster la valeur sur le long long attendu par la fonction. L'application a toutes les chances de planter car la taille du paramètre ne sera pas la bonne.
Par contre, tu parle de "mon K&R"... qu'est-ce donc qu'un "K&R" ?
Le livre de Kernighan et Ritchie, les auteurs du langage C.
Je suis allé sur ton site, mais je n'ai pas trouvé les documents dont tu me parle. Peux-tu m'en dire plus.
Sur mon site ? Je ne comprends pas. Si tu parles de la FAQ, elle est postée une fois par mois dans ce groupe :
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 30/09/07 17:33, dans <46ffc1b6$0$17517$426a74cc@news.free.fr>, « Didier
Forfait » <didier.forfait@free.fr> a écrit :
En ce qui concerne le code de l'howto, sur ma station la compilation
passe correctement, même si gcc râle un peu au sujet d'une déclaration
implicite de strlen()...
Ce n'est pas qu'un simple warning, c'est une erreur de compilation. Cela
compile sur certaines architectures mais cela a des chances de planter sur
d'autres. Il faut que toutes les fonctions que l'on utilise soient déclarées
pour que les types passés et retournés soient du bon type et de la bonne
taille.
Supposons une fonction qui attend un long long et que l'on passe un int.
Supposons encore que l'on oublie le prototypage. Il y aura un warning à la
compilation, et la déclaration implicite utilisera un int au lien de caster
la valeur sur le long long attendu par la fonction. L'application a toutes
les chances de planter car la taille du paramètre ne sera pas la bonne.
Par contre, tu parle de "mon K&R"... qu'est-ce donc qu'un "K&R" ?
Le livre de Kernighan et Ritchie, les auteurs du langage C.
Je suis allé sur ton site, mais je n'ai pas trouvé les documents dont tu
me parle. Peux-tu m'en dire plus.
Sur mon site ? Je ne comprends pas. Si tu parles de la FAQ, elle est postée
une fois par mois dans ce groupe :
Le 30/09/07 17:33, dans <46ffc1b6$0$17517$, « Didier Forfait » a écrit :
En ce qui concerne le code de l'howto, sur ma station la compilation passe correctement, même si gcc râle un peu au sujet d'une déclaration implicite de strlen()...
Ce n'est pas qu'un simple warning, c'est une erreur de compilation. Cela compile sur certaines architectures mais cela a des chances de planter sur d'autres. Il faut que toutes les fonctions que l'on utilise soient déclarées pour que les types passés et retournés soient du bon type et de la bonne taille.
Supposons une fonction qui attend un long long et que l'on passe un int. Supposons encore que l'on oublie le prototypage. Il y aura un warning à la compilation, et la déclaration implicite utilisera un int au lien de caster la valeur sur le long long attendu par la fonction. L'application a toutes les chances de planter car la taille du paramètre ne sera pas la bonne.
Par contre, tu parle de "mon K&R"... qu'est-ce donc qu'un "K&R" ?
Le livre de Kernighan et Ritchie, les auteurs du langage C.
Je suis allé sur ton site, mais je n'ai pas trouvé les documents dont tu me parle. Peux-tu m'en dire plus.
Sur mon site ? Je ne comprends pas. Si tu parles de la FAQ, elle est postée une fois par mois dans ce groupe :
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Didier Forfait
Eric Levenez wrote:
Le 30/09/07 17:33, dans <46ffc1b6$0$17517$, « Didier
En ce qui concerne le code de l'howto, sur ma station la compilation passe correctement, même si gcc râle un peu au sujet d'une déclaration implicite de strlen()...
Ce n'est pas qu'un simple warning, c'est une erreur de compilation. Cela compile sur certaines architectures mais cela a des chances de planter sur d'autres. Il faut que toutes les fonctions que l'on utilise soient déclarées pour que les types passés et retournés soient du bon type et de la bonne taille.
Supposons une fonction qui attend un long long et que l'on passe un int. Supposons encore que l'on oublie le prototypage. Il y aura un warning à la compilation, et la déclaration implicite utilisera un int au lien de caster la valeur sur le long long attendu par la fonction. L'application a toutes les chances de planter car la taille du paramètre ne sera pas la bonne.
Par contre, tu parle de "mon K&R"... qu'est-ce donc qu'un "K&R" ?
Le livre de Kernighan et Ritchie, les auteurs du langage C.
Je suis allé sur ton site, mais je n'ai pas trouvé les documents dont tu me parle. Peux-tu m'en dire plus.
Sur mon site ? Je ne comprends pas. Si tu parles de la FAQ, elle est postée une fois par mois dans ce groupe :
A OK... je ne savais pas que tu faisais référence à un livre. Je croyais
qu'il s'agissait d'une doc en ligne. C'est donc LE livre de référence du C, l'incontournable ? J'ai fait un tour sur la fac... Ca m'a l'air bien utile... merci pour le tuyau. ;-) En ce qui concerne la déclaration implicite de la fonction, j'ai pris bonne note. De toutes façons, il ne faut jamais prendre un message de type "warning" à la légère.
Bonne soirée. Cordialement.
Eric Levenez wrote:
Le 30/09/07 17:33, dans <46ffc1b6$0$17517$426a74cc@news.free.fr>, « Didier
En ce qui concerne le code de l'howto, sur ma station la compilation
passe correctement, même si gcc râle un peu au sujet d'une déclaration
implicite de strlen()...
Ce n'est pas qu'un simple warning, c'est une erreur de compilation. Cela
compile sur certaines architectures mais cela a des chances de planter sur
d'autres. Il faut que toutes les fonctions que l'on utilise soient déclarées
pour que les types passés et retournés soient du bon type et de la bonne
taille.
Supposons une fonction qui attend un long long et que l'on passe un int.
Supposons encore que l'on oublie le prototypage. Il y aura un warning à la
compilation, et la déclaration implicite utilisera un int au lien de caster
la valeur sur le long long attendu par la fonction. L'application a toutes
les chances de planter car la taille du paramètre ne sera pas la bonne.
Par contre, tu parle de "mon K&R"... qu'est-ce donc qu'un "K&R" ?
Le livre de Kernighan et Ritchie, les auteurs du langage C.
Je suis allé sur ton site, mais je n'ai pas trouvé les documents dont tu
me parle. Peux-tu m'en dire plus.
Sur mon site ? Je ne comprends pas. Si tu parles de la FAQ, elle est postée
une fois par mois dans ce groupe :
A OK... je ne savais pas que tu faisais référence à un livre. Je croyais
qu'il s'agissait d'une doc en ligne. C'est donc LE livre de référence du
C, l'incontournable ?
J'ai fait un tour sur la fac... Ca m'a l'air bien utile... merci pour le
tuyau. ;-)
En ce qui concerne la déclaration implicite de la fonction, j'ai pris
bonne note. De toutes façons, il ne faut jamais prendre un message de
type "warning" à la légère.
Le 30/09/07 17:33, dans <46ffc1b6$0$17517$, « Didier
En ce qui concerne le code de l'howto, sur ma station la compilation passe correctement, même si gcc râle un peu au sujet d'une déclaration implicite de strlen()...
Ce n'est pas qu'un simple warning, c'est une erreur de compilation. Cela compile sur certaines architectures mais cela a des chances de planter sur d'autres. Il faut que toutes les fonctions que l'on utilise soient déclarées pour que les types passés et retournés soient du bon type et de la bonne taille.
Supposons une fonction qui attend un long long et que l'on passe un int. Supposons encore que l'on oublie le prototypage. Il y aura un warning à la compilation, et la déclaration implicite utilisera un int au lien de caster la valeur sur le long long attendu par la fonction. L'application a toutes les chances de planter car la taille du paramètre ne sera pas la bonne.
Par contre, tu parle de "mon K&R"... qu'est-ce donc qu'un "K&R" ?
Le livre de Kernighan et Ritchie, les auteurs du langage C.
Je suis allé sur ton site, mais je n'ai pas trouvé les documents dont tu me parle. Peux-tu m'en dire plus.
Sur mon site ? Je ne comprends pas. Si tu parles de la FAQ, elle est postée une fois par mois dans ce groupe :
A OK... je ne savais pas que tu faisais référence à un livre. Je croyais
qu'il s'agissait d'une doc en ligne. C'est donc LE livre de référence du C, l'incontournable ? J'ai fait un tour sur la fac... Ca m'a l'air bien utile... merci pour le tuyau. ;-) En ce qui concerne la déclaration implicite de la fonction, j'ai pris bonne note. De toutes façons, il ne faut jamais prendre un message de type "warning" à la légère.
Bonne soirée. Cordialement.
Eric Levenez
Le 30/09/07 21:15, dans <46fff5b3$0$15793$, « Didier Forfait » a écrit :
A OK... je ne savais pas que tu faisais référence à un livre. Je croyais qu'il s'agissait d'une doc en ligne. C'est donc LE livre de référence du C, l'incontournable ?
J'ai toujours l'édition originale, mais il faut vraiment avoir et lire la dernière version du livre (qui parle de la norme ANSI). De nos jours le standard C a évolué et c'est maintenant une norme ISO datant de 1999. Voir la FAQ chapitre 3.7 et 3.9.
J'ai fait un tour sur la fac... Ca m'a l'air bien utile... merci pour le tuyau. ;-) En ce qui concerne la déclaration implicite de la fonction, j'ai pris bonne note. De toutes façons, il ne faut jamais prendre un message de type "warning" à la légère.
Il faut toujours activer le maximum d'options possibles, les options par défaut n'étant pas suffisantes. Voici par exemple les options que j'utilise souvent avec gcc :
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 30/09/07 21:15, dans <46fff5b3$0$15793$426a74cc@news.free.fr>, « Didier
Forfait » <didier.forfait@free.fr> a écrit :
A OK... je ne savais pas que tu faisais référence à un livre. Je croyais
qu'il s'agissait d'une doc en ligne. C'est donc LE livre de référence du
C, l'incontournable ?
J'ai toujours l'édition originale, mais il faut vraiment avoir et lire la
dernière version du livre (qui parle de la norme ANSI). De nos jours le
standard C a évolué et c'est maintenant une norme ISO datant de 1999.
Voir la FAQ chapitre 3.7 et 3.9.
J'ai fait un tour sur la fac... Ca m'a l'air bien utile... merci pour le
tuyau. ;-)
En ce qui concerne la déclaration implicite de la fonction, j'ai pris
bonne note. De toutes façons, il ne faut jamais prendre un message de
type "warning" à la légère.
Il faut toujours activer le maximum d'options possibles, les options par
défaut n'étant pas suffisantes. Voici par exemple les options que j'utilise
souvent avec gcc :
Le 30/09/07 21:15, dans <46fff5b3$0$15793$, « Didier Forfait » a écrit :
A OK... je ne savais pas que tu faisais référence à un livre. Je croyais qu'il s'agissait d'une doc en ligne. C'est donc LE livre de référence du C, l'incontournable ?
J'ai toujours l'édition originale, mais il faut vraiment avoir et lire la dernière version du livre (qui parle de la norme ANSI). De nos jours le standard C a évolué et c'est maintenant une norme ISO datant de 1999. Voir la FAQ chapitre 3.7 et 3.9.
J'ai fait un tour sur la fac... Ca m'a l'air bien utile... merci pour le tuyau. ;-) En ce qui concerne la déclaration implicite de la fonction, j'ai pris bonne note. De toutes façons, il ne faut jamais prendre un message de type "warning" à la légère.
Il faut toujours activer le maximum d'options possibles, les options par défaut n'étant pas suffisantes. Voici par exemple les options que j'utilise souvent avec gcc :
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
xylo
Le Sun, 30 Sep 2007 21:34:42 +0200, Eric Levenez a écrit:
Le 30/09/07 21:15, dans <46fff5b3$0$15793$, « Didier Forfait » a écrit :
A OK... je ne savais pas que tu faisais référence à un livre. Je croyais qu'il s'agissait d'une doc en ligne. C'est donc LE livre de référence du C, l'incontournable ?
J'ai toujours l'édition originale, mais il faut vraiment avoir et lire la dernière version du livre (qui parle de la norme ANSI). De nos jours le standard C a évolué et c'est maintenant une norme ISO datant de 1999. Voir la FAQ chapitre 3.7 et 3.9.
J'ai fait un tour sur la fac... Ca m'a l'air bien utile... merci pour le tuyau. ;-) En ce qui concerne la déclaration implicite de la fonction, j'ai pris bonne note. De toutes façons, il ne faut jamais prendre un message de type "warning" à la légère.
Il faut toujours activer le maximum d'options possibles, les options par défaut n'étant pas suffisantes. Voici par exemple les options que j'utilise souvent avec gcc :
mouai..., pedantic ça peut vite confler. mais l'esprit est là.
-- Apply rot13 to this e-mail address before using it. JM Marino http://jm.marino.free.fr
Le Sun, 30 Sep 2007 21:34:42 +0200, Eric Levenez a écrit:
Le 30/09/07 21:15, dans <46fff5b3$0$15793$426a74cc@news.free.fr>, « Didier
Forfait » <didier.forfait@free.fr> a écrit :
A OK... je ne savais pas que tu faisais référence à un livre. Je croyais
qu'il s'agissait d'une doc en ligne. C'est donc LE livre de référence du
C, l'incontournable ?
J'ai toujours l'édition originale, mais il faut vraiment avoir et lire la
dernière version du livre (qui parle de la norme ANSI). De nos jours le
standard C a évolué et c'est maintenant une norme ISO datant de 1999.
Voir la FAQ chapitre 3.7 et 3.9.
J'ai fait un tour sur la fac... Ca m'a l'air bien utile... merci pour le
tuyau. ;-)
En ce qui concerne la déclaration implicite de la fonction, j'ai pris
bonne note. De toutes façons, il ne faut jamais prendre un message de
type "warning" à la légère.
Il faut toujours activer le maximum d'options possibles, les options par
défaut n'étant pas suffisantes. Voici par exemple les options que j'utilise
souvent avec gcc :
Le Sun, 30 Sep 2007 21:34:42 +0200, Eric Levenez a écrit:
Le 30/09/07 21:15, dans <46fff5b3$0$15793$, « Didier Forfait » a écrit :
A OK... je ne savais pas que tu faisais référence à un livre. Je croyais qu'il s'agissait d'une doc en ligne. C'est donc LE livre de référence du C, l'incontournable ?
J'ai toujours l'édition originale, mais il faut vraiment avoir et lire la dernière version du livre (qui parle de la norme ANSI). De nos jours le standard C a évolué et c'est maintenant une norme ISO datant de 1999. Voir la FAQ chapitre 3.7 et 3.9.
J'ai fait un tour sur la fac... Ca m'a l'air bien utile... merci pour le tuyau. ;-) En ce qui concerne la déclaration implicite de la fonction, j'ai pris bonne note. De toutes façons, il ne faut jamais prendre un message de type "warning" à la légère.
Il faut toujours activer le maximum d'options possibles, les options par défaut n'étant pas suffisantes. Voici par exemple les options que j'utilise souvent avec gcc :
