Suite à une extension logiciel, j'ai du passé en modèle mémoire HUGE,
parceque une variable dépassée 64 K
j'ai maintenant un problème de compilation que j'arrive pas à résoudre
- une variable > à 64 K déclaré en dehors de l'union: => COMPILATION OK
exemple :
char a[10000]; // OK
- une variable > à 64 K dans une union => COMPILATION
ERREUR !
exemple :
union Type1
{
char a[10000];
int b[10000];
};
union Type1 Test1;
Si quelqu'un pouvait m'éclairer sur ce problème (option de compilation,
pragma, ...)
compilateur utilisé: Visual C++ 1.5
class hack // on est sur fr.comp.lang.c++ nan ? { private: uchar * m_ptr; size_t m_taille; public: hack (size_t taille_octet) { // vérifie que ce ne soit pas une allocation idiote assert (0 < taille_octet);
// vérifie qu'on prend une taille divisible par la taille d'un int // pour pouvoir accéder à la classe en char ou int assert ((taille_octet % sizeof(int)) == 0); m_taille = taille_octet; m_ptr = new char[taille_octet]; } ~hack() { delete m_ptr; } uchar& operator[] (size_t pos) { assert (pos < m_taille); return m_ptr[pos]; } int& acces_int (size_t pos) { assert (pos < (m_taille/4)); ^^^
En résumé : - Allocation de mémoire avec new - Libération de mémoire avec delete - Changement de type avec static_cast<type> (valeur)
Fait bien attention à la taille des données : si tu alloues juste 1 octet, et que tu tentes d'y accéder en int* alors que tu bosses en 16 bits (2 octets par int), tu risques d'avoir des surprises !
Ce à quoi sert le « assert( 0 == taille % sizeof( int ) ) ».
Pour le reste, je n'ai pas vraiment suivit la discussion. Mais AMHA, s'il peut se passer d'allocation dynamique, il n'y a pas de raison de l'utiliser. Cela a tout l'air d'un bug de son compilo. Je suis pas expert en VC++, mais VC++ 1.5, ça me semble antédiluven, non ?
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
spam@haypocalc.com (Victor STINNER) writes:
class hack // on est sur fr.comp.lang.c++ nan ?
{
private:
uchar * m_ptr;
size_t m_taille;
public:
hack (size_t taille_octet) {
// vérifie que ce ne soit pas une allocation idiote
assert (0 < taille_octet);
// vérifie qu'on prend une taille divisible par la taille d'un int
// pour pouvoir accéder à la classe en char ou int
assert ((taille_octet % sizeof(int)) == 0);
m_taille = taille_octet;
m_ptr = new char[taille_octet];
}
~hack() { delete m_ptr; }
uchar& operator[] (size_t pos) { assert (pos < m_taille); return
m_ptr[pos]; }
int& acces_int (size_t pos) {
assert (pos < (m_taille/4));
^^^
En résumé :
- Allocation de mémoire avec new
- Libération de mémoire avec delete
- Changement de type avec static_cast<type> (valeur)
Fait bien attention à la taille des données : si tu alloues juste 1
octet, et que tu tentes d'y accéder en int* alors que tu bosses en 16
bits (2 octets par int), tu risques d'avoir des surprises !
Ce à quoi sert le « assert( 0 == taille % sizeof( int ) ) ».
Pour le reste, je n'ai pas vraiment suivit la discussion. Mais
AMHA, s'il peut se passer d'allocation dynamique, il n'y a pas de
raison de l'utiliser. Cela a tout l'air d'un bug de son compilo. Je
suis pas expert en VC++, mais VC++ 1.5, ça me semble antédiluven,
non ?
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
class hack // on est sur fr.comp.lang.c++ nan ? { private: uchar * m_ptr; size_t m_taille; public: hack (size_t taille_octet) { // vérifie que ce ne soit pas une allocation idiote assert (0 < taille_octet);
// vérifie qu'on prend une taille divisible par la taille d'un int // pour pouvoir accéder à la classe en char ou int assert ((taille_octet % sizeof(int)) == 0); m_taille = taille_octet; m_ptr = new char[taille_octet]; } ~hack() { delete m_ptr; } uchar& operator[] (size_t pos) { assert (pos < m_taille); return m_ptr[pos]; } int& acces_int (size_t pos) { assert (pos < (m_taille/4)); ^^^
En résumé : - Allocation de mémoire avec new - Libération de mémoire avec delete - Changement de type avec static_cast<type> (valeur)
Fait bien attention à la taille des données : si tu alloues juste 1 octet, et que tu tentes d'y accéder en int* alors que tu bosses en 16 bits (2 octets par int), tu risques d'avoir des surprises !
Ce à quoi sert le « assert( 0 == taille % sizeof( int ) ) ».
Pour le reste, je n'ai pas vraiment suivit la discussion. Mais AMHA, s'il peut se passer d'allocation dynamique, il n'y a pas de raison de l'utiliser. Cela a tout l'air d'un bug de son compilo. Je suis pas expert en VC++, mais VC++ 1.5, ça me semble antédiluven, non ?
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Oups, il fallait lire "sizeof(int)" bien sûr :-) Je suis trop habitué à travailler sur des compilos 32 bits ...
Fait bien attention à la taille des données : si tu alloues juste 1 octet, et que tu tentes d'y accéder en int* alors que tu bosses en 16 bits (2 octets par int), tu risques d'avoir des surprises !
Ce à quoi sert le « assert( 0 == taille % sizeof( int ) ) ».
Et bien à être sur que la taille du tampon est un multiple de la taille d'un int. Exemple : on alloue 3 octets sans faire de test. Si tu accèdes au 2e int, on va lire 1 octet en dehors de la mémorie allouée ... Bon ok, l'autre assertion va rejetter l'accès, mais autant faire les choses proprement dès le début.
@+ Haypo
drkm <usenet.fclcxx@fgeorges.org> wrote in message news:<wksmb56owk.fsf@fgeorges.org>...
Oups, il fallait lire "sizeof(int)" bien sûr :-) Je suis trop habitué
à travailler sur des compilos 32 bits ...
Fait bien attention à la taille des données : si tu alloues juste 1
octet, et que tu tentes d'y accéder en int* alors que tu bosses en 16
bits (2 octets par int), tu risques d'avoir des surprises !
Ce à quoi sert le « assert( 0 == taille % sizeof( int ) ) ».
Et bien à être sur que la taille du tampon est un multiple de la
taille d'un int. Exemple : on alloue 3 octets sans faire de test. Si
tu accèdes au 2e int, on va lire 1 octet en dehors de la mémorie
allouée ... Bon ok, l'autre assertion va rejetter l'accès, mais autant
faire les choses proprement dès le début.
Oups, il fallait lire "sizeof(int)" bien sûr :-) Je suis trop habitué à travailler sur des compilos 32 bits ...
Fait bien attention à la taille des données : si tu alloues juste 1 octet, et que tu tentes d'y accéder en int* alors que tu bosses en 16 bits (2 octets par int), tu risques d'avoir des surprises !
Ce à quoi sert le « assert( 0 == taille % sizeof( int ) ) ».
Et bien à être sur que la taille du tampon est un multiple de la taille d'un int. Exemple : on alloue 3 octets sans faire de test. Si tu accèdes au 2e int, on va lire 1 octet en dehors de la mémorie allouée ... Bon ok, l'autre assertion va rejetter l'accès, mais autant faire les choses proprement dès le début.
@+ Haypo
drkm
(Victor STINNER) writes:
drkm wrote in message news:...
Fait bien attention à la taille des données : si tu alloues juste 1 octet, et que tu tentes d'y accéder en int* alors que tu bosses en 16 bits (2 octets par int), tu risques d'avoir des surprises !
Ce à quoi sert le « assert( 0 == taille % sizeof( int ) ) ».
Et bien à être sur que la taille du tampon est un multiple de la taille d'un int.
C'est exactement ce que j'ai dit.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
spam@haypocalc.com (Victor STINNER) writes:
drkm <usenet.fclcxx@fgeorges.org> wrote in message
news:<wksmb56owk.fsf@fgeorges.org>...
Fait bien attention à la taille des données : si tu alloues juste 1
octet, et que tu tentes d'y accéder en int* alors que tu bosses en 16
bits (2 octets par int), tu risques d'avoir des surprises !
Ce à quoi sert le « assert( 0 == taille % sizeof( int ) ) ».
Et bien à être sur que la taille du tampon est un multiple de la
taille d'un int.
C'est exactement ce que j'ai dit.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Fait bien attention à la taille des données : si tu alloues juste 1 octet, et que tu tentes d'y accéder en int* alors que tu bosses en 16 bits (2 octets par int), tu risques d'avoir des surprises !
Ce à quoi sert le « assert( 0 == taille % sizeof( int ) ) ».
Et bien à être sur que la taille du tampon est un multiple de la taille d'un int.
C'est exactement ce que j'ai dit.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
