salut, j'ai une petite idée pour tous ceux qui veulent progresser en c et c++  
on se rejoindrait sur ce forum et on decidrait d'un programme à realiser (seul) dans un delai imparti, et celui qui aura le programme le plus rapide (en cas d'egalité on tranchera sur la qualité du programme, quoique se cas de figure est peu probable) aura gagné le petit defi et il nous filera son programme en nous expliquant ses astuces
il y aura aussi des autre type de gagnant, comme par exemple, le programme le mieux penser, le programme le mieux structurer etc....
il y aura aussi des personnes experimentées pour nous aider en cas d eprobléme  
si vous voulez participer merci de poster un petit message sur ce forum en expliquant brievement ce que vous faites en 'c'  
merci  
ah oui pour l'instant les programmes seront faits en mode console grans debutants oblige :-)
_______________________________________________________________________
Tous ceux qui veulent participer merci de poster un message avec leur pseudo et leur niveau en c, débutant ou confirmé et je le rajouterais sur le premier message de ce forum on s'y retrouvera mieux
_______________________________________________________________________
 
 
 
participants :
 
debutants en c:
 
 -Rider62
 -Max2000
 -swixm
 -didier1809
 -Flaie
 
confirmés en c:
 
 -Deimos_
 -JagStang
 -BlackGoddess
 -Taz

je vais fouiller dans mes cours et vous faire des scans des exercices que j'ai eu l'année passée    

:-)
oué mais bon ya pas trop d'interré a faire ça, tu ne progressera pas mais les ennoncer des exos sa pourrrais servire
sa t'interése d'y participer?

Un effort du coté de l'orthographe stp, c'est vraiment abominable... mais l'idée est sympa, quand aura-t-on le premier énoncé?
Et quand tu dis le programme le plus petit, tu parles de la source ou du fichier executable?

depuis quand le plus petit programme en octect (tu dois parler de la source sans doute) est-il plus performant ?
 
parce qu'un gros truc bourrin de 3 lignes c'est nettement moins intéressant qu'un algo de 15 lignes bien pensé

Mais si, regarde

je parle du fichier executable
pour le premier enoncé j'attends qu'il y a plus de participants pour l'instant nous sommes 3 mais si vous voulez y participer merci de poster un petit message sur le lien que j'ai donné au dessus

 
   
 
oula !  
 
j'ai rien calé    
 
un truc recurcif qui s'appelle 2x  

 
et si on veut pas aller sur paipaicai ?

 
non, n fois

Et pourquoi pas ici?

pour moi le critère le plus important c'est la robustesse et la rapidité du code. le nombre de ligne de code n'est pas un critère

Oui, c'est pour montrer ca que j'ai posté fibonacci  
Le cas typique de l'algo hyper compact mais inutilisable

bah on m'a dit cela plusieurs fois sur d'autre forum, j'ai deja changé une fois, mais bon il y a plus de monde sur ce forum sans doute, je vais voir comment sa va se bidouiller

 
oué c'est sur mais j'ai fait des test en faisant un programme à la con mal foutu avec aucune fonction
et j'ai fait le même avec des fonctions dans des fichier .cpp et .h et à la compilation bah le fichier exe était de la même taille

on pourrais faire quoi comme aute critére que la taille du fichier exe, c'est pas evident de juger un programme sur sa rapidité et la robustesse surtout si il y a beaucoup de programme,mais je veux bien changer mais dite moi comment on pourrais faire pour "noter" un programme et declarer quelqu'un vainqueur

Mauvais critère.
Moyennant une convention de codage, je dirais plutot le plus petit nombre de lignes de code, et encore ça prouve pas que le code est élégant.

Perso mes algo les plus performants sont des codes générées par deroulement inline de boucle et pese pas loin des 500Ko chacun .... alors la taille de l'executable LOL

 
oué je c'est mais cetait le critére le plus simple
tu as une idée sur le critére?  
je viens de penser à une methode, ou pourrais faire une sorte de baréme, genre si il y a des fonction dans le programme, si le programme et bien structuré, claire, mais pour la rapidité je ne vois pas comment on peut faire

