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 trouve tout ce que tu présentes secondaire (hormis l'héritage). Ce qui me semble plus important, c'est la conception objet avec RAII, constructeur, destructeur, copie. Ensuite, string + les conteneurs.
Tu abondes dans mon sens. Autant de difficultés, à mon sens, par rapport au C.
En même temps, l'approche RAII a changé ma façon de programmer en C, et rend je pense mes codes plus robustes et plus clairs.
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.
In article <425f8ef2$0$22184$626a14ce@news.free.fr>, AG wrote:
Marc Boyer wrote:
Je trouve tout ce que tu présentes secondaire (hormis l'héritage).
Ce qui me semble plus important, c'est la conception objet avec RAII,
constructeur, destructeur, copie.
Ensuite, string + les conteneurs.
Tu abondes dans mon sens. Autant de difficultés, à mon sens, par rapport
au C.
En même temps, l'approche RAII a changé ma façon de programmer
en C, et rend je pense mes codes plus robustes et plus clairs.
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.
Je trouve tout ce que tu présentes secondaire (hormis l'héritage). Ce qui me semble plus important, c'est la conception objet avec RAII, constructeur, destructeur, copie. Ensuite, string + les conteneurs.
Tu abondes dans mon sens. Autant de difficultés, à mon sens, par rapport au C.
En même temps, l'approche RAII a changé ma façon de programmer en C, et rend je pense mes codes plus robustes et plus clairs.
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.
Emmanuel Delahaye
Marc Boyer wrote on 15/04/05 :
In article <425f8ef2$0$22184$, AG wrote:
Marc Boyer wrote:
Je trouve tout ce que tu présentes secondaire (hormis l'héritage). Ce qui me semble plus important, c'est la conception objet avec RAII, constructeur, destructeur, copie. Ensuite, string + les conteneurs.
Tu abondes dans mon sens. Autant de difficultés, à mon sens, par rapport au C.
En même temps, l'approche RAII a changé ma façon de programmer en C, et rend je pense mes codes plus robustes et plus clairs.
Pareil.
http://mapage.noos.fr/emdel/tad.htm
je savais pas que ça s'appelait aussi RAII
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
.sig under repair
Marc Boyer wrote on 15/04/05 :
In article <425f8ef2$0$22184$626a14ce@news.free.fr>, AG wrote:
Marc Boyer wrote:
Je trouve tout ce que tu présentes secondaire (hormis l'héritage).
Ce qui me semble plus important, c'est la conception objet avec RAII,
constructeur, destructeur, copie.
Ensuite, string + les conteneurs.
Tu abondes dans mon sens. Autant de difficultés, à mon sens, par rapport
au C.
En même temps, l'approche RAII a changé ma façon de programmer
en C, et rend je pense mes codes plus robustes et plus clairs.
Pareil.
http://mapage.noos.fr/emdel/tad.htm
je savais pas que ça s'appelait aussi RAII
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
Je trouve tout ce que tu présentes secondaire (hormis l'héritage). Ce qui me semble plus important, c'est la conception objet avec RAII, constructeur, destructeur, copie. Ensuite, string + les conteneurs.
Tu abondes dans mon sens. Autant de difficultés, à mon sens, par rapport au C.
En même temps, l'approche RAII a changé ma façon de programmer en C, et rend je pense mes codes plus robustes et plus clairs.
Pareil.
http://mapage.noos.fr/emdel/tad.htm
je savais pas que ça s'appelait aussi RAII
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
.sig under repair
Michel Billaud
"K. Ahausse" writes:
Si maintenant, tu veux résoudre ton problème en C++, il te faut t'engager sur la voie de l'apprentissage d'un nouveau langage qui présente malgré tout "quelques difficultés", et lutter contre l'envie, lorsque la résistance devient trop forte, de tomber dans la facilité, en résolvant le problème avec ce que l'on maîtrise bien mieux.
La conclusion c'est qu'il faut apprendre des nouveaux langages au moment où on n'en a pas besoin.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Si maintenant, tu veux résoudre ton problème en C++, il te faut t'engager
sur la voie de l'apprentissage d'un nouveau langage qui présente malgré tout
"quelques difficultés", et lutter contre l'envie, lorsque la résistance
devient trop forte, de tomber dans la facilité, en résolvant le problème
avec ce que l'on maîtrise bien mieux.
La conclusion c'est qu'il faut apprendre des nouveaux langages au moment
où on n'en a pas besoin.
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Si maintenant, tu veux résoudre ton problème en C++, il te faut t'engager sur la voie de l'apprentissage d'un nouveau langage qui présente malgré tout "quelques difficultés", et lutter contre l'envie, lorsque la résistance devient trop forte, de tomber dans la facilité, en résolvant le problème avec ce que l'on maîtrise bien mieux.
La conclusion c'est qu'il faut apprendre des nouveaux langages au moment où on n'en a pas besoin.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Jean-Marc Bourguet
"Emmanuel Delahaye" writes:
http://mapage.noos.fr/emdel/tad.htm
je savais pas que ça s'appelait aussi RAII
Non. RAII est un idiome C++ qui dépend de l'existence de destructeurs synchrones (donc les finaliseurs asynchrones de Java, même s'ils étaient certains, ne permettent pas l'équivalent).
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Non. RAII est un idiome C++ qui dépend de l'existence de
destructeurs synchrones (donc les finaliseurs asynchrones de
Java, même s'ils étaient certains, ne permettent pas
l'équivalent).
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Non. RAII est un idiome C++ qui dépend de l'existence de destructeurs synchrones (donc les finaliseurs asynchrones de Java, même s'ils étaient certains, ne permettent pas l'équivalent).
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Richard Delorme
Marc Boyer wrote on 15/04/05 :
In article <425f8ef2$0$22184$, AG wrote:
Marc Boyer wrote:
Je trouve tout ce que tu présentes secondaire (hormis l'héritage). Ce qui me semble plus important, c'est la conception objet avec RAII, constructeur, destructeur, copie. Ensuite, string + les conteneurs.
Tu abondes dans mon sens. Autant de difficultés, à mon sens, par rapport au C.
En même temps, l'approche RAII a changé ma façon de programmer en C, et rend je pense mes codes plus robustes et plus clairs.
Pareil.
http://mapage.noos.fr/emdel/tad.htm
je savais pas que ça s'appelait aussi RAII
Je ne pense pas que RAII (Resource Acquisition Is Initialisation) et ADT (Abstract Data Type) soient synonyme. Le RAII est surtout une technique pour empêcher l'utilisation d'objets non initialisées et d'objets alloués non libérés. Cf l'exemple de Bjarne Stroustrup : http://www.research.att.com/~bs/bs_faq2.html#finally A mon avis on ne peut pas vraiment faire du RAII en C, c'est-à-dire forcer l'initialisation d'un objet et automatiser sa destruction, tout cela devant être explicitement indiqué par le programmeur. Par contre je pense aussi que cela puisse malgré tout influencer la façon de programmer en C.
-- Richard
Marc Boyer wrote on 15/04/05 :
In article <425f8ef2$0$22184$626a14ce@news.free.fr>, AG wrote:
Marc Boyer wrote:
Je trouve tout ce que tu présentes secondaire (hormis l'héritage).
Ce qui me semble plus important, c'est la conception objet avec RAII,
constructeur, destructeur, copie.
Ensuite, string + les conteneurs.
Tu abondes dans mon sens. Autant de difficultés, à mon sens, par
rapport au C.
En même temps, l'approche RAII a changé ma façon de programmer
en C, et rend je pense mes codes plus robustes et plus clairs.
Pareil.
http://mapage.noos.fr/emdel/tad.htm
je savais pas que ça s'appelait aussi RAII
Je ne pense pas que RAII (Resource Acquisition Is Initialisation) et ADT
(Abstract Data Type) soient synonyme. Le RAII est surtout une technique
pour empêcher l'utilisation d'objets non initialisées et d'objets
alloués non libérés. Cf l'exemple de Bjarne Stroustrup :
http://www.research.att.com/~bs/bs_faq2.html#finally
A mon avis on ne peut pas vraiment faire du RAII en C, c'est-à-dire
forcer l'initialisation d'un objet et automatiser sa destruction, tout
cela devant être explicitement indiqué par le programmeur. Par contre je
pense aussi que cela puisse malgré tout influencer la façon de
programmer en C.
Je trouve tout ce que tu présentes secondaire (hormis l'héritage). Ce qui me semble plus important, c'est la conception objet avec RAII, constructeur, destructeur, copie. Ensuite, string + les conteneurs.
Tu abondes dans mon sens. Autant de difficultés, à mon sens, par rapport au C.
En même temps, l'approche RAII a changé ma façon de programmer en C, et rend je pense mes codes plus robustes et plus clairs.
Pareil.
http://mapage.noos.fr/emdel/tad.htm
je savais pas que ça s'appelait aussi RAII
Je ne pense pas que RAII (Resource Acquisition Is Initialisation) et ADT (Abstract Data Type) soient synonyme. Le RAII est surtout une technique pour empêcher l'utilisation d'objets non initialisées et d'objets alloués non libérés. Cf l'exemple de Bjarne Stroustrup : http://www.research.att.com/~bs/bs_faq2.html#finally A mon avis on ne peut pas vraiment faire du RAII en C, c'est-à-dire forcer l'initialisation d'un objet et automatiser sa destruction, tout cela devant être explicitement indiqué par le programmeur. Par contre je pense aussi que cela puisse malgré tout influencer la façon de programmer en C.
-- Richard
Stephane Legras-Decussy
Thomas Labourdette a écrit dans le message :
À part que l'on n'est pas obligé de tout maîtriser pour commencer. On peut
très bien passer du C au C++ en douceur (d'abord les surcharges, les classes simples, ...).
tout à fait d'accord. On peut même se contenter de class new delete...
ensuite peut être la surcharge de fonction... ensuite le reste.... hum....
Thomas Labourdette <thomas.labourdette@9online.fr> a écrit dans le message :
gss3j2-n8i.ln1@news.labourdette.homelinux.com...
À part que l'on n'est pas obligé de tout maîtriser pour commencer. On
peut
très bien passer du C au C++ en douceur (d'abord les surcharges, les
classes simples, ...).
tout à fait d'accord.
On peut même se contenter de class new delete...
ensuite peut être la surcharge de fonction...
ensuite le reste.... hum....
À part que l'on n'est pas obligé de tout maîtriser pour commencer. On peut
très bien passer du C au C++ en douceur (d'abord les surcharges, les classes simples, ...).
tout à fait d'accord. On peut même se contenter de class new delete...
ensuite peut être la surcharge de fonction... ensuite le reste.... hum....
Jean-Marc Bourguet
"Antoine Leca" writes:
Pour résoudre un problème un problème a priori plus facile à résoudre en C++ qu'en C, vaut-il mieux apprendre le bout de C++ qui conviendrait, ou rester sur le C que l'on connaît?
Tout dépend de l'empleur du problème, de la solution que tu utiliserais en C et de la quantité de tels problèmes que tu rencontres (sans parler des critères utilisés pour comparer deux solutions).
Une des choses qui a fait le succès du C++, c'est qu'on pouvait partir de qqch en C et ajouter du C++ petit à petit tout en maintenant le gros du machin en C. On ne va pas profiter autant du C++ que si on reconcevait tout à partir de scratch avec une équipe expérimentée et dans le domaine et en C++ (et encore, de telles reconceptions échouent plus souvent qu'à leur tour), mais d'après mon expérience il y a un gain.
Note que si passer par le C pour apprendre le C++ n'est pas la meilleure chose à faire, connaître le C -- surtout à ton niveau -- permet quand même d'éviter de se poser pas mal de questions lors de l'apprentissage de C++.
-- 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:
Pour résoudre un problème un problème a priori plus facile
à résoudre en C++ qu'en C, vaut-il mieux apprendre le bout
de C++ qui conviendrait, ou rester sur le C que l'on
connaît?
Tout dépend de l'empleur du problème, de la solution que tu
utiliserais en C et de la quantité de tels problèmes que tu
rencontres (sans parler des critères utilisés pour comparer
deux solutions).
Une des choses qui a fait le succès du C++, c'est qu'on
pouvait partir de qqch en C et ajouter du C++ petit à petit
tout en maintenant le gros du machin en C. On ne va pas
profiter autant du C++ que si on reconcevait tout à partir
de scratch avec une équipe expérimentée et dans le domaine
et en C++ (et encore, de telles reconceptions échouent plus
souvent qu'à leur tour), mais d'après mon expérience il y a
un gain.
Note que si passer par le C pour apprendre le C++ n'est pas
la meilleure chose à faire, connaître le C -- surtout à ton
niveau -- permet quand même d'éviter de se poser pas mal de
questions lors de l'apprentissage de C++.
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Pour résoudre un problème un problème a priori plus facile à résoudre en C++ qu'en C, vaut-il mieux apprendre le bout de C++ qui conviendrait, ou rester sur le C que l'on connaît?
Tout dépend de l'empleur du problème, de la solution que tu utiliserais en C et de la quantité de tels problèmes que tu rencontres (sans parler des critères utilisés pour comparer deux solutions).
Une des choses qui a fait le succès du C++, c'est qu'on pouvait partir de qqch en C et ajouter du C++ petit à petit tout en maintenant le gros du machin en C. On ne va pas profiter autant du C++ que si on reconcevait tout à partir de scratch avec une équipe expérimentée et dans le domaine et en C++ (et encore, de telles reconceptions échouent plus souvent qu'à leur tour), mais d'après mon expérience il y a un gain.
Note que si passer par le C pour apprendre le C++ n'est pas la meilleure chose à faire, connaître le C -- surtout à ton niveau -- permet quand même d'éviter de se poser pas mal de questions lors de l'apprentissage de C++.
-- 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
Marc Boyer wrote:
La réponse pratique, c'est: explique ton problème à quelqu'un qui connait C et C++, et en les capacités duquel tu as confiance, et qui a du temps à te consacrer...
Oui. fr.comp.lang.c, par exemple. C'est d'ailleurs ce qu'a fait Julien.
Antoine
Marc Boyer wrote:
La réponse pratique, c'est: explique ton problème à quelqu'un
qui connait C et C++, et en les capacités duquel tu as confiance,
et qui a du temps à te consacrer...
Oui. fr.comp.lang.c, par exemple.
C'est d'ailleurs ce qu'a fait Julien.
La réponse pratique, c'est: explique ton problème à quelqu'un qui connait C et C++, et en les capacités duquel tu as confiance, et qui a du temps à te consacrer...
Oui. fr.comp.lang.c, par exemple. C'est d'ailleurs ce qu'a fait Julien.
Antoine
Marc Boyer
Antoine Leca wrote:
Marc Boyer wrote:
La réponse pratique, c'est: explique ton problème à quelqu'un qui connait C et C++, et en les capacités duquel tu as confiance, et qui a du temps à te consacrer...
Oui. fr.comp.lang.c, par exemple. C'est d'ailleurs ce qu'a fait Julien.
Sauf que 1) j'ai pas toujours bien compris son problème 2) je ne sais pas si le temps que chacun des contributeurs consacre à fclc est suffisant pour attaquer sérieusement un problème complexe de conception et pas un point de détail
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 wrote:
Marc Boyer wrote:
La réponse pratique, c'est: explique ton problème à quelqu'un
qui connait C et C++, et en les capacités duquel tu as confiance,
et qui a du temps à te consacrer...
Oui. fr.comp.lang.c, par exemple.
C'est d'ailleurs ce qu'a fait Julien.
Sauf que
1) j'ai pas toujours bien compris son problème
2) je ne sais pas si le temps que chacun des contributeurs consacre
à fclc est suffisant pour attaquer sérieusement un problème complexe
de conception et pas un point de détail
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.
La réponse pratique, c'est: explique ton problème à quelqu'un qui connait C et C++, et en les capacités duquel tu as confiance, et qui a du temps à te consacrer...
Oui. fr.comp.lang.c, par exemple. C'est d'ailleurs ce qu'a fait Julien.
Sauf que 1) j'ai pas toujours bien compris son problème 2) je ne sais pas si le temps que chacun des contributeurs consacre à fclc est suffisant pour attaquer sérieusement un problème complexe de conception et pas un point de détail
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.
Harpo
Stephane Legras-Decussy wrote:
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...
Ta remarque montre bien les limitations des interventions sur un forum de ce genre. On peut intervenir pour donner des conseils concernant le code jusqu'à un certain niveau mais on ne peut que difficilement intervenir sur ce qui se rattache à la conception d'un projet. Un des problème peut venir du fait que l'on puisse donner une bonne solution à une question technique alors que cette question n'est due qu'à une conception sous-jacente inadaptée qui l'a amenée.
Ici on parle d'un langage et des possibilités qu'il offre, non de conception de projet, c'est une limitation nécessaire mais c'est néanmoins dommage car j'ai cru remarquer qu'il y a des gens ici capables de donner des avis pertinents
Pour en venir à des choses plus concrètes, il serait bon parfois de demander "qu'est-ce que tu veux faire au juste ?", Peut-être que dans -disons- 50% des cas on pourrait dire "tape 'man xtruc' , il te fera la même chose avec un gui en couleurs".
Dans le problème qui nous occupe présentement, nous pouvons donner de bons conseils de programmation mais ceux-ci ne peuvent être véritablement efficaces que s'ils sont employés dans la mesure où il s'agit de problèmes de programmation.
Selon mon avis qui vaut ce qu'il vaut mais guère plus, les #ifdef tout ça peuvent être employées dans certaines conditions en vue d'objectifs précis, ces objectifs ne me semblent pas en rapport avec le design d'une application, en gros c'est pour tester . 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.
Amha, à moins d'écrire un kernel qui doit tourner sur différents processeurs en faisant des choses compliquées, il ne doit pas y avoir de #iddef dans un .c ou alors très peu, ils doivent être mis dans des .h. Plus important que cela, ils ne devraient pas affecter la sémantique d'un programme, sinon le problème se situe en amont de la précompilation, dans la conception. En arriver à mettre des #ifdef partout n'a qu'un intérêt : montrer que le projet doit être revu depuis le début.
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.
Stephane Legras-Decussy wrote:
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...
Ta remarque montre bien les limitations des interventions sur un forum
de ce genre.
On peut intervenir pour donner des conseils concernant le code jusqu'à
un certain niveau mais on ne peut que difficilement intervenir sur ce
qui se rattache à la conception d'un projet.
Un des problème peut venir du fait que l'on puisse donner une bonne
solution à une question technique alors que cette question n'est due
qu'à une conception sous-jacente inadaptée qui l'a amenée.
Ici on parle d'un langage et des possibilités qu'il offre, non de
conception de projet, c'est une limitation nécessaire mais c'est
néanmoins dommage car j'ai cru remarquer qu'il y a des gens ici
capables de donner des avis pertinents
Pour en venir à des choses plus concrètes, il serait bon parfois de
demander "qu'est-ce que tu veux faire au juste ?", Peut-être que dans
-disons- 50% des cas on pourrait dire "tape 'man xtruc' , il te fera la
même chose avec un gui en couleurs".
Dans le problème qui nous occupe présentement, nous pouvons donner de
bons conseils de programmation mais ceux-ci ne peuvent être
véritablement efficaces que s'ils sont employés dans la mesure où il
s'agit de problèmes de programmation.
Selon mon avis qui vaut ce qu'il vaut mais guère plus, les #ifdef tout
ça peuvent être employées dans certaines conditions en vue d'objectifs
précis, ces objectifs ne me semblent pas en rapport avec le design
d'une application, en gros c'est pour tester
. 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.
Amha, à moins d'écrire un kernel qui doit tourner sur différents
processeurs en faisant des choses compliquées, il ne doit pas y avoir
de #iddef dans un .c ou alors très peu, ils doivent être mis dans
des .h.
Plus important que cela, ils ne devraient pas affecter la sémantique
d'un programme, sinon le problème se situe en amont de la
précompilation, dans la conception.
En arriver à mettre des #ifdef partout n'a qu'un intérêt : montrer que
le projet doit être revu depuis le début.
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.
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...
Ta remarque montre bien les limitations des interventions sur un forum de ce genre. On peut intervenir pour donner des conseils concernant le code jusqu'à un certain niveau mais on ne peut que difficilement intervenir sur ce qui se rattache à la conception d'un projet. Un des problème peut venir du fait que l'on puisse donner une bonne solution à une question technique alors que cette question n'est due qu'à une conception sous-jacente inadaptée qui l'a amenée.
Ici on parle d'un langage et des possibilités qu'il offre, non de conception de projet, c'est une limitation nécessaire mais c'est néanmoins dommage car j'ai cru remarquer qu'il y a des gens ici capables de donner des avis pertinents
Pour en venir à des choses plus concrètes, il serait bon parfois de demander "qu'est-ce que tu veux faire au juste ?", Peut-être que dans -disons- 50% des cas on pourrait dire "tape 'man xtruc' , il te fera la même chose avec un gui en couleurs".
Dans le problème qui nous occupe présentement, nous pouvons donner de bons conseils de programmation mais ceux-ci ne peuvent être véritablement efficaces que s'ils sont employés dans la mesure où il s'agit de problèmes de programmation.
Selon mon avis qui vaut ce qu'il vaut mais guère plus, les #ifdef tout ça peuvent être employées dans certaines conditions en vue d'objectifs précis, ces objectifs ne me semblent pas en rapport avec le design d'une application, en gros c'est pour tester . 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.
Amha, à moins d'écrire un kernel qui doit tourner sur différents processeurs en faisant des choses compliquées, il ne doit pas y avoir de #iddef dans un .c ou alors très peu, ils doivent être mis dans des .h. Plus important que cela, ils ne devraient pas affecter la sémantique d'un programme, sinon le problème se situe en amont de la précompilation, dans la conception. En arriver à mettre des #ifdef partout n'a qu'un intérêt : montrer que le projet doit être revu depuis le début.
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.
