Discussion :

[irnbru]

Bonjour j'ai une fonction avec la signature suivante :

ExpandCommand(char * szCmd)

au moment de l'appel je fait passer la commande

char szPreCmd[MAX_STRING_SIZE] ;

ExpandCommand(szPreCmd)

avant l'appel szPreCmd comme par

"IGenIti ......"

mais dans l'execution de la fonction ExpandCommand szPreCmd prends la valeur suivant!

"GenIti....." Le I a été omis ! il ne se passe rien, juste une transmission : je ne sais pas comment il fait ca!

j'ai bien vérifier pas à pas, des suggestions?

merci

IRNBRU

[Merci d'éviter les titres "A l'aide", "au secours", et de privilégier une description claire]

[nico-pyright(c)]

le pointeur de chaine n'est pas modifié ?
genre un szPreCmd++ caché

et sinon, on peut peut-etre voir la convention d'appel ? le prototype, l'appel, etc ...

[farscape]

salut
ce n'est pas possible.
verifies que les adresses sont identiques( a mon avis non) avant l'appel et dans l'appel.
sinon post un peu de code un peu plus explicite .

[irnbru]

Comment verifier les adresses avant l'appel de la fonction et dans l'appel?

Dans le fichier .h j'ai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class Nico
{
 
.....
 
protected :
 
// Expand the command with the var
char * ExpandCommand(char * szCmd) ;
 
..
};

dans le fichier cpp j'ai

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
char * Nico::ExpandCommand(char * szCmd)
{
 
....
 
}

rien de particulier, je me demande si le fichier que je fais appel correspond bien à celui de mon code ??

merci

IRNBRU

[nico-pyright(c)]

avec ton debbuggeur, tu mets un point d'arret avant l'appel et dans l'appel et tu regardes dans les variables si l'adresse de la chaine est la meme

par contre, tu es sur de ne pas faire de confusion entre le paramètre et le retour de la fonction ?

[irnbru]

naaan c'est un paramètre d'entrée, l'adresse d'ailleur n'est pas la même, j'ai 0x150c78f4 avant l'appel et dans l'appel j'ai 0x150c78f5 ! quelle serait le problème??

Merci encore pour votre gentillesse

IRNBRU

[nico-pyright(c)]

je ne vois pas comment c'est possible,

l'adresse doit etre la meme dans la mesure où c'est un passage de pointeur !


l'appel est-il vraiment comme tu le décris ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
char szPreCmd[MAX_STRING_SIZE] ;
 
ExpandCommand(szPreCmd)

n'y a-t-il pas une modification de szPreCmd avant l'appel ?

[irnbru]

pas réellement, c'est

RunCommand(ExpandCommand(szPreCmd), FALSE)

mais expandcommand serait appelé d'abord n'est ce pas?

IRNBRU

[nico-pyright(c)]

expandCommand est appelé d'abord, effectivement, mais je ré-itère, ce n'est pas possible.

Trace la chaine juste avant l'appel de la fonction, et au debut de l'appel de la fonction, pour voir à quel endroit elle ne correspond pas à tes attentes, mais ce qui est certain, c'est qu'au moment de l'appel et au tout début de la fonction, elles ont la meme valeur

[irnbru]

Comment peut on expliquer le changement d'adresse de la variable que j'ai mentionné auparavant? C'est fou! j'ai envie d'exploser

merci pour votre patience
IRNBRU

[nico-pyright(c)]

Je ne l'explique pas

Peux-tu fournir un code minimaliste qui permet de reproduire l'erreur ?

[irnbru]

Bizzare, j'essaie la fonction OutputDebug et le logiciel DebugView, il ne se fait rien! j'ai de plus en plus de doutes sur le fichier appelé, je modifie du code et le code qui est exécuté pas à pas ne fait rien! faut bien que je regarde quel fichier dll est appelé, je suis perdu...

IRNBRU

[irnbru]

Comment savoir quelle dll est chargée et lancée, ou faut il regarder dans les propriétés du projet?? je suis plus que sur maintenant que le code et le code exécuté ne correspondent pas,

a l'aide please

thanks

IRNBRU

[nico-pyright(c)]

et puis, vérifie aussi que c'est la bonne classe qui est appelée, à partir du bon objet (en l'occurence l'objet "nico" ici)

[irnbru]

je pense avoir résolu mon problème, VC++ ne chargeait pas le bon fichier dll du coup toutes les instructions décalées ne collaient plus comme il chargeait une dll plus ancienne que celle du code! D'où le décalage, c'est extrement dangereux VC++ lol

Je vérifie encore avant de considérer résolu

merci
IRNBRU

[Neo41]

c'est extrement dangereux VC++ lol

ça dépend entre les mains de qui

[farscape]

je profite de ce post pour dire que (c'est général et je ne vise personne):
La bonne réaction dans ce genre de réaction c'est :
Ce qui arrive est impossible, donc comme dirait Mulder la vérité est ailleurs.

Alors on utilise le merveilleux debbuger de VC on met des points d'arrets,trace etc ..
Et surtout problème fréquent on s’assure que les sources/modules en questions sont bien a jour .
Des fois un simple clean + rebuild ALL permet de résoudre l’impossible.

donc toujours se remettre en cause avant de dire c'est le compilo ,c'est les MFC etc..

[irnbru]

j'ai un warning du genre :

c:\travail\dev\aaseq\aaseqdll\debug\msado15.tlh(409) : warning C4146: unary minus operator applied to unsigned type, result still unsigned

c'est quoi ce délire? lol

est ce important?

IRNBRU

[nico-pyright(c)]

ca doit etre un problème de signed/unsigned
quel est le code de la ligne qui fait un warning ?

[irnbru]

incroyable quand même microsoft!

regardez vous même; il faut désactiver cet avertissement car ils sont trop fénéasse de réparer de bug lol

http://support.microsoft.com/default...;EN-US;q253317

IRNBRU