Discussion :

[Invité]

a- Qui donne LE algorithme optimal ? Dijkstra reste la référence, le reste n'est que variations, ou non optimal (A*).

Est ce important? La question est jolie parce qu'il y a de nombreuses façons de l'attaquer, et que le problème est suffisament petit pour que toutes ces solutions puissent aboutir en temps raisonnable. Depuis hier, j'en cause autour de moi (avec des gens qui connaissent un peu le sujet) et je suis amusé du nombre de suggestions différentes qui sont proposées...

Bref, ca mérite mieux qu'un "algo 23 de la librairie 12".

b- Oui, la modélisation en graphe, et la prise en compte des points d'intersection.

Si tu veux absolument faire des graphes. Mais on pourrait aussi se demander comment modéliser le problème autrement. Par exemple, on peut remarquer que la fonction qu'on minimise est linéaire en deux paramètres discrets, le nb de stations et de nb de correspondances (le second dérivant de la notion de ligne, on n'est pas du tout dans un cas de graphe "bateau" ici). Il doit y avoir un intéressant problème dual planqué derrière...

On peut également remarquer la présence de trois niveaux d'échelle dans le problème sous jacent : plusieurs centaines de stations, une soixantaine de correspondances, et une quinzaine de lignes... Là encore, on doit pouvoir tirer parti de cette hierarchie (qui se retrouve, d'ailleurs, dans la forme de la fonction qu'on minimise, au travers des correspondances). Pour bâtir un arbre?

Et comme la combinatoire n'est pas réellement explosive : parce qu'un réseau de métro n'est jamais très dense (disons une correspondance pour 3 ou 4 stations), il y aura, même pour un gros métro comme Paris, des solutions force brute par énumération, qui seront intéressantes de plein droit.

Un ami APL-iste me disait ce matin que ce serait un joli terrain de jeu pour les fonctions booléenne qui font le bonheur des adepte de ce langage...

Il y a plein de choses amusantes à essayer et à faire. Même si on devait, à la fin, conclure qu'il n'y a que Dijkstra qui tienne.

c- Je n'ai pas dit qu'il était mauvais. Juste que c'est trop classique (pour ne pas dire scolaire) pour que je m'y intéresse. ^^'

Chacun voit midi à sa porte. Pour moi, ce ne sont pas les problèmes qui sont scolaires, ce sont les approches.

Francois

[Mac LAK]

Nous cherchons toujours à comprendre la raison qui fait que l'on en arrive à cela.

Ma modeste idée sur le sujet, celle qui fait que même si j'avais eu le temps de plancher dessus, je n'aurais pas rendu de projet malgré tout :

