warning C4275 with VC++ (non dll-interface class...) (again)
Hi I was wondering why boost libraries don't do something like: class positional_options_description { public: BOOST_PROGRAM_OPTIONS_DECL positional_options_description(); BOOST_PROGRAM_OPTIONS_DECL void add(const char* name, int max_count); ... }; instead of: class BOOST_PROGRAM_OPTIONS_DECL positional_options_description { public: max_count); ... }; in order to remove the irritating C4275 warning? i.e. only declspec public, protected members (and any private members invoked from inline methods). From searching the archives it looks like the usual suggestion is to disable the warning, I just wondered if the above had been considered (and if rejected, why)? Is it because this behaviour doesn't work with win32 builds of GCC if using the declspec functionality (instead of the export-all)? Thanks for any insight. Luke Elliott.
Luke Elliott wrote:
I was wondering why boost libraries don't do something like:
class positional_options_description { public: BOOST_PROGRAM_OPTIONS_DECL positional_options_description(); BOOST_PROGRAM_OPTIONS_DECL void add(const char* name, int max_count); ... };
instead of:
class BOOST_PROGRAM_OPTIONS_DECL positional_options_description { public: max_count); ... };
in order to remove the irritating C4275 warning? i.e. only declspec public, protected members (and any private members invoked from inline methods).
Well, I did what I considered to be the standard thing. I have no idea what's C4275 warning is, and why adding declspecs to each method is a good idea. Can you explain? - Volodya
Vladimir Prus wrote:
Luke Elliott wrote:
I was wondering why boost libraries don't do something like:
class positional_options_description { public: BOOST_PROGRAM_OPTIONS_DECL positional_options_description(); BOOST_PROGRAM_OPTIONS_DECL void add(const char* name, int max_count); ... };
instead of:
class BOOST_PROGRAM_OPTIONS_DECL positional_options_description { public: max_count); ... };
in order to remove the irritating C4275 warning? i.e. only declspec public, protected members (and any private members invoked from inline methods).
Well, I did what I considered to be the standard thing. I have no idea what's C4275 warning is, and why adding declspecs to each method is a good idea. Can you explain?
(BTW - I just used program_options as an example as that's what I was looking at at the time...) I don't have access to VC++ right now so this is from memory, but there are (at least) 2 cases where it raises a warning: class MY_LIB_DECL my_class : public some_base { my_class(); }; if some_base isn't a declspeced class then you get "warning non dll-interface class used as based for dll-interface class". class MY_LIB_DECL my_class { my_class(); std::string m_string; }; Which gives "m_string must have dll-interface to be used by clients of my_class". Both warnings a pretty harmless hence the usual recommendation to disable the warning, I guess. However, the warnings can be removed by exporting only members which truly need to be exported - I was just curious as to why it isn't done in boost (possibly GCC issues?). Thanks Luke.
Both warnings a pretty harmless hence the usual recommendation to disable the warning, I guess.
However, the warnings can be removed by exporting only members which truly need to be exported - I was just curious as to why it isn't done in boost (possibly GCC issues?).
I would be a bit reluctant about "pollution" of the boost header files, for the sake of a non-standard compiler feature/bug. Nigel
Nigel Stewart wrote:
Both warnings a pretty harmless hence the usual recommendation to disable the warning, I guess.
However, the warnings can be removed by exporting only members which truly need to be exported - I was just curious as to why it isn't done in boost (possibly GCC issues?).
I would be a bit reluctant about "pollution" of the boost header files, for the sake of a non-standard compiler feature/bug.
Have you seen the boost header files?! :) jon
Jonathan Wakely wrote:
Nigel Stewart wrote:
Both warnings a pretty harmless hence the usual recommendation to disable the warning, I guess.
However, the warnings can be removed by exporting only members which truly need to be exported - I was just curious as to why it isn't done in boost (possibly GCC issues?).
I would be a bit reluctant about "pollution" of the boost header files, for the sake of a non-standard compiler feature/bug.
Have you seen the boost header files?! :)
jon
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
There are some other benefits: smaller binaries, the optimizer seems to do a better job...
However, the warnings can be removed by exporting only members which truly need to be exported
I would be a bit reluctant about "pollution"
Have you seen the boost header files?! :)
There are some other benefits: smaller binaries, the optimizer seems to do a better job...
Sounds interesting, any further information available? Nigel
Nigel Stewart wrote:
However, the warnings can be removed by exporting only members which truly need to be exported
I would be a bit reluctant about "pollution"
Have you seen the boost header files?! :)
There are some other benefits: smaller binaries, the optimizer seems to do a better job...
Sounds interesting, any further information available?
Nigel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Well, here's a simple class:
Nigel Stewart wrote:
However, the warnings can be removed by exporting only members which truly need to be exported
I would be a bit reluctant about "pollution"
Have you seen the boost header files?! :)
There are some other benefits: smaller binaries, the optimizer seems to do a better job...
Sounds interesting, any further information available?
Nigel
Whoops! Try again... With: class MY_LIB_API my_class { public: void some_fn(); void some_inline_fn() { ++m_i; } int get() { return m_i; } private: int m_i; }; dumpbin /exports exports.dll Microsoft (R) COFF/PE Dumper Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file exports.dll File Type: DLL Section contains the following exports for exports.dll 00000000 characteristics 430C9B5E time date stamp Wed Aug 24 11:07:58 2005 0.00 version 1 ordinal base 4 number of functions 4 number of names ordinal hint RVA name 1 0 00001020 ??4my_class@@QAEAAV0@ABV0@@Z 2 1 00001010 ?get@my_class@@QAEHXZ 3 2 00001000 ?some_fn@my_class@@QAEXXZ 4 3 00001000 ?some_inline_fn@my_class@@QAEXXZ So the "inline" functions are actually exported from the dll. Whereas: class my_class { public: MY_LIB_API void some_fn(); void some_inline_fn() { ++m_i; } int get() { return m_i; } private: int m_i; }; dumpbin /exports exports.dll Microsoft (R) COFF/PE Dumper Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file exports.dll File Type: DLL Section contains the following exports for exports.dll 00000000 characteristics 430C9BA8 time date stamp Wed Aug 24 11:09:12 2005 0.00 version 1 ordinal base 1 number of functions 1 number of names ordinal hint RVA name 1 0 00001000 ?some_fn@my_class@@QAEXXZ You only get the explicitly exported methods. All makes sense, I suppose. As far as optimizations go, I've seen that a client of a dll may not use an inline method and may make an actual dll call if the inline method is declspeced. I just tried that with a simple example and of course couldn't demonstrate it... Luke.
Luke Elliott wrote:
(BTW - I just used program_options as an example as that's what I was looking at at the time...)
I don't have access to VC++ right now so this is from memory, but there are (at least) 2 cases where it raises a warning:
class MY_LIB_DECL my_class : public some_base { my_class(); };
if some_base isn't a declspeced class then you get "warning non dll-interface class used as based for dll-interface class".
I believe this sometime happen when inheriting boost::noncopyable, that has no method to begin with, right? Then it's indeed poor compiler diagnostic, and we probably can add declspec, but I don't yet understand when it should be dllexport and when dllimport :-/
class MY_LIB_DECL my_class { my_class();
std::string m_string; };
Does this happen with any boost library?
However, the warnings can be removed by exporting only members which truly need to be exported - I was just curious as to why it isn't done in boost (possibly GCC issues?).
Truly, have no idea if GCC allows visibility attribute on methods. - Volodya
On 8/24/05, Vladimir Prus <ghost@cs.msu.su> wrote:
Luke Elliott wrote:
(BTW - I just used program_options as an example as that's what I was looking at at the time...)
I don't have access to VC++ right now so this is from memory, but there are (at least) 2 cases where it raises a warning:
class MY_LIB_DECL my_class : public some_base { my_class(); };
if some_base isn't a declspeced class then you get "warning non dll-interface class used as based for dll-interface class".
I believe this sometime happen when inheriting boost::noncopyable, that has no method to begin with, right? Then it's indeed poor compiler diagnostic, and we probably can add declspec, but I don't yet understand when it should be dllexport and when dllimport :-/
It's dependent on the users context. The easiest solution would be to have some macro (BOOST_CLASS_LINKAGE or something?) normally declared as empty: #define BOOST_CLASS_LINKAGE class BOOST_CLASS_LINKAGE noncopyable { <definition> }; If you need to dllexport a Boost class, redefine BOOST_CLASS_LINKAGE appropriately: #undef BOOST_CLASS_LINKAGE #define BOOST_CLASS_LINKAGE __declspec(dllexport) Having said that, my normal approach is #pragma warning(disable : 4275)... <snip>
- Volodya
Stuart Dootson
participants (5)
-
Jonathan Wakely -
Luke Elliott -
Nigel Stewart -
Stuart Dootson -
Vladimir Prus