lut!!! on voit souvent du monde qui dit que tel version d'un algorithme est plus rapide qu'un autre ... comment fait on pour savoir le temps que met le programme a s'éxécuté???
merci!!

tu peux utiliser GetTickCount
ex :  
 

 
sinon, de maniere portable, tu peux utilise boost::timer  
(www.boost.org)
 

HUG!!!! euh je capte rien au site de boost et je sais meme pas quel est le truc a télécharger... si on pouvait m aider merci, sinon pareil la premiere solution avec DWORD, on fait comment pour l'utiliser?

Ce qui compte si tu veux comparer deux algorithmes, c'est principalement la complexité. Par exemple, pour un algorithme de tri, la complexité ca va etre le nombre de comparaisons réalisées pour trier une liste de longueur n. Dans la pratique on calcule rarement une complexité exacte, mais on sait l'estimer, et on sait comparer deux complexités : si j'ai un algo en O(n * log(n)) et un autre en O(n^2), et bien je sais que le premier algo est plus efficace ( je préviens que je simplifie quand meme pas mal ).

ah voila c bon, il me manquait le header windows.h!!
merci ca marche comme ca!
Sinon Ace17 je savais deja ca lol, mais je voulais un truc + exact !!
merci aussi!

man time
 
ça marche très bien aussi

euh ... ca s utilise comment ca man time ???

RDTSC ça marche aussi très bien

chui pas convaincu que Taz soit de cet avis o_O
me semblait qu'il fallait laisser les flux gérer leurs flush tout seul

AMHA, c'est ce genre de débats qui fait du tord à C++. Ecrire une fonction main qui fait Hello World et qui sattisfasse tout le monde est proche de l'impossible, et c'est bien dommage selon moi. '\n' ou endl ou std::endl sont tous parfaitement acceptables.

Je comprends maintenant pourquoi c'est si dur de poster du code sans s'en prendre plein la gueule

 
je suis pas d'accord, je fais expres de mettre '\n' systematiquement car utilisée std::endl à outrance est une tres mauvaise habitude, bs l'utilise pratiquement pas dans c++ 3e ed
surtout que generalement cout est "line buffered", et endl juste avant la fin du bloc main ca sert un peu a rien

je vois pas en quoi c'est une mauvaise habitude, franchement... si j'ai envie de flusher le buffer, j'ai le droit non ?
Stroustrup ne l'utilise peut être pas, mais Koenig & Moo l'utilisent à fond dans Accelerated C++, donc qui a raison et qui a tort ?

voila ce que ca dit sur cpptips
 

 
paroles d'hommes

de toute façon, c'est un débat stérile comme dit HelloWorld
certains utilisent le flush, d'autres non, c'est comme le mot clé "friend", certains l'utilisent, d'autres (dont moi) disent que c'est anti objet

pas de probleme, donc on impose pas son point de vue
 

j'ai pas imposé, je voulais juste faire remarquer que je trouvais le "\n" malvenu ici étant donné l'utilisation de la STL dans le code donné en exemple (quitte à utiliser la STL, autant l'utiliser jusqu'au bout)
de toutes façons, les gouts et les couleurs.... et ce bon à rien de Taz, jamais ici quand on a besoin de son avis

putain, l'enculage de mouche

par contre \n c moins long à taper que std::endl

Sauf que dans la pratique certains utilisent using namespace std, et donc on peut taper endl tout court, ce qui fait 4 caracteres, tout comme "\n"...
(les mouches n'ont qu'a bien se tenir)

notons qu'avec un clavier fr aussi le \ se fait par la pression de 2 touches (simultanément en plus), donc a ce niveau endl serait peut-être plus avantageux.

non mais je reve, j'ai posé la question sur le temps d'executtion justement pour réglé ce genre de question a la con, vous avez juste a tésté la rapidité de endl, "/n" et std:endl et vous verrez bien lequel est le meilleur

 
time nom_du_programme (en ligne de commande)
 
ça évite d'avoir à instrumenter le programme.
 
évidemment dès que ton programme gagne en complexité
c'est une bonne idée de l'instrumenter de toute façon.
(mais il faut être sioux pour mesurer les bonnes choses..)

Pour ceux qui auraient besoin de mesurer des délais très courts ET qui sont sous Windose (9X, NT/2k, XP), le plus précis - et de loin -
c'est la fonction "QueryPerformanceCounter". La précision est meilleure que la micro-seconde    (3.579.545 ticks par seconde sur mon PC), voir la valeur retournée par la fonction "QueryPerformanceFrequency" !!!
 
Attention, le compteur est remis à zéro au boot, le nombre de ticks retourné devient très vite colossal : il faut du 64 bits (sinon overflow au bout de 35 minutes pour les micro-secondes et 23 jours pour les milli-secondes. Aucun problème, par contre, pour les secondes qui tiennent plus de 68 ans avec 32 bits. Mais on peut passer cette fonction aussi en 64 bits pour l'homogénéité).
Pour la petite histoire, lorsque j'ai installé mes premières applications en clientèle, ça se plantait régulièrement un peu plus d'une fois par mois - programmes tournants 24h/24. Il fallait obligatoirement rebooter Windows pour que ça reparte. Mes timers en
milli-secondes tombait en overflow et passait alors en négatif, ça n'a pas été facile de trouver l'origine du problème...    
 
Assez causé, voici les sources.
"_i64" est un entier 64 bits ==> typedef __int64 _i64;
Mes sources sont pour C++ Builder, avec d'autres compilos comme Visual C++, il faut trouver l'équivalent de "__int64".
 

__int64 egalement sous vc++

et surtout des non signés, c'est mieux

RDTSC moi je dis, y'a pas plus précis pour mesurer le temps

 
le nombre de cycle, ouais, le temps je sais pas

bah, si tu connais le nombre de cycles et la fréquence de ta machine, tu peux calculer le temps

ya pas une histoire comme quoi on est obligé de refraichir la valeur de la frequence ?

wai, mais une telle précision est faussée par le multitache de la machine.

C'est sûr qu'avoir des timers hyper-précis (en-dessous de la milli ou micro-seconde) reste d'un intérêt très limité sous Windows ou tout autre système multi-tâche. Sans compter, le temps pris par la mesure elle-même. Pour être vraiment précis, il faut faire une moyenne sur plusieurs passes.
Perso, je n'emploi que mon timer en milli-seconde et il me sert avant tout à déclencher des traitements périodiques (tous les dixièmes de secondes appeller telle fonction).

Pour cris56 :
- [et surtout des non signés, c'est mieux]
Bof, ça risque vraiment pas de passer en négatif !
Et puis, c'est plus simple en signé lorsque tu fais des calculs entre les ticks ou pour avoir des "magic value" comme -1.
- [ya pas une histoire comme quoi on est obligé de
   refraichir la valeur de la frequence ?]
Pour faire un timer portable avec RDTSC, il faut déterminer la fréquence du proc au départ   . Et gaffe aux cas particuliers du style Intel SpeedStep ! Je pense que le RDTSC est utile surtout pour mesurer le nombre de cycle que prend une routine (hors interruptions). Il est top pour mesurer précisemment la fréquence du proc, ce que fait CPU-Z.