Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Environnement Microsoft Pas de globales en win32

Pas de globales en win32

25 réponses
Avatar
Stephane Legras-Decussy
bonjour,

Me débrouillant maintenant pas mal en api win32, je souhaite passer
maintenant à des appli un peu serieuses. Comme il se doit, je veux bannir
de mon code les variables globales qu'on trouve toujours dans les exemples
win32.

mon problème est : où et comment déclarer les variables
qui seraient normalement dans le main() d'un prog console?

Je pense à les déclarer en static au début de la win proc comme
à l'air de la faire Petzold.

Est-ce bien la bonne méthode ?

--
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Florent Clairambault
> Il n'y a bien que dans les livres et les cours de facs qu'ont peu débiter
des trucs pareils. Évidemment, les variables globales sont à éviter au
possible, mais tout de même, de la à les proscrire !



C'est clair, voici une liste de quelques trucs bidons qu'on peut s'interdire
si on est un peu masochistes :
- Ne pas utiliser de variables globales
- Ne pas utiliser de goto
- Ne faire qu'un seul return par fonction et en fin de celle ci
- Ne pas faire des copies avec "=" de structures, mais copier tous les
champs de la structure
- Ne pas faire de boucles dans les fonctions recursives
- Ne pas utiliser les tests paresseux du C [ du genre if (tableau_taille >
10 && tableau[10] == 'C') { [...] } ]
- Ne pas fixer la valeur des variables à leur déclaration.

Bref, tous plein de trucs qui peuvent grandement simplifier et clarifier
votre code, mais qu'il faut soit disant éviter à tout prix. Pourquoi ? Parce
que c'est dangereux. A mon avis, dans ce cas la, il faut carrément éviter
l'allocation dynamique.

Florent
Avatar
AMcD®
Florent Clairambault wrote:

C'est clair, voici une liste de quelques trucs bidons qu'on peut
s'interdire si on est un peu masochistes :
- Ne pas utiliser de variables globales



Disons, à éviter, sauf dans des acs où cela simplifie grandement a vie.

- Ne pas utiliser de goto



Ça c'est absolument à éviter.

- Ne faire qu'un seul return par fonction et en fin de celle ci



Cela c'est n'importe quoi :). Ce n'est pas toujours possible.

- Ne pas faire des copies avec "=" de structures, mais copier tous les
champs de la structure



:)

- Ne pas faire de boucles dans les fonctions recursives



?

- Ne pas utiliser les tests paresseux du C [ du genre if
(tableau_taille > 10 && tableau[10] == 'C') { [...] } ]



Oui, ça c'est à éviter. Les valeurs numériques dans le code, c'est
inmaintennable.

- Ne pas fixer la valeur des variables à leur déclaration.



Cela dépend les cas.

Bref, tous plein de trucs qui peuvent grandement simplifier et
clarifier votre code, mais qu'il faut soit disant éviter à tout prix.
Pourquoi ? Parce que c'est dangereux. A mon avis, dans ce cas la, il
faut carrément éviter l'allocation dynamique.



Bof, il y a plein de chose à ne pas faire dans ta liste tout de même.
Valeurs numériques et goto, heu...

--
AMcD®

http://arnold.mcdonald.free.fr/
Avatar
Pierre Maurette
Florent Clairambault a écrit :
Il n'y a bien que dans les livres et les cours de facs qu'ont peu débiter
des trucs pareils. Évidemment, les variables globales sont à éviter au
possible, mais tout de même, de la à les proscrire !




C'est clair, voici une liste de quelques trucs bidons qu'on peut s'interdire
si on est un peu masochistes :
- Ne pas utiliser de variables globales
- Ne pas utiliser de goto
- Ne faire qu'un seul return par fonction et en fin de celle ci
- Ne pas faire des copies avec "=" de structures, mais copier tous les
champs de la structure
- Ne pas faire de boucles dans les fonctions recursives
- Ne pas utiliser les tests paresseux du C [ du genre if (tableau_taille >
10 && tableau[10] == 'C') { [...] } ]
- Ne pas fixer la valeur des variables à leur déclaration.

Bref, tous plein de trucs qui peuvent grandement simplifier et clarifier
votre code, mais qu'il faut soit disant éviter à tout prix. Pourquoi ? Parce
que c'est dangereux. A mon avis, dans ce cas la, il faut carrément éviter
l'allocation dynamique.


Ça fait plaisir de lire ça. C'eut été encore plus agréable dans fclc ;-)

Une question: je suis d'accord pour l'utilisation des tests paresseux,
mais j'avais cru comprendre que même les plus intégristes ne les
proscrivaient pas, bien au contraire. Qui les "interdit" ?

J'ajouterais à la liste la recherche religieuse de la portabilité
ISO/ANSI. A partir du momment où on a écrit:
#include <windows.h>

