Hello Robert,
Thanks for the response.
In order to know the advantages and mechanics of using _declspec(dllim port)
and _declspec(dllex port) in the application, we could refer to one MSDN
article:
"INFO: Using _declspec(dllim port) & _declspec(dllex port) in Code"
http://support.microsoft.com/default...b;en-us;132044
Hope that helps.
Best regards,
Yanhong Huang
Microsoft Online Partner Support
Get Secure! -
www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
!Reply-To: "Robert A Riedel" <ra******@beckm an.com>
!From: "Robert A Riedel" <ra**********@b eckman.com>
!References: <#F************ *@TK2MSFTNGP09. phx.gbl>
<0s************ **@cpmsftngxa06 .phx.gbl>
!Subject: Re: C4251 Compiler Warning: How Do I Remediate?
!Date: Mon, 29 Sep 2003 16:05:21 -0700
!Lines: 167
!Organization: Beckman Coulter
!X-Priority: 3
!X-MSMail-Priority: Normal
!X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
!X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
!Message-ID: <#6************ *@TK2MSFTNGP12. phx.gbl>
!Newsgroups: microsoft.publi c.dotnet.langua ges.vc
!NNTP-Posting-Host: 64-162-186-125.ded.pacbell .net 64.162.186.125
!Path: cpmsftngxa06.ph x.gbl!TK2MSFTNG P08.phx.gbl!TK2 MSFTNGP12.phx.g bl
!Xref: cpmsftngxa06.ph x.gbl microsoft.publi c.dotnet.langua ges.vc:28876
!X-Tomcat-NG: microsoft.publi c.dotnet.langua ges.vc
!
!Your reply contains only a partial explanation.
!
!The use of dllexport is described with reasonable clarity in the Microsoft
!writings, however, dllimport is not, nor have you really addressed its use
!in your reply. What is really problematic is that I cannot find a
reasonalbe
!explanation of its use anywhere. For example, the VC.NET 2003 help file
!states the following:
!
!"As a reference, search through the Win32 WINBASE.H header file. It
contains
!examples of __declspec(dlli mport) usage"
!
!However, WINBASE.H contains no such examples.
!
!An explanation of dllimport and examples would be appreciated.
!
!Thanks.
!
!"Yan-Hong Huang[MSFT]" <yh*****@online .microsoft.com> wrote in message
!news:0s******* *******@cpmsftn gxa06.phx.gbl.. .
!> Hello Robert,
!>
!> Thanks for your email.
!>
!> From MSDN, we could see that:
!>
!> The dllexport and dllimport storage-class attributes are
!Microsoft-specific
!> extensions to the C and C++ languages. They enable you to export and
!import
!> functions, data, and objects to and from a DLL.
!>
!> These attributes explicitly define the DLL's interface to its client,
!which
!> can be the executable file or another DLL. Declaring functions as
!dllexport
!> eliminates the need for a module-definition (.DEF) file, at least with
!> respect to the specification of exported functions. Note that dllexport
!> replaces the __export keyword.
!>
!> If a class is marked declspec(dllexp ort), any specializations of class
!> templates in the class hierarchy are implicitly marked as
!> declspec(dllexp ort).
!>
!> The declaration of dllexport and dllimport must use extended attribute
!> syntax and the __declspec keyword.
!>
!> Based on my experience, dllexport is there to avoid def files. When you
!> dllexport a __stdcall function it is exported alongwith the name
!> decoration. Thats the @ stuff after your function name.
!>
!> For functions that you export via dllexport and import via dllimport and
!if
!> both use the same compiler you shouldn't have problems with the
!decoration.
!> With a def, the export happens with the name you provided in the def
which
!> happens to be without name adornation. You could check the difference by
!> using Depency tool in Visual Studio 6.0 -> Tools.
!>
!> Does that answer your question?
!>
!> Best regards,
!> Yanhong Huang
!> Microsoft Online Partner Support
!>
!> Get Secure! -
www.microsoft.com/security
!> This posting is provided "AS IS" with no warranties, and confers no
!rights.
!>
!> --------------------
!> !Reply-To: "Robert A Riedel" <ra******@beckm an.com>
!> !From: "Robert A Riedel" <ra**********@b eckman.com>
!> !Subject: C4251 Compiler Warning: How Do I Remediate?
!> !Date: Tue, 23 Sep 2003 15:37:22 -0700
!> !Lines: 73
!> !Organization: Beckman Coulter
!> !X-Priority: 3
!> !X-MSMail-Priority: Normal
!> !X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
!> !X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
!> !Message-ID: <#F************ *@TK2MSFTNGP09. phx.gbl>
!> !Newsgroups:
!> microsoft.publi c.dotnet.langua ges.vc,microsof t.public.vc.lan guage
!> !NNTP-Posting-Host: 64-162-186-125.ded.pacbell .net 64.162.186.125
!> !Path: cpmsftngxa06.ph x.gbl!TK2MSFTNG P08.phx.gbl!TK2 MSFTNGP09.phx.g bl
!> !Xref: cpmsftngxa06.ph x.gbl microsoft.publi c.vc.language:1 98187
!> microsoft.publi c.dotnet.langua ges.vc:28638
!> !X-Tomcat-NG: microsoft.publi c.dotnet.langua ges.vc
!> !
!> !I have a class that is intended to be exported in a DLL that uses
another
!> !class that is in a static library. All clients that use the DLL will
also
!> !link with the same static library. In summary, the following condition
!> !exists:
!> !
!> !class A {} ; // Instantiated in the static library and specified
!> ! // in a header included by all clients.
!> !
!> !//
!> !// This is the class using A that is exported by a DLL.
!> !//
!> !class __declspec( dllexport ) B
!> !{
!> ! public :
!> ! B( const A & ) ;
!> !
!> ! const A &
!> ! value( void ) const ;
!> !
!> ! private :
!> ! A _a ;
!> !} ;
!> !
!> !Of course, the implementation of class B is not shown, and class A
!> !has other members, so the entire example is greatly simplified, however,
!> !compilation of code similar to this always results in a C4251 warning
!> !being issued on any line where a type of class A is referenced by a
class
!> !using the dllexport attribute.
!> !
!> !The question to be posed is how does one eliminate the C4251 warning
!> without
!> !re-declaring class A using the dllexport directive. The intent is not to
!> !export
!> !this class in any DLL since it is to be resolved at link-time, not
!> !run-time -- that
!> !is: all clients using class A must use the appropriate header and link
!with
!> !the
!> !static library.
!> !
!> !NOTE: This message was posted to both the dotnet.language s.vc and
!> !vc.language newsgroups.
!> !
!> !--
!> !============== =============== =============== =============== ===========
!> !============== =============== =============== =============== ===========
!> !==
!> !== Bob Riedel
!> !== Beckman Coulter, Incorporated
!> !== PO Box 8000 W-529
!> !== 200 S Kraemer Blvd
!> !== Brea CA 92822-8000
!> !==
!> !== Email 1:
ra******@beckma n.com
!> !== Email 2:
ra******@mindsp ring.com
!> !==
!> !==
!> !== The opinions expressed are my own, and do not necessarily represent
!> !== those of Beckman Coulter, Inc.
!> !==
!> !============== =============== =============== =============== ===========
!> !============== =============== =============== =============== ===========
!> !==
!> !== "Effective education is the key to successful democracy."
!> !==
!> !== "Criticizin g the actions of others offers so little risk, and
!> !== requires so little effort that it is, without exception, the tool
!> !== of the lazy and of the foolish -- who have neither the intelligence
!> !== to discover, nor the discipline to pursue, a realistic
!> !== alternative."
!> !==
!> !============== =============== =============== =============== ===========
!> !============== =============== =============== =============== ===========
!> !
!> !
!> !
!>
!
!
!
