Prev: Loading numbered files in sequence
Next: Which inclue file to use to use the winapi. Not using stdafx or MFC.
From: Alex Blekhman on 24 Apr 2008 04:20
<muybluie(a)hotmail.com> wrote:
> In a different DLL, I link with the the LIB for the above code,
> and attempt to use 'B'. However, I get an 'unresolved external'
> linker error for 'B::method'. The weird thing is that if I
> change the method to not be virtual, or if I change the
> parameter to not be a RecordsetPtr, the code links successfully.
> It seems like the combination of a virtual method and an ADO
> recordset does not work.
> What gives?

Did you introduce the MSADO namespace (or whataever name is
generated by the #import directive) in the different DLL? Try to
use fully qualified name for ADO classes (i.e., with namespace):

class __declspec(dllexport) A
{
//All kinds of stuff
virtual method( MSADO::_RecordsetPtr rs );
};

class __dclspec(dllexport) B : public A
{
//override
virtual method( MSADO::_RecordsetPtr rs );
};

Also, I assume you have a proper macro instead of the
"__dclspec(dllexport)" specifier, which expands either to
"dllexport" or "dllimport" according to the project settings.

Alex


From: Ulrich Eckhardt on 24 Apr 2008 04:30
muybluie(a)hotmail.com wrote:
> I have a DLL that exports a base class and a derived class, both
> exported. Here is an example header file snippet:
>
> class __declspec(dllexport) A
> {
> //All kinds of stuff
> virtual method( _RecordsetPtr rs );
> };
>
> class __dclspec(dllexport) B : public A
> {
> //override
> virtual method( _RecordsetPtr rs );
> };
>
> In a different DLL, I link with the the LIB for the above code, and
> attempt to use 'B'.

Well, that will fail if you include above code there, because that code
would tell the compiler that you want to export both A and B from that
other DLL. You need to switch to __declspec(dllimport) for code that
actually should import stuff from a DLL.

One further note: anything beginning with an underscore followed by an
uppercase letter is reserved. Do not use such names for your own code, be
extremely careful if such names used by others are official or just an
implementation detail.

Uli

--
C++ FAQ: http://parashift.com/c++-faq-lite

Sator Laser GmbH
Geschäftsführer: Michael Wöhrmann, Amtsgericht Hamburg HR B62 932
From: Giovanni Dicanio on 24 Apr 2008 06:07

"Ulrich Eckhardt" <eckhardt(a)satorlaser.com> ha scritto nel messaggio
news:e2t5e5-lcp.ln1(a)satorlaser.homedns.org...


>> class __declspec(dllexport) A
>> {
>> //All kinds of stuff
>> virtual method( _RecordsetPtr rs );
>> };

> Well, that will fail if you include above code there, because that code
> would tell the compiler that you want to export both A and B from that
> other DLL. You need to switch to __declspec(dllimport) for code that
> actually should import stuff from a DLL.

I thought that the OP's code was just a sample code, not the real code.

In fact, he wrote:

<quote>
The weird thing is that if I change the method
to not be virtual, or if I change the parameter to not be a
RecordsetPtr, the code links successfully.
</quote>

so my understanding was that the OP had correctly implemented the
__declspec(dllexport/import) mechanism, e.g. using the classical
preprocessor conditional stuff:

// In MyDll.h

#ifndef MYDLL
#define MYDLL __declspec(dllimport)
#endif

class MYDLL A
{
....
};

and:

// In MyDll.cpp
#define MYDLL __declspec(dllexport)
#include "MyDll.h"

....

Giovanni


From: muybluie on 24 Apr 2008 09:45
On Apr 24, 6:07 am, "Giovanni Dicanio" <giovanni.dica...(a)invalid.com>
wrote:
> "Ulrich Eckhardt" <eckha...(a)satorlaser.com> ha scritto nel messaggionews:e2t5e5-lcp.ln1(a)satorlaser.homedns.org...
>
> >> class __declspec(dllexport) A
> >> {
> >>     //All kinds of stuff
> >>     virtual method( _RecordsetPtr rs );
> >> };
> > Well, that will fail if you include above code there, because that code
> > would tell the compiler that you want to export both A and B from that
> > other DLL. You need to switch to __declspec(dllimport) for code that
> > actually should import stuff from a DLL.
>
> I thought that the OP's code was just a sample code, not the real code.
>
> In fact, he wrote:
>
> <quote>
> The weird thing is that if I change the method
> to not be virtual, or if I change the parameter to not be a
> RecordsetPtr, the code links successfully.
> </quote>
>
> so my understanding was that the OP had correctly implemented the
> __declspec(dllexport/import) mechanism, e.g. using the classical
> preprocessor conditional stuff:
>
> // In MyDll.h
>
> #ifndef MYDLL
> #define MYDLL __declspec(dllimport)
> #endif
>
> class MYDLL A
> {
> ...
>
> };
>
> and:
>
> // In MyDll.cpp
> #define MYDLL __declspec(dllexport)
> #include "MyDll.h"
>
> ...
>
> Giovanni

Yes, I used the correct export/import mechanism (the code I posted was
just an example).

Namespaces! Of course! I should have thought of that :( The same
name is used within and without a namespace. Using dumpbin (thanks
for the tip!) I saw that the namespace reference was what made the
difference. Now the question is can I fix taht without overhauling
the legacy code that this is in...but that is a technical thing.

Thanks guys!
From: Giovanni Dicanio on 24 Apr 2008 14:05

<muybluie(a)hotmail.com> ha scritto nel messaggio
news:3c00c632-75a7-43c3-a2cd-5cd9d77684d2(a)d45g2000hsc.googlegroups.com...

> Using dumpbin (thanks
> for the tip!) I saw that the namespace reference was what made the
> difference.

Yes dumpbin is a quality utility and helps in several cases.

Giovanni



First  |  Prev  | 
Pages: 1 2
Prev: Loading numbered files in sequence
Next: Which inclue file to use to use the winapi. Not using stdafx or MFC.