--
Pierre
Avatar
Vincent Burel
"AMcD®" wrote in message
news:42434f0c$0$11593$
Florent Clairambault wrote:

> C'est clair, voici une liste de quelques trucs bidons qu'on peut
> s'interdire si on est un peu masochistes :
> - Ne pas utiliser de variables globales

Disons, à éviter, sauf dans des acs où cela simplifie grandement a vie.

> - Ne pas utiliser de goto

Ça c'est absolument à éviter.



oulah, attention a ce que tu dis mon grand, y'a peut-être des types de
programmation ou le goto est inutile... On est d'accord que dans le cas
général, le goto peut s'éviter sans que cela pose de problème , ni en terme
d'optimization (un goto c'est beaucoup plus rapide qu'un appel de fonction)
ni en terme de clareté du code.

Cependant, y'a des cas, par exemple en traitement d'erreur, ou le goto est
très utile : typiquement quand une fonction à plusieurs sorties, Label
Good_Ending et Label Bad_Endind. Sortie dont l'effectivité est lié à une
multitude de conditions qu'on ne saurait formaliser sous une forme de bloc
IF. On trouve se genre de situation par exemple dans les fonction de
création / modification d'objet complexe, contenant beaucoup de potentialité
d'erreur.

Y'a aussi des cas d'algorithme ou le goto est le formalisme le plus simple
pour signifier un retour à un point particulier d'un processus.

Bref, GOTO fait partie intégrante du langage "C" , l'éviter, c'est
s'interdire un certain nombre de méthodologies dont l'efficacité est
éprouvée depuis la nuit des temps. GOTO est un simple saut (JMP), et je
m'étonne qu'un programmeur comme toi, adepte du bas niveau, conseille la non
utilisation absolue du goto.

VB
Avatar
Pierre Maurette
Vincent Burel a écrit :
"AMcD®" wrote in message
news:42434f0c$0$11593$

Florent Clairambault wrote:


C'est clair, voici une liste de quelques trucs bidons qu'on peut
s'interdire si on est un peu masochistes :
- Ne pas utiliser de variables globales



Disons, à éviter, sauf dans des acs où cela simplifie grandement a vie.


- Ne pas utiliser de goto



Ça c'est absolument à éviter.




oulah, attention a ce que tu dis mon grand, y'a peut-être des types de
programmation ou le goto est inutile... On est d'accord que dans le cas
général, le goto peut s'éviter sans que cela pose de problème , ni en terme
d'optimization (un goto c'est beaucoup plus rapide qu'un appel de fonction)
ni en terme de clareté du code.

Cependant, y'a des cas, par exemple en traitement d'erreur, ou le goto est
très utile : typiquement quand une fonction à plusieurs sorties, Label
Good_Ending et Label Bad_Endind. Sortie dont l'effectivité est lié à une
multitude de conditions qu'on ne saurait formaliser sous une forme de bloc
IF. On trouve se genre de situation par exemple dans les fonction de
création / modification d'objet complexe, contenant beaucoup de potentialité
d'erreur.

Y'a aussi des cas d'algorithme ou le goto est le formalisme le plus simple
pour signifier un retour à un point particulier d'un processus.

Bref, GOTO fait partie intégrante du langage "C" , l'éviter, c'est
s'interdire un certain nombre de méthodologies dont l'efficacité est
éprouvée depuis la nuit des temps. GOTO est un simple saut (JMP), et je
m'étonne qu'un programmeur comme toi, adepte du bas niveau, conseille la non
utilisation absolue du goto.


Pas du tout expert en C, j'ai eu l'occasion de faire il y a peu sur un
autre NG à peu près les mêmes remarques en moins magistral ;-), après
réflexions sur les raisons objectives de rejet du goto (et non GOTO
;-)). Je suis malheureusement influencé par cet opprobre, et je ne
l'utilise jamais, ou si peu. Mais en relisant du code, il m'arrive de le
regretter.
A mon avis, le rejet pédagogique du goto s'explique historiquement. Il
s'agissait de promouvoir à juste titre la programmation structurée, et
de briser des habitudes "nouillesques" issues d'autres langages. Il est
vrai que du code même bien écrit pour *certains* BASIC donne la nausée à
la relecture.
Je pense qu'il est effectivement souhaitable de limiter l'usage du goto,
mais également du break et du continue. Je trouve *personnellement* que
des goto assortis de bons noms de label est plus lisible que des break
et continue. Même en restant dans une algorithmique raisonnable (en
termes de niveau d'imbrication), le goto est plus souple et mieux
protégé de l'erreur idiote que le break :

for(i=0;i<10;i++)
for(j=0;j<10;j++)
{
/* traitement */
if(j==3) break;
}
printf("%dt%dn", i, j);


for(i=0;i<10;i++)
for(j=0;j<10;j++)
{
/* traitement */
if(j==3) goto TraitementFini;
}
TraitementFini:
printf("%dt%dn", i, j);

--
Pierre
Avatar
Bertrand Lenoir-Welter
>>- Ne pas utiliser de goto


Ça c'est absolument à éviter.

- Ne faire qu'un seul return par fonction et en fin de celle ci


Cela c'est n'importe quoi :). Ce n'est pas toujours possible.



