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

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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.
 
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:
 
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"?
 
Back
Top