(I'm using VC++ Net 2003)
Consider this simple template example.
Why does it give the "myclass<T>::myclass(): definition of dllimport
function not allowed" warning?
This happens when compiling the DLL2.

myclass.h

// EXP_IMP1 is dllexport if inside DLL1 and dllimport if outside

template <class T>
class EXP_IMP1 myclass{
public:
myclass();
T a;
};

template <class T>
inline myclass<T>::myclass()
{
a = 4;
}

myclass.cpp (in DLL1)

#include "myclass.h"
template class EXP_IMP1 myclass<int>; // Explicit instantiation

mylib.h:

#include "myclass.h"

// EXP_IMP2 is dllexport if inside DLL2 and dllimport if outside

class EXP_IMP2 anotherclass{
public:
myclass<int> test;
};

mlib.cpp:

#include "mylib.h"

This warning vanishes if I put the myclass constructor implementation inside
the class definition:

myclass.h:

template <class T>
class EXP_IMP1 myclass{
public:
myclass() { a = 4; }
T a;
};

But aren't these two ways equivalent ?

Have you tried explicitly instructing the compiler to export the
constructor in the first snippet? It may be that it is automatically
being exported as an implicitly inlined function but not otherwise.
You are correct that they should otherwise be identical, though, as
far as I can tell. The net in either case should be a dll that
exports 2 default constructors and 2 copy constructors.

"Kalle Rutanen" <kalle_rutanen@nospam.hotmail.com> wrote in message news:<bviq13$7q4$1@phys-news1.kolumbus.fi>...

ack! I didn't pay enough attention before posting. Didn't realize
you had two seperate projects and didn't look carefully enough at the
error message. Sorry.

The easiest solution is to just redefine the EXP_IMP2 in the second
project to match the defines in the first.

"Kalle Rutanen" <kalle_rutanen@nospam.hotmail.com> wrote in message news:<bviq13$7q4$1@phys-news1.kolumbus.fi>...

But then the code of the class "anotherclass" would be generated in the DLL1
(assuming the header was included in DLL1), and I want it to reside in DLL2.
Maybe it's just another bug... This is supported by the fact that I can
create a normal class (without template) with the inline functions defined
outside of the class, export it and use it in another dll.

Though the only thing that I lose by placing the class implementation inside
the class definition is that the code get's somewhat messier, because I
can't see the class's function-headers and variables at once.

"Kalle Rutanen" <kalle_rutanen@nospam.hotmail.com> wrote in message news:<bvljd8$m1i$1@phys-news1.kolumbus.fi>...
Why would you include the second project's headers in the first
project? If your coupling is so confused as to prevent clean division
between projects, you should probably be rethinking your solution.
Otherwise, each dll contains what it should. You can verify this with
dependency walker.

It isn't a bug, you're just getting confused by the dllimport/export
macros.

I've heard that it violates the principle of least priviledge or some
such mumbo jumbo. Not much choice w/ templates, though.

Consider I have a math-engine and a 3d-engine both located in their own
dlls.
The 3d-engine naturally uses matrices and vectors so it is dependent on the
math engine.
Now, in my application projects, I may wish to use the math engine but not
necessarily the 3d-engine.

The original code won't compile, because it gives an error (wrote it wrong
as a warning in the first message...). The "functions inside the class
declaration" works just as expected.

Well, the definition of bug is quite unclear in this situation, because the
behaviour of the dllimport/dllexport is not standard C++, but Microsofts
extension, so they decide what is possible and what is not.

But think about what would be reasonable:
(Note that the dll, in which the class is defined, is properly compiled and
linked. The error appears when including the header file in another dll's
source)

If you don't use templates, then the "inline functions inside
dllexported/imported class declaration in the same header" is identical to
the "inline functions outside dllexported/imported class declaration in the
same header". This is easily verified by writing the code. This is
reasonable.

Now you use templates, and think you can use them to avoid repeating the
same code with another type. You use "inline functions inside
dllexported/imported class declaration in the same header" and everything
goes fine. Now you think that it is more clear to use "inline functions
outside dllexported/imported class declaration in the same header". You try
it... no luck. You get an error, which is not in any sense reasonable.
Nothing is gained by denieing this possibility, although it is very clear by
analogy what the compiler is supposed to do. This is not reasonable.

You can't export a pure template since a template doesn't produce
any code until you instantiate it. It's like trying to export a
macro. There's no code yet until you actually fill in the
brackets.

On Sun, 1 Feb 2004 14:04:20 +0200, "Kalle Rutanen"
<kalle_rutanen@nospam.hotmail.com> wrote: