Discussion :

[Yoxoman]

Bonjour à tous.

Je pense que cette question est très bête, mais apparemment quelque chose m'échappe.

Boost est une bibliothèque qui est censée étendre la bibliothèque standard. A ce titre, c'est une bibliothèque majoritairement composée de templates (complètement ?). Or, les templates ne se compilent pas, il me semble. Leur implémentation est nécessaire dans les en-têtes pour générer autant de code qu'il y a d'instanciation avec paramètres différents de ces mêmes templates.

Donc, si on ne compile pas les templates, qu'est-ce que c'est que toutes ces bibliothèques binaires, statiques et dynamiques (tous les libboost_filesystem_xxx.lib et consorts) qui ont mis 2 h 30 à être compilés sur ma machine ?


Merci.

[loufoque]

Il n'y a pas que des templates.
Quelques bibliothèques ont aussi des bibliothèques qu'il faut lier. De mémoire regex, filesystem, wave, thread, python, iostreams...

[Laurent Gomila]

Donc, si on ne compile pas les templates, qu'est-ce que c'est que toutes ces bibliothèques binaires, statiques et dynamiques (tous les libboost_filesystem_xxx.lib et consorts) qui ont mis 2 h 30 à être compilés sur ma machine ?

Ce sont les bibliothèques qui ne contiennent pas que du code template.

[Yoxoman]

Au temps pour moi. J'ai mal cherché dans la hierarchie des fichiers de Boost. Ma première impression fut que les fichiers cpp étaient tous des fichiers d'exemple... mais non.

Sinon, pouvez-vous confirmer que, sans l'utilisation du mot clé export (pas encore vraiment implémenté, me semble-t-il), la compilation d'un template ne sert à rien ?

Merci.

[Laurent Gomila]

Sinon, pouvez-vous confirmer que, sans l'utilisation du mot clé export (pas encore vraiment implémenté, me semble-t-il), la compilation d'un template ne sert à rien ?

C'est pas que ça ne sert à rien, c'est que c'est impossible (sans le mot-clé export, toujours). Tu peux seulement compiler des instanciations.

[Jean-Marc.Bourguet]

Sinon, pouvez-vous confirmer que, sans l'utilisation du mot clé export (pas encore vraiment implémenté, me semble-t-il), la compilation d'un template ne sert à rien ?

Même avec export, il n'y a pas de compilation des templates en C++. Export évite d'introduire des dépendances, mais pour qu'il soit vraiment utile, il faut qu'il soit employé avec un modèle d'instanciation itérée (autrement dit à l'édition de liens). Mais les compilateurs qui l'emploient ont besoin de la définition des templates au moment de leur instantiation. Petite pub personnelle: http://www.bourguet.org/cpp/export.pdf

[Yoxoman]

Au temps pour moi (encore). L'erreur venait ici du fait que g++ fait apparemment semblant de compiler un fichier template, probablement par consistance. Mais je viens de découvrir avec effroi qu'il ne bronche pas sur certaines erreurs (hors syntaxe) dans le code du template. Comme si le template était interprété comme un morceau vide de code, s'il est syntaxiquement correct.

Merci à tous pour vos remarques (et articles ) .

[fd]

Ce n'est pas avec effroi : c'est absolument normal. Les template sont compilé au point d'instanciation
C'est trés commode ça permet une grande souplesse

[Yoxoman]

Ce n'est pas avec effroi : c'est absolument normal. Les template sont compilé au point d'instanciation
C'est trés commode ça permet une grande souplesse

Oui, bien sûr. Je me suis un peu emmelé les pinceaux, mais tout est très logique.

Dans la série, je me demandais : comment on assure la confidentialité du code source avec les templates ?

[loufoque]

Tu fais pas, ou alors tu ne proposes que certaines instanciations.

[koala01]

Salut,

(...)
Dans la série, je me demandais : comment on assure la confidentialité du code source avec les templates ?

Les template ont cela de très bien qu'il permettent la "généricité" de ton code...

C'est principalement intéressant quand tu prévois de devoir coder quelque chose qui doit pouvoir s'appliquer à plusieurs types de données...

Autrement dit, plutot que de "perdre ton temps" à créer un classe pour gérer tes entier, une pour gérer tes string, une pour gérer ..., tu crées une classe template qui s'adaptera au type que tu définira plus loin selon tes besoins...

Seulement, la première question à se poser est: ai-je réellement besoin dans mon projet, de cette généricité?

En effet, l'utilisation des template revient quelque part à utiliser un canon pour chasser un moustique...

Par exemple, quel serait l'avantage de s'emm... à utiliser les template pour un arbre binaire, alors que l'on saurait dés le départ que, dans le projet en cours, il ne contiendrait que des données de type entier?

