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).
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.
À 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, ...). Les templates ne sont à voir que si vraiment tu en a le besoin. Et la STL n'est pas à apprendre par coeur :-) et on peut vivre sans connaître <algorithm>.
Qu'ensuite tu approfondis la question pour connaître les tournures idiomatiques c'est autre chose, mais franchement le C++ on peut s'y mettre très progressivement.
@+ -- Sarah PAFROMAGE (signature aléatoire) Ma femme a pris un bain de boue. Ça lui a fait paraître vingt ans de moins. Pendant deux jours. Puis la boue est tombée...
AG a écrit le Jeudi 14 Avril 2005 19:01 :
K. Ahausse wrote:
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.
À 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, ...). Les templates ne sont à voir que si vraiment tu en a
le besoin. Et la STL n'est pas à apprendre par coeur :-) et on peut vivre
sans connaître <algorithm>.
Qu'ensuite tu approfondis la question pour connaître les tournures
idiomatiques c'est autre chose, mais franchement le C++ on peut s'y mettre
très progressivement.
@+
--
Sarah PAFROMAGE (signature aléatoire)
Ma femme a pris un bain de boue. Ça lui a fait paraître vingt ans de moins.
Pendant deux jours. Puis la boue est tombée...
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.
À 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, ...). Les templates ne sont à voir que si vraiment tu en a le besoin. Et la STL n'est pas à apprendre par coeur :-) et on peut vivre sans connaître <algorithm>.
Qu'ensuite tu approfondis la question pour connaître les tournures idiomatiques c'est autre chose, mais franchement le C++ on peut s'y mettre très progressivement.
@+ -- Sarah PAFROMAGE (signature aléatoire) Ma femme a pris un bain de boue. Ça lui a fait paraître vingt ans de moins. Pendant deux jours. Puis la boue est tombée...
Wallace
Julien SCORDIA écrivait précédemment ces quelques mots... <news:425ecb9e$0$32038$
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. [...] Ma structure maison ressemblera donc à cela: [code] Cela permet de définir la structure maison qui va bien suivant les options à la compilation.
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 ?
-- W. ( Marteau-pilon et mouche sont sur un bateau... )
<< Prière d'enlever vos_fringues pour m'insulter via e-mail. >>
Julien SCORDIA écrivait précédemment ces quelques mots...
<news:425ecb9e$0$32038$626a14ce@news.free.fr>
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. [...]
Ma structure maison ressemblera donc à cela:
[code]
Cela permet de définir la structure maison qui va bien suivant les
options à la compilation.
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 ?
-- W. ( Marteau-pilon et mouche sont sur un bateau... )
<< Prière d'enlever vos_fringues pour m'insulter via e-mail. >>
Julien SCORDIA écrivait précédemment ces quelques mots... <news:425ecb9e$0$32038$
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. [...] Ma structure maison ressemblera donc à cela: [code] Cela permet de définir la structure maison qui va bien suivant les options à la compilation.
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 ?
-- W. ( Marteau-pilon et mouche sont sur un bateau... )
<< Prière d'enlever vos_fringues pour m'insulter via e-mail. >>
Marc Boyer
Julien SCORDIA wrote:
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".
Ca s'appelle du polymorphisme, et mieux vaut utiliser un langage avec un support pour ce genre de chose, ou au moins s'inspirer de ce que font les compilateurs pour gérer la chose.
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.
Julien SCORDIA wrote:
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".
Ca s'appelle du polymorphisme, et mieux vaut utiliser un langage
avec un support pour ce genre de chose, ou au moins s'inspirer de
ce que font les compilateurs pour gérer la chose.
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 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".
Ca s'appelle du polymorphisme, et mieux vaut utiliser un langage avec un support pour ce genre de chose, ou au moins s'inspirer de ce que font les compilateurs pour gérer la chose.
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
Julien SCORDIA wrote:
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. <snip>
Cela permet de définir la structure maison qui va bien suivant les options à la compilation. Quelle autre solution préconises-tu?
Une liste chaînée d'attributs. Une maison devient juste un pointeur vers la liste (ou le premier élement).
Tu vas y perdre la facilité d'écriture des trucs comme
Et le code de manipulation des maisons va être profondemment bouleversé. Mais pour le reste cela devrait devenir beaucoup plus facile à manipuler.
Antoine
Julien SCORDIA wrote:
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.
<snip>
Cela permet de définir la structure maison qui va bien suivant les
options à la compilation. Quelle autre solution préconises-tu?
Une liste chaînée d'attributs. Une maison devient juste un pointeur vers la
liste (ou le premier élement).
Tu vas y perdre la facilité d'écriture des trucs comme
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. <snip>
Cela permet de définir la structure maison qui va bien suivant les options à la compilation. Quelle autre solution préconises-tu?
Une liste chaînée d'attributs. Une maison devient juste un pointeur vers la liste (ou le premier élement).
Tu vas y perdre la facilité d'écriture des trucs comme
Et le code de manipulation des maisons va être profondemment bouleversé. Mais pour le reste cela devrait devenir beaucoup plus facile à manipuler.
Antoine
Marc Boyer
AG wrote:
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.
La question n'est pas là: la question c'est "pour résoudre un problème donné en C et en C++ (avec le même niveau de qualité), est-il plus difficile d'apprendre le bout de C++ ou le bout de C qui convient". Après, savoir si écrire un compilo C ou un compilo C++ est plus difficile est une autre question.
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.
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.
Après, maitriser toute la STL, les templates, je ne suis pas sur que ce soit primordial.
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.
AG wrote:
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.
La question n'est pas là: la question c'est "pour résoudre
un problème donné en C et en C++ (avec le même niveau de
qualité), est-il plus difficile d'apprendre le bout de C++
ou le bout de C qui convient".
Après, savoir si écrire un compilo C ou un compilo C++
est plus difficile est une autre question.
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.
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.
Après, maitriser toute la STL, les templates, je ne suis pas sur
que ce soit primordial.
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 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.
La question n'est pas là: la question c'est "pour résoudre un problème donné en C et en C++ (avec le même niveau de qualité), est-il plus difficile d'apprendre le bout de C++ ou le bout de C qui convient". Après, savoir si écrire un compilo C ou un compilo C++ est plus difficile est une autre question.
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.
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.
Après, maitriser toute la STL, les templates, je ne suis pas sur que ce soit primordial.
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.
Jean-Marc Bourguet
Julien SCORDIA writes:
Cela permet de définir la structure maison qui va bien suivant les options à la compilation. Quelle autre solution préconises-tu?
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.
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
Cela permet de définir la structure maison qui va bien
suivant les options à la compilation. Quelle autre
solution préconises-tu?
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.
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
Cela permet de définir la structure maison qui va bien suivant les options à la compilation. Quelle autre solution préconises-tu?
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.
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
Marc Boyer wrote:
La question n'est pas là: la question c'est "pour résoudre un problème donné en C et en C++ (avec le même niveau de qualité), est-il plus difficile d'apprendre le bout de C++ ou le bout de C qui convient".
Comme c'est moi qui ai formulé la question :^), je me permets de la repréciser:
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?
(Et question subsidiaire, comment le faire. Je sais, celle-là est HS, c'est une question pour fclc++. Tandis que la précédente peut être répondue ici.)
Antoine
Marc Boyer wrote:
La question n'est pas là: la question c'est "pour résoudre
un problème donné en C et en C++ (avec le même niveau de
qualité), est-il plus difficile d'apprendre le bout de C++
ou le bout de C qui convient".
Comme c'est moi qui ai formulé la question :^), je me permets de la
repréciser:
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?
(Et question subsidiaire, comment le faire. Je sais, celle-là est HS, c'est
une question pour fclc++. Tandis que la précédente peut être répondue ici.)
La question n'est pas là: la question c'est "pour résoudre un problème donné en C et en C++ (avec le même niveau de qualité), est-il plus difficile d'apprendre le bout de C++ ou le bout de C qui convient".
Comme c'est moi qui ai formulé la question :^), je me permets de la repréciser:
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?
(Et question subsidiaire, comment le faire. Je sais, celle-là est HS, c'est une question pour fclc++. Tandis que la précédente peut être répondue ici.)
Antoine
Marc Boyer
Antoine Leca wrote:
Marc Boyer wrote:
La question n'est pas là: la question c'est "pour résoudre un problème donné en C et en C++ (avec le même niveau de qualité), est-il plus difficile d'apprendre le bout de C++ ou le bout de C qui convient".
Comme c'est moi qui ai formulé la question :^), je me permets de la repréciser:
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?
Pour un besoin ponctuel, je serais tenté de rester en C: j'ai moi même écrit en bourne shell+awk des scripts dont je sais très bien qu'ils seraient plus facile à écrire en perl.
La réponse théorique, c'est qu'il faut comparer le cout de l'investissement au cout du gain, cotienté par la ré-utilisation des connaissances acquises.
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...
J'ajoute que de nombreuses fonctionnalités du C++ sont émulables à la main en C, certaines sont faciles mais fastidieuses, d'autres difficiles mais agréables à manipuler, etc.
(Et question subsidiaire, comment le faire. Je sais, celle-là est HS, c'est une question pour fclc++. Tandis que la précédente peut être répondue ici.)
J'ai fait le cross-post, chacun fera le fu2 qui lui convient, et j'ai changé le titre.
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 question n'est pas là: la question c'est "pour résoudre
un problème donné en C et en C++ (avec le même niveau de
qualité), est-il plus difficile d'apprendre le bout de C++
ou le bout de C qui convient".
Comme c'est moi qui ai formulé la question :^), je me permets de la
repréciser:
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?
Pour un besoin ponctuel, je serais tenté de rester en C: j'ai moi
même écrit en bourne shell+awk des scripts dont je sais très bien
qu'ils seraient plus facile à écrire en perl.
La réponse théorique, c'est qu'il faut comparer le cout de
l'investissement au cout du gain, cotienté par la ré-utilisation
des connaissances acquises.
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...
J'ajoute que de nombreuses fonctionnalités du C++ sont
émulables à la main en C, certaines sont faciles mais
fastidieuses, d'autres difficiles mais agréables à manipuler,
etc.
(Et question subsidiaire, comment le faire. Je sais, celle-là est HS, c'est
une question pour fclc++. Tandis que la précédente peut être répondue ici.)
J'ai fait le cross-post, chacun fera le fu2 qui lui convient,
et j'ai changé le titre.
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 question n'est pas là: la question c'est "pour résoudre un problème donné en C et en C++ (avec le même niveau de qualité), est-il plus difficile d'apprendre le bout de C++ ou le bout de C qui convient".
Comme c'est moi qui ai formulé la question :^), je me permets de la repréciser:
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?
Pour un besoin ponctuel, je serais tenté de rester en C: j'ai moi même écrit en bourne shell+awk des scripts dont je sais très bien qu'ils seraient plus facile à écrire en perl.
La réponse théorique, c'est qu'il faut comparer le cout de l'investissement au cout du gain, cotienté par la ré-utilisation des connaissances acquises.
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...
J'ajoute que de nombreuses fonctionnalités du C++ sont émulables à la main en C, certaines sont faciles mais fastidieuses, d'autres difficiles mais agréables à manipuler, etc.
(Et question subsidiaire, comment le faire. Je sais, celle-là est HS, c'est une question pour fclc++. Tandis que la précédente peut être répondue ici.)
J'ai fait le cross-post, chacun fera le fu2 qui lui convient, et j'ai changé le titre.
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
"Antoine Leca" a écrit dans le message de news:d3o18h$cm0$
Marc Boyer wrote:
La question n'est pas là: la question c'est "pour résoudre un problème donné en C et en C++ (avec le même niveau de qualité), est-il plus difficile d'apprendre le bout de C++ ou le bout de C qui convient".
Comme c'est moi qui ai formulé la question :^), je me permets de la repréciser:
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?
C'est exactement la difficulté que je voulais pointer. Lorsque l'on connaît le C il est quasi intuitif de rédiger un programme. 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.
A ta question, amha, je répondrais, oui, il vaut mieux, et le plus tôt possible, tenter le C++, même si cela ne fonctionne pas du premier coup (parce que la difficulté est réelle), ce qui sera acquis, aussi minime fut-ce-t-il, sera toujours ça de fait.
"Antoine Leca" <root@localhost.invalid> a écrit dans le message de
news:d3o18h$cm0$1@shakotay.alphanet.ch...
Marc Boyer wrote:
La question n'est pas là: la question c'est "pour résoudre
un problème donné en C et en C++ (avec le même niveau de
qualité), est-il plus difficile d'apprendre le bout de C++
ou le bout de C qui convient".
Comme c'est moi qui ai formulé la question :^), je me permets de la
repréciser:
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?
C'est exactement la difficulté que je voulais pointer. Lorsque l'on connaît
le C il est quasi intuitif de rédiger un programme.
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.
A ta question, amha, je répondrais, oui, il vaut mieux, et le plus tôt
possible, tenter le C++, même si cela ne fonctionne pas du premier coup
(parce que la difficulté est réelle), ce qui sera acquis, aussi minime
fut-ce-t-il, sera toujours ça de fait.
"Antoine Leca" a écrit dans le message de news:d3o18h$cm0$
Marc Boyer wrote:
La question n'est pas là: la question c'est "pour résoudre un problème donné en C et en C++ (avec le même niveau de qualité), est-il plus difficile d'apprendre le bout de C++ ou le bout de C qui convient".
Comme c'est moi qui ai formulé la question :^), je me permets de la repréciser:
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?
C'est exactement la difficulté que je voulais pointer. Lorsque l'on connaît le C il est quasi intuitif de rédiger un programme. 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.
A ta question, amha, je répondrais, oui, il vaut mieux, et le plus tôt possible, tenter le C++, même si cela ne fonctionne pas du premier coup (parce que la difficulté est réelle), ce qui sera acquis, aussi minime fut-ce-t-il, sera toujours ça de fait.
AG
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.
AG.
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.
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.
