Hello,

J'essaye d’implémenter des matrices de manière dynamique pour pouvoir les réutiliser ensuite dans OpenGL.
Et ça marche seulement je ne sais pas si c'est vraiment optimisé d'un point de vue mémoire(les doubles pointeurs c'est pas trop mon trip)

Vous en pensez quoi ?

http://paste.kde.org/p95btxjrl/pxq67t

Merci

C'est exactement ce qu'il faut faire.
Oublie pas de faire un free pour eviter les fuites de mémoire et tu peux aussi utiliser la fonction calloc a la place de malloc (l'avantage c'est que ça initialise directement ta matrice avec des 0 partout)

Normalement en C++ avec OpenGL tu peux utiliser GLM qui permet d'avoir une bonne manipulation des matrices

En fait, c'est probablement une mauvaise idee de faire tes matrices comme cela. La tu as des espace d'adressage different pour chaque ligne de la matrice. Il est probablement plus judicieux de stocker toute ta matrices dans une zone contigue de memoire. Ce qui va probablement miniser l'utilisation de la tlb et si tu as de la chance activer le prefetcher materiel.

De facon general, c'est probablement mieux de travailler sur ta matrice en recalculant les index. *(mat+w*i+j). Mais si tu veux vraiment une notation a base de [], tu peux garder un tableau de int* qui pointe au debut de la ligne qui va bien dans la zone de memoire contigue.

Tu veux probablement aussi derager du cote de __restrict__.

Sinon, ces choses la sont en generale bien plus facile a implementer en C++ a base de surcharge d'operateur et de fonction inline qui permet de garder l'abstraction que tu souhaites en laissant un moyen facil de changer le mode d'indexation.

je connais pas le C mais faudrait aussi définir les opérateurs non ? ( qu'on puisse faire mat1 + mat2, etc..)
sinon ce serait pas trop pratique à utiliser ...

C ne permet pas la redefinition d'operateur. Il faut faire des fonctions pour faire ca. Mais c'est possible en C++. C'ou l'interet d'utiliser C++ et pas C. Franchement pourquoi les gens utilisent encore C en 2014? (A part, pour les 3 systemes embarques qui n'ont pas de compilo C++ raisonable.)

Godrik :
Sur le net j'ai trouvé ça :

• • ****

You pick C when

you need portable assembler (which is what C is, really) for whatever reason,
your platform doesn't provide C++ (a C compiler is much easier to implement),
you need to interact with other languages that can only interact with C (usually the lowest common denominator on any platform) and your code consists of little more than the interface, not making it worth to lay a C interface over C++ code,
you hack in an Open Source project (many of which, for various reasons, stick to C),
you don't know C++.

In all other cases you should pick C++.

• • *

Je me demandais : y'a pas de domaines où il y a des programmes suffisamment simples pour être traités en C mais demandant une rapidité d'exécution vraiment, vraiment très grande ? De plus, dans les (rares) programmes parallèles où l'overhead est assez faible, le petit avantage de vitesse du C ne peut-il pas se transformer en net avantage ?

Oups je reviens j'avais complétement oublié mon topic

godrik -> J'y avais pensé justement mais c'est ce que je trouve le plus clair pour l'utilisation que j'ai à en faire.
Merci pour vos commentaires et sinon j'utilise pas le C++ car je le connais pas et utiliser du C pur m'oblige à faire des choses à la dur

Triple14 -> Le C n'est pas intrinsèquement plus rapide que le C++.

Triple14, c'est une bonne liste. Laisse moi la commenter:

"you need portable assembler (which is what C is, really) for whatever reason,"

En effet, si tu n'as besoin que d'ecrire des fonctions extrement courte, C++ pourrait ne pas ammener grand chose et t'amener des problemes de compilateurs plus tard.

"your platform doesn't provide C++ (a C compiler is much easier to implement),"

C'est vraiment l'argument majeur. Il y a des plateformes qui ont des compilateurs C++ merdique ou inexistant.

"you need to interact with other languages that can only interact with C (usually the lowest common denominator on any platform) and your code consists of little more than the interface, not making it worth to lay a C interface over C++ code,"

En fait, c'est quasiment le meme commentaire que le premier.

"you hack in an Open Source project (many of which, for various reasons, stick to C),"

Ca en effet c'est un argument majeur. Mais il s'applique a n'importe quel pair de language. "Pourquoi faire du brainf*ck et pas du lisp? Parceque le projet est ecrit en brainf*ck."

"you don't know C++."
Mais la a peu de chose pres, la bonne solution est de l'apprendre
Mais en effet, C++ est un langage BIEN plus complique.