Parce que la seule représentation de la date de l'heure en C++ en C++ standard, c'est time_t. (Ou tm.) S'il veut une solution pûrement Windows, je ne peux pas l'aider (et strictement parlant, ce n'est pas ici qu'il faudrait démander). Vue la
time_t est heureusement supporté sur wintel (time_t time(time_t*)) mais à "l'inconvénient" de retourner un nb de sec. ... à convertir en st ruct tm via localtime(), puis ajuster les valeurs, pourquoi le mois est 0-basé et le jour 1-basé, ..., tout cela est très archaïque!
Je ne dis pas le contraire. C'est ce qu'exige la norme, ce qui fait que c'est ce qu'on trouve partout, mais c'est un domaine où la norme ne brille pas. On est resté à l'état des Unix des années 1980.
bref GetSystemTime(SYSTEMTIME*) est plus direct (sous wintel tjrs).
Je comprends bien. Et du moment que c'est du propre à Windows, on utilise les fonctions Windows pour le formatter.
Comme j'ai dit, je ne sais pas trop ce que cherche le posteur initial. Il a dit qu'il ne souhaitait pas utiliser GetDateFormat et GetTimeFormat. Est-ce qu'il cherche à faire portable, et ne sait simplement pas que SYSTEMTIME ne l'est pas ? Sinon, pourquoi récuser GetDateFormat et GetTimeFormat ?
faiblesse du support standard ici, je peux bien concevoir ce qu'on préfère une solution propre au système, mais avec un support plus complet. Mais il avait déjà répondu à Serge qu'il ne voulait pas GetDateFormat() et GetTimeFormat(). Et s'il ne veut pas les fonctions propre à Windows, évidemment, il va falloir qu'il utilise time_t et tm (et qu'il rénonce aux microsecondes:-().
ce n'est surement pas tant le caractère propre à windows, que le prop os même de Get/Date/Time/Format, ceux-ci utilisent une locale et produisent des sorties un peu trop littéraires, par exemple:
int GetDateFormat( LCID Locale, // locale DWORD dwFlags, // options CONST SYSTEMTIME *lpDate, // date LPCTSTR lpFormat, // date format LPTSTR lpDateStr, // formatted string buffer int cchDate // size of buffer ); (avec LCID=DWORD, DWORD=unsigned long, LPCTSTR=const char*, LPTSTR =char* (si non unicode))
fonctionne à peu près comme strftime avec des identifiants spécifiq ues (extraits: d Day of month as digits with no leading zero for single-digit days. dd Day of month as digits with leading zero for single-digit days. ddd Day of week as a three-letter abbreviation. [...] M Month as digits with no leading zero for single-digit months. etc, etc)
Trop littéraires ? Si c'est comme strftime, c'est aussi littéraire qu'on veut. Ou aussi peu, comme on veut.
bref, justement on peut avoir envie de s'en passer -- pour ne pas "chercher les options de formattage chaque fois dans la doc" !
Ça, effectivement, c'est un problème avec toutes ces chaînes de formattage. Mais si on veut un format bien précis, il faut souvent y passer.
la question des millisec. est annexe, ils sont indispensables dans peu de cas - chronométrage fin, qui à peu de chance de se satisfaire de SYSTEMTIME de toute façon (je préfèrerais une carte National Instr. dans ce cas).
Mais j'avoue que je ne sais pas au juste ce qu'il veut. Je n'ai pas la moindre idée ce que c'est SYSTEMTIME, par exemple. Mais
typedef struct _SYSTEMTIME { WORD wYear; WORD wMonth; WORD wDayOfWeek; WORD wDay; WORD wHour; WORD wMinute; WORD wSecond; WORD wMilliseconds; } SYSTEMTIME, *PSYSTEMTIME, *LPSYSTEMTIME; (WORD=unsigned short)
donc "l'avantage" de quelque chose près à l'emploi vs le nb de sec. depuis on-sait-jamais-quand.
Un tm, en somme, plutôt qu'un time_t. Dans la pratique, les deux ont leur utilité. J'ai aussi des applications où on aimerait avoir la date en nombre de jours depuis on-ne-sait-jamais-quand. (Encore que quand on calcule des intérêts, c'est encore plus complexe, parce que les banques ont décidé qu'il y a toujours trente jours dans un mois.)
[...]
C'est quoi, Vista ?
la dernière vache à lait de MS (sortie cette semaine) - et la derni ère vacherie pour des développeurs qui pleuront leur chères API sacrifi ées.
C-à-d qu'il va falloir réécrire toutes les applications encore une fois ? C'est la sécurité de l'emploi, quoi. :-)
-- James Kanze (Gabi Software) email: 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
Sylvain wrote:
James Kanze wrote on 01/12/2006 22:01:
Parce que la seule représentation de la date de l'heure en C++
en C++ standard, c'est time_t. (Ou tm.) S'il veut une solution
pûrement Windows, je ne peux pas l'aider (et strictement
parlant, ce n'est pas ici qu'il faudrait démander). Vue la
time_t est heureusement supporté sur wintel (time_t time(time_t*)) mais
à "l'inconvénient" de retourner un nb de sec. ... à convertir en st ruct
tm via localtime(), puis ajuster les valeurs, pourquoi le mois est
0-basé et le jour 1-basé, ..., tout cela est très archaïque!
Je ne dis pas le contraire. C'est ce qu'exige la norme, ce qui
fait que c'est ce qu'on trouve partout, mais c'est un domaine où
la norme ne brille pas. On est resté à l'état des Unix des
années 1980.
bref GetSystemTime(SYSTEMTIME*) est plus direct (sous wintel tjrs).
Je comprends bien. Et du moment que c'est du propre à Windows,
on utilise les fonctions Windows pour le formatter.
Comme j'ai dit, je ne sais pas trop ce que cherche le posteur
initial. Il a dit qu'il ne souhaitait pas utiliser GetDateFormat
et GetTimeFormat. Est-ce qu'il cherche à faire portable, et ne
sait simplement pas que SYSTEMTIME ne l'est pas ? Sinon,
pourquoi récuser GetDateFormat et GetTimeFormat ?
faiblesse du support standard ici, je peux bien concevoir ce
qu'on préfère une solution propre au système, mais avec un
support plus complet. Mais il avait déjà répondu à Serge qu'il
ne voulait pas GetDateFormat() et GetTimeFormat(). Et s'il ne
veut pas les fonctions propre à Windows, évidemment, il va
falloir qu'il utilise time_t et tm (et qu'il rénonce aux
microsecondes:-().
ce n'est surement pas tant le caractère propre à windows, que le prop os
même de Get/Date/Time/Format, ceux-ci utilisent une locale et produisent
des sorties un peu trop littéraires, par exemple:
int GetDateFormat(
LCID Locale, // locale
DWORD dwFlags, // options
CONST SYSTEMTIME *lpDate, // date
LPCTSTR lpFormat, // date format
LPTSTR lpDateStr, // formatted string buffer
int cchDate // size of buffer
);
(avec LCID=DWORD, DWORD=unsigned long, LPCTSTR=const char*, LPTSTR =char*
(si non unicode))
fonctionne à peu près comme strftime avec des identifiants spécifiq ues
(extraits:
d Day of month as digits with no leading zero for single-digit days.
dd Day of month as digits with leading zero for single-digit days.
ddd Day of week as a three-letter abbreviation. [...]
M Month as digits with no leading zero for single-digit months.
etc, etc)
Trop littéraires ? Si c'est comme strftime, c'est aussi
littéraire qu'on veut. Ou aussi peu, comme on veut.
bref, justement on peut avoir envie de s'en passer -- pour ne pas
"chercher les options de formattage chaque fois dans la doc" !
Ça, effectivement, c'est un problème avec toutes ces chaînes de
formattage. Mais si on veut un format bien précis, il faut
souvent y passer.
la question des millisec. est annexe, ils sont indispensables dans peu
de cas - chronométrage fin, qui à peu de chance de se satisfaire de
SYSTEMTIME de toute façon (je préfèrerais une carte National Instr. dans
ce cas).
Mais j'avoue que je ne sais pas au juste ce qu'il veut. Je n'ai
pas la moindre idée ce que c'est SYSTEMTIME, par exemple. Mais
typedef struct _SYSTEMTIME {
WORD wYear;
WORD wMonth;
WORD wDayOfWeek;
WORD wDay;
WORD wHour;
WORD wMinute;
WORD wSecond;
WORD wMilliseconds;
} SYSTEMTIME, *PSYSTEMTIME, *LPSYSTEMTIME;
(WORD=unsigned short)
donc "l'avantage" de quelque chose près à l'emploi vs le nb de sec.
depuis on-sait-jamais-quand.
Un tm, en somme, plutôt qu'un time_t. Dans la pratique, les deux
ont leur utilité. J'ai aussi des applications où on aimerait
avoir la date en nombre de jours depuis on-ne-sait-jamais-quand.
(Encore que quand on calcule des intérêts, c'est encore plus
complexe, parce que les banques ont décidé qu'il y a toujours
trente jours dans un mois.)
[...]
C'est quoi, Vista ?
la dernière vache à lait de MS (sortie cette semaine) - et la derni ère
vacherie pour des développeurs qui pleuront leur chères API sacrifi ées.
C-à-d qu'il va falloir réécrire toutes les applications encore
une fois ? C'est la sécurité de l'emploi, quoi. :-)
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
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
Parce que la seule représentation de la date de l'heure en C++ en C++ standard, c'est time_t. (Ou tm.) S'il veut une solution pûrement Windows, je ne peux pas l'aider (et strictement parlant, ce n'est pas ici qu'il faudrait démander). Vue la
time_t est heureusement supporté sur wintel (time_t time(time_t*)) mais à "l'inconvénient" de retourner un nb de sec. ... à convertir en st ruct tm via localtime(), puis ajuster les valeurs, pourquoi le mois est 0-basé et le jour 1-basé, ..., tout cela est très archaïque!
Je ne dis pas le contraire. C'est ce qu'exige la norme, ce qui fait que c'est ce qu'on trouve partout, mais c'est un domaine où la norme ne brille pas. On est resté à l'état des Unix des années 1980.
bref GetSystemTime(SYSTEMTIME*) est plus direct (sous wintel tjrs).
Je comprends bien. Et du moment que c'est du propre à Windows, on utilise les fonctions Windows pour le formatter.
Comme j'ai dit, je ne sais pas trop ce que cherche le posteur initial. Il a dit qu'il ne souhaitait pas utiliser GetDateFormat et GetTimeFormat. Est-ce qu'il cherche à faire portable, et ne sait simplement pas que SYSTEMTIME ne l'est pas ? Sinon, pourquoi récuser GetDateFormat et GetTimeFormat ?
faiblesse du support standard ici, je peux bien concevoir ce qu'on préfère une solution propre au système, mais avec un support plus complet. Mais il avait déjà répondu à Serge qu'il ne voulait pas GetDateFormat() et GetTimeFormat(). Et s'il ne veut pas les fonctions propre à Windows, évidemment, il va falloir qu'il utilise time_t et tm (et qu'il rénonce aux microsecondes:-().
ce n'est surement pas tant le caractère propre à windows, que le prop os même de Get/Date/Time/Format, ceux-ci utilisent une locale et produisent des sorties un peu trop littéraires, par exemple:
int GetDateFormat( LCID Locale, // locale DWORD dwFlags, // options CONST SYSTEMTIME *lpDate, // date LPCTSTR lpFormat, // date format LPTSTR lpDateStr, // formatted string buffer int cchDate // size of buffer ); (avec LCID=DWORD, DWORD=unsigned long, LPCTSTR=const char*, LPTSTR =char* (si non unicode))
fonctionne à peu près comme strftime avec des identifiants spécifiq ues (extraits: d Day of month as digits with no leading zero for single-digit days. dd Day of month as digits with leading zero for single-digit days. ddd Day of week as a three-letter abbreviation. [...] M Month as digits with no leading zero for single-digit months. etc, etc)
Trop littéraires ? Si c'est comme strftime, c'est aussi littéraire qu'on veut. Ou aussi peu, comme on veut.
bref, justement on peut avoir envie de s'en passer -- pour ne pas "chercher les options de formattage chaque fois dans la doc" !
Ça, effectivement, c'est un problème avec toutes ces chaînes de formattage. Mais si on veut un format bien précis, il faut souvent y passer.
la question des millisec. est annexe, ils sont indispensables dans peu de cas - chronométrage fin, qui à peu de chance de se satisfaire de SYSTEMTIME de toute façon (je préfèrerais une carte National Instr. dans ce cas).
Mais j'avoue que je ne sais pas au juste ce qu'il veut. Je n'ai pas la moindre idée ce que c'est SYSTEMTIME, par exemple. Mais
typedef struct _SYSTEMTIME { WORD wYear; WORD wMonth; WORD wDayOfWeek; WORD wDay; WORD wHour; WORD wMinute; WORD wSecond; WORD wMilliseconds; } SYSTEMTIME, *PSYSTEMTIME, *LPSYSTEMTIME; (WORD=unsigned short)
donc "l'avantage" de quelque chose près à l'emploi vs le nb de sec. depuis on-sait-jamais-quand.
Un tm, en somme, plutôt qu'un time_t. Dans la pratique, les deux ont leur utilité. J'ai aussi des applications où on aimerait avoir la date en nombre de jours depuis on-ne-sait-jamais-quand. (Encore que quand on calcule des intérêts, c'est encore plus complexe, parce que les banques ont décidé qu'il y a toujours trente jours dans un mois.)
[...]
C'est quoi, Vista ?
la dernière vache à lait de MS (sortie cette semaine) - et la derni ère vacherie pour des développeurs qui pleuront leur chères API sacrifi ées.
C-à-d qu'il va falloir réécrire toutes les applications encore une fois ? C'est la sécurité de l'emploi, quoi. :-)
-- James Kanze (Gabi Software) email: 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
