Si ton sentiment est confirmé, ça remet en cause le miens.
Ce type d'union est pas mal utilisé pour faciliter la
manipulation des octets d'une donnée quelconque.
Par qui ? C'est un comportement indéfini de lire un élément
de l'union autre que le dernier qu'on a écrit. Ça l'a
toujours été, et en général, ça ne marche pas avec beaucoup
de compilateurs ; par exemple, le compilateur voit que la
valeur écrite dan mon_t.l n'est jamais utilisée, et supprime
l'écriture.
J'ai deux exemples en tête. Un ancien, du temps de DOS, pour
la représentation des registres du CPU:
struct WORDREGS {
unsigned int ax, bx, cx, dx, si, di, cflag, flags;
};
struct BYTEREGS {
unsigned char al, ah, bl, bh, cl, ch, dl, dh;
};
union REGS {
struct WORDREGS x;
struct BYTEREGS h;
};
exemple d'utilisation:
http://perso.wanadoo.fr/olivier.lalorette/sys.htm
ou plus récent, dans le monde Windows, le type LARGE_INTEGER:
typedef union _LARGE_INTEGER {
struct {
DWORD LowPart;
LONG HighPart;
};
struct {
DWORD LowPart;
LONG HighPart; } u;
LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;
http://msdn.microsoft.com/library/en-us/winprog/winprog/large_integer_str.asp
Utilisé par SetFilePointerEx par exemple (equivalent de seek):
http://msdn.microsoft.com/library/en-us/fileio/fs/setfilepointer.asp
Le type LARGE_INTEGER est utilisé par de nombreux compilos
C/C++ sous Windows, et je pense que ça marche à chaque fois.
Si ton sentiment est confirmé, ça remet en cause le miens.
Ce type d'union est pas mal utilisé pour faciliter la
manipulation des octets d'une donnée quelconque.
Par qui ? C'est un comportement indéfini de lire un élément
de l'union autre que le dernier qu'on a écrit. Ça l'a
toujours été, et en général, ça ne marche pas avec beaucoup
de compilateurs ; par exemple, le compilateur voit que la
valeur écrite dan mon_t.l n'est jamais utilisée, et supprime
l'écriture.
J'ai deux exemples en tête. Un ancien, du temps de DOS, pour
la représentation des registres du CPU:
struct WORDREGS {
unsigned int ax, bx, cx, dx, si, di, cflag, flags;
};
struct BYTEREGS {
unsigned char al, ah, bl, bh, cl, ch, dl, dh;
};
union REGS {
struct WORDREGS x;
struct BYTEREGS h;
};
exemple d'utilisation:
http://perso.wanadoo.fr/olivier.lalorette/sys.htm
ou plus récent, dans le monde Windows, le type LARGE_INTEGER:
typedef union _LARGE_INTEGER {
struct {
DWORD LowPart;
LONG HighPart;
};
struct {
DWORD LowPart;
LONG HighPart; } u;
LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;
http://msdn.microsoft.com/library/en-us/winprog/winprog/large_integer_str.asp
Utilisé par SetFilePointerEx par exemple (equivalent de seek):
http://msdn.microsoft.com/library/en-us/fileio/fs/setfilepointer.asp
Le type LARGE_INTEGER est utilisé par de nombreux compilos
C/C++ sous Windows, et je pense que ça marche à chaque fois.
Si ton sentiment est confirmé, ça remet en cause le miens.
Ce type d'union est pas mal utilisé pour faciliter la
manipulation des octets d'une donnée quelconque.
Par qui ? C'est un comportement indéfini de lire un élément
de l'union autre que le dernier qu'on a écrit. Ça l'a
toujours été, et en général, ça ne marche pas avec beaucoup
de compilateurs ; par exemple, le compilateur voit que la
valeur écrite dan mon_t.l n'est jamais utilisée, et supprime
l'écriture.
J'ai deux exemples en tête. Un ancien, du temps de DOS, pour
la représentation des registres du CPU:
struct WORDREGS {
unsigned int ax, bx, cx, dx, si, di, cflag, flags;
};
struct BYTEREGS {
unsigned char al, ah, bl, bh, cl, ch, dl, dh;
};
union REGS {
struct WORDREGS x;
struct BYTEREGS h;
};
exemple d'utilisation:
http://perso.wanadoo.fr/olivier.lalorette/sys.htm
ou plus récent, dans le monde Windows, le type LARGE_INTEGER:
typedef union _LARGE_INTEGER {
struct {
DWORD LowPart;
LONG HighPart;
};
struct {
DWORD LowPart;
LONG HighPart; } u;
LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;
http://msdn.microsoft.com/library/en-us/winprog/winprog/large_integer_str.asp
Utilisé par SetFilePointerEx par exemple (equivalent de seek):
http://msdn.microsoft.com/library/en-us/fileio/fs/setfilepointer.asp
Le type LARGE_INTEGER est utilisé par de nombreux compilos
C/C++ sous Windows, et je pense que ça marche à chaque fois.
(Mais j'avoue
qu'une saloperie comme ça ne me donne pas envie de programmer
pour le système.)
(Mais j'avoue
qu'une saloperie comme ça ne me donne pas envie de programmer
pour le système.)
(Mais j'avoue
qu'une saloperie comme ça ne me donne pas envie de programmer
pour le système.)
On Sun, 09 Apr 2006 20:21:42 +0200, James Kanze :(Mais j'avoue
qu'une saloperie comme ça ne me donne pas envie de programmer
pour le système.)
Ben... si tu dois programmer sous Windows, tu feras comme tout
le monde : encapsuler les saloperies qui te sont
indispensables (et Dieu sait qu'il y en a un paquet !),
histoire de pouvoir programmer proprement dans le reste du
code...
On Sun, 09 Apr 2006 20:21:42 +0200, James Kanze <kanze.james@neuf.fr>:
(Mais j'avoue
qu'une saloperie comme ça ne me donne pas envie de programmer
pour le système.)
Ben... si tu dois programmer sous Windows, tu feras comme tout
le monde : encapsuler les saloperies qui te sont
indispensables (et Dieu sait qu'il y en a un paquet !),
histoire de pouvoir programmer proprement dans le reste du
code...
On Sun, 09 Apr 2006 20:21:42 +0200, James Kanze :(Mais j'avoue
qu'une saloperie comme ça ne me donne pas envie de programmer
pour le système.)
Ben... si tu dois programmer sous Windows, tu feras comme tout
le monde : encapsuler les saloperies qui te sont
indispensables (et Dieu sait qu'il y en a un paquet !),
histoire de pouvoir programmer proprement dans le reste du
code...
ou plus récent, dans le monde Windows, le type LARGE_INTEGER:
typedef union _LARGE_INTEGER {
struct {
DWORD LowPart;
LONG HighPart;
};
struct {
DWORD LowPart;
LONG HighPart; } u;
LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;
http://msdn.microsoft.com/library/en-us/winprog/winprog/large_integer_str.asp
Tu as dû perdre un nom quelque part en copiant. Tel que c'est
écrit, la première struct ne sert à rien -- je crois que le code
n'est même pas légal.
En supposant un nom derrière la première struct : sans savoir ce
que sont DWORD et LONG, c'est difficile à saisir ce qui se passe
ici.
Mais j'ai comme une doute qu'il s'agit aussi d'un
comportement indéfini par la norme, défini en revanche dans une
certaine impémentation pour qui sait quelle raison.
Utilisé par SetFilePointerEx par exemple (equivalent de seek):
http://msdn.microsoft.com/library/en-us/fileio/fs/setfilepointer.asp
Le type LARGE_INTEGER est utilisé par de nombreux compilos
C/C++ sous Windows, et je pense que ça marche à chaque fois.
Si ça fait partie de l'API du système, effectivement, un
compilateur n'oserait pas ne pas le faire marcher. (Mais j'avoue
qu'une saloperie comme ça ne me donne pas envie de programmer
pour le système.)
ou plus récent, dans le monde Windows, le type LARGE_INTEGER:
typedef union _LARGE_INTEGER {
struct {
DWORD LowPart;
LONG HighPart;
};
struct {
DWORD LowPart;
LONG HighPart; } u;
LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;
http://msdn.microsoft.com/library/en-us/winprog/winprog/large_integer_str.asp
Tu as dû perdre un nom quelque part en copiant. Tel que c'est
écrit, la première struct ne sert à rien -- je crois que le code
n'est même pas légal.
En supposant un nom derrière la première struct : sans savoir ce
que sont DWORD et LONG, c'est difficile à saisir ce qui se passe
ici.
Mais j'ai comme une doute qu'il s'agit aussi d'un
comportement indéfini par la norme, défini en revanche dans une
certaine impémentation pour qui sait quelle raison.
Utilisé par SetFilePointerEx par exemple (equivalent de seek):
http://msdn.microsoft.com/library/en-us/fileio/fs/setfilepointer.asp
Le type LARGE_INTEGER est utilisé par de nombreux compilos
C/C++ sous Windows, et je pense que ça marche à chaque fois.
Si ça fait partie de l'API du système, effectivement, un
compilateur n'oserait pas ne pas le faire marcher. (Mais j'avoue
qu'une saloperie comme ça ne me donne pas envie de programmer
pour le système.)
ou plus récent, dans le monde Windows, le type LARGE_INTEGER:
typedef union _LARGE_INTEGER {
struct {
DWORD LowPart;
LONG HighPart;
};
struct {
DWORD LowPart;
LONG HighPart; } u;
LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;
http://msdn.microsoft.com/library/en-us/winprog/winprog/large_integer_str.asp
Tu as dû perdre un nom quelque part en copiant. Tel que c'est
écrit, la première struct ne sert à rien -- je crois que le code
n'est même pas légal.
En supposant un nom derrière la première struct : sans savoir ce
que sont DWORD et LONG, c'est difficile à saisir ce qui se passe
ici.
Mais j'ai comme une doute qu'il s'agit aussi d'un
comportement indéfini par la norme, défini en revanche dans une
certaine impémentation pour qui sait quelle raison.
Utilisé par SetFilePointerEx par exemple (equivalent de seek):
http://msdn.microsoft.com/library/en-us/fileio/fs/setfilepointer.asp
Le type LARGE_INTEGER est utilisé par de nombreux compilos
C/C++ sous Windows, et je pense que ça marche à chaque fois.
Si ça fait partie de l'API du système, effectivement, un
compilateur n'oserait pas ne pas le faire marcher. (Mais j'avoue
qu'une saloperie comme ça ne me donne pas envie de programmer
pour le système.)
Pour moi
l'union c'est (entre autre) un autre moyen de faire du cast.
Ben non. Un union est juste un moyen d'économiser de la place, quand
on sait qu'à un moment donné d'un programme, on n'utilisera qu'une
partie des membres.
En fait, "union" n'est rien d'autre qu'une optimisation. Si, en
remplaçant "union" par "struct" partout dans ton code, le sens du
programme change, il y a des chances pour que ton code de départ ait
un comportement indéfini.
Par ailleurs, quand tu écris :
union union_t {
struct s {
short low;
short high;
} u;
long l;
};
tu as l'air de penser que sizeof(union_t::s)==sizeof(long).
Y a-t-il un argument qui justifierait cela ?
Pour moi
l'union c'est (entre autre) un autre moyen de faire du cast.
Ben non. Un union est juste un moyen d'économiser de la place, quand
on sait qu'à un moment donné d'un programme, on n'utilisera qu'une
partie des membres.
En fait, "union" n'est rien d'autre qu'une optimisation. Si, en
remplaçant "union" par "struct" partout dans ton code, le sens du
programme change, il y a des chances pour que ton code de départ ait
un comportement indéfini.
Par ailleurs, quand tu écris :
union union_t {
struct s {
short low;
short high;
} u;
long l;
};
tu as l'air de penser que sizeof(union_t::s)==sizeof(long).
Y a-t-il un argument qui justifierait cela ?
Pour moi
l'union c'est (entre autre) un autre moyen de faire du cast.
Ben non. Un union est juste un moyen d'économiser de la place, quand
on sait qu'à un moment donné d'un programme, on n'utilisera qu'une
partie des membres.
En fait, "union" n'est rien d'autre qu'une optimisation. Si, en
remplaçant "union" par "struct" partout dans ton code, le sens du
programme change, il y a des chances pour que ton code de départ ait
un comportement indéfini.
Par ailleurs, quand tu écris :
union union_t {
struct s {
short low;
short high;
} u;
long l;
};
tu as l'air de penser que sizeof(union_t::s)==sizeof(long).
Y a-t-il un argument qui justifierait cela ?
je peux caster comme en suivant ?
int n = 10;
union_t *u = reinterpret_cast<union_t*>( &n );
std::cout << u->i;
Si une petite union comme ça te fait hérisser le poil, VARIANT risque de
te causer un infarctus:
je peux caster comme en suivant ?
int n = 10;
union_t *u = reinterpret_cast<union_t*>( &n );
std::cout << u->i;
Si une petite union comme ça te fait hérisser le poil, VARIANT risque de
te causer un infarctus:
je peux caster comme en suivant ?
int n = 10;
union_t *u = reinterpret_cast<union_t*>( &n );
std::cout << u->i;
Si une petite union comme ça te fait hérisser le poil, VARIANT risque de
te causer un infarctus:
BOOL GetMessage (...)
La valeur de retour, de type BOOL, vaut :
If the function retrieves a message other than WM_QUIT, the
return value is nonzero.
If the function retrieves the WM_QUIT message, the return value
is zero.
If there is an error, the return value is -1.
Bien évidemment, pour que ça marche, "BOOL" est en fait un typedef sur
int. Et, pour simplifier le tout, il me semble que stricto sensu, -1
est une valeur "nonzero".
BOOL GetMessage (...)
La valeur de retour, de type BOOL, vaut :
If the function retrieves a message other than WM_QUIT, the
return value is nonzero.
If the function retrieves the WM_QUIT message, the return value
is zero.
If there is an error, the return value is -1.
Bien évidemment, pour que ça marche, "BOOL" est en fait un typedef sur
int. Et, pour simplifier le tout, il me semble que stricto sensu, -1
est une valeur "nonzero".
BOOL GetMessage (...)
La valeur de retour, de type BOOL, vaut :
If the function retrieves a message other than WM_QUIT, the
return value is nonzero.
If the function retrieves the WM_QUIT message, the return value
is zero.
If there is an error, the return value is -1.
Bien évidemment, pour que ça marche, "BOOL" est en fait un typedef sur
int. Et, pour simplifier le tout, il me semble que stricto sensu, -1
est une valeur "nonzero".
Fabien LE LEZ wrote on 10/04/2006 10:05:
BOOL GetMessage (...)
La valeur de retour, de type BOOL, vaut :
If the function retrieves a message other than WM_QUIT, the
return value is nonzero.
If the function retrieves the WM_QUIT message, the return value
is zero. If there is an error, the return value is -1.
Bien évidemment, pour que ça marche, "BOOL" est en fait un typedef sur
int. Et, pour simplifier le tout, il me semble que stricto sensu, -1
est une valeur "nonzero".
drole de façon de (ré)inventer l'histoire ?!
le type BOOL existe depuis windows 1.0 bien avant que GetMessage ne soit
modifié pour permettre la distinction d'erreur sévère, passons.
Fabien LE LEZ wrote on 10/04/2006 10:05:
BOOL GetMessage (...)
La valeur de retour, de type BOOL, vaut :
If the function retrieves a message other than WM_QUIT, the
return value is nonzero.
If the function retrieves the WM_QUIT message, the return value
is zero. If there is an error, the return value is -1.
Bien évidemment, pour que ça marche, "BOOL" est en fait un typedef sur
int. Et, pour simplifier le tout, il me semble que stricto sensu, -1
est une valeur "nonzero".
drole de façon de (ré)inventer l'histoire ?!
le type BOOL existe depuis windows 1.0 bien avant que GetMessage ne soit
modifié pour permettre la distinction d'erreur sévère, passons.
Fabien LE LEZ wrote on 10/04/2006 10:05:
BOOL GetMessage (...)
La valeur de retour, de type BOOL, vaut :
If the function retrieves a message other than WM_QUIT, the
return value is nonzero.
If the function retrieves the WM_QUIT message, the return value
is zero. If there is an error, the return value is -1.
Bien évidemment, pour que ça marche, "BOOL" est en fait un typedef sur
int. Et, pour simplifier le tout, il me semble que stricto sensu, -1
est une valeur "nonzero".
drole de façon de (ré)inventer l'histoire ?!
le type BOOL existe depuis windows 1.0 bien avant que GetMessage ne soit
modifié pour permettre la distinction d'erreur sévère, passons.
le type BOOL existe depuis windows 1.0 bien avant que GetMessage ne
soit modifié pour permettre la distinction d'erreur sévère, passons.
Pourquoi ne pas modifier la fonction pour qu'elle retourne un int (un
DWORD) dans ce cas ? Ca éviterai d'induire l'utilisateur en erreur, et
ne devrait pas casser de code existant.
le type BOOL existe depuis windows 1.0 bien avant que GetMessage ne
soit modifié pour permettre la distinction d'erreur sévère, passons.
Pourquoi ne pas modifier la fonction pour qu'elle retourne un int (un
DWORD) dans ce cas ? Ca éviterai d'induire l'utilisateur en erreur, et
ne devrait pas casser de code existant.
le type BOOL existe depuis windows 1.0 bien avant que GetMessage ne
soit modifié pour permettre la distinction d'erreur sévère, passons.
Pourquoi ne pas modifier la fonction pour qu'elle retourne un int (un
DWORD) dans ce cas ? Ca éviterai d'induire l'utilisateur en erreur, et
ne devrait pas casser de code existant.
Loïc Joly wrote on 10/04/2006 23:31:
le type BOOL existe depuis windows 1.0 bien avant que GetMessage ne
soit modifié pour permettre la distinction d'erreur sévère, passons.
Pourquoi ne pas modifier la fonction pour qu'elle retourne un int (un
DWORD) dans ce cas ? Ca éviterai d'induire l'utilisateur en erreur, et
ne devrait pas casser de code existant.
un "int" (type aliasé par "BOOL") est sur Intel 32 bits un type entier
signé sur 32 bits, un DWORD est un "unsigned long", ça fait déjà une
différence.
modifier le type retour d'une API préhistorique n'aurait pas été
imaginable (problème de compatibilité asc. même si l'impact est ici
assez faible, pas pire que le fait de ne pas traiter ces retours négatifs).
Loïc Joly wrote on 10/04/2006 23:31:
le type BOOL existe depuis windows 1.0 bien avant que GetMessage ne
soit modifié pour permettre la distinction d'erreur sévère, passons.
Pourquoi ne pas modifier la fonction pour qu'elle retourne un int (un
DWORD) dans ce cas ? Ca éviterai d'induire l'utilisateur en erreur, et
ne devrait pas casser de code existant.
un "int" (type aliasé par "BOOL") est sur Intel 32 bits un type entier
signé sur 32 bits, un DWORD est un "unsigned long", ça fait déjà une
différence.
modifier le type retour d'une API préhistorique n'aurait pas été
imaginable (problème de compatibilité asc. même si l'impact est ici
assez faible, pas pire que le fait de ne pas traiter ces retours négatifs).
Loïc Joly wrote on 10/04/2006 23:31:
le type BOOL existe depuis windows 1.0 bien avant que GetMessage ne
soit modifié pour permettre la distinction d'erreur sévère, passons.
Pourquoi ne pas modifier la fonction pour qu'elle retourne un int (un
DWORD) dans ce cas ? Ca éviterai d'induire l'utilisateur en erreur, et
ne devrait pas casser de code existant.
un "int" (type aliasé par "BOOL") est sur Intel 32 bits un type entier
signé sur 32 bits, un DWORD est un "unsigned long", ça fait déjà une
différence.
modifier le type retour d'une API préhistorique n'aurait pas été
imaginable (problème de compatibilité asc. même si l'impact est ici
assez faible, pas pire que le fait de ne pas traiter ces retours négatifs).
