Discussion :

[AnthoB]

Bonjour à vous,

Je recherche un peu d'aide pour développer mon projet de simulation électronique audio temps réel. Un processus assez complexe que je potasse maintenant depuis bientôt deux ans en solitaire et donc que je commence a bien maitrisé!

Je vais essayé de vous décrire le processus que je souhaite mettre en place, sans rentrer dans les détails car ça pourrait être long... Mais si ça ne vous parait pas clair n'hésitez pas à poser vos questions.

J'utilise Matlab pour créer un système d'équations différentielles non-linéaires automatiquement à partir d'un fichier qui décrit la structure d'un circuit électronique. La résolution de ces équations doit être effectuée pour chaque échantillon d'un flux audio. Pour effectuer cette étape en "temps-réel", j'utilise un SDK pour construire un logiciel tierce-partie que l'on peut utilisé dans un séquenceur audio-numérique.

J'ai établi une liste d'objets à codé en c++, mais je suis un perdu sur l'organisation de mon travail et la structure du projet...
J'ai appris le c++ en autodidacte et j'en ai retenu que les rudiments mais je suis bien déterminé à développer mon projet et mes compétences.
Comme mon projet est personnel mais très sérieux (je souhaiterai ensuite présenter mon prototype à des entreprises spécialisées pour savoir ce que ça vaut et ce que je peut en faire), je pense qu'il vaudrait mieux avoir un "plan" très précis de ce que je veux faire avant de commencé à coder. J'en tenté d'apprendre l'UML et de dessiner un diagramme de classe mais là je bloque vraiment et je voie que j'ai encore beaucoup à apprendre...

Je n'ai pas vraiment de question précise vu que ce n'est encore pas très clair dans ma tête. En gros je me demande si les "objets" que j'ai listé doivent être des classes, des enum, des structures ou des template...
Pourriez-vous m'aiguiller ou m'aider dans ma démarche?

[r0d]

Bonjour,

tout d'abord, ton approche est la bonne: tu as un prototype, tu as déjà des choses qui fonctionnent, et maintenant tu veux mettre de l'ordre dans tout ça et faire quelque chose de propre. C'est la bonne méthode.

Il faut bien comprendre que la conception est un processus qui consiste à découper les problèmes en petits sous-problèmes de façon à ce que, pris chacun de leur côté, ils soient plus faciles à résoudre. Il faut que tu voies ton programme comme un mur dans lequel chaque brique est une classe.

Chaque classe résous un problème. C'est donc très varié, donc une classe peut représenter des données ou en manipuler. Par exemple, on peut avoir une classe AudioBuffer qui va contenir un buffer de double ainsi que quelques valeurs utiles (bitrate, buffer_size, je_ne_sais_quoi_encore, ...). Cette classe contient des données. Mais on peut avoir des classes qui se contentent d'implémenter des algorithmes, comme par exemple une classe FadeOut, qui contiendra quelques données (par ex. duration, curve_type, etc.) mais aussi et surtout un algo qui va modifier les échantillons à chaque tick en fonction d'un algo qu'elle implémentera.

Tout ça pour dire que, à ta question:

En gros je me demande si les "objets" que j'ai listé doivent être des classes, des enum, des structures ou des template...

