Discussion :

[ram-0000]

Bonjour,

Un petit rappel, il ne vous reste plus que 1 semaine pour peaufiner vos projets.

[Ulmo]

J'ai finalement eu (pris) le temps de faire quelque chose de correct.
Il ne me reste plus qu'un petit blabla à rédiger et je vous envoie tout ça. !

[Sylvain Togni]

Et hop, envoyé en ce qui me concerne !

J'ai bien aimé ce défi, à la fois ludique et algorithmiquement très intéressant

[ram-0000]

Et hop, envoyé en ce qui me concerne !

J'ai bien aimé ce défi, à la fois ludique et algorithmiquement très intéressant

Merci, archive téléchargée et lue, il ne reste plus qu'à dépouiller maintenant.

[Ulmo]

Participation envoyée !
Au dernier moment bien sûr, mais normalement dans les temps.

[ram-0000]

Au dernier moment bien sûr, mais normalement dans les temps.

Comme à l'école, on fait le devoir la veille pour le lendemain !!

Archive valide et lue.



+----------------------------------------+
| Cloture du dépôt des projets pour ce défi |
+----------------------------------------+

[FunK92]

mince j'ai encore louper ce défis par manque de temps :/

[Ulmo]

Ce bonus a été introduit pour "rééquilibrer" le très gros avantage à coder en C++. Si on prend par exemple l'exemple bateau et courant de la liste chainée, c'est tout de même beaucoup simple à implémenter en C++ (1 ligne de déclaration avec std::list) que en C où il faut tout refaire. C'est pareil avec la librairie boost qui offre beaucoup de fonctionnalités non disponibles en C.

Ce point particulier a été discuté entre les différents membres du jury.

Ce bonus au C est totalement justifié à mon sens.
Par contre, il serait plus "politiquement correct" de dire un truc du genre "le travail supplémentaire nécessaire en C a été pris en compte dans la notation", cela évite l'impression que toutes les règles n'ont pas été dites.

Sinon, est-il possible d'avoir accès aux différents projets ?
Et à ceux des modérateurs et responsables ?
Histoire de voir les idées des un et des autres.

[ram-0000]

Ce bonus au C est totalement justifié à mon sens.
Par contre, il serait plus "politiquement correct" de dire un truc du genre "le travail supplémentaire nécessaire en C a été pris en compte dans la notation", cela évite l'impression que toutes les règles n'ont pas été dites.

Aucun système de notation n'est parfait. Les petites imperfections dans la notation de ce défi sont prises en comptes pour le prochain défi dans lequel le barème et les critères d'évaluation seront connus dès le début du défi.

Sinon, est-il possible d'avoir accès aux différents projets ?
Et à ceux des modérateurs et responsables ?
Histoire de voir les idées des un et des autres.

C'est en cours, les résultats définitifs devraient être publiés ce soir ou demain.

[yan]

Ce bonus au C est totalement justifié à mon sens.

perso je n'en suis pas sur. Si tu autorise l'utilisation de glib...

[ram-0000]

perso je n'en suis pas sur. Si tu autorise l'utilisation de glib...

Je ne connais pas glib (jamais eu l'occasion d'utiliser). Donc quelques questions :

• Est ce que c'est utilisable dans un environnement "console only" sans librairie X/KDE/Gnome installée ?
• Est ce que ce n'est pas que graphique ?
• Est ce que cela apporte des fonctionnalités et des facilités supplémentaires du même genre que la STL et/ou boost ?

[yan]

Est ce que c'est utilisable dans un environnement "console only" sans librairie X/KDE/Gnome installée ?

oui, elle est portable

Est ce que ce n'est pas que graphique ?

glib n'est pas graphique, c'est gtk. Qui est basé dessus.

Est ce que cela apporte des fonctionnalités et des facilités supplémentaires du même genre que la STL et/ou boost ?

glib, c'est une sorte de STL+boost en C.
je te laisse regarder ce quelle offre
http://library.gnome.org/devel/glib/stable/

Pour moi, ce bonus C, c'est un peu comme dire que C est moins fourni que le C++... Ce qui n'est pas vrai

[Ulmo]

Aucun système de notation n'est parfait. Les petites imperfections dans la notation de ce défi sont prises en comptes pour le prochain défi dans lequel le barème et les critères d'évaluation seront connus dès le début du défi.

Je ne critique pas la notation, et à mon avis ce bonus est une bonne idée pour protéger les développeurs C (qui seraient effectivement désavantagés sinon).
Je ne parlais que de la présentation.

perso je n'en suis pas sur. Si tu autorise l'utilisation de glib...