Hum, ça me paraît un brin contradictoire. Le return au milieu d'une
fonction - que j'utilise assez souvent - ça ressemble beaucoup à un
faux-nez pour un goto, non ?

Un intégriste ajouterait que le break après un case est un cache-sexe
sur un goto honteux.

Bon, le seul endroit où j'utilise les goto, c'est dans les parsers. Je
reconnais que c'est pas obligatoire (rien ne l'est jamais après tout),
mais seulement pratique. Et ça, c'est une raison qui me suffit.
Avatar
Vincent Burel
"Pierre Maurette" wrote in message
news:4243bd6a$0$28299$
Vincent Burel a écrit :
> "AMcD®" wrote in message
> news:42434f0c$0$11593$
>
>>Florent Clairambault wrote:
>>
>>
>>>C'est clair, voici une liste de quelques trucs bidons qu'on peut
>>>s'interdire si on est un peu masochistes :
>>>- Ne pas utiliser de variables globales
>>
>>Disons, à éviter, sauf dans des acs où cela simplifie grandement a vie.
>>
>>
>>>- Ne pas utiliser de goto
>>
>>Ça c'est absolument à éviter.
>
>
> oulah, attention a ce que tu dis mon grand, y'a peut-être des types de
> programmation ou le goto est inutile... On est d'accord que dans le cas
> général, le goto peut s'éviter sans que cela pose de problème , ni en


terme
> d'optimization (un goto c'est beaucoup plus rapide qu'un appel de


fonction)
> ni en terme de clareté du code.
>
> Cependant, y'a des cas, par exemple en traitement d'erreur, ou le goto


est
> très utile : typiquement quand une fonction à plusieurs sorties, Label
> Good_Ending et Label Bad_Endind. Sortie dont l'effectivité est lié à une
> multitude de conditions qu'on ne saurait formaliser sous une forme de


bloc
> IF. On trouve se genre de situation par exemple dans les fonction de
> création / modification d'objet complexe, contenant beaucoup de


potentialité
> d'erreur.
>
> Y'a aussi des cas d'algorithme ou le goto est le formalisme le plus


simple
> pour signifier un retour à un point particulier d'un processus.
>
> Bref, GOTO fait partie intégrante du langage "C" , l'éviter, c'est
> s'interdire un certain nombre de méthodologies dont l'efficacité est
> éprouvée depuis la nuit des temps. GOTO est un simple saut (JMP), et je
> m'étonne qu'un programmeur comme toi, adepte du bas niveau, conseille la


non
> utilisation absolue du goto.




Pas du tout expert en C, j'ai eu l'occasion de faire il y a peu sur un
autre NG à peu près les mêmes remarques en moins magistral ;-), après
réflexions sur les raisons objectives de rejet du goto (et non GOTO
;-)). Je suis malheureusement influencé par cet opprobre, et je ne
l'utilise jamais, ou si peu. Mais en relisant du code, il m'arrive de le
regretter.
A mon avis, le rejet pédagogique du goto s'explique historiquement. Il
s'agissait de promouvoir à juste titre la programmation structurée, et
de briser des habitudes "nouillesques" issues d'autres langages. Il est
vrai que du code même bien écrit pour *certains* BASIC donne la nausée à
la relecture.
Je pense qu'il est effectivement souhaitable de limiter l'usage du goto,
mais également du break et du continue. Je trouve *personnellement* que
des goto assortis de bons noms de label est plus lisible que des break
et continue. Même en restant dans une algorithmique raisonnable (en
termes de niveau d'imbrication), le goto est plus souple et mieux
protégé de l'erreur idiote que le break :

for(i=0;i<10;i++)
for(j=0;j<10;j++)
{
/* traitement */
if(j==3) break;
}
printf("%dt%dn", i, j);


for(i=0;i<10;i++)
for(j=0;j<10;j++)
{
/* traitement */
if(j==3) goto TraitementFini;
}
TraitementFini:
printf("%dt%dn", i, j);



Effectivement, le goto est la meilleure méthode pour sortir d'un imbrication
de boucles, le break est source d'erreur, car c'est un saut relatif (au
bloc), pas absolue.

Historiquement, le rejet du goto est surement lié à une certaine pédagogie
comme vous dites. Dans les années 1990 je me rappelle qu'en FAC y'avait un
lobbying anti-goto très très fort, même en langage PASCAL.. La raison reste
flou, mais on peut remarquer aussi que l'université était (à l'époque en
tout cas) dans l'incapacité de proposer de réelle méthode de
programmation... ceci explique peut-être cela.

