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_s tr.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.
Non, je n'ai rien oublié. C'est juste que le compilo de MS
permettait de définir des structs (et même des unions)
anonymes.
Je suppose qu'à la base il ne devait y avoir que la première
struct (anonyme), et qu'il ont rajouté la seconde (identique
mais nommée) pour que ce soit un peu plus conforme à la norme,
tout en laissant la struct anonyme pour compatibilité
ascendante.
MingW définit LARGE_INTEGER ainsi:
typedef union _LARGE_INTEGER {
struct {
DWORD LowPart;
LONG HighPart;
} u;
#if ! defined(NONAMELESSUNION) || defined(__cplusplus)
_ANONYMOUS_STRUCT struct {
DWORD LowPart;
LONG HighPart;
};
#endif /* NONAMELESSUNION */
LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;
et dans windef.h (de MingW toujours):
#define _ANONYMOUS_UNION __extension__
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.
typedef unsigned long DWORD;
typedef long LONG;
typedef __int64 LONGLONG;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.
La doc de LARGE_INTERGER semble expliquer que ce type sert à
manipuler des entiers bits avec des compilateurs qui ne
disposent que d'entiers 32 bits.
Je modifie ma question. Si j'ai ceci:
union union_t
{
int i;
};
je peux caster comme en suivant ?
int n = 10;
union_t *u = reinterpret_cast<union_t*>( &n );
std::cout << u->i;
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.)
Si une petite union comme ça te fait hérisser le poil,
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_s tr.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.
Non, je n'ai rien oublié. C'est juste que le compilo de MS
permettait de définir des structs (et même des unions)
anonymes.
Je suppose qu'à la base il ne devait y avoir que la première
struct (anonyme), et qu'il ont rajouté la seconde (identique
mais nommée) pour que ce soit un peu plus conforme à la norme,
tout en laissant la struct anonyme pour compatibilité
ascendante.
MingW définit LARGE_INTEGER ainsi:
typedef union _LARGE_INTEGER {
struct {
DWORD LowPart;
LONG HighPart;
} u;
#if ! defined(NONAMELESSUNION) || defined(__cplusplus)
_ANONYMOUS_STRUCT struct {
DWORD LowPart;
LONG HighPart;
};
#endif /* NONAMELESSUNION */
LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;
et dans windef.h (de MingW toujours):
#define _ANONYMOUS_UNION __extension__
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.
typedef unsigned long DWORD;
typedef long LONG;
typedef __int64 LONGLONG;
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.
La doc de LARGE_INTERGER semble expliquer que ce type sert à
manipuler des entiers bits avec des compilateurs qui ne
disposent que d'entiers 32 bits.
Je modifie ma question. Si j'ai ceci:
union union_t
{
int i;
};
je peux caster comme en suivant ?
int n = 10;
union_t *u = reinterpret_cast<union_t*>( &n );
std::cout << u->i;
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.)
Si une petite union comme ça te fait hérisser le poil,
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_s tr.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.
Non, je n'ai rien oublié. C'est juste que le compilo de MS
permettait de définir des structs (et même des unions)
anonymes.
Je suppose qu'à la base il ne devait y avoir que la première
struct (anonyme), et qu'il ont rajouté la seconde (identique
mais nommée) pour que ce soit un peu plus conforme à la norme,
tout en laissant la struct anonyme pour compatibilité
ascendante.
MingW définit LARGE_INTEGER ainsi:
typedef union _LARGE_INTEGER {
struct {
DWORD LowPart;
LONG HighPart;
} u;
#if ! defined(NONAMELESSUNION) || defined(__cplusplus)
_ANONYMOUS_STRUCT struct {
DWORD LowPart;
LONG HighPart;
};
#endif /* NONAMELESSUNION */
LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;
et dans windef.h (de MingW toujours):
#define _ANONYMOUS_UNION __extension__
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.
typedef unsigned long DWORD;
typedef long LONG;
typedef __int64 LONGLONG;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.
La doc de LARGE_INTERGER semble expliquer que ce type sert à
manipuler des entiers bits avec des compilateurs qui ne
disposent que d'entiers 32 bits.
Je modifie ma question. Si j'ai ceci:
union union_t
{
int i;
};
je peux caster comme en suivant ?
int n = 10;
union_t *u = reinterpret_cast<union_t*>( &n );
std::cout << u->i;
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.)
Si une petite union comme ça te fait hérisser le poil,
Non, je n'ai rien oublié. C'est juste que le compilo de MS
permettait de définir des structs (et même des unions)
anonymes.
Les unions anonymes, ça fait partie du langage. Les structs
anonymes, non, mais je crois que Microsoft n'est pas le seul à
les supporter comme extension. Seulement, avoir une struct
anonyme, et une autre non, et que les deux aient les mêmes noms
de membre... Ça me semble un peu louche.Je suppose qu'à la base il ne devait y avoir que la première
struct (anonyme), et qu'il ont rajouté la seconde (identique
mais nommée) pour que ce soit un peu plus conforme à la norme,
tout en laissant la struct anonyme pour compatibilité
ascendante.
Deux structs anonymes ayant les mêmes noms de membre ne peut pas
aller. Logiquement. Si tu utilisais un des noms, de quelle
struct est-ce qu'il faut le tirer.
Je modifie ma question. Si j'ai ceci:union union_t
{
int i;
};je peux caster comme en suivant ?int n = 10;
union_t *u = reinterpret_cast<union_t*>( &n );
std::cout << u->i;
Formellement, non. Dans la pratique, oui. Mais pourquoi ?
Non, je n'ai rien oublié. C'est juste que le compilo de MS
permettait de définir des structs (et même des unions)
anonymes.
Les unions anonymes, ça fait partie du langage. Les structs
anonymes, non, mais je crois que Microsoft n'est pas le seul à
les supporter comme extension. Seulement, avoir une struct
anonyme, et une autre non, et que les deux aient les mêmes noms
de membre... Ça me semble un peu louche.
Je suppose qu'à la base il ne devait y avoir que la première
struct (anonyme), et qu'il ont rajouté la seconde (identique
mais nommée) pour que ce soit un peu plus conforme à la norme,
tout en laissant la struct anonyme pour compatibilité
ascendante.
Deux structs anonymes ayant les mêmes noms de membre ne peut pas
aller. Logiquement. Si tu utilisais un des noms, de quelle
struct est-ce qu'il faut le tirer.
Je modifie ma question. Si j'ai ceci:
union union_t
{
int i;
};
je peux caster comme en suivant ?
int n = 10;
union_t *u = reinterpret_cast<union_t*>( &n );
std::cout << u->i;
Formellement, non. Dans la pratique, oui. Mais pourquoi ?
Non, je n'ai rien oublié. C'est juste que le compilo de MS
permettait de définir des structs (et même des unions)
anonymes.
Les unions anonymes, ça fait partie du langage. Les structs
anonymes, non, mais je crois que Microsoft n'est pas le seul à
les supporter comme extension. Seulement, avoir une struct
anonyme, et une autre non, et que les deux aient les mêmes noms
de membre... Ça me semble un peu louche.Je suppose qu'à la base il ne devait y avoir que la première
struct (anonyme), et qu'il ont rajouté la seconde (identique
mais nommée) pour que ce soit un peu plus conforme à la norme,
tout en laissant la struct anonyme pour compatibilité
ascendante.
Deux structs anonymes ayant les mêmes noms de membre ne peut pas
aller. Logiquement. Si tu utilisais un des noms, de quelle
struct est-ce qu'il faut le tirer.
Je modifie ma question. Si j'ai ceci:union union_t
{
int i;
};je peux caster comme en suivant ?int n = 10;
union_t *u = reinterpret_cast<union_t*>( &n );
std::cout << u->i;
Formellement, non. Dans la pratique, oui. Mais pourquoi ?
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_s tr.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.
Non, je n'ai rien oublié. C'est juste que le compilo de MS
permettait de définir des structs (et même des unions)
anonymes.
Je suppose qu'à la base il ne devait y avoir que la première
struct (anonyme), et qu'il ont rajouté la seconde (identique
mais nommée) pour que ce soit un peu plus conforme à la norme,
tout en laissant la struct anonyme pour compatibilité
ascendante.
MingW définit LARGE_INTEGER ainsi:
typedef union _LARGE_INTEGER {
struct {
DWORD LowPart;
LONG HighPart;
} u;
#if ! defined(NONAMELESSUNION) || defined(__cplusplus)
_ANONYMOUS_STRUCT struct {
DWORD LowPart;
LONG HighPart;
};
#endif /* NONAMELESSUNION */
LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;
et dans windef.h (de MingW toujours):
#define _ANONYMOUS_UNION __extension__
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.
typedef unsigned long DWORD;
typedef long LONG;
typedef __int64 LONGLONG;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.
La doc de LARGE_INTERGER semble expliquer que ce type sert à
manipuler des entiers bits avec des compilateurs qui ne
disposent que d'entiers 32 bits.
Je modifie ma question. Si j'ai ceci:
union union_t
{
int i;
};
je peux caster comme en suivant ?
int n = 10;
union_t *u = reinterpret_cast<union_t*>( &n );
std::cout << u->i;
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.)
Si une petite union comme ça te fait hérisser le poil,
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_s tr.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.
Non, je n'ai rien oublié. C'est juste que le compilo de MS
permettait de définir des structs (et même des unions)
anonymes.
Je suppose qu'à la base il ne devait y avoir que la première
struct (anonyme), et qu'il ont rajouté la seconde (identique
mais nommée) pour que ce soit un peu plus conforme à la norme,
tout en laissant la struct anonyme pour compatibilité
ascendante.
MingW définit LARGE_INTEGER ainsi:
typedef union _LARGE_INTEGER {
struct {
DWORD LowPart;
LONG HighPart;
} u;
#if ! defined(NONAMELESSUNION) || defined(__cplusplus)
_ANONYMOUS_STRUCT struct {
DWORD LowPart;
LONG HighPart;
};
#endif /* NONAMELESSUNION */
LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;
et dans windef.h (de MingW toujours):
#define _ANONYMOUS_UNION __extension__
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.
typedef unsigned long DWORD;
typedef long LONG;
typedef __int64 LONGLONG;
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.
La doc de LARGE_INTERGER semble expliquer que ce type sert à
manipuler des entiers bits avec des compilateurs qui ne
disposent que d'entiers 32 bits.
Je modifie ma question. Si j'ai ceci:
union union_t
{
int i;
};
je peux caster comme en suivant ?
int n = 10;
union_t *u = reinterpret_cast<union_t*>( &n );
std::cout << u->i;
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.)
Si une petite union comme ça te fait hérisser le poil,
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_s tr.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.
Non, je n'ai rien oublié. C'est juste que le compilo de MS
permettait de définir des structs (et même des unions)
anonymes.
Je suppose qu'à la base il ne devait y avoir que la première
struct (anonyme), et qu'il ont rajouté la seconde (identique
mais nommée) pour que ce soit un peu plus conforme à la norme,
tout en laissant la struct anonyme pour compatibilité
ascendante.
MingW définit LARGE_INTEGER ainsi:
typedef union _LARGE_INTEGER {
struct {
DWORD LowPart;
LONG HighPart;
} u;
#if ! defined(NONAMELESSUNION) || defined(__cplusplus)
_ANONYMOUS_STRUCT struct {
DWORD LowPart;
LONG HighPart;
};
#endif /* NONAMELESSUNION */
LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;
et dans windef.h (de MingW toujours):
#define _ANONYMOUS_UNION __extension__
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.
typedef unsigned long DWORD;
typedef long LONG;
typedef __int64 LONGLONG;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.
La doc de LARGE_INTERGER semble expliquer que ce type sert à
manipuler des entiers bits avec des compilateurs qui ne
disposent que d'entiers 32 bits.
Je modifie ma question. Si j'ai ceci:
union union_t
{
int i;
};
je peux caster comme en suivant ?
int n = 10;
union_t *u = reinterpret_cast<union_t*>( &n );
std::cout << u->i;
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.)
Si une petite union comme ça te fait hérisser le poil,
Vu que INT et BOOL sont définis de même manière, je ne vois aucun impact
pour les utilisateurs.
Vu que INT et BOOL sont définis de même manière, je ne vois aucun impact
pour les utilisateurs.
Vu que INT et BOOL sont définis de même manière, je ne vois aucun impact
pour les utilisateurs.
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.)
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.)
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.)
bool SetFilePointerEx( LONGLONG DistanceToMove )
{
LARGE_INTEGER tmp;
tmp.QuadPart = DistanceToMove;
return ::SetFilePointerEx( tmp ) == TRUE;
}
pour info j'ai retenu la 2° écriture, mais je me demandais si la
première était valable.
Dernière question : peut-on initialiser un seul champ d'une union lors
de sa déclaration ?
bool SetFilePointerEx( LONGLONG DistanceToMove )
{
LARGE_INTEGER tmp;
tmp.QuadPart = DistanceToMove;
return ::SetFilePointerEx( tmp ) == TRUE;
}
pour info j'ai retenu la 2° écriture, mais je me demandais si la
première était valable.
Dernière question : peut-on initialiser un seul champ d'une union lors
de sa déclaration ?
bool SetFilePointerEx( LONGLONG DistanceToMove )
{
LARGE_INTEGER tmp;
tmp.QuadPart = DistanceToMove;
return ::SetFilePointerEx( tmp ) == TRUE;
}
pour info j'ai retenu la 2° écriture, mais je me demandais si la
première était valable.
Dernière question : peut-on initialiser un seul champ d'une union lors
de sa déclaration ?
Formellement, non. Dans la pratique, oui. Mais pourquoi ?
Pour sucharger SetFilePointerEx ainsi par exemple:
bool SetFilePointerEx( LONGLONG DistanceToMove )
{
return ::SetFilePointerEx(
*reinterpret_cast<LARGE_INTEGER*>( &DistanceToMove )
) == TRUE;
}
au lieu de:
bool SetFilePointerEx( LONGLONG DistanceToMove )
{
LARGE_INTEGER tmp;
tmp.QuadPart = DistanceToMove;
return ::SetFilePointerEx( tmp ) == TRUE;
}
pour info j'ai retenu la 2° écriture, mais je me demandais si
la première était valable.
Dernière question : peut-on initialiser un seul champ d'une
union lors de sa déclaration ?
Formellement, non. Dans la pratique, oui. Mais pourquoi ?
Pour sucharger SetFilePointerEx ainsi par exemple:
bool SetFilePointerEx( LONGLONG DistanceToMove )
{
return ::SetFilePointerEx(
*reinterpret_cast<LARGE_INTEGER*>( &DistanceToMove )
) == TRUE;
}
au lieu de:
bool SetFilePointerEx( LONGLONG DistanceToMove )
{
LARGE_INTEGER tmp;
tmp.QuadPart = DistanceToMove;
return ::SetFilePointerEx( tmp ) == TRUE;
}
pour info j'ai retenu la 2° écriture, mais je me demandais si
la première était valable.
Dernière question : peut-on initialiser un seul champ d'une
union lors de sa déclaration ?
Formellement, non. Dans la pratique, oui. Mais pourquoi ?
Pour sucharger SetFilePointerEx ainsi par exemple:
bool SetFilePointerEx( LONGLONG DistanceToMove )
{
return ::SetFilePointerEx(
*reinterpret_cast<LARGE_INTEGER*>( &DistanceToMove )
) == TRUE;
}
au lieu de:
bool SetFilePointerEx( LONGLONG DistanceToMove )
{
LARGE_INTEGER tmp;
tmp.QuadPart = DistanceToMove;
return ::SetFilePointerEx( tmp ) == TRUE;
}
pour info j'ai retenu la 2° écriture, mais je me demandais si
la première était valable.
Dernière question : peut-on initialiser un seul champ d'une
union lors de sa déclaration ?
Aurelien Regat-Barrel wrote on 11/04/2006 10:48:bool SetFilePointerEx( LONGLONG DistanceToMove )
{
LARGE_INTEGER tmp;
tmp.QuadPart = DistanceToMove;
return ::SetFilePointerEx( tmp ) == TRUE;
}
pour info j'ai retenu la 2° écriture, mais je me demandais si la
première était valable.
je préfère également cette seconde (car reinterpret_cast ne
sert à rien), voire:
bool setFilePointer(__int64 offset)
{
LARGE_INTEGER li;
li.QuadPart = offset;
return ::SetFilePointerEx(hFile, li, null, FILE_BEGIN) == TRUE);
}
__int64 n'est pas supporté par gcc (tjrs pas?)
mais c'est tjrs plus propre qu'un typedef M$ de plus; par
ailleurs c'est bien ici le but que de spécifier des offsets >
4 Go, un int64 en param. me parait + lisible (faute de "long
long").
Dernière question : peut-on initialiser un seul champ d'une
union lors de sa déclaration ?
c'est même ce qu'il faut faire - et non pas initialiser tous
les champs avec des valeurs non consistantes (eg initialiser à
0 les champs non (effectivement) utilisés et à la valeur
souhaitée le ou les autres).
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.
Aurelien Regat-Barrel wrote on 11/04/2006 10:48:
bool SetFilePointerEx( LONGLONG DistanceToMove )
{
LARGE_INTEGER tmp;
tmp.QuadPart = DistanceToMove;
return ::SetFilePointerEx( tmp ) == TRUE;
}
pour info j'ai retenu la 2° écriture, mais je me demandais si la
première était valable.
je préfère également cette seconde (car reinterpret_cast ne
sert à rien), voire:
bool setFilePointer(__int64 offset)
{
LARGE_INTEGER li;
li.QuadPart = offset;
return ::SetFilePointerEx(hFile, li, null, FILE_BEGIN) == TRUE);
}
__int64 n'est pas supporté par gcc (tjrs pas?)
mais c'est tjrs plus propre qu'un typedef M$ de plus; par
ailleurs c'est bien ici le but que de spécifier des offsets >
4 Go, un int64 en param. me parait + lisible (faute de "long
long").
Dernière question : peut-on initialiser un seul champ d'une
union lors de sa déclaration ?
c'est même ce qu'il faut faire - et non pas initialiser tous
les champs avec des valeurs non consistantes (eg initialiser à
0 les champs non (effectivement) utilisés et à la valeur
souhaitée le ou les autres).
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.
Aurelien Regat-Barrel wrote on 11/04/2006 10:48:bool SetFilePointerEx( LONGLONG DistanceToMove )
{
LARGE_INTEGER tmp;
tmp.QuadPart = DistanceToMove;
return ::SetFilePointerEx( tmp ) == TRUE;
}
pour info j'ai retenu la 2° écriture, mais je me demandais si la
première était valable.
je préfère également cette seconde (car reinterpret_cast ne
sert à rien), voire:
bool setFilePointer(__int64 offset)
{
LARGE_INTEGER li;
li.QuadPart = offset;
return ::SetFilePointerEx(hFile, li, null, FILE_BEGIN) == TRUE);
}
__int64 n'est pas supporté par gcc (tjrs pas?)
mais c'est tjrs plus propre qu'un typedef M$ de plus; par
ailleurs c'est bien ici le but que de spécifier des offsets >
4 Go, un int64 en param. me parait + lisible (faute de "long
long").
Dernière question : peut-on initialiser un seul champ d'une
union lors de sa déclaration ?
c'est même ce qu'il faut faire - et non pas initialiser tous
les champs avec des valeurs non consistantes (eg initialiser à
0 les champs non (effectivement) utilisés et à la valeur
souhaitée le ou les autres).
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.
James Kanze wrote on 09/04/2006 20:21: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.)
une saloperie qui permets des déplacements dans un fichier
proche du To avec un compilo ne gérant que des longs 32 bits
est imho une bonne saloperie.
James Kanze wrote on 09/04/2006 20:21:
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.)
une saloperie qui permets des déplacements dans un fichier
proche du To avec un compilo ne gérant que des longs 32 bits
est imho une bonne saloperie.
James Kanze wrote on 09/04/2006 20:21: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.)
une saloperie qui permets des déplacements dans un fichier
proche du To avec un compilo ne gérant que des longs 32 bits
est imho une bonne saloperie.
je préfère également cette seconde (car reinterpret_cast ne sert à
rien), voire:
bool setFilePointer(__int64 offset)
{
LARGE_INTEGER li;
li.QuadPart = offset;
return ::SetFilePointerEx(hFile, li, null, FILE_BEGIN) == TRUE);
}
__int64 n'est pas supporté par gcc (tjrs pas?) mais c'est tjrs plus
propre qu'un typedef M$ de plus; par ailleurs c'est bien ici le but que
de spécifier des offsets > 4 Go, un int64 en param. me parait + lisible
(faute de "long long").
Dernière question : peut-on initialiser un seul champ d'une union lors
de sa déclaration ?
c'est même ce qu'il faut faire - et non pas initialiser tous les champs
avec des valeurs non consistantes (eg initialiser à 0 les champs non
(effectivement) utilisés et à la valeur souhaitée le ou les autres).
je préfère également cette seconde (car reinterpret_cast ne sert à
rien), voire:
bool setFilePointer(__int64 offset)
{
LARGE_INTEGER li;
li.QuadPart = offset;
return ::SetFilePointerEx(hFile, li, null, FILE_BEGIN) == TRUE);
}
__int64 n'est pas supporté par gcc (tjrs pas?) mais c'est tjrs plus
propre qu'un typedef M$ de plus; par ailleurs c'est bien ici le but que
de spécifier des offsets > 4 Go, un int64 en param. me parait + lisible
(faute de "long long").
Dernière question : peut-on initialiser un seul champ d'une union lors
de sa déclaration ?
c'est même ce qu'il faut faire - et non pas initialiser tous les champs
avec des valeurs non consistantes (eg initialiser à 0 les champs non
(effectivement) utilisés et à la valeur souhaitée le ou les autres).
je préfère également cette seconde (car reinterpret_cast ne sert à
rien), voire:
bool setFilePointer(__int64 offset)
{
LARGE_INTEGER li;
li.QuadPart = offset;
return ::SetFilePointerEx(hFile, li, null, FILE_BEGIN) == TRUE);
}
__int64 n'est pas supporté par gcc (tjrs pas?) mais c'est tjrs plus
propre qu'un typedef M$ de plus; par ailleurs c'est bien ici le but que
de spécifier des offsets > 4 Go, un int64 en param. me parait + lisible
(faute de "long long").
Dernière question : peut-on initialiser un seul champ d'une union lors
de sa déclaration ?
c'est même ce qu'il faut faire - et non pas initialiser tous les champs
avec des valeurs non consistantes (eg initialiser à 0 les champs non
(effectivement) utilisés et à la valeur souhaitée le ou les autres).
