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

[Paul Cornett]

In file included from ../include/wx/textctrl.h:788:0,
from ../src/common/event.cpp:44:
../include/wx/gtk/textctrl.h:33:13: error: looser throw specifier for
‘virtual wxTextCtrl::~wxTextCtrl()’
In file included
from ../src/common/event.cpp:44:0: ../include/wx/textctrl.h:682:13:
error: overriding ‘virtual wxTextCtrlBase::~wxTextCtrlBase() throw ()’

[Vadim Zeitlin]

On Sat, 17 Nov 2012 20:58:11 -0800 Paul Cornett wrote:

PC> In file included from ../include/wx/textctrl.h:788:0,
PC> from ../src/common/event.cpp:44:
PC> ../include/wx/gtk/textctrl.h:33:13: error: looser throw specifier for
PC> ‘virtual wxTextCtrl::~wxTextCtrl()’
PC> In file included
PC> from ../src/common/event.cpp:44:0: ../include/wx/textctrl.h:682:13:
PC> error: overriding ‘virtual wxTextCtrlBase::~wxTextCtrlBase() throw ()’

Should be fixed in r72984, thanks (somehow I didn't see this with my g++
4.4.5, I wonder why).

VZ

[Marian 'VooDooMan' Meravy]

On 2012-11-19 12:54, Vadim Zeitlin wrote:
> On Sat, 17 Nov 2012 20:58:11 -0800 Paul Cornett wrote:
>

[...]

> PC> error: overriding ‘virtual wxTextCtrlBase::~wxTextCtrlBase() throw ()’
>
> Should be fixed in r72984, thanks (somehow I didn't see this with my g++
> 4.4.5, I wonder why).

Just my best guess: You have not enabled C++0x compilation standard.

I'm guessing this, since these warnings (the patch is resolving)
appeared in MSVC+ICC *after* I switched ICC to C++0x mode. Maybe GCC
behaves similarly.

best,
vdm
.

>
> VZ
>

[Vadim Zeitlin]

On Mon, 19 Nov 2012 13:38:57 +0100 Marian 'VooDooMan' Meravy wrote:

MVM> Just my best guess: You have not enabled C++0x compilation standard.

I didn't, but throw() doesn't require C++11 and Paul's error messages were
about mismatch in throw specifications and didn't mention noexcept, so they
were from a C++98 compiler too.

Regards,
VZ

[Marian 'VooDooMan' Meravy]

On 2012-11-19 13:41, Vadim Zeitlin wrote:
> I didn't, but throw() doesn't require C++11 and Paul's error messages were
> about mismatch in throw specifications and didn't mention noexcept, so they
> were from a C++98 compiler too.

but IIRC rules for exception specification were made more restrictive in
C++0x. I was not speaking about C++11 (and noexcept), just C++0x (since
even ICC doesn't support C++11 yet AFAIK, so I am not able to test the
code under C++11, only in C++0x mode).

And Paul's error was:

../include/wx/gtk/textctrl.h:33:13: error: looser throw specifier for

‘virtual wxTextCtrl::~wxTextCtrl()’

so I guessed, but I might be wrong, he compiled with C++0x std with GCC,
which does not allow "degrade" exception specification/throw specifier
(hence the word "looser throw specifier" from GCC). Too bad, I don't
have GCC at the hand ATM.

Am I missing something, or I should take a rest, since I must admit, I
am overworked ATM... My apologies if I do miss something important.

best,
vdm
.

>
> Regards,
> VZ
>

[Vadim Zeitlin]

On Mon, 19 Nov 2012 14:00:31 +0100 Marian 'VooDooMan' Meravy wrote:

MVM> but IIRC rules for exception specification were made more restrictive in
MVM> C++0x.

To the best of my knowledge this is not the case.

MVM> I was not speaking about C++11 (and noexcept), just C++0x

C++0x and C++11 are exactly the same thing, it doesn't make sense to
distinguish between them.

MVM> And Paul's error was:
MVM>
MVM> ../include/wx/gtk/textctrl.h:33:13: error: looser throw specifier for
MVM> ‘virtual wxTextCtrl::~wxTextCtrl()’
MVM>
MVM> so I guessed, but I might be wrong, he compiled with C++0x std with GCC,
MVM> which does not allow "degrade" exception specification/throw specifier
MVM> (hence the word "looser throw specifier" from GCC). Too bad, I don't
MVM> have GCC at the hand ATM.
MVM>
MVM> Am I missing something, or I should take a rest, since I must admit, I
MVM> am overworked ATM... My apologies if I do miss something important.