la rapidité ben tu bench la chose.
Ensuite tu fait des cat.
 
code elegant
code brutal etc ...
 
mais PAS LA TAILLE !

ok ok j'adandonne la taille :-)
heu j'ai pas trop compris ce que tu as dit :  
la rapidité ben tu bench la chose.  
Ensuite tu fait des cat.  
 
bench ok je comprend mais avec quoi on bench?
des cat, heu la je comprend pas

tu demandes à tes gars d'instrumenter leur code de maniére à sortir des temps d'execution.
Ensuite tu va avoir des gens avec des temps d'execution proche. Pour departager tu fais un gagnant avec le code le plus court, le plus elegant etc ...
 
Style festival de cannes : prix du public, prix du jury etc ...

ok  
instrumenter le code, comment on fait?
c'est a dire que par exemple on fait un compteur qui incremente a chaque operation ou fonction exécuter?

... tu debarques d'où o_O
 
gettimeofday sous nux
QueryPerformanceCOunter sous win32 ....

 
bah je ne c'est pas moi comment on instrumente un code de maniére à sortir des temps d'execution
je débute

 
Sans faire une selection sur la taille de l'exe, tu peux tout de meme mettre une contrainte sur cette taille, genre l'exe ne devra pas depasser 64 Ko (cela vous dis qquechose ? mmhhh =) )
 
Ceci permet de mettre une contrainte interressante, qui sans faire de selection sur la taille permet deja de filtrer les eventuels tricheurs

oué c'est bon j'ai capté comment faire pour un bench, mais je voyais pas comment sa allais marcher mais c'est bon pour le bench

 
oué ok bonne idée
mais bon normalement mon petit projet est pour les debutants, il faut de l'entrainement pour tricher

Alors, rider , tu proposes quoi comme sujet ?  

je veux bien mais y'a t'il des debutants ?
moi je debute je suis en train de chercher pour le bench

pour avoir un executable le plus petit possible il faut programmer au plus pas niveau, linker avec le moins de binaires possible
 
sous windows, un exe 100% win32 peu faire que qq ko, mais le mieux c'est de faire direct en asm
 
c'est quoi les conditions ? parce que se baser sur la taille de l'exe, ca implique que tous lesparticipants utilisent le meme compilateurs
je trouve pas ca tres interessant, ca nn'a aucun interet

maintenant c'est la rapidité du programme qui tranchera
et en cas d'egalité ce sera le programme le mieux penser qui gagnera, c'est mieux non?

oui, mais pour la rapidité ca devra etre tester sur la meme machine et compilé avec le meme compilo, on  y echappe pas

voici les nouvelles regles :
il y aura plusieurs types de victoire :
le programme le plus rapide
le programme le plus astucieux
le programme le plus elegant
le programme le plus clair
je pense que c'est mieux aprés toutes vos remarques

 
ok
Tu conseilles quel compilateur?

Bah faut arrêter pour la taille. Les plus grosses variations seront dues au compilo utilisé. Faut pisser pas mal de code pour faire 1Ko de binaire.
Mon critère serait le moins de lignes de codes en utilisant la STL, boost, ...
1 appel de fonction = 1 ligne de code (pour donner le droit de faire 1 ligne par argument pour rendre lisible). Genre si le mec fait une boucle for pour calculer un max => 4 / lignes face à 1 ligne pour std::max_element...

ca sera en C++ ?
 
pour les debutant je pense qu'il vaut meiux faire ca en C, c'est un langage tout a fais adapter a la condensation de code
 
rider62 > sous windows, vs2003

C'est justement parce que c'est adapté à la condensation de code que c'est pas une bonne idée pour les débutants.
Le compilo il optimize => il effectue la condensation, loop unrolling, inlining, et tout et tout... Et en fonction du compilo, l'exe de base pèse entre 25 et 350 Ko...

ok mais c'est quoi stl, boost je comprend pas

STL, c'est uen lib qui fait partie du standard C++
Boost c'en est une autre, non standard mais très utilisée, qui compense les lacunes du C++.