468,554 Members | 1,062 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,554 developers. It's quick & easy.

how to get rid off -- warning C4251: needs to have dll-interface

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 'MyClass'
D:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\atlmfc\include\af
xcoll.h(367) : see declaration of 'CPtrArray'

How can I get rid of the warnings.

I put the following

#pragma warning(disable: 4251)

at the top of the cpp file I am compiling, as well as the top of stdafx.h,
but it does not work.

Thanks.
Jan 17 '06 #1
2 29890
did you recompile StdAfx.h when you added #pragma warning(disable: 4251) ?
the precompiled header will not be recreated automatically.

also, why don't you use __declspec(dllexport) to get rid of the warning?

another approach would be to do something like this in your header file:

#pragma warning(push)
#pragma warning(disable:4251)
//your declarations that cause 4251
#pragma warning(pop)

kind regards,
Bruno.

"Siemel Naran" schreef:
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 'MyClass'
D:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\atlmfc\include\af
xcoll.h(367) : see declaration of 'CPtrArray'

How can I get rid of the warnings.

I put the following

#pragma warning(disable: 4251)

at the top of the cpp file I am compiling, as well as the top of stdafx.h,
but it does not work.

Thanks.

Jan 18 '06 #2
Localizing the pragma to the header file causing it is preferred and is what
we do. Also, because we build on multiple compilers and platforms,

#if defined (_MSC_VER)
# pragma nonesense
#endif

The push and pop are very good tips because it contains the explosion only
to the code affected regardless of who uses it.

It's a very annoying warning to have on by default because it assumes
anything the exported class will use is also exported. If your class
restricts access to these members being warned about internally, there's no
problem.

The suggestion of __declspec(dllexport)'ing the affected member of the
exported class isn't always viable or necessary. For example, I routinely
export classes in dll's using stl containers which makes it impossible to
supress the warning without a #pragma or command line switch. I don't expect
or allow the client to directly twink the member variable or any references
to it so there's no problem.

For the warning to make more sense, it should be smart about only activating
in unsafe cases, like:

exported class is inherited from non-exported class
public member variable
public function returning or taking non-exported class type
public function using throw () decl with non-exported class type
...etc

Or even better moving the warning to the linker where it can determine with
certainty if there really is a problem.

While we're having all this __declspec() crap thrown upon us, why not add
another one which explicity marks the symbol "not-for-export"?
"Bruno van Dooren" wrote:
did you recompile StdAfx.h when you added #pragma warning(disable: 4251) ?
the precompiled header will not be recreated automatically.

also, why don't you use __declspec(dllexport) to get rid of the warning?

another approach would be to do something like this in your header file:

#pragma warning(push)
#pragma warning(disable:4251)
//your declarations that cause 4251
#pragma warning(pop)

kind regards,
Bruno.


Jan 21 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Bolin | last post: by
1 post views Thread by Peter Steele | last post: by
6 posts views Thread by =?Utf-8?B?RmFiaWFu?= | last post: by
4 posts views Thread by mdubey82 | last post: by
3 posts views Thread by Martin Schneider | last post: by
1 post views Thread by kurtzky | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.