Tous les concours d'algorithmique et de programmation

@Paul : zut, il faudra donc que j'apprenne le pascal et que je m'inscrive en prépa :(
6h c'est beaucoup quand même : à part le C que je n'ai pas compris (et où il n'y a pas d'encadrement des valeurs de l'entrée !!), les exos sont faciles et les contraintes bien trop gentilles (sauf si le temps limite est très (très) bas :x)

@Artix : Le pascal est un langage qui n'a jamais existé, et qui n'existera jamais !

Faut savoir que pour le caml/Ocaml, le code était interprété et non compilé, donc par rapport à du C, faut compter un petit facteur multiplicatif. (M'enfin j'avoue ne pas avoir regardé de près les contraintes, qui n'étaient pas souvent indiquées.)

Pour le C un bourrin passait. Pour le D, c'est le gars avec moi qui a cherché et trouvé l'algo, et j'ai passé pas mal de temps à essayer de l'optimiser (en utilisant les set de caml Light notamment, qui ont apparemment une tendance à pas bien se comporter) car notre première version ne passait pas en temps. Sachant qu'1h après ils ont revu le temps pour cet exo et notre code passait -__-.
Le E c'est pas moi qui ai cherché l'algo, j'étais en train de chercher à optimiser le D quand le E est arrivé, et du coup j'ai dû débugger l'algo du gars avec qui j'ai fait le concours. Puis j'ai mis je ne sais combien de temps à bien comprendre le problème (je trouve pas que l'énoncé soit des plus clairs). Le F j'y ai quasiment pas touché, mais mon pote l'a résolu (j'étais en train de me débattre avec l'énoncé du D pendant ce temps...). Le G idem, et le H plus de temps.
Bilan : 15e, un peu décevant je trouve :/

Ça s'interprète aussi.

@TLN : Si t'arrives à implementer les fonctions inline et les templates sur plusieurs TU sans introduire de dépendances... Tu seras vénéré par tous les utilisateurs C++ sur terre... dommage que ce ne soit pas possible. C'est comme demander en C à ce qu'une macro soit appliqué dans une TU alors qu'elle a été declaré dans une autre.
Et ce n'est pas limité à g++, c'est dans le standard : n3225 14.7.2.4
"A declaration of a function template shall be in scope at the point of the explicit instantiation of the function template. A definition of the class or class template containing a member function template shall be in scope at the point of the explicit instantiation of the member function template. A definition of a class template or class member template shall be in scope at the point of the explicit instantiation of the class template or class member template. A definition of a class template shall be in scope at the point of an explicit instantiation of a member function or a static data member of the class template. A definition of a member class of a class template shall be in scope at the point of an explicit instantiation of the member class. If the declaration of the explicit instantiation names an implicitly-declared special member function (Clause 12), the program is ill-formed."
Export ajoute des dépendances et est donc completement innutile. Si vraiment on veut séparer l'interface de l'implementation, on peut toujours #include l'implémentation dans le header (c.f. H. Sutter). Et les imports en D (qui fonctionnent aussi avec les templates) génerent plus de dépendances que les #include C++.

Quand au troll, OCaml plus rapide que C++ et pourtant plus lent que le C, je m'abstiendrai de le feed en ce trolldi, mais si tu veux un code en assembleur qui affiche 42 et qui est plus lent que du Java, n'hesite pas à demander, je suis sûr que je peux faire. Je me demande d'ailleurs quels sont les facteurs appliqués à prologin.

« Faut savoir que pour le caml/Ocaml, le code était interprété et non compilé, donc par rapport à du C, faut compter un petit facteur multiplicatif. »
→ Euh ... ça se compile l'OCaml hein ... Et c'est même plus performant que le C++ (même si ça ne bat pas le C).

De toute façon g++ est vraiment un gros débile en matière de compilation (enfin je devrai plutôt accuser le linker : non mais sérieux implanter les templates + les fonctions inlines dans les header ?! è_é).

« Si t'arrives à implementer les fonctions inline et les templates sur plusieurs TU sans introduire de dépendances... Tu seras vénéré par tous les utilisateurs C++ sur terre... dommage que ce ne soit pas possible. C'est comme demander en C à ce qu'une macro soit appliqué dans une TU alors qu'elle a été declaré dans une autre »
→ Ouai ben justement ... le problème il vient de la compilation séparée qui t'empêche de faire des optimisations plus intelligentes. Sérieusement le concept était valable dans les années 50 quand on était limité à 256ko de RAM pour compiler ... ou encore pour les très gros projets qui mettent 100 ans à compiler (au hasard : noyau linux). Mais aujourd'hui pour la plupart des applications que l'utilisateur lambda peut faire de son programme, je pense qu'il gagnerait à ce qu'on lui compile tout son programme en une passe.

« Quand au troll, OCaml plus rapide que C++ et pourtant plus lent que le C, je m'abstiendrai de le feed en ce trolldi, mais si tu veux un code en assembleur qui affiche 42 et qui est plus lent que du Java, n'hesite pas à demander, je suis sûr que je peux faire. »
→ Oh oui, c'est facile. Moi aussi je peux faire un "for i = 0 to 10\^20 do {}; print 42" en assembleur qui sera plus lent qu'un "print 42" en java.
Non mais franchement. Vrai que j'exagère en disant que c'est plus rapide que le C++. Mais tu te prends rarement pire qu'un facteur 50 %. Et pour un programme équivalent dans les deux langages, tu auras souvent des performances équivalentes. Enfin vu tout ce qu'on peut faire en OCaml je pense que ce n'est pas un mauvais trade-off :p

Euh... C'est quoi un "TU"?

Je répète : "Faut savoir que le caml/Ocaml était interprété". J'ai pas dit "peut être", j'ai dis "était" !
Pour des raisons obscures, ils ont décidé de les interpréter, c'tout.

@TLN : Heuu… attend… la compilation séparée un problème ? C'est quoi ton alternative ? J'espère que c'est pas « on compile tout en une fois », que dans la vraie vie les softs ne font pas 20 lignes et ne servent pas à calculer le nombre de chemin pour un escargot sur une grille.

@alex3er : TU = Translation Unit
Typiquement un .cpp avec tous les includes remplacés par leur contenu. Et d'ailleurs c'est ça qui serait modifiable, remplacer la modularisation par inclusion textuelle par autre chose… Les modules n'ayant pas été retenus pour C++0x, il faudra attendre la prochaine norme pour avoir une alternative si cela est jugé nécessaire… mais cela avait déjà été discuté dans les années 90 pour C++98, j'ai le souvenir d'un paper Stroustrup à ce sujet, mais j'arrive plus à mettre la main dessus. :(

@epsilon : Ben honnêtement ... je demande à voir. Pour une bonne partie des softs qu'on utilise régulièrement, ça me paraît jouable. Enfin cela dit 'vrai que c'est peu réaliste comme solution.

Toujours est-il qu'il me semble qu'en C, y a pas besoin de foutre les fonctions inline dans les header, alors que c'est le cas en C++ :s (même si j'ignore pourquoi et je me dis que j'aurais dû faire plus de compile dans la vie \^\^)

inline ça veut dire que tu conseilles au compilo de macro-tiser ta fonction. Et pour qu'il recopie le code, il vaut mieux l'avoir. D'où le header.
Mais si tu veux, tu peux inclure le .cpp :x

Macro-tisons !

Il vaudrait mieux ne pas te cloner. Un seul exemplaire, c'est déjà trop.

J'ai voulu faire comme toi (c'est ton clone sur mon avatar d'ailleurs).

Rah jsuis nul, j'ai même pas réussi à gagner quelques points sur le probleme C...
???
Quelqu'un peut m'expliquer pourquoi je suis passé de 580 points à -75 pendant la phase challenge?

3 challenge perdus, sûrement.
Et on ne gagne pas "quelques points". Ou tu as tout juste, ou tu as 0.

Ah d'accord, le nombre de points dépend de l'heure de soumission?
Mais en fait non, jvois pas pourquoi c'est comme tu dis: pour le problème B, je donnais une mauvaise réponse à l'exemple 5, mais j'ai eu 300 et quelques dizaines de points.
Et puis, si on était obligé de faire tout juste pour avoir des points, la phase challenge ne servirait à rien ...
Sauf si quand on soumet pendant le coding, le code n'est pas testé, et qu'il n'est testé que pendant la system phase...

Un TU c'est un JE++.

-->[]