Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Non, pas du tout...Envoyé par camboui
Par principe, tu dois te dire que tout ce qui apparait dans un fichier d'en-tête t'est accessible, point barre.
Si, pour une raison ou une autre, le développeur avait voulu limiter la connaissance que tu as d'une classe ou d'une fonction, il se serait arrangé pour ne pas te fournir le fichier d'en-tête dans lequel la classe est définie ou la fonction déclarée.
A méditer: La solution la plus simple est toujours la moins compliquée
Attention, je veux bien faire avec les deux "cercles" dont tu parles... Mais ça dépend surtout d'où. Aussi, j'estime que n'importe quel dev doit savoir lire une doc, donc que mon idiot-proofisation (oO) ne se limite qu'à cela dans la majeur partie des cas.
De l'autre côté, il parait évident que je ne vais pas fournir tous les ingrédients de ma recettes au gens qui n'en ont pas besoin, surtout s'il est dangereux de jouer avec.
Dans le monde de bambi, où tout le monde il est beau, tout le monde il est gentil, et où tous les développeurs ils sont compétents, oui...
Seulement, cette vision idyllique est contredite par les faits.
Dans les faits, combien de développeurs sont (je le pense réellement) incompétents ou ne lisent jamais la doc qui leur est fournie (ou du moins, jamais suffisamment en profondeur pour en comprendre tous les rouages)
Et, dans les faits, quel impact pourra avoir la seule ligne proche de
même si elle est mise en évidence par tous les moyens possibles et imaginables, si elle est noyée dans 150 pages de docattention cette classe est à usage interne uniquement, ne l'utilisez pas à des fins personnelles
Alors, oui, dans l'absolu, ce devrait être suffisant, mais, en pratique, s'il y a moyen d'apporter une sécurité supplémentaire, il peut sembler opportun d'en profiter
[EDIT]Et je vais même aller plus loin.
Même le développeur compétent qui a pris soin d'étudier la doc en profondeur ne va pas s'y référer de manière systématique pour écrire la moindre ligne de code.
Or, le temps passant, les souvenirs s'estompent ou s'altèrent toujours peu ou prou.
Même ce développeur peut donc, à un moment donné, en arriver à "vaguement se souvenir qu'il était question de telle classe" et vouloir l'utiliser, alors que, s'il en était effectivement question dans la doc, c'était pour clairement stipuler qu'il ne fallait pas s'en servir...
[/EDIT]
Sur ce point, nous sommes d'accordDe l'autre côté, il parait évident que je ne vais pas fournir tous les ingrédients de ma recettes au gens qui n'en ont pas besoin, surtout s'il est dangereux de jouer avec.
Sans parler du présent exemple, je pense que nivelé par le bas, c'est encouragé la médiocrité. Si un dev est trop bête pour lire une doc, alors oui il lui faut une bibliothèque idiot-proof. Mais c'est quand même bien dommage >< !Dans les faits, combien de développeurs sont (je le pense réellement) incompétents ou ne lisent jamais la doc qui leur est fournie (ou du moins, jamais suffisamment en profondeur pour en comprendre tous les rouages
pour les classes internes, je compare ca au dynamic_cast. Tout le monde comprend que utiliser dynamic_cast pour "tester" le type exact d'un objet et effectuer une action différente est "mal".
mais aller taper la classe "helper" interne, tout le monde semble me dire "si ca doit arriver il faut le laisser faire".
ben moi je dis non, c'est la meme chose;
j'ai l'impression de devenir de plus en plus integriste avec l'age... c'est mal ? :s
les gens ne sont pas idiots... mais pour le cas du mutex, meme si on conseille d'utiliser le ScopedMutexLock au lieu du Mutex directement, les gens qui lisent le fichier en-tête verront le mutex et pas forcément la classe helper (qui est plus bas). Et pis c'est aussi plus naturel d'utiliser un Mutex lorsqu'on est nouveau sur le projet.
Sans parler du présent exemple, je pense que nivelé par le bas, c'est encouragé la médiocrité. Si un dev est trop bête pour lire une doc, alors oui il lui faut une bibliothèque idiot-proof. Mais c'est quand même bien dommage >< !
Mais supposons qu'un SECOND programmeur, toujours très compétent, vienne dans une fonction, lise le code et décide de rajouter un "if(finished) return;" au milieu, sans voir le mutex. Soudainement tout se casse, et c'est pas faute d'avoir pas lu la doc ou d'avoir utilisé le mauvais outil;
80% des bugs sont des bugs "collectifs", ils apparaissent dans le code ecrit par A dans une partie obscur du logiciel, parce qu'un individu B a changé le code de C dans une partie complétement differente.
Par exemple chez nous, le logiciel s'est mis a planté dans du très vieux code car quelqu'un a retiré le support de weak_ptr sur une classe qui n'avait rien a voir.
Individuellement, chaque changement est justifié et personne n'a fait d'erreur, le bug est "collectif". et la personne qui a créé le bug n'est meme pas au courant... chacun est compétent.
et moi mon interet c'est de reduire les bugs "collectifs" aussi.
Ahh... je n'ai jamais dit que c'est pas dommage, et, crois moi bien, je regrette sincèrement et réellement cet état de fait...
Mais il faut être réaliste et accepter l'idée que le monde est imparfait par nature, autrement, nous serons non seulement déçus, mais, en plus, les erreurs "des autres" risquent de nous retomber dessus...
je suis d'accord avec toi...
à mon sens, il faut évaluer le point au delà duquel il ne faut pas laisser la classe helper disponibleHonnêtement, non... Pas à ce point de vue làj'ai l'impression de devenir de plus en plus integriste avec l'age... c'est mal ? :s
Mais cela mérite un bémol:
Tant que, malgré ton "intégrisme", tu n'en arrive pas à vouloir obliger n'importe qui (qui ne soit pas hiérarchiquement lié à toi, s'entend) à se rallier à tes idées, ce n'est pas un mal.
Le jour où tu décidera de descendre sur Paris pour aller "casser la gueule" à un type qui n'est pas de ton avis, cela le deviendra
Non (enfin, pas tous)...
Par contre, ils sont très facilement distraits, et leur distraction vaut pleinement idiotie
je suis 1 seul sur mon projet, donc je n'ai pas ce genre de probleme.
c'est pour cela que sur mon projet, les fichiers include sont cachés, les locks de mutex sont privés, l'opérateur & sur les entités est interdit (pour ne pas recuperer un pointeur), le dynamic_cast n'est pas autorisé (desactivé dans la compilation).
et encore, je l'ai laissé s'encrasser et la je vais nettoyer (à) sec
J'avoue que ça fais réfléchir... Mais est-il vraiment raisonnable de modifier du code que l'on ne connaît pas vraiment ? L'auteur n'aurait-il pas du signaler l'utilisation de mutex dans la classe ?
Je dois avouer cependant que je comprend ton point de vue.
Whoa, si j'avait su que ca ferait ce remue ménage ^^.
Personellement, tout est question d'appliquer la méthode d'encapsulation à un package. On pousse le génie logiciel au maximum où les blocs séparé ne sont pas les classes mais aussi des ensembles classes.
On inclue bien une classe dans une autre, pourquoi ne pouvont nous faire pareil en C++ avec un package qui n'est qu'une grosse classe simulée.
Au lieu de cela, nous avons un namespace qui cloisonne le code sans faire rien d'autre.
Pour ce qui est du passage au C# au C++, c'est une décision difficile mais il est difficile de faire un jeu qui soit en C# sur PS3, Psp, Ds, Wii, iPhone, Linux et Mac.
Même si pour les 4 derniers cas, Mono fait un résultat plutôt positif, ce n'est pas encore le saint graal.
L'utilisation même de C++ pour le gameplay devient tellement contraignante que les jeu, à défaut d'avoir un support officiel d'un langage pour les machines, en arrive à intégrer un moteur de script tel que LUA (Sims3, Wow, Natural Selection 2 etc...) ou Python (Eve Online ...).
Avouons-le (du moins j'en suis fier défenseur): une architecture logicielle et la programmation sont beaucoup plus fluide et agréable en C# qu'en C++.
Pourtant, je vais sur C++ car: il faut bien connaitre C++ pour penser à intégrer Mono ou Ruby comme moteur de script (ca j'ai réussi à le faire), il faut aussi se rendre à l'évidence que je ne peux me passer de C++ pour l'envergure de puissance que requiert mon projet actuel (beaucoup d'IA, Mono et encore moins Ruby ne feront l'affaire) et enfin je suis étudiant en jeu vidéo et la tendance actuelle n'est pas encore à utiliser un langage managé (hormis UnrealScript)... et les langages attendu du domaine comme D ou Go (des langages compilés et non managé) ne sont qu'embrayonnaire et les voir un jour sur console changerait sensiblement les méthodes de développement de jeu vidéo.
lorsque l'on est plusieurs a travailler sur le meme projet on est toujours amené a changer du code que l'on ne connait pas. tiens je le fais en ce moment meme. Je suis sur a 99% que je vais péter un truc, et sur a 90% que le truc que je vais péter n'est pas important (dans le sens ou on utilise pas vraiment la fonctionnalité que je vais casser).
mais rejeter la faute sur les autres n'avance a rien, trouver un coupable est contre-productif, fixer le problème permet de continuer mais a fait perdre du temps. Tandis que s'assurer que l'on utilise correctement l'outil permet de minimiser les erreurs et éventuellement de ne pas perdre de temps.
et ma technique pour ca c'est de demander au compilateur de tout vérifier (en tous cas c'est une des possibilités). ca revient a detecter l'erreur potentielle au moment ou on la commet.
et ca m'est arrivé recemment d'avoir cassé un truc par inadvertance, alors qu'il etait possible et meme "facile" de blinder le code pour que ca n'arrive pas. la logique a été que la personne, au lieu de blinder le code, a préféré aller au plus vite. du coup, j'ai cassé un truc et fait perdre 6h de taf a 30 personnes, et pris la faute sur moi, et le code moisi est toujours en place. Ce genre de comportement coute cher et rend les collègues un peu agressifs
[edit] c'etait en rapport avec le post de lavock
Je n'ai pas compris pourquoi on parlait de nivellement par le bas, il me semble au contraire que rendre son code difficile a mal utiliser est un bon moyen d'enseigner aux autres des techniques efficaces, non? Le code difficile a mal utiliser "guide" l'utilisateur vers du code correcte et si il a un minimum d'
J'essaie dans mon code (même perso) de "blinder" au maximum en isolant autant que possible, abusant d'assertions et en faisant en sorte qu'il soit quasimment impossible de se tromper avec l'interface des classes/systemes (je perds notamment pas mal de temps a travailler les interfaces, mais ça se réduit avec l'experience heureusement). J'ai bossé sur des projets seul et a plusieurs et a mon sens ça revient exactement au même : le moi d'aujourd'hui est différent du moi de demain et mieu vaut épargner des erreurs au moi de demain, le guider par l'erreur (en exploitant le compilo en fait -- vive le typage fort) et au pire les assertions au runtime.
C'est devenu obsessif depuis que j'ai vu a quel point ça me faisait gagner du temps, tout simplement parceque j'ai confiance en mon code (qui du coup devient rapidement "correct") parceque je sais qu'il plantera vite si ya un probleme. De fait il devient beaucoup plus facile d'avancer avec le code de quelqu'un (d'autre ou son soit passé) et d'avancer rapidement sur l'utilisation de ce code quand on sait qu'on sera prévenu de la moindre erreur (prévue).
Personellement pour expliquer cette manière de penser aux stagiaires et aux autres employés non-programmeurs, j'utilise l'image suivante :
Les programmeurs sont des aveugles qui tirent le projet (fouettés par des managers....non je plaisante).
Quand ils rencontrent un bug, ils viennent de se cogner contre un mur.
Les assertions sont nos mains, qui, si on prends la peine de les tendre vers là ou on va, nous préviennent quand on approche d'un mur, tout en entrant en contact avec.
Les testeurs (service QA) sont nos chiens d'aveugles. Ils nous guident pour comprendre nos erreurs et nous révèlent des problèmes plus difficiles a découvrir pour nous même qui tentons d'avancer sur un chemin invisible.
On est vraiment des aveugles: tout ce qu'on tente de faire relève de l'esprit et de la théorie jusqu'à ce qu'on essaie de lancer l'application pour se confronter a la réalité, parfois dure, mais avec laquelle il faut rentrer rapidement en contact avant de se la prendre au mauvais moment, sans prévenir.
Avec les habitude, l'experience, notre cecité est de moins en moins un handicap.
Voilà ça vaut ce que ça vaut comme image mais ça explique bien pourquoi faut organiser son code de manière plutot défensive.
Tu t'es peut être un peu trop habitué a la notion de package, elle n'est pas nécessaire dans le cas présent (comme dans d'autres languages d'ailleurs). Il y a des tas de methodes pour isoler le code tel que tu le décris en C++ sans besoin d'une notion de package. Surtout qu'il serait absurde de considérer un ensemble de fonctions, de classes et potentiellement d'instances comme "un objet" que sont les packages. Ca n'a tout simplement pas de sens en C++. Je me répète, mais je pense que tu comprendras mieu en comprenant les fondamentaux du pourquoi du comment. L'exemple du fait des include/cpp au lieu d'un fichier par classe est un bon point de départ.On inclue bien une classe dans une autre, pourquoi ne pouvont nous faire pareil en C++ avec un package qui n'est qu'une grosse classe simulée.
Au lieu de cela, nous avons un namespace qui cloisonne le code sans faire rien d'autre.
Au passage -- HS-- , Lua et Python sont, il me semble, toujours utilisés "par desssus" les "règles du jeu" pour les manipuler, les règles d'un jeu sont rarement implémentées dans les languages de scripts mais en C++ pour les raisons que tu évoques effectivement. Elles sont implémentées en c++ et peuvent être manipulées via du script (dans cet ordre de développement). Ce qui donne la flexibilité du script pour les modifications/parametrages, guides scenaristiques etc. alié a la puissance "brutale" du C++(ou C ou asm ou tout ensemble) pour l'execution de "l'essentiel".
Le fait est que, dans le monde de bambi, on ne devrait pas s'inquiéter de savoir si, oui ou non, nous avons affaire à un *bon* programmeur, ni si, oui ou non, il *risque* de faire une c...e avec notre code.
Or, si tu tente (quel qu'en soit le moyen) de faire de manière à ce que ton code résiste un tant soit peu aux programmeurs fatigués, distraits ou, simplement mauvais, tu autorise implicitement la médiocrité lorsqu'il s'agit de l'utiliser.
En cela, cela revient à considérer n'importe quel étranger à ton service ou à ton équipe de dev comme... le plus médiocre de tous ceux qui existent, y compris le meilleur d'entre nous.
Voilà pourquoi le terme "nivellement par le bas" est apparu dans la discussion
EDIT: j'ai parlé d'un code qui est destiné à être diffusé, mais le raisonnement est souvent appliqué au niveau des applications... Ne dit-on pas que la majorité des bugs trouvent leur origine entre la chaise et le clavier
Le fait est que, dans le monde de bambi, on ne devrait pas s'inquiéter de savoir si, oui ou non, nous avons affaire à un *bon* programmeur, ni si, oui ou non, il *risque* de faire une c...e avec notre code.
Or, si tu tente (quel qu'en soit le moyen) de faire de manière à ce que ton code résiste un tant soit peu aux programmeurs fatigués, distraits ou, simplement mauvais, tu autorise implicitement la médiocrité lorsqu'il s'agit de l'utiliser.
Ah ça part du principe que le dit programmeur n'est même pas un minimum curieux de savoir "pourquoi" ça "marche pas" (compilation ou runtime?) (le code lui indiquant déjà pourquoi).
Ce n'est plus un programmeur a ce niveau là, mais bon effectivement yen a pas mal dans le milieu malheureusement.
Oui, c'est un peu cela, effectivement...
Mais tu sais comme moi qu'il arrive, même aux meilleurs, de ne pas avoir "la tête à ce qu'il font", que ce soit parce qu'ils viennent d'enchainer 16 heures de boulot, dont 10 à débugger une grosse partie et qu'ils en ont "plein les boost" (heuu... "plein les boots"
Et puis, surtout, il faut regarder la réalité en face...
Ben en fait j'ai plutot tendance a considérer le code protégé comme un gain de temps pour tout le monde (sur le projet) plutot qu'autre chose, pour justement que quelqu'un qui soit pas dans un etat optimal de reflexion (ce qui au final reste relativement rare) soit quand même a même de faire son boulot sans que le tiens le "gène" de manière.
Salut,
Je pense qu'il y a 2 choses distinctes : faire du code blindé - ce qui me parait un minimum - et ne proposer que des outils en mousse. Pour reprendre l'exemple des mutex : oui dans le code que j'implémente, je pense qu'il vaut mieux utiliser des locker RAII sur les mutex. En revanche, si je développe une bibliothèque de mutex, ma bibliothèque exposera aussi bien les lockers RAII que les mutex en brut. A charge de l'utilisateur d'utiliser ce qui lui semble le plus pertinent pour son problème.
Ressources proposées par 3DArchi - Les fonctions virtuelles en C++ - Cours et tutoriels C++ - FAQ C++ - Forum C++.
pourquoi le mutex RAII est en mousse ?
(ou plutot, pourquoi ne fournir que cela est en mousse)
il me semble qu'on ne peut pas d'un coté promouvoir les smart ptr et de l'autre demander des fonctions de lock nues, c'est le meme type de ressource et conduit a des problemes similaires (leak, asymétrie)
tout comme les ouvertures/fermetures de fichiers par exemple.
Je suis d'accord que les mutex nus présentent des problèmes similaires aux pointeurs nus. Je suis d'accord pour dire qu'une bibliothèque de mutex devrait avoir des locker RAII pour faciliter l'utilisation de ses mutex. Je suis d'accord que dans la majorité des cas, ne pas utiliser un tel locker frôle avec la faute professionnelle. Je suis d'accord que la doc devrait recommander l'utilisation
de ces lockers. Mais je pense que la bibliothèque devrait permettre à l'utilisateur d'accéder uniquement aux mutex s'il ne veut pas du locker. Aux risques et périls de l'utilisateur. Je peux avoir mon propre locker répondant à mes propres politiques, par exemple. Ou alors, il n'y a pas de mutex, il n'y a pas de locker et l'api proposée par la bibliothèque a un niveau d'abstraction plus élevé.
Je préfère laisser la liberté à un utilisateur de faire un code qui plante mais je me dois de faire un code qui présente le moins de risque de planter. Pour le coup, je crois que ce sont simplement des points de vues (inconciliables ?).
Ressources proposées par 3DArchi - Les fonctions virtuelles en C++ - Cours et tutoriels C++ - FAQ C++ - Forum C++.
Répondre avec citation
Partager