Vecteurs et matrices : couche intermédiaire propre entre mon programme et boost

Bonjour.

J'ai déjà posté plusieurs topic, mais comme je suis en train de démarrer un gros programme de calcul pour la physique je veux être certain que mes choix de départ seront les bons.

Mon code va massivement utiliser des vecteurs, des matrices, des tenseurs et certaines fonctions mathématiques. Pour tenter de rendre mon code le plus indépendant possible de librairies annexes j'avais pensé à faire la chose suivante :

Citation:

---

[lib externe 1] - \
[lib externe 2] - - -> [couche intermédiaire] -> [ mon programme ]
[lib externe 3] - /

---

Les lib externes étant par exemple boost, blitz++ etc...
Ce que j'appelle "couche intermédiaire" serait un ensemble de classes de base tels que "vector2" "vector3" "vector4" "vectorN" "matrix2" "matrix3" "matrix4" "matrixN" etc... utilisant les lib externes, mais permettant à mon programme de ne pas explicitement utiliser les lib externes.
Comme ça si dans un futur lointain, je dois changer de lib externe, il "suffira" de réimplémenter la couche intermédiaire et pas tout le programme.

Sauf que tout en faisant ça, je cherche à minimiser autant que faire se peut le temps à l'exécution (il faut donc éviter les surcouches inutiles durant le runtime).

Ma question est donc la suivante : quelle est la meilleure façon de faire cela (un exemple est le bienvenu) ? (note : je peux faire usage de la métaprogrammation)

Merci infiniment ;)

Salut,

Je ne suis pas persuadé qu'il s'agisse d'une bonne idée pour les librairies pérennes généralistes comme Boost ou de ton domaine comme blitz++. Ca va obfusquer ton code alors qu'elles sont réputées connues. Pour les autres, à coup de trait et de politique, ça devrait minimiser les coûts par rapport à une approche type DP Adaptateur.
Ensuite une bonne architecture logicielle séparant les différentes couches permet de minimiser la pénétration des bibliothèques uniquement là où elles sont vraiment nécessaires et éviter les contaminations.

Autant faire une couche d'abstraction quand il s'agit de gérer différents systèmes d’exploitation, c'est important. Autant faire une couche qui sépare la partie applicative et la partie IHM de manière à pouvoir changer de bibliothèque d'IHM, c'est important (même si là ce travaille ne se fait pas forcément en wrappant la bibliothèque d'IHM choisie, mais plutôt en identifiant et isolant quel code sera à jeter si on en change).

Autant dans ce cas, je suis bien plus dubitatif. Pourquoi ?
- Une couche d'abstraction a généralement un coût en terme de performances, ce qui pour la partie mathématique d'un programme faisant plein de calculs a un impact plus fort que d'ajouter par exemple un surcoût au parcours du disque dur.
- Là où une couche d'abstraction est quasi indispensable c'est quand plusieurs sous-couches vont (ou risquent d') être utilisées simultanément dans le produit. Je ne pense pas que ce soit le cas ici. Si tu décides de changer de bibliothèque mathématique, c'est plus un basculement à faire une bonne fois pour toute, pas besoin d'en faire coexister deux. De ce point de vue, la couche d'abstraction est alors de la sur-conception, qui va coûter plus cher que le temps qu'elle va faire gagner.

Citation:

---

Envoyé par JolyLoic

même si là ce travail ne se fait pas forcément en wrappant la bibliothèque d'IHM choisie, mais plutôt en identifiant et isolant quel code sera à jeter si on en change

---

C'est un écueil de beaucoup de wrapper qui sont supposés abstraire une bibliothèque : en général, la surcouche ne fait que reproduire quasi à l'identique l'interface de la bibliothèque, ce qui rend le changement de bibliothèque aussi laborieux qu'un changement de bibliothèque non wrapper. C'est aussi pour ça que je pense que c'est probablement une mauvaise idée.

Ok, merci beaucoup pour vos réponses, ça va surement m'éviter de faire de grosses erreurs de conception. Enfin avant toute chose, il faut que j'étudie si je peux restreindre l'utilisation des libs externes à certains fichiers où si j'en ai besoin au sein de tout mon programme.

Autre question : j'ai vu que boost::numeric::ublas était surtout optimisée pour les très gros vecteurs/matrices. Y-t-il des bibliothèques plus optimisées pour des matrices/vecteurs de taille<=10 (surtout<= 4 puisque c'est pour de la relativité générale) ? (je cherche des choses testées et éprouvées par une assez large communauté)

J'ai l'impression que boost.geometry serait plus adaptée, même si je ne la connais pas et ne peux donc la conseiller les yeux fermés.