Version imprimable
Les dépendances c'est Charybde, réinventer, c'est Scylla. Deux sources de problèmes à éviter. Je suis toujours mal à l'aise devant les opinions tellement opposées à l'une qu'elles ont l'air d'ignorer les dangers de l'autre.Citation:
Envoyé par Charlemagne
Jadis, le syndrome du NIH frappait tellement fort que j'afficher une opinion tranchée contre était sensé,... tant qu'on avait une action plus nuancée. Mais les choses évoluent et je me demande si le balancier ne va pas passer de l'autre côté.
Je reste encore excessivement méfiant à l'égard du syndrome du NIH.
Certes, à réinventer, quand on reste modeste, on peut apprendre énormément.
D'un autre côté, je constate que souvent on perd un temps fou à recoder des choses qui l'ont déjà été. Et surtout, qui ont déjà été validées. Au moins, cela permet de se concentrer sur la partie métier qui est déjà suffisament complexe pour mériter que l'on parte de briques de "haut" niveau.
J'ai tendance à réserver le "réinventer" aux exercices (qu'ils soient dirigés (TDs) et fassent parti de leçons, ou qu'ils soient personnels pour tester de nouvelles approches ou faire de la veille), et le "réutiliser" au boulot. Quitte à réutiliser le résultat de ces exos en dernier lieu.
PS: oui, ACE est vieux, mais depuis, je n'ai rien observé de sérieux qui révolutionne le boulot de Schmidt. De temps à autres des petites modernisations (boost), mais rien de trascendantal.
Franchement j'aurais mis dans l'ordre inverse. Je préfère récrire (dans un temps raisonnable bien sûr) ce dont j'ai besoin, plutôt que d'utiliser des dépendances.Citation:
Envoyé par Jean-Marc.Bourguet
Si le TLS des compilos n'existait pas, j'aurais programmé les classes moi même plutôt que que d'utiliser celui d'un tiers. J'y vois un avantage de plus de récrire (et non "réinventer") une fonctionnalité (pas du plagiat bien-sûr) : on applique la licence que l'on veut sur son code.
Par contre je ne sais pas ce qu'est le "NIH". c'est quoi?
De toute façon dans cette discussion on me conseillait soit d'utiliser une bibliothèque soit de le programmer moi même, mais personne pour me conseiller sur le TLS qui obtient pourtant largement ma préférence. Basta
NIH c'est l'équivalent anglosaxon de "réinventer la roue", littérallement :
"Not Invented Here"
Déf :
Le syndrome du Not Invented Here (littéralement « non inventé ici ») se rencontre couramment dans le domaine de l'industrie du logiciel. Elle s’emploie lorsque des entreprises ont redéveloppé quelque chose qui existait déjà.
Chose drôle (enfin si on veux, je tremble quand même pour que ce ne soit pas prémonitoire), c'est aussi le nom d'une série TV sur les alertes médicales en cas de propagation de virus.
Dans ce sens, c'est National Health Institute.Citation:
Envoyé par mchk0123
Je déterre ce fil, car je suis tombé sur diverses choses en rapport ces dernières semaines.
Sous Solaris, __thread n'existe que depuis la version 5.9 -- evidemment on est 5.8 au taf'. De plus, cela ne s'utilise pas avec les objets -- j'ai oublié si la limitation est aux PODs ou bien aux petits types. Donc pas de membre
possible. Les solutions d'ACE ou de STLSoft restent d'actualité en ce qui me concerne.Code:__thread std::streambuf m_stream;
Sinon, aujourd'hui je suis tombé sur le lien donné par Jean-Marc au sujet du mailing Post Oxford 2007 (sur fclc++), dedans on voit une référence aux TLS: document N2280.
Voilà.
Oui, j'avais remarqué assez vite cet inconvénient majeur de __thread.Code:De plus, cela ne s'utilise pas avec les objets
Dans mon cas il m'aurait fallu déclarer des vecteurs static dans diverses fonctions. J'ai par conséquent opté pour un pointeur auquel j'alloue de la mémoire.
Le problème c'est que mon programme n'a donc plus l'occasion de libérer cette mémoire par lui même (puisque qu'un pointeur C n'a pas de destructeur) et que je compte sur l'OS pour le faire une fois l'exécution finie.