15 мая 2023 года "Исходники.РУ" отмечают своё 23-летие!
Поздравляем всех причастных и неравнодушных с этим событием!
И огромное спасибо всем, кто был и остаётся с нами все эти годы!

Главная Форум Журнал Wiki DRKB Discuz!ML Помощь проекту


Extension dll's

Lin Sebastian Kayser -- Lin.Kayser@munich.netsurf.de
Tuesday, November 12, 1996

Ash,

you cannot use types exported with AFX_EXT_CLASS in another extension =
DLL. You need to use dllexport/dllimport instead. There is an article =
about it in your online documentation.
=20
Regards,
Lin




Erik Funkenbusch -- chucks@isd.net
Monday, November 11, 1996

MFC defines AFX_EXT_CLASS as __declspec(dllexport) if the _AFXEXT
preprocessor define is defined.  It defines it as __declspec(dllimport) if
this is not defined.  this allows you to use one header file in both the
afx application and extension dll.  problem is, if you use this in another
extension dll it _AFXEXT will be defined and you will get an export
reference rather than an import one.

What I do is define my own _MY_EXPORT symbol that i then specifically
define in my projects.  This let's me set it's meaning for either
__declspec(dllexport) or (dllimport) based on my needs.

----------
> From: Ash Williams 
> To: mfc-l@netcom.com
> Cc: ash@digitalworkshop.co.uk
> Subject: Extension dll's
> Date: Monday, November 11, 1996 2:58 AM
> 
> Environment: Win 95, VC++ 4.2b
> 
> 
> I don't know whether this is due to conflicting with MFC dll or what, 
> but I am having trouble getting my own extension dll to export its 
> static member variable.
> 
> I created a project (MFC AppWizard dll) and defined a class, using
> 
>     class AFX_EXT_CLASS MyClass etc.
>     
> In that class I put a static member amongst other things, only I can't
> seem to use that static member in another extension dll, since I get a
> link error (yes, I did remember to define the static member in the 
> .cpp). I can use all the functions fine.
> 
> I can however use the class from within another app (ie exe) without 
> any link errors on using the static member in particular.
> 
> What have I done, or what haven't I done?
> 
> Thanks, Ash



Ash Williams -- ash@digitalworkshop.co.uk
Monday, November 11, 1996

Environment: Win 95, VC++ 4.2b


I don't know whether this is due to conflicting with MFC dll or what, 
but I am having trouble getting my own extension dll to export its 
static member variable.

I created a project (MFC AppWizard dll) and defined a class, using

    class AFX_EXT_CLASS MyClass etc.
    
In that class I put a static member amongst other things, only I can't
seem to use that static member in another extension dll, since I get a
link error (yes, I did remember to define the static member in the 
.cpp). I can use all the functions fine.

I can however use the class from within another app (ie exe) without 
any link errors on using the static member in particular.

What have I done, or what haven't I done?

Thanks, Ash




John Singleton -- johns@cam-ani.co.uk
Tuesday, November 12, 1996

[Mini-digest: 4 responses]

> From: Ash Williams 
> To: mfc-l@netcom.com
> Cc: ash@digitalworkshop.co.uk
> Subject: Extension dll's
> Date: 11 November 1996 8:58
> 
> Environment: Win 95, VC++ 4.2b
> 
> 
> I don't know whether this is due to conflicting with MFC dll or what, 
> but I am having trouble getting my own extension dll to export its 
> static member variable.
> 
> I created a project (MFC AppWizard dll) and defined a class, using
> 
>     class AFX_EXT_CLASS MyClass etc.
>     
> In that class I put a static member amongst other things, only I can't
> seem to use that static member in another extension dll, since I get a
> link error (yes, I did remember to define the static member in the 
> .cpp). I can use all the functions fine.
> 
> I can however use the class from within another app (ie exe) without 
> any link errors on using the static member in particular.
> 
> What have I done, or what haven't I done?
> 
> Thanks, Ash
> 

Read Technical Note 33, especially the section about the limitations of
_AFXEXT, you need to do what it says about dllimport/dllexport.

John

John Singleton - johns@cam-ani.co.uk
Cambridge Animation Systems,
UK.

