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
Suite à une extension logiciel, j'ai du passé en modèle mémoire HUGE, parceque une variable dépassée 64 K
[...]
compilateur utilisé: Visual C++ 1.5
Je vous parle d'un temps que les moins de 20 ans ne peuvent pas connaître... ;)
A part ça, je ne peux pas trop t'aider, sauf à te conseiller de changer de compilateur. :(
-- Loïc
heinquoi
"JM_Free" a écrit dans le message de news:cdlabi$l26$
Bonjour,
Suite à une extension logiciel, j'ai du passé en modèle mémoire HUGE, parceque une variable dépassée 64 K TINY = code+données <64Ko
SMALL = 64Ko de code + 64 ko de données Medium = 1mo de code + 64 ko de données Compact = 64 ko de code + 1 Mo de données Large = 1Mo de code + 1 Mo de données Huge = permet des données sttique sup a 64ko + sup a 1 Mo de données + sup à 1Mo de code
pourquoi ne pas utiliser les donnees dynamiques ( new ou malloc suivant ce qu'accept VC1.5 ), tu pourait continuer à utiliser les modèles Compact et plus
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
le principe de l'union, c'est , si je me souvient bien un objet de lz tzille de l'objet max contenu par l'union et le programmeur à la possibilité de choisir une donnée parmis les types declaré dans dans l'union.
exemple : char a[10000]; // OK
size_of (char) *10000000 bytes et donc < 64ko
- une variable > à 64 K dans une union => COMPILATION
ERREUR !
exemple : union Type1 { char a[10000]; int b[10000]; }; taille max est int donc
size_of (int)*10000=(2ou 4 suivant ton compilo)*10000 000 ou 40000 bytes, deja bcp plus.mais tjrs < 64ko et ceux pour chaque objet Type1 créé.
union Type1 Test1; ici j'ecrirais plus simplement
Type1 Test1 mais c'est peut etre pas pareil sur ton 'antiquité'
Si quelqu'un pouvait m'éclairer sur ce problème (option de compilation, pragma, ...) compilateur utilisé: Visual C++ 1.5
sur le compilateur borland tu dois en plus du choix de memoire rajouter une option pour que les données sup à 64 ko soit automatiquement gere avec des adresses far.
Merci d'avance peu pas t'aider...désolé
-- Cordialement, Heinquoi
"JM_Free" <jmdfree@free.fr> a écrit dans le message de
news:cdlabi$l26$1@news.mch.sbs.de...
Bonjour,
Suite à une extension logiciel, j'ai du passé en modèle mémoire HUGE,
parceque une variable dépassée 64 K
TINY = code+données <64Ko
SMALL = 64Ko de code + 64 ko de données
Medium = 1mo de code + 64 ko de données
Compact = 64 ko de code + 1 Mo de données
Large = 1Mo de code + 1 Mo de données
Huge = permet des données sttique sup a 64ko + sup a 1 Mo de données + sup à
1Mo de code
pourquoi ne pas utiliser les donnees dynamiques ( new ou malloc suivant ce
qu'accept VC1.5 ), tu pourait continuer à utiliser les modèles Compact et
plus
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
le principe de l'union, c'est , si je me souvient bien un objet de lz tzille
de l'objet max contenu par l'union et le programmeur à la possibilité de
choisir une donnée parmis les types declaré dans dans l'union.
exemple :
char a[10000]; // OK
size_of (char) *10000000 bytes et donc < 64ko
- une variable > à 64 K dans une union =>
COMPILATION
ERREUR !
exemple :
union Type1
{
char a[10000];
int b[10000];
};
taille max est int donc
size_of (int)*10000=(2ou 4 suivant ton compilo)*10000 000 ou 40000 bytes,
deja bcp plus.mais tjrs < 64ko
et ceux pour chaque objet Type1 créé.
union Type1 Test1;
ici j'ecrirais plus simplement
Type1 Test1
mais c'est peut etre pas pareil sur ton 'antiquité'
Si quelqu'un pouvait m'éclairer sur ce problème (option de compilation,
pragma, ...)
compilateur utilisé: Visual C++ 1.5
sur le compilateur borland tu dois en plus du choix de memoire rajouter une
option pour que les données sup à 64 ko soit automatiquement gere avec des
adresses far.
"JM_Free" a écrit dans le message de news:cdlabi$l26$
Bonjour,
Suite à une extension logiciel, j'ai du passé en modèle mémoire HUGE, parceque une variable dépassée 64 K TINY = code+données <64Ko
SMALL = 64Ko de code + 64 ko de données Medium = 1mo de code + 64 ko de données Compact = 64 ko de code + 1 Mo de données Large = 1Mo de code + 1 Mo de données Huge = permet des données sttique sup a 64ko + sup a 1 Mo de données + sup à 1Mo de code
pourquoi ne pas utiliser les donnees dynamiques ( new ou malloc suivant ce qu'accept VC1.5 ), tu pourait continuer à utiliser les modèles Compact et plus
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
le principe de l'union, c'est , si je me souvient bien un objet de lz tzille de l'objet max contenu par l'union et le programmeur à la possibilité de choisir une donnée parmis les types declaré dans dans l'union.
exemple : char a[10000]; // OK
size_of (char) *10000000 bytes et donc < 64ko
- une variable > à 64 K dans une union => COMPILATION
ERREUR !
exemple : union Type1 { char a[10000]; int b[10000]; }; taille max est int donc
size_of (int)*10000=(2ou 4 suivant ton compilo)*10000 000 ou 40000 bytes, deja bcp plus.mais tjrs < 64ko et ceux pour chaque objet Type1 créé.
union Type1 Test1; ici j'ecrirais plus simplement
Type1 Test1 mais c'est peut etre pas pareil sur ton 'antiquité'
Si quelqu'un pouvait m'éclairer sur ce problème (option de compilation, pragma, ...) compilateur utilisé: Visual C++ 1.5
sur le compilateur borland tu dois en plus du choix de memoire rajouter une option pour que les données sup à 64 ko soit automatiquement gere avec des adresses far.
Merci d'avance peu pas t'aider...désolé
-- Cordialement, Heinquoi
heinquoi
si tu nous met l'erreur renvoyé , ce serais plus facile pour t'aider.
-- Cordialement, Heinquoi
si tu nous met l'erreur renvoyé , ce serais plus facile pour t'aider.
"heinquoi" <nospam* a écrit dans le message news: 41004e5f$0$10468$
"JM_Free" a écrit dans le message de news:cdlabi$l26$
compilateur utilisé: Visual C++ 1.5
sur le compilateur borland tu dois [...]
Euh, le niveau baisse, on dirait :-)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
heinquoi
"Alain Naigeon" a écrit dans le message de news:4100645e$0$15275$
"heinquoi" <nospam* a écrit dans le message news: 41004e5f$0$10468$
"JM_Free" a écrit dans le message de news:cdlabi$l26$
compilateur utilisé: Visual C++ 1.5
sur le compilateur borland tu dois [...]
Euh, le niveau baisse, on dirait :-)
et oui ! c'est d'autand plus inquietant que le mien n'a jamais ete haut.Cela dit c'etait pas la pire des remarques, dire que sur un compilo concurent il faut mettre une option voulais suggerer que peut etre sur le compilo VC 1.5, il y en avait besoins aussi. Je travail avec le compilo de VC++6 SP6, et je le trouve veillo ( pb avec template + multiple bug) , ce qui fait que j'imagine mal quelqu'un travaillé sur VC++1.5, et je n'en voit pas l'interet notament avec DevC++ ou mingw developper studio qui utilise mingw, l'un des meilleurs compilo. A moins qu'il souhaite faire du 16 bits, mais la encore il y pas mal de compilo libre ou gratuit. cela dit c'est pas interdit d'etre maso et nostalgique. -- Cordialement, Heinquoi
"Alain Naigeon" <anaigeon@free.fr> a écrit dans le message de
news:4100645e$0$15275$636a15ce@news.free.fr...
"heinquoi" <nospam*heinquoi1@libertysurf.fr> a écrit dans le message news:
41004e5f$0$10468$626a14ce@news.free.fr...
"JM_Free" <jmdfree@free.fr> a écrit dans le message de
news:cdlabi$l26$1@news.mch.sbs.de...
compilateur utilisé: Visual C++ 1.5
sur le compilateur borland tu dois [...]
Euh, le niveau baisse, on dirait :-)
et oui ! c'est d'autand plus inquietant que le mien n'a jamais ete haut.Cela
dit c'etait pas la pire des remarques, dire que sur un compilo concurent il
faut mettre une option voulais suggerer que peut etre sur le compilo VC 1.5,
il y en avait besoins aussi.
Je travail avec le compilo de VC++6 SP6, et je le trouve veillo ( pb avec
template + multiple bug) , ce qui fait que j'imagine mal quelqu'un travaillé
sur VC++1.5, et je n'en voit pas l'interet notament avec DevC++ ou mingw
developper studio qui utilise mingw, l'un des meilleurs compilo. A moins
qu'il souhaite faire du 16 bits, mais la encore il y pas mal de compilo
libre ou gratuit.
cela dit c'est pas interdit d'etre maso et nostalgique.
--
Cordialement,
Heinquoi
"Alain Naigeon" a écrit dans le message de news:4100645e$0$15275$
"heinquoi" <nospam* a écrit dans le message news: 41004e5f$0$10468$
"JM_Free" a écrit dans le message de news:cdlabi$l26$
compilateur utilisé: Visual C++ 1.5
sur le compilateur borland tu dois [...]
Euh, le niveau baisse, on dirait :-)
et oui ! c'est d'autand plus inquietant que le mien n'a jamais ete haut.Cela dit c'etait pas la pire des remarques, dire que sur un compilo concurent il faut mettre une option voulais suggerer que peut etre sur le compilo VC 1.5, il y en avait besoins aussi. Je travail avec le compilo de VC++6 SP6, et je le trouve veillo ( pb avec template + multiple bug) , ce qui fait que j'imagine mal quelqu'un travaillé sur VC++1.5, et je n'en voit pas l'interet notament avec DevC++ ou mingw developper studio qui utilise mingw, l'un des meilleurs compilo. A moins qu'il souhaite faire du 16 bits, mais la encore il y pas mal de compilo libre ou gratuit. cela dit c'est pas interdit d'etre maso et nostalgique. -- Cordialement, Heinquoi
heinquoi
dommage, il ne repond pas Mr JM_Free. J'avais bien envie de revoir du 16 bits et sa gestion 'complexe' de memoire.
-- Cordialement, Heinquoi
dommage, il ne repond pas Mr JM_Free.
J'avais bien envie de revoir du 16 bits et sa gestion 'complexe' de memoire.
dommage, il ne repond pas Mr JM_Free. J'avais bien envie de revoir du 16 bits et sa gestion 'complexe' de memoire.
-- Cordialement, Heinquoi
JM_Free
Désolé, mais je me suis pas connecté depuis.
En résumé avec certains compilateur 16 bits (dos et window) , on peut rencontrer des problèmes dans certains cas dés lors que l'on adresse des blocs de mémoire > à 64 K (tableau , pointeur, ...)
Solution :migrer soit vers un nouveau compilateur, soit organiser sa mémoire de telle manière < à 64K.
Merci de vos infos. Cordialement
Désolé, mais je me suis pas connecté depuis.
En résumé avec certains compilateur 16 bits (dos et window) , on peut
rencontrer des problèmes dans certains cas dés lors que l'on adresse
des blocs de mémoire > à 64 K (tableau , pointeur, ...)
Solution :migrer soit vers un nouveau compilateur, soit organiser sa mémoire
de telle manière < à 64K.
En résumé avec certains compilateur 16 bits (dos et window) , on peut rencontrer des problèmes dans certains cas dés lors que l'on adresse des blocs de mémoire > à 64 K (tableau , pointeur, ...)
Solution :migrer soit vers un nouveau compilateur, soit organiser sa mémoire de telle manière < à 64K.
Merci de vos infos. Cordialement
spam
"JM_Free" wrote in message news:<cdlabi$l26$...
Suite à une extension logiciel, j'ai du passé en modèle mémoire HUGE, parceque une variable dépassée 64 K
Hu hu hu, ça me rappelle Turbo Pascal 7 (sorti en 1990 je crois) sous MSDOS ça :-)
Connais-tu GCC ? Un des meilleurs compilateurs actuel, http://gcc.gnu.org/
exemple : union Type1 { char a[10000]; int b[10000]; }; union Type1 Test1;
Je te conseille d'allouer dynamiquement la mémoire, puis de jouer avec les pointeur pour accéder à tes données dans différents formats :
#include <cstdlib> // pour avoir size_t, je sais pas où il est précisément typedef unsigned char uchar; 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)); int *int_ptr = static_cast<int *> (m_ptr); return int_ptr[pos]; } ... };
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 !
@+ Haypo
"JM_Free" <jmdfree@free.fr> wrote in message news:<cdlabi$l26$1@news.mch.sbs.de>...
Suite à une extension logiciel, j'ai du passé en modèle mémoire HUGE,
parceque une variable dépassée 64 K
Hu hu hu, ça me rappelle Turbo Pascal 7 (sorti en 1990 je crois) sous
MSDOS ça :-)
Connais-tu GCC ? Un des meilleurs compilateurs actuel,
http://gcc.gnu.org/
exemple :
union Type1
{
char a[10000];
int b[10000];
};
union Type1 Test1;
Je te conseille d'allouer dynamiquement la mémoire, puis de jouer avec
les pointeur pour accéder à tes données dans différents formats :
#include <cstdlib> // pour avoir size_t, je sais pas où il est
précisément
typedef unsigned char uchar;
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));
int *int_ptr = static_cast<int *> (m_ptr);
return int_ptr[pos];
}
...
};
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 !
Suite à une extension logiciel, j'ai du passé en modèle mémoire HUGE, parceque une variable dépassée 64 K
Hu hu hu, ça me rappelle Turbo Pascal 7 (sorti en 1990 je crois) sous MSDOS ça :-)
Connais-tu GCC ? Un des meilleurs compilateurs actuel, http://gcc.gnu.org/
exemple : union Type1 { char a[10000]; int b[10000]; }; union Type1 Test1;
Je te conseille d'allouer dynamiquement la mémoire, puis de jouer avec les pointeur pour accéder à tes données dans différents formats :
#include <cstdlib> // pour avoir size_t, je sais pas où il est précisément typedef unsigned char uchar; 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)); int *int_ptr = static_cast<int *> (m_ptr); return int_ptr[pos]; } ... };
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 !
