C4251 Compiler Warning: How Do I Remediate?

  • Thread starter Thread starter Robert A Riedel
  • Start date Start date
R

Robert A Riedel

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: (e-mail address removed)
== Email 2: (e-mail address removed)
==
==
== 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."
==
======================================================================
======================================================================
 
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
 
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" <[email protected]>
!From: "Robert A Riedel" <[email protected]>
!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: <#[email protected]>
!Newsgroups:
microsoft.public.dotnet.languages.vc,microsoft.public.vc.language
!NNTP-Posting-Host: 64-162-186-125.ded.pacbell.net 64.162.186.125
!Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09.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: (e-mail address removed)
!== Email 2: (e-mail address removed)
!==
!==
!== 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."
!==
!======================================================================
!======================================================================
!
!
!
 
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.
 
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.aspx?scid=kb;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" <[email protected]>
!From: "Robert A Riedel" <[email protected]>
!References: <#[email protected]>
<[email protected]>
!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: <#[email protected]>
!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!TK2MSFTNGP12.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.
!
!!> 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" <[email protected]>
!> !From: "Robert A Riedel" <[email protected]>
!> !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: <#[email protected]>
!> !Newsgroups:
!> microsoft.public.dotnet.languages.vc,microsoft.public.vc.language
!> !NNTP-Posting-Host: 64-162-186-125.ded.pacbell.net 64.162.186.125
!> !Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09.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: (e-mail address removed)
!> !== Email 2: (e-mail address removed)
!> !==
!> !==
!> !== 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."
!> !==
!> !======================================================================
!> !======================================================================
!> !
!> !
!> !
!>
!
!
!
 
Much better. Thanks for the info.

Yan-Hong Huang said:
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.aspx?scid=kb;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" <[email protected]>
!From: "Robert A Riedel" <[email protected]>
!References: <#[email protected]>
<[email protected]>
!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: <#[email protected]>
!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!TK2MSFTNGP12.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.
!
!!> 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" <[email protected]>
!> !From: "Robert A Riedel" <[email protected]>
!> !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: <#[email protected]>
!> !Newsgroups:
!> microsoft.public.dotnet.languages.vc,microsoft.public.vc.language
!> !NNTP-Posting-Host: 64-162-186-125.ded.pacbell.net 64.162.186.125
!> !Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09.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: (e-mail address removed)
!> !== Email 2: (e-mail address removed)
!> !==
!> !==
!> !== 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."
!> !==
!> !======================================================================
!> !======================================================================
!> !
!> !
!> !
!>
!
!
!
Click to expand...
 
Back
Top