Cela est bien rigolo, mais un tantinet illisible (cependant, je ne
développe pas professionnellement en C, donc mon avis est peut-être
non pertinent...).
Qui plus est, je me pose une petite question : comment comptez-vous
utiliser les membres de votre structure ? En effet, quand bien même
vous conserveriez cette structure alambiquée et vous auriez trouvé
une manière d'itérer sur ses membres (votre question d'origine, si
je ne m'abuse), que feriez-vous exactement du résultat de cette
itération ?
Bref, dans la mesure où la tronche de votre structure va dépendre de
toutes vos "constantes de compilation" (pardonnez la terminologie
incertaine), quel comportement universel voulez-vous faire avec votre
itération ?
Cela est bien rigolo, mais un tantinet illisible (cependant, je ne
développe pas professionnellement en C, donc mon avis est peut-être
non pertinent...).
Qui plus est, je me pose une petite question : comment comptez-vous
utiliser les membres de votre structure ? En effet, quand bien même
vous conserveriez cette structure alambiquée et vous auriez trouvé
une manière d'itérer sur ses membres (votre question d'origine, si
je ne m'abuse), que feriez-vous exactement du résultat de cette
itération ?
Bref, dans la mesure où la tronche de votre structure va dépendre de
toutes vos "constantes de compilation" (pardonnez la terminologie
incertaine), quel comportement universel voulez-vous faire avec votre
itération ?
Cela est bien rigolo, mais un tantinet illisible (cependant, je ne
développe pas professionnellement en C, donc mon avis est peut-être
non pertinent...).
Qui plus est, je me pose une petite question : comment comptez-vous
utiliser les membres de votre structure ? En effet, quand bien même
vous conserveriez cette structure alambiquée et vous auriez trouvé
une manière d'itérer sur ses membres (votre question d'origine, si
je ne m'abuse), que feriez-vous exactement du résultat de cette
itération ?
Bref, dans la mesure où la tronche de votre structure va dépendre de
toutes vos "constantes de compilation" (pardonnez la terminologie
incertaine), quel comportement universel voulez-vous faire avec votre
itération ?
tu te prends la tête sur des trucs "gadget" de C qui cachent une grosse
mauvaise
conception en fait...
tu te prends la tête sur des trucs "gadget" de C qui cachent une grosse
mauvaise
conception en fait...
tu te prends la tête sur des trucs "gadget" de C qui cachent une grosse
mauvaise
conception en fait...
Pour en revenir au sujet, un forum concernant un langage particulier
n'est pas compétent pour cela.
C'est dommage car il me semble qu'il y a des personnes ici qui sont
compétentes en ce domaine.
Pour en revenir au sujet, un forum concernant un langage particulier
n'est pas compétent pour cela.
C'est dommage car il me semble qu'il y a des personnes ici qui sont
compétentes en ce domaine.
Pour en revenir au sujet, un forum concernant un langage particulier
n'est pas compétent pour cela.
C'est dommage car il me semble qu'il y a des personnes ici qui sont
compétentes en ce domaine.
Tu m'expliques que tu as besoin d'une structure avec des
champs variants suivant les define donnes lors de la
compilation. Je n'ai toujours pas compris quel est le
problème qui impose une telle solution. Je n'ai pas non
plus compris comment on utilise une telle structure sans
placer des ifdef partout, ce qui a priori est une mauvaise
idée.
Les principales alternatives ont déjà été données (plusieurs
structures, plusieurs définition de la même structure mais
n'en prendre qu'une, avoir dans la structure une table de
propriétés) mais t'indiquer quel est la bonne sans avoir une
idée du problème (jusqu'à présent on a une idée des
problèmes que te pose la solution que tu as choisie, ce qui
n'est pas du tout la même chose), c'est hors de ma
compétance.
Tu m'expliques que tu as besoin d'une structure avec des
champs variants suivant les define donnes lors de la
compilation. Je n'ai toujours pas compris quel est le
problème qui impose une telle solution. Je n'ai pas non
plus compris comment on utilise une telle structure sans
placer des ifdef partout, ce qui a priori est une mauvaise
idée.
Les principales alternatives ont déjà été données (plusieurs
structures, plusieurs définition de la même structure mais
n'en prendre qu'une, avoir dans la structure une table de
propriétés) mais t'indiquer quel est la bonne sans avoir une
idée du problème (jusqu'à présent on a une idée des
problèmes que te pose la solution que tu as choisie, ce qui
n'est pas du tout la même chose), c'est hors de ma
compétance.
Tu m'expliques que tu as besoin d'une structure avec des
champs variants suivant les define donnes lors de la
compilation. Je n'ai toujours pas compris quel est le
problème qui impose une telle solution. Je n'ai pas non
plus compris comment on utilise une telle structure sans
placer des ifdef partout, ce qui a priori est une mauvaise
idée.
Les principales alternatives ont déjà été données (plusieurs
structures, plusieurs définition de la même structure mais
n'en prendre qu'une, avoir dans la structure une table de
propriétés) mais t'indiquer quel est la bonne sans avoir une
idée du problème (jusqu'à présent on a une idée des
problèmes que te pose la solution que tu as choisie, ce qui
n'est pas du tout la même chose), c'est hors de ma
compétance.
. des choses relatives à la plateforme comme l'endianness, si le stack
va vers le haut ou le bas et des choses aussi palpitantes.
. des options de génération du logiciel (genre with-feature blah).
. Des choses qu'on est obligé de tester si on veut avoir des chances de
tourner sur plusieurs systèmes.
Je rajouterais plusieurs choses qui sont gérables par les #if:
C'est dommage car il me semble qu'il y a des personnes ici qui sont
compétentes en ce domaine.
. des choses relatives à la plateforme comme l'endianness, si le stack
va vers le haut ou le bas et des choses aussi palpitantes.
. des options de génération du logiciel (genre with-feature blah).
. Des choses qu'on est obligé de tester si on veut avoir des chances de
tourner sur plusieurs systèmes.
Je rajouterais plusieurs choses qui sont gérables par les #if:
C'est dommage car il me semble qu'il y a des personnes ici qui sont
compétentes en ce domaine.
. des choses relatives à la plateforme comme l'endianness, si le stack
va vers le haut ou le bas et des choses aussi palpitantes.
. des options de génération du logiciel (genre with-feature blah).
. Des choses qu'on est obligé de tester si on veut avoir des chances de
tourner sur plusieurs systèmes.
Je rajouterais plusieurs choses qui sont gérables par les #if:
C'est dommage car il me semble qu'il y a des personnes ici qui sont
compétentes en ce domaine.
Mon problème est [...]
Mon problème est [...]
Mon problème est [...]
Harpo wrote:
Je ne vois pas pourquoi le forum n'est pas adapté, car j'ai posté du C
dans certains de mes posts de ce thread, et j'attends bien des
solutions en C. Concernant la conception du projet, le fait d'avoir
mis ces constantes préprocesseur ne doit pas préjuger du reste du
programme (que je revendique de relative bonne qualité). Les
constantes préprocesseurs sont bien une possibilité offerte par le C,
après tout, je ne suis pas dans un milieu d'informaticiens, loin de
là, donc en tant qu'autodidacte, je ne vois pas pourquoi je m'en
serais privé, d'autant plus que ni le K&R, ni le H&S, indiquent de ne
pas les utiliser (de mémoire).
Mon problème est d'avoir une structure avec juste ce qu'il faut
suivant le cas à traiter (pour l'exemple donné plus haut, à savoir si
l'on est dans la MANGROVE, sur MARS, ou au GROENLAND). Cette structure
contient dans mon cas précis tout un tas de pointeurs, que je veux
allouer et libérer automatiquement en itérant sur la structure, au
lieu de reporter les mêmes constantes préprocesseur dans la fonction
d'allocation et libération: je vois bien que ces constantes ne sont
pas très lisibles, donc je viens vous voir afin de ne les employer
tout au plus que dans la définition de la structure.
Harpo wrote:
Je ne vois pas pourquoi le forum n'est pas adapté, car j'ai posté du C
dans certains de mes posts de ce thread, et j'attends bien des
solutions en C. Concernant la conception du projet, le fait d'avoir
mis ces constantes préprocesseur ne doit pas préjuger du reste du
programme (que je revendique de relative bonne qualité). Les
constantes préprocesseurs sont bien une possibilité offerte par le C,
après tout, je ne suis pas dans un milieu d'informaticiens, loin de
là, donc en tant qu'autodidacte, je ne vois pas pourquoi je m'en
serais privé, d'autant plus que ni le K&R, ni le H&S, indiquent de ne
pas les utiliser (de mémoire).
Mon problème est d'avoir une structure avec juste ce qu'il faut
suivant le cas à traiter (pour l'exemple donné plus haut, à savoir si
l'on est dans la MANGROVE, sur MARS, ou au GROENLAND). Cette structure
contient dans mon cas précis tout un tas de pointeurs, que je veux
allouer et libérer automatiquement en itérant sur la structure, au
lieu de reporter les mêmes constantes préprocesseur dans la fonction
d'allocation et libération: je vois bien que ces constantes ne sont
pas très lisibles, donc je viens vous voir afin de ne les employer
tout au plus que dans la définition de la structure.
Harpo wrote:
Je ne vois pas pourquoi le forum n'est pas adapté, car j'ai posté du C
dans certains de mes posts de ce thread, et j'attends bien des
solutions en C. Concernant la conception du projet, le fait d'avoir
mis ces constantes préprocesseur ne doit pas préjuger du reste du
programme (que je revendique de relative bonne qualité). Les
constantes préprocesseurs sont bien une possibilité offerte par le C,
après tout, je ne suis pas dans un milieu d'informaticiens, loin de
là, donc en tant qu'autodidacte, je ne vois pas pourquoi je m'en
serais privé, d'autant plus que ni le K&R, ni le H&S, indiquent de ne
pas les utiliser (de mémoire).
Mon problème est d'avoir une structure avec juste ce qu'il faut
suivant le cas à traiter (pour l'exemple donné plus haut, à savoir si
l'on est dans la MANGROVE, sur MARS, ou au GROENLAND). Cette structure
contient dans mon cas précis tout un tas de pointeurs, que je veux
allouer et libérer automatiquement en itérant sur la structure, au
lieu de reporter les mêmes constantes préprocesseur dans la fonction
d'allocation et libération: je vois bien que ces constantes ne sont
pas très lisibles, donc je viens vous voir afin de ne les employer
tout au plus que dans la définition de la structure.
On 2005-04-15, Harpo wrote:. des choses relatives à la plateforme comme l'endianness, si le
stack va vers le haut ou le bas et des choses aussi palpitantes.
. des options de génération du logiciel (genre with-feature blah).
. Des choses qu'on est obligé de tester si on veut avoir des chances
de tourner sur plusieurs systèmes.
Je rajouterais plusieurs choses qui sont gérables par les #if:
o les messages/fenêtres/io de trace.
o le code utilisé pour les tests unitaires.
o le code de chronométrage.
J'ai compté récemment sur un kluge que je confectionne, ça
représente peut-être un quart des lignes. Dans ce quart, il
y a probablement beaucoup de trucs qui sont devenus inutiles,
mais dont je risque d'avoir besoin dans quelques mois/années.
On 2005-04-15, Harpo <trashcan@hotmail.com> wrote:
. des choses relatives à la plateforme comme l'endianness, si le
stack va vers le haut ou le bas et des choses aussi palpitantes.
. des options de génération du logiciel (genre with-feature blah).
. Des choses qu'on est obligé de tester si on veut avoir des chances
de tourner sur plusieurs systèmes.
Je rajouterais plusieurs choses qui sont gérables par les #if:
o les messages/fenêtres/io de trace.
o le code utilisé pour les tests unitaires.
o le code de chronométrage.
J'ai compté récemment sur un kluge que je confectionne, ça
représente peut-être un quart des lignes. Dans ce quart, il
y a probablement beaucoup de trucs qui sont devenus inutiles,
mais dont je risque d'avoir besoin dans quelques mois/années.
On 2005-04-15, Harpo wrote:. des choses relatives à la plateforme comme l'endianness, si le
stack va vers le haut ou le bas et des choses aussi palpitantes.
. des options de génération du logiciel (genre with-feature blah).
. Des choses qu'on est obligé de tester si on veut avoir des chances
de tourner sur plusieurs systèmes.
Je rajouterais plusieurs choses qui sont gérables par les #if:
o les messages/fenêtres/io de trace.
o le code utilisé pour les tests unitaires.
o le code de chronométrage.
J'ai compté récemment sur un kluge que je confectionne, ça
représente peut-être un quart des lignes. Dans ce quart, il
y a probablement beaucoup de trucs qui sont devenus inutiles,
mais dont je risque d'avoir besoin dans quelques mois/années.
Soit c'est su au moment de la compilation du programme, auquel cas on
peut utiliser le préprocesseur, mais on peut se demander s'il ne vaut
pas mieux faire 3 programmes et des fonctions communes au 3 programmes.
J'ai fait un petit exemple, je ne l'ai pas testé, j'ai remplacé mangrove
par igloo, hlm, cabane car je ne connais pas de manière détaillée les
caractéristiques des maisons martiennes :
Les différentes unions et structures ont été détaillées, il y a moyen de
faire plus concis.
==================================== > #include <stdio.h>
#include <stdlib.h>
// ----------------- .h
typedef enum
{
// La maison peut être un igloo, un hlm et une cabane
igloo, hlm, cabane
} MaisonType ;
typedef struct
{
int temperature ;
unsigned int diametre ;
// des pointeurs
} Igloo ;
typedef struct
{
unsigned int etages ;
unsigned int largeur ;
unsigned int longueur ;
// un tas de pointeurs
} Hlm ;
typedef struct
{
unsigned int hauteur ;
} Cabane ;
typedef union
{
Igloo igloo ;
Hlm hlm ;
Cabane cabane ;
} Maison ;
typedef struct
{
MaisonType type ;
Maison * maison ;
} MaisonPtr ;
// -----------------
int
main( void )
{
MaisonPtr m ;
// on alloue une maison, un igloo mais ça aurait pu être autre chose
m.maison = malloc( sizeof( *( m.maison ) ) ) ;
// tester le malloc
m.type = igloo ;
m.maison->igloo.temperature = -20 ;
m.maison->igloo.diametre = 12 ;
// allouer la mémoire et renseigner les pointeurs de l'igloo
// il faut désallouer la maison
if ( m.type == igloo )
{
printf("temp : %dn", m.maison->igloo.temperature) ;
// liberer la mémoire de l'igloo
}
free( m.maison ) ;
//
exit( EXIT_SUCCESS ) ;
}
====================================
--
Soit c'est su au moment de la compilation du programme, auquel cas on
peut utiliser le préprocesseur, mais on peut se demander s'il ne vaut
pas mieux faire 3 programmes et des fonctions communes au 3 programmes.
J'ai fait un petit exemple, je ne l'ai pas testé, j'ai remplacé mangrove
par igloo, hlm, cabane car je ne connais pas de manière détaillée les
caractéristiques des maisons martiennes :
Les différentes unions et structures ont été détaillées, il y a moyen de
faire plus concis.
==================================== > #include <stdio.h>
#include <stdlib.h>
// ----------------- .h
typedef enum
{
// La maison peut être un igloo, un hlm et une cabane
igloo, hlm, cabane
} MaisonType ;
typedef struct
{
int temperature ;
unsigned int diametre ;
// des pointeurs
} Igloo ;
typedef struct
{
unsigned int etages ;
unsigned int largeur ;
unsigned int longueur ;
// un tas de pointeurs
} Hlm ;
typedef struct
{
unsigned int hauteur ;
} Cabane ;
typedef union
{
Igloo igloo ;
Hlm hlm ;
Cabane cabane ;
} Maison ;
typedef struct
{
MaisonType type ;
Maison * maison ;
} MaisonPtr ;
// -----------------
int
main( void )
{
MaisonPtr m ;
// on alloue une maison, un igloo mais ça aurait pu être autre chose
m.maison = malloc( sizeof( *( m.maison ) ) ) ;
// tester le malloc
m.type = igloo ;
m.maison->igloo.temperature = -20 ;
m.maison->igloo.diametre = 12 ;
// allouer la mémoire et renseigner les pointeurs de l'igloo
// il faut désallouer la maison
if ( m.type == igloo )
{
printf("temp : %dn", m.maison->igloo.temperature) ;
// liberer la mémoire de l'igloo
}
free( m.maison ) ;
//
exit( EXIT_SUCCESS ) ;
}
====================================
--
Soit c'est su au moment de la compilation du programme, auquel cas on
peut utiliser le préprocesseur, mais on peut se demander s'il ne vaut
pas mieux faire 3 programmes et des fonctions communes au 3 programmes.
J'ai fait un petit exemple, je ne l'ai pas testé, j'ai remplacé mangrove
par igloo, hlm, cabane car je ne connais pas de manière détaillée les
caractéristiques des maisons martiennes :
Les différentes unions et structures ont été détaillées, il y a moyen de
faire plus concis.
==================================== > #include <stdio.h>
#include <stdlib.h>
// ----------------- .h
typedef enum
{
// La maison peut être un igloo, un hlm et une cabane
igloo, hlm, cabane
} MaisonType ;
typedef struct
{
int temperature ;
unsigned int diametre ;
// des pointeurs
} Igloo ;
typedef struct
{
unsigned int etages ;
unsigned int largeur ;
unsigned int longueur ;
// un tas de pointeurs
} Hlm ;
typedef struct
{
unsigned int hauteur ;
} Cabane ;
typedef union
{
Igloo igloo ;
Hlm hlm ;
Cabane cabane ;
} Maison ;
typedef struct
{
MaisonType type ;
Maison * maison ;
} MaisonPtr ;
// -----------------
int
main( void )
{
MaisonPtr m ;
// on alloue une maison, un igloo mais ça aurait pu être autre chose
m.maison = malloc( sizeof( *( m.maison ) ) ) ;
// tester le malloc
m.type = igloo ;
m.maison->igloo.temperature = -20 ;
m.maison->igloo.diametre = 12 ;
// allouer la mémoire et renseigner les pointeurs de l'igloo
// il faut désallouer la maison
if ( m.type == igloo )
{
printf("temp : %dn", m.maison->igloo.temperature) ;
// liberer la mémoire de l'igloo
}
free( m.maison ) ;
//
exit( EXIT_SUCCESS ) ;
}
====================================
--
Soit c'est su au moment de la compilation du programme, auquel cas on
peut utiliser le préprocesseur, mais on peut se demander s'il ne vaut
pas mieux faire 3 programmes et des fonctions communes au 3 programmes.
Soit c'est su au moment de la compilation du programme, auquel cas on
peut utiliser le préprocesseur, mais on peut se demander s'il ne vaut
pas mieux faire 3 programmes et des fonctions communes au 3 programmes.
Soit c'est su au moment de la compilation du programme, auquel cas on
peut utiliser le préprocesseur, mais on peut se demander s'il ne vaut
pas mieux faire 3 programmes et des fonctions communes au 3 programmes.
