cast dans un template

Bonjour

J'ai le code suivant

Code:

---

1 2 3 4 5 6

template <Scalar> void class<Scalar>::fonction(Scalar s) { if(s == 0) etc... }

---

Ma question est faut-il que je fasse un cast de ce type :

Code:

---

s == static_cast<Scalar>(0.0f)

---

Actuellement mon template peut être instancier avec float ou double mais je compte plus tard l'utiliser une vrai class.

Je me pose aussi la même question pour :

Code:

---

1 2 3

Scalar s(0); //ou Scalar s(static_cast<Scalar>(0.0f));

---

J'aurais tendance à écrire :

Code:

---

if (s == Scalar())

---

Dans mes souvenirs, la valeur par défaut ainsi obtenue est le zéro du type.

Pourquoi je n'y avais pas penser plus tôt.

En faites j'avais un doute sur le fait suivant :

Code:

---

1 2 3

float f = float(); // f == 0.0f // et double d = double(); // d == 0.0

---

Mais, est-ce que cela pose des problèmes sur le constructeur ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

// header template <Scalar> class maClass { maClass(Scalar s = Scalar()); };   // code template <Scalar> maClass<Scalar>::maClass(Scalar s) { ... }

---

Par contre dans mon cas, je n'aurai pas que 0 mais aussi 1 dans le constructeur.
Dans ce cas, suis-je obligé d'utiliser static_cast<Scalar>(1.0f) ? A moins que Scalar(1.0f) ne suffise ?

1.0f ou 1.0 ou encore 1
Il y a forcement une différence au niveau temps d'exécution.
Je recherche aussi le maximum de performance dans la plupart des cas.

Si tu as un doute, au pire des cas, il y a :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

template <typename T> struct mon_trait { static T un() { return static_cast<T>(1); } };   template <> struct mon_trait<float> { static float un() { return 1.0f; } } ...pareil pour les autres.... Scalar un = mon_trait<scalar>::un();

---

Sinon, il faut voir comment les compilos implémenteraient le static_cast<> qui est connu à la compilation.
J'avoue ne jamais m'être posé la question. Fais des benchs. Vois le code assembleur généré avec tes compilos.

Par contre attention avec les tests de nullité, l'opérateur == ne marchera pas bien avec les flottants (à cause de l'imprécision). Je te conseillerais un truc de ce genre :

Code:

---

1 2 3 4 5 6

