You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Andre Fischer <aw...@gmail.com> on 2014/03/05 09:30:14 UTC
Compiler warnings
I am currently working on some bug in the sc module and find that it is
really hard to even find compiler errors among the many warning
messages. Some of these warnings are caused directly by code in sc but
the majority of the warnings originate in header files. Platform is
Windows. The most annoying warnings are
warning C4530: C++ exception handler used, but unwind semantics are
not enabled. Specify /EHsc
and even more (because of the warning text that is repeated again and
again)
warning C4555: expression has no effect; expected expression with
side-effect
(see full text below)
Any ideas how to silence these two?
re C4530: One option would be to compile all sc code with exceptions
enabled. Does anyone know of a reason not to do that?
Best regards,
Andre
PS: here is the complete output for one instance of the C4555 warning:
C:\PROGRA~2\MICROS~1.0\VC\include\../../VC/include/list(1137) :
warning C4555: expression has no effect; expected expression with
side-effect
C:\PROGRA~2\MICROS~1.0\VC\include\../../VC/include/list(1126) : while
compiling class template member function 'void
std::list<_Ty,_Ax>::_Splice(std::list<_Ty,_Ax>::_Const_iterator<_Secure_validation>,std::list<_Ty,_Ax>
&,std::list<_Ty,_Ax>::_Const_iterator<_Secure_validation>,std::list<_Ty,_Ax>::_Const_iterator<_Secure_validation>,unsigned
int,bool)'
with
[
_Ty=std::pair<const String,OpCode>,
_Ax=std::allocator<std::pair<const String,OpCode>>,
_Secure_validation=true
]
C:\PROGRA~2\MICROS~1.0\VC\include\xhash(205) : see reference to
class template instantiation 'std::list<_Ty,_Ax>' being compiled
with
[
_Ty=std::pair<const String,OpCode>,
_Ax=std::allocator<std::pair<const String,OpCode>>
]
C:\PROGRA~2\MICROS~1.0\VC\include\../../VC/include/unordered_map(86) :
see reference to class template instantiation 'stdext::_Hash<_Traits>'
being compiled
with
[
_Traits=std::tr1::_Umap_traits<String,OpCode,stdext::_Hash_compare<String,formula::StringHashCode,std::equal_to<String>>,std::allocator<std::pair<String,OpCode>>,false>
]
C:\source\trunk\git\main\solver\410\wntmsci12.pro\inc\stl\hash_map(59) :
see reference to class template instantiation
'std::tr1::unordered_map<_Kty,_Ty,_Hasher,_Keyeq,_Alloc>' being compiled
with
[
_Kty=String,
_Ty=OpCode,
_Hasher=formula::StringHashCode,
_Keyeq=std::equal_to<String>,
_Alloc=std::allocator<std::pair<String,OpCode>>
]
C:\source\trunk\git\main\solver\410\wntmsci12.pro\inc\formula/FormulaCompiler.hxx(109)
: see reference to class template instantiation
'std::hash_map<__K,__T,__H,__E>' being compiled
with
[
__K=String,
__T=OpCode,
__H=formula::StringHashCode,
__E=std::equal_to<String>
]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by Andre Fischer <aw...@gmail.com>.
On 05.03.2014 11:54, Andre Fischer wrote:
> On 05.03.2014 09:30, Andre Fischer wrote:
>>
>
> I have created issue 124361 for this. The 4555 warning is triggered
> by the hash_map wrapper in module stl_port/ when it includes
> unordered_map. Luckily this allows us to turn of the warning
> temporarily for just this header.
Revision 1575930 enables exception support for all source files of sc.
So if you experience any problems, this is the change to roll back :-)
-Andre
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by Andre Fischer <aw...@gmail.com>.
On 05.03.2014 09:30, Andre Fischer wrote:
> I am currently working on some bug in the sc module and find that it
> is really hard to even find compiler errors among the many warning
> messages. Some of these warnings are caused directly by code in sc
> but the majority of the warnings originate in header files. Platform
> is Windows. The most annoying warnings are
>
>
> warning C4530: C++ exception handler used, but unwind semantics are
> not enabled. Specify /EHsc
>
> and even more (because of the warning text that is repeated again and
> again)
>
> warning C4555: expression has no effect; expected expression with
> side-effect
>
> (see full text below)
>
>
> Any ideas how to silence these two?
>
I have created issue 124361 for this. The 4555 warning is triggered by
the hash_map wrapper in module stl_port/ when it includes
unordered_map. Luckily this allows us to turn of the warning
temporarily for just this header.
-Andre
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by Andre Fischer <aw...@gmail.com>.
On 05.03.2014 11:53, Herbert Duerr wrote:
> On 05.03.2014 11:45, Andre Fischer wrote:
>> On 05.03.2014 11:28, Herbert Duerr wrote:
>>> On 05.03.2014 10:28, Andre Fischer wrote:
>>>> On 05.03.2014 10:01, Herbert Duerr wrote:
>>>>> The warning "expression has no effect" itself is interesting enough,
>>>>> just not in in list header. Fortunately terms like "list(1137)"
>>>>> can be
>>>>> filtered out easily.
>>>>
>>>> Please explain how that can be filtered out easily.
>>>
>>> e.g. by piping the output through the command
>>> perl -ne 'print if not /^.*list.1137/../^\S/'
>>> It removes all "list.1137" lines and their indented followup lines.
>>> Unfortunately also one more line but perl experts can probably fix
>>> that easily.
>>
>> Of course, on the command line this is easy, but I am building inside
>> emacs. Any idea how to do it there?
>
> As I don't use emacs I had to rely on my googling skills instead and
> found [1] that looks relevant. Does it help?
No, building in emacs works a little different. But keep trying :-)
-Andre
>
> [1]
> http://stackoverflow.com/questions/206806/filtering-text-through-a-shell-command-in-emacs
>
> Herbert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by Herbert Duerr <hd...@apache.org>.
On 05.03.2014 11:45, Andre Fischer wrote:
> On 05.03.2014 11:28, Herbert Duerr wrote:
>> On 05.03.2014 10:28, Andre Fischer wrote:
>>> On 05.03.2014 10:01, Herbert Duerr wrote:
>>>> The warning "expression has no effect" itself is interesting enough,
>>>> just not in in list header. Fortunately terms like "list(1137)" can be
>>>> filtered out easily.
>>>
>>> Please explain how that can be filtered out easily.
>>
>> e.g. by piping the output through the command
>> perl -ne 'print if not /^.*list.1137/../^\S/'
>> It removes all "list.1137" lines and their indented followup lines.
>> Unfortunately also one more line but perl experts can probably fix
>> that easily.
>
> Of course, on the command line this is easy, but I am building inside
> emacs. Any idea how to do it there?
As I don't use emacs I had to rely on my googling skills instead and
found [1] that looks relevant. Does it help?
[1]
http://stackoverflow.com/questions/206806/filtering-text-through-a-shell-command-in-emacs
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by Andre Fischer <aw...@gmail.com>.
On 05.03.2014 11:28, Herbert Duerr wrote:
> On 05.03.2014 10:28, Andre Fischer wrote:
>> On 05.03.2014 10:01, Herbert Duerr wrote:
>>> The warning "expression has no effect" itself is interesting enough,
>>> just not in in list header. Fortunately terms like "list(1137)" can be
>>> filtered out easily.
>>
>> Please explain how that can be filtered out easily.
>
> e.g. by piping the output through the command
> perl -ne 'print if not /^.*list.1137/../^\S/'
> It removes all "list.1137" lines and their indented followup lines.
> Unfortunately also one more line but perl experts can probably fix
> that easily.
Of course, on the command line this is easy, but I am building inside
emacs. Any idea how to do it there?
-Andre
>
> Herbert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by Herbert Duerr <hd...@apache.org>.
On 05.03.2014 10:28, Andre Fischer wrote:
> On 05.03.2014 10:01, Herbert Duerr wrote:
>> The warning "expression has no effect" itself is interesting enough,
>> just not in in list header. Fortunately terms like "list(1137)" can be
>> filtered out easily.
>
> Please explain how that can be filtered out easily.
e.g. by piping the output through the command
perl -ne 'print if not /^.*list.1137/../^\S/'
It removes all "list.1137" lines and their indented followup lines.
Unfortunately also one more line but perl experts can probably fix that
easily.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by Andre Fischer <aw...@gmail.com>.
On 05.03.2014 10:01, Herbert Duerr wrote:
> On 05.03.2014 09:30, Andre Fischer wrote:
>> I am currently working on some bug in the sc module and find that it is
>> really hard to even find compiler errors among the many warning
>> messages. Some of these warnings are caused directly by code in sc but
>> the majority of the warnings originate in header files. Platform is
>> Windows. The most annoying warnings are
>>
>>
>> warning C4530: C++ exception handler used, but unwind semantics are
>> not enabled. Specify /EHsc
>>
>> and even more (because of the warning text that is repeated again and
>> again)
>>
>> warning C4555: expression has no effect; expected expression with
>> side-effect
>
> The problem is in MSVC2008's list header. They probably fixed that in
> their newer versions. Another reason to update our build environment
> on that platform to something newer.
>
> The warning "expression has no effect" itself is interesting enough,
> just not in in list header. Fortunately terms like "list(1137)" can be
> filtered out easily.
Please explain how that can be filtered out easily.
>
>> Any ideas how to silence these two?
>
> We could disable such warnings altogether by adding e.g. the -wd4555
> option to CFLAGSWARNCXX in main/solenv/inc/wntmsci11.mk and
> main/solenv/gbuild/platform/windows.mk
How do we do that only for the system headers?
-Andre
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by Andre Fischer <aw...@gmail.com>.
On 05.03.2014 14:49, jan i wrote:
> On 5 March 2014 14:42, Andre Fischer <aw...@gmail.com> wrote:
>
>> On 05.03.2014 10:01, Herbert Duerr wrote:
>>
>>> On 05.03.2014 09:30, Andre Fischer wrote:
>>>
>>> re C4530: One option would be to compile all sc code with exceptions
>>>> enabled.
>>>>
>>> That sounds reasonable.
>>>
>>> Does anyone know of a reason not to do that?
>>> Not that I'm aware of.
>>>
>> I am neither, that's why I ask :-)
>>
>> Exception support does make object files larger and possibly a bit slower.
>> The question is, is that significant? Module sw nowadays has exception
>> support for all its files. And not changing at least the files in sc/ for
>> which there are warnings might lead to memory leaks when there are
>> exceptions. So it is probably best to activate support for exceptions
>> module wide.
>>
> On ubuntu, the "slower" is not measureable. It is basically to extra
> function calls, and a word extra on heap, I assume it is identical on
> windows.
>
> On ubuntu object files seems to be 5-10% bigger, but the final exe (I use
> this in e.g. genLang) in my case is less than 1% bigger.
Thanks, that is good to know. I remember vaguely that the size increase
on Solaris was more noticeable. But that was years ago.
-Andre
>
> I had problems with exceptions in modules where java is called (just a
> warning).
>
>
> rgds
> jan I.
>
>
>> -Andre
>> Herbert
>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by jan i <ja...@apache.org>.
On 5 March 2014 14:42, Andre Fischer <aw...@gmail.com> wrote:
> On 05.03.2014 10:01, Herbert Duerr wrote:
>
>> On 05.03.2014 09:30, Andre Fischer wrote:
>>
>> re C4530: One option would be to compile all sc code with exceptions
>>> enabled.
>>>
>>
>> That sounds reasonable.
>>
>> Does anyone know of a reason not to do that?
>>>
>>
>> Not that I'm aware of.
>>
>
> I am neither, that's why I ask :-)
>
> Exception support does make object files larger and possibly a bit slower.
> The question is, is that significant? Module sw nowadays has exception
> support for all its files. And not changing at least the files in sc/ for
> which there are warnings might lead to memory leaks when there are
> exceptions. So it is probably best to activate support for exceptions
> module wide.
>
On ubuntu, the "slower" is not measureable. It is basically to extra
function calls, and a word extra on heap, I assume it is identical on
windows.
On ubuntu object files seems to be 5-10% bigger, but the final exe (I use
this in e.g. genLang) in my case is less than 1% bigger.
I had problems with exceptions in modules where java is called (just a
warning).
rgds
jan I.
> -Andre
> Herbert
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Compiler warnings
Posted by Herbert Duerr <hd...@apache.org>.
On 05.03.2014 14:42, Andre Fischer wrote:
> Exception support does make object files larger and possibly a bit
> slower. The question is, is that significant?
To put some actual data behind this: the exception handling tables in
the libraries cost us about 20MB (on our current 64bit Linux build).
Twenty megabytes are certainly significant, but as they are useful this
is a cost we have to bear.
> Module sw nowadays has
> exception support for all its files. And not changing at least the
> files in sc/ for which there are warnings might lead to memory leaks
> when there are exceptions. So it is probably best to activate support
> for exceptions module wide.
There are files that use an "EXCEPTION_OFF" define to generate different
code depending on whether exception handling is enabled or not. I
suggest to analyze them and their uses...
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by Andre Fischer <aw...@gmail.com>.
On 05.03.2014 10:01, Herbert Duerr wrote:
> On 05.03.2014 09:30, Andre Fischer wrote:
>
>> re C4530: One option would be to compile all sc code with exceptions
>> enabled.
>
> That sounds reasonable.
>
>> Does anyone know of a reason not to do that?
>
> Not that I'm aware of.
I am neither, that's why I ask :-)
Exception support does make object files larger and possibly a bit
slower. The question is, is that significant? Module sw nowadays has
exception support for all its files. And not changing at least the
files in sc/ for which there are warnings might lead to memory leaks
when there are exceptions. So it is probably best to activate support
for exceptions module wide.
-Andre
>
> Herbert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by Herbert Duerr <hd...@apache.org>.
On 05.03.2014 09:30, Andre Fischer wrote:
> I am currently working on some bug in the sc module and find that it is
> really hard to even find compiler errors among the many warning
> messages. Some of these warnings are caused directly by code in sc but
> the majority of the warnings originate in header files. Platform is
> Windows. The most annoying warnings are
>
>
> warning C4530: C++ exception handler used, but unwind semantics are
> not enabled. Specify /EHsc
>
> and even more (because of the warning text that is repeated again and
> again)
>
> warning C4555: expression has no effect; expected expression with
> side-effect
The problem is in MSVC2008's list header. They probably fixed that in
their newer versions. Another reason to update our build environment on
that platform to something newer.
The warning "expression has no effect" itself is interesting enough,
just not in in list header. Fortunately terms like "list(1137)" can be
filtered out easily.
> Any ideas how to silence these two?
We could disable such warnings altogether by adding e.g. the -wd4555
option to CFLAGSWARNCXX in main/solenv/inc/wntmsci11.mk and
main/solenv/gbuild/platform/windows.mk
> re C4530: One option would be to compile all sc code with exceptions
> enabled.
That sounds reasonable.
> Does anyone know of a reason not to do that?
Not that I'm aware of.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by Andre Fischer <aw...@gmail.com>.
On 05.03.2014 14:18, Rob Weir wrote:
> On Wed, Mar 5, 2014 at 7:32 AM, jan i <ja...@apache.org> wrote:
>> On 5 March 2014 12:46, Andre Fischer <aw...@gmail.com> wrote:
>>
>>> On 05.03.2014 12:38, John O'Sullivan wrote:
>>>
>>>> Use MSVC's WD flag to disable the warning. You'll probably need to hack
>>>> wntmsci11.mk...
>>>>
>>> I wouldn't like to turn off this warning globally. I only don't want to
>>> see it for system headers that I can't change anyway.
>>>
>>>
>> Use #pragma to disable/enable the warnings. Put the #pragma around the
>> include statement.
>>
> Or use a push/pop set of pragmas, which handles nested inclusion
> scenarios safer:
>
> http://msdn.microsoft.com/en-us/library/2c8f766e%28v=vs.90%29.aspx
>
> -Rob
>
Thanks John, Rob, Jan, I think I have this warning under control now.
As suggested I use
#if defined(_MSC_VER)
#pragma warning(push)
#pragma warning(disable:4555)
#include ...
#pragma warning(pop)
#endif
After putting this in hash_map and still seeing warnings 4555 I thought
that maybe not only the definition of the list template had to be
treated this way but also the template instantiation, which would have
required a lot more work. Luckily I just had to do the same fix for the
list template. No more 4555.
-Andre
>> rgds
>> jan I.
>>
>> -Andre
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by Andre Fischer <aw...@gmail.com>.
On 05.03.2014 14:20, jan i wrote:
> On 5 March 2014 14:18, Rob Weir <ro...@apache.org> wrote:
>
>> On Wed, Mar 5, 2014 at 7:32 AM, jan i <ja...@apache.org> wrote:
>>> On 5 March 2014 12:46, Andre Fischer <aw...@gmail.com> wrote:
>>>
>>>> On 05.03.2014 12:38, John O'Sullivan wrote:
>>>>
>>>>> Use MSVC's WD flag to disable the warning. You'll probably need to hack
>>>>> wntmsci11.mk...
>>>>>
>>>> I wouldn't like to turn off this warning globally. I only don't want to
>>>> see it for system headers that I can't change anyway.
>>>>
>>>>
>>> Use #pragma to disable/enable the warnings. Put the #pragma around the
>>> include statement.
>>>
>> Or use a push/pop set of pragmas, which handles nested inclusion
>> scenarios safer:
>>
>> http://msdn.microsoft.com/en-us/library/2c8f766e%28v=vs.90%29.aspx
>>
Yes, I am already doing that. But with my last commit [1] I missed
another inclusion of a system header that triggers the warning.
> If you use push/pop please check for platform, since this is not supported
> by all C++ compilers, whereas #pragma alone is.
That is not a problem here. Warnings are compiler dependent. And when
you know for which compiler you want to turn off a warning, you also
know if it can handle push/pop.
-Andre
>
> rgds
> jan I.
>
>
>> -Rob
>>
[1] http://svn.apache.org/viewvc?view=revision&revision=1574449
>>> rgds
>>> jan I.
>>>
>>> -Andre
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by jan i <ja...@apache.org>.
On 5 March 2014 14:18, Rob Weir <ro...@apache.org> wrote:
> On Wed, Mar 5, 2014 at 7:32 AM, jan i <ja...@apache.org> wrote:
> > On 5 March 2014 12:46, Andre Fischer <aw...@gmail.com> wrote:
> >
> >> On 05.03.2014 12:38, John O'Sullivan wrote:
> >>
> >>> Use MSVC's WD flag to disable the warning. You'll probably need to hack
> >>> wntmsci11.mk...
> >>>
> >>
> >> I wouldn't like to turn off this warning globally. I only don't want to
> >> see it for system headers that I can't change anyway.
> >>
> >>
> > Use #pragma to disable/enable the warnings. Put the #pragma around the
> > include statement.
> >
>
> Or use a push/pop set of pragmas, which handles nested inclusion
> scenarios safer:
>
> http://msdn.microsoft.com/en-us/library/2c8f766e%28v=vs.90%29.aspx
>
If you use push/pop please check for platform, since this is not supported
by all C++ compilers, whereas #pragma alone is.
rgds
jan I.
>
> -Rob
>
>
> > rgds
> > jan I.
> >
> > -Andre
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Compiler warnings
Posted by Rob Weir <ro...@apache.org>.
On Wed, Mar 5, 2014 at 7:32 AM, jan i <ja...@apache.org> wrote:
> On 5 March 2014 12:46, Andre Fischer <aw...@gmail.com> wrote:
>
>> On 05.03.2014 12:38, John O'Sullivan wrote:
>>
>>> Use MSVC's WD flag to disable the warning. You'll probably need to hack
>>> wntmsci11.mk...
>>>
>>
>> I wouldn't like to turn off this warning globally. I only don't want to
>> see it for system headers that I can't change anyway.
>>
>>
> Use #pragma to disable/enable the warnings. Put the #pragma around the
> include statement.
>
Or use a push/pop set of pragmas, which handles nested inclusion
scenarios safer:
http://msdn.microsoft.com/en-us/library/2c8f766e%28v=vs.90%29.aspx
-Rob
> rgds
> jan I.
>
> -Andre
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by jan i <ja...@apache.org>.
On 5 March 2014 12:46, Andre Fischer <aw...@gmail.com> wrote:
> On 05.03.2014 12:38, John O'Sullivan wrote:
>
>> Use MSVC's WD flag to disable the warning. You'll probably need to hack
>> wntmsci11.mk...
>>
>
> I wouldn't like to turn off this warning globally. I only don't want to
> see it for system headers that I can't change anyway.
>
>
Use #pragma to disable/enable the warnings. Put the #pragma around the
include statement.
rgds
jan I.
-Andre
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Compiler warnings
Posted by Andre Fischer <aw...@gmail.com>.
On 05.03.2014 12:38, John O'Sullivan wrote:
> Use MSVC's WD flag to disable the warning. You'll probably need to hack
> wntmsci11.mk...
I wouldn't like to turn off this warning globally. I only don't want to
see it for system headers that I can't change anyway.
-Andre
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Compiler warnings
Posted by John O'Sullivan <os...@gmail.com>.
Use MSVC's WD flag to disable the warning. You'll probably need to hack
wntmsci11.mk...
On 5 Mar 2014 08:31, "Andre Fischer" <aw...@gmail.com> wrote:
> I am currently working on some bug in the sc module and find that it is
> really hard to even find compiler errors among the many warning messages.
> Some of these warnings are caused directly by code in sc but the majority
> of the warnings originate in header files. Platform is Windows. The most
> annoying warnings are
>
>
> warning C4530: C++ exception handler used, but unwind semantics are not
> enabled. Specify /EHsc
>
> and even more (because of the warning text that is repeated again and
> again)
>
> warning C4555: expression has no effect; expected expression with
> side-effect
>
> (see full text below)
>
>
> Any ideas how to silence these two?
>
> re C4530: One option would be to compile all sc code with exceptions
> enabled. Does anyone know of a reason not to do that?
>
>
> Best regards,
>
> Andre
>
>
>
> PS: here is the complete output for one instance of the C4555 warning:
>
> C:\PROGRA~2\MICROS~1.0\VC\include\../../VC/include/list(1137) : warning
> C4555: expression has no effect; expected expression with side-effect
> C:\PROGRA~2\MICROS~1.0\VC\include\../../VC/include/list(1126) : while
> compiling class template member function 'void std::list<_Ty,_Ax>::_Splice(
> std::list<_Ty,_Ax>::_Const_iterator<_Secure_validation>,std::list<_Ty,_Ax>
> &,std::list<_Ty,_Ax>::_Const_iterator<_Secure_validation>,
> std::list<_Ty,_Ax>::_Const_iterator<_Secure_validation>,unsigned
> int,bool)'
> with
> [
> _Ty=std::pair<const String,OpCode>,
> _Ax=std::allocator<std::pair<const String,OpCode>>,
> _Secure_validation=true
> ]
> C:\PROGRA~2\MICROS~1.0\VC\include\xhash(205) : see reference to
> class template instantiation 'std::list<_Ty,_Ax>' being compiled
> with
> [
> _Ty=std::pair<const String,OpCode>,
> _Ax=std::allocator<std::pair<const String,OpCode>>
> ]
> C:\PROGRA~2\MICROS~1.0\VC\include\../../VC/include/unordered_map(86) :
> see reference to class template instantiation 'stdext::_Hash<_Traits>'
> being compiled
> with
> [
> _Traits=std::tr1::_Umap_traits<String,OpCode,stdext::_
> Hash_compare<String,formula::StringHashCode,std::equal_to<
> String>>,std::allocator<std::pair<String,OpCode>>,false>
> ]
> C:\source\trunk\git\main\solver\410\wntmsci12.pro\inc\stl\hash_map(59) :
> see reference to class template instantiation 'std::tr1::unordered_map<_Kty,_Ty,_Hasher,_Keyeq,_Alloc>'
> being compiled
> with
> [
> _Kty=String,
> _Ty=OpCode,
> _Hasher=formula::StringHashCode,
> _Keyeq=std::equal_to<String>,
> _Alloc=std::allocator<std::pair<String,OpCode>>
> ]
> C:\source\trunk\git\main\solver\410\wntmsci12.pro\inc\
> formula/FormulaCompiler.hxx(109) : see reference to class template
> instantiation 'std::hash_map<__K,__T,__H,__E>' being compiled
> with
> [
> __K=String,
> __T=OpCode,
> __H=formula::StringHashCode,
> __E=std::equal_to<String>
> ]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>