Class method declaration from a different context

[ordana]

Hi guys, I have a question about class method declaration of externally defined object... it's quite difficult to explain so here is an example of my situation:

my project is composed of some static libraries, say my_lib1..., and the executable my_app, which links the libraries.
From my_lib1 I want to call a method of a global object (MyType g_my_object) declared and defined in my_app. Generally I would have written:

//In my_lib1, where I want make the call
#include "MyTypeHeader.h"

extern class MyType g_my_object;
//...
g_my_object.MyMethod();

the problem is that MyType class is declared in my_app and I can't simply include MyTypeHeader.h class header because the class if full of elsewhere defined type attributes (and MFC specific types).

So my question is: is there any way of making a declaration of MyMethod()?

After some tries this seems to work, but I don't know why and if it is the correct approach:

//In my_lib1, where I want make the call
//I made a declaration of MyType specifying only the interested method, with the right signature and visibility
class MyType{
public:
void MyMethod();
};
extern class MyType g_my_object;
//...
g_my_object.MyMethod();

thank you in advance! Alessandro.

[clanmjc]

I'm not 100% sure I follow, so that is my disclaimer, however, if you are able to modify one of the other classes, couldn't you just wrap one in a namespace then when you need to make the calls use the resolution operator?

_{After all that is one of the reasons namespaces exist, to resolve ambiguity.}

[JLBorges]

> After some tries this seems to work, but I don't know why and if it is the correct approach:

//In my_lib1, where I want make the call
//I made a declaration of MyType specifying only the interested method, with the right signature and visibility
class MyType{
public:
void MyMethod();
};

No. It is a gross violation of ODR http://en.wikipedia.org/wiki/One_Definition_Rule


> the problem is that MyType class is declared in my_app and I can't simply include MyTypeHeader.h class header
> because the class if full of elsewhere defined type attributes (and MFC specific types).

You could define a helper function in my_app (in a separate header, say MyType_helper.h)

class MyType ; // opaque
void call_MyMethod( MyType& This ) ;  

Implement it in the implementation file (MyType_helper.cpp) as

#include "MyType_helper.h"
#include "MyTypeHeader.h"
void call_MyMethod( MyType& This ) { This.MyMethod() ; }

And then in my_lib1,

#include "MyType_helper.h"

// ...

call_MyMethod( g_my_object ) ;

[ordana]

Thank you for your answer, JLBorges your solution works, I had only to add:

//MyType_helper.h
class MyType ; // opaque
extern class MyType g_my_object;
void call_MyMethod( MyType& This ) ;

So my suspects were true... I have to write such a call_MyOtherMethod for each other method I need to "export".

Thank you again for your super-fast answer!

[JLBorges]

> So my suspects were true... I have to write such a call_MyOtherMethod for each other method I need to "export".

The other option would be to have a base class for MyType (which has no dependencies on things like MFC) where MyMethod(), MyOtherMethod() etc. are pure virtual functions. And in in my_lib1, use the base class operations polymorphically.

[ordana]

This is exactly what I was looking for! So I can use it as general MFC-independent interface for my object, thank you very much!
I'm not new with C++ but this is the first time I use it seriously and I still forget some C++ features like multiple inheritance :b