Quant aux typedef en question : effectivement, ça n'a plus de sens. Dans la mesure où le compilateur supportait __int64, à mon avis, ça n'avait pas de sens alors non plus -- ça dépend de toute façon de l'implémentation. (Il y a un truc curieux là dedans aussi. Je me serait attendu que DWORD soit un type 64 bits -- sur des machines modernes, un « mot » c'est bien au moins 32 bits. Et même bien avant... on avait BYTE (8 bits), HWORD (16 bits), WORD (32 bits) et DWORD (32 bits). Au moins, c'était l'utilisation courante à la fin des années 1970.)
Mais la WinAPI date de l'époque 16 bits, et donc WORD = 16 bits et DWORD 32. Il ont pas modifié la taille de ces types pour des raisons de compatibilité qu'on comprend bien: http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx
-- Aurélien Regat-Barrel
Quant aux typedef en question : effectivement, ça n'a plus de
sens. Dans la mesure où le compilateur supportait __int64, à mon
avis, ça n'avait pas de sens alors non plus -- ça dépend de
toute façon de l'implémentation. (Il y a un truc curieux là
dedans aussi. Je me serait attendu que DWORD soit un type 64
bits -- sur des machines modernes, un « mot » c'est bien au
moins 32 bits. Et même bien avant... on avait BYTE (8 bits),
HWORD (16 bits), WORD (32 bits) et DWORD (32 bits). Au moins,
c'était l'utilisation courante à la fin des années 1970.)
Mais la WinAPI date de l'époque 16 bits, et donc WORD = 16 bits et DWORD
32. Il ont pas modifié la taille de ces types pour des raisons de
compatibilité qu'on comprend bien:
http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx
Quant aux typedef en question : effectivement, ça n'a plus de sens. Dans la mesure où le compilateur supportait __int64, à mon avis, ça n'avait pas de sens alors non plus -- ça dépend de toute façon de l'implémentation. (Il y a un truc curieux là dedans aussi. Je me serait attendu que DWORD soit un type 64 bits -- sur des machines modernes, un « mot » c'est bien au moins 32 bits. Et même bien avant... on avait BYTE (8 bits), HWORD (16 bits), WORD (32 bits) et DWORD (32 bits). Au moins, c'était l'utilisation courante à la fin des années 1970.)
Mais la WinAPI date de l'époque 16 bits, et donc WORD = 16 bits et DWORD 32. Il ont pas modifié la taille de ces types pour des raisons de compatibilité qu'on comprend bien: http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx
-- Aurélien Regat-Barrel
Sylvain
kanze wrote on 12/04/2006 09:44:
__int64 n'est pas supporté par gcc (tjrs pas?)
Pourquoi doit-il le supporter ? C'est un type propre à l'implémentation Microsoft.
je n'ai pas dit qu'il "doit", je note que c'est un thème récurrent; "tjrs pas" signifie "c'est bien, il ne s'est pas renié, il n'a pas supporté par dépit cette infamie microsofienne"; ça va comme ça ?
En fait, le comité C a adopté le « long long » des milieux Unix, et le comité C++ suit -- « long long » fera partie de C++0x. Les derniers compilateurs Microsoft l'acceptent déjà (comme la quasi-totalité des compilateurs sous Unix).
en effet sous VC2005 (pas 98 'course).
[...]. (Il y a un truc curieux là dedans aussi. Je me serait attendu que DWORD soit un type 64 bits -- sur des machines modernes, un « mot » c'est bien au moins 32 bits. Et même bien avant... on avait BYTE (8 bits), HWORD (16 bits), WORD (32 bits) et DWORD (32 bits). Au moins, c'était l'utilisation courante à la fin des années 1970.)
[tu veux dire "DWORD (64 bits)]
c'est aussi la définition à laquelle je m'attendais, un "mot" correspond à la taille des registres du CPU; avec la génaralisation des CPU 64 bits, j'aurai préféré le contraire (plus de dépendance) mais une taille normée comme en Java.
avec un compilo M$ (et surement bcp d'autres), on a sizeof(LARGE_INTEGER) = sizeof(QuadPart) = sizeof(u) = 8 donc modifier un membre change forcement le membre aligné à la même adresse.
J'ai 16 sur la moitié des machines à ma disposition:-). (8 sur PC 32 bits Windows et PC 32 bits Linux, quelque soit le compilateur. 16 sur PC 64 bits Linux ou Sun Sparc Solaris -- aussi quelque soit le compilateur.)
d'où le "avec un compilo M$", par ailleurs "SetFilePointerEx" sous Solaris ...
Étant donné que l'union en question fait partie de l'API Windows, j'imagine que tous les compilateurs Windows s'arrangera pour qu'elle ait la même organistation en mémoire. En revanche, à part les PC, beaucoup de machines aujourd'hui sont à 64 bits,
oui, la plupart des machines non PC (donc 3 à 6% du parc) sont en 64 bits (et même depuis un bout de temps, Digital avant SUN par exemple); ne reste que 95% du parc qui utilise des 32 bits.
avec un long de 8 octets (et qui a besoin d'un alignement de 8), ce qui fait que le sizeof du struct est 16, et non 8.
ce n'est pas l'alignement qui génére 16, simplement les champs: un unsigned long "LowPart" de 8 octets + un [signed] long "HighPart" de 8 octets.
Sylvain.
kanze wrote on 12/04/2006 09:44:
__int64 n'est pas supporté par gcc (tjrs pas?)
Pourquoi doit-il le supporter ? C'est un type propre à
l'implémentation Microsoft.
je n'ai pas dit qu'il "doit", je note que c'est un thème récurrent;
"tjrs pas" signifie "c'est bien, il ne s'est pas renié, il n'a pas
supporté par dépit cette infamie microsofienne"; ça va comme ça ?
En fait, le comité C a adopté le « long long » des milieux Unix,
et le comité C++ suit -- « long long » fera partie de C++0x. Les
derniers compilateurs Microsoft l'acceptent déjà (comme la
quasi-totalité des compilateurs sous Unix).
en effet sous VC2005 (pas 98 'course).
[...]. (Il y a un truc curieux là
dedans aussi. Je me serait attendu que DWORD soit un type 64
bits -- sur des machines modernes, un « mot » c'est bien au
moins 32 bits. Et même bien avant... on avait BYTE (8 bits),
HWORD (16 bits), WORD (32 bits) et DWORD (32 bits). Au moins,
c'était l'utilisation courante à la fin des années 1970.)
[tu veux dire "DWORD (64 bits)]
c'est aussi la définition à laquelle je m'attendais, un "mot" correspond
à la taille des registres du CPU; avec la génaralisation des CPU 64
bits, j'aurai préféré le contraire (plus de dépendance) mais une taille
normée comme en Java.
avec un compilo M$ (et surement bcp d'autres), on a
sizeof(LARGE_INTEGER) = sizeof(QuadPart) = sizeof(u) = 8 donc
modifier un membre change forcement le membre aligné à la même
adresse.
J'ai 16 sur la moitié des machines à ma disposition:-). (8 sur
PC 32 bits Windows et PC 32 bits Linux, quelque soit le
compilateur. 16 sur PC 64 bits Linux ou Sun Sparc Solaris --
aussi quelque soit le compilateur.)
d'où le "avec un compilo M$", par ailleurs "SetFilePointerEx" sous
Solaris ...
Étant donné que l'union en question fait partie de l'API
Windows, j'imagine que tous les compilateurs Windows s'arrangera
pour qu'elle ait la même organistation en mémoire. En revanche,
à part les PC, beaucoup de machines aujourd'hui sont à 64 bits,
oui, la plupart des machines non PC (donc 3 à 6% du parc) sont en 64
bits (et même depuis un bout de temps, Digital avant SUN par exemple);
ne reste que 95% du parc qui utilise des 32 bits.
avec un long de 8 octets (et qui a besoin d'un alignement de 8),
ce qui fait que le sizeof du struct est 16, et non 8.
ce n'est pas l'alignement qui génére 16, simplement les champs: un
unsigned long "LowPart" de 8 octets + un [signed] long "HighPart" de 8
octets.
Pourquoi doit-il le supporter ? C'est un type propre à l'implémentation Microsoft.
je n'ai pas dit qu'il "doit", je note que c'est un thème récurrent; "tjrs pas" signifie "c'est bien, il ne s'est pas renié, il n'a pas supporté par dépit cette infamie microsofienne"; ça va comme ça ?
En fait, le comité C a adopté le « long long » des milieux Unix, et le comité C++ suit -- « long long » fera partie de C++0x. Les derniers compilateurs Microsoft l'acceptent déjà (comme la quasi-totalité des compilateurs sous Unix).
en effet sous VC2005 (pas 98 'course).
[...]. (Il y a un truc curieux là dedans aussi. Je me serait attendu que DWORD soit un type 64 bits -- sur des machines modernes, un « mot » c'est bien au moins 32 bits. Et même bien avant... on avait BYTE (8 bits), HWORD (16 bits), WORD (32 bits) et DWORD (32 bits). Au moins, c'était l'utilisation courante à la fin des années 1970.)
[tu veux dire "DWORD (64 bits)]
c'est aussi la définition à laquelle je m'attendais, un "mot" correspond à la taille des registres du CPU; avec la génaralisation des CPU 64 bits, j'aurai préféré le contraire (plus de dépendance) mais une taille normée comme en Java.
avec un compilo M$ (et surement bcp d'autres), on a sizeof(LARGE_INTEGER) = sizeof(QuadPart) = sizeof(u) = 8 donc modifier un membre change forcement le membre aligné à la même adresse.
J'ai 16 sur la moitié des machines à ma disposition:-). (8 sur PC 32 bits Windows et PC 32 bits Linux, quelque soit le compilateur. 16 sur PC 64 bits Linux ou Sun Sparc Solaris -- aussi quelque soit le compilateur.)
d'où le "avec un compilo M$", par ailleurs "SetFilePointerEx" sous Solaris ...
Étant donné que l'union en question fait partie de l'API Windows, j'imagine que tous les compilateurs Windows s'arrangera pour qu'elle ait la même organistation en mémoire. En revanche, à part les PC, beaucoup de machines aujourd'hui sont à 64 bits,
oui, la plupart des machines non PC (donc 3 à 6% du parc) sont en 64 bits (et même depuis un bout de temps, Digital avant SUN par exemple); ne reste que 95% du parc qui utilise des 32 bits.
avec un long de 8 octets (et qui a besoin d'un alignement de 8), ce qui fait que le sizeof du struct est 16, et non 8.
ce n'est pas l'alignement qui génére 16, simplement les champs: un unsigned long "LowPart" de 8 octets + un [signed] long "HighPart" de 8 octets.
Sylvain.
Sylvain
Aurelien Regat-Barrel wrote on 12/04/2006 11:19:
je préfère également cette seconde (car reinterpret_cast ne sert à rien), voire:
Je ne comprends pas ta remarque sur reinterpret_cast.
union_t *u = reinterpret_cast<union_t*>( &n );
ne "sert" à rien à la concision ni à la facilité de lecture du code.
Je préfère LONGLONG qu'un type spécifique VC++. Si j'écris un wrapper C++ à Win32 en utilisant les types Win32 plutôt que ceux de VC++, mon wrapper sera plus facilement utilisable sur d'autres compilos. Si MingW définit LONGLONG pour que ça marche, ça marchera.
certes, mon resentiment était plus à l'endroit des types capitalisés ... mais dans les 2 cas, un compilo non MS exigera un typedef ce qui ne change pas bcp l'histoire (et si ce compilo utilise les headers MS, il devra bien définir ce __int64).
Je parlais d'initialiser à la déclaration, et voulait savoir s'il était possible (et comment) d'initialiser le 2° ou 3° champ d'une union, à la déclaration toujours.
j'avais mal compris! les règles sont quasi les mêmes que pour une struct (sans union): vous pouvez initialiser de 0 à n champs, le fait spécifique à une union est qu'il n'y a pas n champs distincts pour n variables listées, donc:
LARGE_INTEGER li = { 1, 2 };
initialise bien LowPart à 1, HighPart à 2 et QuadPart à 200000001h ((high << 32) | low ou (high * 4294967296 + low) pour ceux qui ne savent pas compter en binaire)
tandis que:
LARGE_INTEGER li = { 1, 2, 3 };
provoquera une erreur de compil. car il y a plus d'initialiseurs que de champs à valoriser.
c'est donc possible mais cela présuppose une connaissance exacte de la déclaration de la struct (elle n'est jamais lointe ni prête de changer mais bon).
Sylvain.
Aurelien Regat-Barrel wrote on 12/04/2006 11:19:
je préfère également cette seconde (car reinterpret_cast ne sert à
rien), voire:
Je ne comprends pas ta remarque sur reinterpret_cast.
union_t *u = reinterpret_cast<union_t*>( &n );
ne "sert" à rien à la concision ni à la facilité de lecture du code.
Je préfère LONGLONG qu'un type spécifique VC++. Si j'écris un wrapper
C++ à Win32 en utilisant les types Win32 plutôt que ceux de VC++, mon
wrapper sera plus facilement utilisable sur d'autres compilos. Si MingW
définit LONGLONG pour que ça marche, ça marchera.
certes, mon resentiment était plus à l'endroit des types capitalisés ...
mais dans les 2 cas, un compilo non MS exigera un typedef ce qui ne
change pas bcp l'histoire (et si ce compilo utilise les headers MS, il
devra bien définir ce __int64).
Je parlais d'initialiser à la déclaration, et voulait savoir s'il était
possible (et comment) d'initialiser le 2° ou 3° champ d'une union, à la
déclaration toujours.
j'avais mal compris! les règles sont quasi les mêmes que pour une struct
(sans union): vous pouvez initialiser de 0 à n champs, le fait
spécifique à une union est qu'il n'y a pas n champs distincts pour n
variables listées, donc:
LARGE_INTEGER li = { 1, 2 };
initialise bien LowPart à 1, HighPart à 2 et QuadPart à 200000001h
((high << 32) | low ou (high * 4294967296 + low) pour ceux qui ne savent
pas compter en binaire)
tandis que:
LARGE_INTEGER li = { 1, 2, 3 };
provoquera une erreur de compil. car il y a plus d'initialiseurs que de
champs à valoriser.
c'est donc possible mais cela présuppose une connaissance exacte de la
déclaration de la struct (elle n'est jamais lointe ni prête de changer
mais bon).
je préfère également cette seconde (car reinterpret_cast ne sert à rien), voire:
Je ne comprends pas ta remarque sur reinterpret_cast.
union_t *u = reinterpret_cast<union_t*>( &n );
ne "sert" à rien à la concision ni à la facilité de lecture du code.
Je préfère LONGLONG qu'un type spécifique VC++. Si j'écris un wrapper C++ à Win32 en utilisant les types Win32 plutôt que ceux de VC++, mon wrapper sera plus facilement utilisable sur d'autres compilos. Si MingW définit LONGLONG pour que ça marche, ça marchera.
certes, mon resentiment était plus à l'endroit des types capitalisés ... mais dans les 2 cas, un compilo non MS exigera un typedef ce qui ne change pas bcp l'histoire (et si ce compilo utilise les headers MS, il devra bien définir ce __int64).
Je parlais d'initialiser à la déclaration, et voulait savoir s'il était possible (et comment) d'initialiser le 2° ou 3° champ d'une union, à la déclaration toujours.
j'avais mal compris! les règles sont quasi les mêmes que pour une struct (sans union): vous pouvez initialiser de 0 à n champs, le fait spécifique à une union est qu'il n'y a pas n champs distincts pour n variables listées, donc:
LARGE_INTEGER li = { 1, 2 };
initialise bien LowPart à 1, HighPart à 2 et QuadPart à 200000001h ((high << 32) | low ou (high * 4294967296 + low) pour ceux qui ne savent pas compter en binaire)
tandis que:
LARGE_INTEGER li = { 1, 2, 3 };
provoquera une erreur de compil. car il y a plus d'initialiseurs que de champs à valoriser.
c'est donc possible mais cela présuppose une connaissance exacte de la déclaration de la struct (elle n'est jamais lointe ni prête de changer mais bon).
Sylvain.
Sylvain
kanze wrote on 12/04/2006 09:47:
Il y a une éternité que Microsoft supporte des entiers 64 bits.
non, un tout petit peu moins, si tu veux une license VC 1.52 pour tester...
Sinon, quel est l'avantage de l'union sur une simple struct ?
tu veux dire d'unioner un offset 64 bits avec un offset 32 bits ?
- le fait que SetFilePointerEx (qui utilise l'union) est une extension de SetFilePointer qui n'utilise que des int32. - le fait que le déplacement dans un fichier se fait (généralement) modulo le secteur de bufferisation qui reste faible devant 2^32, dès lors une appli. peut s'autoriser à faire de l'arithmétique 32 bits en triturant le LowPart uniquement - une telle appli parse généralement un volume compressé où l'offset du fichier à atteindre est sur 64 bits mais le fichier lui-même de taille < à 2^32).
Sylvain.
kanze wrote on 12/04/2006 09:47:
Il y a une éternité que Microsoft supporte des entiers 64 bits.
non, un tout petit peu moins, si tu veux une license VC 1.52 pour tester...
Sinon, quel est l'avantage de l'union sur une simple struct ?
tu veux dire d'unioner un offset 64 bits avec un offset 32 bits ?
- le fait que SetFilePointerEx (qui utilise l'union) est une extension
de SetFilePointer qui n'utilise que des int32.
- le fait que le déplacement dans un fichier se fait (généralement)
modulo le secteur de bufferisation qui reste faible devant 2^32, dès
lors une appli. peut s'autoriser à faire de l'arithmétique 32 bits en
triturant le LowPart uniquement - une telle appli parse généralement un
volume compressé où l'offset du fichier à atteindre est sur 64 bits mais
le fichier lui-même de taille < à 2^32).
Il y a une éternité que Microsoft supporte des entiers 64 bits.
non, un tout petit peu moins, si tu veux une license VC 1.52 pour tester...
Sinon, quel est l'avantage de l'union sur une simple struct ?
tu veux dire d'unioner un offset 64 bits avec un offset 32 bits ?
- le fait que SetFilePointerEx (qui utilise l'union) est une extension de SetFilePointer qui n'utilise que des int32. - le fait que le déplacement dans un fichier se fait (généralement) modulo le secteur de bufferisation qui reste faible devant 2^32, dès lors une appli. peut s'autoriser à faire de l'arithmétique 32 bits en triturant le LowPart uniquement - une telle appli parse généralement un volume compressé où l'offset du fichier à atteindre est sur 64 bits mais le fichier lui-même de taille < à 2^32).
Sylvain.
Loïc Joly
LARGE_INTEGER li = { 1, 2 };
initialise bien LowPart à 1, HighPart à 2 et QuadPart à 200000001h ((high << 32) | low ou (high * 4294967296 + low) pour ceux qui ne savent pas compter en binaire)
Non, pas en C++. Peut-être dans une extention microsoft.
-- Loïc
LARGE_INTEGER li = { 1, 2 };
initialise bien LowPart à 1, HighPart à 2 et QuadPart à 200000001h
((high << 32) | low ou (high * 4294967296 + low) pour ceux qui ne savent
pas compter en binaire)
Non, pas en C++. Peut-être dans une extention microsoft.
initialise bien LowPart à 1, HighPart à 2 et QuadPart à 200000001h ((high << 32) | low ou (high * 4294967296 + low) pour ceux qui ne savent pas compter en binaire)
Non, pas en C++. Peut-être dans une extention microsoft.
-- Loïc
kanze
Sylvain wrote:
Étant donné que l'union en question fait partie de l'API Windows, j'imagine que tous les compilateurs Windows s'arrangera pour qu'elle ait la même organistation en mémoire. En revanche, à part les PC, beaucoup de machines aujourd'hui sont à 64 bits,
oui, la plupart des machines non PC (donc 3 à 6% du parc) sont en 64 bits (et même depuis un bout de temps, Digital avant SUN par exemple); ne reste que 95% du parc qui utilise des 32 bits.
Non. Si on ne compte que les machines, la plupart des machines non PC sont à 8 ou à 16 bits. Et elles sont bien plus nombreuses que les PC. J'ai dit « beaucoup », non la plupart.
En ce qui nous concerne, je ne suis pas certain que le nombre de machines est si important. Dans le monde imbriqué, on écrit un programme de 2000 lignes, et il tourne sur des centains de milliers de machines. De même, tu écris un programme « shrink wrapped » pour le PC, et il tourne sur énormement de machines aussi. Mais j'imagine (d'après les offres d'emploi sur le marché) travaille sur les applications maison, qui ne tournera que chez leur employeur. Or, si mes expériences sont typiques (et là, je ne sais pas), la configuration classique est un client/serveur, avec de plus en plus, IE ou Netscape comme client. Alors, Windows sert parfois pour les petits serveurs, mais dès que le système devient un peu grand, c'est Unix.
Enfin, je ne dirais pas qu'il y a plus de travail sur Unix que sur Windows, mais la différence n'est pas par rapport au nombre de machines.
-- 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
Sylvain wrote:
Étant donné que l'union en question fait partie de l'API
Windows, j'imagine que tous les compilateurs Windows
s'arrangera pour qu'elle ait la même organistation en
mémoire. En revanche, à part les PC, beaucoup de machines
aujourd'hui sont à 64 bits,
oui, la plupart des machines non PC (donc 3 à 6% du parc) sont
en 64 bits (et même depuis un bout de temps, Digital avant SUN
par exemple); ne reste que 95% du parc qui utilise des 32
bits.
Non. Si on ne compte que les machines, la plupart des machines
non PC sont à 8 ou à 16 bits. Et elles sont bien plus nombreuses
que les PC. J'ai dit « beaucoup », non la plupart.
En ce qui nous concerne, je ne suis pas certain que le nombre de
machines est si important. Dans le monde imbriqué, on écrit un
programme de 2000 lignes, et il tourne sur des centains de
milliers de machines. De même, tu écris un programme « shrink
wrapped » pour le PC, et il tourne sur énormement de machines
aussi. Mais j'imagine (d'après les offres d'emploi sur le
marché) travaille sur les applications maison, qui ne tournera
que chez leur employeur. Or, si mes expériences sont typiques
(et là, je ne sais pas), la configuration classique est un
client/serveur, avec de plus en plus, IE ou Netscape comme
client. Alors, Windows sert parfois pour les petits serveurs,
mais dès que le système devient un peu grand, c'est Unix.
Enfin, je ne dirais pas qu'il y a plus de travail sur Unix que
sur Windows, mais la différence n'est pas par rapport au nombre
de machines.
--
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
Étant donné que l'union en question fait partie de l'API Windows, j'imagine que tous les compilateurs Windows s'arrangera pour qu'elle ait la même organistation en mémoire. En revanche, à part les PC, beaucoup de machines aujourd'hui sont à 64 bits,
oui, la plupart des machines non PC (donc 3 à 6% du parc) sont en 64 bits (et même depuis un bout de temps, Digital avant SUN par exemple); ne reste que 95% du parc qui utilise des 32 bits.
Non. Si on ne compte que les machines, la plupart des machines non PC sont à 8 ou à 16 bits. Et elles sont bien plus nombreuses que les PC. J'ai dit « beaucoup », non la plupart.
En ce qui nous concerne, je ne suis pas certain que le nombre de machines est si important. Dans le monde imbriqué, on écrit un programme de 2000 lignes, et il tourne sur des centains de milliers de machines. De même, tu écris un programme « shrink wrapped » pour le PC, et il tourne sur énormement de machines aussi. Mais j'imagine (d'après les offres d'emploi sur le marché) travaille sur les applications maison, qui ne tournera que chez leur employeur. Or, si mes expériences sont typiques (et là, je ne sais pas), la configuration classique est un client/serveur, avec de plus en plus, IE ou Netscape comme client. Alors, Windows sert parfois pour les petits serveurs, mais dès que le système devient un peu grand, c'est Unix.
Enfin, je ne dirais pas qu'il y a plus de travail sur Unix que sur Windows, mais la différence n'est pas par rapport au nombre de machines.
-- 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
kanze
Loïc Joly wrote:
LARGE_INTEGER li = { 1, 2 };
initialise bien LowPart à 1, HighPart à 2 et QuadPart à 200000001h ((high << 32) | low ou (high * 4294967296 + low) pour ceux qui ne savent pas compter en binaire)
Non, pas en C++. Peut-être dans une extention microsoft.
Il initialisait bien LowPart à 1, et HighPart à 2. Formellement, ensuite, tout accès À QuadPart a un comportement indéfini, mais pratiquement, cette utilisation des unions est tellement répandue, je vois mal un compilateur où il ne marche pas.
Mais je crois qu'on parlait bien de l'API Windows. Parce que sinon, l'union n'a de toute façon peu de sens -- selon les options de compilation sur mon Sun, j'ai QuadPart soit 0x100000002, soit simplement 1, mais ça ne me viendrait pas à l'idée de me servir de cette union sur un Sparc (sous Solaris).
-- 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
Loïc Joly wrote:
LARGE_INTEGER li = { 1, 2 };
initialise bien LowPart à 1, HighPart à 2 et QuadPart à
200000001h ((high << 32) | low ou (high * 4294967296 + low)
pour ceux qui ne savent pas compter en binaire)
Non, pas en C++. Peut-être dans une extention microsoft.
Il initialisait bien LowPart à 1, et HighPart à 2. Formellement,
ensuite, tout accès À QuadPart a un comportement indéfini, mais
pratiquement, cette utilisation des unions est tellement
répandue, je vois mal un compilateur où il ne marche pas.
Mais je crois qu'on parlait bien de l'API Windows. Parce que
sinon, l'union n'a de toute façon peu de sens -- selon les
options de compilation sur mon Sun, j'ai QuadPart soit
0x100000002, soit simplement 1, mais ça ne me viendrait pas à
l'idée de me servir de cette union sur un Sparc (sous Solaris).
--
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
initialise bien LowPart à 1, HighPart à 2 et QuadPart à 200000001h ((high << 32) | low ou (high * 4294967296 + low) pour ceux qui ne savent pas compter en binaire)
Non, pas en C++. Peut-être dans une extention microsoft.
Il initialisait bien LowPart à 1, et HighPart à 2. Formellement, ensuite, tout accès À QuadPart a un comportement indéfini, mais pratiquement, cette utilisation des unions est tellement répandue, je vois mal un compilateur où il ne marche pas.
Mais je crois qu'on parlait bien de l'API Windows. Parce que sinon, l'union n'a de toute façon peu de sens -- selon les options de compilation sur mon Sun, j'ai QuadPart soit 0x100000002, soit simplement 1, mais ça ne me viendrait pas à l'idée de me servir de cette union sur un Sparc (sous Solaris).
-- 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
Sylvain
kanze wrote on 13/04/2006 12:54:
Sylvain wrote:
[...] En revanche, à part les PC, beaucoup de machines aujourd'hui sont à 64 bits,
oui, la plupart des machines non PC sont en 64 bits [...]
Non. Si on ne compte que les machines, la plupart des machines non PC sont à 8 ou à 16 bits. Et elles sont bien plus nombreuses que les PC. J'ai dit « beaucoup », non la plupart.
tu as (donc) dit "« beaucoup » sont 64 bits" et "« la plupart » sont 8 ou 16"; et je dirais même plus "avec un dominante pour le 8" si on tient compte de tous les micro-proc existants.
Enfin, je ne dirais pas qu'il y a plus de travail sur Unix que sur Windows, mais la différence n'est pas par rapport au nombre de machines.
en terme de temps CPU utile par type d'OS (un PC en entreprise passe bcp de temps à rien faire) je pense que cela s'équilibre bcp plus en effet.
Sylvain.
kanze wrote on 13/04/2006 12:54:
Sylvain wrote:
[...] En revanche, à part les PC, beaucoup de machines
aujourd'hui sont à 64 bits,
oui, la plupart des machines non PC sont en 64 bits [...]
Non. Si on ne compte que les machines, la plupart des machines
non PC sont à 8 ou à 16 bits. Et elles sont bien plus nombreuses
que les PC. J'ai dit « beaucoup », non la plupart.
tu as (donc) dit "« beaucoup » sont 64 bits" et "« la plupart » sont 8
ou 16"; et je dirais même plus "avec un dominante pour le 8" si on tient
compte de tous les micro-proc existants.
Enfin, je ne dirais pas qu'il y a plus de travail sur Unix que
sur Windows, mais la différence n'est pas par rapport au nombre
de machines.
en terme de temps CPU utile par type d'OS (un PC en entreprise passe bcp
de temps à rien faire) je pense que cela s'équilibre bcp plus en effet.
[...] En revanche, à part les PC, beaucoup de machines aujourd'hui sont à 64 bits,
oui, la plupart des machines non PC sont en 64 bits [...]
Non. Si on ne compte que les machines, la plupart des machines non PC sont à 8 ou à 16 bits. Et elles sont bien plus nombreuses que les PC. J'ai dit « beaucoup », non la plupart.
tu as (donc) dit "« beaucoup » sont 64 bits" et "« la plupart » sont 8 ou 16"; et je dirais même plus "avec un dominante pour le 8" si on tient compte de tous les micro-proc existants.
Enfin, je ne dirais pas qu'il y a plus de travail sur Unix que sur Windows, mais la différence n'est pas par rapport au nombre de machines.
en terme de temps CPU utile par type d'OS (un PC en entreprise passe bcp de temps à rien faire) je pense que cela s'équilibre bcp plus en effet.
Sylvain.
Sylvain
Sylvain wrote on 13/04/2006 21:21:
tu as (donc) dit "« beaucoup » sont 64 bits" et "« la plupart » sont 8 ou 16"; et je dirais même plus "avec un dominante pour le 8" si on tient compte de tous les micro-proc existants.
gasp, j'ai oublié le smiley !! espérons que la sémantique dupontesque (ou dupondesque) suffira.
Sylvain.
Sylvain wrote on 13/04/2006 21:21:
tu as (donc) dit "« beaucoup » sont 64 bits" et "« la plupart » sont 8
ou 16"; et je dirais même plus "avec un dominante pour le 8" si on tient
compte de tous les micro-proc existants.
gasp, j'ai oublié le smiley !!
espérons que la sémantique dupontesque (ou dupondesque) suffira.
tu as (donc) dit "« beaucoup » sont 64 bits" et "« la plupart » sont 8 ou 16"; et je dirais même plus "avec un dominante pour le 8" si on tient compte de tous les micro-proc existants.
gasp, j'ai oublié le smiley !! espérons que la sémantique dupontesque (ou dupondesque) suffira.
Sylvain.
TERENCE
"Sylvain" a écrit dans le message de news:443d636a$0$6668$
kanze wrote on 12/04/2006 09:44:
Je pense qu'il y a un malentendu.
avec un long de 8 octets (et qui a besoin d'un alignement de 8), ce qui fait que le sizeof du struct est 16, et non 8.
James dit les processeurs 64 bits ont des long de 8 octets. Ce qui implique un alignement sur 16 bits pour ces processeurs.
ce n'est pas l'alignement qui génére 16, simplement les champs: un unsigned long "LowPart" de 8 octets + un [signed] long "HighPart" de 8 octets.
Et là j'ai l'impression que tu parles d'un alignement de 16 octets.
"Sylvain" <noSpam@mail.net> a écrit dans le message de news:443d636a$0$6668$8fcfb975@news.wanadoo.fr...
kanze wrote on 12/04/2006 09:44:
Je pense qu'il y a un malentendu.
avec un long de 8 octets (et qui a besoin d'un alignement de 8),
ce qui fait que le sizeof du struct est 16, et non 8.
James dit les processeurs 64 bits ont des long de 8 octets.
Ce qui implique un alignement sur 16 bits pour ces processeurs.
ce n'est pas l'alignement qui génére 16, simplement les champs: un
unsigned long "LowPart" de 8 octets + un [signed] long "HighPart" de 8
octets.
Et là j'ai l'impression que tu parles d'un alignement de 16 octets.
