| on aurait : VRAI OU VRAI = ECHEC, ce qui serait un peu absurde.
Pourquoi ?
Enfin je veux dire, si on se raccroche à l'algèbre de Boole et qu'on cherche à avoir une "compatibilité", la proposition "VRAI OU VRAI = ECHEC" n'a pas lieu d'être.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
DINH Viêt Hoà <dinh.viet.hoa@free.fr> writes:
| on aurait : VRAI OU VRAI = ECHEC, ce qui serait un peu absurde.
Pourquoi ?
Enfin je veux dire, si on se raccroche à l'algèbre de Boole et qu'on
cherche à avoir une "compatibilité", la proposition
"VRAI OU VRAI = ECHEC" n'a pas lieu d'être.
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
| on aurait : VRAI OU VRAI = ECHEC, ce qui serait un peu absurde.
Pourquoi ?
Enfin je veux dire, si on se raccroche à l'algèbre de Boole et qu'on cherche à avoir une "compatibilité", la proposition "VRAI OU VRAI = ECHEC" n'a pas lieu d'être.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
un.gabacho.sans.pourrier
Fabien LE LEZ writes:
On Thu, 04 Dec 2003 10:20:03 +0100, Richard Delorme wrote:
du verbe offusquer, qui veut dire « cacher à la vue, empêcher de voir »,
C'est marrant, mon Larousse une définition très différente de ce verbe (celle que je connaissais, en fait)
La seule qui existe.
choquer, déplaire à.
Ben oui.
Fabien LE LEZ <gramster@gramster.com> writes:
On Thu, 04 Dec 2003 10:20:03 +0100, Richard Delorme <abulmo@nospam.fr>
wrote:
du verbe
offusquer, qui veut dire « cacher à la vue, empêcher de voir »,
C'est marrant, mon Larousse une définition très différente de ce verbe
(celle que je connaissais, en fait)
while(true) //quand ce n'est pas while(!FINI) { // ... }
(j'ai préféré abandonner une version macro FAIRE_TOUJOURS).
Pierre
Pierre Maurette
"Gabriel Dos Reis" a écrit ..
"Pierre Maurette" writes:
| Ou alors, peut-être préférez-vous : | while(A = f(), A != ERROR)
for (A = f(); A != ERROR; A = f()) Certes. Mais personnellement, je n'aurais pas osé.
Non pas l'écrire mais le proposer ici. Je deviens parano au moment de poster sur ce groupe ;-) Bon, j'ai eu fait bien pire à base de for(;;), mais actuellement, j'en suis plutôt à me soigner. Donc, vive le while() pour une boucle de type "tant que". Pierre
"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit ..
"Pierre Maurette" writes:
| Ou alors, peut-être préférez-vous :
| while(A = f(), A != ERROR)
for (A = f(); A != ERROR; A = f())
Certes. Mais personnellement, je n'aurais pas osé.
Non pas l'écrire mais le proposer ici.
Je deviens parano au moment de poster sur ce groupe ;-)
Bon, j'ai eu fait bien pire à base de for(;;), mais actuellement, j'en suis
plutôt à me soigner.
Donc, vive le while() pour une boucle de type "tant que".
Pierre
| Ou alors, peut-être préférez-vous : | while(A = f(), A != ERROR)
for (A = f(); A != ERROR; A = f()) Certes. Mais personnellement, je n'aurais pas osé.
Non pas l'écrire mais le proposer ici. Je deviens parano au moment de poster sur ce groupe ;-) Bon, j'ai eu fait bien pire à base de for(;;), mais actuellement, j'en suis plutôt à me soigner. Donc, vive le while() pour une boucle de type "tant que". Pierre
Fabien LE LEZ
On Fri, 5 Dec 2003 15:25:12 +0100, DINH Viêt Hoà wrote:
Z/3Z est déjà bien connu, non ?
enfin j'ai l'impression que ce n'est pas trop équivalent à Z/3Z
"tiens, un corps à ajouter à la théorie des ensembles ?"
Un corps de 3 éléments est forcément isomorphe à Z/3Z, puisque c'est le seul corps à 3 éléments.
De toutes façons, dans le cas de GetMessage(), il n'y a pas d'opérateurs : on traite généralement le message indiqué par un premier appel à cette fonction avant de l'appeler une nouvelle fois.
-- ;-)
On Fri, 5 Dec 2003 15:25:12 +0100, DINH Viêt Hoà
<dinh.viet.hoa@free.fr> wrote:
Z/3Z est déjà bien connu, non ?
enfin j'ai l'impression que ce n'est pas trop équivalent à Z/3Z
"tiens, un corps à ajouter à la théorie des ensembles ?"
Un corps de 3 éléments est forcément isomorphe à Z/3Z, puisque c'est
le seul corps à 3 éléments.
De toutes façons, dans le cas de GetMessage(), il n'y a pas
d'opérateurs : on traite généralement le message indiqué par un
premier appel à cette fonction avant de l'appeler une nouvelle fois.
On Fri, 5 Dec 2003 15:25:12 +0100, DINH Viêt Hoà wrote:
Z/3Z est déjà bien connu, non ?
enfin j'ai l'impression que ce n'est pas trop équivalent à Z/3Z
"tiens, un corps à ajouter à la théorie des ensembles ?"
Un corps de 3 éléments est forcément isomorphe à Z/3Z, puisque c'est le seul corps à 3 éléments.
De toutes façons, dans le cas de GetMessage(), il n'y a pas d'opérateurs : on traite généralement le message indiqué par un premier appel à cette fonction avant de l'appeler une nouvelle fois.
Moi je préfère : bool Finiúlse; while(!Fini) { A=f(); if(A != NO_ERROR) Fini = true; .... }
je n'aime pas trop l'idée de faire un test pour savoir si 1 est vrai. Et puis j'aime pas trop break non plus ;-)
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
espie
In article , Fabien LE LEZ wrote:
On Fri, 5 Dec 2003 15:25:12 +0100, DINH Viêt Hoà wrote:
Z/3Z est déjà bien connu, non ?
enfin j'ai l'impression que ce n'est pas trop équivalent à Z/3Z
"tiens, un corps à ajouter à la théorie des ensembles ?"
Un corps de 3 éléments est forcément isomorphe à Z/3Z, puisque c'est le seul corps à 3 éléments.
C'est malin d'entretenir la confusion comme ca.
Pas trop l'interet de considerer Z/3Z comme corps, vu qu'on essaie d'etendre l'algebre de Boole, qui euh, ne correspond pas trop a une structure de corps sur Z/2Z, hein...
Enfin, meme pas l'algebre de Boole en fait, puisque ce qu'on considere a le bon gout de ne pas etre commutatif grace aux proprietes de court-circuit des operateurs du C++.
(d'ou la difference entre les gens que FAUX ou ECHEC = ECHEC choque et ceux qui trouvent ca naturel).
In article <1bj1tvgf36iid5jo1p2ec8sj5hcj1njjpi@4ax.com>,
Fabien LE LEZ <usenet2@gramster.com> wrote:
On Fri, 5 Dec 2003 15:25:12 +0100, DINH Viêt Hoà
<dinh.viet.hoa@free.fr> wrote:
Z/3Z est déjà bien connu, non ?
enfin j'ai l'impression que ce n'est pas trop équivalent à Z/3Z
"tiens, un corps à ajouter à la théorie des ensembles ?"
Un corps de 3 éléments est forcément isomorphe à Z/3Z, puisque c'est
le seul corps à 3 éléments.
C'est malin d'entretenir la confusion comme ca.
Pas trop l'interet de considerer Z/3Z comme corps, vu qu'on essaie
d'etendre l'algebre de Boole, qui euh, ne correspond pas trop a une
structure de corps sur Z/2Z, hein...
Enfin, meme pas l'algebre de Boole en fait, puisque ce qu'on considere
a le bon gout de ne pas etre commutatif grace aux proprietes de
court-circuit des operateurs du C++.
(d'ou la difference entre les gens que FAUX ou ECHEC = ECHEC choque et ceux
qui trouvent ca naturel).
On Fri, 5 Dec 2003 15:25:12 +0100, DINH Viêt Hoà wrote:
Z/3Z est déjà bien connu, non ?
enfin j'ai l'impression que ce n'est pas trop équivalent à Z/3Z
"tiens, un corps à ajouter à la théorie des ensembles ?"
Un corps de 3 éléments est forcément isomorphe à Z/3Z, puisque c'est le seul corps à 3 éléments.
C'est malin d'entretenir la confusion comme ca.
Pas trop l'interet de considerer Z/3Z comme corps, vu qu'on essaie d'etendre l'algebre de Boole, qui euh, ne correspond pas trop a une structure de corps sur Z/2Z, hein...
Enfin, meme pas l'algebre de Boole en fait, puisque ce qu'on considere a le bon gout de ne pas etre commutatif grace aux proprietes de court-circuit des operateurs du C++.
(d'ou la difference entre les gens que FAUX ou ECHEC = ECHEC choque et ceux qui trouvent ca naturel).
|> > if(a == c) |> Vous ne préfèreriez pas : |> if ( a == c ) |> ? ;-)
C'est ce que j'utilise, moi aussi.
Ceci dit, ça va à l'encontre des conventions habituelles de la typographie, qui dit qu'il n'y a pas d'espace après le '('. Quand on établit de telles règles, il y a toujours un choix difficile à faire entre les conventions et la logique. Donc, si je mets un espace après le '(', c'est parce que l'ensemble qui suit est logiquement plus lié entre lui qu'avec le parenthèse. Dans ce cas-ci, le a et le c sont plus liés au == qu'au '(' ou au ')'. Donc, je ne veux pas moins d'espace, et je tiens aux espaces dans l'expression.
Mais la même logique ferait mettre un espace et avant et après le virgule, dans par exemple « f( a , b ) ». Chose que j'ai fait un certain temps, mais qui fait bien beaucoup d'espaces, et qu'aucun client n'a jamais voulu agréer.
Parfois, aussi, on crée des distinctions que la typographie standard ne connaît pas. Donc, par exemple, je sépare les mots clés if, while, etc. du '(' par un espace, mais non les noms de fonctions. De façon à ce que la distinction soit rapidement visible.
|> [...] |> > Je préfère :
|> > while (1) {
|> > A = f(); |> > if (A != NO_ERROR) |> > break;
|> > // ... |> > } |> J'écris :
|> while(true) //quand ce n'est pas while(!FINI) |> { |> // ... |> }
Dans les deux cas, on sort du milieu de la boucle. Ce n'est pas bien.
|> (j'ai préféré abandonner une version macro FAIRE_TOUJOURS).
Je l'espère. Le langage est ce qu'il est, mais essayer de le changer au moyen des macros ne peut que préter à la confusion à la longue.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> "DINH Viêt Hoà" <dinh.viet.hoa@free.fr> a écrit
|> [...]
|> > je préfère :
|> > if (a == c)
|> > à :
|> > if(a == c)
|> Vous ne préfèreriez pas :
|> if ( a == c )
|> ? ;-)
C'est ce que j'utilise, moi aussi.
Ceci dit, ça va à l'encontre des conventions habituelles de la
typographie, qui dit qu'il n'y a pas d'espace après le '('. Quand on
établit de telles règles, il y a toujours un choix difficile à
faire entre les conventions et la logique. Donc, si je mets un espace
après le '(', c'est parce que l'ensemble qui suit est logiquement
plus lié entre lui qu'avec le parenthèse. Dans ce cas-ci, le a et
le c sont plus liés au == qu'au '(' ou au ')'. Donc, je ne veux pas
moins d'espace, et je tiens aux espaces dans l'expression.
Mais la même logique ferait mettre un espace et avant et après le
virgule, dans par exemple « f( a , b ) ». Chose que j'ai fait un
certain temps, mais qui fait bien beaucoup d'espaces, et qu'aucun client
n'a jamais voulu agréer.
Parfois, aussi, on crée des distinctions que la typographie standard
ne connaît pas. Donc, par exemple, je sépare les mots clés if,
while, etc. du '(' par un espace, mais non les noms de fonctions. De
façon à ce que la distinction soit rapidement visible.
|> [...]
|> > Je préfère :
|> > while (1) {
|> > A = f();
|> > if (A != NO_ERROR)
|> > break;
|> > // ...
|> > }
|> J'écris :
|> while(true) //quand ce n'est pas while(!FINI)
|> {
|> // ...
|> }
Dans les deux cas, on sort du milieu de la boucle. Ce n'est pas bien.
|> (j'ai préféré abandonner une version macro FAIRE_TOUJOURS).
Je l'espère. Le langage est ce qu'il est, mais essayer de le changer
au moyen des macros ne peut que préter à la confusion à la
longue.
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> > if(a == c) |> Vous ne préfèreriez pas : |> if ( a == c ) |> ? ;-)
C'est ce que j'utilise, moi aussi.
Ceci dit, ça va à l'encontre des conventions habituelles de la typographie, qui dit qu'il n'y a pas d'espace après le '('. Quand on établit de telles règles, il y a toujours un choix difficile à faire entre les conventions et la logique. Donc, si je mets un espace après le '(', c'est parce que l'ensemble qui suit est logiquement plus lié entre lui qu'avec le parenthèse. Dans ce cas-ci, le a et le c sont plus liés au == qu'au '(' ou au ')'. Donc, je ne veux pas moins d'espace, et je tiens aux espaces dans l'expression.
Mais la même logique ferait mettre un espace et avant et après le virgule, dans par exemple « f( a , b ) ». Chose que j'ai fait un certain temps, mais qui fait bien beaucoup d'espaces, et qu'aucun client n'a jamais voulu agréer.
Parfois, aussi, on crée des distinctions que la typographie standard ne connaît pas. Donc, par exemple, je sépare les mots clés if, while, etc. du '(' par un espace, mais non les noms de fonctions. De façon à ce que la distinction soit rapidement visible.
|> [...] |> > Je préfère :
|> > while (1) {
|> > A = f(); |> > if (A != NO_ERROR) |> > break;
|> > // ... |> > } |> J'écris :
|> while(true) //quand ce n'est pas while(!FINI) |> { |> // ... |> }
Dans les deux cas, on sort du milieu de la boucle. Ce n'est pas bien.
|> (j'ai préféré abandonner une version macro FAIRE_TOUJOURS).
Je l'espère. Le langage est ce qu'il est, mais essayer de le changer au moyen des macros ne peut que préter à la confusion à la longue.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Michel Michaud
Dans news:, James
(j'ai préféré abandonner une version macro FAIRE_TOUJOURS).
Je l'espère. Le langage est ce qu'il est, mais essayer de le changer au moyen des macros ne peut que préter à la confusion à la longue.
Bien sûr... Et c'est pourquoi il faut éviter NULL et utiliser 0.
:-)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:86y8tq2dkf.fsf@alex.gabi-soft.fr, James
(j'ai préféré abandonner une version macro FAIRE_TOUJOURS).
Je l'espère. Le langage est ce qu'il est, mais essayer de le changer
au moyen des macros ne peut que préter à la confusion à la
longue.
Bien sûr... Et c'est pourquoi il faut éviter NULL et utiliser 0.
:-)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
