"time_t" sait gérer le temps jusqu'aux secondes.
Est-ce qu'il existe un outil plutôt standart pour gérer le temps et qui
sait travailler jusqu'aux millisecondes ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fabien LE LEZ
On Tue, 17 Nov 2009 18:32:21 +0100, TSalm :
Est-ce qu'il existe un outil plutôt standart pour gérer le temps et qui sait travailler jusqu'aux millisecondes ?
En théorie, clock() devrait convenir. http://www.cplusplus.com/reference/clibrary/ctime/clock/
Toutefois, sous Windows, il est relativement difficile d'obtenir une résolution meilleure que 15 ou 16 millisecondes : il faut bricoler avec des fonctions spécifiques à Windows, comme QueryPerformanceCounter().
On Tue, 17 Nov 2009 18:32:21 +0100, TSalm <tsalm@free.fr>:
Est-ce qu'il existe un outil plutôt standart pour gérer le temps et qui
sait travailler jusqu'aux millisecondes ?
En théorie, clock() devrait convenir.
http://www.cplusplus.com/reference/clibrary/ctime/clock/
Toutefois, sous Windows, il est relativement difficile d'obtenir une
résolution meilleure que 15 ou 16 millisecondes : il faut bricoler
avec des fonctions spécifiques à Windows, comme
QueryPerformanceCounter().
Est-ce qu'il existe un outil plutôt standart pour gérer le temps et qui sait travailler jusqu'aux millisecondes ?
En théorie, clock() devrait convenir. http://www.cplusplus.com/reference/clibrary/ctime/clock/
Toutefois, sous Windows, il est relativement difficile d'obtenir une résolution meilleure que 15 ou 16 millisecondes : il faut bricoler avec des fonctions spécifiques à Windows, comme QueryPerformanceCounter().
TSalm
Le Tue, 17 Nov 2009 18:56:31 +0100, Fabien LE LEZ a écrit:
On Tue, 17 Nov 2009 18:32:21 +0100, TSalm :
Est-ce qu'il existe un outil plutôt standart pour gérer le temps et qui sait travailler jusqu'aux millisecondes ?
En théorie, clock() devrait convenir. http://www.cplusplus.com/reference/clibrary/ctime/clock/
Toutefois, sous Windows, il est relativement difficile d'obtenir une résolution meilleure que 15 ou 16 millisecondes : il faut bricoler avec des fonctions spécifiques à Windows, comme QueryPerformanceCounter().
Non, je voulais parler du temps dans le sens années,mois,jours,heures,minutes,secondes,millisecondes. Il me semble que ca tiendrait dans un <long long>, alors que <time_t> ne tiens que dans un <long> et ne gére que jusqu'aux secondes.
Le Tue, 17 Nov 2009 18:56:31 +0100, Fabien LE LEZ <gramster@gramster.com>
a écrit:
On Tue, 17 Nov 2009 18:32:21 +0100, TSalm <tsalm@free.fr>:
Est-ce qu'il existe un outil plutôt standart pour gérer le temps et qui
sait travailler jusqu'aux millisecondes ?
En théorie, clock() devrait convenir.
http://www.cplusplus.com/reference/clibrary/ctime/clock/
Toutefois, sous Windows, il est relativement difficile d'obtenir une
résolution meilleure que 15 ou 16 millisecondes : il faut bricoler
avec des fonctions spécifiques à Windows, comme
QueryPerformanceCounter().
Non, je voulais parler du temps dans le sens
années,mois,jours,heures,minutes,secondes,millisecondes.
Il me semble que ca tiendrait dans un <long long>, alors que <time_t> ne
tiens que dans un <long> et ne gére que jusqu'aux secondes.
Le Tue, 17 Nov 2009 18:56:31 +0100, Fabien LE LEZ a écrit:
On Tue, 17 Nov 2009 18:32:21 +0100, TSalm :
Est-ce qu'il existe un outil plutôt standart pour gérer le temps et qui sait travailler jusqu'aux millisecondes ?
En théorie, clock() devrait convenir. http://www.cplusplus.com/reference/clibrary/ctime/clock/
Toutefois, sous Windows, il est relativement difficile d'obtenir une résolution meilleure que 15 ou 16 millisecondes : il faut bricoler avec des fonctions spécifiques à Windows, comme QueryPerformanceCounter().
Non, je voulais parler du temps dans le sens années,mois,jours,heures,minutes,secondes,millisecondes. Il me semble que ca tiendrait dans un <long long>, alors que <time_t> ne tiens que dans un <long> et ne gére que jusqu'aux secondes.
Fabien LE LEZ
On Tue, 17 Nov 2009 19:03:03 +0100, TSalm :
Non, je voulais parler du temps dans le sens années,mois,jours,heures,minutes,secondes,millisecondes.
POSIX définit gettimeofday(). Mais comme d'hab', tu vas te heurter au fait que Windows n'est pas POSIX...
On Tue, 17 Nov 2009 19:03:03 +0100, TSalm <tsalm@free.fr>:
Non, je voulais parler du temps dans le sens
années,mois,jours,heures,minutes,secondes,millisecondes.
POSIX définit gettimeofday(). Mais comme d'hab', tu vas te heurter au
fait que Windows n'est pas POSIX...
Le Tue, 17 Nov 2009 20:19:36 +0100, Richard Delorme a écrit:
Le 17/11/2009 19:41, Fabien LE LEZ a écrit :
On Tue, 17 Nov 2009 19:17:13 +0100, Richard Delorme :
Sous Windows, il y a GetSystemTime()
...et Cygwin.
Pour une compatibilité POSIX, on doit pouvoir s'en passer. P.ex avec :
http://www.cadforte.com/system64.html
Merci pour vos réponses. Heureux utilisateur de MinGW, je dispose bien <sys/time.h>.
James Kanze
On Nov 17, 5:56 pm, Fabien LE LEZ wrote:
On Tue, 17 Nov 2009 18:32:21 +0100, TSalm :
>Est-ce qu'il existe un outil plutôt standart pour gérer le >temps et qui sait travailler jusqu'aux millisecondes ?
En théorie, clock() devrait convenir.http://www.cplusplus.com/reference/clibrary/ctime/clock/
Toutefois, sous Windows, il est relativement difficile d'obtenir une résolution meilleure que 15 ou 16 millisecondes : il faut bricoler avec des fonctions spécifiques à Windows, comme QueryPerformanceCounter().
La fonction clock() ne convient pas du tout, puisque d'une part, ce qu'elle est censée mesurer, c'est le temps CPU utilisé par le programme, et non le temps tout court, et de l'autre, la résolution n'est pas spécifiée, et est rarement jusqu'aux millisecondes. (Historiquement, dans les premiers Unix, où la fonction a vue le jour, CLOCKS_PER_SECOND était 50 ou 60, selon que la machine se trouvait en Europe ou aux États-unis. La norme Posix exige que CLOCKS_PER_SECOND vale 1000000, mais dit explicitement que la resolution dépend du système.)
Et sous Unix et sous Windows il y a des fonctions fournissant une meilleur résolution, mais elles ne sont pas portables.
-- James Kanze
On Nov 17, 5:56 pm, Fabien LE LEZ <grams...@gramster.com> wrote:
On Tue, 17 Nov 2009 18:32:21 +0100, TSalm <ts...@free.fr>:
>Est-ce qu'il existe un outil plutôt standart pour gérer le
>temps et qui sait travailler jusqu'aux millisecondes ?
En théorie, clock() devrait
convenir.http://www.cplusplus.com/reference/clibrary/ctime/clock/
Toutefois, sous Windows, il est relativement difficile
d'obtenir une résolution meilleure que 15 ou 16 millisecondes
: il faut bricoler avec des fonctions spécifiques à Windows,
comme QueryPerformanceCounter().
La fonction clock() ne convient pas du tout, puisque d'une part,
ce qu'elle est censée mesurer, c'est le temps CPU utilisé par le
programme, et non le temps tout court, et de l'autre, la
résolution n'est pas spécifiée, et est rarement jusqu'aux
millisecondes. (Historiquement, dans les premiers Unix, où la
fonction a vue le jour, CLOCKS_PER_SECOND était 50 ou 60, selon
que la machine se trouvait en Europe ou aux États-unis. La norme
Posix exige que CLOCKS_PER_SECOND vale 1000000, mais dit
explicitement que la resolution dépend du système.)
Et sous Unix et sous Windows il y a des fonctions fournissant
une meilleur résolution, mais elles ne sont pas portables.
>Est-ce qu'il existe un outil plutôt standart pour gérer le >temps et qui sait travailler jusqu'aux millisecondes ?
En théorie, clock() devrait convenir.http://www.cplusplus.com/reference/clibrary/ctime/clock/
Toutefois, sous Windows, il est relativement difficile d'obtenir une résolution meilleure que 15 ou 16 millisecondes : il faut bricoler avec des fonctions spécifiques à Windows, comme QueryPerformanceCounter().
La fonction clock() ne convient pas du tout, puisque d'une part, ce qu'elle est censée mesurer, c'est le temps CPU utilisé par le programme, et non le temps tout court, et de l'autre, la résolution n'est pas spécifiée, et est rarement jusqu'aux millisecondes. (Historiquement, dans les premiers Unix, où la fonction a vue le jour, CLOCKS_PER_SECOND était 50 ou 60, selon que la machine se trouvait en Europe ou aux États-unis. La norme Posix exige que CLOCKS_PER_SECOND vale 1000000, mais dit explicitement que la resolution dépend du système.)
Et sous Unix et sous Windows il y a des fonctions fournissant une meilleur résolution, mais elles ne sont pas portables.
