|> > if(a == c) |> Vous ne préfèreriez pas : |> if ( a == c ) |> ? ;-)
C'est ce que j'utilise, moi aussi. [...]
Mais la même logique ferait mettre un espace et avant et après le virgule, dans par exemple « f( a , b ) ». En fait, ce n'est pas ce que j'utilise. Je chambrais (gentiment) la réponse
à la "schtroumpf grognon", en faisant la même chose. J'ai des contraintes de lisibilité à l'impression, impression que je ne maîtrise pas, donc de longueur de ligne, d'autant que j'utilise des noms relativement long. J'en arrive donc à des trucs un peu boiteux: x = f(a, b); Je réduit la tabulation à deux caractères. J'économise la première indentation au niveau fonction : int fonct(int a, int b) { a = 2 * b; if(a == 0) { b = 12;: } return b; } Je mets le plus souvent les paramètres de fonctions (API Windows en particulier) sur plusieurs lignes. A priori un par ligne, mais c'est parfois limite : que faire avec ce genre de liste de paramètres (réalisé avec trucages) : NumErreur = lineOpen(hLineApp, dwDeviceID, &hLine, 0, 0, NULL, 0, 0, TapiVersion); ou NumErreur = lineOpen(hLineApp, dwDeviceID, &hLine, 0, 0, NULL, 0, 0, TapiVersion); Remarquez, ça n'empêchera pas le monde de tourner ...
|> [...] |> > 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. Effectivement.
Le monsieur m'avait précédemment dit qu'il préférait NULL à 0, alors moi, je lui dit que je préfère true à 1. Je suis puéril .... Une question : soit une boucle do....while, elle-même dans un try...catch, le tout dans un try ... __finally. Dans la boucle, des appels API, test de demande de fin de thread, gestion de la charge CPU, etc. Contrainte : identifier la première cause de fin de boucle, donc la première erreur. Sous Builder, c'est assez simple. Pour l'instant, je lance une exception une fois sorti de la boucle. Dans ces conditions, l'exception perd beaucoup de son intérêt. Le code se prête bien au lancement immédiat de l'exception (paramétrée du type d'erreur). J'ai testé sans souci, mais ce genre d'appli est par essence impossible à tester à 100%. Quelles sont les raisons objectives de me priver de cette méthode. Je précise qu'il ne paut pas y avoir de problème de libération.
Il fait un temps frais et splendide à Sète, le vie est belle, il était temps .... Cordialement, Pierre
"James Kanze" <kanze@alex.gabi-soft.fr> a écrit ...
|> "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.
[...]
Mais la même logique ferait mettre un espace et avant et après le
virgule, dans par exemple « f( a , b ) ».
En fait, ce n'est pas ce que j'utilise. Je chambrais (gentiment) la réponse
à la "schtroumpf grognon", en faisant la même chose.
J'ai des contraintes de lisibilité à l'impression, impression que je ne
maîtrise pas, donc de longueur de ligne, d'autant que j'utilise des noms
relativement long.
J'en arrive donc à des trucs un peu boiteux:
x = f(a, b);
Je réduit la tabulation à deux caractères. J'économise la première
indentation au niveau fonction :
int fonct(int a, int b)
{
a = 2 * b;
if(a == 0)
{
b = 12;:
}
return b;
}
Je mets le plus souvent les paramètres de fonctions (API Windows en
particulier) sur plusieurs lignes. A priori un par ligne, mais c'est parfois
limite : que faire avec ce genre de liste de paramètres (réalisé avec
trucages) :
NumErreur = lineOpen(hLineApp,
dwDeviceID,
&hLine,
0,
0,
NULL,
0,
0,
TapiVersion);
ou
NumErreur = lineOpen(hLineApp,
dwDeviceID,
&hLine,
0, 0, NULL, 0, 0,
TapiVersion);
Remarquez, ça n'empêchera pas le monde de tourner ...
|> [...]
|> > 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.
Effectivement.
Le monsieur m'avait précédemment dit qu'il préférait NULL à 0, alors moi, je
lui dit que je préfère true à 1. Je suis puéril ....
Une question : soit une boucle do....while, elle-même dans un try...catch,
le tout dans un try ... __finally. Dans la boucle, des appels API, test de
demande de fin de thread, gestion de la charge CPU, etc. Contrainte :
identifier la première cause de fin de boucle, donc la première erreur. Sous
Builder, c'est assez simple. Pour l'instant, je lance une exception une fois
sorti de la boucle. Dans ces conditions, l'exception perd beaucoup de son
intérêt. Le code se prête bien au lancement immédiat de l'exception
(paramétrée du type d'erreur). J'ai testé sans souci, mais ce genre d'appli
est par essence impossible à tester à 100%. Quelles sont les raisons
objectives de me priver de cette méthode. Je précise qu'il ne paut pas y
avoir de problème de libération.
Il fait un temps frais et splendide à Sète, le vie est belle, il était temps
....
Cordialement,
Pierre
|> > if(a == c) |> Vous ne préfèreriez pas : |> if ( a == c ) |> ? ;-)
C'est ce que j'utilise, moi aussi. [...]
Mais la même logique ferait mettre un espace et avant et après le virgule, dans par exemple « f( a , b ) ». En fait, ce n'est pas ce que j'utilise. Je chambrais (gentiment) la réponse
à la "schtroumpf grognon", en faisant la même chose. J'ai des contraintes de lisibilité à l'impression, impression que je ne maîtrise pas, donc de longueur de ligne, d'autant que j'utilise des noms relativement long. J'en arrive donc à des trucs un peu boiteux: x = f(a, b); Je réduit la tabulation à deux caractères. J'économise la première indentation au niveau fonction : int fonct(int a, int b) { a = 2 * b; if(a == 0) { b = 12;: } return b; } Je mets le plus souvent les paramètres de fonctions (API Windows en particulier) sur plusieurs lignes. A priori un par ligne, mais c'est parfois limite : que faire avec ce genre de liste de paramètres (réalisé avec trucages) : NumErreur = lineOpen(hLineApp, dwDeviceID, &hLine, 0, 0, NULL, 0, 0, TapiVersion); ou NumErreur = lineOpen(hLineApp, dwDeviceID, &hLine, 0, 0, NULL, 0, 0, TapiVersion); Remarquez, ça n'empêchera pas le monde de tourner ...
|> [...] |> > 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. Effectivement.
Le monsieur m'avait précédemment dit qu'il préférait NULL à 0, alors moi, je lui dit que je préfère true à 1. Je suis puéril .... Une question : soit une boucle do....while, elle-même dans un try...catch, le tout dans un try ... __finally. Dans la boucle, des appels API, test de demande de fin de thread, gestion de la charge CPU, etc. Contrainte : identifier la première cause de fin de boucle, donc la première erreur. Sous Builder, c'est assez simple. Pour l'instant, je lance une exception une fois sorti de la boucle. Dans ces conditions, l'exception perd beaucoup de son intérêt. Le code se prête bien au lancement immédiat de l'exception (paramétrée du type d'erreur). J'ai testé sans souci, mais ce genre d'appli est par essence impossible à tester à 100%. Quelles sont les raisons objectives de me priver de cette méthode. Je précise qu'il ne paut pas y avoir de problème de libération.
Il fait un temps frais et splendide à Sète, le vie est belle, il était temps .... Cordialement, Pierre
James Kanze
"Michel Michaud" writes:
|> 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.
NULL fait partie du langage.
-- 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" <mm@gdzid.com> writes:
|> 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.
NULL fait partie du langage.
--
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
|> 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.
NULL fait partie du langage.
-- 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
"Michel Michaud" writes:
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.
NULL fait partie du langage.
Je n'en doute nullement, mais c'est une macro qui est interprété différemment de ce qu'elle est, par nombre de personnes, ce qui ressemble à ton « prêter à la confusion à la longue ». Après tout, le langage est ce qu'il est : 0 ou NULL, ça choisit f(int) et non pas f(int*).
Je ne voulais surtout pas repartir cette discussion sur NULL vs 0... (Tu as manqué mon :-) ?)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:86ekvg26a3.fsf@alex.gabi-soft.fr, James
"Michel Michaud" <mm@gdzid.com> writes:
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.
NULL fait partie du langage.
Je n'en doute nullement, mais c'est une macro qui est interprété
différemment de ce qu'elle est, par nombre de personnes, ce qui
ressemble à ton « prêter à la confusion à la longue ». Après tout,
le langage est ce qu'il est : 0 ou NULL, ça choisit f(int) et non
pas f(int*).
Je ne voulais surtout pas repartir cette discussion sur NULL vs
0... (Tu as manqué mon :-) ?)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
(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.
NULL fait partie du langage.
Je n'en doute nullement, mais c'est une macro qui est interprété différemment de ce qu'elle est, par nombre de personnes, ce qui ressemble à ton « prêter à la confusion à la longue ». Après tout, le langage est ce qu'il est : 0 ou NULL, ça choisit f(int) et non pas f(int*).
Je ne voulais surtout pas repartir cette discussion sur NULL vs 0... (Tu as manqué mon :-) ?)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
kanze
"Michel Michaud" wrote in message news:<rHKAb.1647$...
Dans news:, James
"Michel Michaud" writes:
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.
NULL fait partie du langage.
Je n'en doute nullement, mais c'est une macro qui est interprété différemment de ce qu'elle est, par nombre de personnes, ce qui ressemble à ton « prêter à la confusion à la longue ». Après tout, le langage est ce qu'il est : 0 ou NULL, ça choisit f(int) et non pas f(int*).
Je ne voulais surtout pas repartir cette discussion sur NULL vs 0... (Tu as manqué mon :-) ?)
C'est pourquoi je me suis pas lancer à discuter s'il faut utiliser NULL ou s'il faut utiliser 0 -- malheureusement, ni l'un ni l'autre n'est vraiment satisfaisant, et celui qu'on préfère dépendra sans doute de son style de programmation (parmi d'autres choses).
Tout ce que je voulais dire, c'est qu'utiliser NULL n'est pas changer le langage au moyen des macros, parce que NULL fait partie du langage. Pour la reste, c'est un peu une question de style (ou des priorités, ou de je ne sais pas quoi).
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<rHKAb.1647$3y1.225610@news20.bellglobal.com>...
Dans news:86ekvg26a3.fsf@alex.gabi-soft.fr, James
"Michel Michaud" <mm@gdzid.com> writes:
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.
NULL fait partie du langage.
Je n'en doute nullement, mais c'est une macro qui est interprété
différemment de ce qu'elle est, par nombre de personnes, ce qui
ressemble à ton « prêter à la confusion à la longue ». Après tout, le
langage est ce qu'il est : 0 ou NULL, ça choisit f(int) et non pas
f(int*).
Je ne voulais surtout pas repartir cette discussion sur NULL vs 0...
(Tu as manqué mon :-) ?)
C'est pourquoi je me suis pas lancer à discuter s'il faut utiliser NULL
ou s'il faut utiliser 0 -- malheureusement, ni l'un ni l'autre n'est
vraiment satisfaisant, et celui qu'on préfère dépendra sans doute de son
style de programmation (parmi d'autres choses).
Tout ce que je voulais dire, c'est qu'utiliser NULL n'est pas changer le
langage au moyen des macros, parce que NULL fait partie du langage. Pour
la reste, c'est un peu une question de style (ou des priorités, ou de je
ne sais pas quoi).
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Michel Michaud" wrote in message news:<rHKAb.1647$...
Dans news:, James
"Michel Michaud" writes:
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.
NULL fait partie du langage.
Je n'en doute nullement, mais c'est une macro qui est interprété différemment de ce qu'elle est, par nombre de personnes, ce qui ressemble à ton « prêter à la confusion à la longue ». Après tout, le langage est ce qu'il est : 0 ou NULL, ça choisit f(int) et non pas f(int*).
Je ne voulais surtout pas repartir cette discussion sur NULL vs 0... (Tu as manqué mon :-) ?)
C'est pourquoi je me suis pas lancer à discuter s'il faut utiliser NULL ou s'il faut utiliser 0 -- malheureusement, ni l'un ni l'autre n'est vraiment satisfaisant, et celui qu'on préfère dépendra sans doute de son style de programmation (parmi d'autres choses).
Tout ce que je voulais dire, c'est qu'utiliser NULL n'est pas changer le langage au moyen des macros, parce que NULL fait partie du langage. Pour la reste, c'est un peu une question de style (ou des priorités, ou de je ne sais pas quoi).
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
