dll, chaine, pointeurs

Version imprimable

Hello,

J'ai une dll à réaliser. Avec quelques tuto et VC++, j'ai réussi à faire une dll qui me retourne un entier, aucun problème, tout va bien.

Or, j'ai voulu la modifier pour qu'elle me retourne une chaine, mais je ne m'en sors vraiment pas. Je merdoye dans les pointeurs à coup sûr. Pourriez-vous m'aiguiller svp ?

Le code qui suit est le seul qui me retourne quelquechose sans planter. Évidemment, ce qui est retourné n'est pas de la forme souhaitée.

Je suis sensée me retrouver avec un date formatée AAAAMMJJHHSSMM, mais je me retrouve avec une suite de nombre incohérents, que j'ai interprété comme étant une @ mémoire. (quoi que j'en doute car ce cnombre est toujours identique)

Alors comment my' prendre ? transtyper ma chaine en entier ? Trouver une soluce pour passer mon char en paramètre ?

Je suis sûr que mon erreur est toute bête ...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
// dllmain.cpp : Définit le point d'entrée pour l'application DLL.
#include "stdafx.h"
#include "time.h"
#include <iostream>
 
 
extern "C" __declspec(dllexport)void retourne_ts(int parametre, char TimestampARecuperer);
 
 
BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
					 )
{
	switch (ul_reason_for_call)
	{
	case DLL_PROCESS_ATTACH:
	case DLL_THREAD_ATTACH:
	case DLL_THREAD_DETACH:
	case DLL_PROCESS_DETACH:
		break;
	}
	return TRUE;
}
 
 
void retourne_ts(int parametre, char TimestampARecuperer)
{
	time_t timestamp;
    struct tm * t;
 
    timestamp = parametre;
    t = localtime(&timestamp);
 
	int jour[2] = {t->tm_mday};
	int mois[2] = {1+t->tm_mon};
	int annee[4] = {1900+t->tm_year};
	int heure[2] = {t->tm_hour};
	int minutes[2] = {t->tm_min};
	int secondes [2] = {t->tm_sec};
	char separateur [] = "/";
	char Timestampconcatene[15]; 
	sprintf(Timestampconcatene, "%02u%02u%02u%02u%02u%02u",*annee, *mois, *jour , *heure, *minutes, *secondes);
	TimestampARecuperer = *Timestampconcatene;
}

Et voici le code dont je me suis inspiré (vous noterez l'utilisation de '&' dans les paramètres int des fonctions. Chose que je n'arrive pas à réutiliser avec les char

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
// dllmain.cpp : Définit le point d'entrée pour l'application DLL.
#include "stdafx.h"
 
// This function is used to calculate the total area of a parallelepiped rectangle
int BoxArea(int L, int H, int W);
// This function is used to calculate the volume of a parallelepiped rectangle
int BoxVolume(int L, int H, int W);
// This function is used to get the dimensions of a rectangular parallelepiped
// calculate the area and volume, then pass the calculated values to the
// function that called it.
extern "C" __declspec(dllexport)void BoxProperties(int Length, int Height,
                                    int Width, int& Area);
 
 
BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
					 )
{
	switch (ul_reason_for_call)
	{
	case DLL_PROCESS_ATTACH:
	case DLL_THREAD_ATTACH:
	case DLL_THREAD_DETACH:
	case DLL_PROCESS_DETACH:
		break;
	}
	return TRUE;
}
int BoxArea(int L, int H, int W)
{
    return 2 * ((L*H) + (L*W) + (H*W));
}
 
int BoxVolume(int L, int H, int W)
{
    return L * H * W;
}
 
void BoxProperties(int L, int H, int W, int& A)
{
    A = 666;
    //V = BoxVolume(L, H, W);
}

Merci d'avance.

petite avancée, si je fais

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
 
// dllmain.cpp : Définit le point d'entrée pour l'application DLL.
#include "stdafx.h"
#include "time.h"
 