AMHA, ca a tendance à me rappeler cette histoire du fou qui se frappe avec un marteau sur la tete...

Et, de manière générale, on peut estimer que le recours systématique à certaines bibliotheques ou à certaines techniques existantes tombent sous le coup de la meme constation...

Je ne veux par mon intervention dénigrer aucune de ces bibliotheques ni aucune de ces techniques, je veux juste faire prendre conscience du fait qu'il est *parfois* plus intéressant de faire sans...

Pour en revenir à ta question réelle concernant la "confidentialité" de ton code source:

De manière générale, j'aurais tendance à estimer que à moins que ta classe modele ne traite d'un secret d'état ou que ta classe n'utilise un algorithme tout à fait révolutionnaire, il y a fort à parier que tu sois le seul etre précoccupé par le problème de sa "confidentialité"...

Par contre, il faut bien etre conscient du fait que, une fois ton application compilée, tu n'est nullement obligé de mettre le code source avec...

Tu peux donc parfaitement créer une classe modèle pour toi, et la réutiliser dans un autre projet, sans qu'elle n'apparaisse comme telle dans ton application (ou tes DLL) en cours de conception...

Si tu tiens absolument à garder le "secret de fabrication" de ta classe modèle, il te suffira de ne pas en fournir le code source ... ou alors, décider de te passer du mot clé template <typename> et travailler uniquement avec des classe ayant des membres fortement typés

[loufoque]

Par exemple, quel serait l'avantage de s'emm... à utiliser les template pour un arbre binaire, alors que l'on saurait dés le départ que, dans le projet en cours, il ne contiendrait que des données de type entier?

Parce que c'est une structure de données générique, le fait que ce soit des entiers ne change absolument rien, ce n'est même pas une spécialisation particulière.
D'autant plus que de l'écrire de façon générique est bien plus intéressant, cela permet d'éviter des problèmes ou on utilise des trucs trop spécifiques...

Seulement, la première question à se poser est: ai-je réellement besoin dans mon projet, de cette généricité?

Les templates sont à utiliser quand ils sont à utiliser.
L'extensibilité apparemment tu connais pas.

Enfin bon, tu sembles avoir des idées rigides suite à ton incompréhension de l'intérêt à la fois conceptuel et technique des templates, alors il me parait inutile de me fatiguer à faire de l'évangelisme.
En plus tu parles de "s'emmerder", alors que c'est au contraire tellement plus simple...

Si tu tiens absolument à garder le "secret de fabrication" de ta classe modèle, il te suffira de ne pas en fournir le code source ... ou alors, décider de te passer du mot clé template <typename> et travailler uniquement avec des classe ayant des membres fortement typés

