Fix ICC warnings about std::streambuf-derived classes dtors

[ghostvoodooman]

I hope this is not a dupe.

I have 2 warnings in program using headers from wx, and some warnings when building the whole wx library from the latest trunk.

In both projects I am using ICC 13.0.1 and STL from MSVC 2012 / 11.0 . I am compiling wxWidgets as DLL|Debug|x64 and DLL|Release|x64 and using enabled C++0x mode.

Though I guess it has nothing to do with ICC, since ICC plug-in in MSVC/devenv.exe IDE is using MSVC's STL.

my custom setup.h (only relevant settings):
wxUSE_STL defined to 0
wxUSE_STD_CONTAINERS defined to 1
wxUSE_STD_IOSTREAM defined to 1
wxUSE_STD_DEFAULT defined to 1
wxUSE_STD_STRING defined to wxUSE_STD_DEFAULT
wxUSE_STD_STRING_CONV_IN_WXSTRING defined to wxUSE_STL

SVN trunk r72949 .

my program using WX library:

c:\PATH_TO_wxWidgets\include\wx/textctrl.h(682): warning #809: exception specification for virtual function "wxTextCtrlBase::~wxTextCtrlBase" is incompatible with that of overridden function "std::basic_streambuf<_Elem, _Traits>::~basic_streambuf [with _Elem=char, _Traits=std::char_traits<char>]"
c:\PATH_TO_wxWidgets\include\wx/msw/textctrl.h(34): warning #809: exception specification for virtual function "wxTextCtrl::~wxTextCtrl" is incompatible with that of overridden function "std::basic_streambuf<_Elem, _Traits>::~basic_streambuf [with _Elem=char, _Traits=std::char_traits<char>]"

wx library itself (this is only sort'ed and uniq'ued list):

..\..\include\wx/msw/textctrl.h(34): warning #809: exception specification for virtual function "wxTextCtrl::~wxTextCtrl" is incompatible with that of overridden function "std::basic_streambuf<_Elem, _Traits>::~basic_streambuf [with _Elem=char, _Traits=std::char_traits<char>]"
..\..\include\wx/stdstream.h(115): warning #809: exception specification for virtual function "wxStdOutputStream::~wxStdOutputStream" is incompatible with that of overridden function "std::basic_ios<_Elem, _Traits>::~basic_ios [with _Elem=char, _Traits=std::char_traits<char>]"
..\..\include\wx/stdstream.h(115): warning #809: exception specification for virtual function "wxStdOutputStream::~wxStdOutputStream" is incompatible with that of overridden function "std::basic_ostream<_Elem, _Traits>::~basic_ostream [with _Elem=char, _Traits=std::char_traits<char>]"
..\..\include\wx/stdstream.h(115): warning #809: exception specification for virtual function "wxStdOutputStream::~wxStdOutputStream" is incompatible with that of overridden function "std::ios_base::~ios_base"
..\..\include\wx/stdstream.h(31): warning #809: exception specification for virtual function "wxStdInputStreamBuffer::~wxStdInputStreamBuffer" is incompatible with that of overridden function "std::basic_streambuf<_Elem, _Traits>::~basic_streambuf [with _Elem=char, _Traits=std::char_traits<char>]"
..\..\include\wx/stdstream.h(74): warning #809: exception specification for virtual function "wxStdInputStream::~wxStdInputStream" is incompatible with that of overridden function "std::basic_ios<_Elem, _Traits>::~basic_ios [with _Elem=char, _Traits=std::char_traits<char>]"
..\..\include\wx/stdstream.h(74): warning #809: exception specification for virtual function "wxStdInputStream::~wxStdInputStream" is incompatible with that of overridden function "std::basic_istream<_Elem, _Traits>::~basic_istream [with _Elem=char, _Traits=std::char_traits<char>]"
..\..\include\wx/stdstream.h(74): warning #809: exception specification for virtual function "wxStdInputStream::~wxStdInputStream" is incompatible with that of overridden function "std::ios_base::~ios_base"
..\..\include\wx/stdstream.h(88): warning #809: exception specification for virtual function "wxStdOutputStreamBuffer::~wxStdOutputStreamBuffer" is incompatible with that of overridden function "std::basic_streambuf<_Elem, _Traits>::~basic_streambuf [with _Elem=char, _Traits=std::char_traits<char>]"
..\..\include\wx/textctrl.h(682): warning #809: exception specification for virtual function "wxTextCtrlBase::~wxTextCtrlBase" is incompatible with that of overridden function "std::basic_streambuf<_Elem, _Traits>::~basic_streambuf [with _Elem=char, _Traits=std::char_traits<char>]"
..\..\src\common\combocmn.cpp(943): warning #809: exception specification for virtual function "wxComboCtrlTextCtrl::~wxComboCtrlTextCtrl" is incompatible with that of overridden function "std::basic_streambuf<_Elem, _Traits>::~basic_streambuf [with _Elem=char, _Traits=std::char_traits<char>]"
..\..\src\generic\spinctlg.cpp(80): warning #809: exception specification for virtual function "wxSpinCtrlTextGeneric::~wxSpinCtrlTextGeneric" is incompatible with that of overridden function "std::basic_streambuf<_Elem, _Traits>::~basic_streambuf [with _Elem=char, _Traits=std::char_traits<char>]"