extern "C" __declspec(dllexport)void retourne_ts(int parametre, char& TimestampARecuperer);
 
 
BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
					 )
{
	switch (ul_reason_for_call)
	{
	case DLL_PROCESS_ATTACH:
	case DLL_THREAD_ATTACH:
	case DLL_THREAD_DETACH:
	case DLL_PROCESS_DETACH:
		break;
	}
	return TRUE;
}
 
 
void retourne_ts(int parametre, char& TimestampARecuperer)
{
	char test[256] = "testchaine";
	TimestampARecuperer = *test;
}

Ma chaine passe bien, mais je ne récupère que le premier caractère de ma chaine :(

Y'a pas moyen de déclarer des String() comme en java ou quelque chose dans le genre ?

21/11/2010, 08h54
Joel F

euh .... std::string ...
21/11/2010, 11h00
Emmanuel Deloget
Citation:

Envoyé par Joel F

euh .... std::string ...

Non pas, non pas ! :)

Le fait que le standard C++ ne définit pas d'ABI fait que les templates ne peuvent pas faire partie d'une interface de DLL. Les risques sont importants que cette DLL soit utilisée par un programme n'utilisant pas la même version de la librairie standard, ou (encore plus agaçant) par les même options de compilation. Et on obtiendra quelque chose qui plante, qui plante, qui plante.

Il est recommandé d'utiliser des pointeurs char* au niveau des interfaces, et (pour éviter les buffers overflow) un contrôle de la taille de ces pointeurs.
Code:

1 2 3 4 5 6 7 void get_times_stamp(char* out, std::size_t outsize) { char b[] = "timestamp"; std::size_t = std::min(sizeof(b), outsize); std::copy(b, b+outsize, out); }
Quand à la raison de ton erreur htrouve, tu passe en paramètre 1 caractère en référence. Tu n'obtiendra donc qu'un caractère en sortie de ta fonction.
21/11/2010, 11h37
Joel F

Citation:

Envoyé par Emmanuel Deloget

Le fait que le standard C++ ne définit pas d'ABI fait que les templates ne peuvent pas faire partie d'une interface de DLL. Les risques sont importants que cette DLL soit utilisée par un programme n'utilisant pas la même version de la librairie standard, ou (encore plus agaçant) par les même options de compilation. Et on obtiendra quelque chose qui plante, qui plante, qui plante.

:calim2: :aie:
certes, le coup des options de compilations, c'est purement MSVC ? Ou a t on le meme probleme avec des .so ou leur fonctionnement est-il tout a fait différent ?
21/11/2010, 13h16
htrouve

Citation:

Envoyé par Emmanuel Deloget

Quand à la raison de ton erreur htrouve, tu passe en paramètre 1 caractère en référence. Tu n'obtiendra donc qu'un caractère en sortie de ta fonction.

Bonjour et merci pour vos éléments de réponses. Cependant, je ne comprends pas pourquoi je ne passe qu'un seul paramètres alors que mon char peut en contenir 256 dans mon code.

Et quelle est la différence, dans le prototype de la fonction entre passer
char* mavariable et char& mavariable ?

Bon, j'ai réussi à faire quelque chose qui 'fonctionne', ma chaine retournée est entière cette fois !

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// dllmain.cpp : Définit le point d'entrée pour l'application DLL.
#include "stdafx.h"
#include "time.h"
#include <iostream>
#include <sstream>
 
 
extern "C" __declspec(dllexport)void retourne_ts(int parametre, char& TimestampARecuperer);
 
 
BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
					 )
{
	switch (ul_reason_for_call)
	{
	case DLL_PROCESS_ATTACH:
	case DLL_THREAD_ATTACH:
	case DLL_THREAD_DETACH:
	case DLL_PROCESS_DETACH:
		break;
	}
	return TRUE;
}
 
 
void retourne_ts(int parametre, char& TimestampARecuperer)
{
	char test[256] = "timestamp";
	TimestampARecuperer =  *test;
	strcpy(&TimestampARecuperer,test);
}