nous ne pouvons malheureusement pas y répondre comme ça, c'est plus compliqué. Tu auras certainement un peu de tout dans ton code, chaque type de donnée (enum, class, struct, etc.) répondra à un besoin précis. A noter que class et struct c'est en fait exactement la même chose (pas exactement mais pour l'instant tu peux considérer que si).

Avant de découper ton code et de dessiner un diagramme de classes, il faut que tu penses en terme de besoin. Il faut bien que tu identifies chaque besoin et que tu en fasses un ensemble (en java on pourrait appeler ça un package). Par exemple:
1. communication avec le driver audio
2. interface graphique
3. algorithmes de traitement audio
(je dis n'importe quoi, je ne connais pas assez ton programme pour faire un découpage précis).

Ensuite, pour chaque "package", tu va essayer d'affiner les besoin. Par exemple, prenons le 1. communication avec le driver audio:
a. récupération de la liste des devices audio disponibles
b. gestion de la communication avec un device donné
c. écriture dans le buffer
d. récupérer la synchro MIDI

A ce niveau là, on commence à voir apparaître des classes. Ici on en aura une qui va discuter avec le système pour récupérer les devices, une autre qui va permettre d'envoyer et de recevoir des infos du device, une autre qui permet de gérer le buffer audio et une dernière qui va gérer la synchro MIDI.
Encore une fois, c'est un exemple bidon.

Ensuite, tu vas commencer à implémenter le code, mais tu te rendras compte que, de temps en temps, c'est plus compliqué ou plus simple que ce que tu ne pensais. Il te faudra donc ajouter des classes ou en enlever. C'est normal, on ne peut pas tout prévoir dès le début.

Tu parles de template mais visiblement tu ne sais pas trop ce que c'est. En gros, les templates te permettent d'implémenter une classe sans savoir à l'avance la nature de ce que va manipuler cette classe. Je te conseilles, dans un premier temps, d'oublier ça, et d'y revenir plus tard si le besoin se présente.

Voilà, mon message est très vague, mais je ne peux pas faire mieux avec le peu de précisions que tu fournis.

Hope it helps.

[JolyLoic]

Un point important que je n'ai pas vu dans ta démarche : Regarder ce que tu peux récupérer de déjà fait. Il existe des bibliothèques sur tout un tas de sujets, et il est bien plus simple, efficace et performant d'en récupérer une de bonne qualité que de vouloir tout recoder toi même.

Par exemple, il y a des chances que dans ton logiciel, tu aies besoin de matrices, de fft, d'un solveur... : Quel(s) composant(s) vas-tu utiliser pour ça ?

[AnthoB]

Merci beaucoup pour vos réponses. Si j'ai écris ce post c'est bien parce que je débute, que je suis un peu perdu et que je ne veux pas perdre de temps à cause d'une mauvaise organisation. Excusez-moi si je suis un peu flou, le but est justement d'éclaircir tout cela.

Donc je commence par faire une liste de "besoins" plus détaillée comme rOd me le suggère :

1. communication entre le logiciel hôte et le plugin
2. traitement du signal
3. description du circuit électronique
4. modélisation des non-linéarité
5. calculs matriciels
6. interface utilisateur

1.a : gestion des entrées et sorties du logiciel hôte
1.b : récupération des contrôles sur le plugin

2.a : mise à jour des matrices en fonction des contrôles
2.b : traitement échantillon par échantillon

3.a : matrices fixes du circuit électronique
3.b : informations complémentaires

4.a : récupération de la liste des non-linéarité et de leurs parametres
4.b : calculs pour une diode
4.c : calculs pour une triode
4.d : calculs pour un transistor
4.e : calculs pour un aop
4.f : calculs pour un transformateur

5.a : multiplication de deux matrices
5.b : addition de deux matrices
5.c : transposition d'une matrice
5.d : inversion d'une matrice (de petite taille)

6.a : récupération des contrôles utilisateurs
6.b : affichage diagramme de bode, niveau entrée et sortie ...

En fait je ne suis pas du tout sûr de mon découpage parce que pour moi c'était dans la première liste qu’apparaissait les classes et dans la deuxième les fonctions...

JolyLoic, en effet je pourrait utiliser une bibliothèque existante pour le calcul matriciel. Mais comme tu peux le voir, les fonctions dont j'ai besoin sont très simples. De plus j'ai déjà écrit une classe pour des matrices de taille deux qui fonctionnait très bien. J'ai tenté de la modifier pour des matrices de tailles variables; mais elle ne fonctionne pas pour le moment. C'est aussi pour ça que je parlait de template... pensez-vous que ça pourrez résoudre ce problème?
Aussi j’aurais probablement besoin d'une bibliothèque pour effectuer du ré-échantillonnage. Mais pour dire vrai je n'ai pas réussi à utiliser les bibliothèques que j'ai trouvé... (je suis pas contre le lien vers un petit tuto, mais j'avoue n'avoir pas chercher très longtemps parceque jusque là je pouvait m'en passer).
Et en effet j'utilise un solveur dans mon programme mais celui que j'ai codé sous matlab me convient pour le moment...
Tu penses vraiment que je pourrait gagner en performance en utilisant des bibliothèques externes malgré que mes calculs soient les plus simples possibles?

D'ailleurs vous pouvez remarquer que je parle de solveur et de ré-échantillonnage alors qu'ils ne sont pas indiqués dans mon découpage... (situés en fait dans la section 2.b)
Quelle peut-être la prochaine étape dans le développement de mon projet?

[AnthoB]

J'ajoute quelques précisions sur les 6 sections de mon projet, si ça peut aider à comprendre :

1. communication entre le logiciel hôte et le plugin
J'utilise pour cela les exemples du SDK de Steinberg, donc pas vraiment de questions sur ce point.

2. traitement du signal
Elle doit fonctionner quelque soit le circuit associé. Elle utilisera le sur-échantillonnage, puis des opérations sur les matrices du circuit, dont un solveur type Newton, puis un sous-échantillonnage.

3. description d'un circuit électronique
En fait l'idée est de générer automatiquement des fichiers depuis matlab pour une utilisation en c++.

4. modélisation des non-linéarité
Il s'agit là d'une "librairie" de fonctions mathématiques assez simple (en utilisant donc la librairie de base).

5. calculs matriciels
Cette classe doit être suffisamment performante pour effectuer à la louche 500 000 opérations par seconde (pas d'inversion cela dit)... Je pense que ça peut être un bon exercice pour moi de la créer moi-même. Je pourrait utiliser une librairie externe par la suite pour plus de performances.

6. interface utilisateur
Je ne m'en occupe pas pour le moment car le logiciel hôte fournit une interface par défaut si le plugin n'en possède pas.

N'hésitez pas à me dire si vous pensez qu'il me manque des notions, ou que je devrait réviser.

[koala01]

Salut,

En fait, tu ne dois pas "trop t'inquiéter" de faire une distinction entre les classes et les fonctions.

Ce qui doit être clair dans ton esprit, c'est que tu vas travailler avec différents "concepts".

Certains concepts vont représenter des comportements plus ou moins observables et ce seront donc des fonctions.

D'autres concepts vont représenter des données qui seront utilisées par les comportements pour obtenir le résultat voulu, et ce seront donc des types (aussi bien des classes que des énumérations, des structures, des unions ou même des alias de type )

Certains types de données sont, parfois, en mesure d'exposer un ensemble de services qu'il sont capable de rendre.

Un service peut être soit le fait de répondre à une question ("quel âge as tu ") soit le fait de réagir à un ordre ("accélères") soit enfin le fait de transmettre une information ("dites à ma femme que...").

Pour rendre ces services, les types de données en question ont alors sans doute besoin d'informations -- représentées par d'autres types de donnée -- qu'ils pourront au choix soit utiliser pour leur demander de rendre un service exposé, soit utiliser comme "valeur" utile à l'exécution d'un comportement donné.

Tu vas donc régulièrement te retrouver durant ton développement face à de nouveaux "concepts", que tu devras introduire dans ton code sous la forme de comportement ou sous celle de type.

La forme que prendra le concept que tu veux modéliser dépendra du concept lui-même : Ce sera soit un comportement, soit un type.

La question au sujet des comportements est alors de savoir si c'est un "comportement général" qui peut être modélisé comme une fonction libre ou un "service rendu" (voir un comportement interne) par un type de donnée particulier, ce qui en ferait un candidat idéal à être une fonction membre du type de donnée en question.

Généralement, on va commencer par se faire une idée générale des différents concepts dont on a besoin en suivant une logique "descendante" dans le sens où l'on va partir d'un concept global ("je veux une application qui...") pour déterminer un certain nombre de concepts plus précis qui correspondent à peu près aux six listes que tu as dressées.

Mais ce n'est vraiment qu'une toute première passe, histoire de "dégrossir" un peu le travail, de se rendre compte de ce que représente les points de suspensions dans ma phrase .

Une fois que c'est fait, on se rend généralement compte qu'il existe une sorte de "hiérarchie" dans les différents concepts que l'on a dénombré car certains concepts s'appuient forcément sur d'autre concepts plus "bas niveau".

Et, l'un dans l'autre, on se rend compte que le fait d'avoir une interface graphique hyper évoluée ne servira sans doute à rien si l'on ne dispose pas des données que cette interface devra afficher

On va donc commencer par le concept qui semble "prioritaire", dont on ne peut se passer parce que c'est celui sur lequel tous les autres vont se baser (de manière directe ou indirecte).

On va donc suivre la même logique pour ce concept, à savoir : essayer de dresser la liste de tout ce qu'il implique, avant de passer au concept suivant.

Mais il n'est pas rare que l'on définisse un concept particulier en utilisant de nouveaux concepts qui devraient être, eux aussi, définis de manière plus précise.

Il faut donc à chaque fois revoir l'ordre de priorité dans lequel chaque concept devra être mis en oeuvre.

Généralement (mais bon, ce n'est pas forcément toujours le cas ), ce sera souvent l'un des concepts que l'explication donnée sur le concept "prioritaire" vient de mettre en évidence.

Et l'on continue comme cela jusqu'à ce que l'on se rende compte que l'on arrive à exprimer un concept qui se suffise à lui-même.

Une fois que tu es arrivé à un premier concept qui se suffit à lui-même, tu réévalue les priorités, et tu recommences le travail, jusqu'à arriver à un point qui soit réutilise un des concepts qui mène "en droite ligne" à un concept qui se suffit à lui même, soit te mène à la découverte d'un nouveau concept qui se suffit à lui-même.

Evidemment, une fois que tu découvres un concept qui se suffit à lui-même, tu peux décider de le placer dans tes différents diagrammes et, surtout, de l'implémenter.

Une fois que tu as plus d'un concept qui se suffit à lui-même, il est souvent intéressant de savoir s'il existe une relation entre eux.

Une fois que tu as défini (dans tes diagrammes, dans ton code) un concept qui se suffit à lui-même, tu peux envisager de "remonter" vers le concept qui l'utilise et voir s'il y a d'autres concepts qui seront nécessaires pour pouvoir définir ce concept "supérieur".

Par exemple, dans un jeu de plateau, une pièce sera représentée par la case où elle se trouve. Mais la case elle-même sera sans doute représentée par une coordonnée et la coordonnée est en relation directe avec la notion de déplacement qui, justement, se trouve être l'un des services que l'on est sans doute en droit d'attendre de la part de la pièce.

Le déplacement peut être représenté soit par la case de départ et la case d'arrivée, mais il est peut être plus intéressant de le représenter sous la forme de la coordonnée de la case de départ et par celle de la case d'arrivée.

Dans ce cas, une fois que tu as fourni l'implémentation de la coordonnée, tu peux choisir soit de fournir une implémentation pour le déplacement soit d'en fournir une pour la case. De toutes manières, l'autre suivra directement

Au final, tu dois commencer par ta réflexion de base, celle qui débroussaille le chemin à parcourir pour arriver à ton but,
puis tu prend par ordre de priorité chaque concept qui est apparu et tu rentre dans une boucle qui se décompose en:

1. réflexion
2. conception
3. réalisation
4. retour en (1) ou en (2) selon le cas

Et si, en cours de route, tu as une "idée de génie", hé bien, tu l'intègres dans ton cheminement de base avant de recommencer à réfléchir aux priorités pour t'attaquer à "ce qui est prioritaire" dans une boucle de réflexion -> conception->réalisation.

L'UML, c'est très bien, pour permettre la communication et la discussion.

Mais le diagramme de classes est, très certainement, parmi les derniers diagrammes que tu devras créer.

Les premiers seront sans doute les diagrammes diagrammes de "cas d'utilisation" (Use Case), car ils permettent de représente les "je veux que XXX puisse ...")

Suivra sans doute un diagramme de communication, qui permettra de représenter les échanges d'informations qui permettent à ton cas d'utilisation de fonctionner.

Et ce n'est au final que quand tu auras une idée bien précise de toutes les relations qui peuvent exister entre les différents éléments que tu pourras créer ton diagramme de classes.

Mais il faut garder deux choses à l'esprit lors de ta conception:

1. Il ne faut pas attendre de l'avoir finie avant de commencer la mise en oeuvre.
2. Tes diagrammes ne valent que s'ils restent simples.

La raison du (1) est que, si tu attends d'avoir fini ta conception, tu te retrouveras avec un dossier de 9421 pages dans lequel tu auras certes une conception finie (si tant est qu'il soit possible de la considérer comme telle), mais que tu ne sauras pas "par quel bout la prendre".

Tu as largement intérêt à te dire, à certains moments que "stop, là, je dois m'arrêter et m'occuper en priorité de (...)", quitte à mettre une note (sur ton diagramme, pourquoi pas ) indiquant "à concevoir une fois que (XXX) sera mis en oeuvre".

La raison du (2) est que tes différents diagrammes doivent, d'abord et avant tout, rester compréhensible pour celui qui les a devant les yeux. Autrement, ils n'ont aucun intérêt.

Rien ne t'empêche de créer un diagramme de classe qui reprend l'ensemble d'une hiérarchie de classes particulière.

Mais le but d'un tel diagramme est de se faire une idée globale de l'organisation de cette hiérarchie. Le seul nom de la classe suffit alors, et il n'y a absolument pas besoin d'en dire d'avantage.

Par contre, lorsque vient le moment d'implémenter une classe spécifique, tu peux sans doute indiquer quelle est (quelles sont, vu qu'on est en C++ ) sa (ses) classes mère(s) directe(s) et l'ensemble des éléments que ta classe manipule.

