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");
Si tu parles pour OOC, la reponse est oui. Les destructeurs sont systematiquement appeles. D'ou la necessite de rentre neutre le parent pour son destructeur avant le debut de l'initialisation des membres. Concretement, je n'ai vu que la necessite de mettre a NULL les pointeurs membres, rien de bien mechant.
Je me demandais si tu avais un mecanisme plus general pour ca, qu'on puisse compter sur un invariant dans le destructeur. Une technique possible pour les deux phases (dans le cas de l'heritage simple, nous sommes d'accord) serait de faire la mise en etat stable du constructeur le plus derive (qui donc ne peut compter sur rien en ce qui concerne les parents) , puis appeler celui du parent, et enfin faire la partie "dangereuse".
C'est exactement ca. Un constructeur d'une classe ayant un membre String str donnerait:
method(MyClass, init) { self->str = 0; // neutre pour dtor
// partie "dangereuse" scall(init); // appel le constructeur init de la super classe self->str = own(new(String)); // alloc+ctor+owner
return self; }
method(void, deinit) { release(self->str); // dtor+dealloc (si ref-count a zero) // accept 0 and set to 0 after destruction scall(deinit); }
Mais il est probable que ce soit de la complication pour rien.
Au fait, est-ce que tu as la meme chose qu'en C++/CLI, la possibilite que les destructeurs soient appeles plusieurs fois?
Non. Il y a trois raisons a cela: 1) les objets sont tous dynamiques (sauf cas exceptionnel) donc c'est comme faire free(ptr), free(ptr); 2) le reference counting et la gestion des contextes (hors sujet ici) fait que delete sur un objet n'aboutit a sa destruction (et donc a l'appel du destructeur) que dans un seul cas unique non-reversible qui est la branche new-delete dans le graphe de la duree de vie des objets. 3) je trouve ca extremement dangereux de compter sur ce genre de possibilite.
a+, ld.
Jean-Marc Bourguet wrote:
Laurent Deniau <laurent.deniau@cern.ch> writes:
Si tu parles pour OOC, la reponse est oui. Les destructeurs sont
systematiquement appeles. D'ou la necessite de rentre neutre le
parent pour son destructeur avant le debut de l'initialisation des
membres. Concretement, je n'ai vu que la necessite de mettre a NULL
les pointeurs membres, rien de bien mechant.
Je me demandais si tu avais un mecanisme plus general pour ca, qu'on
puisse compter sur un invariant dans le destructeur. Une technique
possible pour les deux phases (dans le cas de l'heritage simple, nous
sommes d'accord) serait de faire la mise en etat stable du
constructeur le plus derive (qui donc ne peut compter sur rien en ce
qui concerne les parents) , puis appeler celui du parent, et enfin
faire la partie "dangereuse".
C'est exactement ca. Un constructeur d'une classe ayant un membre String
str donnerait:
method(MyClass, init)
{
self->str = 0; // neutre pour dtor
// partie "dangereuse"
scall(init); // appel le constructeur init de la super classe
self->str = own(new(String)); // alloc+ctor+owner
return self;
}
method(void, deinit)
{
release(self->str); // dtor+dealloc (si ref-count a zero)
// accept 0 and set to 0 after destruction
scall(deinit);
}
Mais il est probable que ce soit de la complication pour rien.
Au fait, est-ce que tu as la meme chose qu'en C++/CLI, la possibilite
que les destructeurs soient appeles plusieurs fois?
Non. Il y a trois raisons a cela:
1) les objets sont tous dynamiques (sauf cas exceptionnel) donc c'est
comme faire free(ptr), free(ptr);
2) le reference counting et la gestion des contextes (hors sujet ici)
fait que delete sur un objet n'aboutit a sa destruction (et donc a
l'appel du destructeur) que dans un seul cas unique non-reversible qui
est la branche new-delete dans le graphe de la duree de vie des objets.
3) je trouve ca extremement dangereux de compter sur ce genre de
possibilite.
Si tu parles pour OOC, la reponse est oui. Les destructeurs sont systematiquement appeles. D'ou la necessite de rentre neutre le parent pour son destructeur avant le debut de l'initialisation des membres. Concretement, je n'ai vu que la necessite de mettre a NULL les pointeurs membres, rien de bien mechant.
Je me demandais si tu avais un mecanisme plus general pour ca, qu'on puisse compter sur un invariant dans le destructeur. Une technique possible pour les deux phases (dans le cas de l'heritage simple, nous sommes d'accord) serait de faire la mise en etat stable du constructeur le plus derive (qui donc ne peut compter sur rien en ce qui concerne les parents) , puis appeler celui du parent, et enfin faire la partie "dangereuse".
C'est exactement ca. Un constructeur d'une classe ayant un membre String str donnerait:
method(MyClass, init) { self->str = 0; // neutre pour dtor
// partie "dangereuse" scall(init); // appel le constructeur init de la super classe self->str = own(new(String)); // alloc+ctor+owner
return self; }
method(void, deinit) { release(self->str); // dtor+dealloc (si ref-count a zero) // accept 0 and set to 0 after destruction scall(deinit); }
Mais il est probable que ce soit de la complication pour rien.
Au fait, est-ce que tu as la meme chose qu'en C++/CLI, la possibilite que les destructeurs soient appeles plusieurs fois?
Non. Il y a trois raisons a cela: 1) les objets sont tous dynamiques (sauf cas exceptionnel) donc c'est comme faire free(ptr), free(ptr); 2) le reference counting et la gestion des contextes (hors sujet ici) fait que delete sur un objet n'aboutit a sa destruction (et donc a l'appel du destructeur) que dans un seul cas unique non-reversible qui est la branche new-delete dans le graphe de la duree de vie des objets. 3) je trouve ca extremement dangereux de compter sur ce genre de possibilite.
a+, ld.
Jean-Marc Bourguet
Laurent Deniau writes:
Mais il est probable que ce soit de la complication pour rien. Au fait, est-ce que tu as la meme chose qu'en C++/CLI, la possibilite que les destructeurs soient appeles plusieurs fois?
3) je trouve ca extremement dangereux de compter sur ce genre de possibilite.
Je suis d'accord. Je ne comprends d'ailleurs pas tres bien pourquoi ils imposent ca sur les destructeurs.
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Laurent Deniau <laurent.deniau@cern.ch> writes:
Mais il est probable que ce soit de la complication pour rien.
Au fait, est-ce que tu as la meme chose qu'en C++/CLI, la possibilite
que les destructeurs soient appeles plusieurs fois?
3) je trouve ca extremement dangereux de compter sur ce genre de
possibilite.
Je suis d'accord. Je ne comprends d'ailleurs pas tres bien pourquoi
ils imposent ca sur les destructeurs.
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Mais il est probable que ce soit de la complication pour rien. Au fait, est-ce que tu as la meme chose qu'en C++/CLI, la possibilite que les destructeurs soient appeles plusieurs fois?
3) je trouve ca extremement dangereux de compter sur ce genre de possibilite.
Je suis d'accord. Je ne comprends d'ailleurs pas tres bien pourquoi ils imposent ca sur les destructeurs.
-- 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 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.
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.
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.
Pas possible, le type est non signé. Il pourrait retourner (size_t)-1, mais il faudrait définir cette valeur comme 'interdite'.
#define INVALID_LEN ((size_t)-1)
(Pas plus tard que cet après midi, j'ai vu un (char *)-1 sur un unixoide, alors je ne m'étonne plus de rien...)
-- A+
Emmanuel Delahaye
Jean-Marc Bourguet
Emmanuel Delahaye writes:
size_t str_len(const char *str) { assert(str); ... } 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.
test+errno+return
me plait bien pour celui-ci, avec return 0
Donc il faudrait aussi mettre errno a quelque chose en cas de retour normal de 0, ce qui est quelque peut contraire a l'habitude de ne pas toucher errno si on n'a pas d'erreur.
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
Emmanuel Delahaye <emdel@YOURBRAnoos.fr> writes:
size_t str_len(const char *str)
{
assert(str);
...
}
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.
test+errno+return
me plait bien pour celui-ci, avec return 0
Donc il faudrait aussi mettre errno a quelque chose en cas de retour
normal de 0, ce qui est quelque peut contraire a l'habitude de ne pas
toucher errno si on n'a pas d'erreur.
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
size_t str_len(const char *str) { assert(str); ... } 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.
test+errno+return
me plait bien pour celui-ci, avec return 0
Donc il faudrait aussi mettre errno a quelque chose en cas de retour normal de 0, ce qui est quelque peut contraire a l'habitude de ne pas toucher errno si on n'a pas d'erreur.
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