throw() is C++98 and its behaviour didn't change in C++11. In fact, it was
deprecated in C++11.

Regards,
VZ

[Marian 'VooDooMan' Meravy]

OIC. Thank you for clarification. I should read more about these
"old-new" standards (C++ std > 98).

thank you,
vdm
.

[Paul Cornett]

Vadim Zeitlin wrote:
> On Sat, 17 Nov 2012 20:58:11 -0800 Paul Cornett wrote:
>
> PC> In file included from ../include/wx/textctrl.h:788:0,
> PC> from ../src/common/event.cpp:44:
> PC> ../include/wx/gtk/textctrl.h:33:13: error: looser throw specifier

> PC> for ‘virtual wxTextCtrl::~wxTextCtrl()’

> PC> In file included
> PC> from ../src/common/event.cpp:44:0: ../include/wx/textctrl.h:682:13:
> PC> error: overriding ‘virtual wxTextCtrlBase::~wxTextCtrlBase()

> PC> throw ()’

>
> Should be fixed in r72984, thanks (somehow I didn't see this with my
> g++ 4.4.5, I wonder why).

Won't compilation of user code deriving from wxTextCtrl be broken by
this also? Do we really want to do this? I'm using GCC 4.7.2 BTW.

[Paul Cornett]

Vadim Zeitlin wrote:
> Should be fixed in r72984, thanks (somehow I didn't see this with my
> g++ 4.4.5, I wonder why).

Still broken:

../src/gtk/textctrl.cpp:613:25: error: declaration of ‘virtual
wxTextCtrl::~wxTextCtrl()’ has a different exception specifier

In file included from ../include/wx/textctrl.h:788:0,

from ../src/gtk/textctrl.cpp:15: ../include/wx/gtk/textctrl.h:33:13:
error: from previous declaration ‘virtual wxTextCtrl::~wxTextCtrl()
throw ()’

[Vadim Zeitlin]

On Mon, 19 Nov 2012 08:45:33 -0800 Paul Cornett wrote:

PC> Vadim Zeitlin wrote:

PC> > On Sat, 17 Nov 2012 20:58:11 -0800 Paul Cornett wrote:
PC> >

PC> > PC> In file included from ../include/wx/textctrl.h:788:0,
PC> > PC> from ../src/common/event.cpp:44:
PC> > PC> ../include/wx/gtk/textctrl.h:33:13: error: looser throw specifier
PC> > PC> for ‘virtual wxTextCtrl::~wxTextCtrl()’
PC> > PC> In file included
PC> > PC> from ../src/common/event.cpp:44:0: ../include/wx/textctrl.h:682:13:
PC> > PC> error: overriding ‘virtual wxTextCtrlBase::~wxTextCtrlBase()
PC> > PC> throw ()’
PC> >
PC> > Should be fixed in r72984, thanks (somehow I didn't see this with my
PC> > g++ 4.4.5, I wonder why).
PC>
PC> Won't compilation of user code deriving from wxTextCtrl be broken by
PC> this also? Do we really want to do this? I'm using GCC 4.7.2 BTW.

Yes, I've just realized this too, see http://trac.wxwidgets.org/ticket/14837
Unless I'm missing some way to make this work in a backwards compatible
way, I'll indeed revert the changes of #14826.

Right now the only solution I see is a pretty hackish one: define
wxNOEXCEPT (which would need to be renamed, too, as it wouldn't be
generally useful then) as throw() for ICC and nothing for the other
compilers. It's probably not worth it...

Regards,
VZ

[Marian 'VooDooMan' Meravy]

I pointed this out in comment #11:
http://trac.wxwidgets.org/ticket/14826#comment:11

IMO the second approach [above link], but ugly, would bring the least
pain, but until we find a good solution, it should be enough, though it
would be a temporary solution.