-----From: "Doug Brubacher" 

     Ash
     
     There have been a number of questions (and answers) about this subject 
     very recently on this mailing list.
     
     Your problem is with the definition of AFX_EXT_CLASS.  When compiling 
     an extension DLL it is defined "export" otherwise, such as when you 
     use it in an app, it is defined as "import".  If you are using your 
     class in another extension DLL you need to write your own macros so 
     that you can better control when it "imports" and exports.  You will 
     your classes from your first extension DLL to be imported into your 
     second extension DLL.
     
     See the sections 
     "Changing your Header Files"
     "Limitations of _AFXEXT"
     in Technical Note 33: DLL Version of MFC
     
     Regards,
     
     Doug Brubacher
     DouglasB@msn.com

-----From: Stuart Downing 

We did this by having macros similar to the AFX_EXT_CLASS macro, but =
dependent on a=20
project-local preprocessor definition which we put in the build settings =
for the project.
I.e.,
1)  in Build Settings|C/C++|General Category|Preprocessor Definitions =
for the MyDll project, add the "_MyDllImplementation_" preprocessor =
definition
2)  Create a project header as follows...

#ifndef _MyDll_h_
  #define _MyDll_h_

  //Within the implementation of the DLL, use dllexport, elsewhere, use =
dllimport
  #undef _DllInterface_
  #ifdef _MyDllImplementation_
    #define _DllInterface_ __declspec(dllexport)
  #else
    #define _DllInterface_ __declspec(dllimport)
  #endif

#endif //_MyDll_h_

3)  #include "MyDll.h" in headers with exported classes
4)  For each class to export, use "class _DllInterface_ CMyClass ..."
Within the project implementation everything is declared as dllexport.  =
When used by any other project,=20
(which should NOT have _MyDllImplementation_ defined) will be declared =
as dllimport.

-----From: Ash Williams 

Thanks for your response. Yes I've found some info on it and I'm having 
to write for instance:

#ifdef exposeMathSpace
	#define theMode _declspec( dllimport )
#else
	#define theMode _declspec( dllexport )
#endif

(I write one dll per namespace)

somewhere in the dll I'm writing, and then in any client dll, make sure 
I hash-define 'exposeMathSpace' in the preprocessor definitions.

All's well that ends well!

Ash




Lin Sebastian Kayser -- Lin.Kayser@munich.netsurf.de
Wednesday, November 13, 1996

Ash,

I would do it the other way round. #define a symbol when building the =
DLL and default to dllimport if it is not #defined. So your clients can =
just use your headers without needing any additional information about =
which dll-header need which #define. This is also the way MFC does it.

I think the existence of the AFX_EXT_CLASS has caused more questions =
than it did solve. If everybody would use their own macros we would =
probably be better off.

Best regards,
Lin

 .....................................................
.            Lin.Kayser@Munich.Netsurf.de             .
. http://ourworld.compuserve.com/homepages/Lin_Kayser .
.   writing from Munich - Date: 13.11.96 Time: 10:14  .
 .....................................................



Quote
-------------------------------------------------------------------------=
-------
Thanks for your response. Yes I've found some info on it and I'm having=20
to write for instance:

#ifdef exposeMathSpace
	#define theMode _declspec( dllimport )
#else
	#define theMode _declspec( dllexport )
#endif

(I write one dll per namespace)

somewhere in the dll I'm writing, and then in any client dll, make sure=20
I hash-define 'exposeMathSpace' in the preprocessor definitions.

All's well that ends well!

Ash
-------------------------------------------------------------------------=
--------
EndQuote





George Roberts X3706 page 0571 -- ROBERTS@RATVAX.dnet.teradyne.com
Monday, November 18, 1996


Environment: Win 95, VC++ 4.2b

>I don't know whether this is due to conflicting with MFC dll or what, 
>but I am having trouble getting my own extension dll to export its 
>static member variable.

I have had similar problems with exporting global variables.  Some times
it works, some times it doesn't.  Try creating
a map file, getting the "mangled" name, and exporting the variable in your
DEF file.  This fixed the problem for me.

- George Roberts
george.roberts@teradyne.com




| Вернуться в корень Архива |