Il semblerait que tu n'aies pas compris les "problèmes" liés à l'utilisation des templates.
Si tu veux distribuer une bibliothèque et que tu veux que l'utilisateur puisse utiliser à fond les templates que tu définis, il faut fournir la définition des templates.
Ce qui n'est pas forcément ce que tout le monde souhaite dans le modèle économique actuel (qui peut changer néanmoins ; après tout une licence suffit à protéger du code, pas besoin de le masquer). Vu la difficulté à implémenter export, et la plus grande difficulté encore à résoudre ce problème, je doute qu'il existe une autre solution que la pré-compilation des entêtes ou l'obfuscation.
Ensuite, si tu veux mettre ta bibliothèque sous forme de DLL (qui est donc chargée à l'execution), on ne peut tout simplement pas créer de nouvelles instances de templates, car cela n'est possible qu'à la compilation. Pour ça il faudrait un modèle similaire aux génériques de C# (ou alors aux génériques de Java, mais c'est moins intéressant - et c'est déjà plus au moins possible en fait).

[koala01]

Parce que c'est une structure de données générique, le fait que ce soit des entiers ne change absolument rien, ce n'est même pas une spécialisation particulière.

Je n'ai jamais dit le contraire...

D'autant plus que de l'écrire de façon générique est bien plus intéressant, cela permet d'éviter des problèmes ou on utilise des trucs trop spécifiques...

Mais il y a des cas, ou, justement, quelque chose de spécifique est nécessaire/utile...

Les templates sont à utiliser quand ils sont à utiliser.

C'est EXACTEMENT ce que je voulais dire...

Mais, avant de partir sur la généricité, il faut voir lors de la conception si l'on en a réellement besoin...

Je suis désolé, mais, faire de la généricité pour le plaisir n'apporte strictement rien...

Quand elle est utile, voire, car ca arrive, nécessaire, il faut l'utiliser, mais ce n'est pas *forcément* le cas

L'extensibilité apparemment tu connais pas.

Je connais tres bien, au contraire... mais, elle aussi, est-elle *forcément* utile ou nécessaire?

Encore une fois, il y a des cas dans lesquels on n'en a pas besoin, et ou quelque chose de spécifique conviendra peut-etre mieux...

Enfin bon, tu sembles avoir des idées rigides suite à ton incompréhension de l'intérêt à la fois conceptuel et technique des templates, alors il me parait inutile de me fatiguer à faire de l'évangelisme.
En plus tu parles de "s'emmerder", alors que c'est au contraire tellement plus simple...

J'ai tres bien compris, au contraire, le mécanisme d'utilisation des template, et je les utilises tres régulièrement...

Simplement, mon intervention avait pour but d'indiquer que, ainsi que je l'ai précisé dans ce message, il faut prendre le temps de réfléchir à l'utilité réelle de ce que l'on décide de mettre en oeuvre...

Bien sur que les template facilitent la vie, mais il n'empeche qu'il y a des cas où l'on peut faire sans...

Un simple exemple, si je veux une matrice carrée de 4*4, de taille fixe, il est quand meme beaucoup plus facile de partir sur un code du genre de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 double matrice[16];

que de commencer à vouloir *absolument* utiliser les méthodes fournies par la STL ou par boost

Bien sur que la STL et boost seront nécessaires dans certains cas, mais, dans d'autres, on peut très bien faire sans

Il ne sagit absolument pas de faire de l'évangélisme, il s'agit *surtout* de direde veiller à utiliser les choses à bon escient...

Il semblerait que tu n'aies pas compris les "problèmes" liés à l'utilisation des templates.
Si tu veux distribuer une bibliothèque et que tu veux que l'utilisateur puisse utiliser à fond les templates que tu définis, il faut fournir la définition des templates.

Ai-je écrit autre chose?

C'est vrai que j'aurais du préciser qu'à ce moment là, la bibliotheque fournie ne serait plus en mesure d'utiliser les templates...

Ce qui n'est pas forcément ce que tout le monde souhaite dans le modèle économique actuel (qui peut changer néanmoins ; après tout une licence suffit à protéger du code, pas besoin de le masquer).

Personnellement, j'ai tendance à garder en tete qu'on peut etre bon, mais qu'il y a toujours quelqu'un qui peut nous etre supérieur, ou qui peut avoir une meilleure idée, simplement parce qu'il aura changé de point de vue...

Je ne dis pas qu'il faut n'utiliser que la licence GNU/GPL, mais je dis que dans bien des cas, elle est profitable à tous, y compris à la personne qui a mis la bibliotheque au point... Mais ca, c'est un autre débat...

Bref, encore une fois, tu part en guerre sans avoir pris la peine de lire correctement ce qui a été écrit, et surtout, sans avoir pris la peine d'essayer de le comprendre...

[loufoque]

C'est qui foufoque ?

[Luc Hermitte]

La confidentialité d'un TAD classique qui résoud un problème informatique, on s'en fout un peu. Ces TADs et leurs algos sont super bien connus. Et chez nous, honnêtement, ce n'est pas une SSII qui va produire une nouvelle organisation de données révolutionnaire avec les algos qui vont bien. Faut pas réver.
Dans les types abstraits de données classiques, je mets toutes les listes, arbres, ... qu'on bouffait en cours d'algorithmie. Le genre de choses que je ne supporte pas de devoir implémenter plus d'une fois.
Et même quand on souffre du syndrôme NIH, les concurrents ont un peu tendance à ne pas s'intéresser à cette partie là, je pense. Bref, inutile d'être paranoiaque pour cela.

En revanche, la confidentialité d'un code métier peut s'avérer plus critique suivant ce que l'on vend.
Donc là, que livre-t-on qui puisse être visible ? Une API pour accéder à notre système! Si on livre l'intégralité des sources, peu importe que l'on cache quoique que ce soit ou non. Ce qui peut rester, c'est juste une API.

Une API, c'est quoi ?
Une interface ! Cela veut dire que si on isole correctement l'interface de l'implémentation, tout le code métier et les structures correspondantes peuvent être encapsulées (à la sauce OO ou non) comme il se doit.
Et dans l'interface d'accès au code métier, je trouve qu'il y assez rarement des fonctions paramétrées par le type.

Et même dans les cas les plus poussés où tout le code métier passe par des template -- si on se la joue mixin-layers (une application du CRTP), ou polices pour obtenir une pseudo Prog Orientée Aspects --, il est toujours possible de fournir une interface faisant la plus totale abstraction des détails d'implémentation. En général, c'est d'ailleurs un peu comme cela qu'il est préférable de procéder si on veut permettre des évolutions sans refactorer tout le code client à chaque modification.

Bref, tout cela me parait être un faux problème.