En général je pense que nous sommes d'accord : une variable globale non contrôlée, c'est mal. L'utilisation d'agents ou d'objets pour encapsuler la variable, ou bien limiter sa portée est évidemment une bonne pratique.
Plus spécifiquement, concernant errno, j'ai pas de doc sous la main (et la flemme, il est près de 5h du mat ici, et au lieu d'aller pioncer je te réponds... :-P) mais il me semble que dans les systèmes POSIX modernes, il y a une transformation de errno en mode TLS (thread-local storage), histoire que chaque thread ait sa copie. Évidemment, c'est pas standard pour le langage C (et pas sûr que C11 ait adopté la pratique), mais ça permet quand même d'éviter tout plein de trucs chiants.
L'important c'est donc de bien spécifier les modes d'accès aux variables globales : soit complètement globales « lexicalement », soit globales sous un espace de nom, de classe, etc., mais qui peuvent quand même risquer un accès concurrent. Dans un soft que je maintiens vaguement, j'ai rajouté tout un ensemble de variables globales qui servent principalement à l'initialisation au tout début du programme. Certes, ces variables se trouvent dans un espace de nom, mais bon, si tu utilises mon truc, tu vas vite arriver à faire un using namespace tartempion; parce que sinon ça devient vite relou : ces variables sont souvent lues (et uniquement lues) par les threads générés ensuite. Bref. Oui, il faudrait que je prenne le temps d'écrire des fonctions qui vont se charger d'accéder à la variable, et au minimum garantir qu'elle sera mise à jour « atomiquement ». Mais en pratique, le main vérifie quelle valeur donner à ces variables une fois pour toutes et tous les threads vont ensuite simplement les lire, et si par malheur un utilisateur les modifiait, ben, ça ne changerait sans doute pas grand chose (oui, ça pourrait provoquer des bugs, mais ce serait quelque chose d'assez aisé à traquer).
... Et oui, je m'invente des excuses pour ne pas mieux encapsuler mes variables globales (parce que c'est du code de recherche avec grosso-modo 5 utilisateurs qui savent ce qu'ils font).
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par lasher . En réponse au journal Comment être un développeur désirable. Évalué à 3.
En général je pense que nous sommes d'accord : une variable globale non contrôlée, c'est mal. L'utilisation d'agents ou d'objets pour encapsuler la variable, ou bien limiter sa portée est évidemment une bonne pratique.
Plus spécifiquement, concernant
errno, j'ai pas de doc sous la main (et la flemme, il est près de 5h du mat ici, et au lieu d'aller pioncer je te réponds... :-P) mais il me semble que dans les systèmes POSIX modernes, il y a une transformation deerrnoen mode TLS (thread-local storage), histoire que chaque thread ait sa copie. Évidemment, c'est pas standard pour le langage C (et pas sûr que C11 ait adopté la pratique), mais ça permet quand même d'éviter tout plein de trucs chiants.L'important c'est donc de bien spécifier les modes d'accès aux variables globales : soit complètement globales « lexicalement », soit globales sous un espace de nom, de classe, etc., mais qui peuvent quand même risquer un accès concurrent. Dans un soft que je maintiens vaguement, j'ai rajouté tout un ensemble de variables globales qui servent principalement à l'initialisation au tout début du programme. Certes, ces variables se trouvent dans un espace de nom, mais bon, si tu utilises mon truc, tu vas vite arriver à faire un
using namespace tartempion;parce que sinon ça devient vite relou : ces variables sont souvent lues (et uniquement lues) par les threads générés ensuite. Bref. Oui, il faudrait que je prenne le temps d'écrire des fonctions qui vont se charger d'accéder à la variable, et au minimum garantir qu'elle sera mise à jour « atomiquement ». Mais en pratique, lemainvérifie quelle valeur donner à ces variables une fois pour toutes et tous les threads vont ensuite simplement les lire, et si par malheur un utilisateur les modifiait, ben, ça ne changerait sans doute pas grand chose (oui, ça pourrait provoquer des bugs, mais ce serait quelque chose d'assez aisé à traquer).... Et oui, je m'invente des excuses pour ne pas mieux encapsuler mes variables globales (parce que c'est du code de recherche avec grosso-modo 5 utilisateurs qui savent ce qu'ils font).