OPÉRATIONS SUR MATRICES C++
cptpingu
Messages postés
3837
Date d'inscription
dimanche 12 décembre 2004
Statut
Modérateur
Dernière intervention
28 mars 2023
-
31 janv. 2010 à 20:49
Minilogus Messages postés 21 Date d'inscription dimanche 31 janvier 2010 Statut Membre Dernière intervention 10 juin 2011 - 8 mars 2010 à 16:42
Minilogus Messages postés 21 Date d'inscription dimanche 31 janvier 2010 Statut Membre Dernière intervention 10 juin 2011 - 8 mars 2010 à 16:42
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/51219-operations-sur-matrices-c
https://codes-sources.commentcamarche.net/source/51219-operations-sur-matrices-c
8 mars 2010 à 16:42
Je te remercie de ton intervention TAGTOG, mais je ne voit pas de quel choix tu fait mention. En effet mon programme propose 8 choix qui, pour autant que j'ai pu le constater, fonctionnent.
Ou alors c'était de l'humour... ^^.
8 mars 2010 à 16:36
mais le choix 9 n'est pas prise en charge ^^.
9 févr. 2010 à 02:18
1 févr. 2010 à 01:20
http://www.cppfrance.com/codes/MATRICE-AVEC-TEMPLATE_45871.aspx
http://www.cppfrance.com/codes/CLASS-MATRICE-AVEC-TEMPLATE_45950.aspx
31 janv. 2010 à 23:51
31 janv. 2010 à 23:41
Absolument pas. Tu peux faire un std::vector< std::vector >, tout est dynamique
En revanche, un vector de vector c'est moyen pour les perfs (même si ce n'est pas dramatique), raison pour laquelle, il existe le boost::multi_array (petite contrainte sur le fait qu'il te faut inclure boost).
La meilleur solution, si tu sais que les dimensions de tes matrices ne vont pas changer, est de créer une classe StaticMultiArray templatée qui encapsule un tableau à double dimension (la classe se chargeant de la vérification des bornes, des allocations mémoires, etc...), ou alors un std::vector d'une classe templatée encapsulant un tableaux fixe.
> Je pense qu'ont en a rien à faire de cette phrase un peu provocatrice....
Ce n'était pas une phrase provocatrice. Le code doit être encore retravaillé, et sous plusieurs aspects:
- Pédagogique: Absence totale de commentaire ou d'explication technique
- Utilisation du C++ comme du C (Quand on sait que l'on peut créer une classe "Matrix" et redéfinir tous les opérateurs pour l'utiliser comme ceci: "Matrix a, b, c; c = a * b; std::cout << c << std::endl;", c'est vraiment dommage de ne pas l'exploiter).
- Améliorer la modularisation du code. En moyenne, une fonction ne devrait pas dépasser 30 lignes. Si c'est le cas, alors la fonction devrait être découpée elle même en plusieurs sous fonctions. Avec l'inlining, il n'y a pas de différence de performance, mais la lisibilité et la maintenabilité s'en trouvent accrue.
La raison pour laquelle j'ai dit cela, c'est qu'en l'état (pour l'instant), ce n'est pas un exemple à donner aux débutant.
31 janv. 2010 à 23:19
"Ce n'est pas un code que je recommenderais." Je pense qu'ont en a rien à faire de cette phrase un peu provocatrice....
Pour tout le reste je te remercie des conseils et vais tenter modifier le code en conséquence (ton portfolio est très instructif ^^ pour le std).
En revanche pour le STL, c'est pas que je le boude, mais si j'utilise std::vector, il faudra que je fournisse une des 2 valeurs (ligne ou colonne) à la compilation... (du moins c'est ce qu'il me semble). N'est-ce pas un peu contraignant?
31 janv. 2010 à 20:49
- Non séparation du code en plusieurs fichiers (aisément réalisable)
- Non utilisation de classe ou de redéfinition d'opérateurs, qui sont adaptés pour ce cas.
- Utilisation d'un using namespace std. Beurk ! Voir: http://0217021.free.fr/portfolio/axel.berardino/articles/bon-usage-using-namespace
- Utilisation d'un type avec **, au lieu d'utiliser la STL
- Non gestion des erreurs de flux d'entrée (si je tape n'importe quoi au lien d'entrée un nombre, ton programme va pas apprécier). On le gère via std::cin.fail(), std::cin.clear et std::cin.ignore.
- include <string> inutile, car déjà inclu dans iostream.
- Non à rallonge.
Pourquoi utiliser du C++, si tu n'exploites aucun des avantages de ce langage ? Autant le faire en C.
Il n'y a aucun raison, pour ce code ci, que la source sous Linux et Windows diffère. Les quelques détails d'affichage, peu utile à cette source devraient être retirés. Si tu perds la portabilité à cause d'une fonctionnalité, demande toi toujours avant, si celle-ci vaut la peine d'être introduite.