Question

Given the classes Foo and Bar where Bar is derived from Foo, how could I export Bar without having to export Foo ?


Foo.h

class Foo
{
    public:
        Foo();
        virtual bool Read(...);
        virtual bool Write(...);
        ~Foo();
};


Bar.h

#ifdef BUILD_DLL
#    include "Foo.h"
#    define EXTERNAL __declspec(dllexport)
#else
#    define EXTERNAL __declspec(dllimport)
#endif 

class EXTERNAL Bar: public Foo
{
    public:
        Bar();
        bool Read(...);
        bool Write(...);
        ~Bar();
};



Edit

This is the warning that Visual C++ 2010 gives me:

warning C4275: non dll-interface class 'Foo' used as base for dll-interface class 'Bar'



Edit #2

Here's what I did to sort-of solve the issue. I made Foo and Bar separate DLL's. The client application links to Bar.dll and Bar.dll links to Foo.dll. This works well for what I was trying to achieve...

Was it helpful?

Solution

Doesn't that work? It should. Just because you're not explicitly exporting the class doesn't mean the logic isn't in the binary. The symbols just aren't visible to anything importing that class.

Your solution should do it. Are you getting linking errors or what?

EDIT: I just saw you only include the header for Foo in one case. You don't need to do that:

#ifdef BUILD_DLL
#    define EXTERNAL __declspec(dllexport)
#else
#    define EXTERNAL __declspec(dllimport)
#endif 

#include "Foo.h"

class EXTERNAL Bar: public Foo
{
    public:
        Bar();
        bool Read(...);
        bool Write(...);
        ~Bar();
};

This way you can't use Foo in a different module since it's not exported, but you can use and declare Bar.

OTHER TIPS

Foo is needed to create a Bar instance - in fact, to create Bar, Foo's constructor is called prior to Bar's constructor.

I highly doubt you can export one and use it without exporting the other.

Im not sure what is this good for?

If you simply try to hide Foo from you customers (like i sometimes do, but not with Foo), just export it as usual...

Make a Dll out of it (link Foo.cpp to your Bar.dll) and kill the Foo class from the headers you deliver with you library/Dll file.

A inhertited class isn't visible to the user of an dll (when you don't choose to export the methods of this class with #define EXTERNAL __declspec(dllexport).

So: Foo is hidden to the user/customer.

Just relax ;)

As w00te mentioned earlier you can't do this the way you suggest.

Could you please provide description of your use case? May be some other decisions would be helpful? F.ex. if you need to pass the Bar object outside of the dll you can create interface to it and reveal it instead of Bar object.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top