template <Scalar> void class<Scalar>::fonction(Scalar s) { if (std::abs(s) <= std::numeric_limits<Scalar>::epsilon()) // au lieu de "s == 0" etc... }

---

Par contre si tu recherches un maximum de performances, il te faudra peut-être faire un poil plus compliqué pour ne pas te trimballer l'abs et l'espilon sur les entiers.

Merci pour vos réponses.

J'avais déjà essayé avec le code assembleur, mais comme mes connaissances sont un peu limitées j'ai abandonné.

La finalité c'est de pouvoir disposer des templates suivants :

Vector2D
Vector3D
Vector4D
Quaternion <-- toujours en développement
Matrix3x3
Matrix4x4

Et de pourvoir les utiliser indifféremment avec des float, des double ou une class utilisant le SSE.

Quand j'aurai fini tous ça, je mettrais sûrement à disposition les sources.

Si tu veux de l'excessivement performant, boost et blitz++ sont tes amis.

Boost ne correspond pas à ce que je recherche.

Et pour blitz++... le site marche, temps pis.

Je recherche la rapidité, par forcement la précision absolue.

Par exemple, dans un jeu comme Doom 3. Je doute que les fonctions sinus et cosinus soit très précise. Ca sert même à rien. Par exemple, cela change rien au jeux si on n'a pas une précision à 10E-5 degrés sur les rotations du joueur.

Comme quoi la rapidité dépend beaucoup du domaine d'application !

Vu que tu vas faire des multiplications, en quoi boost::uBlas ne correspond pas ?

La précision à 10e-5, c'est pour les inversions que l'on en parle. La précision pour une multiplication restera la même. En revanche, tes classes faites depuis 0 ne te permettront pas d'être aussi expressif que boost/blitz++ (marche très bien) tout en ayant les mêmes peformances qu'eux -- sauf si tu as plusieurs mois à perdre.
Une matrice reste une matrice. La précision de tes tables de sinus et cosinus est un tout autre problème.

(boost a aussi des sous-projets pour octonions et quaternions)

Ceci dit, je me demande si le mieux n'est pas d'utiliser les primitives de la carte graphique pour ce genre de choses... C'est peut-etre ça que tu appelles SSE ?

Citation:

---

Envoyé par Luc Hermitte

Ceci dit, je me demande si le mieux n'est pas d'utiliser les primitives de la carte graphique pour ce genre de choses...

---

Tout à fait. D'où l'intérèt d'utiliser les fonctions de DirectX ou OpenGL et l'inutiliter de refaire ce qui a déjà été bien fait. Donc si ton projet est didactique, c'est bien, sinon il ne sert à rien.

Citation:

---

Ceci dit, je me demande si le mieux n'est pas d'utiliser les primitives de la carte graphique pour ce genre de choses...

---

Tout ce qui est calcul mathématique ne pourra jamais être géré en hardware. Avec DirectX est livrée une bibliothèque dédiée à ce genre de tâche (D3DX), qui contient toutes les classes nécessaires et qui est très performante (optimisations SSE / 3DNow!). Par contre avec OpenGL t'es chocolat, il te faut tout reprogrammer. J'ajouterais aussi que c'est le genre d'exerice à faire au moins une fois, ça permet de bien saisir ou se remettre en tête les notions mathématiques que tu utilises tout au long de ton jeu.

Citation:

---

Envoyé par Loulou24

Tout ce qui est calcul mathématique ne pourra jamais être géré en hardware. Avec DirectX est livrée une bibliothèque dédiée à ce genre de tâche (D3DX), qui contient toutes les classes nécessaires et qui est très performante (optimisations SSE / 3DNow!).

---

Tu m'étonne beaucoup... La carte graphique n'implémente donc pas en hard la multiplication de matrice, le derterminant, etc ?

Le hardware fait de la multiplication de matrices, mais seulement en interne et lorsqu'il en a besoin (à savoir pour transformer tes vertices du repère objet au repère écran). Si tu veux multiplier toi-même 2 matrices quelconques et récupérer le résultat, ta carte graphique ne te sera d'aucune aide. Elle n'est pas faite pour ça d'ailleurs. Quant aux déterminants et compagnie, là je ne crois même pas que la carte en ait besoin en interne, donc il ne faut même pas y penser.

Il est désormais possible d'effectuer des calculs sur la carte, à l'aide de programmes qu'on appelle des shaders, et qui peuvent désormais s'écrire avec un langage c-like. Ce langage est spécialisé en calculs matriciels, et est très à la mode pour implémenter ses propres techniques de rendu.

J'ai même entendu parler de gens qui utilisent une carte graphique pour effectuer des calculs sans rapport avec le graphique de manière plus performante qu'avec le processeur de base. Mais ça m'avais l'air un peu expérimental.

Par contre, je suis d'accord qu'il y a encore des choses à voir en dehors de la carte graphique.

Oui, avec les shaders on peut tout faire ou presque (j'ai vu des "blobs" 3D simulés en 2D avec un pixel shader, ou encore le jeu de la vie dont les iterations sont entierement calculées par le hardware), mais ce sera toujours pareil : les résultats suivront le flux qui va irrémédiablement vers l'écran. Tu n'auras jamais accès à ces résultats. Et puis 99% des calculs mathématiques restent tout de même dans le programme en lui même, d'où la necessité d'avoir une bonne bibliothèque pour gérer ça.

Effectivement le matériel graphique ne fait pas tous. A par l'affichage, il fait pas grand chose.

Par exemple, pour le calcul d'animation, on fait aussi des calculs mathématiques. Et là, la carte graphique ne sert pas à grand chose.

Mais maintenant, on peut faire des transformations évoluées grâce au vertex shader.

Le vertex shader est une bonne chose. On peut faire des calculs matriciels sans aucun problème. Par contre, ces calculs sont plutôt destinés à l'affichage.

On peut bien sur détourner ces calculs, mais les performances s'en ressentes.

Effectivement, j'utilise OpenGL. J'aurai pus utiliser les calculs matriciels de DirectX mais il n'y a pas toutes les fonctionnalités dont j'aurai besoin.

Quand j'aurai un moteur un peu correct, j'essayerais d'implémenter un système ragdoll. Certes ce n'est pas pour tout de suite mais j'anticipe maintenant avant de devoir y revenir plus tard.