Mais, bien sur, ce ne sont là que les deux extrêmes, et il y a sans doute bon nombre de "niveaux de spécificités" entre les deux

En très gros, on pourrait dire que plus un diagramme (quel qu'il soit) est général, moins il doit comporter de détails.

Et, bien sur, plus un diagramme est spécifique, plus il devra être complet.

A l'inverse, plus un diagramme est général, plus tu devras "revenir dessus" pour le compléter en cours de développement

[r0d]

Je rajoute une petite considération technique, concernant les matrices. On voit que dans ton découpage, les matrices apparaissent souvent et à différents endroits:

3.a : matrices fixes du circuit électronique
5.a : multiplication de deux matrices
5.b : addition de deux matrices
5.c : transposition d'une matrice
5.d : inversion d'une matrice (de petite taille)

Une matrice contient des données et fournis des opérations. Ce sera donc clairement une classe. Si tu veux que ta matrice puisse manipuler des types différents, alors la solution c'est bien d'en faire une classe template.
Tu pourras trouver un exemple de matrice 2D template ici. Ce code est vieux, et je crois qu'il ne compile pas partout, mais dans l'idée il est correct et ça pourra te donner une idée de ce qu'il faut faire.

[JolyLoic]

Tu penses vraiment que je pourrait gagner en performance en utilisant des bibliothèques externes malgré que mes calculs soient les plus simples possibles?

Oui. Parce que par exemple, implémenté naïvement, un calcul de matrice comme A = B + C + D est très peu efficace (allocation de 2 matrices intermédiaires, 3 boucles d'affilée). Et même pour calculer la somme de deux matrices, une bonne bibliothèque utilisera les instructions du processeur qui permettent de calculer en un seul bloc la somme de plusieurs valeurs d'un coup. Certains compilateurs commence à implémenter des optimisations qui détectent ça dans certains cas, mais je pense qu'il reste pour l'instant plus sûr de faire confiance à une bibliothèque optimisée.

Et ensuite, en terme de facilité de notation, il y a des chances qu'une bibliothèque externe soit là aussi mieux polie...

Je ne suis pas trop dans le domaine, mais je crois que Eigen a bonne réputation : http://eigen.tuxfamily.org/index.php?title=Main_Page

[koala01]

Oui. Parce que par exemple, implémenté naïvement, un calcul de matrice comme A = B + C + D est très peu efficace (allocation de 2 matrices intermédiaires, 3 boucles d'affilée). Et même pour calculer la somme de deux matrices, une bonne bibliothèque utilisera les instructions du processeur qui permettent de calculer en un seul bloc la somme de plusieurs valeurs d'un coup. Certains compilateurs commence à implémenter des optimisations qui détectent ça dans certains cas, mais je pense qu'il reste pour l'instant plus sûr de faire confiance à une bibliothèque optimisée.

Et ensuite, en terme de facilité de notation, il y a des chances qu'une bibliothèque externe soit là aussi mieux polie...

En outre, il faut te dire que, de manière générale, c'est l'utilisation qui permet de évidence en avant les faiblesses du code.

Qu'il s'agisse d'une algorithme "encore optimisable", d'un cas qui n'aurait pas du arriver mais qui "arrive quand même quand on s'y prend de telle ou telle façon", d'un cas qui n'avait purement ou simplement pas été prévu, plus le code est utilisé (malmené :question) plus ses faiblesses ont de chance d’apparaître rapidement (et donc d'être corrigées rapidement)


tu peux te dire qu'une communauté de quelques dizaines utilisateurs mettra sans doute en évidence en un mois plus de problèmes que ceux que tu pourrais trouver par toi même en plusieurs années.

Enfin, cela te permet de resté d'avantage concentré sur ton objectif, plutôt que de "perdre du temps" à (mal) recréer des outils qui existent par ailleurs.

[AnthoB]

Ok, merci pour tous vos conseils.

Merci koala01 mais c'est pas encore bien tout clair dans ma tête...

On va donc commencer par le concept qui semble "prioritaire", dont on ne peut se passer parce que c'est celui sur lequel tous les autres vont se baser (de manière directe ou indirecte).

Dans mon cas, ce concept serait donc un type "instrument audio numérique". Pour réaliser cela j'utilise le dernier SDK de Steinberg. J'ai récemment compilé des exemples fournis et éplucher la documentation. Je commence a y voir plus clair entre mon concept général et la forme qu'il doit prendre.

Une fois que tu as plus d'un concept qui se suffit à lui-même, il est souvent intéressant de savoir s'il existe une relation entre eux.

Ok, mais du coup j'aimerai y voir plus clair dans les relations possibles entre ces concepts, comment les signifier dans les diagrammes et leurs implémentations en c++...
Et est-ce que tu pourrais me donner des exemples des diagrammes? (Use case, diagramme de communication et diagramme de classe)

Pour ce qui est du calcul matriciel, en fait j'ai déjà écris une classe à partir de pointeurs et d'opérateurs new et delete (donc sans <vector> contrairement à l'exemple que tu m'as donné) mais elle bug pour le moment... sans doute à cause d'une mauvaise gestion de la mémoire.
Je n'y tiens pas particulièrement à ma classe, mais je veux la faire fonctionner pour m'exercer.
En fait je me pose deux questions par rapport à l'utilisation de librairies...
Le SDK que j'utilise permet de compiler des applications pour mac et windows à partir des mêmes sources c++. Je ne me suis pas encore penché sur la compilation sous mac... Mais si j'utilise des librairies externe, fonctionneront-elles sur les deux systèmes?
La deuxième question concerne la licence. Si je finis par distribuer mon logiciel, payant ou gratuit, qu'elles seront les contraintes? (vous me répondrez surement que ça dépend des librairies...)

[koala01]

Ok, merci pour tous vos conseils.

Merci koala01 mais c'est pas encore bien tout clair dans ma tête...

Dans mon cas, ce concept serait donc un type "instrument audio numérique".

Hé bien non, ca, ce n'est pas forcément le concept prioritaire... C'est une partie seulement de ce que tu veux

Pour réaliser cela j'utilise le dernier SDK de Steinberg.

Ca c'est une manière d'obtenir une partie de ce que tu veux

J'ai récemment compilé des exemples fournis et éplucher la documentation. Je commence a y voir plus clair entre mon concept général et la forme qu'il doit prendre.

Et ca, c'est une partie du travail qui te permet de te familiariser avec l'outil.

Mais tu laisses l'arbre cacher la forêt!

Ce que tu vas manipuler, ce sont des sons. Pas des images, pas des données personnelles, pas des horaires, des sons!

Ton concept de base, c'est donc le son. C'est sur ce concept de base que tout le reste va s'articuler : pour pouvoir l'acquérir d'une manière ou d'une autre, pour pouvoir le manipuler, pour pouvoir l'afficher et l'archiver au besoin, mais tout sera orienté vers le travail sur des sons.

Tant que tu ne disposeras pas d'une donnée capable de représenter un (des) son(s), tu ne pourras strictement rien faire

Ok, mais du coup j'aimerai y voir plus clair dans les relations possibles entre ces concepts, comment les signifier dans les diagrammes et leurs implémentations en c++...
Et est-ce que tu pourrais me donner des exemples des diagrammes? (Use case, diagramme de communication et diagramme de classe)

Bien, justement, le point commun est le son. Mais il y a peut être certains concepts qui permettent de relier les sons à certains éléments que tu as déjà identifié, qui seront indispensables pour te permettre de mettre ces relations en place.

C'est à toi de voir quels sont les concepts qui manquent et qui permettront -- parfois de manière très indirecte -- de créer les différentes relations.

Essayes de trouver un ou des tutoriaux qui abordent ces différents diagrammes, parce qu'il sera vraiment difficile de tous te les présenter ici

Pour ce qui est du calcul matriciel, en fait j'ai déjà écris une classe à partir de pointeurs et d'opérateurs new et delete (donc sans <vector> contrairement à l'exemple que tu m'as donné) mais elle bug pour le moment... sans doute à cause d'une mauvaise gestion de la mémoire.
Je n'y tiens pas particulièrement à ma classe, mais je veux la faire fonctionner pour m'exercer.

Si tu nous présente son code, nous pourrons très certainement te donner des pistes

En fait je me pose deux questions par rapport à l'utilisation de librairies...
Le SDK que j'utilise permet de compiler des applications pour mac et windows à partir des mêmes sources c++. Je ne me suis pas encore penché sur la compilation sous mac... Mais si j'utilise des librairies externe, fonctionneront-elles sur les deux systèmes?
La deuxième question concerne la licence. Si je finis par distribuer mon logiciel, payant ou gratuit, qu'elles seront les contraintes? (vous me répondrez surement que ça dépend des librairies...)

Le fait que le SDK que tu utilise sont disponibles sur mac et sur windows est déjà encourageant en soi.

Si tu décides d'utiliser d'autres bibliothèques, il faudra voir si elles sont susceptibles de fonctionner ou non sur les différents systèmes. Mais, de manière générale, il existe souvent plusieurs bibliothèques qui abordent (parfois de manière très similaire, parfois de manière très différente) un problème donné. La disponibilité de ces bibliothèques sur différentes plateformes peut être un critère de choix parmi d'autres

Quand aux contraintes imposées par l'utilisation des différentes bibliothèques, cela dépend exclusivement de la licence utilisées par celles-ci.

Certaines licence sont très permissives, d'autres sont plus restrictives, certaines sont gratuite quoi qu'il arrive, d'autres sont gratuites pour un usage non commercial, payantes pour un usage commercial.

Cet aspect peut aussi être un des critères de choix lorsque tu choisira la bibliothèque avec laquelle tu décides de travailler