Si vous avez mieux, je ne demande qu'à comprendre et apprendre !

Encore merci.

21/11/2010, 21h03
3DArchi
Citation:

Envoyé par htrouve

Si vous avez mieux, je ne demande qu'à comprendre et apprendre !

on va le faire autrement. Que se passe-t-il si j'utilise ta DLL comme suit :
Code:

1 2 3 4 5 6 int main() { char c; retourne_ts(0,c); return 0; }
:aie:

Tu devrais passer explicitement un tableau et sa taille à ta DLL. Voir la réponse d'Emmanuel ci dessus.
21/11/2010, 21h21
htrouve

Euh franchement j'en sais rien, j'imagine que ca te retourne 01/01/1970 :D

J'ai pas trop compris le commentaire d'Emmanuel sur 'passe en paramètre 1 caractère en référence'.

Moi, tel que je le vois, je passe en paramètre un entier, et ca renvoit une chaine. Mais je ne comprends pas pourquoi avec mon premier code, ca ne me retournait que la 1e lettre de ma chaine.

Alors que quand je testais en printf, j'avais bien toute ma chaine formatée de retournée.

J'ai réussi à m'en sortir avec strcopy, mais j'aimerais bien comprendre le pourquoi du comment de mes erreurs en fait.
21/11/2010, 21h39
htrouve

Citation:

Envoyé par 3DArchi

Tu devrais passer explicitement un tableau et sa taille à ta DLL. Voir la réponse d'Emmanuel ci dessus.

Je crois avoir saisi ta remarque. Tu insinues qu'en C, les char sont des tableau dont chaque éléments contient un code ASCII/une lettre ? c'est ca ?

Et qu'en retournant un char, implicitement, je retourne le premier élément du tableau, d'où le fait que je ne récupérais qu'une lettre ?

Mais alors, pourquoi avec un strcopy, mon char retourne bien ma chaine complète ? :furieux:
22/11/2010, 21h06
Joel F

parce que par hasard tu ecrase la mémoire connee à ton char.
une chaine de caractères c'ets un char* + une taille. point.
22/11/2010, 23h13
JolyLoic

Citation:

Envoyé par Emmanuel Deloget

Non pas, non pas ! :)

Je mitigerais légèrement cet avis. En général, on fait des DLL pour l'une des trois raisons suivantes :

- Pour de la modularité, y compris avec des partenaires externes, ou avec d'autres langages de programmation. Dans ce cas, en effet, éviter des DLL avec du C++ dans l'interface, à plus forte raison un template.
- Pour de la modularité dans une application que l'on contrôle de bout en bout: Pouvoir réaliser des livraisons partielles, faire des montées de version sans arrêter le produit... Dans ce cas, et à condition bien entendu d'utiliser partout les mêmes options de compilation, le gain apporté par l'utilisation de vrais types (avec du RAII) dans les interfaces me semble supérieur au coût
- Parce qu'on n'a pas compris qu'une bibliothèque statique était plus adaptée.
23/11/2010, 10h44
Emmanuel Deloget
Citation:

Envoyé par Joel F

:calim2: :aie:
certes, le coup des options de compilations, c'est purement MSVC ? Ou a t on le meme probleme avec des .so ou leur fonctionnement est-il tout a fait différent ?

Tous les compilateurs sont impactés - il ne s'agit pas nécessairement de MSVC. Bien sûr, ça dépends fortement de l'implémentation de la librairie standard, et de la façon dont le compilateur fonctionne. Sans ABI (abstract binary interface) standardisée, on ne peut pas prédire ce qui peut se passer. Les .so peuvent être impactés de la même manière - mais il me semble que la librairie standard de g++ est beaucoup plus solide que celle de MS vis à vis de ce point. Mais ça ne veut pas dire que les opérateurs globaux ::new() et ::delete() auront la même définition dans les deux modules.