• La contrainte de portabilité est très lourde sur plusieurs points : d'une part, cela présuppose d'avoir deux plate-formes installées chez soi pour le vérifier (ce qui n'est pas le cas). A titre personnel, je développe sur Windows, et je ne vais pas refuser d'utiliser l'API Win32 par pur masochisme... Surtout quand je vois le format du fichier des stations qui a un goût de fichier INI bien prononcé.
  En plus, il y a incohérence côté règlement : "Environnement de dev libre", "écrit pour environnements Microsoft ou Linux" (et non pas "et"), et je n'ai pas vu le mot "portable" dans le règlement général...
• La non-utilisation de bibliothèque peut se comprendre sur des librairies payantes et/ou en version d'essai / limitée. Elle n'est pas tolérable, à mon sens, sur une librairie gratuite.
• Commenter son code, c'est normal. La documentation, par contre, a tendance à rebuter pas mal de gens vivant du développement si c'est pour quelque chose de personnel, "jetable" et ne faisant pas partie d'un projet que l'on maintient soi-même par goût.
  Habituellement, c'est quand même LA corvée de base à faire, ou alors il va falloir accepter les CHM produits par Doxygen...
• La distinction forte faite entre C et C++ me gêne un peu pour ma part, ayant une tendance naturelle à privilégier la solution la plus simple... Qui peut parfaitement être une fonction "C" utilisant des maps, vecteurs, etc. et non pas une méthode de classe. Ce n'est d'ailleurs pas du C, ça ne compilerait pas.
  Or, là, j'ai tendance à lire "C++ = classes au taquet y compris quand ça ne sert à rien", et ça, ça me dérange, personnellement.
• Le défi en question (le 4ème) me fait plus l'impression d'un défi n'impliquant QUE des contraintes d'implémentation et non pas de conception... Cela aurait pu être amusant en devant implémenter l'algo de recherche soi-même, en n'utilisant ni boost, ni STL, ni Dijkstra, ou en ayant comme but d'être le plus rapide possible à l'exécution, bref quelque chose de plus "challenge".
• Quitte à poser des problèmes de portabilité, non-dépendance à des librairies, rigidité du langage, etc., un problème plus amusant serait de "nettoyer" un code existant.
  En gros, prendre un truc-spaghetti, et le rendre propre, efficace, lever les dépendances de plate-forme, etc. en prenant comme critère d'efficacité le nombre de modifications apportées au code d'origine.

Voilà, ce n'est que MON avis, qui n'engage QUE moi, mais en tout cas c'est rédhibitoire pour moi : je refuse de me taper les mêmes contraintes qu'au boulot pour un truc personnel censé m'amuser et me faire passer le temps...

Poser trop de contraintes de développement sur un tel défi enlève le côté "ludique" (donc qui "donne envie" de le faire) pour y introduire soit un côté "scolaire" (limite vexant pour un professionnel...), soit un côté "pro" (qui gâche le week-end...).

[Nogane]

Bonjour,

La contrainte de portabilité est très lourde sur plusieurs points : d'une part, cela présuppose d'avoir deux plate-formes installées chez soi pour le vérifier (ce qui n'est pas le cas).

Je reconnais que c'est pas évident. J'ai du m'installer un linux éxpré(même si je le regrette pas). Mais j'ai pu constater qu'entre MinGW et g++ il n'y avais pas vraiment de surprise. Sauf pour les encodage et charset, mais ça c'est plus un problème linux/windows. C'est vrai que des projets n'impliquant pas ces problème rendrai la portabilité plus facile, et n'obligerai pas a installer d'autre system.

A titre personnel, je développe sur Windows, et je ne vais pas refuser d'utiliser l'API Win32 par pur masochisme... Surtout quand je vois le format du fichier des stations qui a un goût de fichier INI bien prononcé.

Je suis a peu près sur qu'on peut trouver un équivalant dans STL/boost a tout ce que fait l'API Win32. Et pour les fichier ini, program_options le fait, et de toute façon, lire ce fichier n'était pas la pire difficulté.

En plus, il y a incohérence côté règlement : "Environnement de dev libre", "écrit pour environnements Microsoft ou Linux" (et non pas "et"), et je n'ai pas vu le mot "portable" dans le règlement général...

La je suis d'accord. Il y a un manque de précision de ce coté là.

La non-utilisation de bibliothèque peut se comprendre sur des librairies payantes et/ou en version d'essai / limitée. Elle n'est pas tolérable, à mon sens, sur une librairie gratuite.

Je ne suis pas vraiment d'accord. Si on te demande, dans le cadre d'un défi, de faire un moteur physique, c'est normal de t'interdire ODE...
Et puis les librairies externe ne sont pas formellement interdite je crois. Elles sont juste désapprouvée. Pour le reste c'est à l'appréciation du jury.

Commenter son code, c'est normal. La documentation, par contre, a tendance à rebuter pas mal de gens vivant du développement si c'est pour quelque chose de personnel, "jetable" et ne faisant pas partie d'un projet que l'on maintient soi-même par goût.
Habituellement, c'est quand même LA corvée de base à faire, ou alors il va falloir accepter les CHM produits par Doxygen...

Je suis d'accord que c'est embêtant, mais pourquoi alors ne pas utiliser Doxigen, comme tu le propose? C'est ce que j'ai fait en tout cas.(Je ne crois pas que ce soit interdit, mais du coup tu me met le doute)

Or, là, j'ai tendance à lire "C++ = classes au taquet y compris quand ça ne sert à rien", et ça, ça me dérange, personnellement.

Ce n'est pas vrais. On peut très bien dans du "bon" c++ utiliser des fonctions, a condition qu'elles soient misent dans un namespace approprié. Ce n'est pas du C#! ^^

Le défi en question (le 4ème) me fait plus l'impression d'un défi n'impliquant QUE des contraintes d'implémentation et non pas de conception... Cela aurait pu être amusant en devant implémenter l'algo de recherche soi-même, en n'utilisant ni boost, ni STL, ni Dijkstra, ou en ayant comme but d'être le plus rapide possible à l'exécution, bref quelque chose de plus "challenge".

Je suis assez d'accord, mais rien ne t'oblige a utiliser boost.graph et Dijkstra. D'ailleurs je ne suis pas convaincu que ce soit la meilleur solution, et d'ailleurs je ne les ai pas utilisé.
Pour ce qui est de la STL... ce serai un drôle de défi c++ si on devais s'en priver.

Quitte à poser des problèmes de portabilité, non-dépendance à des librairies, rigidité du langage, etc., un problème plus amusant serait de "nettoyer" un code existant.

Je trouve cette idée plutôt sympathique. Peut-être pas pour tout les défis, mais c'est a creuser.

[pfeuh]

Salut,

je refuse de me taper les mêmes contraintes qu'au boulot pour un truc personnel censé m'amuser et me faire passer le temps...

Idem pour moi.

A+

Pfeuh

[koala01]

Il faut comprendre que, si nous mettons l'accent sur la documentation et sur les commentaires du code, ce n'est pas tout à fait innocent...

Tout comme le fait que l'on demande de céder les droits à developpez ne l'est pas, ou d'autres contraintes d'ailleurs, ne l'est pas.

Ce genre de défis est, certes, destiné à "amuser" ceux qui décident de le relever, mais l'idée par delà même ce but premier est de proposer les sources fournies à "d'autres lecteurs" pour qu'il puissent soit s'amuser (eux aussi) avec, soit, pourquoi pas, s'inspirer de ce qui est fait.

(Et comme nous laissons le choix tout à fait libre en ce qui concerne la présentation de la documentation, tu es effectivement tout à fait en droit d'utiliser l'outil que tu veux pour la générer )

[EDIT]Il ne faut pas non plus oublier que les gens qui sont en charge de la vérification des projets ne savent à la base absolument pas quelle optique tu pourra avoir envisagée...

Il est donc "normal" que tu la leur présente un minimum au travers de la documentation
[/EDIT]

De ce fait, je trouve presque moche que tu considère les projets du défis comme étant "jetables" et destinés à être "oubliés" sitôt les résultats présentés, car ces projets seront hébergés "tels quels" (avec toutes leurs qualités et tous leurs défauts) aussi longtemps de developpez existera

Maintenant, en ce qui concerne les points particuliers du règlement, il faut aussi comprendre que nous (ceux qui l'ont écrit) ne sommes que des hommes, avec leurs qualités et leurs défauts, et qu'il peut donc y avoir certains points inappropriés ou nécessitant une mise au point...

Partant de là, nous acceptons bien évidemment toute proposition "honnête et cohérente" de modification du règlement .

Je ne dis pas qu'elles seront toutes prises en compte, mais elles seront au minimum étudiées avec le plus grand soin

Par exemple, nous pourrions effectivement (mais je ne parle qu'en tant que consultant sur ce point) envisager d'assouplir les règles de "portabilité" de manière à seulement insister sur le fait que, si un programme compile sous linux avec Gcc, il doit également compiler sous windows avec MinGW ou sous cygwin (qui sont tous deux basés sous Gcc)...

Bref, partant du principe que l'on apprend beaucoup plus de ces erreurs que de ses réussites, je t'inviterais volontiers à nous faire part des propositions d'amélioration du règlement que tu pourrais envisager

[Luc Hermitte]

Ici, il est plus simple d'avoir un truc qui marche avec gcc-linux ET VC++, qu'avec gcc-mingw/gcc-cygwin. A cause de gcc qui ne sait pas supporter wchar_t et divers types qui en découlent sous windows.

[Vincent Rogier]

Les défi C de developpez ne sont pas des exercices en lignes ni des TP !

Il s'agit pour ceux qui veulent y participer de proposer un projet qui sera stocké sur developpez et librement accessibles aux utilisateurs du site. Ils pourront alors le télécharger, le compiler, l'étudier, etc... Il y a aussi un aspect pédagogique à la chose.

Fournir un projet pour qu'il soit accessible aux autres nécessite donc que le code code soit commenté et qu'un minimum de documentation explique les choix d'implémentation et le fonctionnement du programme. De plus, on ne demande pas d'écrire une documentation universitaire de 100 pages non plus !

Faut arrêter de bloquer la dessus.
Que ce soit à titre personnel, à titre professionnel ou collaboratif open source, un code source et/ou une application doit être commenté et son utilisation expliquée même succinctement.
Ceux qui ne comprennent pas ça auront du mal à se faire une place comme développeur en pro ou en collaboratif !

Les défis de developpez sont des défis à visée pédagogique et collaboratif.

Refuser de faire ne serait ce q'une 1 page de documentation est vraiment une insulte à ceux qui prennent bénevolement le temps de réfléchir au thèmes des défis, à les organiser, les fiares vivre et évaluer les projets notés.

Un peu de respect pour nos membres bénévoles qui font tout ca sur leur temps libre afin que la communauté puisse en profiter.

[Vincent Rogier]

Ici, il est plus simple d'avoir un truc qui marche avec gcc-linux ET VC++, qu'avec gcc-mingw/gcc-cygwin. A cause de gcc qui ne sait pas supporter wchar_t et divers types qui en découlent sous windows.

Hum... gcc gère tres bien wchar_t...

Je vois vraiment pas ce que tu veux dire

[Mac LAK]

Je suis a peu près sur qu'on peut trouver un équivalant dans STL/boost a tout ce que fait l'API Win32. Et pour les fichier ini, program_options le fait, et de toute façon, lire ce fichier n'était pas la pire difficulté.

Heu... Là, je crois que tu t'avances beaucoup, l'API Win32 est quand même plutôt volumineuse, spécifique et contient aussi bien des fonctions basiques (i.e. des ouvertures de fichier) que des fonctions de haut niveau (boîte de dialogue de sauvegarde / impression), des fonctions réseau, XML, thread, processus, etc.
La STL ou Boost sont des librairies "basiques", elles simplifient des implémentations sans toutefois être cruciales. Par exemple, à titre professionnel, je n'utilise jamais Boost, et même au niveau de la STL, je limite au maximum son utilisation à des éléments non-critiques...

Je ne suis pas vraiment d'accord. Si on te demande, dans le cadre d'un défi, de faire un moteur physique, c'est normal de t'interdire ODE...
Et puis les librairies externe ne sont pas formellement interdite je crois. Elles sont juste désapprouvée. Pour le reste c'est à l'appréciation du jury.

Il est normal d'interdire une librairie qui résoudrait le défi par un simple appel de fonction, si le but est justement de retrouver / refaire l'algo sous-jacent.
Dans le cadre de ce défi, en ce qui ME concerne, l'ouverture du fichier est une base "triviale" qui n'est là que pour assurer à tous les participants les mêmes données d'entrée : en conséquence, son ouverture devrait être faite avec un support maximal des API de l'OS ou de librairies dédiées à ces conversions (libiconv par exemple)... Sauf si le but du défi était justement de convertir de l'Unicode, il n'y avait aucune raison de passer plus de 20 secondes sur ce problème d'encodage.

Je suis d'accord que c'est embêtant, mais pourquoi alors ne pas utiliser Doxigen, comme tu le propose? C'est ce que j'ai fait en tout cas.(Je ne crois pas que ce soit interdit, mais du coup tu me met le doute)

Le règlement demande plusieurs documents bien particuliers, qui ne sont pas forcément présents dans une documentation Doxygen (notamment la phase de conception, sauf archivage de la version préliminaire de la doc...). Et je ne parle même pas de l'algorithme textuel !!

Ce n'est pas vrais. On peut très bien dans du "bon" c++ utiliser des fonctions, a condition qu'elles soient misent dans un namespace approprié. Ce n'est pas du C#! ^^

Namespace ? Pourquoi faire, dans un aussi petit projet ?
Peut-être vois-tu mieux ce que je veux dire... Pour moi, si ça compile (en sensibilité maximale bien sûr) sans erreurs ni warnings en mode C++, et qu'il refuse de compiler en mode C "pur", c'est du C++ : peu importe s'il ressemble à du C ou à du C#.

Je suis assez d'accord, mais rien ne t'oblige a utiliser boost.graph et Dijkstra. D'ailleurs je ne suis pas convaincu que ce soit la meilleur solution, et d'ailleurs je ne les ai pas utilisé.

La seule partie "amusante" (mais je reconnais avoir des goûts parfois étranges en ce domaine...) du défi, pour moi, c'était justement la création des graphes et leur parcours.

Pour ce qui est de la STL... ce serai un drôle de défi c++ si on devais s'en priver.

Toi, t'as pas assez mangé de C étant petit...
On s'en passe en fait très bien dans 90% des cas, j'ai toujours considéré la STL comme un outil pratique pour des choses non-critiques et/ou les programmes de test / faisabilité.
Pour le reste, essaie de remplir une map avec un million d'entrées et de l'utiliser ensuite, tu verras qu'il faut parfois aussi savoir "faire autrement" si l'on veut des performances.

Je trouve cette idée plutôt sympathique. Peut-être pas pour tout les défis, mais c'est a creuser.

Je voyais ça comme UN défi en particulier moi aussi, ou alors un nouveau genre de défis, mais sûrement pas comme quelque chose qui remplace les défis actuels.



Pour le reste, je tiens quand même à préciser un point non négligeable, qui n'est peut-être pas bien clair : mon avis est celui d'un professionnel expérimenté, qui considère DVP comme une détente et/ou un moyen d'aider les autres, et non pas comme le Messie "nécessaire" pour finir son projet / stage. Je réponds souvent, mais je ne crois pas avoir posé plus d'une ou deux questions en tout depuis mon inscription ici...

Les défis tels qu'ils sont prévus actuellement sont un excellent entraînement pour tous les étudiants et débutants : en milieu professionnel, on vous demandera encore pire que ça, autant savoir le faire dès le départ. Toutefois, cette quasi-parfaite adéquation pour les débutants rend justement les défis rebutants et/ou non-amusants pour les professionnels qui font ça à longueur de journée. Et c'est ça qui est dommage, je trouve...

[Luc Hermitte]

Hum... gcc gère tres bien wchar_t...

Je vois vraiment pas ce que tu veux dire

Code c++ :

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

1
2
3
4
5
6
7
8
9
#include <iostream>
#include <string>
 
int main (int argc, char **argv)
{
    wchar_t c;
    std::wcin >> c;
    std::wstring s;
}

Code :

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

1
2
3
4
5
6
|| g++     wchar_t.cpp   -o wchar_t
|| wchar_t.cpp: In function `int main(int, char**)':
wchar_t.cpp|7| erreur: `wcin' is not a member of `std'
wchar_t.cpp|8| erreur: `wstring' is not a member of `std'
wchar_t.cpp|8| erreur: expected `;' before "s"
|| make: *** [wchar_t] Erreur 1

gcc sous windows n'a jamais rien compris aux types dérivés de wchar_t. C'est un problème connu depuis un bout de temps. De temps à autres la question ressurgit sur la ML de cygwin.

[Vincent Rogier]

ce que tu montres, c'est pas des problèmes avec wchar_t mais avec wcin et wstring...

le type de donnée C wchar_t ainsi que les fonctions dédiées de manipualtion de chaines de caractères larges de la lib C fonctionnent tres bien sous gcc et sous windows.

Maintenant, que la surcouche C++ merdouille dans g++, c'est autre chsoe...

Faut pas tout mélanger ....

Code c++ :

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

1
2
3
4
5
6
7
8
9
10
 
#include <iostream>
#include <string>
 
int main (int argc, char **argv)
{
    wchar_t c;
    std::wcin >> c;
    std::wstring s;
}

Code :

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

1
2
3
4
5
6
|| g++     wchar_t.cpp   -o wchar_t
|| wchar_t.cpp: In function `int main(int, char**)':
wchar_t.cpp|7| erreur: `wcin' is not a member of `std'
wchar_t.cpp|8| erreur: `wstring' is not a member of `std'
wchar_t.cpp|8| erreur: expected `;' before "s"
|| make: *** [wchar_t] Erreur 1

gcc sous windows n'a jamais rien compris aux types dérivés de wchar_t. C'est un problème connu depuis un bout de temps. De temps à autres la question ressurgit sur la ML de cygwin.

[Mac LAK]

Il faut comprendre que, si nous mettons l'accent sur la documentation et sur les commentaires du code, ce n'est pas tout à fait innocent...

Disons qu'un "professionnel" qui se permettrait d'envoyer un code source sur un site comme DVP sans commentaires pertinents mérite d'être brûlé sur un bûcher de bois vert...
Je suis tout à fait d'accord avec toi sur le sujet : quel que soit le "niveau" du participant, les sources doivent être correctement commentés, et le source "propre".
C'est sur la documentation supplémentaire demandée pour les défis que je tique un peu plus...

Tout comme le fait que l'on demande de céder les droits à developpez ne l'est pas, ou d'autres contraintes d'ailleurs, ne l'est pas.

La question des droits n'est pas un souci en soi, tu t'en doutes bien. Quant aux autres contraintes, là aussi, j'en vois bien l'utilité pour en bouffer tous les jours.
Mais là, pour moi, c'est du loisir de traîner sur DVP, pas du "travail"...

De ce fait, je trouve presque moche que tu considère les projets du défis comme étant "jetables" et destinés à être "oubliés" sitôt les résultats présentés, car ces projets seront hébergés "tels quels" (avec toutes leurs qualités et tous leurs défauts) aussi longtemps de developpez existera

"Jetables" dans le sens "non réutilisables" : à part si le défi porte sur une fonctionnalité particulière devant être générique et fournie sous forme de librairie, cela reste du code "en dur". Donc, "jetable".
Que l'on puisse s'en inspirer, bien sûr, c'est le but du site de façon générale. Mais le code des défis n'est pas, en soi, un code réutilisable tel que je l'entends (=zéro modifications, importation et ça marche direct, une librairie donc...).
Et "oubliés" par leur auteur, sauf demandes spécifiques sur le sujet : pour ma part, je ferais ça comme certains bouts de code dans mes réponses, pour passer le temps et/ou résoudre un problème technique amusant. Rarement pour y revenir sans arrêt dessus...

Maintenant, en ce qui concerne les points particuliers du règlement, il faut aussi comprendre que nous (ceux qui l'ont écrit) ne sommes que des hommes, avec leurs qualités et leurs défauts, et qu'il peut donc y avoir certains points inappropriés ou nécessitant une mise au point...

Tel était le but de mon post : donner un avis que je n'avais pour l'instant pas lu dans la discussion, et qui pouvait à mon sens éclairer en partie sur la faible participation... Je pense que beaucoup de membres dans la même situation que moi ont tout simplement zappé complètement le défi, sans chercher même à donner un avis, en le considérant comme "scolaire" et donc forcément "ennuyeux".

Partant de là, nous acceptons bien évidemment toute proposition "honnête et cohérente" de modification du règlement .
Je ne dis pas qu'elles seront toutes prises en compte, mais elles seront au minimum étudiées avec le plus grand soin

T'en as déjà quelques unes un peu plus haut, mais on peut détailler si tu le désires (un autre topic peut-être ?)

Par exemple, nous pourrions effectivement (mais je ne parle qu'en tant que consultant sur ce point) envisager d'assouplir les règles de "portabilité" de manière à seulement insister sur le fait que, si un programme compile sous linux avec Gcc, il doit également compiler sous windows avec MinGW ou sous cygwin (qui sont tous deux basés sous Gcc)...

Déjà, ce serait un très bon point, ça : pour ma part, je reste scotché soit à Visual C++, soit à C++ Builder, mais GCC, à titre personel, c'est le "niet" catégorique. Je le "subis" un peu trop au boulot pour le revouloir à la maison.

Bref, partant du principe que l'on apprend beaucoup plus de ces erreurs que de ses réussites, je t'inviterais volontiers à nous faire part des propositions d'amélioration du règlement que tu pourrais envisager

En premier lieu, la suppression de portabilité dans le sens "Windows / Linux" au profit, effectivement, d'une portabilité "Variantes GCC"... Bien que je ne vois pas l'inconvénient, pour ma part, d'avoir un programme spécifique Windows et un autre spécifique Linux, tant qu'ils ne demandent pas des trucs loufoques (genre le dernier night build de kernel Linux pour une distribution précise, ou Windows 7 avec un serveur Oracle installé...).

Ensuite, par rapport aux librairies, je pense qu'il serait bon d'avoir une liste des librairies "autorisées", ainsi que des API d'OS acceptées. Cette liste peut être "figée", ou au contraire enrichie / réduite à chaque défi.

Côté documentation, la partie qui me gêne le plus est la "conception" demandée (avec algo textuel notamment)... Sur un truc aussi court, la lecture d'un code correctement commenté doit suffire amplement.
Corollaire à ceci : l'absence de commentaires corrects doit être lourdement sanctionnée...

Plus d'éléments d'entrée / test devraient être fournis avec l'énoncé du défi : ici, par exemple, il y avait la liste des stations (très bien). De plus, l'interface du programme était verrouillée lourdement, je trouve ça bien, mais ... Dans ce cas, où est le script / programme de test utilisant justement cette interface verrouillée ?
Bref, un petit truc de test / validation qui fait les tests fonctionnels, les chronométrages, etc. et qui permet d'avoir un résumé rapide du fonctionnement du programme. Cela évite d'avoir à l'écrire soi-même, phase toujours rebutante et que personne n'aime faire réellement (en plus, on teste toujours "mal" son propre code...).

Noter sur des considérations esthétiques peut poser problème en soi : sur le 4ème défi, par exemple, quitte à verrouiller les entrées et les interfaces du programme, j'en aurais aussi verrouillé les sorties... Sortir le trajet dans un fichier XML par exemple aurait été intéressant, et permettait en plus de faire des tests de fonctionnement rapidement tout en autorisant un affichage agréable derrière (le 5ème défi ? ). L'idée derrière tout ça, c'est que soit on laisse une (assez) grande liberté sur les E/S du projet, soit on verrouille au maximum, mais pas un demi-verrouillage...



Le juste milieu existe, il suffit de tous s'y mettre pour le trouver : des défis qui le sont réellement pour des débutants sans pour autant leur filer de mauvaises habitudes, et qui apportent en même temps un côté "ludique" (ou de "challenge") pour les professionnels qui viennent ici pour se détendre.

Les défi C de developpez ne sont pas des exercices en lignes ni des TP !

C'est quoi alors ? Attention, je ne critique pas, mais que sont les questions des forums alors, si ce ne sont pas des "colles" intéressantes à résoudre ? Répondre "pour répondre", c'est le but d'une FAQ. Répéter sans cesse ce que l'on considère comme acquis et "évident" n'a rien d'amusant, ça ne l'est que lorsque celui qui répond y "gagne" d'apprendre un nouveau truc, même dérisoire...

Là, tel que posé, le défi me fait penser justement à un TP, et non pas à une "colle" amusante à résoudre, ni à un "vrai défi" côté difficulté / performances. C'est très bien pour un débutant, les débutants "sérieux" devraient d'ailleurs tous faire ces défis. Mais bon, pour ma part, cela fait un moment que j'ai fini mes études, je n'ai guère envie de passer en mode "régression" pour refaire des choses que je maîtrise depuis dix ans.

Attitude "hacker" ? Sûrement. Si je suis le seul sur DVP à être ainsi, je veux bien être pendu...

Il y a aussi un aspect pédagogique à la chose.

Que je ne contredis pas, tu noteras... C'est pas non plus la peine de pré-mâcher intégralement le projet en question et rendre inutile la moindre réflexion de la part de celui qui l'étudie.
Suffisamment de doc (commentaires notamment) pour être compréhensible et pouvoir être repris. Ni plus, ni moins.
Fournir un document de conception complet, ce serait à faire si c'était un défi "Modélisation" ou "Gestion de projet" (il faudrait même d'autres docs, là, d'ailleurs). Là, c'est un défi C/C++ : le plus intéressant, ça reste le CODE.

un minimum de documentation explique les choix d'implémentation et le fonctionnement du programme.

Pourquoi faire ?
Le fonctionnement global du programme est donné par l'énoncé du défi, s'il est suffisamment détaillé / verrouillé.
Les choix d'implémentation ? Il y en a combien, sur un projet d'aussi petite taille ? Deux ou trois à tout casser ? Autant les mettre dans les commentaires du code !

Que ce soit à titre personnel, à titre professionnel ou collaboratif open source, un code source et/ou une application doit être commenté et son utilisation expliquée même succinctement.

Commentaires, je suis à 200% d'accord.
Utilisation ? Niet. L'énoncé est là pour ça. En milieu pro, j'appelle ça des specs / CdC... C'est suffisamment petit (et suffisamment verrouillé) pour qu'il soit inutile de faire un "manuel d'utilisation"...

Refuser de faire ne serait ce q'une 1 page de documentation est vraiment une insulte à ceux qui prennent bénevolement le temps de réfléchir au thèmes des défis, à les organiser, les fiares vivre et évaluer les projets notés.

En général, je commente suffisamment mon code pour faire l'équivalent de PLUSIEURS pages de doc... Notamment parce que j'ai pris l'habitude de toujours faire des blocs Doxygen dans mon code.

Je le répète, c'est un défi C/C++, pas un défi Word : l'intéressant, c'est le CODE, et ses commentaires bien entendu. Si l'explication du bouzin est dans un fichier séparé, ce sont des copier/coller inutiles de fait et/ou un gros risque d'incohérence entre la partie "papier" et le code...

Un peu de respect pour nos membres bénévoles qui font tout ca sur leur temps libre afin que la communauté puisse en profiter.

Heu, s'il te plait, n'exagère pas non plus : je n'ai manqué de respect à personne, j'ai donné MON point de vue sur les RAISONS qui font que réaliser ces défis ne m'intéresse pas (sous leur forme actuelle tout du moins), et je n'ai jeté la pierre à personne. Toutefois, ça m'intéresse suffisamment pour que j'aie envie de voir ces défis prendre une évolution qui les rendrait amusants...

Quant à être bénévole... C'est aussi mon cas, tu sais ?

[Luc Hermitte]

ce que tu montres, c'est pas des problèmes avec wchar_t mais avec wcin et wstring...

le type de donnée C wchar_t ainsi que les fonctions dédiées de manipualtion de chaines de caractères larges de la lib C fonctionnent tres bien sous gcc et sous windows.

Maintenant, que la surcouche C++ merdouille dans g++, c'est autre chsoe...

Faut pas tout mélanger ....

La partie C++ ... comme wprintf ?
Non, je t'assure, le support de ce qui dérive de wchar_t pour g++ ET gcc est incomplet sous cygwin/mingw.

[Vincent Rogier]

La partie C++ ... comme wprintf ?

!

wprintf() fonctionne très bien avec gcc...

La seule petite subtilité est le port windows de gcc, mingw, se base sur le runtime microsoft. Et comme Microsoft ne respecte pas la norme C en ce qui concerne les arguments (%s est considéré comme une chaine wide sous MS, alors que la norme veut %ls pour une chaine wide, ce que fait d'ailler gcc respecte sous unix !)

J'utilise wchar_t sous gcc (unix et windows) et ca fonctionne très bien !

Non, je t'assure, le support de ce qui dérive de wchar_t pour g++ ET gcc est incomplet sous cygwin/mingw.

Au lieu de me l'assurer, démontre le !

[Nogane]

gcc sous windows n'a jamais rien compris aux types dérivés de wchar_t. C'est un problème connu depuis un bout de temps. De temps à autres la question ressurgit sur la ML de cygwin.

La dernière version release est la gcc 3.4 et elle ne gere effectivement pas les wstring, w*stream, wcin et wcout. Mais la gcc 4.3 alpha les gère très bien. Je l'utilise tout les jour et elle fonctionne très bien.

Heu... Là, je crois que tu t'avances beaucoup, l'API Win32 est quand même plutôt volumineuse, spécifique et contient aussi bien des fonctions basiques (i.e. des ouvertures de fichier) que des fonctions de haut niveau (boîte de dialogue de sauvegarde / impression), des fonctions réseau, XML, thread, processus, etc.

En effet boost ne gère pas l'aspect graphique, ni le XML ni surement d'autre chose que fait l'API windows. Mais il gère quand même très bien le réseaux et les threads.
Je me suis surement un peu(beaucoup) avancé je le reconnait.

Sauf si le but du défi était justement de convertir de l'Unicode, il n'y avait aucune raison de passer plus de 20 secondes sur ce problème d'encodage.

Je suis d'accord, mais le problème c'est que ça faisais aussi partit du défi. Même si j'aurais préféré que ça ne sois pas le cas, et même si le titre du défi n'en donnai pas l'impression.

Toi, t'as pas assez mangé de C étant petit...
On s'en passe en fait très bien dans 90% des cas, j'ai toujours considéré la STL comme un outil pratique pour des choses non-critiques et/ou les programmes de test / faisabilité.
Pour le reste, essaie de remplir une map avec un million d'entrées et de l'utiliser ensuite, tu verras qu'il faut parfois aussi savoir "faire autrement" si l'on veut des performances.

Hihi^^
Bon je suis pas là pour faire l'apologie de la STL à quelqu'un qui sait certainement trés bien s'en passer. Sache seulement que j'ai commencé le C a 14 ans, et le C++ a 20, et que je suis pas du genre a codé qu'une fois de temps en temps.
Je suis d'accord qu'il FAUT savoir faire autrement et que la STL a ses limites. D'ailleur je serais tout a fait capable de (re)faire sans. Mais dans mon cas personel la STL/boost répondent a 99.9% a mais problème de structure de données, donc j'en use et j'en abuse avec joie. Et c'est surement de m'être galeré aussi longtemps en C qui me fait apprécier autant la STL. (Je précise que j'ai rien contre le C)

[Luc Hermitte]

OK. Au temps pour moi, c'est de plus en plus bizarre.
Le même petit programme, qui appelle wprintf, compilé avec g++ est refusé. Avec gcc il passe comme une lettre à la poste. :/

Il reste toutefois des erreurs de link sur fwprintf ou sur wscanf avec cygwin. Les symboles sont peut-être planqués dans une tierce bibliothèque ceci dit.


EDIT: Ca y est, voilà des faits qu'ils sont beaux: http://article.gmane.org/gmane.os.cy...8/match=wscanf

[ram-0000]

Bonsoir, je vais essayer de répondre point par point :

La contrainte de portabilité est très lourde sur plusieurs points : d'une part, cela présuppose d'avoir deux plate-formes installées chez soi pour le vérifier (ce qui n'est pas le cas). A titre personnel, je développe sur Windows, et je ne vais pas refuser d'utiliser l'API Win32 par pur masochisme...

La contrainte est aussi très forte pour les correcteurs, ils doivent pouvoir recompiler et exécuter les différents projets sans trop de problèmes. Un code à peu près portable écrit pour Linux afec GCC se recompilera sans problèmes ou alors avec quelques warnings seulement dans un environnement Microsoft Visual Studio. Cela tombe bien, j'utilise Visual Studio comme compilateur principal, je n'ai pas de machine Linux et malgré tout, j'ai pu corriger/recompiler/exécuter des défis écrit pour Linux. C'est quand même agréable.

Surtout quand je vois le format du fichier des stations qui a un goût de fichier INI bien prononcé.

En fait ma première idée était de fournir un fichier XML, finalement, je me suis rabattu sur un fichier texte avec une syntaxe proche de ce que j'ai l'habitude, c'est à dire un formalisme de fichier .INI. Ce formalisme n'est ni pire ni meiulleur qu'un autre, il a le mérite d'être simple, donc je l'utilise (et je l'ai aussi utilisé pour des projets sous Unix).

En plus, il y a incohérence côté règlement : "Environnement de dev libre", "écrit pour environnements Microsoft ou Linux" (et non pas "et"), et je n'ai pas vu le mot "portable" dans le règlement général...

C'est effectivement mal dit. Cette phrase veut simplement dire que l'on est libre de choisir l'environnement de développement que l'on veut tout en pensant que le correcteur n'utilisera peut être pas le même environnement ni la même plateforme.

La non-utilisation de bibliothèque peut se comprendre sur des librairies payantes et/ou en version d'essai / limitée. Elle n'est pas tolérable, à mon sens, sur une librairie gratuite.

Le but est tout simplement d'éviter que le correcteur ne perde du temps à configurer son poste pour ajouter la librairie adéquate. Cela permet de garantir que tous les projets pourront être examinés par les correcteurs.

Commenter son code, c'est normal. La documentation, par contre, a tendance à rebuter pas mal de gens vivant du développement si c'est pour quelque chose de personnel, "jetable" et ne faisant pas partie d'un projet que l'on maintient soi-même par goût.
Habituellement, c'est quand même LA corvée de base à faire, ou alors il va falloir accepter les CHM produits par Doxygen...

Le but de la documentation est de permettre de prendre en main rapidement le projet. Il ne faut pas oublier non plus que c'est la base d'un travail professionnel. Donc autant prendre les bonnes habitudes.

D'autre part, il ne faut pas exagérer, on demande de la documentation, c'est vrai mais ce n'est pas un concours littéraire non plus. Dans le cadre des défis, un simple fichier .txt suffit largement et n'enlève rien par rapport à celui qui livre une documentation rédigée avec Doxygen (il y en a eu dans le précédent défi). De la doc au format CHM ne me pose pas plus de problème non plus.

La distinction forte faite entre C et C++ me gêne un peu pour ma part, ayant une tendance naturelle à privilégier la solution la plus simple... Qui peut parfaitement être une fonction "C" utilisant des maps, vecteurs, etc. et non pas une méthode de classe. Ce n'est d'ailleurs pas du C, ça ne compilerait pas.
Or, là, j'ai tendance à lire "C++ = classes au taquet y compris quand ça ne sert à rien", et ça, ça me dérange, personnellement.

Initialement, les défis étaient pour le C uniquement. Quand je les ai repris il y a quelques mois, j'ai voulu agrandir l'audience en autorisant le C++ mais il faut reconnaitre que certaines choses sont plus faciles en C++ qu'en C (gestion des listes chainées par exemple). C'est donc la raison du Bonus C.
Maintenant, je suis d'accord avec toi, le C++ ce n'est pas que des classes au taquet, il peut y avoir aussi des fonction libres. Par contre, si on fait du C++, on utilise la librairie C++ (cin, cout, new, delete) et si on fait du C, on utilise la librairie C (printf, scanf, malloc, free). Un mélange des genres n'est pas d'un très bon goût.

Le défi en question (le 4ème) me fait plus l'impression d'un défi n'impliquant QUE des contraintes d'implémentation et non pas de conception... Cela aurait pu être amusant en devant implémenter l'algo de recherche soi-même, en n'utilisant ni boost, ni STL, ni Dijkstra, ou en ayant comme but d'être le plus rapide possible à l'exécution, bref quelque chose de plus "challenge".

En proposant ce défi, je savais qu'il y avait une solution "facile" avec boost mais peut être qu'il y aurait aussi d'autres idées intéressantes. Quand au problème de performance, vu la taille du métro parisien dans le défi, je ne pense pas qu'il y aura de grosses différence. Je pense qu'un algo type "brute force" fera aussi rapide que Dijkstra.

Quitte à poser des problèmes de portabilité, non-dépendance à des librairies, rigidité du langage, etc., un problème plus amusant serait de "nettoyer" un code existant.
En gros, prendre un truc-spaghetti, et le rendre propre, efficace, lever les dépendances de plate-forme, etc. en prenant comme critère d'efficacité le nombre de modifications apportées au code d'origine.

Pourquoi pas, c'est une idée.

Voilà, ce n'est que MON avis, qui n'engage QUE moi, mais en tout cas c'est rédhibitoire pour moi : je refuse de me taper les mêmes contraintes qu'au boulot pour un truc personnel censé m'amuser et me faire passer le temps...

Poser trop de contraintes de développement sur un tel défi enlève le côté "ludique" (donc qui "donne envie" de le faire) pour y introduire soit un côté "scolaire" (limite vexant pour un professionnel...), soit un côté "pro" (qui gâche le week-end...).

C'est ton droit le plus strict, ce qui me "rembourse" du temps que je passe à préparer ces défis et à les relire/corriger, c'est que d'autres personnes participent aux défis (et même y reviennent pour certains).

[Mac LAK]

j'utilise Visual Studio comme compilateur principal, je n'ai pas de machine Linux et malgré tout, j'ai pu corriger/recompiler/exécuter des défis écrit pour Linux. C'est quand même agréable.

Je suis d'accord avec toi. Cependant, même s'il y a "beaucoup" de compilateurs C/C++ sur le marché, on se retrouve assez vite limité à quelques uns seulement :

• Visual, souvent en version Express.
• GCC sous Linux, souvent la dernière release stable.
• MinGW sous Windows, souvent la dernière release stable là aussi.
• C++ Builder / Borland C++

En dehors de ça, on tombe quand même dans le "cas rare", et là, je trouverais normal d'exiger la compatibilité avec l'un des compilateurs précité...
Après, ça doit quand même être possible de s'arranger avec des membres du staff DVP pour tester sur n'importe quelle plate-forme, je pense, non ?

Ce formalisme n'est ni pire ni meiulleur qu'un autre, il a le mérite d'être simple, donc je l'utilise (et je l'ai aussi utilisé pour des projets sous Unix).

Ce n'était pas une critique, juste que dans ce cas, vive l'API d'accès aux fichiers INI quand on est sous Windows, et bonjour la demi-galère sous Linux...

C'est effectivement mal dit. Cette phrase veut simplement dire que l'on est libre de choisir l'environnement de développement que l'on veut tout en pensant que le correcteur n'utilisera peut être pas le même environnement ni la même plateforme.

D'où le premier point : voir peut-être à limiter à certaines chaînes de compilation "seulement"...

Le but est tout simplement d'éviter que le correcteur ne perde du temps à configurer son poste pour ajouter la librairie adéquate. Cela permet de garantir que tous les projets pourront être examinés par les correcteurs.

Je m'auto-cite :

Ensuite, par rapport aux librairies, je pense qu'il serait bon d'avoir une liste des librairies "autorisées", ainsi que des API d'OS acceptées. Cette liste peut être "figée", ou au contraire enrichie / réduite à chaque défi.

Une fois une librairie autorisée, elle le "reste" jusqu'au bout, sauf défi requérant explicitement de ne pas l'utiliser... Cela réduit le temps de déploiement à presque rien.

Le but de la documentation est de permettre de prendre en main rapidement le projet. Il ne faut pas oublier non plus que c'est la base d'un travail professionnel. Donc autant prendre les bonnes habitudes.

Argument 100% pertinent pour un débutant.
Argument "goût du boulot quotidien sans la paie qui va avec" pour les non-débutants... Comme il l'a souvent été dit, beaucoup de ceux qui répondent ici sont des bénévoles, mais refaire pour ses loisirs ce que l'on fait déjà 50h par semaine, bof quoi...

D'autre part, il ne faut pas exagérer, on demande de la documentation, c'est vrai mais ce n'est pas un concours littéraire non plus.

J'ai tendance à être manichéen sur la doc : soit c'est complet, soit c'est juste les commentaires dans le code. Pas des commentaires genre "i=0; // on initialise i à zéro", bien entendu... L'habitude d'utiliser Doxygen, mes commentaires sont en même temps la doc de conception détaillée et le manuel utilisateur.
J'estime cela amplement suffisant, voire déjà "trop" : un algo textuel en plus ?? Heu... Cela voudrait donc dire que je vais être "corrigé" par quelqu'un qui ne sait pas lire du code commenté ?
Comprends que ça peut devenir limite vexant, quand même... Ce n'est pas une attaque personnelle ni une critique, je te dis juste l'impression que cela ME fait en lisant le règlement des défis.

mais il faut reconnaitre que certaines choses sont plus faciles en C++ qu'en C (gestion des listes chainées par exemple).

Mouais, si l'on veut... Ma librairie de listes chaînées "personnelle" en C doit dater d'au moins 15 ans, et continue de me rendre de bons et loyaux services... Je ne pense pas être le seul à avoir de telles librairies personnelles utilisées plus ou moins constamment, même si j'ai plus tendance à le faire en Delphi qu'en C.

Par contre, si on fait du C++, on utilise la librairie C++ (cin, cout, new, delete) et si on fait du C, on utilise la librairie C (printf, scanf, malloc, free). Un mélange des genres n'est pas d'un très bon goût.

Pas totalement faux, pas totalement vrai non plus... Mais admettons : là, c'est un débat de puristes, chaque opinion a ses avantages et inconvénients. Si ça se limite à ce genre de restrictions, c'est pas un problème trop gênant.

Je pense qu'un algo type "brute force" fera aussi rapide que Dijkstra.

Sûrement. Bien que pour ma part, j'aurais gardé un fichier d'entrée "spécial correction" sous le coude avec dix fois plus de stations histoire de stresser le programme...
Oui, je sais ce que tu vas dire, "sadique !". Merci...

C'est ton droit le plus strict, ce qui me "rembourse" du temps que je passe à préparer ces défis et à les relire/corriger, c'est que d'autres personnes participent aux défis (et même y reviennent pour certains).

Je le re-répète, ce n'est nullement une critique envers les organisateurs de façon générale, ni envers les sujets eux-mêmes... Ni même, d'ailleurs, sur le règlement tel qu'il est actuellement si c'est destiné à des débutants, afin de leur faire prendre de bonnes habitudes.
Simplement, j'explique pourquoi JE n'y participe pas (dans l'état actuel du moins), en précisant que je ne suis sûrement pas le seul à penser la même chose... Juste le seul (avec pfeuh) à l'écrire publiquement, ce qui peut expliquer pourquoi il y a finalement "peu" de participants :

• Beaucoup de débutants croient savoir développer, peu sont conscients d'avoir beaucoup à apprendre.
  Ceux qui participent aux défis en toute connaissance de cause, en rendant un projet vraiment correct et bien ficelé, méritent d'ailleurs de sincères félicitations pour avoir compris qu'on ne progresse pas en restant vissé sur sa chaise, imbu d'un savoir scolaire superficiel et en croyant que l'on n'a plus rien à apprendre.
  Or, des gens capables de se remettre en question, c'est rare... Je pense que beaucoup de débutants doivent juger le travail demandé par un défi comme "indignes d'eux" et/ou "trop facile" sans même envisager une seule seconde de le faire, en croyant déjà tout savoir et tout faire.
• Pour les pros, c'est l'aspect "comme au boulot" qui doit certainement rebuter et limiter la participation.

Pour le reste, je continue de penser que les défis sont d'excellentes idées, leur défaut majeur étant uniquement de ne pas "ratisser large" côté membres, c'est tout.
Mes posts dans ce topic ont pour seul et unique but de donner un début d'explication sur le faible nombre de participants, ni plus, ni moins.

[Climoo]

Je dois faire partie des exceptions, je suis un débutant (étudiant) qui trouvé le défi sympathique...
En ce qui concerne les problèmes de compatibilité etc, c'est vrai qu'il serait peut être possible d'assouplir un peu les règles... En même temps, il n'y a que pour ce défi que cela a posé problème il me semble (quand j'ai fait le défi de l'ane rouge, je n'avais même pas vérifié si mon code fonctionnait sous Windows, car la question ne se posait pas). Peut être, à défaut d'autoriser/exclure des librairies, proposer des défis qui n'en nécessitent pas... Mais en tout cas, je comprend assez bien le point de vue des organisateurs/correcteurs, qui n'ont pas envie de devoir chercher à droite à gauche les librairies qu'il faut. Donc le plus simple c'est sûr, et je rejoins Mac Lak sur ce point, serait de donner la liste exhaustive des librairies autorisées; comme ça les organisateurs les installent dès le début une fois pour toute, et puis ça devrait être bon.
Y'a surement plein de gens qui ont des idées de défis (en tout cas, on dirait), peut être créer un fil "idées de défi", serait une bonne chose. Et un jury désigné à l'avance pourrait aller piocher ici et là les bonnes choses et proposer un sujet... Enfin je sais pas, c'est juste une idée...

[ram-0000]

Le hors sujet qui avait débuté dans cette enfilade a été déplacé dans ce message : Petites dérives autour du 4eme défi
Prière de ne poster ici que ce qui concerne le 4eme défi