Exporting a Template class from a DLL?!?!?! And inlines?
Joseph Renda
I'm converting a few static .libs, (archives) into DLLs. I've got a couple
of problems that I don't know how to solve.
1st. How do I Export templet classes and functions???? Visual C++ does not
support export of template class or
functions. BUT: I understand there is a workaround buzzing around...
something about declaring the template class or
functions with declspec attribute in the DLL and instantiate all possible
types in the DLL source? I don't understand
this! Anybody can help me in this one?!? Maybe some quick code snippets?
2nd Question. I'm exporting public functions! in my DLL, what happens when a
public inline function calls a private non-inline??? ie: the call to the
private function ends up in another DLL? this will break no?? Do I need to
export all
private functions accessed by inlines??? Is that possible?
Anybody know of examples of this??? somewhere on the net?
Ed Astle
However, if you do a release build then the code (if enabled, which it is by
default) does become inlined. Suddenly your dll does not actually have
export info for these functions because they don't really exist anymore.
Code that requires access to "internal" dll stuff, whether its data or
private functions, should not be inlined, via "inline" or being lazy and
putting actual code in header files !
eg
header file...
class X
{ public:
__declspec( dllexport ) void some_routine()
{
printf( "hello" );
}
}
In a debug build the above will actually be exported from the dll. In a
release build the code will be inlined and the dllexport will have no effect
because the function will not be packaged inside the dll - it's inlined into
whatever .cpp the end user #includes the include file into. This is quite
dangerous, actually, if your dll uses one heap system (eg release
multithreaded support) but the end user is using debug single threaded - two
heap managers will be in force so trying to share heap memory between the
dll and the end user will cause severe problems. Memory allocated in a dll
must be freed by the same dll and not the end user. Just a tip.
You can export specific template implementations. For example, if you have
MyTemplate< MyType > used in your lib/dll then you can export this specific
implementation (I think you just "template class MyTemplate< MyType >;" in
your header file, which forces the functions to be generated). Check out
"Explicit Instantiation" in the MS docs. But you cannot export the generic
template code, if you know what I mean. The .h (the template definition)
and the .inl (the template code) must be available to the end user to
#include.
Anyway, I think that's the case...
Ed.
Joseph Renda <jre...@sympatico.ca> wrote in message
news:i0n14.102430$up3.1...@news21.bellglobal.com...
Martin Aupperle
wrote:
>
>I'm converting a few static .libs, (archives) into DLLs. I've got a couple
>of problems that I don't know how to solve.
>
>1st. How do I Export templet classes and functions???? Visual C++ does not
>support export of template class or
>functions.
Sure it does. A template class is a regular class with a funny name.
But probably you want to export class templates, and this is
impossible. You even can't store class templates in LIBs.
So, if you can have something in a LIB, you can also have it in a DLL
(with caution) . Your problem must be something different. Give us
more information.
>BUT: I understand there is a workaround buzzing around...
>something about declaring the template class or
>functions with declspec attribute in the DLL and instantiate all possible
>types in the DLL source?
Well, it really seems that you want to export a class template. But
you can only export template classes (i.e. instantiations). It is
definitely no good idea to pre-instantiate ALL POSSIBLE classes end
export those! Think of instantiating the most important ones to save
code, and live with the rest.
>2nd Question. I'm exporting public functions! in my DLL, what happens when a
>public inline function calls a private non-inline???
No problem. Think of the inline function as a macro. The code is not
put into the DLL but expanded when the client compiles. It goes into
the code space of the client. That's why you must make the inline
function visible in the client, even if the class is in the DLL.
------------------------------------------------
Martin Aupperle
MikeAlpha@NoSpam_csi.com
(remove NoSpam_)
------------------------------------------------