exporting classes in a non-mfc dll

[joeGrammar]

Something tells me this may be a pain in the arse. Has anyone ever done this? Let me know

 

[Cagliostro]

exporting:
class __declspec(dllexport)
xxxxx
{
};
importing
class __declspec(dllimport)
xxxxx
{
};
for using the same .h for both you can in it:
#if defined(__DLL_IMPL)
#define dllapi __declspec(dllexport)
#else
#define dllapi __declspec(dllimport)
#endif

so in all dll implementations .cpp the first line you will put #define __DLL_IMPL, but in client programs is noting required. the classes you'll declare as
class dllapi xxx
{
};
instead of __DLL_IMPL and dllapi you can put
your own names
John Fill

ivfmd@mail.md

 

[joeGrammar]

ok, when I try to export my class, I get unresolved symbols. If I leave the class non exported, the symbols will resolve. The symbols are meant to be defined outside of scope(console application accessing the dll). Anyways here is my code, let me know if you see anything wrong


class abstract

{

abstract();
~abstract();
public:

virtual void pvfun() = 0;
void dumbfun();

};

class __declspec(dllexport) derived : public abstract

{

public:

derived();
~derived();

virtual void pvfun();


};

 

[Cagliostro]

Below is a piece of the dll's .h file. Followind the idea above, your internal dll classes and functions which you're not exporting mustn't be visible from DLLs clients(see class abstract):
#if defined(__DLL_IMPL)
#define dllapi __declspec(dllexport)
#else
#define dllapi __declspec(dllimport)
#endif


#if defined(__DLL_IMPL)
//so you should be assured which declarations
//to bi visible only in your dll, which only from
//DLLs cliend and which ones from both
class abstract
{

abstract();
~abstract();
public:

virtual void pvfun() = 0;
void dumbfun();

};
#endif
class dllapi derived
#if defined(__DLL_IMPL)
: public abstract
#end

{

public:

derived();
~derived();

virtual void pvfun();


}; John Fill

ivfmd@mail.md

 

[joeGrammar]

ok using the interface doesn't seem to work for me. Here is my revised code below, I get the same unresolved error

#include <iostream.h>

#define __DLL_IMPL

#if defined(__DLL_IMPL)
#define dllapi __declspec(dllexport)
#else
#define dllapi __declspec(dllimport)
#endif


class dllapi abstract

{

public:
abstract();
~abstract();


virtual void pvfun() = 0;
void dumbfun();

};

class dllapi derived : public abstract

{

public:

derived();
~derived();

virtual void pvfun();


};

I want to export both of them... it seems to have a problem with no definition for pvfun() while trying to export. Isn't there a way around this?

 

[Cagliostro]

try to add the .lib resulted in compilling youd dll to your linker options of your console application. John Fill

ivfmd@mail.md

 

[joeGrammar]

This has nothing to do with the console application, this error occurs while creating the dll

 

[Cagliostro]

which symbol is not defined? You can have troubles on making dll fith console input/output functions, like cin/cout/printf.... You can't use them in WinAPI applications however all WinAPI functions are supported by console applications. John Fill

ivfmd@mail.md

 

[joeGrammar]

the pvfun() is coming up as not resolved, but I don't want to have to define it yet, I was to define it in a console application

 

[Cagliostro]

as you see the pvfun in derived is not pure virtual. It means you must implement it. You may to not implement this function in class abstract because it is pure virtual. John Fill

ivfmd@mail.md

 

[joeGrammar]

yes but I don't want to implement it, I just want it as an interface in the dll. I'm creating several console applications which are going to access this DLL. I want to define pvfun() in each of these console applications. I don't want to define it in the dll. There must be a workaround to fool the compiler to think its been defined so it will resolve so I can define it within the console application

 

[Cagliostro]

In this case you should thinking a little other ways. In my opinion you want to use in one process some data instances from other processes whici loads this dll.
in this case you do

class dllapi abstract
{
public:
virtual void pfunc() = 0;
};
dllapi abstract* sharedclass;

you don't need the derived in the dll.
make some class implementations in dll cliencts as:
//load the dll
class some_derivedublic abstract
{
public:
virtual void pfunc(){implementation here;}
};
int main()
{
charedclass = new somederived;
//do something...
return 0;
}

in some other client

int main()
{
sharedclass->pfunc();
}
John Fill

ivfmd@mail.md

 

[joeGrammar]

Oh I figured it out, I'm going to use conditional compilation and then include the header file in the console application. That way it will resolve and be also able to be defined in the console application.

I am so smart

smrt!