Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
conflit de noms de classes
Bonjour,
j'utilise 2 api (apiA et apiB) dont je ne peux pas modifier le code, et chacune d'entre elle définit une classe qui a le même nom. Par exemple, apiA définit une classe Toto, et apiB définit une autre classe Toto, qui est différente mais qui porte le même nom. Et aucune des deux n'utilise de namespace.
Or, j'ai besoin d'utiliser ces 2 classes. Existe-t-il une solution pour résoudre ce conflit sans avoir à modifier les sources de ces api ?
Non.
Ha... ben ça a le mérite d'être clair. C'est bien ce que je craignais
Merci beaucoup pour votre réponse.
Si, tu peux les utiliser dans deux fichiers sources différents dont chacun n'inclut pas les fichiers d'en-tête de l'autre.
Mais tu ne pourras pas les utiliser dans le même fichier source, et si tu as besoin des types des deux dans le fichier d'en-tête et qu'une déclaration anticipée ne suffit pas, t'es eu...
Edit: Comme on me l'a fait remarquer, cela résout les problèmes de compilation mais pas ceux d'édition de liens --> KO.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
définit tes propres namespaces... recompile ta lib intermédiaire, et utilise la comme si les API d'origine fournissaient leur propre namespace
Non. Tu tombes dans du comportement indefini (rupture de la regle de la definition unique). Il est possible que ca ait l'air de marcher dans certains cas, mais j'ai du mal a l'imaginer si les deux classes ne partagent aucune signature de fonctions non inline, y compris les constructeurs et le destructeur et qu'aucune fonction libre ne soit surchargee pour les deux types (par exemple operator<<(ostream&,).Envoyé par Médinoc
En effet, j'oubliais les problèmes d'édition de liens : Je ne pensais qu'à la compilation...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
J'y avais pensé, mais je viens de voir quelque chose qui dépasse mon entendement: la LibA utilise la libB et inclus des fichiers de la LibB. (pour info, la libB c'est Direct Show et la libA c'est une lib propriétaire qui utilise direct show). Je ne comprends même pas comment ils ont réussi à compiler leur lib
t'es sur qu'il n'y a pas juste une notion d'héritage et de surcharge ?
Répondre avec citation
Partager