Voilà... je suis super débutant... Je poste ici mon premier programme
fait maison....
Je voudrait avoir votre avis..
J'utilise Xcode sur un macintosh sous 10.4.4, mais cela n'a pas beaucoup
d'importance...
#include <stdio.h>
#include <string.h>
int main (int argc, const char * argv[]) {
//on défini les variables
char Nom[200];
float quantite; // la variable quantité
float prix; // la variable prix
float total; // la variable total
float tauxtva; // le taux de tva
float soustotal; // le sous tatal sans la tva
float tva; // le montant de la tva
printf("Entrez votre nom : ");
scanf("%s", Nom);
printf("\n");
printf("Taux de tva ? : "); // on demande le taux de tva
scanf("%f",&tauxtva);
printf("\n");
printf("Quantite de l'article a facturer ? : "); // on demande
la quantité
scanf("%f",&quantite);
printf("\n");
printf("Le prix de l'article ? : "); // on demande le prix
scanf("%f",&prix);
printf("\n");
Pour l'autre, je suis d'accord et c'est une des raisons pour lesquelles si j'avais à enseigner la programmation j'envisagerai un langage interprété.
Ca se discute...
-- http://harpo.free.fr/
Harpo
Jean-Marc Bourguet wrote:
Je crois qu'on a déjà eu ce débat. Je suis quelqu'un qui pense que ce qui se passe réellement lors de l'exécution d'un programme, c'est des déplacement d'électrons.
Tu es bassement matérialiste, pour d'autres il s'agit de conceptions qui s'avèrent foireuses.
Toute autre vision est une abstraction (celle là aussi, mais une description quantique l'est encore plus). Celle de l'interface hardware/software ne me semble pas particulièrement plus pertinente qu'une autre. Il me semble intéressant de pouvoir réfléchir à des niveaux inférieurs comme supérieurs.
De toute manière, il s'git de représentations, l'existence d'une réalité qui serait sous-jacente à ces représentations ne peut être qu'imputée.
-- http://harpo.free.fr/
Jean-Marc Bourguet wrote:
Je crois qu'on a déjà eu ce débat. Je suis quelqu'un qui
pense que ce qui se passe réellement lors de l'exécution
d'un programme, c'est des déplacement d'électrons.
Tu es bassement matérialiste, pour d'autres il s'agit de conceptions qui
s'avèrent foireuses.
Toute
autre vision est une abstraction (celle là aussi, mais une
description quantique l'est encore plus). Celle de
l'interface hardware/software ne me semble pas
particulièrement plus pertinente qu'une autre. Il me semble
intéressant de pouvoir réfléchir à des niveaux inférieurs
comme supérieurs.
De toute manière, il s'git de représentations, l'existence d'une réalité
qui serait sous-jacente à ces représentations ne peut être qu'imputée.
Je crois qu'on a déjà eu ce débat. Je suis quelqu'un qui pense que ce qui se passe réellement lors de l'exécution d'un programme, c'est des déplacement d'électrons.
Tu es bassement matérialiste, pour d'autres il s'agit de conceptions qui s'avèrent foireuses.
Toute autre vision est une abstraction (celle là aussi, mais une description quantique l'est encore plus). Celle de l'interface hardware/software ne me semble pas particulièrement plus pertinente qu'une autre. Il me semble intéressant de pouvoir réfléchir à des niveaux inférieurs comme supérieurs.
De toute manière, il s'git de représentations, l'existence d'une réalité qui serait sous-jacente à ces représentations ne peut être qu'imputée.
-- http://harpo.free.fr/
candide
Harpo wrote in news:43e651dc$0$23264$8fcfb975 @news.wanadoo.fr:
Pierre Maurette wrote:
Kerchomsky, célèbre linguiste natif de Ploudalmézeau,
J'ai très bien connu sa mère.
:))
Harpo <trashcan@hotmail.com> wrote in news:43e651dc$0$23264$8fcfb975
@news.wanadoo.fr:
Pierre Maurette wrote:
Kerchomsky, célèbre linguiste natif de Ploudalmézeau,
"Pierre Maurette" a écrit dans le message de news:
Vous êtes monochromatique, Candide.
cohérent ou non ? ça change tout...
Marc Boyer
Le 05-02-2006, candide a écrit :
Marc Boyer wrote in news::
Je pense que c'est une vision complètement caricaturale.
En effet. J'avais même la prétention qu'elle contienne une dose d'humour.
J'avais compris mais je pense que ce n'était pas que de l'humour.
Non, c'est aussi une distinction de mode de pensée: math et info ont des problèmatiques distinctes en général, même s'il existe une intersection non nulle.
Mais n'avais-tu pas commencé avec "Et pourtant, ce ne doit pas tre très dur, la capacité première étant desavoir faire un tri topologique."
Il y avait un fond de vérité dans mon propos.
Ça fait un bout de temps que je me désole de la médiocrité des bouquins de C, et que je me demande si plutôt que de me lamenter, je ne pourrais pas en faire un. Mais au final, je ne m'y résoud pas. "La critique est facile..."
Sinon, en passant je suis en train de refaire mon support de cours de C: si tu en veux un exemplaire, contacte moi par email.
Volontiers et c'est fort aimable de penser à moi.
Et bien, en enlevant yahoo et invalid de mon email Usenet, tu obtiendras mon véritable email.
Marc Boyer -- Entre le fort et le faible, c'est la liberte qui opprime et le droit qui libere. Henri Lacordaire, Dominicain
Le 05-02-2006, candide <candide@domain.invalid> a écrit :
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in
news:slrnducmdq.4fp.Marc.Boyer@localhost.localdomain:
Je pense que c'est une vision complètement caricaturale.
En effet. J'avais même la prétention qu'elle contienne une dose
d'humour.
J'avais compris mais je pense que ce n'était pas que de l'humour.
Non, c'est aussi une distinction de mode de pensée: math et
info ont des problèmatiques distinctes en général, même s'il
existe une intersection non nulle.
Mais n'avais-tu pas commencé avec "Et pourtant, ce ne doit pas tre
très
dur, la capacité première étant desavoir faire un tri topologique."
Il y avait un fond de vérité dans mon propos.
Ça fait un bout de temps que je me désole de la médiocrité des
bouquins de C, et que je me demande si plutôt que de me lamenter,
je ne pourrais pas en faire un. Mais au final, je ne m'y résoud
pas. "La critique est facile..."
Sinon, en passant je suis en train de refaire mon support
de cours de C: si tu en veux un exemplaire, contacte moi par
email.
Volontiers et c'est fort aimable de penser à moi.
Et bien, en enlevant yahoo et invalid de mon email Usenet,
tu obtiendras mon véritable email.
Marc Boyer
--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain
Je pense que c'est une vision complètement caricaturale.
En effet. J'avais même la prétention qu'elle contienne une dose d'humour.
J'avais compris mais je pense que ce n'était pas que de l'humour.
Non, c'est aussi une distinction de mode de pensée: math et info ont des problèmatiques distinctes en général, même s'il existe une intersection non nulle.
Mais n'avais-tu pas commencé avec "Et pourtant, ce ne doit pas tre très dur, la capacité première étant desavoir faire un tri topologique."
Il y avait un fond de vérité dans mon propos.
Ça fait un bout de temps que je me désole de la médiocrité des bouquins de C, et que je me demande si plutôt que de me lamenter, je ne pourrais pas en faire un. Mais au final, je ne m'y résoud pas. "La critique est facile..."
Sinon, en passant je suis en train de refaire mon support de cours de C: si tu en veux un exemplaire, contacte moi par email.
Volontiers et c'est fort aimable de penser à moi.
Et bien, en enlevant yahoo et invalid de mon email Usenet, tu obtiendras mon véritable email.
Marc Boyer -- Entre le fort et le faible, c'est la liberte qui opprime et le droit qui libere. Henri Lacordaire, Dominicain
candide
Gabriel Dos Reis wrote in news::
candide writes:
| P'tain, je suis un alien ou quoi,
vu de là où j'écris ce message, oui.
C'est réciproque.
Mon dieu. Tu me donne encore plus de raisons de croire que le debugger est cancérigène. :-(
Hummm, t'es une cervelle qui a le mauvais oeil, je vais faire exorciser mon debugger
C.
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in
news:m3bqxlag6b.fsf@uniton.integrable-solutions.net:
candide <candide@domain.invalid> writes:
| P'tain, je suis un alien ou quoi,
vu de là où j'écris ce message, oui.
C'est réciproque.
Mon dieu.
Tu me donne encore plus de raisons de croire que le debugger est
cancérigène. :-(
Hummm, t'es une cervelle qui a le mauvais oeil, je vais faire exorciser mon
debugger
Mon dieu. Tu me donne encore plus de raisons de croire que le debugger est cancérigène. :-(
Hummm, t'es une cervelle qui a le mauvais oeil, je vais faire exorciser mon debugger
C.
Laurent Deniau
Jean-Marc Bourguet wrote:
"Laurent Deniau" writes:
C'est la que l'approche est differente. Je considere le code correcte par defaut (parce que debugge et teste ;-) )
Optimiste... Mais je crois surtout que nous travaillons dans des contextes très différents et que je maîtrise beaucoup moins ce dont je ne m'occupe pas dans le programme que toi.
C'est fort possible. Je ne suis pas vraiment dans une logique industrielle, mais plutot R&D.
mais je ne fais pas confiance aux entrees.
Je n'utilise pas des assertions pour vérifier les entrées de l'utilisateur. Ces vérifications doivent être là quoi qu'il passe dans la tête d'un CM, de celui qui reprendra le code, ou des défauts considérés comme adéquats par le fournisseur du compilateur qu'on utilisera dans le futur. Les assertions sont pour moi des commentaires dont la validité est vérifiée à l'exécution, elles ne font pas partie de ce que le programme est sensé faire. Vérifier les entrées de l'utilisateur, le programme doit le faire.
Je ne parle pas seulement de l'utilisateur. Par exemple si on devait reecrire strlen en supposant que le C ait les exceptions:
Est ce que tu considere que le assert devrait etre semantiquement equivalent a un test+log+exit, un test+errno+return, un assert-debug ou un assert-exception.
Je trouve parfois ce choix difficile et donc pour ce qui est de mon code, je choisi presque toujours assert-exception qui a le merite d'etre simple, compact, jamais desactive (dans mon cas) et qui dit a l'utilisateur (du code, pas du programme) "c'est vous qui voyez" ;-).
Pour ce qui est de verifier les donnees utilisateur-DB-fichier au niveau du programme j'ai un tout autre mecanisme que l'on appelle ici les alarmes. Rien a voir avec les tests sur les arguments.
L'etat est donc connu en cas d'echec puisque non affecte par les entrees invalides. Un cas typique, c'est realloc.
Le plus souvent, la cause de l'echec est un defaut d'analyse: l'etat est valide mais le programme n'est pas prevu pour traiter ce cas la. Mais il n'est pas rare qu'on se retrouve avec un etat invalide, soit que l'hypothese a ete tenue pour vraie avant, soit qu'il y a une erreur dans le programme.
Ni l'un, ni l'autre qui normalement auraient du etre revele par les tests. L'utilisateur n'a pas suivi les specs. Les deux premiers cas sont traites pendant les tests et la je suis d'accord qu'a part faire du log et quitter il n'y a pas grand chose d'autre a faire. Ceci dit, meme si c'est pour quitter, les exceptions permettent de detruire les objets existants et
Quel est l'intérêt?
de liberer proprement les ressources.
Libérer les ressources qui ne le sont pas par effet de bord d'une fin de programme, je le fais aussi. Elles sont rares dans les OS que j'utilise.
C'est vrai que l'on peut directement se poser la question de l'interet des exceptions dans ce cas. Parce que 19/20 on quitte plus ou moins brutalement. La question soujacente, c'est quelle classe de problemes reveles au niveau N peuvent etre resolus au niveau N-P (P<N)? On a parfois l'impression (c'est parfois mon cas) que les exceptions servent surtout a se donner bonne conscience a ceux qui ecrivent des bibliotheques mais que ceux qui les attrapes ne savent pas trop quoi en faire. Un error_handler est souvent plus simple et tout aussi efficace.
Cas mis a part de l'utilisation des exceptions comme un mecanisme simple de retour non-local pour faire des tentatives.
Je n'ai que trois cas ou je fait un abort en OOC et ce sont les memes que C++. Il doit y avoir une bonne raison ;-)
Ce sont?
ooc_abort("exception %s thrown (%s:%d) during stack unwinding",name,file,line..); ooc_abort("exception %s thrown (%s:%d) but not caught",name,file,line); ooc_abort("pure virtual method call with an instance of class %s as its first parameter (self?)",name); ooc_abort("pure virtual (static?) method call"); ooc_abort("inhibited method call with an instance of class %s as its first parameter (self?)",name); ooc_abort("inhibited (static?) method call");
Les 4 derniers sont les memes, appel d'une methode virtuelle pure.
C'est la que l'approche est differente. Je considere le
code correcte par defaut (parce que debugge et teste ;-) )
Optimiste... Mais je crois surtout que nous travaillons dans
des contextes très différents et que je maîtrise beaucoup
moins ce dont je ne m'occupe pas dans le programme que toi.
C'est fort possible. Je ne suis pas vraiment dans une logique
industrielle, mais plutot R&D.
mais je ne fais pas confiance aux entrees.
Je n'utilise pas des assertions pour vérifier les entrées de
l'utilisateur. Ces vérifications doivent être là quoi qu'il
passe dans la tête d'un CM, de celui qui reprendra le code,
ou des défauts considérés comme adéquats par le fournisseur
du compilateur qu'on utilisera dans le futur. Les
assertions sont pour moi des commentaires dont la validité
est vérifiée à l'exécution, elles ne font pas partie de ce
que le programme est sensé faire. Vérifier les entrées de
l'utilisateur, le programme doit le faire.
Je ne parle pas seulement de l'utilisateur. Par exemple si on devait
reecrire strlen en supposant que le C ait les exceptions:
Est ce que tu considere que le assert devrait etre semantiquement
equivalent a un test+log+exit, un test+errno+return, un assert-debug ou
un assert-exception.
Je trouve parfois ce choix difficile et donc pour ce qui est de mon
code, je choisi presque toujours assert-exception qui a le merite d'etre
simple, compact, jamais desactive (dans mon cas) et qui dit a
l'utilisateur (du code, pas du programme) "c'est vous qui voyez" ;-).
Pour ce qui est de verifier les donnees utilisateur-DB-fichier au niveau
du programme j'ai un tout autre mecanisme que l'on appelle ici les
alarmes. Rien a voir avec les tests sur les arguments.
L'etat est donc connu en cas d'echec puisque non affecte
par les entrees invalides. Un cas typique, c'est realloc.
Le plus souvent, la cause de l'echec est un defaut
d'analyse: l'etat est valide mais le programme n'est pas
prevu pour traiter ce cas la. Mais il n'est pas rare
qu'on se retrouve avec un etat invalide, soit que
l'hypothese a ete tenue pour vraie avant, soit qu'il y a
une erreur dans le programme.
Ni l'un, ni l'autre qui normalement auraient du etre
revele par les tests. L'utilisateur n'a pas suivi les
specs. Les deux premiers cas sont traites pendant les
tests et la je suis d'accord qu'a part faire du log et
quitter il n'y a pas grand chose d'autre a faire. Ceci
dit, meme si c'est pour quitter, les exceptions permettent
de detruire les objets existants et
Quel est l'intérêt?
de liberer proprement les ressources.
Libérer les ressources qui ne le sont pas par effet de bord
d'une fin de programme, je le fais aussi. Elles sont rares
dans les OS que j'utilise.
C'est vrai que l'on peut directement se poser la question de l'interet
des exceptions dans ce cas. Parce que 19/20 on quitte plus ou moins
brutalement. La question soujacente, c'est quelle classe de problemes
reveles au niveau N peuvent etre resolus au niveau N-P (P<N)? On a
parfois l'impression (c'est parfois mon cas) que les exceptions servent
surtout a se donner bonne conscience a ceux qui ecrivent des
bibliotheques mais que ceux qui les attrapes ne savent pas trop quoi en
faire. Un error_handler est souvent plus simple et tout aussi efficace.
Cas mis a part de l'utilisation des exceptions comme un mecanisme simple
de retour non-local pour faire des tentatives.
Je n'ai que trois cas ou je fait un abort en OOC et ce
sont les memes que C++. Il doit y avoir une bonne raison
;-)
Ce sont?
ooc_abort("exception %s thrown (%s:%d) during stack
unwinding",name,file,line..);
ooc_abort("exception %s thrown (%s:%d) but not caught",name,file,line);
ooc_abort("pure virtual method call with an instance of class %s as its
first parameter (self?)",name);
ooc_abort("pure virtual (static?) method call");
ooc_abort("inhibited method call with an instance of class %s as its
first parameter (self?)",name);
ooc_abort("inhibited (static?) method call");
Les 4 derniers sont les memes, appel d'une methode virtuelle pure.
C'est la que l'approche est differente. Je considere le code correcte par defaut (parce que debugge et teste ;-) )
Optimiste... Mais je crois surtout que nous travaillons dans des contextes très différents et que je maîtrise beaucoup moins ce dont je ne m'occupe pas dans le programme que toi.
C'est fort possible. Je ne suis pas vraiment dans une logique industrielle, mais plutot R&D.
mais je ne fais pas confiance aux entrees.
Je n'utilise pas des assertions pour vérifier les entrées de l'utilisateur. Ces vérifications doivent être là quoi qu'il passe dans la tête d'un CM, de celui qui reprendra le code, ou des défauts considérés comme adéquats par le fournisseur du compilateur qu'on utilisera dans le futur. Les assertions sont pour moi des commentaires dont la validité est vérifiée à l'exécution, elles ne font pas partie de ce que le programme est sensé faire. Vérifier les entrées de l'utilisateur, le programme doit le faire.
Je ne parle pas seulement de l'utilisateur. Par exemple si on devait reecrire strlen en supposant que le C ait les exceptions:
Est ce que tu considere que le assert devrait etre semantiquement equivalent a un test+log+exit, un test+errno+return, un assert-debug ou un assert-exception.
Je trouve parfois ce choix difficile et donc pour ce qui est de mon code, je choisi presque toujours assert-exception qui a le merite d'etre simple, compact, jamais desactive (dans mon cas) et qui dit a l'utilisateur (du code, pas du programme) "c'est vous qui voyez" ;-).
Pour ce qui est de verifier les donnees utilisateur-DB-fichier au niveau du programme j'ai un tout autre mecanisme que l'on appelle ici les alarmes. Rien a voir avec les tests sur les arguments.
L'etat est donc connu en cas d'echec puisque non affecte par les entrees invalides. Un cas typique, c'est realloc.
Le plus souvent, la cause de l'echec est un defaut d'analyse: l'etat est valide mais le programme n'est pas prevu pour traiter ce cas la. Mais il n'est pas rare qu'on se retrouve avec un etat invalide, soit que l'hypothese a ete tenue pour vraie avant, soit qu'il y a une erreur dans le programme.
Ni l'un, ni l'autre qui normalement auraient du etre revele par les tests. L'utilisateur n'a pas suivi les specs. Les deux premiers cas sont traites pendant les tests et la je suis d'accord qu'a part faire du log et quitter il n'y a pas grand chose d'autre a faire. Ceci dit, meme si c'est pour quitter, les exceptions permettent de detruire les objets existants et
Quel est l'intérêt?
de liberer proprement les ressources.
Libérer les ressources qui ne le sont pas par effet de bord d'une fin de programme, je le fais aussi. Elles sont rares dans les OS que j'utilise.
C'est vrai que l'on peut directement se poser la question de l'interet des exceptions dans ce cas. Parce que 19/20 on quitte plus ou moins brutalement. La question soujacente, c'est quelle classe de problemes reveles au niveau N peuvent etre resolus au niveau N-P (P<N)? On a parfois l'impression (c'est parfois mon cas) que les exceptions servent surtout a se donner bonne conscience a ceux qui ecrivent des bibliotheques mais que ceux qui les attrapes ne savent pas trop quoi en faire. Un error_handler est souvent plus simple et tout aussi efficace.
Cas mis a part de l'utilisation des exceptions comme un mecanisme simple de retour non-local pour faire des tentatives.
Je n'ai que trois cas ou je fait un abort en OOC et ce sont les memes que C++. Il doit y avoir une bonne raison ;-)
Ce sont?
ooc_abort("exception %s thrown (%s:%d) during stack unwinding",name,file,line..); ooc_abort("exception %s thrown (%s:%d) but not caught",name,file,line); ooc_abort("pure virtual method call with an instance of class %s as its first parameter (self?)",name); ooc_abort("pure virtual (static?) method call"); ooc_abort("inhibited method call with an instance of class %s as its first parameter (self?)",name); ooc_abort("inhibited (static?) method call");
Les 4 derniers sont les memes, appel d'une methode virtuelle pure.
a+, ld.
Laurent Deniau
Jean-Marc Bourguet wrote:
"Laurent Deniau" writes:
OOC supporte seulement l'heritage simple et utilise la delegation de type pour simuler l'heritage multiple. Un objet est structurellement valide (du point de vu OOC) juste apres son *allocation* et avant son initialisation, donc ses parents aussi.
Tu as l'air de dire maintenant que l'objet est en situation neutre pour le destructeur par l'effet de l'allocation.
Non. Il est structurellement complet, mais pas initialise.
J'avais compris de
si le constructeur commence par rendre son objet neutre pour son destructeur
qu'il fallait écrire du code spécifiquement pour ça. Comme
Exact.
il faut que toute la hiérarchie soit dans un état neutre pour pouvoir appeler le destructeur, j'imaginais une construction en deux temps.
Sur ce point, il faut faire une difference fondamentale entre l'heritage simple et l'heritage multiple. Le premier garanti que des que l'objet est alloue et que le pointeur isa (ou vptr) est initialise, l'objet est structurellement complet. Reste au developpeur d'initialiser ses membres.
En revanche l'heritage multiple est plus complique et une maniere "simple" de construire la structure de l'objet est de proceder de facon incrementale au fur et a mesure des appels des constructeurs lors de l'initialisation des membres (d'ou les restrictions qu'impose C++). On pourrait imaginer une initialisation en deux passes separees comme tu le suggeres, mais alors la premiere passe pourrait etre couteuse "pour rien" si l'initialisation echoue. Elle demanderait en plus un code plus complique (et plus lent que la version incrementale) similaire a ce que fait dynamic_cast. Je ne me souviens pas avoir lu la raison historique du choix de C++ dans le D&E mais la philosophie du C++ "on paye seulement le prix de ce qu'on achete" justifie deja ce choix.
OOC supporte seulement l'heritage simple et utilise la delegation de
type pour simuler l'heritage multiple. Un objet est structurellement
valide (du point de vu OOC) juste apres son *allocation* et avant son
initialisation, donc ses parents aussi.
Tu as l'air de dire maintenant que l'objet est en situation
neutre pour le destructeur par l'effet de l'allocation.
Non. Il est structurellement complet, mais pas initialise.
J'avais compris de
si le constructeur commence par rendre son objet neutre pour
son destructeur
qu'il fallait écrire du code spécifiquement pour ça. Comme
Exact.
il faut que toute la hiérarchie soit dans un état neutre
pour pouvoir appeler le destructeur, j'imaginais une
construction en deux temps.
Sur ce point, il faut faire une difference fondamentale entre l'heritage
simple et l'heritage multiple. Le premier garanti que des que l'objet
est alloue et que le pointeur isa (ou vptr) est initialise, l'objet est
structurellement complet. Reste au developpeur d'initialiser ses membres.
En revanche l'heritage multiple est plus complique et une maniere
"simple" de construire la structure de l'objet est de proceder de facon
incrementale au fur et a mesure des appels des constructeurs lors de
l'initialisation des membres (d'ou les restrictions qu'impose C++). On
pourrait imaginer une initialisation en deux passes separees comme tu le
suggeres, mais alors la premiere passe pourrait etre couteuse "pour
rien" si l'initialisation echoue. Elle demanderait en plus un code plus
complique (et plus lent que la version incrementale) similaire a ce que
fait dynamic_cast. Je ne me souviens pas avoir lu la raison historique
du choix de C++ dans le D&E mais la philosophie du C++ "on paye
seulement le prix de ce qu'on achete" justifie deja ce choix.
OOC supporte seulement l'heritage simple et utilise la delegation de type pour simuler l'heritage multiple. Un objet est structurellement valide (du point de vu OOC) juste apres son *allocation* et avant son initialisation, donc ses parents aussi.
Tu as l'air de dire maintenant que l'objet est en situation neutre pour le destructeur par l'effet de l'allocation.
Non. Il est structurellement complet, mais pas initialise.
J'avais compris de
si le constructeur commence par rendre son objet neutre pour son destructeur
qu'il fallait écrire du code spécifiquement pour ça. Comme
Exact.
il faut que toute la hiérarchie soit dans un état neutre pour pouvoir appeler le destructeur, j'imaginais une construction en deux temps.
Sur ce point, il faut faire une difference fondamentale entre l'heritage simple et l'heritage multiple. Le premier garanti que des que l'objet est alloue et que le pointeur isa (ou vptr) est initialise, l'objet est structurellement complet. Reste au developpeur d'initialiser ses membres.
En revanche l'heritage multiple est plus complique et une maniere "simple" de construire la structure de l'objet est de proceder de facon incrementale au fur et a mesure des appels des constructeurs lors de l'initialisation des membres (d'ou les restrictions qu'impose C++). On pourrait imaginer une initialisation en deux passes separees comme tu le suggeres, mais alors la premiere passe pourrait etre couteuse "pour rien" si l'initialisation echoue. Elle demanderait en plus un code plus complique (et plus lent que la version incrementale) similaire a ce que fait dynamic_cast. Je ne me souviens pas avoir lu la raison historique du choix de C++ dans le D&E mais la philosophie du C++ "on paye seulement le prix de ce qu'on achete" justifie deja ce choix.
