472,791 Members | 1,065 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,791 software developers and data experts.

C4251 Compiler Warning: How Do I Remediate?

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.languages.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******@beckman.com
== Email 2: ra******@mindspring.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."
==
== "Criticizing 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."
==
================================================== ====================
================================================== ====================
Nov 16 '05 #1
5 6364
Robert,

When I ran into this is was completely harmless. I turned it off and back
on with a pragma.

#pragma warning( disable : 4251)
#include "foobar.h"
#pragma warning( default : 4251)

Cheers,
dan

"Robert A Riedel" <ra**********@beckman.com> wrote in message
news:#F*************@TK2MSFTNGP09.phx.gbl...
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.languages.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******@beckman.com
== Email 2: ra******@mindspring.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."
==
== "Criticizing 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."
==
================================================== ====================
================================================== ====================

Nov 16 '05 #2
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(dllexport), any specializations of class
templates in the class hierarchy are implicitly marked as
declspec(dllexport).

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******@beckman.com>
!From: "Robert A Riedel" <ra**********@beckman.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.public.dotnet.languages.vc,microsoft.pub lic.vc.language
!NNTP-Posting-Host: 64-162-186-125.ded.pacbell.net 64.162.186.125
!Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP09.phx.gbl
!Xref: cpmsftngxa06.phx.gbl microsoft.public.vc.language:198187
microsoft.public.dotnet.languages.vc:28638
!X-Tomcat-NG: microsoft.public.dotnet.languages.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.languages.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******@beckman.com
!== Email 2: ra******@mindspring.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."
!==
!== "Criticizing 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."
!==
!================================================= =====================
!================================================= =====================
!
!
!

Nov 16 '05 #3
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(dllimport) 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**************@cpmsftngxa06.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(dllexport), any specializations of class
templates in the class hierarchy are implicitly marked as
declspec(dllexport).

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******@beckman.com>
!From: "Robert A Riedel" <ra**********@beckman.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.public.dotnet.languages.vc,microsoft.pub lic.vc.language
!NNTP-Posting-Host: 64-162-186-125.ded.pacbell.net 64.162.186.125
!Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP09.phx.gbl
!Xref: cpmsftngxa06.phx.gbl microsoft.public.vc.language:198187
microsoft.public.dotnet.languages.vc:28638
!X-Tomcat-NG: microsoft.public.dotnet.languages.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.languages.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******@beckman.com
!== Email 2: ra******@mindspring.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."
!==
!== "Criticizing 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."
!==
!================================================= =====================
!================================================= =====================
!
!
!

Nov 16 '05 #4
Hello Robert,

Thanks for the response.

In order to know the advantages and mechanics of using _declspec(dllimport)
and _declspec(dllexport) in the application, we could refer to one MSDN
article:
"INFO: Using _declspec(dllimport) & _declspec(dllexport) 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******@beckman.com>
!From: "Robert A Riedel" <ra**********@beckman.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.public.dotnet.languages.vc
!NNTP-Posting-Host: 64-162-186-125.ded.pacbell.net 64.162.186.125
!Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP12.phx.gbl
!Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.vc:28876
!X-Tomcat-NG: microsoft.public.dotnet.languages.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(dllimport) 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**************@cpmsftngxa06.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(dllexport), any specializations of class
!> templates in the class hierarchy are implicitly marked as
!> declspec(dllexport).
!>
!> 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******@beckman.com>
!> !From: "Robert A Riedel" <ra**********@beckman.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.public.dotnet.languages.vc,microsoft.pub lic.vc.language
!> !NNTP-Posting-Host: 64-162-186-125.ded.pacbell.net 64.162.186.125
!> !Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP09.phx.gbl
!> !Xref: cpmsftngxa06.phx.gbl microsoft.public.vc.language:198187
!> microsoft.public.dotnet.languages.vc:28638
!> !X-Tomcat-NG: microsoft.public.dotnet.languages.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.languages.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******@beckman.com
!> !== Email 2: ra******@mindspring.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."
!> !==
!> !== "Criticizing 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."
!> !==
!> !================================================= =====================
!> !================================================= =====================
!> !
!> !
!> !
!>
!
!
!

Nov 16 '05 #5
Much better. Thanks for the info.

"Yan-Hong Huang[MSFT]" <yh*****@online.microsoft.com> wrote in message
news:Fo**************@cpmsftngxa06.phx.gbl...
Hello Robert,

Thanks for the response.