Exact, c'est pourquoi je parlerais plutôt d'une prise en compte du travail fait que d'un bonus à utiliser tel langage.
Après, on peut se poser la question de savoir si on préfère valoriser "ceux qui savent utiliser les ressources disponibles" (boost, glib, ...) ou ceux qui collent au standard.
Mais c'est aux organisateurs/correcteurs de voir pour tout ça.

Je ne connais pas glib (jamais eu l'occasion d'utiliser). Donc quelques questions :

• Est ce que c'est utilisable dans un environnement "console only" sans librairie X/KDE/Gnome installée ?
• Est ce que ce n'est pas que graphique ?
• Est ce que cela apporte des fonctionnalités et des facilités supplémentaires du même genre que la STL et/ou boost ?

Dans mes souvenirs, glib est la bibliothèque d'utilitaires (macros, boucles, chaines de caractères, listes ...), il n'y a aucun graphisme dedans.
C'est effectivement proche de l'esprit de la STL.

[ram-0000]

Pour moi, ce bonus C, c'est un peu comme dire que C est moins fourni que le C++... Ce qui n'est pas vrai

Je ne voudrais pas démarrer un troll C vs C++ ici, il y en a assez ailleurs .

Ce que je constate tout de même, c'est que nativement, C++ apporte beaucoup plus de richesse (polymorphisme, templates, surcharge) de manière immédiate. Les même concepts peuvent probablement être écrits ou approchés en C mais il faut rajouter du code à la main.

De plus et sans que l'on s'en rende compte lorsque l'on débute en C++, les concepts de la STL sont intégrés dans le langage à tel point que l'on ne sait pas dire (quand on débute toujours) si std::vector fait partie du C++ ou de la STL.

Tout le monde a déjà fait des listes chainées en C et sait combien la gestion des pointeurs est pénible. Avec la STL, c'est natif (et c'est très bien).

Donc loin de moi l'idée de dire que le C est moins fourni que le C++ et effectivement la manière de le dire de Ulmo est peut être moins polémique en parlant de "travail et d'effort supplémentaire nécessaire pour écrire en C"

[ram-0000]

Les personnes ayant participé jusqu'au bout à ce défi sont par ordre alphabétique :

• D[r]eadLock
• Sylvain Togni
• Ulmo

Nous les remercions pour de leur participation à ce défi ainsi que tous les autres participants qui ne sont pas allées jusqu'au bout de la démarche mais qui ont tenté de participer.

Et voici les résultats tant attendus :

• D[r]eadLock a obtenu une note de 14/20. Cette note prend en compte le bonus de 2 points attribués aux projets écrits en C.
• Sylvain Togni a obtenu une note de 16/20.
• Ulmo a obtenu une note de 13/20.

Le gagnant de ce défi est donc Sylvain Togni et nous le félicitons tous.







De manière globale, on retiendra :

• D[r]eadLock : Un travail en C (saluons l'effort), un algorithme simple (par brut force) mais qui montre ses limites sur des plateaux un peu plus complexes.
• Sylvain Togni, un vrai travail de recherche d'algorithme, une présentation des résultats soignée, un temps d'exécution très rapide, un algorithme de détection des solutions impossibles mis en défaut 1 seule fois.
• Ulmo, un travail de recherche d'algorithme (un peu moins poussé), une présentation des résultats un peu brouillon, un temps d'exécution assez long.

La page du défi a été mise à jour et contient les résultats, nos commentaires et les liens pour télécharger les différents projets.

[LittleWhite]

Bravo à tous, les organisateurs ainsi que les participants...
Peut être que j'aurais plus de temps libre pour le prochain defi :p

[D[r]eadLock]

Le gagnant de ce défi est donc Sylvain Togni et nous le félicitons tous.

Bravo ! Je savais que c'était un bon algo quand j'ai vu les temps et la conso mémoire.
Merci aux organisateurs et je vais me remettre à mes cours d'algo...
Quant à la "polémique" du C vs. C++, c'est vrai que j'aurais pu utiliser la glib mais je préférais tout faire ;D (le seul vrai 'souci' pour moi c'est la norme choisi pour le défi (cf. mon code commenté), macro avec nombre de paramètres variable non autorisé, extension GNU ,##__VA_ARGS__ non supportée)
Et sinon, je me suis rendu compte que j'avais oublié de coder le ResizePlateau

[Jean-Marc.Bourguet]

macro avec nombre de paramètres variable non autorisé, extension GNU ,##__VA_ARGS__ non supportée

C99 pas GCC (mais si j'ai bonne memoire GCC a eu la feature en extension avant C99, avec des incompatibilites; et je n'ai pas regarde s'ils sont bien passes au comportement normalise).


Felicitations a Sylvain.