PS: "#ifdef wxMSW" is for ALL windows like for mingw and cygwin as well?
Because as they use GCC and not ICC it might produce the same
problems... If this is the case I would suggest to use "#ifdef
__INTEL_COMPILER" or even (since ICC under windows is actually STL from
MSVC + MSVC plugin) "#if defined(_MSC_VER) && defined(__INTEL_COMPILER)"
('_MSC_VER' could be replaced by any VC-specific intrinsic/implicit
define's).

[Vadim Zeitlin]

On Mon, 19 Nov 2012 18:37:39 +0100 Marian 'VooDooMan' Meravy wrote:

MVM> I pointed this out in comment #11:
MVM> http://trac.wxwidgets.org/ticket/14826#comment:11
MVM>
MVM> IMO the second approach [above link], but ugly, would bring the least
MVM> pain, but until we find a good solution, it should be enough, though it
MVM> would be a temporary solution.

It won't be temporary because I don't see what it would be replaced with.

MVM> PS: "#ifdef wxMSW" is for ALL windows like for mingw and cygwin as well?

Yes.

MVM> Because as they use GCC and not ICC it might produce the same
MVM> problems... If this is the case I would suggest to use "#ifdef
MVM> __INTEL_COMPILER" or even (since ICC under windows is actually STL from
MVM> MSVC + MSVC plugin) "#if defined(_MSC_VER) && defined(__INTEL_COMPILER)"
MVM> ('_MSC_VER' could be replaced by any VC-specific intrinsic/implicit
MVM> define's).

We use __INTELC__ for this. But I still don't like it, it would mean
littering the code with icc-specific macros which are useless for other
compilers. I prefer just to disable the warning for ICC, if it has pragmas
to do it just around wx/textctrl.h contents we could do this, otherwise it
could be disabled globally.

Regards,
VZ

[Marian 'VooDooMan' Meravy]

On 2012-11-19 18:48, Vadim Zeitlin wrote:
[...]

> We use __INTELC__ for this. But I still don't like it, it would mean
> littering the code with icc-specific macros which are useless for other
> compilers. I prefer just to disable the warning for ICC, if it has pragmas
> to do it just around wx/textctrl.h contents we could do this, otherwise it
> could be disabled globally.

Yes, I'm against to temporary solutions and these ugly non-readable code
as well...

I can make a patch like:

--- snip ---
#if defined(__INTELC__)
# pragma warning( push )
# pragma warning( disable : 809 )
#endif
class {
...
};
#if defined(__INTELC__)
# pragma warning( pop )
#endif
--- snip ---

but I'm not sure whether ICC under non-MSVC is able to understand
MS-specific:
# pragma warning( push )
and it's "pop" counter-part (I did some google but w/o any relevant
results; if you are more clever at choosing right keywords, get back to
me...). If not (push/pop), we can omit these pragmas, and disable 809's
fully in "prologue" code (i.e. defs.h or and-alike). This would mean
user will not get this warning at all, if we not re-enable it in some
"epilogue" code. Other solution would be only disable them in particular
.cpp files, which I feel would be the best solution, though, some
virtual dtors are inlined/empty inlined. In this case, I could move them
into .cpp's in my patch (but as they are empty and virtual, the compiler
will supply generated virtual dtor by itself).

What you feel is the best for me to do a right patch?

Any thoughts are welcome.

[Vadim Zeitlin]

On Mon, 19 Nov 2012 19:07:52 +0100 Marian 'VooDooMan' Meravy wrote:

MVM> Yes, I'm against to temporary solutions and these ugly non-readable code
MVM> as well...

Actually I take my words back, it's not only ugly, it doesn't work too, so
it's not even a solution.

MVM> I can make a patch like:
MVM>
MVM> --- snip ---
MVM> #if defined(__INTELC__)
MVM> # pragma warning( push )
MVM> # pragma warning( disable : 809 )
MVM> #endif
MVM> class {
MVM> ...
MVM> };
MVM> #if defined(__INTELC__)
MVM> # pragma warning( pop )
MVM> #endif
MVM> --- snip ---

I guess this is the best you can do for ICC, yes.

MVM> but I'm not sure whether ICC under non-MSVC is able to understand
MVM> MS-specific:
MVM> # pragma warning( push )

I'm not sure but this should be easy to test with their compiler under
Linux.

Regards,
VZ

[Marian 'VooDooMan' Meravy]

On 2012-11-19 19:09, Vadim Zeitlin wrote:
> On Mon, 19 Nov 2012 19:07:52 +0100 Marian 'VooDooMan' Meravy wrote:
>
> MVM> Yes, I'm against to temporary solutions and these ugly non-readable code
> MVM> as well...
>
> Actually I take my words back, it's not only ugly, it doesn't work too, so
> it's not even a solution.
>
> MVM> I can make a patch like:
> MVM>
> MVM> --- snip ---
> MVM> #if defined(__INTELC__)
> MVM> # pragma warning( push )
> MVM> # pragma warning( disable : 809 )
> MVM> #endif
> MVM> class {
> MVM> ...
> MVM> };
> MVM> #if defined(__INTELC__)
> MVM> # pragma warning( pop )
> MVM> #endif
> MVM> --- snip ---
>
> I guess this is the best you can do for ICC, yes.

