Discussion :

[detourbetx]

Hello � tous,

J'ai du migrer un programme C vers un compilateur C++ suite � l'ajout d'une biblioth�que dynamique compiler dans ce dernier.
Le changement de compilateur me retourne une erreur que je n'avais pas sur un compilateur C.
Malheureusement je ne maitrise pas le C++, et esp�re que les fonctions incrimin�es et le log du compilateur inspirera une �me charitable

Merci par avance.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
 
H:\sandbox\test\main.cpp||In function 'BOOL ReadCOM(void*, int, int*)':|
H:\sandbox\test\main.cpp|207|error: invalid conversion from 'int*' to 'PDWORD {aka long unsigned int*}' [-fpermissive]|
C:\Program Files (x86)\CodeBlocks\MinGW\include\winbase.h|2012|note: initializing argument 4 of 'BOOL ReadFile(HANDLE, PVOID, DWORD, PDWORD, LPOVERLAPPED)'|
 
H:\sandbox\test\main.cpp||In function 'BOOL WriteCOM(void*, int, int*)':|
H:\sandbox\test\main.cpp|221|error: invalid conversion from 'int*' to 'PDWORD {aka long unsigned int*}' [-fpermissive]|
C:\Program Files (x86)\CodeBlocks\MinGW\include\winbase.h|2206|note: initializing argument 4 of 'BOOL WriteFile(HANDLE, PCVOID, DWORD, PDWORD, LPOVERLAPPED)'|

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
 
 
BOOL ReadCOM    (void* buffer, int nBytesToRead, int* pBytesRead);
BOOL WriteCOM   (void* buffer, int nBytesToWrite, int* pBytesWritten);
 
 
BOOL ReadCOM(void* buffer, int nBytesToRead, int* pBytesRead)
{
    return ReadFile(g_hCOM, buffer, nBytesToRead, pBytesRead, NULL);
}
 
 
BOOL WriteCOM(void* buffer, int nBytesToWrite, int* pBytesWritten)
{
    /* écriture sur le port */
    return WriteFile(g_hCOM, buffer, nBytesToWrite, pBytesWritten, NULL);
}

[bacelar]

Laissez-moi vous dire qu'un �diteur/d�veloppeur qui force le passage d'une API C � une "API" C++, moi, j'appelle cela un gros guignol.
Les API C++, c'est tellement merdique actuellement (le draft du standard C++17 � encore repousser sa standardisation, snif) que passer d'une API C � une "API" C++ n'a aucun de putain de sens.

On va faire l'abstraction de cette connerie et faire �a comme un petit exercice "� la con".

Votre code, c'est clairement du code C et pas du code C++ :
- pas de typedef BOOL tout moisi mais l'utilisation du type int�gr� bool.
- renvoyer un BOOL au lieu de renvoyer la chaine lue pour la fonction "ReadCOM"
- Utilisation d'un code retour pour g�rer des erreurs et pas d'utilisation d'exceptions
- Utilisation de pointeur � la place de r�f�rences pour les param�tres
- etc...

On ne va pas faire du C++, on va essayer de rendre votre code C compilable dans un compilateur C++.
OK ?

Votre code C ne compile pas en C++ car le compilateur C++ est beaucoup plus tatillon que votre compilateur C, semble-t-il.
Mais l'erreur, elle existe, aussi bien en C qu'en C++.

Vous passez aux fonctions Win32 ReadFile et WriteFile (qui sont des API C et pas C++ au demeurant), en 4�me param�tre un "int*" et pas un "PDWORD".
Avec les options de compilation actuels "PDWORD" est �gale � "long unsigned int*".
Donc, si voulez que le compilateur ne vous engueule plus, ne passez pas un "int*" mais un "long unsigned int*".
Mais d�s que vous allez changer d'options de compilation, �a va �tre encore la foire � saucisse.
Donc, soit vos fonctions "ReadCOM"/WriteCOM sont de simple wrapper "fin" sur l'API Win32 et vous utiliser les m�mes signatures que les primitives de bases :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
BOOL ReadCOM(LPVOID buffer, DWORD nBytesToRead, LPDWORD pBytesRead)
{
    return ReadFile(g_hCOM, buffer, nBytesToRead, pBytesRead, NULL);
}
 
 
BOOL WriteCOM(LPVOID buffer, DWORD nBytesToWrite, LPDWORD pBytesWritten)
{
    /* écriture sur le port */
    return WriteFile(g_hCOM, buffer, nBytesToWrite, pBytesWritten, NULL);
}

Soit vous en faite de "vraies" fonctions qui doivent vraiment s'occuper du transtypage de ses param�tres avant de les passer en argument des primitives Win32 ("gestion" des param�tres n�gatifs via assert, etc...).
Quitte � faire ce travail de transtypage, pensez � utiliser toutes les fonctionnalit�s qu'offre le C++ comme les exceptions, les conversions implicites et explicites, les classes de la STL comme std::string ou std::vector<>, etc...

P.S.: "g_hCOM", les globales, c'est CACA.

[detourbetx]

Merci beaucoup d'avoir pris le temps de me r�pondre.
Je reconnais bien mon incomp�tence en C++ et vais m'y mettre s�rieusement, je code principalement pour des microcontroleurs.
J'avais d�j� essay� de corriger la signature des fonctions avec LPDWORD en lieu et place du int* mais sans succ�s m'ouvrant une autre erreur.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
 