My best guess is that these WX classes are derived from STL classes (e.g. streams) which might throw an exception in their virtual destructor.

Attaching patch fixing those warnings against r72949 , but I'm not sure about it, it might cause performance penalty (due to exceptions) in build without using STD/STL by custom setup.h . I guess there should be preprocessor guards/disablers around "throw()" in my patch for such case?

[ghostvoodooman]

Patch to eliminate warnings #809

[vadz]

throw() is deprecated in C++11, it doesn't seem like a good idea to start adding it now. And, of course, C++11 noexcept is not widely supported yet. So we probably need to define wxNOEXCEPT macro or something like this and use it instead.

This being said, the warnings are perfectly harmless because you're never going to delete a wxTextCtrl via streambuf pointer anyhow so it's hardly high priority.

[ghostvoodooman]

Hello Vadim,

Do you like this new patch?

Or did you except wxNOEXCEPT not to be a "decorator", but rather wxNOEXCEPT( declaration of funcion ) ?

Attaching a path for both C++0x and C++11.

[ghostvoodooman]

PS: and I am very sorry for my English spelling, I wrote it after I just woke up, and I am not native speaker... But I hope everyone is able to understand...

[ghostvoodooman]

After searching some internets, I have found that C++0x compilers require throw() but all compilers are able to understand noexcept not regarding version of C++. Should we change this decoration by preprocessor for some compiler that do not understands noexcept? Are there any?

There is my third version of patch, which compiles fine under MSVC2012 + ICC 13.0.1 .

[ghostvoodooman]

3rd version of patch

[vadz]

Replying to ghostvoodooman:

After searching some internets, I have found that C++0x compilers require throw() but all compilers are able to understand noexcept not regarding version of C++.

This can't be right. noexcept is new in C++11, old compilers definitely don't support it.

[ghostvoodooman]

I was thinking about this, the base class's destructor could throw an exception (in a rare situation), I think whether we should honour this fact by using throw(...) or, for higher versions of C++ "may-throw" noexcept(false) . If so, then macro should have a different name. What do you think?

[ghostvoodooman]

Replying to ghostvoodooman:

I was thinking about this, the base class's destructor could throw an exception (in a rare situation), I think whether we should honour this fact by using throw(...) or, for higher versions of C++ "may-throw" noexcept(false) . If so, then macro should have a different name. What do you think?

Please disregard my previous post, I have just found throw(...) produces the same warning.

Attaching my 4th version of patch ( warning_809_patch4.patch ).

[ghostvoodooman]

4th version of patch

[vadz]

I'm confused about the comments in your macro definitions (clearly 199711 corresponds to C++98, not C++0x...) but the patch itself is probably still correct so I'll commit it soon, thanks.

[VZ]

(In [72978]) Add wxNOEXCEPT and use it for std::streambuf-derived classes.

