cptpingu
Messages postés3837Date d'inscriptiondimanche 12 décembre 2004StatutModérateurDernière intervention28 mars 2023
-
31 janv. 2010 à 20:49
Minilogus
Messages postés21Date d'inscriptiondimanche 31 janvier 2010StatutMembreDernière intervention10 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.
Minilogus
Messages postés21Date d'inscriptiondimanche 31 janvier 2010StatutMembreDernière intervention10 juin 20113 8 mars 2010 à 16:42
Bonjour,
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... ^^.
tagtog
Messages postés7Date d'inscriptionmardi 17 février 2009StatutMembreDernière intervention20 juillet 2011 8 mars 2010 à 16:36
Merci,
mais le choix 9 n'est pas prise en charge ^^.
Minilogus
Messages postés21Date d'inscriptiondimanche 31 janvier 2010StatutMembreDernière intervention10 juin 20113 9 févr. 2010 à 02:18
Voilà, j'ai fait des modifications.
cptpingu
Messages postés3837Date d'inscriptiondimanche 12 décembre 2004StatutModérateurDernière intervention28 mars 2023123 1 févr. 2010 à 01:20
Minilogus
Messages postés21Date d'inscriptiondimanche 31 janvier 2010StatutMembreDernière intervention10 juin 20113 31 janv. 2010 à 23:51
Merci pour toutes ces précisions très utiles, par contre le C en lui même je n'y connais pas grand chose (raison pour laquelle je le fait en C++ ^^).
cptpingu
Messages postés3837Date d'inscriptiondimanche 12 décembre 2004StatutModérateurDernière intervention28 mars 2023123 31 janv. 2010 à 23:41
> mais si j'utilise std::vector, il faudra que je fournisse une des 2 valeurs (ligne ou colonne) à la compilation
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.
Minilogus
Messages postés21Date d'inscriptiondimanche 31 janvier 2010StatutMembreDernière intervention10 juin 20113 31 janv. 2010 à 23:19
Bonjour, merci pour le commentaire.
"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?
cptpingu
Messages postés3837Date d'inscriptiondimanche 12 décembre 2004StatutModérateurDernière intervention28 mars 2023123 31 janv. 2010 à 20:49
Ce n'est pas un code que je recommenderais.
- 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.
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.