par xTG » 02 sept. 2013, 19:10
par Sékiltoyai » 02 sept. 2013, 14:20
Ce n'est pas ce que j'ai dit, tu n'as pas besoin de savoir ce qui se cache derrière une interface si elle est bien conçue (ou si elle respecte au moins une partie de la petite dizaine de règles "d'usage"). Après on a pas de projets qui font des millions de LoC en Haskell (principalement par ce que le langage n'est pas assez verbeux pour y arriver), mais c'est faisable relativement automatiquement. Sauf que c'est pas à la lecture de la doc d'interface que tu sais si ce qu'il y a derrière est bien conçu... Donc pour éviter les ouvertures de rapport d'anomalie en série (surtout que ça prend du temps de trouver quelle équipe est fautive...) le plus simple reste de faire tes contrôles avant l'interface. Et donc tu as des chances de dupliquer du code entre le tien et celui de la couche que tu attaques.
Ce n'est pas ce que j'ai dit, tu n'as pas besoin de savoir ce qui se cache derrière une interface si elle est bien conçue (ou si elle respecte au moins une partie de la petite dizaine de règles "d'usage"). Après on a pas de projets qui font des millions de LoC en Haskell (principalement par ce que le langage n'est pas assez verbeux pour y arriver), mais c'est faisable relativement automatiquement.
par xTG » 02 sept. 2013, 13:11
par katagoto » 01 sept. 2013, 20:03
Je ne duplique jamais MES conditions. Tu parles bien pour des optiques petits projets... Mais as-tu déjà parlé optimisation sur des projets de plusieurs millions de ligne avec des couches et des interfaces développées par plusieurs équipes ? Vérifier ce que font les autres est une perte de rendement très inquiétante... On te file une doc d'une cinquantaine de page par interface, si tu la maitrise c'est déjà un énorme boulot, alors savoir le détail derrière relève de l'utopie ou de la folie furieuse... Le but n'est pas de passer le temps de dev de 10ans à 70ans...
, enfin si tu regarde anti-if campaign tu verra qu'on peut aisément virer 90% des conditions et cloisonner les 5% restantes dans des factories. <troll mode > Je découvre que les pourcentage c'est sur 95 et pas 100. Tous un monde qui s'écroule autour de moi, tant de certitude qui s'envole </troll>
, enfin si tu regarde anti-if campaign tu verra qu'on peut aisément virer 90% des conditions et cloisonner les 5% restantes dans des factories.
par moogli » 01 sept. 2013, 13:35
par xTG » 01 sept. 2013, 12:31
par katagoto » 01 sept. 2013, 11:33
par xTG » 31 août 2013, 23:43
par katagoto » 30 août 2013, 22:04
par xTG » 29 août 2013, 08:22
Code : Tout sélectionner
uint32* maFonction() { uint32* ptr; //.... if( ptr > 0xDFFF ) // ... // ... } uint32* monPtr = NULL; monPtr = maFonction(); if( monPtr > 0xDFFF ) // ....
par katagoto » 28 août 2013, 22:23
Tu veux dire un compilateur qui fait en sorte d'éviter les fuites mémoire à l'exécution ? Euh non... T'es un sacré troll tout de même... =D> Tu sembles reprocher qu'on ne cherche pas à comprendre tes réponses mais... L'inverse est fortement vrai aussi. La barrière de la langue est un sacré mur en fait non ?
Tu veux dire un compilateur qui fait en sorte d'éviter les fuites mémoire à l'exécution ?
par xTG » 28 août 2013, 15:25
kata, (...) tu es un des personnages de ce forum qui (...) crée de la polémique futile (autrement appelée trolling) C'est bizarre j'ai l'impression que ça ne s'applique pas qu'à lui...
kata, (...) tu es un des personnages de ce forum qui (...) crée de la polémique futile (autrement appelée trolling)
par Sékiltoyai » 28 août 2013, 14:07
par Nagol » 28 août 2013, 13:47
par xTG » 28 août 2013, 09:15
