"Loïc Joly" a écrit dans le message news: bqmpod$lpi$
DINH Viêt Hoà wrote:
Les profs de C++ pourraient se servir de cet exemple pour illustrer les magnifiques méthodes d'obfuscation utilisées dans l'industrie ;-)
ça veut dire quoi "obfuscation" ?
Il n'est pas dans mon dictionnaire, est-ce un angliscisme ?
Oui, de l'anglais obfuscate
Obfuscate: tr.v. -cated, -cating, -cates. 1. a. To render obscure. b. To darken. 2. To confuse: his emotions obfuscated his judgment. [LLat. obfuscare, to darken : ob(intensive) + Lat. fuscare, to darken < fuscus, dark.] -obfuscation n. obfuscatory adj
Alors, mettons : "brouiller les pistes", même si l'on peut rêver plus court.
Embrouiller ?
Chris
Alain Naigeon wrote:
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message
news: bqmpod$lpi$1@news-reader1.wanadoo.fr...
DINH Viêt Hoà wrote:
Les profs de C++ pourraient se servir de cet exemple pour illustrer
les magnifiques méthodes d'obfuscation utilisées dans l'industrie
;-)
ça veut dire quoi "obfuscation" ?
Il n'est pas dans mon dictionnaire, est-ce un angliscisme ?
Oui, de l'anglais obfuscate
Obfuscate: tr.v. -cated, -cating, -cates. 1. a. To render obscure.
b. To darken. 2. To confuse: his emotions obfuscated his judgment.
[LLat. obfuscare, to darken : ob(intensive) + Lat. fuscare,
to darken < fuscus, dark.] -obfuscation n. obfuscatory adj
Alors, mettons : "brouiller les pistes", même si l'on peut rêver plus
court.
"Loïc Joly" a écrit dans le message news: bqmpod$lpi$
DINH Viêt Hoà wrote:
Les profs de C++ pourraient se servir de cet exemple pour illustrer les magnifiques méthodes d'obfuscation utilisées dans l'industrie ;-)
ça veut dire quoi "obfuscation" ?
Il n'est pas dans mon dictionnaire, est-ce un angliscisme ?
Oui, de l'anglais obfuscate
Obfuscate: tr.v. -cated, -cating, -cates. 1. a. To render obscure. b. To darken. 2. To confuse: his emotions obfuscated his judgment. [LLat. obfuscare, to darken : ob(intensive) + Lat. fuscare, to darken < fuscus, dark.] -obfuscation n. obfuscatory adj
Alors, mettons : "brouiller les pistes", même si l'on peut rêver plus court.
Embrouiller ?
Chris
Patrick Mézard
"DINH Viêt Hoà" a écrit dans le message de news:
quand à la valeur de retour de l'opérateur new, me semble-t-il qu'on n'a pas besoin de la tester, soit une a une exception, soit il réussit.
.. .soit tu compiles avec MSVC 6.0 et il te renvoie NULL (ok, c'est historique, la norme de l'époque... mais bon quand même).
Patrick Mézard
"DINH Viêt Hoà" <dinh.viet.hoa@free.fr> a écrit dans le message de
news:etPan.3fcf5f49.2310fc30.41c6@homer...
quand à la valeur de retour de l'opérateur new, me semble-t-il qu'on n'a
pas besoin de la tester, soit une a une exception, soit il réussit.
.. .soit tu compiles avec MSVC 6.0 et il te renvoie NULL (ok, c'est
historique, la norme de l'époque... mais bon quand même).
quand à la valeur de retour de l'opérateur new, me semble-t-il qu'on n'a pas besoin de la tester, soit une a une exception, soit il réussit.
.. .soit tu compiles avec MSVC 6.0 et il te renvoie NULL (ok, c'est historique, la norme de l'époque... mais bon quand même).
Patrick Mézard
Fabien LE LEZ
On Thu, 4 Dec 2003 16:29:20 +0100, "Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote:
Le choix du nom BOOL ne semble effectivement pas très heureux, d'autant plus que Microsoft ne se prive pas par ailleurs pour créer des noms de types bien spécifiques. Pour atténuer un peu la critique, les fonctions API sont du C utilisables en C++, et donc le type bool n'existait pas :
Bah oui, mais là il s'agit d'un booléen à trois valeurs ~_~ Il aurait quand même été plus heureux de renvoyer un int ou quelque chose du même style...
-- ;-)
On Thu, 4 Dec 2003 16:29:20 +0100, "Pierre Maurette"
<mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote:
Le choix du nom BOOL ne semble effectivement pas très heureux, d'autant plus
que Microsoft ne se prive pas par ailleurs pour créer des noms de types bien
spécifiques.
Pour atténuer un peu la critique, les fonctions API sont du C utilisables en
C++, et donc le type bool n'existait pas :
Bah oui, mais là il s'agit d'un booléen à trois valeurs ~_~
Il aurait quand même été plus heureux de renvoyer un int ou quelque
chose du même style...
On Thu, 4 Dec 2003 16:29:20 +0100, "Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote:
Le choix du nom BOOL ne semble effectivement pas très heureux, d'autant plus que Microsoft ne se prive pas par ailleurs pour créer des noms de types bien spécifiques. Pour atténuer un peu la critique, les fonctions API sont du C utilisables en C++, et donc le type bool n'existait pas :
Bah oui, mais là il s'agit d'un booléen à trois valeurs ~_~ Il aurait quand même été plus heureux de renvoyer un int ou quelque chose du même style...
-- ;-)
Fabien LE LEZ
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) : choquer, déplaire à.
-- ;-)
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) : choquer, déplaire à.
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) : choquer, déplaire à.
-- ;-)
Richard Delorme
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) : choquer, déplaire à.
C'est un sens figuré d'offusquer, le sens premier est celui que je donne. Pour une définition complète, tu peux consulter le TLFi : http://atilf.atilf.fr/tlf.htm
On y trouve une citation de Valéry où offusquer est utilisé dans le même sens que l'on pourrait employer en programmation : « Ce qui est évidence au regard ingénu disparaît quelquefois aux yeux des connaisseurs par la fixité même et le raffinement de leurs attentions. Il ne faut alors rien de moins qu'un homme de génie pour apercevoir quelque vérité essentielle et fort simple qu'ont offusquée les travaux et l'application d'une quantité de têtes profondes (VALÉRY, Variété IV, 1938, p.60). » Les états de services littéraires du monsieur nous autorise à employer offusquer à la place de l'anglicisme obfusquer sans aucune retenue.
Quand à ton Larousse, je pense que tu peux le brûler. La pauvreté de son vocabulaire est consternante.
-- Richard
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) : choquer, déplaire à.
C'est un sens figuré d'offusquer, le sens premier est celui que je donne.
Pour une définition complète, tu peux consulter le TLFi :
http://atilf.atilf.fr/tlf.htm
On y trouve une citation de Valéry où offusquer est utilisé dans le même
sens que l'on pourrait employer en programmation : « Ce qui est évidence au
regard ingénu disparaît quelquefois aux yeux des connaisseurs par la fixité
même et le raffinement de leurs attentions. Il ne faut alors rien de moins
qu'un homme de génie pour apercevoir quelque vérité essentielle et fort
simple qu'ont offusquée les travaux et l'application d'une quantité de
têtes profondes (VALÉRY, Variété IV, 1938, p.60). » Les états de services
littéraires du monsieur nous autorise à employer offusquer à la place de
l'anglicisme obfusquer sans aucune retenue.
Quand à ton Larousse, je pense que tu peux le brûler. La pauvreté de son
vocabulaire est consternante.
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) : choquer, déplaire à.
C'est un sens figuré d'offusquer, le sens premier est celui que je donne. Pour une définition complète, tu peux consulter le TLFi : http://atilf.atilf.fr/tlf.htm
On y trouve une citation de Valéry où offusquer est utilisé dans le même sens que l'on pourrait employer en programmation : « Ce qui est évidence au regard ingénu disparaît quelquefois aux yeux des connaisseurs par la fixité même et le raffinement de leurs attentions. Il ne faut alors rien de moins qu'un homme de génie pour apercevoir quelque vérité essentielle et fort simple qu'ont offusquée les travaux et l'application d'une quantité de têtes profondes (VALÉRY, Variété IV, 1938, p.60). » Les états de services littéraires du monsieur nous autorise à employer offusquer à la place de l'anglicisme obfusquer sans aucune retenue.
Quand à ton Larousse, je pense que tu peux le brûler. La pauvreté de son vocabulaire est consternante.
-- Richard
Gabriel Dos Reis
Richard Delorme writes:
| Quand à ton Larousse, je pense que tu peux le brûler. La pauvreté de son | vocabulaire est consternante.
Ainsi parla le Mollah Richard.
;-)
-- Gaby
Richard Delorme <abulmo@nospam.fr> writes:
| Quand à ton Larousse, je pense que tu peux le brûler. La pauvreté de son
| vocabulaire est consternante.
| Quand à ton Larousse, je pense que tu peux le brûler. La pauvreté de son | vocabulaire est consternante.
Ainsi parla le Mollah Richard.
;-)
-- Gaby
Je suis quand même moins dangereux que toi, je n'essaie pas de brûler de prof avec ;-)
Pour ceux qui ne suivent pas ma pensée : Message-ID:
-- Richard
Alain Naigeon
"Christophe Lephay" a écrit dans le message news: bqntvn$l9v$
Alain Naigeon wrote:
"Loïc Joly" a écrit dans le message news: bqmpod$lpi$
DINH Viêt Hoà wrote:
Les profs de C++ pourraient se servir de cet exemple pour illustrer les magnifiques méthodes d'obfuscation utilisées dans l'industrie ;-)
ça veut dire quoi "obfuscation" ?
Il n'est pas dans mon dictionnaire, est-ce un angliscisme ?
Oui, de l'anglais obfuscate
Obfuscate: tr.v. -cated, -cating, -cates. 1. a. To render obscure. b. To darken. 2. To confuse: his emotions obfuscated his judgment. [LLat. obfuscare, to darken : ob(intensive) + Lat. fuscare, to darken < fuscus, dark.] -obfuscation n. obfuscatory adj
Alors, mettons : "brouiller les pistes", même si l'on peut rêver plus court.
Embrouiller ?
Chris
Et voilà... Sony (tm) l'a fait !
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
news: bqntvn$l9v$1@news-reader1.wanadoo.fr...
Alain Naigeon wrote:
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message
news: bqmpod$lpi$1@news-reader1.wanadoo.fr...
DINH Viêt Hoà wrote:
Les profs de C++ pourraient se servir de cet exemple pour illustrer
les magnifiques méthodes d'obfuscation utilisées dans l'industrie
;-)
ça veut dire quoi "obfuscation" ?
Il n'est pas dans mon dictionnaire, est-ce un angliscisme ?
Oui, de l'anglais obfuscate
Obfuscate: tr.v. -cated, -cating, -cates. 1. a. To render obscure.
b. To darken. 2. To confuse: his emotions obfuscated his judgment.
[LLat. obfuscare, to darken : ob(intensive) + Lat. fuscare,
to darken < fuscus, dark.] -obfuscation n. obfuscatory adj
Alors, mettons : "brouiller les pistes", même si l'on peut rêver plus
court.
Embrouiller ?
Chris
Et voilà... Sony (tm) l'a fait !
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
"Christophe Lephay" a écrit dans le message news: bqntvn$l9v$
Alain Naigeon wrote:
"Loïc Joly" a écrit dans le message news: bqmpod$lpi$
DINH Viêt Hoà wrote:
Les profs de C++ pourraient se servir de cet exemple pour illustrer les magnifiques méthodes d'obfuscation utilisées dans l'industrie ;-)
ça veut dire quoi "obfuscation" ?
Il n'est pas dans mon dictionnaire, est-ce un angliscisme ?
Oui, de l'anglais obfuscate
Obfuscate: tr.v. -cated, -cating, -cates. 1. a. To render obscure. b. To darken. 2. To confuse: his emotions obfuscated his judgment. [LLat. obfuscare, to darken : ob(intensive) + Lat. fuscare, to darken < fuscus, dark.] -obfuscation n. obfuscatory adj
Alors, mettons : "brouiller les pistes", même si l'on peut rêver plus court.
Embrouiller ?
Chris
Et voilà... Sony (tm) l'a fait !
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
Pierre Maurette
"DINH Viêt Hoà" a écrit
Ceci dit, cette valeur de retour est assez pratique : une fois testée la valeur 0 (WM_QUIT), il suffit d'un ~ (inversion des bits) ou d'un ++ (incrément) pour la tester à -1. C'est surtout pratique en assembleur, en
fait.
Oulà, je n'ai rien compris. C'est assez obfusqué (un nouveau mot tous les jours) ton explication. Effectivement, pas clair (c'est HS). En MASM :
Je vois là un certain rapport avec le void* retourné par exemple par malloc() (ou new() dans certaines conditions) : pour moi, c'est un semi booléen, et donc je vais écrire if((ptr=malloc())) ou if(!(ptr=malloc())),
et ne pas me forcer à if((ptr=malloc())!=0) ou if((ptr=malloc())==0), mais
ce serait plutôt :
ptr = malloc(...); if (ptr == NULL) { ^^^^ ... }
enfin on dérive sur le C là ... désolé. Non, justement, je me situe bien en C++. J'aurais du choisir autre chose que
malloc(). J'utilise effectivement plutôt cette forme, celle que vous "préconisez". Pour les deux lignes ou une seule, c'est à voir, ici c'est plus compact à écrire dans le cours du message. Pour ce qui est de l'utilisation de NULL en C++, c'est sur ce groupe que j'ai vu des remarques signifiant que l'on ne devait pas. Je n'ose pas penser que vous en soyez l'auteur ... L'ami Bjarne (3ème éditioon, §5.1.1) est vaguement réticent, c'est tout ce que j'ai trouvé. Je continue donc à l'utiliser, quand mon compilateur le reconnait sans include particulier, c'est à dire tout le temps. Mais quand je poste ici, je reviens au 0, pour éviter les remarques. C'est donc raté.
quand à la valeur de retour de l'opérateur new, me semble-t-il qu'on n'a pas besoin de la tester, soit une a une exception, soit il réussit. L'opérateur new peut être utilisé en version nothrow. Il ne lance pas alors
d'exception, mais comme malloc(), renvoie le pointeur nul en cas d'échec. D'où "(ou new() dans certaines conditions)".
Reste qu'avec ton exemple, je ne vois pas le rapport non plus. Quand les booléens ne suffisent plus à communiquer un code de retour, en général, on essaie d'utiliser un entier (ce qui est généralement utilisé en C) ou autre (ou alors une exception si c'est en C++). Je m'impose des règles (de style) qui différencient absolument entiers et
booléens. Pas d'arihmétique entière sur ces derniers par exemple, etc. pour les tests, c'est if(varInt == 0) et if(!varBool), jamais le contraire. Sur ce dernier point, je m'accorde une liberté avec les pointeurs que nous venons d'évoquer, en prenant en compte l'aqspect booléen de leur comportement, ce qui me permet d'écrire éventuellement if(ptr). C'est personnel, peut-être contestable, mais volontairement décidé.
Cordialement, Pierre
"DINH Viêt Hoà" <dinh.viet.hoa@free.fr> a écrit
Ceci dit, cette valeur de retour est assez pratique : une fois testée la
valeur 0 (WM_QUIT), il suffit d'un ~ (inversion des bits) ou d'un ++
(incrément) pour la tester à -1. C'est surtout pratique en assembleur,
en
fait.
Oulà, je n'ai rien compris. C'est assez obfusqué (un nouveau mot tous
les jours) ton explication.
Effectivement, pas clair (c'est HS). En MASM :
Je vois là un certain rapport avec le void* retourné par exemple par
malloc() (ou new() dans certaines conditions) : pour moi, c'est un semi
booléen, et donc je vais écrire if((ptr=malloc())) ou
if(!(ptr=malloc())),
et ne pas me forcer à if((ptr=malloc())!=0) ou if((ptr=malloc())==0),
mais
ce serait plutôt :
ptr = malloc(...);
if (ptr == NULL) {
^^^^
...
}
enfin on dérive sur le C là ... désolé.
Non, justement, je me situe bien en C++. J'aurais du choisir autre chose que
malloc().
J'utilise effectivement plutôt cette forme, celle que vous "préconisez".
Pour les deux lignes ou une seule, c'est à voir, ici c'est plus compact à
écrire dans le cours du message.
Pour ce qui est de l'utilisation de NULL en C++, c'est sur ce groupe que
j'ai vu des remarques signifiant que l'on ne devait pas.
Je n'ose pas penser que vous en soyez l'auteur ...
L'ami Bjarne (3ème éditioon, §5.1.1) est vaguement réticent, c'est tout ce
que j'ai trouvé.
Je continue donc à l'utiliser, quand mon compilateur le reconnait sans
include particulier, c'est à dire tout le temps. Mais quand je poste ici, je
reviens au 0, pour éviter les remarques. C'est donc raté.
quand à la valeur de retour de l'opérateur new, me semble-t-il qu'on n'a
pas besoin de la tester, soit une a une exception, soit il réussit.
L'opérateur new peut être utilisé en version nothrow. Il ne lance pas alors
d'exception, mais comme malloc(), renvoie le pointeur nul en cas d'échec.
D'où "(ou new() dans certaines conditions)".
Reste qu'avec ton exemple, je ne vois pas le rapport non plus.
Quand les booléens ne suffisent plus à communiquer un code de retour, en
général, on essaie d'utiliser un entier (ce qui est généralement utilisé
en C) ou autre (ou alors une exception si c'est en C++).
Je m'impose des règles (de style) qui différencient absolument entiers et
booléens. Pas d'arihmétique entière sur ces derniers par exemple, etc.
pour les tests, c'est if(varInt == 0) et if(!varBool), jamais le contraire.
Sur ce dernier point, je m'accorde une liberté avec les pointeurs que nous
venons d'évoquer, en prenant en compte l'aqspect booléen de leur
comportement, ce qui me permet d'écrire éventuellement if(ptr). C'est
personnel, peut-être contestable, mais volontairement décidé.
Ceci dit, cette valeur de retour est assez pratique : une fois testée la valeur 0 (WM_QUIT), il suffit d'un ~ (inversion des bits) ou d'un ++ (incrément) pour la tester à -1. C'est surtout pratique en assembleur, en
fait.
Oulà, je n'ai rien compris. C'est assez obfusqué (un nouveau mot tous les jours) ton explication. Effectivement, pas clair (c'est HS). En MASM :
Je vois là un certain rapport avec le void* retourné par exemple par malloc() (ou new() dans certaines conditions) : pour moi, c'est un semi booléen, et donc je vais écrire if((ptr=malloc())) ou if(!(ptr=malloc())),
et ne pas me forcer à if((ptr=malloc())!=0) ou if((ptr=malloc())==0), mais
ce serait plutôt :
ptr = malloc(...); if (ptr == NULL) { ^^^^ ... }
enfin on dérive sur le C là ... désolé. Non, justement, je me situe bien en C++. J'aurais du choisir autre chose que
malloc(). J'utilise effectivement plutôt cette forme, celle que vous "préconisez". Pour les deux lignes ou une seule, c'est à voir, ici c'est plus compact à écrire dans le cours du message. Pour ce qui est de l'utilisation de NULL en C++, c'est sur ce groupe que j'ai vu des remarques signifiant que l'on ne devait pas. Je n'ose pas penser que vous en soyez l'auteur ... L'ami Bjarne (3ème éditioon, §5.1.1) est vaguement réticent, c'est tout ce que j'ai trouvé. Je continue donc à l'utiliser, quand mon compilateur le reconnait sans include particulier, c'est à dire tout le temps. Mais quand je poste ici, je reviens au 0, pour éviter les remarques. C'est donc raté.
quand à la valeur de retour de l'opérateur new, me semble-t-il qu'on n'a pas besoin de la tester, soit une a une exception, soit il réussit. L'opérateur new peut être utilisé en version nothrow. Il ne lance pas alors
d'exception, mais comme malloc(), renvoie le pointeur nul en cas d'échec. D'où "(ou new() dans certaines conditions)".
Reste qu'avec ton exemple, je ne vois pas le rapport non plus. Quand les booléens ne suffisent plus à communiquer un code de retour, en général, on essaie d'utiliser un entier (ce qui est généralement utilisé en C) ou autre (ou alors une exception si c'est en C++). Je m'impose des règles (de style) qui différencient absolument entiers et
booléens. Pas d'arihmétique entière sur ces derniers par exemple, etc. pour les tests, c'est if(varInt == 0) et if(!varBool), jamais le contraire. Sur ce dernier point, je m'accorde une liberté avec les pointeurs que nous venons d'évoquer, en prenant en compte l'aqspect booléen de leur comportement, ce qui me permet d'écrire éventuellement if(ptr). C'est personnel, peut-être contestable, mais volontairement décidé.
Cordialement, Pierre
Pierre Maurette
"Fabien LE LEZ" a écrit .
On Thu, 4 Dec 2003 16:29:20 +0100, "Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote:
Le choix du nom BOOL ne semble effectivement pas très heureux, d'autant plus
que Microsoft ne se prive pas par ailleurs pour créer des noms de types bien
spécifiques. Pour atténuer un peu la critique, les fonctions API sont du C utilisables en
C++, et donc le type bool n'existait pas :
Bah oui, mais là il s'agit d'un booléen à trois valeurs ~_~ Il aurait quand même été plus heureux de renvoyer un int ou quelque chose du même style... C'est un TRIBOOL !
Dans la dernière version du MSDN que j'ai, il y a un récapitulatif "Windows Data Types". Le BOOL est décrit "Boolean variable (should be TRUE or FALSE)". Et aussi un type BOOLEAN avec strictement la même définition. Un truc maison genre WPARAM ou LRESULT, avec une enum qui va bien peut-être, aurait sans doute convenu. Tiens, le LRESULT aussi est assez rigolo : sur certaines fonctions, "renvoie 0 si la fonction a réussi" ;-) Tout ça, ça doit avoir des raisons historiques. Pierre
"Fabien LE LEZ" <gramster@gramster.com> a écrit .
On Thu, 4 Dec 2003 16:29:20 +0100, "Pierre Maurette"
<mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote:
Le choix du nom BOOL ne semble effectivement pas très heureux, d'autant
plus
que Microsoft ne se prive pas par ailleurs pour créer des noms de types
bien
spécifiques.
Pour atténuer un peu la critique, les fonctions API sont du C utilisables
en
C++, et donc le type bool n'existait pas :
Bah oui, mais là il s'agit d'un booléen à trois valeurs ~_~
Il aurait quand même été plus heureux de renvoyer un int ou quelque
chose du même style...
C'est un TRIBOOL !
Dans la dernière version du MSDN que j'ai, il y a un récapitulatif "Windows
Data Types". Le BOOL est décrit "Boolean variable (should be TRUE or
FALSE)". Et aussi un type BOOLEAN avec strictement la même définition.
Un truc maison genre WPARAM ou LRESULT, avec une enum qui va bien peut-être,
aurait sans doute convenu.
Tiens, le LRESULT aussi est assez rigolo : sur certaines fonctions, "renvoie
0 si la fonction a réussi" ;-)
Tout ça, ça doit avoir des raisons historiques.
Pierre
On Thu, 4 Dec 2003 16:29:20 +0100, "Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote:
Le choix du nom BOOL ne semble effectivement pas très heureux, d'autant plus
que Microsoft ne se prive pas par ailleurs pour créer des noms de types bien
spécifiques. Pour atténuer un peu la critique, les fonctions API sont du C utilisables en
C++, et donc le type bool n'existait pas :
Bah oui, mais là il s'agit d'un booléen à trois valeurs ~_~ Il aurait quand même été plus heureux de renvoyer un int ou quelque chose du même style... C'est un TRIBOOL !
Dans la dernière version du MSDN que j'ai, il y a un récapitulatif "Windows Data Types". Le BOOL est décrit "Boolean variable (should be TRUE or FALSE)". Et aussi un type BOOLEAN avec strictement la même définition. Un truc maison genre WPARAM ou LRESULT, avec une enum qui va bien peut-être, aurait sans doute convenu. Tiens, le LRESULT aussi est assez rigolo : sur certaines fonctions, "renvoie 0 si la fonction a réussi" ;-) Tout ça, ça doit avoir des raisons historiques. Pierre
