--{ Marc Boyer a plopé ceci: }--C'est aussi mon sentiment, et ça semble idiomatique. Mais
Marc Espie semblait émettre des réserves.
Oui, j'ai vu. Il faut bien entendu que le nom soit bien choisi,
et là, c'est affaire de conventions personnelles (dans mon cas)
ou de règles clairement prédéfinies dans le cas d'un projet.
Il me semble bien qu'à la lecture de ce nom, il soit immédiat
de se dire "c'est un typedef pour ce projet/cette lib".
Et _surtout_, de ne pas passer à la déclaration
d'un typedef pour les pointeurs sur la structure "typedéfée"
à l'étape précedente. Pour moi, un pointeur doit *toujours*
rester explicite. Bon, je ne suis pas une référence non
plus, c'est juste que je fonctionne comme ça :-(
A mon sens, si on fait un typedef, c'est pour définir un nouveau
type, un nouvel usage. En effet, si on a juste besoin d'un pointeur,
je conseillerais de faire une struc avec un unique pointeur dedans.
Euh ? mettre un unique pointeur dans une structure, j'ai du mal
à voir, un petit exemple ?
En fait ce que je voulais dire, c'est
#v+
/* exemple rapide */
#define T_NOM 42
typedef struct
{
char nom[T_NOM+1];
int valeur;
} Mon_Machin;
typedef Mon_Machin *Mon_Machin_Ptr; /* <----- ici */
int main(int argc, char *argv[])
{
Mon_Machin machin;
Mon_Machin_Ptr truc; /* <----- et la */
machin.valeur = 51;
truc = &machin;
return 0;
}
#v-
C'est ce genre de typedef que je n'aime pas, puisque plus loin dans
le code, il n'est pas immédiat que c'est réellement un pointeur C,
l'interprétation est plus "subjective".
--{ Marc Boyer a plopé ceci: }--
C'est aussi mon sentiment, et ça semble idiomatique. Mais
Marc Espie semblait émettre des réserves.
Oui, j'ai vu. Il faut bien entendu que le nom soit bien choisi,
et là, c'est affaire de conventions personnelles (dans mon cas)
ou de règles clairement prédéfinies dans le cas d'un projet.
Il me semble bien qu'à la lecture de ce nom, il soit immédiat
de se dire "c'est un typedef pour ce projet/cette lib".
Et _surtout_, de ne pas passer à la déclaration
d'un typedef pour les pointeurs sur la structure "typedéfée"
à l'étape précedente. Pour moi, un pointeur doit *toujours*
rester explicite. Bon, je ne suis pas une référence non
plus, c'est juste que je fonctionne comme ça :-(
A mon sens, si on fait un typedef, c'est pour définir un nouveau
type, un nouvel usage. En effet, si on a juste besoin d'un pointeur,
je conseillerais de faire une struc avec un unique pointeur dedans.
Euh ? mettre un unique pointeur dans une structure, j'ai du mal
à voir, un petit exemple ?
En fait ce que je voulais dire, c'est
#v+
/* exemple rapide */
#define T_NOM 42
typedef struct
{
char nom[T_NOM+1];
int valeur;
} Mon_Machin;
typedef Mon_Machin *Mon_Machin_Ptr; /* <----- ici */
int main(int argc, char *argv[])
{
Mon_Machin machin;
Mon_Machin_Ptr truc; /* <----- et la */
machin.valeur = 51;
truc = &machin;
return 0;
}
#v-
C'est ce genre de typedef que je n'aime pas, puisque plus loin dans
le code, il n'est pas immédiat que c'est réellement un pointeur C,
l'interprétation est plus "subjective".
--{ Marc Boyer a plopé ceci: }--C'est aussi mon sentiment, et ça semble idiomatique. Mais
Marc Espie semblait émettre des réserves.
Oui, j'ai vu. Il faut bien entendu que le nom soit bien choisi,
et là, c'est affaire de conventions personnelles (dans mon cas)
ou de règles clairement prédéfinies dans le cas d'un projet.
Il me semble bien qu'à la lecture de ce nom, il soit immédiat
de se dire "c'est un typedef pour ce projet/cette lib".
Et _surtout_, de ne pas passer à la déclaration
d'un typedef pour les pointeurs sur la structure "typedéfée"
à l'étape précedente. Pour moi, un pointeur doit *toujours*
rester explicite. Bon, je ne suis pas une référence non
plus, c'est juste que je fonctionne comme ça :-(
A mon sens, si on fait un typedef, c'est pour définir un nouveau
type, un nouvel usage. En effet, si on a juste besoin d'un pointeur,
je conseillerais de faire une struc avec un unique pointeur dedans.
Euh ? mettre un unique pointeur dans une structure, j'ai du mal
à voir, un petit exemple ?
En fait ce que je voulais dire, c'est
#v+
/* exemple rapide */
#define T_NOM 42
typedef struct
{
char nom[T_NOM+1];
int valeur;
} Mon_Machin;
typedef Mon_Machin *Mon_Machin_Ptr; /* <----- ici */
int main(int argc, char *argv[])
{
Mon_Machin machin;
Mon_Machin_Ptr truc; /* <----- et la */
machin.valeur = 51;
truc = &machin;
return 0;
}
#v-
C'est ce genre de typedef que je n'aime pas, puisque plus loin dans
le code, il n'est pas immédiat que c'est réellement un pointeur C,
l'interprétation est plus "subjective".
Les erreurs courantes de debutants sont de mettre des typedef sur des
struct ou des tableaux (oui, je n'aime pas).
Entre:
typedef struct foo foo; // qui ne compile pas en C++
typedef struct foo *machin; // et hop, un pointeur tout ca.
Il semblerait que le programmeur moyen ait beaucoup de mal a comprendre
a quel point un typedef est quelque chose de violent, puisque sa simple
presence suffit a rendre invalide tout le code C qui suit qui a le malheur
d'utiliser le nouveau nom de type pour n'importe quoi, y compris comme
nom de variable locale.
Les erreurs courantes de debutants sont de mettre des typedef sur des
struct ou des tableaux (oui, je n'aime pas).
Entre:
typedef struct foo foo; // qui ne compile pas en C++
typedef struct foo *machin; // et hop, un pointeur tout ca.
Il semblerait que le programmeur moyen ait beaucoup de mal a comprendre
a quel point un typedef est quelque chose de violent, puisque sa simple
presence suffit a rendre invalide tout le code C qui suit qui a le malheur
d'utiliser le nouveau nom de type pour n'importe quoi, y compris comme
nom de variable locale.
Les erreurs courantes de debutants sont de mettre des typedef sur des
struct ou des tableaux (oui, je n'aime pas).
Entre:
typedef struct foo foo; // qui ne compile pas en C++
typedef struct foo *machin; // et hop, un pointeur tout ca.
Il semblerait que le programmeur moyen ait beaucoup de mal a comprendre
a quel point un typedef est quelque chose de violent, puisque sa simple
presence suffit a rendre invalide tout le code C qui suit qui a le malheur
d'utiliser le nouveau nom de type pour n'importe quoi, y compris comme
nom de variable locale.
--{ Marc Boyer a plopé ceci: }--Un commentaire sur le commentaire. Lorsque j'enseigne le C, je
deconseille toujours l'usage de typedef et l'usage de macros (*)
aux debutants.
*: pour autre chose que de betes #define VALUE 42
Même un typedef sur des structs ?
Si, pour moi, celui-ci peut être bien, et même souvent,
comment dire, "clarifiant", à condition que le nom soit
bien choisi.
Et _surtout_, de ne pas passer à la déclaration
d'un typedef pour les pointeurs sur la structure "typedéfée"
à l'étape précedente. Pour moi, un pointeur doit *toujours*
rester explicite.
--{ Marc Boyer a plopé ceci: }--
Un commentaire sur le commentaire. Lorsque j'enseigne le C, je
deconseille toujours l'usage de typedef et l'usage de macros (*)
aux debutants.
*: pour autre chose que de betes #define VALUE 42
Même un typedef sur des structs ?
Si, pour moi, celui-ci peut être bien, et même souvent,
comment dire, "clarifiant", à condition que le nom soit
bien choisi.
Et _surtout_, de ne pas passer à la déclaration
d'un typedef pour les pointeurs sur la structure "typedéfée"
à l'étape précedente. Pour moi, un pointeur doit *toujours*
rester explicite.
--{ Marc Boyer a plopé ceci: }--Un commentaire sur le commentaire. Lorsque j'enseigne le C, je
deconseille toujours l'usage de typedef et l'usage de macros (*)
aux debutants.
*: pour autre chose que de betes #define VALUE 42
Même un typedef sur des structs ?
Si, pour moi, celui-ci peut être bien, et même souvent,
comment dire, "clarifiant", à condition que le nom soit
bien choisi.
Et _surtout_, de ne pas passer à la déclaration
d'un typedef pour les pointeurs sur la structure "typedéfée"
à l'étape précedente. Pour moi, un pointeur doit *toujours*
rester explicite.
(Marc Espie) writes:Les erreurs courantes de debutants sont de mettre des typedef sur des
struct ou des tableaux (oui, je n'aime pas).
J'ai aucun probleme avec les typedef sur les struct (ni meme sur les
pointeurs quand la cible est une struct declaree mais non definie).Entre:
typedef struct foo foo; // qui ne compile pas en C++
Ca devrait.
typedef struct foo * foo;
par contre ne devrait pas.typedef struct foo *machin; // et hop, un pointeur tout ca.
Tant que la seule utilisation de machin c'est de les copier et de les
passer a des fonctions, ca ne me gene pas.Il semblerait que le programmeur moyen ait beaucoup de mal a comprendre
a quel point un typedef est quelque chose de violent, puisque sa simple
presence suffit a rendre invalide tout le code C qui suit qui a le
malheur
d'utiliser le nouveau nom de type pour n'importe quoi, y compris comme
nom de variable locale.
Je ne me rends pas compte de ca. J'ai meme la conviction que c'est faux.
typedef struct x { int x; } x;
int foo() {
x a;
int x;
a.x = 1;
x = 2;
return a.x == x;
}
doit compiler (et compile en C comme en C++ d'ailleurs avec tout les
compilateurs que j'ai essaye)
espie@lain.home (Marc Espie) writes:
Les erreurs courantes de debutants sont de mettre des typedef sur des
struct ou des tableaux (oui, je n'aime pas).
J'ai aucun probleme avec les typedef sur les struct (ni meme sur les
pointeurs quand la cible est une struct declaree mais non definie).
Entre:
typedef struct foo foo; // qui ne compile pas en C++
Ca devrait.
typedef struct foo * foo;
par contre ne devrait pas.
typedef struct foo *machin; // et hop, un pointeur tout ca.
Tant que la seule utilisation de machin c'est de les copier et de les
passer a des fonctions, ca ne me gene pas.
Il semblerait que le programmeur moyen ait beaucoup de mal a comprendre
a quel point un typedef est quelque chose de violent, puisque sa simple
presence suffit a rendre invalide tout le code C qui suit qui a le
malheur
d'utiliser le nouveau nom de type pour n'importe quoi, y compris comme
nom de variable locale.
Je ne me rends pas compte de ca. J'ai meme la conviction que c'est faux.
typedef struct x { int x; } x;
int foo() {
x a;
int x;
a.x = 1;
x = 2;
return a.x == x;
}
doit compiler (et compile en C comme en C++ d'ailleurs avec tout les
compilateurs que j'ai essaye)
(Marc Espie) writes:Les erreurs courantes de debutants sont de mettre des typedef sur des
struct ou des tableaux (oui, je n'aime pas).
J'ai aucun probleme avec les typedef sur les struct (ni meme sur les
pointeurs quand la cible est une struct declaree mais non definie).Entre:
typedef struct foo foo; // qui ne compile pas en C++
Ca devrait.
typedef struct foo * foo;
par contre ne devrait pas.typedef struct foo *machin; // et hop, un pointeur tout ca.
Tant que la seule utilisation de machin c'est de les copier et de les
passer a des fonctions, ca ne me gene pas.Il semblerait que le programmeur moyen ait beaucoup de mal a comprendre
a quel point un typedef est quelque chose de violent, puisque sa simple
presence suffit a rendre invalide tout le code C qui suit qui a le
malheur
d'utiliser le nouveau nom de type pour n'importe quoi, y compris comme
nom de variable locale.
Je ne me rends pas compte de ca. J'ai meme la conviction que c'est faux.
typedef struct x { int x; } x;
int foo() {
x a;
int x;
a.x = 1;
x = 2;
return a.x == x;
}
doit compiler (et compile en C comme en C++ d'ailleurs avec tout les
compilateurs que j'ai essaye)
En revanche, il n'est pas possible d'inverser l'ordre des déclarations de a
et x dans la fonction foo;
Pas possible non plus de nommer une fonction "x"
ce qui est un vrai problème de portabilité.
En revanche, il n'est pas possible d'inverser l'ordre des déclarations de a
et x dans la fonction foo;
Pas possible non plus de nommer une fonction "x"
ce qui est un vrai problème de portabilité.
En revanche, il n'est pas possible d'inverser l'ordre des déclarations de a
et x dans la fonction foo;
Pas possible non plus de nommer une fonction "x"
ce qui est un vrai problème de portabilité.
Programmer en C, c'est aussi se prémunir de sa propre bétise.
Programmer en C, c'est aussi se prémunir de sa propre bétise.
Programmer en C, c'est aussi se prémunir de sa propre bétise.
C'est ce genre de typedef que je n'aime pas, puisque plus loin dans
le code, il n'est pas immédiat que c'est réellement un pointeur C,
l'interprétation est plus "subjective".
C'est surtout execivement moche puisqu'on cache un pointeur dans un
type, mais qu'on va l'utiliser comme un pointeur. Ensuite, on va faire
void foo(Mon_Machin_Ptr x);
pour simuler un passage par référence de Mon_Machin (mode in/out en
algo), alors que l'idiomatique en C, c'est
void foo(Mon_Machin* x);
How much does a slrn weigh?
42.
42 in African or European units?
British units.
C'est ce genre de typedef que je n'aime pas, puisque plus loin dans
le code, il n'est pas immédiat que c'est réellement un pointeur C,
l'interprétation est plus "subjective".
C'est surtout execivement moche puisqu'on cache un pointeur dans un
type, mais qu'on va l'utiliser comme un pointeur. Ensuite, on va faire
void foo(Mon_Machin_Ptr x);
pour simuler un passage par référence de Mon_Machin (mode in/out en
algo), alors que l'idiomatique en C, c'est
void foo(Mon_Machin* x);
How much does a slrn weigh?
42.
42 in African or European units?
British units.
C'est ce genre de typedef que je n'aime pas, puisque plus loin dans
le code, il n'est pas immédiat que c'est réellement un pointeur C,
l'interprétation est plus "subjective".
C'est surtout execivement moche puisqu'on cache un pointeur dans un
type, mais qu'on va l'utiliser comme un pointeur. Ensuite, on va faire
void foo(Mon_Machin_Ptr x);
pour simuler un passage par référence de Mon_Machin (mode in/out en
algo), alors que l'idiomatique en C, c'est
void foo(Mon_Machin* x);
How much does a slrn weigh?
42.
42 in African or European units?
British units.
Marc Espie a ecrit:Il semblerait que le programmeur moyen ait beaucoup de mal a comprendre
a quel point un typedef est quelque chose de violent, puisque sa simple
presence suffit a rendre invalide tout le code C qui suit qui a le malheur
d'utiliser le nouveau nom de type pour n'importe quoi, y compris comme
nom de variable locale.
Je ne me rends pas compte de ca. J'ai meme la conviction que c'est faux.
typedef struct x { int x; } x;
int foo() {
x a;
int x;
a.x = 1;
x = 2;
return a.x == x;
}
doit compiler (et compile en C comme en C++ d'ailleurs avec tout les
compilateurs que j'ai essaye)
Marc Espie a ecrit:
Il semblerait que le programmeur moyen ait beaucoup de mal a comprendre
a quel point un typedef est quelque chose de violent, puisque sa simple
presence suffit a rendre invalide tout le code C qui suit qui a le malheur
d'utiliser le nouveau nom de type pour n'importe quoi, y compris comme
nom de variable locale.
Je ne me rends pas compte de ca. J'ai meme la conviction que c'est faux.
typedef struct x { int x; } x;
int foo() {
x a;
int x;
a.x = 1;
x = 2;
return a.x == x;
}
doit compiler (et compile en C comme en C++ d'ailleurs avec tout les
compilateurs que j'ai essaye)
Marc Espie a ecrit:Il semblerait que le programmeur moyen ait beaucoup de mal a comprendre
a quel point un typedef est quelque chose de violent, puisque sa simple
presence suffit a rendre invalide tout le code C qui suit qui a le malheur
d'utiliser le nouveau nom de type pour n'importe quoi, y compris comme
nom de variable locale.
Je ne me rends pas compte de ca. J'ai meme la conviction que c'est faux.
typedef struct x { int x; } x;
int foo() {
x a;
int x;
a.x = 1;
x = 2;
return a.x == x;
}
doit compiler (et compile en C comme en C++ d'ailleurs avec tout les
compilateurs que j'ai essaye)
In article ,
Jean-Marc Bourguet wrote:Marc Espie a ecrit:Il semblerait que le programmeur moyen ait beaucoup de mal a comprendre
a quel point un typedef est quelque chose de violent, puisque sa simple
presence suffit a rendre invalide tout le code C qui suit qui a le malheur
d'utiliser le nouveau nom de type pour n'importe quoi, y compris comme
nom de variable locale.
Je ne me rends pas compte de ca. J'ai meme la conviction que c'est faux.
typedef struct x { int x; } x;
int foo() {
x a;
int x;
a.x = 1;
x = 2;
return a.x == x;
}
doit compiler (et compile en C comme en C++ d'ailleurs avec tout les
compilateurs que j'ai essaye)
[...]
je prefere le code un peu plus explicite, c'est plus facile pour un
exterieur de rentrer dedans, et j'ai rarement vu des conventions de
nommage suffisamment carrees pour que les typedef aident a rendre les
choses claires (bien au contraire, j'ai vu des tonnes de gens se vautrer
avec des conventions de nommage incorrectes...)
Dans le cadre tres particulier de l'audit de code, tout ce que font les
typedef, c'est rendre le code plus difficile a lire, et masquer les
problemes...
In article <pxbmyz6u891.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> wrote:
Marc Espie a ecrit:
Il semblerait que le programmeur moyen ait beaucoup de mal a comprendre
a quel point un typedef est quelque chose de violent, puisque sa simple
presence suffit a rendre invalide tout le code C qui suit qui a le malheur
d'utiliser le nouveau nom de type pour n'importe quoi, y compris comme
nom de variable locale.
Je ne me rends pas compte de ca. J'ai meme la conviction que c'est faux.
typedef struct x { int x; } x;
int foo() {
x a;
int x;
a.x = 1;
x = 2;
return a.x == x;
}
doit compiler (et compile en C comme en C++ d'ailleurs avec tout les
compilateurs que j'ai essaye)
[...]
je prefere le code un peu plus explicite, c'est plus facile pour un
exterieur de rentrer dedans, et j'ai rarement vu des conventions de
nommage suffisamment carrees pour que les typedef aident a rendre les
choses claires (bien au contraire, j'ai vu des tonnes de gens se vautrer
avec des conventions de nommage incorrectes...)
Dans le cadre tres particulier de l'audit de code, tout ce que font les
typedef, c'est rendre le code plus difficile a lire, et masquer les
problemes...
In article ,
Jean-Marc Bourguet wrote:Marc Espie a ecrit:Il semblerait que le programmeur moyen ait beaucoup de mal a comprendre
a quel point un typedef est quelque chose de violent, puisque sa simple
presence suffit a rendre invalide tout le code C qui suit qui a le malheur
d'utiliser le nouveau nom de type pour n'importe quoi, y compris comme
nom de variable locale.
Je ne me rends pas compte de ca. J'ai meme la conviction que c'est faux.
typedef struct x { int x; } x;
int foo() {
x a;
int x;
a.x = 1;
x = 2;
return a.x == x;
}
doit compiler (et compile en C comme en C++ d'ailleurs avec tout les
compilateurs que j'ai essaye)
[...]
je prefere le code un peu plus explicite, c'est plus facile pour un
exterieur de rentrer dedans, et j'ai rarement vu des conventions de
nommage suffisamment carrees pour que les typedef aident a rendre les
choses claires (bien au contraire, j'ai vu des tonnes de gens se vautrer
avec des conventions de nommage incorrectes...)
Dans le cadre tres particulier de l'audit de code, tout ce que font les
typedef, c'est rendre le code plus difficile a lire, et masquer les
problemes...
Lorsque je vois une fonction de prototype:
void f(struct machin *a);
je sais ce que la fonction prend comme parametre, et a quoi je peux
m'attendre comme semantique.
Lorsque je vois une fonction de prototype
void f(machin a);
eh bien, je ne sais pas si machin est un type scalaire, un type pointeur
(de quel niveau ?) ou autre chose. Faudra que j'aille chercher sa definition
pour comprendre ce qui se passe, meme au niveau syntaxique.
Lorsque je vois une fonction de prototype:
void f(struct machin *a);
je sais ce que la fonction prend comme parametre, et a quoi je peux
m'attendre comme semantique.
Lorsque je vois une fonction de prototype
void f(machin a);
eh bien, je ne sais pas si machin est un type scalaire, un type pointeur
(de quel niveau ?) ou autre chose. Faudra que j'aille chercher sa definition
pour comprendre ce qui se passe, meme au niveau syntaxique.
Lorsque je vois une fonction de prototype:
void f(struct machin *a);
je sais ce que la fonction prend comme parametre, et a quoi je peux
m'attendre comme semantique.
Lorsque je vois une fonction de prototype
void f(machin a);
eh bien, je ne sais pas si machin est un type scalaire, un type pointeur
(de quel niveau ?) ou autre chose. Faudra que j'aille chercher sa definition
pour comprendre ce qui se passe, meme au niveau syntaxique.