Discussion :

[flesenne]

Bonjour à tous,

Je développe une dll contenant des classes et des objets.
Une fonction qui crée un objet dynamique doit retourner le pointeur de l'objet + autres info.
Voici la structure déclarée :

Code :

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

1
2
3
4
5
typedef struct {
    HSMixer G_Mixer;
    HSSTREAM G_Source;
    HANDLE G_Objet;
} WB_PLAYLIST;

Puis la méthode de la classe qui doit retourner la structure en question :

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
 
class Play_list {
 
private :
    WB_PLAYLIST m_str_playlist;
....
 
public:
    WB_PLAYLIST* Creer();
....
};
 
WB_PLAYLIST* Play_list::Creer() {
....
 
    this->m_str_playlist.G_Mixer = this->m_mixer;
    this->m_str_playlist.G_Source = this->m_source;
    Play_list *const id_objet = this;
    this->m_str_playlist.G_Objet = static_cast<HANDLE>(id_objet);
 
    return &this->m_str_playlist;
}

Dans la structure m_str_playlist je récupère bien les infos mixer et source que je souhaite mais dans id_objet j'ai un doute.
Je ne suis pas certain de récupérer le pointeur sur l'objet. Pour info, je récupère bien une valeur (ex:5726840) qui peut être une adresse.

Compte-tenu que mon niveau en C++ n'est pas très élevé, je vous sollicite une nouvelle fois pour me donner votre avis sur le code présenté.
L'utilisation qui est faite du static_cast permet elle de récupérer l'adr de l'objet ? Comment vérifier ?
Merci de votre aide précieuse.

[Bousk]

Salut,

c'est quoi la question ? Si this retourne bien this ?

[white_tentacle]

Si « Creer » crée un nouvel objet, elle devrait être statique, non ? Et renvoyer un nouvel objet, pas this… Mais quel est l’intérêt par rapport à new ?

[foetus]

L'utilisation qui est faite du static_cast permet elle de récupérer l'adr de l'objet ? Merci de votre aide précieuse.

Tu as besoin du static_const parce que tu crées une variable locale inutile et constante

Code :

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

1
2
3
4
5
6
7
8
9
10
WB_PLAYLIST* Play_list::Creer() {
 
    ....
 
    this->m_str_playlist.G_Mixer  = this->m_mixer;
    this->m_str_playlist.G_Source = this->m_source;
    this->m_str_playlist.G_Objet  = this;
 
    return &this->m_str_playlist;
}

Après si l'attribut G_Objet n'est pas du même type que this, il faut soit caster soit réfléchir (caster n'est pas une fin en soi )

Comment vérifier ?

Au debugger , regarder si l'adresse de l'objet et la même qui garnie l'attribut.

[bacelar]

@flesenne, déjà, j'étais pas fan de l'utilisation de classe dans l'API d'une Dll, dans tes posts précédents.
VS permet de faire ce genre d'acrobatie mais, franchement, à par rendre inutilisable tous les avantages des Dll par rapport à des bibliothèques statiques, et mettre plein de peaux de banane aux débutants, c'est vraiment à éviter comme la peste.
Si c'est pour rendre une API, POO, fournit un wrapper objet sous forme de .h qui encapsule l'API C (même avec des concepts de POO) de le Dll.

Il suffit que ta Dll et ton applicatif n'utilise pas la même C-Runtime, ton API avec des pointeurs donc des problèmes de deletes, d'alignement, de padding, etc..., va te faire suer.
C'est inutilisable si ce n'est pas le même compilateur avec exactement les même réglages, c'est donc totalement inutile d'en faire une Dll.

[Médinoc]

Généralement, pour une DLL C++, j'y vais façon COM, sans les parties compliquées (pas d'enregistrement, j'exporte juste des fonctions de création retournant des interfaces COM, pas d'histoires de marshaling, etc.)

Parfois même, une interface ne dérivant même pas de IUnknown (pas de comptage de référence ni de QueryInterface), mais déclarée avec la macro DECLARE_INTERFACE pour être utilisable depuis C et C++.