C'est-à-dire que l'erreur du code suivant ne peut pas être
supérieure à une seconde, quelle que soit la durée totale :
[...]
Alors là, tu rèves.
C'est-à-dire que l'erreur du code suivant ne peut pas être
supérieure à une seconde, quelle que soit la durée totale :
[...]
Alors là, tu rèves.
C'est-à-dire que l'erreur du code suivant ne peut pas être
supérieure à une seconde, quelle que soit la durée totale :
[...]
Alors là, tu rèves.
Autant que je
sache, Mac OS est un « Unix semblable », comme Linux
Autant que je
sache, Mac OS est un « Unix semblable », comme Linux
Autant que je
sache, Mac OS est un « Unix semblable », comme Linux
(D'ailleurs,
la valeur renvoyée par time() ici varie de jusqu'à une trentaine
de sécondes d'une machine à l'autre.
(D'ailleurs,
la valeur renvoyée par time() ici varie de jusqu'à une trentaine
de sécondes d'une machine à l'autre.
(D'ailleurs,
la valeur renvoyée par time() ici varie de jusqu'à une trentaine
de sécondes d'une machine à l'autre.
On 12 Sep 2005 00:37:13 -0700, "kanze" :(D'ailleurs, la valeur renvoyée par time() ici varie de
jusqu'à une trentaine de sécondes d'une machine à l'autre.
À cause du mauvais fonctionnement (voire de l'absence) du
système de synchronisation entre machines ?
On 12 Sep 2005 00:37:13 -0700, "kanze" <kanze@gabi-soft.fr>:
(D'ailleurs, la valeur renvoyée par time() ici varie de
jusqu'à une trentaine de sécondes d'une machine à l'autre.
À cause du mauvais fonctionnement (voire de l'absence) du
système de synchronisation entre machines ?
On 12 Sep 2005 00:37:13 -0700, "kanze" :(D'ailleurs, la valeur renvoyée par time() ici varie de
jusqu'à une trentaine de sécondes d'une machine à l'autre.
À cause du mauvais fonctionnement (voire de l'absence) du
système de synchronisation entre machines ?
Il existe des protocols pour synchroniser des horloges, mais je
ne sais pas ce qu'ils valent
Il existe des protocols pour synchroniser des horloges, mais je
ne sais pas ce qu'ils valent
Il existe des protocols pour synchroniser des horloges, mais je
ne sais pas ce qu'ils valent
bernard tatin wrote:j'utilise <ctime> dans mon prog mais la precision n'est pas
au rendez vous, plusieurs secondes sur une minute :-( n'y a
t'il pas une autre api plus precise.Soit t0 = time(0) et t1 = time(0). time(0) renvoie le nombre
de secondes depuis le 01/01/1970.
C'est vrai sous Unix, mais ce n'est certainement pas universel.
Selon la norme (C, mais inclue dans la norme C++ par
référence), time_t est un « arithmetic type capable of
representing times » et time() renvoie « the current clendar
time », mais « The encoding of the value is unspecified ».
(J'avoue que je trouve déjà le concepte d'un « calendar time »
amusant. Chez moi, le calendrier donne les dates, non l'heure.)
Moi aussi, ça me le fait.
Donc t0 et t1 sont précis à 1 seconde près.
Ce n'est pas dit. Ce n'est pas le cas sur ma machine Linux, par
exemple. Ni sur la machine Solaris ici au travail. (D'ailleurs,
la valeur renvoyée par time() ici varie de jusqu'à une trentaine
de sécondes d'une machine à l'autre. Ce qui ne va pas sans posé
de problèmes pour make -- l'heure qu'il voit sur les fichiers,
c'est l'heure du serveur de fichiers, ce qui fait qu'il trouve
souvent que la dernière modification du fichier a eu lieu dans
l'avenir.)
Correctement dit, sous Unix (et je crois sous Windows, mais pas
forcement ailleurs), time_t est un type entier (mais la norme C
permet aussi double) qui exprime l'heure et la date en unités
d'une séconde. La résolution n'est pas garantie par la norme
C/C++ ; ce n'est pas claire si elle est garantie par Posix. La
précision dépend de l'hardware qui donne l'heure, et est souvent
assez mauvaise.Cela signifie donc que t1 - t0 est précis à deux secondes
près, quelque soit la valeur de l'intervalle.
Encore : rien ne le dit. Selon la norme C/C++, t1 - t0 peut ne
rien signifier du tout. Sous MS-Dos, au niveau du système,
l'heure se représentait sur deux entiers de 16 bits, avec les
sécondes divisées par 2 sur les 5 bits de poids faibles, les
minutes sur les 6 qui suivaient, etc. L'utilisation direct de
ces deux mots sur une longue (avec éventuellement la date sur
les poids faible, même) serait tout à fait conforme. De même
qu'un time_t sur un double, avec l'unité d'un jour (mais je n'ai
jamais entendu parler d'une telle implémentation).
Si tu veux avoir la différence entre deux heures, de façon
portable, il faut se servir de la fonction difftime().
exact, je l'oublie toujours, celle-là.
Si la dérive sur une minute est supérieure à deux secondes,
alors il y a un problème soit avec l'horloge de la machine,
soit dans la méthode de mesure de la dérive. Il est aussi
possible que la machine soit vraiment surchargée par des
tâches de fond ou qu'elle swappe comme un PC sous Windows et
là, la mesure des intervalle et délicate, quelque soit la
méthode.
La dérive sur la plupart des systèmes que je connais est bien de
l'ordre de plusieurs secondes, voire plusieurs dizaines de
sécondes, par jour. (Il y a eu une exception, où on avait une
dérive garantie inférieur à une dizaines de picosécondes par an.
Mais on avait une carte entière pour implémenter l'horloge.)
Une dérive de 10 secondes sur 24 heures donne une dérive de 0.007
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
bernard tatin wrote:
j'utilise <ctime> dans mon prog mais la precision n'est pas
au rendez vous, plusieurs secondes sur une minute :-( n'y a
t'il pas une autre api plus precise.
Soit t0 = time(0) et t1 = time(0). time(0) renvoie le nombre
de secondes depuis le 01/01/1970.
C'est vrai sous Unix, mais ce n'est certainement pas universel.
Selon la norme (C, mais inclue dans la norme C++ par
référence), time_t est un « arithmetic type capable of
representing times » et time() renvoie « the current clendar
time », mais « The encoding of the value is unspecified ».
(J'avoue que je trouve déjà le concepte d'un « calendar time »
amusant. Chez moi, le calendrier donne les dates, non l'heure.)
Moi aussi, ça me le fait.
Donc t0 et t1 sont précis à 1 seconde près.
Ce n'est pas dit. Ce n'est pas le cas sur ma machine Linux, par
exemple. Ni sur la machine Solaris ici au travail. (D'ailleurs,
la valeur renvoyée par time() ici varie de jusqu'à une trentaine
de sécondes d'une machine à l'autre. Ce qui ne va pas sans posé
de problèmes pour make -- l'heure qu'il voit sur les fichiers,
c'est l'heure du serveur de fichiers, ce qui fait qu'il trouve
souvent que la dernière modification du fichier a eu lieu dans
l'avenir.)
Correctement dit, sous Unix (et je crois sous Windows, mais pas
forcement ailleurs), time_t est un type entier (mais la norme C
permet aussi double) qui exprime l'heure et la date en unités
d'une séconde. La résolution n'est pas garantie par la norme
C/C++ ; ce n'est pas claire si elle est garantie par Posix. La
précision dépend de l'hardware qui donne l'heure, et est souvent
assez mauvaise.
Cela signifie donc que t1 - t0 est précis à deux secondes
près, quelque soit la valeur de l'intervalle.
Encore : rien ne le dit. Selon la norme C/C++, t1 - t0 peut ne
rien signifier du tout. Sous MS-Dos, au niveau du système,
l'heure se représentait sur deux entiers de 16 bits, avec les
sécondes divisées par 2 sur les 5 bits de poids faibles, les
minutes sur les 6 qui suivaient, etc. L'utilisation direct de
ces deux mots sur une longue (avec éventuellement la date sur
les poids faible, même) serait tout à fait conforme. De même
qu'un time_t sur un double, avec l'unité d'un jour (mais je n'ai
jamais entendu parler d'une telle implémentation).
Si tu veux avoir la différence entre deux heures, de façon
portable, il faut se servir de la fonction difftime().
exact, je l'oublie toujours, celle-là.
Si la dérive sur une minute est supérieure à deux secondes,
alors il y a un problème soit avec l'horloge de la machine,
soit dans la méthode de mesure de la dérive. Il est aussi
possible que la machine soit vraiment surchargée par des
tâches de fond ou qu'elle swappe comme un PC sous Windows et
là, la mesure des intervalle et délicate, quelque soit la
méthode.
La dérive sur la plupart des systèmes que je connais est bien de
l'ordre de plusieurs secondes, voire plusieurs dizaines de
sécondes, par jour. (Il y a eu une exception, où on avait une
dérive garantie inférieur à une dizaines de picosécondes par an.
Mais on avait une carte entière pour implémenter l'horloge.)
Une dérive de 10 secondes sur 24 heures donne une dérive de 0.007
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
bernard tatin wrote:j'utilise <ctime> dans mon prog mais la precision n'est pas
au rendez vous, plusieurs secondes sur une minute :-( n'y a
t'il pas une autre api plus precise.Soit t0 = time(0) et t1 = time(0). time(0) renvoie le nombre
de secondes depuis le 01/01/1970.
C'est vrai sous Unix, mais ce n'est certainement pas universel.
Selon la norme (C, mais inclue dans la norme C++ par
référence), time_t est un « arithmetic type capable of
representing times » et time() renvoie « the current clendar
time », mais « The encoding of the value is unspecified ».
(J'avoue que je trouve déjà le concepte d'un « calendar time »
amusant. Chez moi, le calendrier donne les dates, non l'heure.)
Moi aussi, ça me le fait.
Donc t0 et t1 sont précis à 1 seconde près.
Ce n'est pas dit. Ce n'est pas le cas sur ma machine Linux, par
exemple. Ni sur la machine Solaris ici au travail. (D'ailleurs,
la valeur renvoyée par time() ici varie de jusqu'à une trentaine
de sécondes d'une machine à l'autre. Ce qui ne va pas sans posé
de problèmes pour make -- l'heure qu'il voit sur les fichiers,
c'est l'heure du serveur de fichiers, ce qui fait qu'il trouve
souvent que la dernière modification du fichier a eu lieu dans
l'avenir.)
Correctement dit, sous Unix (et je crois sous Windows, mais pas
forcement ailleurs), time_t est un type entier (mais la norme C
permet aussi double) qui exprime l'heure et la date en unités
d'une séconde. La résolution n'est pas garantie par la norme
C/C++ ; ce n'est pas claire si elle est garantie par Posix. La
précision dépend de l'hardware qui donne l'heure, et est souvent
assez mauvaise.Cela signifie donc que t1 - t0 est précis à deux secondes
près, quelque soit la valeur de l'intervalle.
Encore : rien ne le dit. Selon la norme C/C++, t1 - t0 peut ne
rien signifier du tout. Sous MS-Dos, au niveau du système,
l'heure se représentait sur deux entiers de 16 bits, avec les
sécondes divisées par 2 sur les 5 bits de poids faibles, les
minutes sur les 6 qui suivaient, etc. L'utilisation direct de
ces deux mots sur une longue (avec éventuellement la date sur
les poids faible, même) serait tout à fait conforme. De même
qu'un time_t sur un double, avec l'unité d'un jour (mais je n'ai
jamais entendu parler d'une telle implémentation).
Si tu veux avoir la différence entre deux heures, de façon
portable, il faut se servir de la fonction difftime().
exact, je l'oublie toujours, celle-là.
Si la dérive sur une minute est supérieure à deux secondes,
alors il y a un problème soit avec l'horloge de la machine,
soit dans la méthode de mesure de la dérive. Il est aussi
possible que la machine soit vraiment surchargée par des
tâches de fond ou qu'elle swappe comme un PC sous Windows et
là, la mesure des intervalle et délicate, quelque soit la
méthode.
La dérive sur la plupart des systèmes que je connais est bien de
l'ordre de plusieurs secondes, voire plusieurs dizaines de
sécondes, par jour. (Il y a eu une exception, où on avait une
dérive garantie inférieur à une dizaines de picosécondes par an.
Mais on avait une carte entière pour implémenter l'horloge.)
Une dérive de 10 secondes sur 24 heures donne une dérive de 0.007
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On 13 Sep 2005 00:07:09 -0700, "kanze" :Il existe des protocols pour synchroniser des horloges, mais
je ne sais pas ce qu'ils valent
Ça marche bien. Même en synchronisant ma machine via Internet
sur un serveur secondaire ("stratum 2"), j'ai une erreur de
l'ordre de la seconde au pire. Entre machines sur le même LAN,
on devrait obtenir une synchro précise à quelques dizaines de
microsecondes.
En prime, c'est un protocole manifestement répandu. Même le
routeur ADSL du bureau l'utilise pour régler son horloge
interne.
<http://ntp.isc.org/bin/view/Servers/WebHome>
(Tiens, puisqu'on en est dans le HS, si tu veux, je peux
t'ouvrir un espace web en .free.fr. J'en parle ici car je ne
sais pas trop si tu es joignable par email...)
On 13 Sep 2005 00:07:09 -0700, "kanze" <kanze@gabi-soft.fr>:
Il existe des protocols pour synchroniser des horloges, mais
je ne sais pas ce qu'ils valent
Ça marche bien. Même en synchronisant ma machine via Internet
sur un serveur secondaire ("stratum 2"), j'ai une erreur de
l'ordre de la seconde au pire. Entre machines sur le même LAN,
on devrait obtenir une synchro précise à quelques dizaines de
microsecondes.
En prime, c'est un protocole manifestement répandu. Même le
routeur ADSL du bureau l'utilise pour régler son horloge
interne.
<http://ntp.isc.org/bin/view/Servers/WebHome>
(Tiens, puisqu'on en est dans le HS, si tu veux, je peux
t'ouvrir un espace web en .free.fr. J'en parle ici car je ne
sais pas trop si tu es joignable par email...)
On 13 Sep 2005 00:07:09 -0700, "kanze" :Il existe des protocols pour synchroniser des horloges, mais
je ne sais pas ce qu'ils valent
Ça marche bien. Même en synchronisant ma machine via Internet
sur un serveur secondaire ("stratum 2"), j'ai une erreur de
l'ordre de la seconde au pire. Entre machines sur le même LAN,
on devrait obtenir une synchro précise à quelques dizaines de
microsecondes.
En prime, c'est un protocole manifestement répandu. Même le
routeur ADSL du bureau l'utilise pour régler son horloge
interne.
<http://ntp.isc.org/bin/view/Servers/WebHome>
(Tiens, puisqu'on en est dans le HS, si tu veux, je peux
t'ouvrir un espace web en .free.fr. J'en parle ici car je ne
sais pas trop si tu es joignable par email...)
bernard tatin wrote:
Cela signifie donc que t1 - t0 est précis à deux secondes
près, quelque soit la valeur de l'intervalle.
Encore : rien ne le dit. Selon la norme C/C++, t1 - t0 peut
ne rien signifier du tout. Sous MS-Dos, au niveau du
système, l'heure se représentait sur deux entiers de 16
bits, avec les sécondes divisées par 2 sur les 5 bits de
poids faibles, les minutes sur les 6 qui suivaient, etc.
L'utilisation direct de ces deux mots sur une longue (avec
éventuellement la date sur les poids faible, même) serait
tout à fait conforme. De même qu'un time_t sur un double,
avec l'unité d'un jour (mais je n'ai jamais entendu parler
d'une telle implémentation).
Jusque là, les compilos que j'ai utilisé renvoient un entier
32 bits qui est le nombre de secondes depuis une date 0 (pas
toujours le 01/01/1970, il me semble bien que sous Windows, il
y ait une date utltérieure). Pour l'instant, je n'ai jamais vu
de float ou de double sur ce type.
Les types date de Microsoft (avec VB, par exemple) sont des
doubles. Cela pose des problèmes de précision parfois. Un
nombre entier de seconde (ou de fraction de seconde) permet
des calculs en entiers dont on connait les propriétés. Avec
les double, dès qu'on divise ou moultiplie par autre chose
qu'une puissance de 2, c'est le bordel. Je préfère le time_t
en entier!
Si tu veux avoir la différence entre deux heures, de façon
portable, il faut se servir de la fonction difftime().
exact, je l'oublie toujours, celle-là.
bernard tatin wrote:
Cela signifie donc que t1 - t0 est précis à deux secondes
près, quelque soit la valeur de l'intervalle.
Encore : rien ne le dit. Selon la norme C/C++, t1 - t0 peut
ne rien signifier du tout. Sous MS-Dos, au niveau du
système, l'heure se représentait sur deux entiers de 16
bits, avec les sécondes divisées par 2 sur les 5 bits de
poids faibles, les minutes sur les 6 qui suivaient, etc.
L'utilisation direct de ces deux mots sur une longue (avec
éventuellement la date sur les poids faible, même) serait
tout à fait conforme. De même qu'un time_t sur un double,
avec l'unité d'un jour (mais je n'ai jamais entendu parler
d'une telle implémentation).
Jusque là, les compilos que j'ai utilisé renvoient un entier
32 bits qui est le nombre de secondes depuis une date 0 (pas
toujours le 01/01/1970, il me semble bien que sous Windows, il
y ait une date utltérieure). Pour l'instant, je n'ai jamais vu
de float ou de double sur ce type.
Les types date de Microsoft (avec VB, par exemple) sont des
doubles. Cela pose des problèmes de précision parfois. Un
nombre entier de seconde (ou de fraction de seconde) permet
des calculs en entiers dont on connait les propriétés. Avec
les double, dès qu'on divise ou moultiplie par autre chose
qu'une puissance de 2, c'est le bordel. Je préfère le time_t
en entier!
Si tu veux avoir la différence entre deux heures, de façon
portable, il faut se servir de la fonction difftime().
exact, je l'oublie toujours, celle-là.
bernard tatin wrote:
Cela signifie donc que t1 - t0 est précis à deux secondes
près, quelque soit la valeur de l'intervalle.
Encore : rien ne le dit. Selon la norme C/C++, t1 - t0 peut
ne rien signifier du tout. Sous MS-Dos, au niveau du
système, l'heure se représentait sur deux entiers de 16
bits, avec les sécondes divisées par 2 sur les 5 bits de
poids faibles, les minutes sur les 6 qui suivaient, etc.
L'utilisation direct de ces deux mots sur une longue (avec
éventuellement la date sur les poids faible, même) serait
tout à fait conforme. De même qu'un time_t sur un double,
avec l'unité d'un jour (mais je n'ai jamais entendu parler
d'une telle implémentation).
Jusque là, les compilos que j'ai utilisé renvoient un entier
32 bits qui est le nombre de secondes depuis une date 0 (pas
toujours le 01/01/1970, il me semble bien que sous Windows, il
y ait une date utltérieure). Pour l'instant, je n'ai jamais vu
de float ou de double sur ce type.
Les types date de Microsoft (avec VB, par exemple) sont des
doubles. Cela pose des problèmes de précision parfois. Un
nombre entier de seconde (ou de fraction de seconde) permet
des calculs en entiers dont on connait les propriétés. Avec
les double, dès qu'on divise ou moultiplie par autre chose
qu'une puissance de 2, c'est le bordel. Je préfère le time_t
en entier!
Si tu veux avoir la différence entre deux heures, de façon
portable, il faut se servir de la fonction difftime().
exact, je l'oublie toujours, celle-là.
Seulement, par
expérience, je sais que s'il me faut constamment faire des ftp,
fichier par fichier, je ne le tiendrai pas à jour.
Seulement, par
expérience, je sais que s'il me faut constamment faire des ftp,
fichier par fichier, je ne le tiendrai pas à jour.
Seulement, par
expérience, je sais que s'il me faut constamment faire des ftp,
fichier par fichier, je ne le tiendrai pas à jour.
On 13 Sep 2005 09:18:56 -0700, "kanze" :Seulement, par expérience, je sais que s'il me faut
constamment faire des ftp, fichier par fichier, je ne le
tiendrai pas à jour.
Étant donné que le contenu n'est pas très gros, tu devrais
pouvoir faire un script qui uploade tout en bloc, non ?
On 13 Sep 2005 09:18:56 -0700, "kanze" <kanze@gabi-soft.fr>:
Seulement, par expérience, je sais que s'il me faut
constamment faire des ftp, fichier par fichier, je ne le
tiendrai pas à jour.
Étant donné que le contenu n'est pas très gros, tu devrais
pouvoir faire un script qui uploade tout en bloc, non ?
On 13 Sep 2005 09:18:56 -0700, "kanze" :Seulement, par expérience, je sais que s'il me faut
constamment faire des ftp, fichier par fichier, je ne le
tiendrai pas à jour.
Étant donné que le contenu n'est pas très gros, tu devrais
pouvoir faire un script qui uploade tout en bloc, non ?
