J'ai une structure coucou comprenant des pointeurs. Dans certaines
conditions je cherche à allouer ou à libérer ces pointeurs. Je peux tout
faire à la main sans problème. Mais étant donné qu'un plus ou moins grand
nombre de ces pointeurs existe réellement dans la structure (du fait de
constantes préprocesseurs), j'aimerais ne pas avoir à changer mes fonctions
d'allocation et de libération de cette structure à chaque fois que je
rajoute un pointeur dans la structure ou que je change une constante
préprocesseur (par exemple).
C'est pourquoi j'aimerais pouvoir parcourir les divers pointeurs présents
dans la structure sans avoir à me soucier de leur nom, avec une sorte
d'itérateur. L'idée serait alors de tester le type du pointeur en cours, et
d'en déduire la bonne méthode d'allocation ou libération.
Comment peut-on réaliser cela en C?
Par ailleurs, je travaille sur un projet C depuis un bon moment, le
programme commence à être relativement conséquent (tout est relatif, c'est
un programme d'informatique scientifique: le nombre de lignes en ferait
sans doute sourire plus d'un sur ce forum). Un bon nombre de constantes
préprocesseurs sont bien pratiques (imbrication parfois de trois #ifdef
avec des && et || préprocesseurs), mais peuvent parfois gêner la lisibilité
et le parcours du code (sans le fameux % de vim, cela serait vraiment
laborieux). Que pensent les programmeurs professionnels et expérimentés des
constantes préprocesseur?
Merci d'avance pour vos conseils avisés,
Julien
--
"Allez, Monsieur, allez, et la foi vous viendra." (D'Alembert).
Je ne suis pas sur de tout comprendre. Est-ce un truc du genre typedef struct { #ifdef OPTION_1 int* popt1; #endif double* toujours_la; #ifdef OPTION_2 char* popt2; #endif } Coucou;
Oui, c'est bien ça, en emboitant des constantes préprocesseur ensemble, et avec une trentaine de champs.
Quelle horreur. Quel est le problème que tu essaies de résoudre? J'ai comme l'impression qu'il doit y avoir de meilleures solutions.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je ne suis pas sur de tout comprendre. Est-ce un truc du genre
typedef struct {
#ifdef OPTION_1
int* popt1;
#endif
double* toujours_la;
#ifdef OPTION_2
char* popt2;
#endif
} Coucou;
Oui, c'est bien ça, en emboitant des constantes préprocesseur ensemble, et
avec une trentaine de champs.
Quelle horreur. Quel est le problème que tu essaies de
résoudre? J'ai comme l'impression qu'il doit y avoir de
meilleures solutions.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je ne suis pas sur de tout comprendre. Est-ce un truc du genre typedef struct { #ifdef OPTION_1 int* popt1; #endif double* toujours_la; #ifdef OPTION_2 char* popt2; #endif } Coucou;
Oui, c'est bien ça, en emboitant des constantes préprocesseur ensemble, et avec une trentaine de champs.
Quelle horreur. Quel est le problème que tu essaies de résoudre? J'ai comme l'impression qu'il doit y avoir de meilleures solutions.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
Julien SCORDIA writes:
Est-il aisé de partir d'un programme C et d'utiliser quelques bribes de C++ là où c'est pratique? (comme ça, je dirais non ;-)) )
C'est aisé, c'est vraissemblablement une des causes du succès de C++. C'est relativement facile de prendre un programme C tel quel et de le recompiler en C++; le compilateur va te trouver la plupart des endroits où des changements sont à faire et si tu as une assez bonne couverture de tests, trouver les rares autres changements est facile. Après tu ajoutes le C++ que tu veux. Alternativement, tu continues à compiler le C en C et tu écris en C++ les nouveaux modules ou ceux qui subissent d'importantes modifications. C'est d'après mon expérience un peu moins confortable.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Est-il aisé de partir d'un programme C et d'utiliser
quelques bribes de C++ là où c'est pratique? (comme ça, je
dirais non ;-)) )
C'est aisé, c'est vraissemblablement une des causes du
succès de C++. C'est relativement facile de prendre un
programme C tel quel et de le recompiler en C++; le
compilateur va te trouver la plupart des endroits où des
changements sont à faire et si tu as une assez bonne
couverture de tests, trouver les rares autres changements
est facile. Après tu ajoutes le C++ que tu veux.
Alternativement, tu continues à compiler le C en C et tu
écris en C++ les nouveaux modules ou ceux qui subissent
d'importantes modifications. C'est d'après mon expérience
un peu moins confortable.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Est-il aisé de partir d'un programme C et d'utiliser quelques bribes de C++ là où c'est pratique? (comme ça, je dirais non ;-)) )
C'est aisé, c'est vraissemblablement une des causes du succès de C++. C'est relativement facile de prendre un programme C tel quel et de le recompiler en C++; le compilateur va te trouver la plupart des endroits où des changements sont à faire et si tu as une assez bonne couverture de tests, trouver les rares autres changements est facile. Après tu ajoutes le C++ que tu veux. Alternativement, tu continues à compiler le C en C et tu écris en C++ les nouveaux modules ou ceux qui subissent d'importantes modifications. C'est d'après mon expérience un peu moins confortable.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
"Antoine Leca" writes:
Je ne connais pour ainsi dire rien sur C++, en dehors d'un bouquin de Stroustrup que j'ai lu il y a 20 ans et qui ne m'a guère plu, et des inférences que je peux faire de par ma connaissance des autres langages de programmation et des normes.
J'ai beaucoup d'admiration pour ceux qui ont appris dans la première édition the TC++PL, je l'ai lue mais mes souvenirs sont de la même sorte que les tiens. Je connais quelqu'un qui prétend l'a brulée de rage...
Comme il va bien falloir que je m'y mettes un jour, à la place de « C++ pour les Nuls », quelqu'un aurait les références d'un bon « C++ pour les programmeurs C chevronnés » ?
À mon avis, tu devrais essayer la 3ième édition de TC++PL, Stroustrup est un auteur qui s'est fortement amélioré. (Personnellement, j'ai appris dans la 2ième édition; je n'ai pas lu la 3ième de bout en bout mais m'en sert comme référence avant d'aller pêcher dans la norme).
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
"Antoine Leca" <root@localhost.invalid> writes:
Je ne connais pour ainsi dire rien sur C++, en dehors d'un
bouquin de Stroustrup que j'ai lu il y a 20 ans et qui ne
m'a guère plu, et des inférences que je peux faire de par
ma connaissance des autres langages de programmation et
des normes.
J'ai beaucoup d'admiration pour ceux qui ont appris dans la
première édition the TC++PL, je l'ai lue mais mes souvenirs
sont de la même sorte que les tiens. Je connais quelqu'un
qui prétend l'a brulée de rage...
Comme il va bien falloir que je m'y mettes un jour, à la
place de « C++ pour les Nuls », quelqu'un aurait les
références d'un bon « C++ pour les programmeurs C
chevronnés » ?
À mon avis, tu devrais essayer la 3ième édition de TC++PL,
Stroustrup est un auteur qui s'est fortement amélioré.
(Personnellement, j'ai appris dans la 2ième édition; je n'ai
pas lu la 3ième de bout en bout mais m'en sert comme
référence avant d'aller pêcher dans la norme).
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je ne connais pour ainsi dire rien sur C++, en dehors d'un bouquin de Stroustrup que j'ai lu il y a 20 ans et qui ne m'a guère plu, et des inférences que je peux faire de par ma connaissance des autres langages de programmation et des normes.
J'ai beaucoup d'admiration pour ceux qui ont appris dans la première édition the TC++PL, je l'ai lue mais mes souvenirs sont de la même sorte que les tiens. Je connais quelqu'un qui prétend l'a brulée de rage...
Comme il va bien falloir que je m'y mettes un jour, à la place de « C++ pour les Nuls », quelqu'un aurait les références d'un bon « C++ pour les programmeurs C chevronnés » ?
À mon avis, tu devrais essayer la 3ième édition de TC++PL, Stroustrup est un auteur qui s'est fortement amélioré. (Personnellement, j'ai appris dans la 2ième édition; je n'ai pas lu la 3ième de bout en bout mais m'en sert comme référence avant d'aller pêcher dans la norme).
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
K. Ahausse
"Antoine Leca" a écrit dans le message de news:d3la6q$b4j$
Je ne connais pour ainsi dire rien sur C++, en dehors d'un bouquin de Stroustrup que j'ai lu il y a 20 ans et qui ne m'a guère plu
Hou ben, cela risque de pas s'arranger avec le C++ d'aujourd'hui.
Le livre initial de Bjarne Stroustrup présentait (dans mon souvenir) essentiellement C avec classe . On trouvait a l'époque des pré-compilateurs C++, qui transcrivait en C les programmes écrits en C++.
Aujourd'hui parler d'un lien entre C et C++, c'est le bûcher assuré ( rien que d'utiliser un pointeur et on te regarde de travers)
Il faut le reconnaître : l'expertise en C peut (bien que, avec une personne de ta qualité cela semble inconcevable) être un frein à l'acquisition de C++.
Par contre, le bénéfice d'une telle conversion en vaut largement, LARGEMENT ... la peine ( quand cela est possible, CVSD) .
"Antoine Leca" <root@localhost.invalid> a écrit dans le message de
news:d3la6q$b4j$1@shakotay.alphanet.ch...
Je ne connais pour ainsi dire rien sur C++, en dehors d'un bouquin de
Stroustrup que j'ai lu il y a 20 ans et qui ne m'a guère plu
Hou ben, cela risque de pas s'arranger avec le C++ d'aujourd'hui.
Le livre initial de Bjarne Stroustrup présentait (dans mon souvenir)
essentiellement C avec classe .
On trouvait a l'époque des pré-compilateurs C++, qui transcrivait en C les
programmes écrits en C++.
Aujourd'hui parler d'un lien entre C et C++, c'est le bûcher assuré ( rien
que d'utiliser un pointeur et on te regarde de travers)
Il faut le reconnaître : l'expertise en C peut (bien que, avec une personne
de ta qualité cela semble inconcevable) être un frein à l'acquisition de
C++.
Par contre, le bénéfice d'une telle conversion en vaut largement, LARGEMENT
... la peine ( quand cela est possible, CVSD) .
"Antoine Leca" a écrit dans le message de news:d3la6q$b4j$
Je ne connais pour ainsi dire rien sur C++, en dehors d'un bouquin de Stroustrup que j'ai lu il y a 20 ans et qui ne m'a guère plu
Hou ben, cela risque de pas s'arranger avec le C++ d'aujourd'hui.
Le livre initial de Bjarne Stroustrup présentait (dans mon souvenir) essentiellement C avec classe . On trouvait a l'époque des pré-compilateurs C++, qui transcrivait en C les programmes écrits en C++.
Aujourd'hui parler d'un lien entre C et C++, c'est le bûcher assuré ( rien que d'utiliser un pointeur et on te regarde de travers)
Il faut le reconnaître : l'expertise en C peut (bien que, avec une personne de ta qualité cela semble inconcevable) être un frein à l'acquisition de C++.
Par contre, le bénéfice d'une telle conversion en vaut largement, LARGEMENT ... la peine ( quand cela est possible, CVSD) .
Marc Boyer
K. Ahausse wrote:
"Antoine Leca" a écrit dans le message de news:d3la6q$b4j$
Je ne connais pour ainsi dire rien sur C++, en dehors d'un bouquin de Stroustrup que j'ai lu il y a 20 ans et qui ne m'a guère plu
Hou ben, cela risque de pas s'arranger avec le C++ d'aujourd'hui.
Pourtant, les livres publiés depuis sont bien meilleurs je pense.
Aujourd'hui parler d'un lien entre C et C++, c'est le bûcher assuré ( rien que d'utiliser un pointeur et on te regarde de travers)
Il y a des extrémistes partout: certain se proposent bien de me bruler parceque je fais des typedef sur des pointeurs en C. Disons qu'on se fait vite incendier si on ne voit pas les différences entre C et C++, si on imagine programmer en C/C++ sorte de vague continuum.
Il faut le reconnaître : l'expertise en C peut (bien que, avec une personne de ta qualité cela semble inconcevable) être un frein à l'acquisition de C++.
Je dirais que le bidouillage C est un frein à l'acquisition de C++, mais que la rigueur liée à l'expertise ne peut elle être qu'un plus, si elle s'associe à l'idée qu'on apprend un nouveau langage, avec des paradigmes différents, et non pas une surcouche parfois utile.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
K. Ahausse wrote:
"Antoine Leca" <root@localhost.invalid> a écrit dans le message de
news:d3la6q$b4j$1@shakotay.alphanet.ch...
Je ne connais pour ainsi dire rien sur C++, en dehors d'un bouquin de
Stroustrup que j'ai lu il y a 20 ans et qui ne m'a guère plu
Hou ben, cela risque de pas s'arranger avec le C++ d'aujourd'hui.
Pourtant, les livres publiés depuis sont bien meilleurs je pense.
Aujourd'hui parler d'un lien entre C et C++, c'est le bûcher assuré ( rien
que d'utiliser un pointeur et on te regarde de travers)
Il y a des extrémistes partout: certain se proposent bien de
me bruler parceque je fais des typedef sur des pointeurs en C.
Disons qu'on se fait vite incendier si on ne voit pas les
différences entre C et C++, si on imagine programmer en C/C++
sorte de vague continuum.
Il faut le reconnaître : l'expertise en C peut (bien que, avec une personne
de ta qualité cela semble inconcevable) être un frein à l'acquisition de
C++.
Je dirais que le bidouillage C est un frein à l'acquisition
de C++, mais que la rigueur liée à l'expertise ne peut elle être
qu'un plus, si elle s'associe à l'idée qu'on apprend un nouveau
langage, avec des paradigmes différents, et non pas une surcouche
parfois utile.
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
"Antoine Leca" a écrit dans le message de news:d3la6q$b4j$
Je ne connais pour ainsi dire rien sur C++, en dehors d'un bouquin de Stroustrup que j'ai lu il y a 20 ans et qui ne m'a guère plu
Hou ben, cela risque de pas s'arranger avec le C++ d'aujourd'hui.
Pourtant, les livres publiés depuis sont bien meilleurs je pense.
Aujourd'hui parler d'un lien entre C et C++, c'est le bûcher assuré ( rien que d'utiliser un pointeur et on te regarde de travers)
Il y a des extrémistes partout: certain se proposent bien de me bruler parceque je fais des typedef sur des pointeurs en C. Disons qu'on se fait vite incendier si on ne voit pas les différences entre C et C++, si on imagine programmer en C/C++ sorte de vague continuum.
Il faut le reconnaître : l'expertise en C peut (bien que, avec une personne de ta qualité cela semble inconcevable) être un frein à l'acquisition de C++.
Je dirais que le bidouillage C est un frein à l'acquisition de C++, mais que la rigueur liée à l'expertise ne peut elle être qu'un plus, si elle s'associe à l'idée qu'on apprend un nouveau langage, avec des paradigmes différents, et non pas une surcouche parfois utile.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
K. Ahausse
"Marc Boyer" a écrit dans le message de news:d3lu7q$b1n$
Il y a des extrémistes partout: certain se proposent bien de me bruler parceque je fais des typedef sur des pointeurs en C.
Oui, je vois à quoi tu fais allusion. Moi aussi, je préferre les typedef sur les pointeurs, je trouve que c'est un gain en clarté. Mais dans ce domaine l'arbitraire est loi, et chacun peut choisir une autre representation, qu'il lui sied mieux.
Je dirais que le bidouillage C est un frein à l'acquisition de C++, mais que la rigueur liée à l'expertise ne peut elle être qu'un plus, si elle s'associe à l'idée qu'on apprend un nouveau langage, avec des paradigmes différents, et non pas une surcouche parfois utile.
Joliment dit. Je trouve que la formulation colle parfaitement aux faits : cela est aisé, au demeurant, si l'on suit la ligne de conduite que tu indiques.
Mon point de vue rejoint le tien, la difficulté pour celui qui maîtrise déjà parfaitement le C, est de se dire que C et C++ sont deux langages différents, alors que le compilateur C++ acceptera ses sources en écrits C !!! En d'autres mots : il ne peut pas compter sur le compilateur pour lui dire : "ha non, ça c'est du C, et pas du C++". N'ayant pas de sanctions de la part du compilateur, les mécanismes et autres réflexes acquis avec l'ancien langages ne vont pas laisser la place immédiatement.
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news:d3lu7q$b1n$1@news.cict.fr...
Il y a des extrémistes partout: certain se proposent bien de
me bruler parceque je fais des typedef sur des pointeurs en C.
Oui, je vois à quoi tu fais allusion.
Moi aussi, je préferre les typedef sur les pointeurs, je trouve que c'est un
gain en clarté.
Mais dans ce domaine l'arbitraire est loi, et chacun peut choisir une autre
representation, qu'il lui sied mieux.
Je dirais que le bidouillage C est un frein à l'acquisition
de C++, mais que la rigueur liée à l'expertise ne peut elle être
qu'un plus, si elle s'associe à l'idée qu'on apprend un nouveau
langage, avec des paradigmes différents, et non pas une surcouche
parfois utile.
Joliment dit.
Je trouve que la formulation colle parfaitement aux faits : cela est aisé,
au demeurant, si l'on suit la ligne de conduite que tu indiques.
Mon point de vue rejoint le tien, la difficulté pour celui qui maîtrise déjà
parfaitement le C, est de se dire que C et C++ sont deux langages
différents, alors que le compilateur C++ acceptera ses sources en écrits C
!!!
En d'autres mots : il ne peut pas compter sur le compilateur pour lui dire :
"ha non, ça c'est du C, et pas du C++".
N'ayant pas de sanctions de la part du compilateur, les mécanismes et
autres réflexes acquis avec l'ancien langages ne vont pas laisser la place
immédiatement.
"Marc Boyer" a écrit dans le message de news:d3lu7q$b1n$
Il y a des extrémistes partout: certain se proposent bien de me bruler parceque je fais des typedef sur des pointeurs en C.
Oui, je vois à quoi tu fais allusion. Moi aussi, je préferre les typedef sur les pointeurs, je trouve que c'est un gain en clarté. Mais dans ce domaine l'arbitraire est loi, et chacun peut choisir une autre representation, qu'il lui sied mieux.
Je dirais que le bidouillage C est un frein à l'acquisition de C++, mais que la rigueur liée à l'expertise ne peut elle être qu'un plus, si elle s'associe à l'idée qu'on apprend un nouveau langage, avec des paradigmes différents, et non pas une surcouche parfois utile.
Joliment dit. Je trouve que la formulation colle parfaitement aux faits : cela est aisé, au demeurant, si l'on suit la ligne de conduite que tu indiques.
Mon point de vue rejoint le tien, la difficulté pour celui qui maîtrise déjà parfaitement le C, est de se dire que C et C++ sont deux langages différents, alors que le compilateur C++ acceptera ses sources en écrits C !!! En d'autres mots : il ne peut pas compter sur le compilateur pour lui dire : "ha non, ça c'est du C, et pas du C++". N'ayant pas de sanctions de la part du compilateur, les mécanismes et autres réflexes acquis avec l'ancien langages ne vont pas laisser la place immédiatement.
AG
K. Ahausse wrote:
Je trouve que la formulation colle parfaitement aux faits : cela est aisé, au demeurant, si l'on suit la ligne de conduite que tu indiques. De là à dire que c'est aisé, je trouve qu'il y a un pas. Pour moi, le
C++ est sans comparaison plus difficile à apprendre que le C. J'ai pas dit que c'était infaisable.
Mon point de vue rejoint le tien, la difficulté pour celui qui maîtrise déjà parfaitement le C, est de se dire que C et C++ sont deux langages différents, alors que le compilateur C++ acceptera ses sources en écrits C !!! En d'autres mots : il ne peut pas compter sur le compilateur pour lui dire : "ha non, ça c'est du C, et pas du C++". N'ayant pas de sanctions de la part du compilateur, les mécanismes et autres réflexes acquis avec l'ancien langages ne vont pas laisser la place immédiatement.
Dans la hiérarchie des difficultés à apprendre le C++ pour un programmeur C confirmé, je ne trouve pas que cela soit la première difficulté. Il y a d'abord bien comprendre/maitriser tout ce que le C++ apporte par rapport au C. Comprendre c'est une chose, mais maîtriser la STL, les algorithmes, les templates, l'héritage etc..., ça c'est difficile. Et ce n'est pas du à la bonne connaissance du C. C'est juste que c'est nouveau et beaucoup.
AG.
K. Ahausse wrote:
Je trouve que la formulation colle parfaitement aux faits : cela est aisé,
au demeurant, si l'on suit la ligne de conduite que tu indiques.
De là à dire que c'est aisé, je trouve qu'il y a un pas. Pour moi, le
C++ est sans comparaison plus difficile à apprendre que le C. J'ai pas
dit que c'était infaisable.
Mon point de vue rejoint le tien, la difficulté pour celui qui maîtrise déjà
parfaitement le C, est de se dire que C et C++ sont deux langages
différents, alors que le compilateur C++ acceptera ses sources en écrits C
!!!
En d'autres mots : il ne peut pas compter sur le compilateur pour lui dire :
"ha non, ça c'est du C, et pas du C++".
N'ayant pas de sanctions de la part du compilateur, les mécanismes et
autres réflexes acquis avec l'ancien langages ne vont pas laisser la place
immédiatement.
Dans la hiérarchie des difficultés à apprendre le C++ pour un
programmeur C confirmé, je ne trouve pas que cela soit la première
difficulté. Il y a d'abord bien comprendre/maitriser tout ce que le C++
apporte par rapport au C. Comprendre c'est une chose, mais maîtriser la
STL, les algorithmes, les templates, l'héritage etc..., ça c'est
difficile. Et ce n'est pas du à la bonne connaissance du C. C'est juste
que c'est nouveau et beaucoup.
Je trouve que la formulation colle parfaitement aux faits : cela est aisé, au demeurant, si l'on suit la ligne de conduite que tu indiques. De là à dire que c'est aisé, je trouve qu'il y a un pas. Pour moi, le
C++ est sans comparaison plus difficile à apprendre que le C. J'ai pas dit que c'était infaisable.
Mon point de vue rejoint le tien, la difficulté pour celui qui maîtrise déjà parfaitement le C, est de se dire que C et C++ sont deux langages différents, alors que le compilateur C++ acceptera ses sources en écrits C !!! En d'autres mots : il ne peut pas compter sur le compilateur pour lui dire : "ha non, ça c'est du C, et pas du C++". N'ayant pas de sanctions de la part du compilateur, les mécanismes et autres réflexes acquis avec l'ancien langages ne vont pas laisser la place immédiatement.
Dans la hiérarchie des difficultés à apprendre le C++ pour un programmeur C confirmé, je ne trouve pas que cela soit la première difficulté. Il y a d'abord bien comprendre/maitriser tout ce que le C++ apporte par rapport au C. Comprendre c'est une chose, mais maîtriser la STL, les algorithmes, les templates, l'héritage etc..., ça c'est difficile. Et ce n'est pas du à la bonne connaissance du C. C'est juste que c'est nouveau et beaucoup.
AG.
Julien SCORDIA
Jean-Marc Bourguet wrote:
Je ne suis pas sur de tout comprendre. Est-ce un truc du genre typedef struct { #ifdef OPTION_1 int* popt1; #endif double* toujours_la; #ifdef OPTION_2 char* popt2; #endif } Coucou;
Oui, c'est bien ça, en emboitant des constantes préprocesseur ensemble, et avec une trentaine de champs.
Quelle horreur. Quel est le problème que tu essaies de résoudre? J'ai comme l'impression qu'il doit y avoir de meilleures solutions.
J'aime bien qu'on me dise que j'écris des horreurs, au moins cela veut dire que je risque d'apprendre quelque chose ;-) Voici un problème similaire au mien. Supposons que je veuille créer une structure maison, qui puisse s'appliquer dans toutes les régions du monde. Si je suis dans une région de mangrove, j'aurai un champ "nombre_de_pilotis". En revanche, si je suis au Groenland, j'aurai un champ "nombre_de_blocs_de_glace". Si je suis sur Mars, j'aurais un champ "nombre_de_generateurs_doxygene". Si je suis dans la Mangrove, et qu'il y a une femme dans la maison, il va falloir prévoir une vraie salle de bain, voire plusieurs ;-) Sinon, on pourra aller à la rivière. Ma structure maison ressemblera donc à cela:
typedef struct { #if defined(MANGROVE) int nombre_de_pilotis #if defined(FEMME) int nombre_de_salles_de_bain #endif /* if defined(FEMME) */
#elif defined(GROENLAND) /* if defined(MANGROVE) */ int nombre_de_blocs_de_glace
#elif defined(MARS) /* if defined(MANGROVE) */ int nombre_de_generateurs_doxygene
#endif /* if defined(MANGROVE) */ } maison;
Cela permet de définir la structure maison qui va bien suivant les options à la compilation. Quelle autre solution préconises-tu?
Merci d'avance,
Julien -- "Allez, Monsieur, allez, et la foi vous viendra." (D'Alembert).
Jean-Marc Bourguet wrote:
Je ne suis pas sur de tout comprendre. Est-ce un truc du genre
typedef struct {
#ifdef OPTION_1
int* popt1;
#endif
double* toujours_la;
#ifdef OPTION_2
char* popt2;
#endif
} Coucou;
Oui, c'est bien ça, en emboitant des constantes préprocesseur ensemble,
et avec une trentaine de champs.
Quelle horreur. Quel est le problème que tu essaies de
résoudre? J'ai comme l'impression qu'il doit y avoir de
meilleures solutions.
J'aime bien qu'on me dise que j'écris des horreurs, au moins cela veut dire
que je risque d'apprendre quelque chose ;-)
Voici un problème similaire au mien.
Supposons que je veuille créer une structure maison, qui puisse s'appliquer
dans toutes les régions du monde. Si je suis dans une région de mangrove,
j'aurai un champ "nombre_de_pilotis". En revanche, si je suis au Groenland,
j'aurai un champ "nombre_de_blocs_de_glace". Si je suis sur Mars, j'aurais
un champ "nombre_de_generateurs_doxygene".
Si je suis dans la Mangrove, et qu'il y a une femme dans la maison, il va
falloir prévoir une vraie salle de bain, voire plusieurs ;-) Sinon, on
pourra aller à la rivière.
Ma structure maison ressemblera donc à cela:
typedef struct {
#if defined(MANGROVE)
int nombre_de_pilotis
#if defined(FEMME)
int nombre_de_salles_de_bain
#endif /* if defined(FEMME) */
#elif defined(GROENLAND) /* if defined(MANGROVE) */
int nombre_de_blocs_de_glace
#elif defined(MARS) /* if defined(MANGROVE) */
int nombre_de_generateurs_doxygene
#endif /* if defined(MANGROVE) */
} maison;
Cela permet de définir la structure maison qui va bien suivant les options à
la compilation. Quelle autre solution préconises-tu?
Merci d'avance,
Julien
--
"Allez, Monsieur, allez, et la foi vous viendra." (D'Alembert).
Je ne suis pas sur de tout comprendre. Est-ce un truc du genre typedef struct { #ifdef OPTION_1 int* popt1; #endif double* toujours_la; #ifdef OPTION_2 char* popt2; #endif } Coucou;
Oui, c'est bien ça, en emboitant des constantes préprocesseur ensemble, et avec une trentaine de champs.
Quelle horreur. Quel est le problème que tu essaies de résoudre? J'ai comme l'impression qu'il doit y avoir de meilleures solutions.
J'aime bien qu'on me dise que j'écris des horreurs, au moins cela veut dire que je risque d'apprendre quelque chose ;-) Voici un problème similaire au mien. Supposons que je veuille créer une structure maison, qui puisse s'appliquer dans toutes les régions du monde. Si je suis dans une région de mangrove, j'aurai un champ "nombre_de_pilotis". En revanche, si je suis au Groenland, j'aurai un champ "nombre_de_blocs_de_glace". Si je suis sur Mars, j'aurais un champ "nombre_de_generateurs_doxygene". Si je suis dans la Mangrove, et qu'il y a une femme dans la maison, il va falloir prévoir une vraie salle de bain, voire plusieurs ;-) Sinon, on pourra aller à la rivière. Ma structure maison ressemblera donc à cela:
typedef struct { #if defined(MANGROVE) int nombre_de_pilotis #if defined(FEMME) int nombre_de_salles_de_bain #endif /* if defined(FEMME) */
#elif defined(GROENLAND) /* if defined(MANGROVE) */ int nombre_de_blocs_de_glace
#elif defined(MARS) /* if defined(MANGROVE) */ int nombre_de_generateurs_doxygene
#endif /* if defined(MANGROVE) */ } maison;
Cela permet de définir la structure maison qui va bien suivant les options à la compilation. Quelle autre solution préconises-tu?
Merci d'avance,
Julien -- "Allez, Monsieur, allez, et la foi vous viendra." (D'Alembert).
Harpo
Julien SCORDIA wrote:
typedef struct { #if defined(MANGROVE) int nombre_de_pilotis #if defined(FEMME) int nombre_de_salles_de_bain #endif /* if defined(FEMME) */
#elif defined(GROENLAND) /* if defined(MANGROVE) */ int nombre_de_blocs_de_glace
#elif defined(MARS) /* if defined(MANGROVE) */ int nombre_de_generateurs_doxygene
#endif /* if defined(MANGROVE) */ } maison;
Cela permet de définir la structure maison qui va bien suivant les options à la compilation. Quelle autre solution préconises-tu?
On peut envisager un bon nombre de solutions : Une structure contenant tout ce qui est possible bien que certaines choses soient incompatibles ou une union entre les différentes structures possibles ou plusieurs programmes ...
Julien SCORDIA wrote:
typedef struct {
#if defined(MANGROVE)
int nombre_de_pilotis
#if defined(FEMME)
int nombre_de_salles_de_bain
#endif /* if defined(FEMME) */
#elif defined(GROENLAND) /* if defined(MANGROVE) */
int nombre_de_blocs_de_glace
#elif defined(MARS) /* if defined(MANGROVE) */
int nombre_de_generateurs_doxygene
#endif /* if defined(MANGROVE) */
} maison;
Cela permet de définir la structure maison qui va bien suivant les
options à la compilation. Quelle autre solution préconises-tu?
On peut envisager un bon nombre de solutions :
Une structure contenant tout ce qui est possible bien que certaines
choses soient incompatibles ou une union entre les différentes
structures possibles ou plusieurs programmes ...
typedef struct { #if defined(MANGROVE) int nombre_de_pilotis #if defined(FEMME) int nombre_de_salles_de_bain #endif /* if defined(FEMME) */
#elif defined(GROENLAND) /* if defined(MANGROVE) */ int nombre_de_blocs_de_glace
#elif defined(MARS) /* if defined(MANGROVE) */ int nombre_de_generateurs_doxygene
#endif /* if defined(MANGROVE) */ } maison;
Cela permet de définir la structure maison qui va bien suivant les options à la compilation. Quelle autre solution préconises-tu?
On peut envisager un bon nombre de solutions : Une structure contenant tout ce qui est possible bien que certaines choses soient incompatibles ou une union entre les différentes structures possibles ou plusieurs programmes ...
Stephane Legras-Decussy
Julien SCORDIA a écrit dans le message : 425ecb9e$0$32038$
Cela permet de définir la structure maison qui va bien suivant les options à
la compilation. Quelle autre solution préconises-tu?
c'est super relou...
ya aucun interet d'avoir un source unique blindé de #ifdef qui doit par miracle compiler partout...
autant faire 5 fichiers sources si tu as 5 cas vraiment differents... sinon faire un source unique qui contient tous les cas de figure (c'est bien plus simple)
tu te prends la tête sur des trucs "gadget" de C qui cachent une grosse mauvaise conception en fait...
Julien SCORDIA <Nojulien_dot_scordia@free_._frspaM> a écrit dans le message
: 425ecb9e$0$32038$626a14ce@news.free.fr...
Cela permet de définir la structure maison qui va bien suivant les options
à
la compilation. Quelle autre solution préconises-tu?
c'est super relou...
ya aucun interet d'avoir un source unique blindé de #ifdef qui
doit par miracle compiler partout...
autant faire 5 fichiers sources si tu as 5 cas vraiment differents...
sinon faire un source unique qui contient tous les cas de figure
(c'est bien plus simple)
tu te prends la tête sur des trucs "gadget" de C qui cachent une grosse
mauvaise
conception en fait...
Julien SCORDIA a écrit dans le message : 425ecb9e$0$32038$
Cela permet de définir la structure maison qui va bien suivant les options à
la compilation. Quelle autre solution préconises-tu?
c'est super relou...
ya aucun interet d'avoir un source unique blindé de #ifdef qui doit par miracle compiler partout...
autant faire 5 fichiers sources si tu as 5 cas vraiment differents... sinon faire un source unique qui contient tous les cas de figure (c'est bien plus simple)
tu te prends la tête sur des trucs "gadget" de C qui cachent une grosse mauvaise conception en fait...
