Discussion :

[Cheb09]

Bonjour voici mon probleme.

J'utilise depuis mon appli DELPHI 7, les services d'une dll compilée en C++ Builder 5.0 (dont j'ai déclaré les prototypes via les mots clefs external, cdecl et Cie ...).



L'appel d'un de ces services me pose problème :

Prototype C :

int _MaFonction (const unsigned char*, const unsigned char *, const long, unsigned char*, long, int* );


La déclaration du prototype dans DELPHI :

Code :

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

1
2
3
4
5
6
function _Mafonction( const  RF_CodeCmde : pByte;
                              const  BufferIn : pByte;
                              const  RF_TailleBufferIn : LongInt;
                                RF_BufferOut : pByte;
                                RF_TailleBufferOut : LongInt;
                            var RF_Status:integer):integer; cdecl; external 'MaDll.dll';

Je peux bien appeler ce service mais le retour de la fontion est toujours négatif, comme s'il ne comprenait pas les valeurs passées. Voici un exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
var
  ret, status : integer;
  TailleQuestion, TailleReponse : LongInt;
 
  PReponse : ^Byte;
  pCodeService, pQuestion : ^Byte;
 
 
begin
    TailleReponse := 3;
    GetMem (PReponse, TailleReponse*SizeOf(Byte));
 
    GetMem (pCodeService, 1);
    pCodeService^ := $01;
 
    TailleQuestion := 1;
    GetMem (pQuestion, TailleQuestion);
    pQuestion^ := $81;
 
    ret := _PerformCommand(pCodeService, pQuestion, TailleQuestion, pByte(PReponse), TailleReponse, status);
    // Cet appel renvoie toujours un statut KO, ret <>1 et status <0 signifiant 'paramètres invalides'
 
end;

J'ai tout inspecté au debuggeur sans rien remarquer de suspect. Je me pose donc 2 question :

- Le choix d'un pByte pour décrire un unsigned char * est il judicieux ?
- Faut il oui ou non garder le const devant les paramètres ?

Merci de vos réponses ....


Sebastien

[ShaiLeTroll]

prototype en C contient const, cela doit être comme dans Delphi à ceci près que const c'est un passage par pointeur, tu risque d'avoir ajouté un niveau d'indirection ... enlève ton const pour RF_CodeCmde, BufferIn et RF_TailleBufferIn

en fait var et const c'est la même chose, c'est la même convention d'appel, c'est juste que dans l'IDE tu ne peux pas compiler une modification de la valeur (quoi qu'en ASM tu peux le faire paniquer à ce sujet)

par exemple,

Code :

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

var RF_Status: integer

ou

Code :

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

RF_Status: Pinteger

l'un et l'autre forme donnera en stdcall, la même chose ...

[Cheb09]

l'un et l'autre forme donnera en stdcall, la même chose ...

Je n'utilise pas stdcall mais cdecl.

A ce propos, quelqu'un peut il m'expliquer la différence entre stdcall et cdecl (mes recherches sur Internet donnent sur ce sujet des explications plutot pas claires)

[Dirk-Pitt]

Extrait de l'aide de Delphi

Code :

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

1
2
3
4
5
6
Directive|Parameter order|Clean-up|Passes parameters in registers?
register|Left-to-right|Routine|Yes
pascal|Left-to-right|Routine|No
cdecl|Right-to-left|Caller|No
stdcall|Right-to-left|Routine|No
safecall|Right-to-left|Routine|No

La différence se situe au niveau du dépilement des paramètres.

[Cheb09]

Oups j'avais oublié de faire F1

[ShaiLeTroll]

Je n'utilise pas stdcall mais cdecl.

Je sais mais ne connaissant pas cdecl, je ne me suis prononcé que sur ce que j'avais testé, d'ailleurs sans les const ... est-ce que cela donne un résultat, ou simplement laisser le const mais remplaer PByte par Byte ?

[CapJack]

en fait var et const c'est la même chose, c'est la même convention d'appel, ...

Je ne suis pas tout à fait d'accord avec toi.

Pour un passage de paramètres register (par défaut), la convention var renverra toujours un pointeur sur la variable, car la variable doit être modifiée, il faut donc toujours accéder à son emplacement.

Alors que si la directive const renvoie un pointeur sur la variable, c'est justement parce que la variable ne peut pas être modifiée, il n'y a donc pas besoin d'en faire une copie, on peut aller chercher les données là où elles sont.

Mais ce n'est absolument pas obligé ! Le compilateur ne transmettra la valeur via l'adresse de la variable que s'il y calcule un intérêt en termes de temps d'exécution, c'est-à-dire si la taille de la variable excède le contenu d'un registre 32 bits (types record par exemple). Dans le cas de valeurs scalaires occupant moins de 4 octets, ou de pointeurs, c'est la valeur qui est directement manipulée parce qu'elle génèrera un code plus compact et plus rapide.

Donc, ce n'est pas équivalent.

Maintenant, dans le cas qui nous intéresse, d'une part je ne sais pas si ce que je viens d'écrire s'applique à la convention cdecl, et en outre il s'agit de pointeurs, donc en convention pascal ça ne changerait rien.

Il faut essayer sans les directives const, et - sait-on jamais ? -, avec des directives var. Qui sait ? Si ça se trouve, BCB considère qu'un char* en const est un pointeur sur un pointeur... ?

Remplacer PByte par Byte me paraît inapproprié, par contre moi je traduis toujours unsigned char * par PChar, mais c'est un choix.

Edit : serais-je malade ? Je me suis trompé : ce n'est pas en convention pascal que le compilateur fait ce que je raconte plus haut, mais en convention par défaut, donc register. Corrigé.