IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Langage C++ Discussion :

Le mot clé "Internal" de C# en C++


Sujet :

Langage C++

  1. #21
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par camboui Voir le message
    Dois-je me remettre en cause ?
    Cesser de regarder le source des #include de librairies et me contenter de lire la doc ? C'est pourtant instructif/pédagogique de regarder les #include, surtout quand ce sont des templates...
    Non, pas du tout...

    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
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  2. #22
    Membre confirmé Avatar de Lavock
    Profil pro
    Inscrit en
    Octobre 2009
    Messages
    560
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 560
    Points : 633
    Points
    633
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Encore une fois, oui, mais non, parce que de toute manières, tu travaille toujours sur au moins deux cercles de survie...
    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.
    The mark of the immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one.
    --Wilhelm Stekel

  3. #23
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par Lavock Voir le message
    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.
    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
    attention cette classe est à usage interne uniquement, ne l'utilisez pas à des fins personnelles
    même si elle est mise en évidence par tous les moyens possibles et imaginables, si elle est noyée dans 150 pages de doc

    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]
    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.
    Sur ce point, nous sommes d'accord
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  4. #24
    Membre confirmé Avatar de Lavock
    Profil pro
    Inscrit en
    Octobre 2009
    Messages
    560
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 560
    Points : 633
    Points
    633
    Par défaut
    Citation Envoyé par koala01 Voir le message
    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.



    Citation Envoyé par koala01 Voir le message
    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
    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 >< !
    The mark of the immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one.
    --Wilhelm Stekel

  5. #25
    screetch
    Invité(e)
    Par défaut
    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

  6. #26
    screetch
    Invité(e)
    Par défaut
    Citation Envoyé par Lavock Voir le message





    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 >< !
    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.
    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.

  7. #27
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par Lavock Voir le message
    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 >< !
    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...
    Citation Envoyé par screetch Voir le message
    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;
    je suis d'accord avec toi...

    à mon sens, il faut évaluer le point au delà duquel il ne faut pas laisser la classe helper disponible
    j'ai l'impression de devenir de plus en plus integriste avec l'age... c'est mal ? :s
    Honnêtement, non... Pas à ce point de vue là

    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  8. #28
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par screetch Voir le message
    les gens ne sont pas idiots...
    Non (enfin, pas tous)...

    Par contre, ils sont très facilement distraits, et leur distraction vaut pleinement idiotie
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  9. #29
    screetch
    Invité(e)
    Par défaut
    Citation Envoyé par koala01 Voir le message
    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.
    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

  10. #30
    Membre confirmé Avatar de Lavock
    Profil pro
    Inscrit en
    Octobre 2009
    Messages
    560
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 560
    Points : 633
    Points
    633
    Par défaut
    Citation Envoyé par screetch Voir le message
    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.
    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;
    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.
    The mark of the immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one.
    --Wilhelm Stekel

  11. #31
    Membre du Club
    Profil pro
    Inscrit en
    Février 2007
    Messages
    73
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2007
    Messages : 73
    Points : 69
    Points
    69
    Par défaut
    Citation Envoyé par 3DArchi Voir le message
    C'est marrant. J'ai le sentiment que c'est, d'une certaine façon aller un peu contre le C++. Le langage n'a pas renoncé à son expressivité au profit de la sécurité. On peut faire de grosses bourdes avec le C++. Cela nécessite certains idioms pour se faciliter la vie (comme le RAII que tu montres). Mais d'un autre côté, tu peux t'en passer, ce qui dans certain cas permet aussi d'être plus efficace. Dans un sens, le C++ est un langage qui fait confiance au développeur. Alors que toi, visiblement non. Pourquoi pas, après tout. Mais personnellement, je préfère pouvoir me taper avec un marteau sur le doigt que ne d'avoir qu'un maillet en mousse pour enfoncer des clous.
    Mais c'est un peu HS.
    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.

  12. #32
    screetch
    Invité(e)
    Par défaut
    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

  13. #33
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    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.

    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.
    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.

    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".

  14. #34
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par Klaim Voir le message
    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<snip>
    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  15. #35
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    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.

  16. #36
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par Klaim Voir le message
    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"), qu'ils viennent de s'engueuler avec leur femme, ou qu'ils ont simplement passé une mauvaise nuit (liste qui n'a rien d'exhaustif).

    Et puis, surtout, il faut regarder la réalité en face...
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  17. #37
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    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.

  18. #38
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    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.

  19. #39
    screetch
    Invité(e)
    Par défaut
    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.

  20. #40
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    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 ?).

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 3 PremièrePremière 123 DernièreDernière

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo