« Single entry, Single exit. » En fait, qu'on entre dans chaque bloc d'en haut, et qu'on sort systèmatiquement d'en bas.
Donc seulement des do-while ? :-)
Il ne faut pas tout confondre. SESO : un point d'entrée, un point de sortie. C'est tout... Heureusement !
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
James Kanze
drkm writes:
|> > Je n'avais pas remarqué qu'ils avaient le même nom. En effet, avec |> > le même nom, le code est illégal. Avec des noms différents, il |> > n'est légal que si les types ont des constructeurs triviaux.
|> Ok. On ne peut donc jamais avoir deux objets du même nom dans la |> même portée. Donc les deux switch suivants sont illégaux, le premier |> car deux objets ont le même nom, le second car le constructeur n'est |> pas trivial :
|> switch ( ... ) { |> case ... : |> int i ; |> break ; |> case ... : |> int i ; |> break ; |> }
|> class Integer { |> public: |> Integer( int i = 0 ) |> : myInt( i ) { |> } |> private: |> int myInt ; |> } ;
|> C'est bien ça ? C'est bien les diagnostiques que donne GCC 3.3.1, |> en tout cas.
J'imagine qu'il y a peu de compilateurs qui s'y trompe aujourd'hui:-).
|> Et pour préciser mon premier article, c'est bien parce que les |> deux objets portaient le même nom que je l'ai posté.
Alors, j'ai raté l'intention. Je n'ai vu que le fait qu'il y avait deux variable d'un type défini par l'utilisateur.
C'est le problème avec les initialisateurs qui a amené la quasi-totale des règles de programmation à insister sur les {}. Ça, et le fait qu'il y avait des compilateurs qui avait des problèmes avec des temporaires.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
drkm <usenet.fclcxx@fgeorges.org> writes:
|> > Je n'avais pas remarqué qu'ils avaient le même nom. En effet, avec
|> > le même nom, le code est illégal. Avec des noms différents, il
|> > n'est légal que si les types ont des constructeurs triviaux.
|> Ok. On ne peut donc jamais avoir deux objets du même nom dans la
|> même portée. Donc les deux switch suivants sont illégaux, le premier
|> car deux objets ont le même nom, le second car le constructeur n'est
|> pas trivial :
|> switch ( ... ) {
|> case ... :
|> int i ;
|> break ;
|> case ... :
|> int i ;
|> break ;
|> }
|> class Integer {
|> public:
|> Integer( int i = 0 )
|> : myInt( i ) {
|> }
|> private:
|> int myInt ;
|> } ;
|> C'est bien ça ? C'est bien les diagnostiques que donne GCC 3.3.1,
|> en tout cas.
J'imagine qu'il y a peu de compilateurs qui s'y trompe aujourd'hui:-).
|> Et pour préciser mon premier article, c'est bien parce que les
|> deux objets portaient le même nom que je l'ai posté.
Alors, j'ai raté l'intention. Je n'ai vu que le fait qu'il y avait deux
variable d'un type défini par l'utilisateur.
C'est le problème avec les initialisateurs qui a amené la quasi-totale
des règles de programmation à insister sur les {}. Ça, et le fait qu'il
y avait des compilateurs qui avait des problèmes avec des temporaires.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> > Je n'avais pas remarqué qu'ils avaient le même nom. En effet, avec |> > le même nom, le code est illégal. Avec des noms différents, il |> > n'est légal que si les types ont des constructeurs triviaux.
|> Ok. On ne peut donc jamais avoir deux objets du même nom dans la |> même portée. Donc les deux switch suivants sont illégaux, le premier |> car deux objets ont le même nom, le second car le constructeur n'est |> pas trivial :
|> switch ( ... ) { |> case ... : |> int i ; |> break ; |> case ... : |> int i ; |> break ; |> }
|> class Integer { |> public: |> Integer( int i = 0 ) |> : myInt( i ) { |> } |> private: |> int myInt ; |> } ;
|> C'est bien ça ? C'est bien les diagnostiques que donne GCC 3.3.1, |> en tout cas.
J'imagine qu'il y a peu de compilateurs qui s'y trompe aujourd'hui:-).
|> Et pour préciser mon premier article, c'est bien parce que les |> deux objets portaient le même nom que je l'ai posté.
Alors, j'ai raté l'intention. Je n'ai vu que le fait qu'il y avait deux variable d'un type défini par l'utilisateur.
C'est le problème avec les initialisateurs qui a amené la quasi-totale des règles de programmation à insister sur les {}. Ça, et le fait qu'il y avait des compilateurs qui avait des problèmes avec des temporaires.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
"Michel Michaud" writes:
|> Dans news:, |> > « Single entry, Single exit. » En fait, qu'on entre dans chaque |> > bloc d'en haut, et qu'on sort systèmatiquement d'en bas.
|> Donc seulement des do-while ? :-)
L'entrée, c'est toujours par le haut. La sortie, en revanche, c'est effectivement plus souvent par le haut que par le bas:-).
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
"Michel Michaud" <mm@gdzid.com> writes:
|> Dans news:m2sma7rzb6.fsf@lns-vlq-28-82-254-72-92.adsl.proxad.net,
|> > « Single entry, Single exit. » En fait, qu'on entre dans chaque
|> > bloc d'en haut, et qu'on sort systèmatiquement d'en bas.
|> Donc seulement des do-while ? :-)
L'entrée, c'est toujours par le haut. La sortie, en revanche, c'est
effectivement plus souvent par le haut que par le bas:-).
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> Dans news:, |> > « Single entry, Single exit. » En fait, qu'on entre dans chaque |> > bloc d'en haut, et qu'on sort systèmatiquement d'en bas.
|> Donc seulement des do-while ? :-)
L'entrée, c'est toujours par le haut. La sortie, en revanche, c'est effectivement plus souvent par le haut que par le bas:-).
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Loïc Joly
wrote:
Note aussi que j'utilise un style rigueureusement SESO ; il n'y aura donc jamais de break dans les {}.
Tu utilises donc toujours la version nothrow de new ? Et jamais std::vector::at ?
-- Loïc
kanze@gabi-soft.fr wrote:
Note aussi que j'utilise un style rigueureusement SESO ; il n'y aura
donc jamais de break dans les {}.
Tu utilises donc toujours la version nothrow de new ? Et jamais
std::vector::at ?
Note aussi que j'utilise un style rigueureusement SESO ; il n'y aura donc jamais de break dans les {}.
Tu utilises donc toujours la version nothrow de new ? Et jamais std::vector::at ?
-- Loïc
kanze
Loïc Joly wrote in message news:<cgv41l$v6h$...
wrote:
Note aussi que j'utilise un style rigueureusement SESO ; il n'y aura donc jamais de break dans les {}.
Tu utilises donc toujours la version nothrow de new ? Et jamais std::vector::at ?
Jamais std::vector::at (d'autant plus qu'il manque dans g++ 2.95.2). Et dans la plupart des applications, j'installe un new_handler qui avorte.
Mais c'est vrai que j'ai resisté longtemps aux exceptions. Après tout, ce n'est que des goto (et non local, en plus) déguisés. Même aujourd'hui, je ne les utilise que comme un espèce de abort() d'un sous-système -- pour que je lève une exception, il faut que l'erreur soit fatale. (Il y a quelques exceptions dans les constructeurs, à cause de la manque d'autres possibilités de rapporter l'erreur.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<cgv41l$v6h$1@news-reader4.wanadoo.fr>...
kanze@gabi-soft.fr wrote:
Note aussi que j'utilise un style rigueureusement SESO ; il n'y aura
donc jamais de break dans les {}.
Tu utilises donc toujours la version nothrow de new ? Et jamais
std::vector::at ?
Jamais std::vector::at (d'autant plus qu'il manque dans g++ 2.95.2). Et
dans la plupart des applications, j'installe un new_handler qui avorte.
Mais c'est vrai que j'ai resisté longtemps aux exceptions. Après tout,
ce n'est que des goto (et non local, en plus) déguisés. Même
aujourd'hui, je ne les utilise que comme un espèce de abort() d'un
sous-système -- pour que je lève une exception, il faut que l'erreur
soit fatale. (Il y a quelques exceptions dans les constructeurs, à cause
de la manque d'autres possibilités de rapporter l'erreur.)
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Note aussi que j'utilise un style rigueureusement SESO ; il n'y aura donc jamais de break dans les {}.
Tu utilises donc toujours la version nothrow de new ? Et jamais std::vector::at ?
Jamais std::vector::at (d'autant plus qu'il manque dans g++ 2.95.2). Et dans la plupart des applications, j'installe un new_handler qui avorte.
Mais c'est vrai que j'ai resisté longtemps aux exceptions. Après tout, ce n'est que des goto (et non local, en plus) déguisés. Même aujourd'hui, je ne les utilise que comme un espèce de abort() d'un sous-système -- pour que je lève une exception, il faut que l'erreur soit fatale. (Il y a quelques exceptions dans les constructeurs, à cause de la manque d'autres possibilités de rapporter l'erreur.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
