Discussion :

[gbdivers]

La bibliothèque standard fournit un nombre important de structures de données et d'algorithmes. Dans de nombreux cas, il est possible de remplacer les structures de contrôle du langage (if, for, while) par les fonctionnalités provenant de celle-ci. Dans ce Guru Of the Week n° 41, Herb Sutter lance le défi de créer un Mastermind en minimisant l'utilisation des structures de contrôle.

Guru Of the Week n° 41 : utiliser la bibliothèque standard

Saurez-vous relever le défi et proposer un tel code de Mastermind ?

Retrouver l'ensemble des Guru of the Week sur la page d'index.

[mitkl]

La solution est très intéressante, c'est une approche que je n'avais jamais développé, j'aime beaucoup !

Saurez-vous relever le défi et proposer un tel code de Mastermind ?

Honnêtement quand j'ai lu l'énoncé, faire un mastermind sans aucun if/for/while me semblait difficilement réalisable. Après avoir vu la solution, j'ai eu quelques déclics avec l'utilisation de la STL et ça me semble déjà plus réalise.

[Kalith]

Il manque un lien vers l'article original

Sinon je trouve dommage que l'exemple de code fourni soit si inutilement cryptique. Ça nuit à la compréhension de l'article, et ça ne fait pas envie (et encore, la mise en forme choisie sur Developpez est un peu plus claire grâce aux sauts de lignes).

[transgohan]

Je suis pas très calé en c++ mais je vois pas tellement l'intérêt du défi.
Le but est de n'utiliser que la STL c'est ça ? (après faut bien avouer qu'elle est sous-utilisée - et je me compte dedans xD )
Car au final, il est faux de dire qu'on n'utilise aucun test et boucle.

[mitkl]

Le but est d'utiliser le moins possible d'if/for/while, c'est un GotW qui fait réfléchir, ça ne veut pas dire qu'il ne faut plus utiliser de structure de contrôle mais au lieu d'imbriquer des if dans des for et compagnie, un petit coup de STL, un foncteur peuvent être plus lisibles.

[Arzar]

Sinon je trouve dommage que l'exemple de code fourni soit si inutilement cryptique. Ça nuit à la compréhension de l'article, et ça ne fait pas envie

+1
Quelle catastrophe ce code... Je ne parle pas de l'utilisation un peu extrême de la STL, qui est après tout le but de l'exercice, mais du reste.

• Nom de variable courte et cryptique. En quelques lignes on subit du l, M, cm, gm, c, g...
• Utilisation à outrance de l'opérateur virgule. Sérieux il faut emprisonner le dingo qui s'amuse à écrire des lignes du style return ++cm_[c], ++gm_[toupper(g)], exact_ += c == toupper(g), '.';

Du reste je crois que bien que le code est buggé. En tout cas chez moi, à chaque nouvel tentative l'affichage du nombre de couleurs correctement devinées est faux car vaut toujours zéro. Par contre l'affichage du nombre de couleurs correctement devinées et bien placées vaut le résultat attendu.

J'ai l'impression que le problème vient d'ici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

std::transform( comb.begin(), comb.end(), guess.begin(), l.begin(), Count( color, exact ) );

Sachant que le destructeur de Count effectue des opérations assez complexes (mise à jour de std::map), j'ai l'impression que le code se base sur des détails d'implémentation en supposant que Count sera copié une fois et détruit une fois dans le std::transform mais manque de bol ce n'est pas le cas sur mon compilo.

[Kalith]

J'utilise GCC 4.7 sans activer le C++11 (donc pas de sémantique de mouvement, mais le GotW a été écrit avant la sortie de la norme) et sans optimisation, et ça marche correctement chez moi.

Sinon je rejoins ta critique : la ligne qui m'a fait le plus mal aux yeux est celle que tu as cité.

[Kiroxas]

Salut,

Utilisation à outrance de l'opérateur virgule. Sérieux il faut emprisonner le dingo qui s'amuse à écrire des lignes du style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

return ++cm_[c], ++gm_[toupper(g)], exact_ += c == toupper(g), '.';

D'ailleurs quelqu'un peut expliquer cette ligne parce que j'ai un peu de mal à voir ce qui est véritablement retourné finalement ?

[Kalith]

Seulement le dernier élément, soit ".".
L'intérêt est de tout écrire en "une instruction", ce qui n'apporte rien en terme de performance, mais peut économiser de la place en terme de quantité de code (c'est discutable ici).