Re: Export class from dll

Remember that C++ classes describe not only the general characteristics of
the class at a high level, but also the actual in-memory layout of things
like the Vtable. You really, really, really don't want to be using separate
declarations in two places for the class. Your chances of matching them up
correctly are very low and there's no chance that you'd be able to maintain
them. The way that eVC's sample does it works just fine. Only when the DLL
itself is being compiled is dllexport uses; everyone else 'automatically'
sees dllimport, so that problem is solved and you can freely add, remove and
*reorder* things in the class without having to worry about properly doing
the same thing twice.

Paul T.

"Fred Harris" <FredHarris@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:D35B23AA-6647-4C39-965F-7B704DE186BA@xxxxxxxxxxxxxxxx
Thanks for the input John, Paul, Geoff. Yes, that should have dawned on
me
about the compiler not knowing the details of a CBox, only its name. I
think
I've made a decision on this, and that is to just declare and implement
the
class in both the host and the dll and not export it. What I do is write
grid custom controls which I place in dlls. I have a string class I wrote
and it works quite well, and I figured I'd put that in the dll and then be
able to use it in the internal dll code in the custom control, and in the
host app by exporting the class. I thought it might be easy but I see now
it
isn't. It may not even be worth doing, as all character string
minipulations
in the grid need to be done with pointers (its all instance data) anyway,
but
I thought I'd look into it now and start the project with cpp files
instead
of c files so I'd have the option later if it was worth while.

I guess the CString class could be used if I linked we MFC, but I'm not
'big' on big class libraries either.

This still isn't working, but its closer. It at least compiles and links,
although it won't calculate the volume...

/* dll */
extern "C" class __declspec(dllexport) CBox
{
public:
CBox(){}
CBox(double length, double breadth, double height)
{
m_length=length;
m_breadth=breadth;
m_height=height;
}

double Volume()
{
return m_length*m_breadth*m_height;
}

double m_length;
double m_breadth;
double m_height;
};
/* end dll */


/* host */
#include <stdio.h>

extern "C" class __declspec(dllimport) CBox
{
public:
CBox();
CBox(double length, double breadth, double height);
double Volume();
double m_length;
double m_breadth;
double m_height;
};

int main(void)
{
CBox box;

box.m_breadth = 2.0;
box.m_height = 3.0;
box.m_length = 4.0;
printf("box.Volume()=%d\n",box.Volume());
getchar();

return 0;
}
/* end host */


"John Spaith [MS]" wrote:

I was actually thinking along the same lines as Geoff of this one but
from a
slightly different angle. If you really need a C++ class from a DLL, it
sounds like COM. COM is obviously a lot more overhead that just a C++
class, especially if you have to ramp up on it, but exposing objects from
DLL's has been something we've relied on COM runtime to do in the MS
world
more than through the linker in practice.

--
John Spaith
Senior Software Design Engineer
Windows CE Networking
Microsoft Corporation

http://blogs.msdn.com/cenet/.

This posting is provided "AS IS" with no warranties, and confers no
rights.
You assume all risk for your use. © 2007 Microsoft Corporation. All
rights
reserved.

"Silver" <moc.liamtoh@gnirrevliseht> wrote in message
news:e92Z5oKHIHA.5328@xxxxxxxxxxxxxxxxxxxxxxx
Before I go any further why do you want to use C++? Does the design
lend
itself to it? If not then don't bother, you end up with something as
pretty as the USB host driver. Go look at it, tell me which line of
code
copies something from the PTD list into memory. If that isn't enough to
scare you off then go for it.

__declspec(dllimport) extern CBox;

int main(void)
{
CBox box;
....

How does the compiler know what CBox is? You are asking the compiler to
reserve space for a CBox on the stack but have told it nothing about
it,
therefore it is rightfully refusing to compile. It does not even know
that
it is a class.


You still need a class definition, such as a header file, for the
compiler
to use even though the functionality is in a dll.

e.g.
CBox.h <-- class definition and small inline functions
CBox.cpp <-- where the heavy functionality lives, like calculating the
area of the box ;)
Build this as a DLL.

Also, try this sort of thing instead, it will correctly 'new' the class
and put it on the heap instead of the stack.

#include "CBox.h"

int main(void)
{
CBox *box;

box = new CBox;
etc.....
}

Link this to the CBox.lib.

I really that this perhaps is not answering your question but the flow
is
hopefully logical and it gets the job done.

Geoff
--








.

Relevant Pages

  • Re: Export class from dll
    ... Thanks for the input John, Paul, Geoff. ... about the compiler not knowing the details of a CBox, ... class in both the host and the dll and not export it. ... How does the compiler know what CBox is? ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Export class from dll
    ... Looks like I had it right finally in that last post without knowing it. ... Only when the DLL ... about the compiler not knowing the details of a CBox, ... How does the compiler know what CBox is? ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Export class from dll
    ... How does the compiler know what CBox is? ... to use even though the functionality is in a dll. ... CBox.cpp <-- where the heavy functionality lives, ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Exposing bool to non-MS, non-C++ callers
    ... the functions in this DLL accept a structure as an argument. ... The compiler doesn't help catch places where I neglect ... the C++ bool type is defined as one byte. ... depends on whether the Exe caller will push a value larger than 1 byte. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Memory allocation methods
    ... all modules are compiled against the same CRT' DLL with the same compiler. ... that case you restrict yourself to a simple C-based API for the DLL. ... I prefer to use either exceptions (but writing exception-safe code is quite ...
    (microsoft.public.win32.programmer.kernel)
Loading