CString en C++ - Programmation
Marsh Posté le 09-05-2001 à 11:49:41
Verifie que les chaines se terminent par un '\0', c'est sans doute ça.
Marsh Posté le 09-05-2001 à 11:53:44
Hé non, parce que j'utilise des fonctions de CString qui fonctionnent très bien, comme CString::Left, qui est censée me rendre une CString correctement terminée qd même j'imagine !
et c'est en attribuant la valeur rendue par cette fonction à une autre CString que ça foire !
Marsh Posté le 09-05-2001 à 11:55:11
fait un tour sur la classe CStringArray .. tres pratique pour tout ce qui conserne les tableaux de CString
@+ et bonne chance
Marsh Posté le 09-05-2001 à 12:02:37
...merci, mais c pas un tableau de CString ce que je veux utiliser, c des CString tout court !
Marsh Posté le 09-05-2001 à 12:33:13
En fait, à force de réflexion, j'en sais un peu plus...
Alors, l'erreur vient de la variable qui reçoit la CString.
Elle appartient à une structure dont voici la définition:
typedef struct _TACHE_ENV
{
CString num
eTYPE_ENV type;
CString arg1;
CString arg2;
CString libelle;
} TACHE_ENV;
voilà, et j'ai un tableau d'éléments de cette structure:
m_TabTachesEnv;
et si je demande: m_TabTachesEnv[1].arg1 = UneCString;
ça fait un débordement mémoire !?
Pourquoi ? qqn à une idée ?
Sachant que UneCString est correcte, et que la même attribution, avec un char arg1[255] dans la structure (et donc, bien sur un strcpy pr attribuer !) se passait très bien...
Help ! snif...
Marsh Posté le 09-05-2001 à 12:43:36
Apparement, dès que j'utilise
m_TabTachesEnv[1].arg1, même pour autr chose ( ex: .Empty())
ça fait une plantage violent à l'execution !
Marsh Posté le 09-05-2001 à 15:44:38
Pourquoi utiliser des CStrings ?
les MFC ne sont plus supportees par Microsoft, et une classe string de la STL devrait correspondre a tes besoins non ?
Marsh Posté le 09-05-2001 à 15:52:04
Verdoux a écrit a écrit : Comment construis tu ton tableau m_TabTachesEnv ? |
Tout bêtement comme ça :
TACHE_ENV m_TabTachesEnv[255];
ça pose un problème !?
Marsh Posté le 09-05-2001 à 15:53:42
BENB a écrit a écrit : Pourquoi utiliser des CStrings ? les MFC ne sont plus supportees par Microsoft, et une classe string de la STL devrait correspondre a tes besoins non ? |
Comment ça !? bien sur que si, elle sont supportées pas Miscrosoft les MFC...
Marsh Posté le 09-05-2001 à 16:17:23
En fait ton erreur est d'avoir omis un point-virgule ->
typedef struct _TACHE_ENV
{
CString num; // point-virgule ici!!!
eTYPE_ENV type;
CString arg1;
CString arg2;
CString libelle;
} TACHE_ENV;
Ensuite tout marchera
C'est quand même bizarre que t'es pas eu un msg du type "missing ';' before identifier ..." !
El_gringo a écrit a écrit : Comment ça !? bien sur que si, elle sont supportées pas Miscrosoft les MFC... |
[edit]--Message édité par Amadeus--[/edit]
Marsh Posté le 09-05-2001 à 14:25:36
Merci, mais ça aurai été trop beau, moi aussi j'y ai cru un moment, mais non, je l'ai juste viré en le collant, mais dans mon prog il y est...re snif !
Marsh Posté le 09-05-2001 à 14:28:52
Tu peux nous montrer la partie de ton code où l'erreur apparaît ?
ça va être ainsi + facile de t'aider
El_gringo a écrit a écrit : Merci, mais ça aurai été trop beau, moi aussi j'y ai cru un moment, mais non, je l'ai juste viré en le collant, mais dans mon prog il y est...re snif ! |
Marsh Posté le 09-05-2001 à 14:36:32
bien sur, mais je te rappel que c une erreur d'execution, la seule façon de la localiser, c'est le debugger, sinon, tout ce qu'y me dis lui, c que mon application plante !
voila, ça c une partie, mais à chaque fois que je fais une opération sur un élément CString contenu dans ce tableau de structure, ça plante:
CString test = "zik"; // marche bien (test)
test = _Arg1; // marche bien (test)
m_tachesEnv[_index].arg1.Empty(); // plante
m_tachesEnv[_index].arg1 = _NoTache; // plante
Marsh Posté le 09-05-2001 à 14:38:31
tu n'avais qu'a bosser tes cours, voila maintenant t'es perdu!!!
Marsh Posté le 09-05-2001 à 14:41:58
fait pas chier grosmétos, y a des gens sérieux qui essayent de travailler, alors je sais que que toi tu t'emmerde, mais moi j'essaye de bosser...
Marsh Posté le 09-05-2001 à 15:05:50
Le pb, je pense, est du au fait que les CString sont des classes qui passe leur temps à allouer et désallouer la mémoire alors les mettre comme membre d'une structure j'ai jammais essayé pasqu'une structure par "tradition" contient des types simples ou des pointeurs.
Essayes de modifier ta structure comme ça :
typedef struct _TACHE_ENV
{
CString* num;
eTYPE_ENV type;
CString* arg1;
CString* arg2;
CString* libelle;
} TACHE_ENV;
TACHE_ENV m_TabTachesEnv[255];
for (int i=0; i<255; i++)
{
m_TabTachesEnv[i].num = new CString("init" );
// pareil pour les 3 autres CString
}
puis tu utilises tes ptr :
*m_TabTachesEnv[i].num = "hello";
...
m_TabTachesEnv[i].num->Empty();
...
à la fin t'oublies pas de libérer la mém :
for (int i=0; i<255; i++)
{
delete m_TabTachesEnv[i].num;
// pareil pour les 3 autres CString
}
C'est un peu plus (très peu) compliqué que ce que t'as fait mais ça marchera sans pb
El_gringo a écrit a écrit : bien sur, mais je te rappel que c une erreur d'execution, la seule façon de la localiser, c'est le debugger, sinon, tout ce qu'y me dis lui, c que mon application plante ! voila, ça c une partie, mais à chaque fois que je fais une opération sur un élément CString contenu dans ce tableau de structure, ça plante: CString test = "zik"; // marche bien (test) test = _Arg1; // marche bien (test) m_tachesEnv[_index].arg1.Empty(); // plante m_tachesEnv[_index].arg1 = _NoTache; // plante |
[edit]--Message édité par Amadeus--[/edit]
Marsh Posté le 09-05-2001 à 15:18:32
merci, en fait g trouvé mais vous pouviez pas trouver, j'avais pas pensé à mettre un truc...je faisait un memset sur tout le tableau a l'initialisation, et ça faisait des merdes
Merci tt le monde qd même (et ton truc ça aurai marché aussi je pense Amadeus, malgré mon memset !)
Marsh Posté le 09-05-2001 à 16:24:05
El_gringo a écrit a écrit : Comment ça !? bien sur que si, elle sont supportées pas Miscrosoft les MFC... |
Non le support des MFC s'arrete avec velui de Visual 6.0... apres plus de MFC...
Marsh Posté le 09-05-2001 à 16:34:14
bah, et si y a plus de MFC, y aura quoi !? plus que le SDK ?
Marsh Posté le 09-05-2001 à 16:51:06
Il y aura une nouvelle lib compatible C# (mais incompatible MFC)
Marsh Posté le 09-05-2001 à 17:03:36
'fait chier, je vient d'apprendre à me servir des MFC pour un stage que je fais...
Marsh Posté le 09-05-2001 à 17:03:44
El_gringo a écrit a écrit : merci, en fait g trouvé mais vous pouviez pas trouver, j'avais pas pensé à mettre un truc...je faisait un memset sur tout le tableau a l'initialisation, et ça faisait des merdes ![]() ![]() |
Oui en c++, il faut y réfléchir plusieurs fois quand on veut bidouiller soi-même la mémoire (avec memset, malloc et autres) car le langage, via les constructeurs, fait déjà pas mal de trucs et quand il y a interférence, ça plante.
Par exemple en c++:
TACHE_ENV m_TabTachesEnv[255];
Va créer le tableau puis appeler le constructeur pour chaque struct TACHE_ENV qui à son tour va appeler les constructeurs des membres et notamment CString()
C'est pas aussi simple qu'en C.
Marsh Posté le 09-05-2001 à 17:09:16
BENB a écrit a écrit : Il y aura une nouvelle lib compatible C# (mais incompatible MFC) |
On reconnaît bien là Microsoft
Marsh Posté le 09-05-2001 à 17:12:24
Bon, y en a marre. Y en a plein qui parlent de classes STL, ptain, elles ont l'air magiques et je sais pas ce que c'est ... J'en aurrais bien besoin, pour des arbres entre autre.
j'exige des explications
Marsh Posté le 09-05-2001 à 17:15:04
oliv5 a écrit a écrit : Bon, y en a marre. Y en a plein qui parlent de classes STL, ptain, elles ont l'air magiques et je sais pas ce que c'est ... J'en aurrais bien besoin, pour des arbres entre autre. j'exige des explications ![]() |
je ne connais pas d'arbre dans la STL, mais il y a des map et la plupart des implementation ont des HashTable...
Marsh Posté le 09-05-2001 à 17:17:28
bah, tant pis, mais explique toujours. Ou c'est qu'on peut trouver ces lib. (c'est ca surtout, apres je verrais ce que je peux faire avec.) Pour le moment, je fais tout ou presque à la main (listes chainees, chaines de caracteres etc...)
Marsh Posté le 09-05-2001 à 17:20:52
STL > Livre en standard avec la plupart des compilo recents...
sgi distribue une version free je crois, et, RogueWave une version payante...
[edit]--Message édité par BENB--[/edit]
Marsh Posté le 09-05-2001 à 17:30:09
Ok, je vois ce dont il s'agit. J'ai deja essayé de m'en servir et VC++6 ne veut pas compiler le truc. c'est quoi qu'il faut inclure ?
Marsh Posté le 09-05-2001 à 17:36:58
oliv5 a écrit a écrit : Ok, je vois ce dont il s'agit. J'ai deja essayé de m'en servir et VC++6 ne veut pas compiler le truc. c'est quoi qu'il faut inclure ? |
par exemple pour une string
- > #include <string>
- > using namespace std; //je crois dans mon implementation y en a pas besoin...
- > string toto;
etc...
Marsh Posté le 09-05-2001 à 18:04:28
http://www.microsoft.com/france/vs [...] intro.html
voila la lib qui remplace (remplacera) les MFC...
Marsh Posté le 09-05-2001 à 11:46:01
j'ai décidé de remplacer, dès que c'est possible, dans mon application, toutes les chaines de type char nomVar[unNombre], par des CString, qd même plus pratiques !
après avoir corrigé toutes les erreures de comilation, je lance mon prog...plantage violent, débordement mémoire je crois.
Avec le débugger, je vois que ce qui fait ce débordement, c'est les opération toute bêtes, du style:
m_tachesEnv[_index].arg1 = _Arg1;
ou les 2 sont de type CString.
passer une seule fois sur ces opérations suffit à ce putain de débordement mémoire (et désolé pour mes débordements de langage à moi !)
Je suis sur que qqn à déja connu ça et connai la solution toute simple (on peut rêver, non ?)
Si c la cas, merci d'avance...