Supposons que ça soit le cas, et que mon module ajoute un élément à un vecteur créé par l'application. Cet ajout va peut être nécessiter un resize() du vecteur, et donc une nouvelle allocation, copie et désallocation du bloc précédent. Au moment de la desallocation, quel delete est utilisé ? Le surchargé ? le non surchargé ? Que se passe-t-il si le ::delete() du module tente d'utiliser des informations de debug qui n'existe pas ? Comment le détecte-t-il ? etc.

Pas d'ABI, redéfinition de comportements, etc: le C++, c'est quand même dangereux à utiliser au niveau des interfaces :) Et je ne parle même pas des templates, dont la génération peut changer en fonction des options de compilation :)

Citation:

Envoyé par JolyLoic

Je mitigerais légèrement cet avis. En général, on fait des DLL pour l'une des trois raisons suivantes :

- Pour de la modularité, y compris avec des partenaires externes, ou avec d'autres langages de programmation. Dans ce cas, en effet, éviter des DLL avec du C++ dans l'interface, à plus forte raison un template.

Le C++ est a éviter, encore que le problème se situe en fait bien souvent sur sur le runtime utilisé par l'un et l'autre des modules, ainsi que sur les options de compilation qui peuvent avoir un impact sur le code des classes utilisées dans l'interface. Je m'explique : supposons que la classe X soit ainsi faite:
Code:

1 2 3 4 5 6 7 8 9 class X { private: #if DEBUG int instance_count; #endif ... };
Dès lors que je vais compiler un module en debug, ma classe n'aura plus la même définition que celle, compilée en release, utilisée par l'application qui instancie mon module. Son comportement en sera donc modifié.

Mais en faisant très attention (et notamment en ne faisant pas ce que ke présente ci-dessus), on peut limiter le problème. Il y a quelques règles à respecter :

1) en paramètre à une fonction, on ne passe que des pointeurs ou des références.
2) le module qui instancie une classe la détruit (par exemple, au cas où new/delete auraient été surchargés dans le module qui utilise l'instance).

Citation:

Envoyé par JolyLoic

- Pour de la modularité dans une application que l'on contrôle de bout en bout: Pouvoir réaliser des livraisons partielles, faire des montées de version sans arrêter le produit... Dans ce cas, et à condition bien entendu d'utiliser partout les mêmes options de compilation, le gain apporté par l'utilisation de vrais types (avec du RAII) dans les interfaces me semble supérieur au coût

Voui, ça marche. En fait, c'est même l'un des rares cas où ça marche. Mais lorsque le projet est composé de plusieurs dizaines de DLL générées par toute une équipe (ça existe), c'est quelque fois difficile d'accorder les options de compilation sur tous les projets (et généralement, c'est le client qui s'en apperçoit, hein ?)

Citation:

Envoyé par JolyLoic

- Parce qu'on n'a pas compris qu'une bibliothèque statique était plus adaptée.

+1 :) Et personnellement, je commence à avoir une impression de "j'aime pas" lorsque je vois des DLL dans un projet. Et je suis incapable de savoir d'où provient cette impression.
23/11/2010, 14h36
Médinoc
Pour les DLLs, il est déconseillé de passer par des classes comme std::string.

Sous Windows, les deux méthodes préférées sont:
- Buffer de caractères en entrée (avec option de retourner la taille requise quand on passe un buffer nul)
- Allocation de BSTR (attention, Visual Basic n'aime pas les BSTR hors des classes COM: Il change leur encodage de UTF-16 à Windows-1252).
Tu peux aussi allouer un char* dans la DLL et le retourner, mais alors il est conseillé que ce soit la DLL aussi qui le désalloue (typiquement, la DLL exporte une fonction à cet effet).
23/11/2010, 18h36
htrouve

Merci pour vos interventions, qui dépassent largement mes compétences en C/C++ (proches du néant).

Je vais tenter de digérer vos infos et de recoder ma toute petite librairie dans les règles. C'est pas gagné :mrgreen: