éternel débutant en C pour mon plaisir, je me permets de venir vous
demander quelques éclaircissements sur une situation que je n'arrive pas
à comprendre :
J'utilise le cours en ligne spécial "grand débutant" du "site du zéro" :
<http://www.siteduzero.com/tutoriel-3-14189-apprenez-a-programmer-en-c.html>
Je réalise les exercices du cours dans deux environnements différents :
- sous windows vista avec l'IDE visual C++ 2008 express
- sous linux ubuntu 9.04 avec gcc
J'ai écrit un programme dans le cadre des exercices proposés sur les
tableaux par ce cours en ligne. Le fichier en question peut être
téléchargé ici :
< http://dl.free.fr/to7PFReLM/tableau.c>
Ce qui m'étonne, c'est que j'arrive à compiler sans difficulté ce code
sous Linux, et que le programme se comporte exactement comme je le
souhaite. Par contre, sous Windows, impossible de compiler, l'IDE me
renvoie 42 erreurs et 31 avertissements !!! La plupart des erreurs
semblent être liées aux variables. Par exemple :
"erreur de syntaxe : absence de ';' avant 'type'"
"identificateur non déclaré"
Or, j'ai beau lire et relire mon code, les variables me sembles toutes
déclarées correctement et il ne manque à mon sens pas de ";" en fin
d'instructions. De plus, comme je le disais au début, le même code se
compile sans aucune erreur sous Linux ...
Alors, comment expliquer que deux compilateurs réagissent aussi
différemment, et où et mon erreur ?
Merci par avance du temps que vous pourrez me consacrer,
| In article , | Pierre Maurette wrote: | >Mickaël Wolff, le 14/09/2009 a écrit : | >> Stephane Legras-Decussy wrote: | >>> "Pierre Maurette" a écrit dans le message de | >>> news: | >>>> . On va éventuellement édicter la règle de style de ne déclarer qu'un | >>>> pointeur par ligne, ou de passer par un typedef. | >>> | >>> pour moi le typedef c'est exclusivement | >>> pour cacher struct, sinon c'est de l'obfuscation... | >> C'est vrai que les types pointeurs sur fonction facilitent la lecture, | >> sans typedef ;) | > | >Je n'en suis pas sûr, mais il me semble bien qu'il y a un truc du genre | >déclarer une fonction de tel ou tel type qu'on ne peut pas faire sans | >typedef. | >Je ne sais pas s'il y a une autre solution, je n'en vois pas, mais je | >l'utilise pour les définitions de structures croisées (problème | >déclaration forward). | | Ca n'est pas necessaire. | | T'as parfaitement le droit de faire | struct a; | | struct b { | struct a *machin; | }; | | et assimiles.
Je trouve que
struct mpz_internal { // ... };
typedef struct mpz_internal mpz_t[1];
permet d'écrire des fonctions qui simulent très bien le passage par réference const, e.e.
mpz_t mpz_negate(const mpz_t);
(et cela marche presque très bien pour des composantes qui sont à l'intersection de C ou C++).
-- Gaby
espie@lain.home (Marc Espie) writes:
| In article <mn.75007d9937d9dd02.79899@wanadoo.fr>,
| Pierre Maurette <maurettepierre@wanadoo.fr> wrote:
| >Mickaël Wolff, le 14/09/2009 a écrit :
| >> Stephane Legras-Decussy wrote:
| >>> "Pierre Maurette" <maurettepierre@wanadoo.fr> a écrit dans le message de
| >>> news: mn.73da7d994f4c3f2b.79899@wanadoo.fr...
| >>>> . On va éventuellement édicter la règle de style de ne déclarer qu'un
| >>>> pointeur par ligne, ou de passer par un typedef.
| >>>
| >>> pour moi le typedef c'est exclusivement
| >>> pour cacher struct, sinon c'est de l'obfuscation...
| >> C'est vrai que les types pointeurs sur fonction facilitent la lecture,
| >> sans typedef ;)
| >
| >Je n'en suis pas sûr, mais il me semble bien qu'il y a un truc du genre
| >déclarer une fonction de tel ou tel type qu'on ne peut pas faire sans
| >typedef.
| >Je ne sais pas s'il y a une autre solution, je n'en vois pas, mais je
| >l'utilise pour les définitions de structures croisées (problème
| >déclaration forward).
|
| Ca n'est pas necessaire.
|
| T'as parfaitement le droit de faire
| struct a;
|
| struct b {
| struct a *machin;
| };
|
| et assimiles.
Je trouve que
struct mpz_internal {
// ...
};
typedef struct mpz_internal mpz_t[1];
permet d'écrire des fonctions qui simulent très bien le passage par
réference const, e.e.
mpz_t mpz_negate(const mpz_t);
(et cela marche presque très bien pour des composantes
qui sont à l'intersection de C ou C++).
| In article , | Pierre Maurette wrote: | >Mickaël Wolff, le 14/09/2009 a écrit : | >> Stephane Legras-Decussy wrote: | >>> "Pierre Maurette" a écrit dans le message de | >>> news: | >>>> . On va éventuellement édicter la règle de style de ne déclarer qu'un | >>>> pointeur par ligne, ou de passer par un typedef. | >>> | >>> pour moi le typedef c'est exclusivement | >>> pour cacher struct, sinon c'est de l'obfuscation... | >> C'est vrai que les types pointeurs sur fonction facilitent la lecture, | >> sans typedef ;) | > | >Je n'en suis pas sûr, mais il me semble bien qu'il y a un truc du genre | >déclarer une fonction de tel ou tel type qu'on ne peut pas faire sans | >typedef. | >Je ne sais pas s'il y a une autre solution, je n'en vois pas, mais je | >l'utilise pour les définitions de structures croisées (problème | >déclaration forward). | | Ca n'est pas necessaire. | | T'as parfaitement le droit de faire | struct a; | | struct b { | struct a *machin; | }; | | et assimiles.
Je trouve que
struct mpz_internal { // ... };
typedef struct mpz_internal mpz_t[1];
permet d'écrire des fonctions qui simulent très bien le passage par réference const, e.e.
mpz_t mpz_negate(const mpz_t);
(et cela marche presque très bien pour des composantes qui sont à l'intersection de C ou C++).
-- Gaby
Gabriel Dos Reis
(Marc Espie) writes:
| In article , | Gabriel Dos Reis wrote: | >| - pas le droit aux fichiers d'entetes imbriques. Tout mettre a plat au | >| depart) | > | >pourquoi ? | | parce que le C possede un seul espace de noms, et que j'ai passe bien trop | longtemps a me battre avec des trucs qui devraient compiler, mais qui ne | compilent pas, parce qu'ils redefinissent une macro au fond d'un entete | de bibliotheque, mais l'entete entre en conflit avec un autre entete. | Deja, quand c'est tout a plat au top-level, c'est pas simple. Quand en plus | c'est enferme au fond de trois entetes, c'est la croix et la banniere a | corriger.
Je trouve la solution de « préfixe » plus simple à pratiquer et à enseigner que les les entêtes à plat.
| Ca evite aussi les dependances "par paresse", style on met tout dans un | fichier d'entetes, ou les dependances fortuites (pas la peine d'inclure | string.h parce qu'il y a deja une bibliotheque du programme qui s'en sert).
Je crois qu'on doit éviter les dépendances inutiles quelque soit leur forme. Cependant, je trouve que l'abstraction -- ignorance selective des détails -- dans l'organisation des fichiers d'entête m'a souvent simplifié la vie et éviter ds migraines qu'une gestion à plat.
| OUI, ce sont tous des choses qui ne sont plus tres vraies en C++ avec un | usage correct des namespace...
Je ne crois pas que ce soit une question de C versus C++. J'ai l'impression que tu t'efforces à introduire ici une distinction entre les deux mondes qui, franchement, n'a pas lieu d'être. Il est courant que des composants C viennent à être reutiliser en C++. Le C donne suffisamment de noix à casser sans avoir à inventer d'autres.
-- Gaby
espie@lain.home (Marc Espie) writes:
| In article <87zl8xisj1.fsf@gauss.cs.tamu.edu>,
| Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
| >| - pas le droit aux fichiers d'entetes imbriques. Tout mettre a plat au
| >| depart)
| >
| >pourquoi ?
|
| parce que le C possede un seul espace de noms, et que j'ai passe bien trop
| longtemps a me battre avec des trucs qui devraient compiler, mais qui ne
| compilent pas, parce qu'ils redefinissent une macro au fond d'un entete
| de bibliotheque, mais l'entete entre en conflit avec un autre entete.
| Deja, quand c'est tout a plat au top-level, c'est pas simple. Quand en plus
| c'est enferme au fond de trois entetes, c'est la croix et la banniere a
| corriger.
Je trouve la solution de « préfixe » plus simple à pratiquer et à
enseigner que les les entêtes à plat.
| Ca evite aussi les dependances "par paresse", style on met tout dans un
| fichier d'entetes, ou les dependances fortuites (pas la peine d'inclure
| string.h parce qu'il y a deja une bibliotheque du programme qui s'en sert).
Je crois qu'on doit éviter les dépendances inutiles quelque soit leur
forme. Cependant, je trouve que l'abstraction -- ignorance selective
des détails -- dans l'organisation des fichiers d'entête m'a souvent
simplifié la vie et éviter ds migraines qu'une gestion à plat.
| OUI, ce sont tous des choses qui ne sont plus tres vraies en C++ avec un
| usage correct des namespace...
Je ne crois pas que ce soit une question de C versus C++. J'ai
l'impression que tu t'efforces à introduire ici une distinction entre
les deux mondes qui, franchement, n'a pas lieu d'être. Il est courant
que des composants C viennent à être reutiliser en C++. Le C donne
suffisamment de noix à casser sans avoir à inventer d'autres.
| In article , | Gabriel Dos Reis wrote: | >| - pas le droit aux fichiers d'entetes imbriques. Tout mettre a plat au | >| depart) | > | >pourquoi ? | | parce que le C possede un seul espace de noms, et que j'ai passe bien trop | longtemps a me battre avec des trucs qui devraient compiler, mais qui ne | compilent pas, parce qu'ils redefinissent une macro au fond d'un entete | de bibliotheque, mais l'entete entre en conflit avec un autre entete. | Deja, quand c'est tout a plat au top-level, c'est pas simple. Quand en plus | c'est enferme au fond de trois entetes, c'est la croix et la banniere a | corriger.
Je trouve la solution de « préfixe » plus simple à pratiquer et à enseigner que les les entêtes à plat.
| Ca evite aussi les dependances "par paresse", style on met tout dans un | fichier d'entetes, ou les dependances fortuites (pas la peine d'inclure | string.h parce qu'il y a deja une bibliotheque du programme qui s'en sert).
Je crois qu'on doit éviter les dépendances inutiles quelque soit leur forme. Cependant, je trouve que l'abstraction -- ignorance selective des détails -- dans l'organisation des fichiers d'entête m'a souvent simplifié la vie et éviter ds migraines qu'une gestion à plat.
| OUI, ce sont tous des choses qui ne sont plus tres vraies en C++ avec un | usage correct des namespace...
Je ne crois pas que ce soit une question de C versus C++. J'ai l'impression que tu t'efforces à introduire ici une distinction entre les deux mondes qui, franchement, n'a pas lieu d'être. Il est courant que des composants C viennent à être reutiliser en C++. Le C donne suffisamment de noix à casser sans avoir à inventer d'autres.
-- Gaby
Gabriel Dos Reis
ld writes:
[...]
| > et que j'ai passe bien trop | > longtemps a me battre avec des trucs qui devraient compiler, mais qui ne | > compilent pas, parce qu'ils redefinissent une macro au fond d'un entete | > de bibliotheque, mais l'entete entre en conflit avec un autre entete. | | Le preprocesseur est bien souvent le bouc emissaire d'un mal plus | profond.
« Furthermore, I would like to abolish CPP. »
-- Gaby
ld <laurent.deniau@gmail.com> writes:
[...]
| > et que j'ai passe bien trop
| > longtemps a me battre avec des trucs qui devraient compiler, mais qui ne
| > compilent pas, parce qu'ils redefinissent une macro au fond d'un entete
| > de bibliotheque, mais l'entete entre en conflit avec un autre entete.
|
| Le preprocesseur est bien souvent le bouc emissaire d'un mal plus
| profond.
| > et que j'ai passe bien trop | > longtemps a me battre avec des trucs qui devraient compiler, mais qui ne | > compilent pas, parce qu'ils redefinissent une macro au fond d'un entete | > de bibliotheque, mais l'entete entre en conflit avec un autre entete. | | Le preprocesseur est bien souvent le bouc emissaire d'un mal plus | profond.
« Furthermore, I would like to abolish CPP. »
-- Gaby
Richard Delorme
Le 14/09/2009 20:01, Marc Espie a écrit :
In article<4aae4785$0$12643$, Richard Delorme wrote:
Le 14/09/2009 14:56, Marc Espie a écrit :
dans tous les cas ou ils finissent par tomber sur des cas ou "ca serait bien", j'essaie de leur expliquer que c'est un ECHEC de conception, ou le developpeur n'a pas reussi a faire assez simple (et de mon point de vue, on en trouve meme dans la bibliotheque standard, FILE * est une grosse connerie, a mon avis).
En quel sens FILE est une connerie ?
Par exemple, ca te rend impossible de prototyper une fonction qui prend un fichier ouvert en parametre sans inclure stdio.h...
si c'est une fonction qui le manipule comme handle opaque, et qui se contente de le passer a une autre fonction, c'est tres cretin.
Si j'ai bien compris, tu veux dire que si l'on avait, par exemple, un "struct file_t" au lieu de FILE, ça allégerait un peu certains codes. Pourquoi pas.
(c'est exactement la raison qui fait que C++ a un iosfwd)
Là j'ai plus de mal à suivre. <iosfwd> est un fichier d'en-tête allégé (sans définition) ce qui ne le différencie pas beaucoup de <stdio.h>. S'il y a beaucoup de définitions, templates et fonctions inlines obligent, dans les fichiers d'en-tête C++, c'est plus rare en C.
-- Richard
Le 14/09/2009 20:01, Marc Espie a écrit :
In article<4aae4785$0$12643$ba4acef3@news.orange.fr>,
Richard Delorme<abulmo@nospam.fr> wrote:
Le 14/09/2009 14:56, Marc Espie a écrit :
dans tous les cas ou ils finissent par tomber sur des cas ou "ca serait
bien", j'essaie de leur expliquer que c'est un ECHEC de conception, ou le
developpeur n'a pas reussi a faire assez simple (et de mon point de vue,
on en trouve meme dans la bibliotheque standard, FILE * est une grosse
connerie, a mon avis).
En quel sens FILE est une connerie ?
Par exemple, ca te rend impossible de prototyper une fonction qui prend
un fichier ouvert en parametre sans inclure stdio.h...
si c'est une fonction qui le manipule comme handle opaque, et qui se contente
de le passer a une autre fonction, c'est tres cretin.
Si j'ai bien compris, tu veux dire que si l'on avait, par exemple, un
"struct file_t" au lieu de FILE, ça allégerait un peu certains codes.
Pourquoi pas.
(c'est exactement la raison qui fait que C++ a un iosfwd)
Là j'ai plus de mal à suivre. <iosfwd> est un fichier d'en-tête allégé
(sans définition) ce qui ne le différencie pas beaucoup de <stdio.h>.
S'il y a beaucoup de définitions, templates et fonctions inlines
obligent, dans les fichiers d'en-tête C++, c'est plus rare en C.
In article<4aae4785$0$12643$, Richard Delorme wrote:
Le 14/09/2009 14:56, Marc Espie a écrit :
dans tous les cas ou ils finissent par tomber sur des cas ou "ca serait bien", j'essaie de leur expliquer que c'est un ECHEC de conception, ou le developpeur n'a pas reussi a faire assez simple (et de mon point de vue, on en trouve meme dans la bibliotheque standard, FILE * est une grosse connerie, a mon avis).
En quel sens FILE est une connerie ?
Par exemple, ca te rend impossible de prototyper une fonction qui prend un fichier ouvert en parametre sans inclure stdio.h...
si c'est une fonction qui le manipule comme handle opaque, et qui se contente de le passer a une autre fonction, c'est tres cretin.
Si j'ai bien compris, tu veux dire que si l'on avait, par exemple, un "struct file_t" au lieu de FILE, ça allégerait un peu certains codes. Pourquoi pas.
(c'est exactement la raison qui fait que C++ a un iosfwd)
Là j'ai plus de mal à suivre. <iosfwd> est un fichier d'en-tête allégé (sans définition) ce qui ne le différencie pas beaucoup de <stdio.h>. S'il y a beaucoup de définitions, templates et fonctions inlines obligent, dans les fichiers d'en-tête C++, c'est plus rare en C.
-- Richard
Gabriel Dos Reis
(Marc Espie) writes:
| In article <4aae4785$0$12643$, | Richard Delorme wrote: | >Le 14/09/2009 14:56, Marc Espie a écrit : | > | >> dans tous les cas ou ils finissent par tomber sur des cas ou "ca serait | >> bien", j'essaie de leur expliquer que c'est un ECHEC de conception, ou le | >> developpeur n'a pas reussi a faire assez simple (et de mon point de vue, | >> on en trouve meme dans la bibliotheque standard, FILE * est une grosse | >> connerie, a mon avis). | > | >En quel sens FILE est une connerie ? | | Par exemple, ca te rend impossible de prototyper une fonction qui prend | un fichier ouvert en parametre sans inclure stdio.h...
Et pourquoi ne voudrais-tu pas inclure <stdio.h> si ta fonction prétend prendre des fichiers ouverts ?
| si c'est une fonction qui le manipule comme handle opaque, et qui se contente | de le passer a une autre fonction, c'est tres cretin.
Non. C'est essayer de duplication de l'information qu'on ne métrise pas qui est nocif.
| (c'est exactement la raison qui fait que C++ a un iosfwd)
La raison en C++ est beaucoup plus profonde et nuancée que cela, et ell n'a rien à avoir avec la simplicité de <stdio.h>.
-- Gaby
espie@lain.home (Marc Espie) writes:
| In article <4aae4785$0$12643$ba4acef3@news.orange.fr>,
| Richard Delorme <abulmo@nospam.fr> wrote:
| >Le 14/09/2009 14:56, Marc Espie a écrit :
| >
| >> dans tous les cas ou ils finissent par tomber sur des cas ou "ca serait
| >> bien", j'essaie de leur expliquer que c'est un ECHEC de conception, ou le
| >> developpeur n'a pas reussi a faire assez simple (et de mon point de vue,
| >> on en trouve meme dans la bibliotheque standard, FILE * est une grosse
| >> connerie, a mon avis).
| >
| >En quel sens FILE est une connerie ?
|
| Par exemple, ca te rend impossible de prototyper une fonction qui prend
| un fichier ouvert en parametre sans inclure stdio.h...
Et pourquoi ne voudrais-tu pas inclure <stdio.h> si ta fonction prétend
prendre des fichiers ouverts ?
| si c'est une fonction qui le manipule comme handle opaque, et qui se contente
| de le passer a une autre fonction, c'est tres cretin.
Non. C'est essayer de duplication de l'information qu'on ne métrise pas
qui est nocif.
| (c'est exactement la raison qui fait que C++ a un iosfwd)
La raison en C++ est beaucoup plus profonde et nuancée que cela, et ell
n'a rien à avoir avec la simplicité de <stdio.h>.
| In article <4aae4785$0$12643$, | Richard Delorme wrote: | >Le 14/09/2009 14:56, Marc Espie a écrit : | > | >> dans tous les cas ou ils finissent par tomber sur des cas ou "ca serait | >> bien", j'essaie de leur expliquer que c'est un ECHEC de conception, ou le | >> developpeur n'a pas reussi a faire assez simple (et de mon point de vue, | >> on en trouve meme dans la bibliotheque standard, FILE * est une grosse | >> connerie, a mon avis). | > | >En quel sens FILE est une connerie ? | | Par exemple, ca te rend impossible de prototyper une fonction qui prend | un fichier ouvert en parametre sans inclure stdio.h...
Et pourquoi ne voudrais-tu pas inclure <stdio.h> si ta fonction prétend prendre des fichiers ouverts ?
| si c'est une fonction qui le manipule comme handle opaque, et qui se contente | de le passer a une autre fonction, c'est tres cretin.
Non. C'est essayer de duplication de l'information qu'on ne métrise pas qui est nocif.
| (c'est exactement la raison qui fait que C++ a un iosfwd)
La raison en C++ est beaucoup plus profonde et nuancée que cela, et ell n'a rien à avoir avec la simplicité de <stdio.h>.
-- Gaby
Gabriel Dos Reis
Richard Delorme writes:
| Le 14/09/2009 20:01, Marc Espie a écrit : | > In article<4aae4785$0$12643$, | > Richard Delorme wrote: | >> Le 14/09/2009 14:56, Marc Espie a écrit : | >> | >>> dans tous les cas ou ils finissent par tomber sur des cas ou "ca serait | >>> bien", j'essaie de leur expliquer que c'est un ECHEC de conception, ou le | >>> developpeur n'a pas reussi a faire assez simple (et de mon point de vue, | >>> on en trouve meme dans la bibliotheque standard, FILE * est une grosse | >>> connerie, a mon avis). | >> | >> En quel sens FILE est une connerie ? | > | > Par exemple, ca te rend impossible de prototyper une fonction qui prend | > un fichier ouvert en parametre sans inclure stdio.h... | > | > si c'est une fonction qui le manipule comme handle opaque, et qui se contente | > de le passer a une autre fonction, c'est tres cretin. | | Si j'ai bien compris, tu veux dire que si l'on avait, par exemple, un | "struct file_t" au lieu de FILE, ça allégerait un peu certains | codes. Pourquoi pas.
avons-nous des exemples de ces codes qui seraient allégés ?
-- Gaby
Richard Delorme <abulmo@nospam.fr> writes:
| Le 14/09/2009 20:01, Marc Espie a écrit :
| > In article<4aae4785$0$12643$ba4acef3@news.orange.fr>,
| > Richard Delorme<abulmo@nospam.fr> wrote:
| >> Le 14/09/2009 14:56, Marc Espie a écrit :
| >>
| >>> dans tous les cas ou ils finissent par tomber sur des cas ou "ca serait
| >>> bien", j'essaie de leur expliquer que c'est un ECHEC de conception, ou le
| >>> developpeur n'a pas reussi a faire assez simple (et de mon point de vue,
| >>> on en trouve meme dans la bibliotheque standard, FILE * est une grosse
| >>> connerie, a mon avis).
| >>
| >> En quel sens FILE est une connerie ?
| >
| > Par exemple, ca te rend impossible de prototyper une fonction qui prend
| > un fichier ouvert en parametre sans inclure stdio.h...
| >
| > si c'est une fonction qui le manipule comme handle opaque, et qui se contente
| > de le passer a une autre fonction, c'est tres cretin.
|
| Si j'ai bien compris, tu veux dire que si l'on avait, par exemple, un
| "struct file_t" au lieu de FILE, ça allégerait un peu certains
| codes. Pourquoi pas.
avons-nous des exemples de ces codes qui seraient allégés ?
| Le 14/09/2009 20:01, Marc Espie a écrit : | > In article<4aae4785$0$12643$, | > Richard Delorme wrote: | >> Le 14/09/2009 14:56, Marc Espie a écrit : | >> | >>> dans tous les cas ou ils finissent par tomber sur des cas ou "ca serait | >>> bien", j'essaie de leur expliquer que c'est un ECHEC de conception, ou le | >>> developpeur n'a pas reussi a faire assez simple (et de mon point de vue, | >>> on en trouve meme dans la bibliotheque standard, FILE * est une grosse | >>> connerie, a mon avis). | >> | >> En quel sens FILE est une connerie ? | > | > Par exemple, ca te rend impossible de prototyper une fonction qui prend | > un fichier ouvert en parametre sans inclure stdio.h... | > | > si c'est une fonction qui le manipule comme handle opaque, et qui se contente | > de le passer a une autre fonction, c'est tres cretin. | | Si j'ai bien compris, tu veux dire que si l'on avait, par exemple, un | "struct file_t" au lieu de FILE, ça allégerait un peu certains | codes. Pourquoi pas.
avons-nous des exemples de ces codes qui seraient allégés ?
-- Gaby
Pierre Maurette
Marc Espie, le 14/09/2009 a écrit :
In article , Pierre Maurette wrote:
[...]
Je n'en suis pas sûr, mais il me semble bien qu'il y a un truc du genre déclarer une fonction de tel ou tel type qu'on ne peut pas faire sans typedef. Je ne sais pas s'il y a une autre solution, je n'en vois pas, mais je l'utilise pour les définitions de structures croisées (problème déclaration forward).
Ca n'est pas necessaire.
T'as parfaitement le droit de faire struct a;
struct b { struct a *machin; };
et assimiles.
Oui, puisque je connais le sizeof de struct a*. Mais si je veux incorporer struct a et non struct a *, je suis de la baise. En fait pour être franc j'ai un peu la tête dans l'oignon, et je ne retrouve pas ce à quoi je me référais. Désolé...
-- Pierre Maurette
Marc Espie, le 14/09/2009 a écrit :
In article <mn.75007d9937d9dd02.79899@wanadoo.fr>,
Pierre Maurette <maurettepierre@wanadoo.fr> wrote:
[...]
Je n'en suis pas sûr, mais il me semble bien qu'il y a un truc du genre
déclarer une fonction de tel ou tel type qu'on ne peut pas faire sans
typedef.
Je ne sais pas s'il y a une autre solution, je n'en vois pas, mais je
l'utilise pour les définitions de structures croisées (problème
déclaration forward).
Ca n'est pas necessaire.
T'as parfaitement le droit de faire
struct a;
struct b {
struct a *machin;
};
et assimiles.
Oui, puisque je connais le sizeof de struct a*. Mais si je veux
incorporer struct a et non struct a *, je suis de la baise.
En fait pour être franc j'ai un peu la tête dans l'oignon, et je ne
retrouve pas ce à quoi je me référais. Désolé...
Je n'en suis pas sûr, mais il me semble bien qu'il y a un truc du genre déclarer une fonction de tel ou tel type qu'on ne peut pas faire sans typedef. Je ne sais pas s'il y a une autre solution, je n'en vois pas, mais je l'utilise pour les définitions de structures croisées (problème déclaration forward).
Ca n'est pas necessaire.
T'as parfaitement le droit de faire struct a;
struct b { struct a *machin; };
et assimiles.
Oui, puisque je connais le sizeof de struct a*. Mais si je veux incorporer struct a et non struct a *, je suis de la baise. En fait pour être franc j'ai un peu la tête dans l'oignon, et je ne retrouve pas ce à quoi je me référais. Désolé...
-- Pierre Maurette
espie
In article , Pierre Maurette wrote:
Oui, puisque je connais le sizeof de struct a*. Mais si je veux incorporer struct a et non struct a *, je suis de la baise. En fait pour être franc j'ai un peu la tête dans l'oignon, et je ne retrouve pas ce à quoi je me référais. Désolé...
Ben de toutes facons, si tu veux incorporer struct a et pas struct a*, t'as pas le choix, tu ne couperas pas a la definition de struct a avant de pouvoir l'incorporer...
In article <mn.75487d9993d86d8e.79899@wanadoo.fr>,
Pierre Maurette <maurettepierre@wanadoo.fr> wrote:
Oui, puisque je connais le sizeof de struct a*. Mais si je veux
incorporer struct a et non struct a *, je suis de la baise.
En fait pour être franc j'ai un peu la tête dans l'oignon, et je ne
retrouve pas ce à quoi je me référais. Désolé...
Ben de toutes facons, si tu veux incorporer struct a et pas struct a*,
t'as pas le choix, tu ne couperas pas a la definition de struct a avant de
pouvoir l'incorporer...
Oui, puisque je connais le sizeof de struct a*. Mais si je veux incorporer struct a et non struct a *, je suis de la baise. En fait pour être franc j'ai un peu la tête dans l'oignon, et je ne retrouve pas ce à quoi je me référais. Désolé...
Ben de toutes facons, si tu veux incorporer struct a et pas struct a*, t'as pas le choix, tu ne couperas pas a la definition de struct a avant de pouvoir l'incorporer...
espie
In article , Gabriel Dos Reis wrote:
"Stephane Legras-Decussy" writes:
| "Pierre Maurette" a écrit dans le message de | news: | >. On va éventuellement édicter la règle de style de ne déclarer qu'un | >pointeur par ligne, ou de passer par un typedef. | | pour moi le typedef c'est exclusivement | pour cacher struct, sinon c'est de l'obfuscation...
Un typedef mème à un type de base sert à exprimer un concept dans un langage même pauvre (comme le C ou C++). On n'écrit pas un programme juste pour la machine ou le compilateur. On écrit un programme pour communiquer des idées à d'autres programmeurs -- e.g. des humains.
Si tu as le temps d'expliquer proprement la notion de type abstrait, et d'expliquer aux etudiants comment ca se debuggue, et pourquoi c'est un outil extremement puissant (et donc passablement dangereux), alors, oui, ca vaut le coup.
Pour ma pomme, je vois plus de conneries resultant de l'usage immodere de typedef que d'usages judicieux: je prefere dire que non, il vaut mieux ne pas s'en servir *sauf excellentes raisons* (qui sont, essentiellement, une tres bonne maitrise de la notion de type abstrait et de portabilite).
In article <877hw1e16t.fsf@gauss.cs.tamu.edu>,
Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
| "Pierre Maurette" <maurettepierre@wanadoo.fr> a écrit dans le message de
| news: mn.73da7d994f4c3f2b.79899@wanadoo.fr...
| >. On va éventuellement édicter la règle de style de ne déclarer qu'un
| >pointeur par ligne, ou de passer par un typedef.
|
| pour moi le typedef c'est exclusivement
| pour cacher struct, sinon c'est de l'obfuscation...
Un typedef mème à un type de base sert à exprimer un concept dans un
langage même pauvre (comme le C ou C++). On n'écrit pas un programme
juste pour la machine ou le compilateur. On écrit un programme pour
communiquer des idées à d'autres programmeurs -- e.g. des humains.
Si tu as le temps d'expliquer proprement la notion de type abstrait, et
d'expliquer aux etudiants comment ca se debuggue, et pourquoi c'est un
outil extremement puissant (et donc passablement dangereux), alors, oui,
ca vaut le coup.
Pour ma pomme, je vois plus de conneries resultant de l'usage immodere de
typedef que d'usages judicieux: je prefere dire que non, il vaut mieux ne
pas s'en servir *sauf excellentes raisons* (qui sont, essentiellement,
une tres bonne maitrise de la notion de type abstrait et de portabilite).
| "Pierre Maurette" a écrit dans le message de | news: | >. On va éventuellement édicter la règle de style de ne déclarer qu'un | >pointeur par ligne, ou de passer par un typedef. | | pour moi le typedef c'est exclusivement | pour cacher struct, sinon c'est de l'obfuscation...
Un typedef mème à un type de base sert à exprimer un concept dans un langage même pauvre (comme le C ou C++). On n'écrit pas un programme juste pour la machine ou le compilateur. On écrit un programme pour communiquer des idées à d'autres programmeurs -- e.g. des humains.
Si tu as le temps d'expliquer proprement la notion de type abstrait, et d'expliquer aux etudiants comment ca se debuggue, et pourquoi c'est un outil extremement puissant (et donc passablement dangereux), alors, oui, ca vaut le coup.
Pour ma pomme, je vois plus de conneries resultant de l'usage immodere de typedef que d'usages judicieux: je prefere dire que non, il vaut mieux ne pas s'en servir *sauf excellentes raisons* (qui sont, essentiellement, une tres bonne maitrise de la notion de type abstrait et de portabilite).
espie
In article , Gabriel Dos Reis wrote:
(Marc Espie) writes:
| In article , | Gabriel Dos Reis wrote: | >| - pas le droit aux fichiers d'entetes imbriques. Tout mettre a plat au | >| depart) | > | >pourquoi ? | | parce que le C possede un seul espace de noms, et que j'ai passe bien trop | longtemps a me battre avec des trucs qui devraient compiler, mais qui ne | compilent pas, parce qu'ils redefinissent une macro au fond d'un entete | de bibliotheque, mais l'entete entre en conflit avec un autre entete. | Deja, quand c'est tout a plat au top-level, c'est pas simple. Quand en plus | c'est enferme au fond de trois entetes, c'est la croix et la banniere a | corriger.
Je trouve la solution de « préfixe » plus simple à pratiquer et à enseigner que les les entêtes à plat.
| Ca evite aussi les dependances "par paresse", style on met tout dans un | fichier d'entetes, ou les dependances fortuites (pas la peine d'inclure | string.h parce qu'il y a deja une bibliotheque du programme qui s'en sert).
Je crois qu'on doit éviter les dépendances inutiles quelque soit leur forme. Cependant, je trouve que l'abstraction -- ignorance selective des détails -- dans l'organisation des fichiers d'entête m'a souvent simplifié la vie et éviter ds migraines qu'une gestion à plat.
Difference d'usage. Comme je porte souvent du code ecrit ailleurs, les fichiers d'entete imbriques me causent plus souvent des migraines que ceux des projets plus simples... les projets gnu etant generalement particulierement gratines, d'ailleurs, cote horreurs qui ne compilent pas trop en dehors de linux, qu'on ne sait pas trop pourquoi au depart...
In article <87skepcm5v.fsf@gauss.cs.tamu.edu>,
Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
espie@lain.home (Marc Espie) writes:
| In article <87zl8xisj1.fsf@gauss.cs.tamu.edu>,
| Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
| >| - pas le droit aux fichiers d'entetes imbriques. Tout mettre a plat au
| >| depart)
| >
| >pourquoi ?
|
| parce que le C possede un seul espace de noms, et que j'ai passe bien trop
| longtemps a me battre avec des trucs qui devraient compiler, mais qui ne
| compilent pas, parce qu'ils redefinissent une macro au fond d'un entete
| de bibliotheque, mais l'entete entre en conflit avec un autre entete.
| Deja, quand c'est tout a plat au top-level, c'est pas simple. Quand en plus
| c'est enferme au fond de trois entetes, c'est la croix et la banniere a
| corriger.
Je trouve la solution de « préfixe » plus simple à pratiquer et à
enseigner que les les entêtes à plat.
| Ca evite aussi les dependances "par paresse", style on met tout dans un
| fichier d'entetes, ou les dependances fortuites (pas la peine d'inclure
| string.h parce qu'il y a deja une bibliotheque du programme qui s'en sert).
Je crois qu'on doit éviter les dépendances inutiles quelque soit leur
forme. Cependant, je trouve que l'abstraction -- ignorance selective
des détails -- dans l'organisation des fichiers d'entête m'a souvent
simplifié la vie et éviter ds migraines qu'une gestion à plat.
Difference d'usage. Comme je porte souvent du code ecrit ailleurs, les
fichiers d'entete imbriques me causent plus souvent des migraines que ceux
des projets plus simples... les projets gnu etant generalement
particulierement gratines, d'ailleurs, cote horreurs qui ne compilent pas
trop en dehors de linux, qu'on ne sait pas trop pourquoi au depart...
| In article , | Gabriel Dos Reis wrote: | >| - pas le droit aux fichiers d'entetes imbriques. Tout mettre a plat au | >| depart) | > | >pourquoi ? | | parce que le C possede un seul espace de noms, et que j'ai passe bien trop | longtemps a me battre avec des trucs qui devraient compiler, mais qui ne | compilent pas, parce qu'ils redefinissent une macro au fond d'un entete | de bibliotheque, mais l'entete entre en conflit avec un autre entete. | Deja, quand c'est tout a plat au top-level, c'est pas simple. Quand en plus | c'est enferme au fond de trois entetes, c'est la croix et la banniere a | corriger.
Je trouve la solution de « préfixe » plus simple à pratiquer et à enseigner que les les entêtes à plat.
| Ca evite aussi les dependances "par paresse", style on met tout dans un | fichier d'entetes, ou les dependances fortuites (pas la peine d'inclure | string.h parce qu'il y a deja une bibliotheque du programme qui s'en sert).
Je crois qu'on doit éviter les dépendances inutiles quelque soit leur forme. Cependant, je trouve que l'abstraction -- ignorance selective des détails -- dans l'organisation des fichiers d'entête m'a souvent simplifié la vie et éviter ds migraines qu'une gestion à plat.
Difference d'usage. Comme je porte souvent du code ecrit ailleurs, les fichiers d'entete imbriques me causent plus souvent des migraines que ceux des projets plus simples... les projets gnu etant generalement particulierement gratines, d'ailleurs, cote horreurs qui ne compilent pas trop en dehors de linux, qu'on ne sait pas trop pourquoi au depart...