Okay, I go for it. Gimme some time.

>
> MVM> but I'm not sure whether ICC under non-MSVC is able to understand
> MVM> MS-specific:
> MVM> # pragma warning( push )
>
> I'm not sure but this should be easy to test with their compiler under
> Linux.

Actually, I have only linux server w/o X, and one linux desktop, but
since it is AMD and not Intel CPU, ICC installation package refuses to
install. It seems I need a VM, but I lost all my VM's due to last HDD
crash. But I will setup one, but maybe tomorrow, you know... when did
you last time sleep?... IMO there are not many ICC users, so I can
provide patch [see above] today, and test it under Intel CPU VM+ICC
linux later, and back to you later.

I have been looking at ICC's compiler reference web site[1], they say
about both ICC-specific and ICC-supported pragma's "warning = allows
selective modification of the behavior of compiler warning messages",
but not about "pragma warning( <something> )", so it should be supported...

[1]
http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/cpp-lin/index.htm#GUID-C2D70038-AED3-4E15-9B1A-0D9C24D9D714.htm

[char...@charjans.com]

Well I'm getting a strange new error that seems to be related, here is the build log.

g++ -c -o gcc_mswudll\monodll_accelcmn.o  -O2 -mthreads  -DHAVE_W32API_H -D__WXMSW__

 -DNDEBUG    -D_UNICODE  -I..\..\lib\gcc_dll\mswu -I..\..\include  -W -Wall -DWXBUILDI

NG -I..\..\src\tiff\libtiff -I..\..\src\jpeg -I..\..\src\png -I..\..\src\zlib -I..\..\

src\regex -I..\..\src\expat\lib -I..\..\src\stc\scintilla\include -I..\..\src\stc\scin

tilla\lexlib -I..\..\src\stc\scintilla\src -D__WX__ -DSCI_LEXER -DLINK_LEXERS -DwxUSE_

BASE=1 -DWXMAKINGDLL   -Wno-ctor-dtor-privacy  -Os -fno-keep-inline-dllexport -MTgcc_m

swudll\monodll_accelcmn.o -MFgcc_mswudll\monodll_accelcmn.o.d -MD -MP ../../src/common

/accelcmn.cpp

../../src/msw/textctrl.cpp:232:25: error: declaration of 'virtual wxTextCtrl::~wxTextC

trl()' has a different exception specifier

In file included from ..\..\include/wx/textctrl.h:784:0,

                 from ../../src/msw/textctrl.cpp:30:

..\..\include/wx/msw/textctrl.h:34:13: error: from previous declaration 'virtual wxTex

tCtrl::~wxTextCtrl() throw ()'

mingw32-make: *** [gcc_mswudll\monodll_msw_textctrl.o] Error 1

mingw32-make: *** Waiting for unfinished jobs....

And this is with tdm-mingw 32bit 4.7.1 running on win 7 64bit. With wxWidgets SVN trunk revision 72991.

[Marian 'VooDooMan' Meravy]

Vadim,

I had a successful build in MSVC + ICC.

Actually I was building wxWidgets as x64, as I was before (and always
for like 4 years), and the only warnings I had were:

..\..\src\msw\mediactrl_qt.cpp(103): warning #1899: multicharacter
character literal

..\..\src\msw\mediactrl_qt.cpp(104): warning #1899: multicharacter
character literal

..\..\src\tiff\libtiff\tif_dirinfo.c(749): warning #167: argument of
type "size_t={unsigned __int64} *" is incompatible with parameter of
type "unsigned int *"

the fist two are okay, and the last one is due to libTiff problem with
x64 build, which I had all time (trac ticket is open for this issue
already, for a long time).

So there is my my patch.

Ubuntu 12.10 is still installing in VM, I will install inside of VM the
ICC, and I will try to compile wxWidgets with linux+ICC.

But IMO, you can safely apply the patch "5" [1], and I will report my
investigations in linux+ICC.

[1] http://trac.wxwidgets.org/ticket/14826#comment:14

best,
vdm
.

On 2012-11-19 19:09, Vadim Zeitlin wrote:

[Vadim Zeitlin]

On Mon, 19 Nov 2012 13:49:50 -0800 (PST) char...@charjans.com wrote:

c> Well I'm getting a strange new error that seems to be related, here is the
c> build log.

Yes, it's the same problem except for wxMSW. Should be fixed by r72992.
VZ