main.obj||error LNK2019: symbole externe non résolu "int __cdecl ReadCOM(void *,int,int *)" (?ReadCOM@@YAHPAXHPAH@Z) référencé dans la fonction _main|
main.obj||error LNK2019: symbole externe non résolu "int __cdecl WriteCOM(void *,int,int *)" (?WriteCOM@@YAHPAXHPAH@Z) référencé dans la fonction _main|
bin\Release\mes_tests.exe||fatal error LNK1120: 2 externes non résolus|
||=== Build failed: 3 error(s), 6 warning(s) (0 minute(s), 0 second(s)) ===|

J'ai trouv� une classe C++ sur le site de developpez.net, je vais me rabattre sur cette solution m�me si � premi�re vue elle utilise aussi l'API Win32
https://cpp.developpez.com/faq/vc?pa...Communications

Merci pour votre aide et vos explications.

P.S : Autant pour moi je n'avais pas mis � jour tous les symboles, le code fonctionne. Merci !

[bacelar]

Je reconnais bien mon incomp�tence en C++

Pas de probl�me, Rome ne s'est pas faite en 1 jour.
Mais c'est bien de savoir qu'on n'est pas encore arriv�.

fonctions avec LPDWORD en lieu et place du int* mais sans succ�s m'ouvrant une autre erreur.

L'erreur, ici, est une erreur de link.
Le message d'erreur indique ce que le linker n'a pas trouv� dans les .obj et .lib qu'on lui � donn�.
Aux noms des fonctions nom trouv�es ("int __cdecl ReadCOM(void *,int,int *)" et "int __cdecl WriteCOM(void *,int,int *)"), il cherche les fonctions avec les anciennes signatures ( "int*" en 3�me param�tre et pas "long unsigned int*" pour LPDWORD ), c'est des choses qui devrait �tre dans les .obj g�n�r�.
Il y a donc discordance entre les .h et les .cpp.
le "int" devant "int __cdecl ReadCOM(void *,int,int *)", c'est le "vrai" BOOL, sans la ruse des MACRO.
"int __cdecl ReadCOM(void *,int,int *)", c'est pour indiquer que la fonction utilise les conventions d'appel � la "C", et pas les conventions d'appel "standard" de Windows.
"int __cdecl ReadCOM(void *,int,int *)", c'est le nom de la fonction.
"int __cdecl ReadCOM(void *,int,int *)", c'est le LPVOID du 1er param�tre de la fonction, normalement.
"int __cdecl ReadCOM(void *,int,int *)", c'est le DWORD du 2�me param�tre de la fonction, normalement, mais c'est bizarre si la compilation est en 64bits.
"int __cdecl ReadCOM(void *,int,int *)", c'est le LPDWORD du 3�me param�tre de la fonction, normalement, mais c'est bizarre si la compilation est comme celle d'avant qui attendait un "long unsigned int*".

Les cas les plus classiques de "discordance" entre les .h et les .cpp, c'est que la signature dans le Cpp n'est pas la m�me que dans le .h.
Si vous utilisez maladroitement les pre-compiled headers (stdAfx.h), il peut aussi avoir d�synchronisation entre le .h et ce que le compilateur utilise (il utilise une vielle version du .h).

P.S : Autant pour moi je n'avais pas mis � jour tous les symboles, le code fonctionne. Merci !

On parle donc d'un probl�me de pre-compiled headers ?
Parce que "symboles", c'est assez flou pour moi, ailleurs que dans les informations de d�bug.

si � premi�re vue elle utilise aussi l'API Win32

C'est l'API standard de Windows (ou presque, parce que les API OS/2 ou POSIX de Windows, c'est vraiment du foutage de gueule), donc, soit elle est utilis� directement ou c'est une biblioth�que qui l'utilise et vous utilisez cette biblioth�que.
Vous utiliserez donc forc�ment Win32 soit directement soit indirectement.

L'exemple que vous montrez est bien un wrapping "lourd" qui utilise les fonctionnalit�s du C++ pour simplifier grandement l'utilisation d'un port COM, m�me dans des situations complexes.

C'est le genre d'outil qui vous fait gagner beaucoup de temps.
Mais cette classe utilise des archa�smes comme des "return -1" en cas d'erreur, etc...
�a sent le programmeur C qui s'est essay� au C++ ou un programmeur C++ qui a fait une API C++ mais avec pas mal de C dedans pour pas trop perdre d'utilisateur C.
Attention aussi qu'il utilise des trucs comme "AfxMessageBox" ou "CString" qui ne sont disponible qu'avec MFC, une surcouche � Win32.

Donc, utilisez l� pour gagner du temps, mais ne vous en servez pas comme exemple de conception d'une classe C++.

[detourbetx]

Un grand merci pour ces pr�cisions, puisse un jour avoir les m�mes connaissances.
Vous avez vu juste c'est une mauvaise manipulation des pre-compiled headers qui est � l'origine de la deuxi�me erreur.
C'est pourtant une erreur de base, j'aurais du trouver et r�soudre le probl�me de suite, comme vous le dites le chemin est encore long
Encore merci d'avoir pris le temps de d�velopper vos r�ponses c'est appr�ciable, elles ont �t� lues religieusement.