[units] warnings under msvc
AMDG msvc 8.0 gives the following warnings with /W4: static_rational.hpp line 96 warning 4100: unreferenced formal parameter. T(N)/T(D) should work. conversion.hpp warning 4512: conversion_helper::quantity_conversion_helper assignment operator could not be generated. io.hpp warning 4512 unit_output_helper assignment operator could not be generated io.hpp line 137 warning 4127: conditional expression is constant try if(boost::is_same<Dim,dimensionless_type>()) In Christ, Steven Watanabe
static_rational.hpp line 96 warning 4100: unreferenced formal parameter. T(N)/T(D) should work.
OK, fixed.
conversion.hpp warning 4512: conversion_helper::quantity_conversion_helper assignment operator could not be generated.
io.hpp warning 4512 unit_output_helper assignment operator could not be generated
I just added undefined private operator= to both of these; I assume that should work unless this error is signifying something more significant...
io.hpp line 137 warning 4127: conditional expression is constant try if(boost::is_same<Dim,dimensionless_type>())
OK, fixed.
unit_example_14.cpp(14) : warning C4068: unknown pragma unit_example_14.cpp(16) : fatal error C1083: Cannot open include file: 'mcs/utility/benchmark.hpp': No such file or directory
Right - this needs to use Boost.Timer...
..\..\..\boost/units/cmath.hpp(32) : error C2039: 'isfinite' : is not a member of 'std' ..\..\..\boost/units/cmath.hpp(40) : error C2039: 'isinf' : is not a member of 'std' ..\..\..\boost/units/cmath.hpp(56) : error C2039: 'isnormal' : is not a member of 'std' &c.
What's the convention here? ::isfinite or just isfinite?
unit_example_7.cpp(26) : fatal error C1083: Cannot open include file: 'mcs/array/array.hpp': No such file or directory
I've changed this to default to not define MCS_HAS_ARRAY - then it just uses built in arrays. Thanks, Steven. Matthias
AMDG Matthias Schabel <boost <at> schabel-family.org> writes:
..\..\..\boost/units/cmath.hpp(32) : error C2039: 'isfinite' : is not a member of 'std' ..\..\..\boost/units/cmath.hpp(40) : error C2039: 'isinf' : is not a member of 'std' ..\..\..\boost/units/cmath.hpp(56) : error C2039: 'isnormal' : is not a member of 'std' &c.
What's the convention here? ::isfinite or just isfinite?
It gets worse. Metrowerks 9.2 says ### mwcc Compiler: # In: ..\..\..\boost\units\cmath.hpp # From: unit_example_12.cpp # ---------------------------- # 30: nst boost::units::quantity<Unit,Y>& q) # Error: ^ # unexpected argument while expanding macro 'isfinite' (wanted 1) In Christ, Steven Watanabe
..\..\..\boost/units/cmath.hpp(32) : error C2039: 'isfinite' : is not a member of 'std' ..\..\..\boost/units/cmath.hpp(40) : error C2039: 'isinf' : is not a member of 'std' ..\..\..\boost/units/cmath.hpp(56) : error C2039: 'isnormal' : is not a member of 'std' &c.
What's the convention here? ::isfinite or just isfinite?
It gets worse. Metrowerks 9.2 says
### mwcc Compiler: # In: ..\..\..\boost\units\cmath.hpp # From: unit_example_12.cpp # ---------------------------- # 30: nst boost::units::quantity<Unit,Y>& q) # Error: ^ # unexpected argument while expanding macro 'isfinite' (wanted 1)
I actually think this is the point of Johan Råde's Floating Point Utilities library, which is in the review queue...I'm beginning to see the value... Matthias
AMDG The only other problem I had with Metrowerks was a partial ordering problem which can be fixed by passing unit<...> by reference to the various functions In Christ, Steven Watanabe
The only other problem I had with Metrowerks was a partial ordering problem which can be fixed by passing unit<...> by reference to the various functions
Fixed for the next release...
Because we were working in parallel the include guard for dimension.hpp was not updated.
Fixed.
Neither were those in boost/units/systems
Fixed. I've also changed the CGS system to parallel the SI system in directory structure/granularity.
I successfully compiled and ran all the examples using msvc 7.1. I did not verify the output.
Excellent. So, to summarize : GCC 4.0.X compiles and runs correctly MSVC 8.0 compiles and runs correctly MSVC 7.1 compiles and runs - correctness not checked MWCW 9.2 compiles - problems with partial ordering (fixed), problems with isfinite, etc... (not fixed yet) Has anyone else successfully compiled/used the library with other compilers?
All the static const objects in the library cause ODR violations for functions that use them. You can avoid this by only putting a reference in the unnamed namespace.
Thanks for coming up with a fix. I was just avoiding having to put them in a .cpp file - your solution looks much more appealing. Let me test it out... Matthias
From experience producing code that compiles cleanly MSVC 8.0 at level 4,
may I suggest that none of these are helpful warnings and should be suppressed: After the boost includes (to make sure BOOST_MSVC is defined). #if defined (BOOST_MSVC) # pragma warning(push) # pragma warning(disable: 4127) // conditional expression is constant # pragma warning(disable: 4100) // unreferenced formal parameter // or comment out the parameter thus /* unused_one */ # pragma warning(disable: 4512) // assignment operator could not be generated #endif rest of code .... #ifdef BOOST_MSVC # pragma warning(pop) #endif #endif // BOOST_UNITS Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Watanabe Sent: 12 February 2007 21:21 To: boost@lists.boost.org Subject: [boost] [units] warnings under msvc
Hi Paul, Thanks for the tip. I'm a little uneasy committing this to the library itself; I sort of feel that deciding what level of warning you want is up to the user of the library. Naturally, I could be convinced otherwise... Matthias
may I suggest that none of these are helpful warnings and should be suppressed:
After the boost includes (to make sure BOOST_MSVC is defined).
#if defined (BOOST_MSVC) # pragma warning(push) # pragma warning(disable: 4127) // conditional expression is constant # pragma warning(disable: 4100) // unreferenced formal parameter // or comment out the parameter thus /* unused_one */ # pragma warning(disable: 4512) // assignment operator could not be generated #endif
rest of code ....
#ifdef BOOST_MSVC # pragma warning(pop) #endif
#endif // BOOST_UNITS
Matthias Schabel said: (by the date of Tue, 13 Feb 2007 13:02:49 -0700)
Paul said
#if defined (BOOST_MSVC) # pragma warning(push) # pragma warning(disable: 4127) // conditional expression is constant # pragma warning(disable: 4100) // unreferenced formal parameter // or comment out the parameter thus /* unused_one */ # pragma warning(disable: 4512) // assignment operator could not be generated #endif
Hi Paul,
Thanks for the tip. I'm a little uneasy committing this to the library itself; I sort of feel that deciding what level of warning you want is up to the user of the library. Naturally, I could be convinced otherwise...
I think there should be a boost policy about that. This problem comes back again and again in boost. For instance I hated very much the warnings in Boost.Serialization. But I think that Robert has finally applied patches for that. You know - there are some people out there who try to write a warning--free programs. And if the library gives you a warning, it is annoying - and extra effort to turn it off. Even with a shortest "hello world" you get a warning. Is there a boost policy about warnings? -- Janek Kozicki |
2007/2/13, Janek Kozicki <janek_listy@wp.pl>:
I think there should be a boost policy about that. This problem comes back again and again in boost.
I agree. In Openoffice.org there is a tough policy. Have a look at: http://wiki.services.openoffice.org/wiki/Writing_warning-free_code
Added metafunctions to query dimensions/units/quantities Conversion factors for quantities now computed at compile-time ODR problems with static constants fixed Uses Boost.Timer for benchmarking Numerous minor fixes/tweaks Cheers, Matthias
Henrik Sundberg wrote:
2007/2/13, Janek Kozicki <janek_listy@wp.pl>:
I think there should be a boost policy about that. This problem comes back again and again in boost.
I agree.
I think we all do. One thing we really need though is to get warnings showing up in the test result matrix again, until that happens it's going to hard for authors to fix warnings on compilers they may not have access to.
In Openoffice.org there is a tough policy. Have a look at: http://wiki.services.openoffice.org/wiki/Writing_warning-free_code
Right, but they're concentrating on gcc-only which makes life rather easier. MSVC in particular issues a lot of busy-body warnings that are sometimes hard or impossible to remove without resorting to #pragma's :-( John.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Henrik Sundberg Sent: 13 February 2007 21:37 To: boost@lists.boost.org Subject: Re: [boost] [units] [warnings] under msvc
2007/2/13, Janek Kozicki <janek_listy@wp.pl>:
I think there should be a boost policy about that. This problem comes back again and again in boost.
I agree.
In Openoffice.org there is a tough policy. Have a look at: http://wiki.services.openoffice.org/wiki/Writing_warning-free_code
Indeed, but it does include the getout "When all else fails There are cases where the only sensible solution is to suppress warnings for a given chunk of code: " and the warnings in question often cannot conveniently be 'cured' by changes to the code (though Steven Watanbe made some interesting suggestions to Matthias). I'd certainly like to see a Boost policy that requires people to make a good effort on getting warning free - but it is certainly a hassle - sometimes a 'cure' on one platform provokes a warning on another :-(( Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
From Matthias Schabel From Paul?? (attribution snipped):
may I suggest that none of these are helpful warnings and should be suppressed:
After the boost includes (to make sure BOOST_MSVC is defined).
#if defined (BOOST_MSVC) # pragma warning(push) # pragma warning(disable: 4127) // conditional expression is constant # pragma warning(disable: 4100) // unreferenced formalparameter // or comment out the parameter thus /* unused_one */ # pragma warning(disable: 4512) // assignment operator could not be generated #endif
rest of code ....
#ifdef BOOST_MSVC # pragma warning(pop) #endif
#endif // BOOST_UNITS
Thanks for the tip. I'm a little uneasy committing this to the library itself; I sort of feel that deciding what level of warning you want is up to the user of the library.
I think you may have missed what the change does. It suppress the warnings FOR THE LIBRARY CODE. The warning state is left unchanged for the user's code. That's what "# pragma warning(pop)" does. Obviously, unilaterally suppressing warnings in the user's code is rude. However, leaving ANY warnings showing from library code is also rude - the user is entitled to expect that the library "just works", and any warnings from library code will hide her own warnings.
Naturally, I could be convinced otherwise...
Does the above help? (Incidentally, personally I would not disable 4100. I would comment out the paramenter name instead. The only exception is if the parameter is used on other platforms (via #if) but not on MSVC). -- Martin Bonner Project Leader PI SHURLOK LTD Telephone: +44 1223 441434 / 203894 (direct) Fax: +44 1223 203999 Email: martin.bonner@pi-shurlok.com www.pi-shurlok.com
Does the above help?
(Incidentally, personally I would not disable 4100. I would comment out the paramenter name instead. The only exception is if the parameter is used on other platforms (via #if) but not on MSVC).
Martin, Thanks for the clarification - that makes it more reasonable sounding to me. I will probably wait until the library has been tested a bit more. It looks like I will still have to put the #pragmas in every header file that triggers the warnings, which is a pain, especially since I don't use/have MSVC... Matthias
Paul A Bristow wrote:
From experience producing code that compiles cleanly MSVC 8.0 at level 4,
may I suggest that none of these are helpful warnings and should be suppressed:
# pragma warning(disable: 4127) // conditional expression is constant
Really? I would tend to take that as a sign that the code in question could be written differently to avoid the conditional, perhaps using SFINAE overloads if its controlled by a template parameter's value. Although IIRC MSVC doesn't like while( 1 ) which is sort of annoying but it is ok with for( ; ; ) maybe that's what your referring too. - Michael Marcin
Michael Marcin wrote:
Paul A Bristow wrote:
From experience producing code that compiles cleanly MSVC 8.0 at level 4,
may I suggest that none of these are helpful warnings and should be suppressed:
# pragma warning(disable: 4127) // conditional expression is constant
Really?
I would tend to take that as a sign that the code in question could be written differently to avoid the conditional, perhaps using SFINAE overloads if its controlled by a template parameter's value.
Depends, the main cases I have are things like: if(std::numeric_limits<T>::has_infinity) { // case A } else { // case B } Where cases A and B are tiny one-liners that are a small part of the overall function. You could factor it out, but it makes the code more rather than less obfuscated. My gut feeling is that sometimes it's just not worth the hassle to refactor code like this, even though I was once rather obsessive about doing so! I also have a few cases where there is something like: if(foo<T>() > 0) where sometimes foo<T>() gets inline-expanded to an integral constant expression, and sometimes not (depends on T), so the warning may only appear for certain compilers, with certain types T, for certain optimisation settings :-( John.
participants (8)
-
Henrik Sundberg -
Janek Kozicki -
John Maddock -
Martin Bonner -
Matthias Schabel -
Michael Marcin -
Paul A Bristow -
Steven Watanabe