In order to know the advantages and mechanics of using _declspec(dllimport) and _declspec(dllexport) in the application, we could refer to one MSDN
article:
"INFO: Using _declspec(dllimport) & _declspec(dllexport) 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******@beckman.com>
!From: "Robert A Riedel" <ra**********@beckman.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.public.dotnet.languages.vc
!NNTP-Posting-Host: 64-162-186-125.ded.pacbell.net 64.162.186.125
!Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP12.phx.gbl
!Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.vc:28876
!X-Tomcat-NG: microsoft.public.dotnet.languages.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(dllimport) 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**************@cpmsftngxa06.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(dllexport), any specializations of class
!> templates in the class hierarchy are implicitly marked as
!> declspec(dllexport).
!>
!> 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******@beckman.com>
!> !From: "Robert A Riedel" <ra**********@beckman.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.public.dotnet.languages.vc,microsoft.pub lic.vc.language
!> !NNTP-Posting-Host: 64-162-186-125.ded.pacbell.net 64.162.186.125
!> !Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP09.phx.gbl
!> !Xref: cpmsftngxa06.phx.gbl microsoft.public.vc.language:198187
!> microsoft.public.dotnet.languages.vc:28638
!> !X-Tomcat-NG: microsoft.public.dotnet.languages.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.languages.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******@beckman.com
!> !== Email 2: ra******@mindspring.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."
!> !==
!> !== "Criticizing 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."
!> !==
!> !================================================= =====================
!> !================================================= =====================
!> !
!> !
!> !
!>
!
!
!

Nov 16 '05 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Nahappan SM | last post by:
I have a struct : #include <string> struct __declspec (dllexport) FILEPROPERTIES { std::wstring FileName; std::wstring Type; };
7
by: Alfonso Morra | last post by:
I cannot believe how convoluted it is to export function templates and class templates from a shared library (or DLL as it is called in the Windoze world). Micro$oft support for STL and...
2
by: Siemel Naran | last post by:
I keep getting warning messages like these: ....\include\myfile.h(451) : warning C4251: 'MyClass::m_myvariable' : class 'CPtrArray' needs to have dll-interface to be used by clients of class...
0
by: Bart Simpson | last post by:
I am writing a shared object (Dll in Windows) and I am making extensive use of the STL. I am getting lots of warnings like this: ClassA.h(139): warning C4251: 'ClassA::indexarray' : class...
6
by: Bart Simpson | last post by:
I am writing a shared object (Dll in Windows) and I am making extensive use of the STL. I am getting lots of warnings like this: ClassA.h(139): warning C4251: 'ClassA::indexarray' : class...
13
by: Anonymous | last post by:
On MS site: http://msdn2.microsoft.com/en-us/library/esew7y1w(VS.80).aspx is the following garbled rambling: "You can avoid exporting classes by defining a DLL that defines a class with...
6
by: =?Utf-8?B?RmFiaWFu?= | last post by:
Hello, I have a class hierarchy distributed over 3 native C++ dlls. The base class has a .NET Windows.Form for status output via a gcroot<>. The gcroot is declared private - the sub classes only...
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 2 August 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM) The start time is equivalent to 19:00 (7PM) in Central...
0
linyimin
by: linyimin | last post by:
Spring Startup Analyzer generates an interactive Spring application startup report that lets you understand what contributes to the application startup time and helps to optimize it. Support for...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Sept 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM) The start time is equivalent to 19:00 (7PM) in Central...
0
by: Taofi | last post by:
I try to insert a new record but the error message says the number of query names and destination fields are not the same This are my field names ID, Budgeted, Actual, Status and Differences ...
14
DJRhino1175
by: DJRhino1175 | last post by:
When I run this code I get an error, its Run-time error# 424 Object required...This is my first attempt at doing something like this. I test the entire code and it worked until I added this - If...
0
by: Rina0 | last post by:
I am looking for a Python code to find the longest common subsequence of two strings. I found this blog post that describes the length of longest common subsequence problem and provides a solution in...
5
by: DJRhino | last post by:
Private Sub CboDrawingID_BeforeUpdate(Cancel As Integer) If = 310029923 Or 310030138 Or 310030152 Or 310030346 Or 310030348 Or _ 310030356 Or 310030359 Or 310030362 Or...
0
by: lllomh | last post by:
Define the method first this.state = { buttonBackgroundColor: 'green', isBlinking: false, // A new status is added to identify whether the button is blinking or not } autoStart=()=>{
2
by: DJRhino | last post by:
Was curious if anyone else was having this same issue or not.... I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.