This fixes warnings from Intel compiler about overriding function using a
different exception specification than the base one and also incidentally
provides a handy macro that can be useful in other situations.

Closes #14826.

[VZ]

(In [72984]) Add wxNOEXCEPT to all wxTextCtrl dtors.

Fix compilation with some compilers after r72978 which added wxNOEXCEPT to
wxTextCtrlBase dtor and wxTextCtrl dtor in wxMSW but not in all the other
ports.

See #14826.

[ghostvoodooman]

Replying to VZ:

(In [72984]) Add wxNOEXCEPT to all wxTextCtrl dtors.

Fix compilation with some compilers after r72978 which added wxNOEXCEPT to
wxTextCtrlBase dtor and wxTextCtrl dtor in wxMSW but not in all the other
ports.

See #14826.

I was not sure what to do about compilation error on wxGTK port reported in wx-dev list. This (above) was one approach. There is still problem if one (an user) derives a new class from wxTextCtrl[Base], since exception specification will get propagated to sub class's dtor (e.g. to implement custom auto-completition). So the user will be surprised about compile error, like that one in the list.

Another approach (but rather ugly) would be to use the preprocessor to enable/disable USAGE of wxNOEXCEPT in all (so far) dtors we use it now, and (future) places as well. Like:

~foo()
#ifdef wxMSW
    wxNOEXCEPT
#endif
{ }

[VZ]

(In [72989]) More compilation fixes after wxNOEXCEPT introduction.

This is a temporary change, r72984 and the following changes (see #14826) will
probably be reverted soon anyhow, but for now at least fix wxGTK compilation.

Closes #14837.

[vadz]

Replying to ghostvoodooman:

Another approach (but rather ugly) would be to use the preprocessor to enable/disable USAGE of wxNOEXCEPT in all (so far) dtors we use it now, and (future) places as well. Like:
{{{
~foo()
#ifdef wxMSW
wxNOEXCEPT
#endif
{ }
}}}

I don't understand at all what does this solve, whether test for __WXMSW__ or __INTELC__. You'd still need to use throw() for your own dtors.

IOW I don't see any solution preserving backwards compatibility at all actually, not even a bad one.

I'll think about it a bit more but if I don't find anything new I'll revert all these commits tomorrow.

[ghostvoodooman]

As per our conversation in wx-dev list, I am attaching warning_809_patch5.patch patch against r72991 , which disables ICC 13.0.1 warnings in C++0x mode about inconsistency of exception specification of our virtual dtors when we are deriving classes from MSVC 2012's STL's ones.

Also, remove our macro wxNOEXCEPT from these dtors (fixing compile errors with GCC).

[ghostvoodooman]

patch 5 to fix compile errors with GCC, and eliminate warnings with ICC compiler

[VZ]

(In [72992]) Fix another compilation problem after wxNOEXCEPT introduction.

Also add wxNOEXCEPT to wxTextCtrl dtor definition in wxMSW.

See #14826.

[vadz]

I hoped it would be enough to use the pragmas in the header... If we really need them in all source files deriving classes from wxTextCtrl, it's a bad solution IMO and I'm pretty sure that nobody will add this stuff around the next wxTextCtrl-derived class we add.

So for now I'll just revert all changes and I think the best way to fix this would be to disable this warning globally for ICC in wx/defs.h.

[ghostvoodooman]

Replying to vadz:

I hoped it would be enough to use the pragmas in the header... If we really need them in all source files deriving classes from wxTextCtrl, it's a bad solution IMO and I'm pretty sure that nobody will add this stuff around the next wxTextCtrl-derived class we add.

That would mean user will not get this warning in their own code, if they don't explicitly re-enable this warning after inclusion of all WX headers.

[VZ]

(In [72993]) Revert all wxNOEXCEPT-related changes.

This reverts r72978, 72984, 72989 and 72992. Do not use wxNOEXCEPT for
wxTextCtrl dtor as this breaks compilation of any user-defined classes
inheriting from it unless they use wxNOEXCEPT as well and the benefits
(fixing a harmless warning for the niche ICC compiler) are just not worth
the compatibility breakage.

See #14826.