VB
Avatar
Dominique Vaufreydaz
Bonjour,

Effectivement, le goto est la meilleure méthode pour sortir d'un
imbrication de boucles, le break est source d'erreur, car c'est un
saut relatif (au bloc), pas absolue.



Exact.

Historiquement, le rejet du goto est surement lié à une certaine
pédagogie comme vous dites. Dans les années 1990 je me rappelle qu'en
FAC y'avait un lobbying anti-goto très très fort, même en langage
PASCAL.. La raison reste flou, mais on peut remarquer aussi que
l'université était (à l'époque en tout cas) dans l'incapacité de
proposer de réelle méthode de programmation... ceci explique
peut-être cela.



D'ailleurs les saut conditionnel ou non dans un code assembleur sont legion
dans un programme (un simple if est suffisant).

Enseignant a l'université, j'avais eu le malheur de dire que de mettre
un booleen qu'on testait en sortie (ou entree bref) de boucle pour sortir
d'une imbrication de 4 for etait une heresie a mes etudiants. On m'etait
tomber dessus en me disant que le goto c'etait pas propre, que si je
mettais un goto, c'est que je savais pas programmer. Alors hop, test
de perf sur un programme du genre :

bool Finir = false;
for( ... ; Finir == false && autres test; )
{
for( ... ; Finir == false && autres test; )
{
for( ... ; Finir == false && autres test; )
{
for( ... ; Finir == false && autres test; )
{
bla bla bla
if ( truc )
Finir = true;
}
}
}
}

et remplacement par

for( ... ; autres test; )
{
for( ... ; autres test; )
{
for( ... ; autres test; )
{
for( ... ; autres test; )
{
bla bla bla
if ( truc )
goto fin;
}
}
}
}
fin:

Juste pour prouver que j'avais raison... Ca fait un poil chier
quand meme !!

Bref, ca fait partie du domaine des certitudes de certains...
Tant pis pour eux ;-P

Doms.
Avatar
halfwolf
Salut,

"AMcD®" wrote in message news:<42434f0c$0$11593$...
> - Ne pas utiliser de goto

Ça c'est absolument à éviter.



Je trouve que ça peut avoir un aspect pratique dans le cas de la
gestion d'erreur en C. Ca permet d'avoir un seul endroit où on
désalloue proprement les ressources tout en évitant d'avoir des if
else imbriqués qui AMHA pèse sur la lisibilité du code principal (cas
où il n'y a pas d'erreur) de la fonction.
Perso je ne les utilise que dans ce cas.

> - Ne pas utiliser les tests paresseux du C [ du genre if
> (tableau_taille > 10 && tableau[10] == 'C') { [...] } ]

Oui, ça c'est à éviter. Les valeurs numériques dans le code, c'est
inmaintennable.



Je pense qu'il parlait plutôt du fait que tableau[10] == 'C' n'est pas
évalué si tableau_taille > 10 est faux.

HalfWolf
Avatar
AMcD®
Vincent Burel wrote:

oulah, attention a ce que tu dis mon grand, y'a peut-être des types de
programmation ou le goto est inutile... On est d'accord que dans le
cas général, le goto peut s'éviter sans que cela pose de problème ,
ni en terme d'optimization (un goto c'est beaucoup plus rapide qu'un
appel de fonction) ni en terme de clareté du code.



Bien évidemment ! Je re répond à toi ainsi qu'aux autres. Je me plaçais dans
le cadre général, il n'est pas à conseiller, par exemple à un débutant, de
pratiquer le coding dit spaghetti à grand coup de goto. Il est des cas, des
langages, où c'est difficile de s'en passer. Je parlais de "conseil". Quand
tu vois le code généralement pondu par les débutants, si en plus ils
gotoisaient, laisse tomber...


Bref, GOTO fait partie intégrante du langage "C" , l'éviter, c'est
s'interdire un certain nombre de méthodologies dont l'efficacité est
éprouvée depuis la nuit des temps. GOTO est un simple saut (JMP), et
je m'étonne qu'un programmeur comme toi, adepte du bas niveau,
conseille la non utilisation absolue du goto.



En assembleur, c'est sûr, se passer du jmp :-)... Je répète, je me plaçais
dans une optique didactique. Moi, je préfère apprendre à programmer
proprement, ensuite, on pass aux cas particuliers.

--
AMcD®

http://arnold.mcdonald.free.fr/
1 2 3