Variables globales, singleton ou paramètres ? - Page 2

et avec du http://en.wikipedia.org/wiki/Dependency_injection, ça donnerait quoi?

Exactement la même chose avec tout un tas d'implicite en bonus, du coup cf. ./15 ^^

Pour ajouter mon grain de sable, une fonction qui prends 15 paramètres, il y en a généralement 10 de trop*.
Si vraiment il faut passer X ou Y argument a chaque fonctions, il est préférable* de les conserver dans une structure/objet et de ne passer que cet objet et non la dizaine.

Ca reviens un peu a la classe "application" ou "jeu".

Sinon c'est aussi peut être un signe que le design de l'application n'est pas optimal, peut etre que les fonctions qui prennent l'objet/structure en question devrait faire partit du dit objet? Ou alors que ces fonctions fassent partit d'un objet avec un pointeur dans ses propriété vers l'objet passé en paramètre partout?

Le C++ à cette fâcheuse tendance a mélanger le fonctionnel et l'objet, la ou le C#, ObjC (pur) et Java sont bien plus orienté Objet et le fonctionnel a moins de place) et on a tendance a mélanger les deux, je ne pense pas que ca soit une bonne chose.

A moins de s'interfacer avec une lib existante, si on fait du C++ il faut proscrire au maximum la programmation type fonctionnelle, sinon autant faire du C* !

* ceci est bien sur mon avis, et je le partage avec moi meme!

flanker (./16) :

Zeph (./29878) :
moi j'aime bien ce qui est explicite y compris pour les dépendances

(et je déteste encore plus quand même un IDE est incapable de savoir d'où vient un élément)

Exemple de code recent ou j'ai essaye de rentrer et impossible (et meme avec un IDE potable): DCC et DisC deux exemple de code (en C++) a vomir, et quasi impossible a suivre dans y passer des nuits blanches, je n'ai, ni pour l'un ni pour l'autre encore reussi a trouver exactement comment il lis les fichiers en entrée. Un des deux me lit des valeurs fantaisistes dans les fichiers binaires je n'ai toujours pas trouvé pourquoi (pas la faute d'avoir utilisé un debugger la plongé dans le code se fait a travers 5 ou 6 couche dont implementation "perso" (et foireuse) des chaines d'un coté et du Qt (gerbatoire car pas utilisé pour faire de l'UI, juste remplacer des trucs simples a faire) de l'autre. (et ce sont les deux seul décompilateur compatible x86 16bit que j'ai trouvé et qui sont sensé fonctionner sur des OS non daté)

Si vous avez quelques heures a tuer aller regarder la classe "string" de disc ca vaux le détour... :/

(désolé je disgress pas mal la pour le coup sur DCC/DisC je voulais juste parler de l'imbrication et le coté mal pensé d'un projet peuvent le rendre incomprehensible)

Je ne vois pas le problème d'utiliser QtCore pour du non-graphique, je l'ai fait aussi plusieurs fois. Le problème, c'est plutôt qu'il y a aussi plein de code legacy utilisant des routines style C comme fopen au lieu de passer par des QIODevice.

Godzil > -fonctionnel +procédural

Sinon, pour rajouter une couche au débat… De manière générale le code est bien plus facile à tester quand une fonction/méthode ne dépend d'aucun paramètre extérieur à la dite fonction (ou le type déclarant la méthode).
C'est aussi assez cool de pouvoir se dire qu'on peut faire tourner deux instances de la même application dans un seul processus sans jamais avoir le moindre problème. Bien sûr, ça n'arrive en général jamais. (de devoir faire tourner N instances par process)

Par contre, ça n'exclut pas d'utiliser des variables globales dans les cas où ça se justifie…
Par exemple pour implémenter des singletons d'objets immutables / stateless qui ont de l'utilité partout dans le code. (C'est pas intéressant de prévoir de demander une référence d'objet en paramètre pour du code dont on sait déjà par avance qu'il ne changera jamais)
Par exemple parce qu'on estime qu'un objet/concept a réellement un rôle clé dans le programme et n'est voué qu'à exister de manière unique. (C'est par exemple le cas du ThreadPool en .NET. Ça ne viendrait à l'idée de personne d'en vouloir plusieurs. C'est pas fait pour, et ça marcherait mal)

Le problème se posera plutôt dans le cas d'un objet dont le contexte n'est pas neutre. (C'est en général le cas de tout ce qui a un état interne)
Typiquement, pour l'objet qui va servir à effectuer les opérations graphiques dans un jeu/autre, on sait bien qu'il n'y en aura jamais deux, car ça n'a aucun sens. Mais malgré tout, l'objet porte un état précis et a une interaction forte avec le reste du programme (même si cette interaction est surtout unidirectionnelle). Dans ce cas, ça peut vraiment poser problème si deux morceaux très éloignés du code référencent ce même objet, sans coordination entre l'un et l'autre. (Peut-être que le programme peut crasher à cause de ça ? Qui sait…)

En tout cas, je ne jugerai pas sur un petit projet. Variable globale ou pas, c'est surtout une question de discipline. Par contre sur un gros projet où plusieurs personnes doivent bosser, la question n'est pas à poser.

GoldenCrystal (./35) :
C'est par exemple le cas du ThreadPool en .NET. Ça ne viendrait à l'idée de personne d'en vouloir plusieurs.

Si tu as une machine avec un nombre énorme de cœurs, éventuellement même hétérogènes, tu peux vouloir des thread pools différents pour différents groupes de cœurs.