Hi, I'm compiling the boost::xpressive library under Visual Studio 9 at warning level 4. At the bottom of this email are the endless pages of warnings I'm getting. Note that I am using the latest version of xpressive from the boost trunk. 1>c:\it\personal\rocket_test\sdk\boost\boost\xpressive\detail\core\peeker.hpp(276) : warning C4512: 'boost::xpressive::detail::xpression_peeker<Char>' : assignment operator could not be generated 1> with 1> [ 1> Char=char 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\detail\dynamic\matchable.hpp(67) : see reference to class template instantiation 'boost::xpressive::detail::xpression_peeker<Char>' being compiled 1> with 1> [ 1> Char=char 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\detail\dynamic\matchable.hpp(66) : while compiling class template member function 'void boost::xpressive::detail::matchable_ex<BidiIter>::peek(boost::xpressive::detail::xpression_peeker<Char> &) const' 1> with 1> [ 1> BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>, 1> Char=char 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\intrusive_ptr.hpp(83) : see reference to class template instantiation 'boost::xpressive::detail::matchable_ex<BidiIter>' being compiled 1> with 1> [ 1> BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\intrusive_ptr.hpp(82) : while compiling class template member function 'boost::intrusive_ptr<T>::~intrusive_ptr(void)' 1> with 1> [ 1> T=const boost::xpressive::detail::matchable_ex<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\detail\core\regex_impl.hpp(183) : see reference to class template instantiation 'boost::intrusive_ptr<T>' being compiled 1> with 1> [ 1> T=const boost::xpressive::detail::matchable_ex<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\type_traits\is_class.hpp(76) : see reference to class template instantiation 'boost::xpressive::detail::regex_impl<BidiIter>' being compiled 1> with 1> [ 1> BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\type_traits\is_class.hpp(121) : see reference to class template instantiation 'boost::detail::is_class_impl<T>' being compiled 1> with 1> [ 1> T=boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\type_traits\is_base_and_derived.hpp(210) : see reference to class template instantiation 'boost::is_class<T>' being compiled 1> with 1> [ 1> T=boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\type_traits\is_base_and_derived.hpp(225) : see reference to class template instantiation 'boost::detail::is_base_and_derived_impl<B,D>' being compiled 1> with 1> [ 1> B=boost::xpressive::detail::enable_reference_tracking<boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>>>, 1> D=boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\mpl\assert.hpp(148) : see reference to class template instantiation 'boost::is_base_and_derived<Base,Derived>' being compiled 1> with 1> [ 1> Base=boost::xpressive::detail::enable_reference_tracking<boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>>>, 1> Derived=boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\detail\utility\tracking_ptr.hpp(381) : see reference to class template instantiation 'boost::mpl::assert_arg_pred_not<P>' being compiled 1> with 1> [ 1> P=boost::is_base_and_derived<boost::xpressive::detail::enable_reference_tracking<boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>>>,boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\proto\expr.hpp(181) : see reference to class template instantiation 'boost::xpressive::detail::tracking_ptr<Type>' being compiled 1> with 1> [ 1> Type=boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\basic_regex.hpp(47) : see reference to class template instantiation 'boost::proto::exprns_::expr<Tag,Args>' being compiled 1> with 1> [ 1> Tag=boost::proto::tag::terminal, 1> Args=boost::proto::argsns_::args0<boost::xpressive::detail::tracking_ptr<boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>>>> 1> ] 1> c:\it\personal\rocket_test\source\rocketeventlisteners\mainmenu.cpp(63) : see reference to class template instantiation 'boost::xpressive::basic_regex<BidiIter>' being compiled 1> with 1> [ 1> BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>> 1> ]
Robert Dailey wrote:
I'm compiling the boost::xpressive library under Visual Studio 9 at warning level 4. At the bottom of this email are the endless pages of warnings I'm getting. Note that I am using the latest version of xpressive from the boost trunk.
Thanks, should be fixed now. You'll need to convince the Fusion guys to fix their warnings, too. -- Eric Niebler Boost Consulting www.boost-consulting.com
Robert Dailey <rcdailey <at> gmail.com> writes:
Thanks, should be fixed now. You'll need to convince the Fusion guys to fix their warnings, too.
Does Fusion have a mailing list? How do I go about contacting them? Thanks for the help!
I've just raised a ticket for a 4512 warning i'm getting from Fusion @ http://svn.boost.org/trac/boost/ticket/1619 . You could add any additional warnings that you're seeing to that?
On Feb 5, 2008 11:58 AM, Richard Webb <richard.webb@boldonjames.com> wrote:
I've just raised a ticket for a 4512 warning i'm getting from Fusion @ http://svn.boost.org/trac/boost/ticket/1619 . You could add any additional warnings that you're seeing to that?
Thank you for raising a ticket on the issue for me. I'm not seeing any other warnings so far after the fixes you made. If I start seeing more warnings after utilizing a little more of the xpressive library I'll most definitely let you know, as I'm not sure what warnings apply to fusion or xpressive. Thanks again.
Richard Webb wrote:
Robert Dailey <rcdailey <at> gmail.com> writes:
Thanks, should be fixed now. You'll need to convince the Fusion guys to fix their warnings, too. Does Fusion have a mailing list? How do I go about contacting them? Thanks for the help!
I've just raised a ticket for a 4512 warning i'm getting from Fusion @ http://svn.boost.org/trac/boost/ticket/1619 . You could add any additional warnings that you're seeing to that?
BTW, what is the warning good for? I've found an iteresting quote from ATL: #pragma warning(disable: 4512) // can't generate assignment operator (so what?) If utterly useless, why not globally turn off? Regards, -- Shunsuke Sogame
shunsuke <pstade.mb <at> gmail.com> writes:
BTW, what is the warning good for? I've found an iteresting quote from ATL:
#pragma warning(disable: 4512)//can't generate assignment operator(so what?)
If utterly useless, why not globally turn off?
Several of the ATL/MFC headers in VC9 disable that warning (amongst others) - and a couple of them do appear to disable it globally (no pragma warning push/pop). I've actually got it disabled in the precompiled header in several projects (so it's turned off for everything) - i just get too many instances of the warning otherwise :(
Eric Niebler <eric <at> boost-consulting.com> writes:
Robert Dailey wrote:
I'm compiling the boost::xpressive library under Visual Studio 9 at warning level 4. At the bottom of this email are the endless pages of warnings I'm getting. Note that I am using the latest version of xpressive from the boost trunk.
Thanks, should be fixed now. You'll need to convince the Fusion guys to fix their warnings, too.
I've just tried running the xpressive tests with VC9+warning level 4, and i got one warning from xpressive itself: boost/xpressive/detail/core/matcher/attr_matcher.hpp(65) : warning C4512: 'boost::xpressive::detail::char_translate<Traits,ICase>' : assignment operator could not be generated The only other warnings i get are from fusion (more 4512's !). Thanks, Richard Webb
Richard Webb wrote:
I've just tried running the xpressive tests with VC9+warning level 4, and i got one warning from xpressive itself:
boost/xpressive/detail/core/matcher/attr_matcher.hpp(65) : warning C4512: 'boost::xpressive::detail::char_translate<Traits,ICase>' : assignment operator could not be generated
Fixed it, thanks. -- Eric Niebler Boost Consulting www.boost-consulting.com
I just updated to latest and I'm still getting lots of warnings. I couldn't paste all of the warnings previously because they made the email too long. I'll paste a single warning below: 1>c:\it\personal\rocket_test\sdk\boost\boost\xpressive\detail\utility\sequence_stack.hpp(197) : warning C4996: 'std::fill_n': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' 1> c:\program files\microsoft visual studio 9.0\vc\include\xutility(3257) : see declaration of 'std::fill_n' 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\detail\utility\sequence_stack.hpp(205) : see reference to function template instantiation 'T *boost::xpressive::detail::sequence_stack<T>::push_sequence<true>(size_t,boost::mpl::bool_<C_>)' being compiled 1> with 1> [ 1> T=boost::xpressive::detail::sub_match_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>>, 1> C_=true 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\detail\utility\sequence_stack.hpp(204) : while compiling class template member function 'boost::xpressive::detail::sub_match_impl<BidiIter> *boost::xpressive::detail::sequence_stack<T>::push_sequence(size_t)' 1> with 1> [ 1> BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>, 1> T=boost::xpressive::detail::sub_match_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\match_results.hpp(79) : see reference to class template instantiation 'boost::xpressive::detail::sequence_stack<T>' being compiled 1> with 1> [ 1> T=boost::xpressive::detail::sub_match_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\intrusive_ptr.hpp(83) : see reference to class template instantiation 'boost::xpressive::detail::results_extras<BidiIter>' being compiled 1> with 1> [ 1> BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\intrusive_ptr.hpp(82) : while compiling class template member function 'boost::intrusive_ptr<T>::~intrusive_ptr(void)' 1> with 1> [ 1> T=boost::xpressive::detail::results_extras<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\match_results.hpp(1054) : see reference to class template instantiation 'boost::intrusive_ptr<T>' being compiled 1> with 1> [ 1> T=boost::xpressive::detail::results_extras<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\source\rocketeventlisteners\mainmenu.cpp(66) : see reference to class template instantiation 'boost::xpressive::match_results<BidiIter>' being compiled 1> with 1> [ 1> BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>> 1> ]
Robert Dailey wrote:
I just updated to latest and I'm still getting lots of warnings. I couldn't paste all of the warnings previously because they made the email too long. I'll paste a single warning below:
1>c:\it\personal\rocket_test\sdk\boost\boost\xpressive\detail\utility\sequence_stack.hpp(197) : warning C4996: 'std::fill_n': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators'
This is one of MSVC's security warnings. There is nothing unsafe about this code, despite what msvc would have you believe. Please compile with -D_SCL_SECURE_NO_DEPRECATE to make this warning go away. -- Eric Niebler Boost Consulting www.boost-consulting.com
On Feb 5, 2008 11:34 AM, Eric Niebler <eric@boost-consulting.com> wrote:
This is one of MSVC's security warnings. There is nothing unsafe about this code, despite what msvc would have you believe. Please compile with -D_SCL_SECURE_NO_DEPRECATE to make this warning go away.
I did add this preprocessor directive to my compiler settings immediately after making that post. However I still wanted to bring it to the attention of the mailing list just in case it was important. Thank you for confirming.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Eric Niebler Sent: 05 February 2008 17:35 To: boost@lists.boost.org Subject: Re: [boost] [xpressive] Lots of warnings on VS9
Robert Dailey wrote:
I just updated to latest and I'm still getting lots of warnings. I couldn't paste all of the warnings previously because they made the email too long. I'll paste a single warning below:
: warning C4996: 'std::fill_n': Function call with
unsafe - this call relies on the caller to check that the
1>c:\it\personal\rocket_test\sdk\boost\boost\xpressive\detail\u tility\sequence_stack.hpp(197) parameters that may be passed values are
correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators'
This is one of MSVC's security warnings. There is nothing unsafe about this code, despite what msvc would have you believe. Please compile with -D_SCL_SECURE_NO_DEPRECATE to make this warning go away.
This is quite correct - but could we not make this global to ALL Boost stuff (and also the other persistent unhelpful and massively voluminous warnings that are such a pest - and seriously worrying/discouraging to anyone trying out Boost for the first time). Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul A Bristow <pbristow <at> hetp.u-net.com> writes:
This is quite correct - but could we not make this global to ALL Boost stuff
(and also the other persistent unhelpful and massively voluminous warnings
that are such a pest - and seriously
worrying/discouraging to anyone trying out Boost for the first time).
When this topic came up a while ago, David Abrahams suggested that some Boost-wide prefix/suffix headers to handle this would be usefull. Sounds like a good idea, though i dont know how much work that would be.
On Tue, Feb 05, 2008 at 11:19:55AM -0600, Robert Dailey wrote:
I just updated to latest and I'm still getting lots of warnings. I couldn't paste all of the warnings previously because they made the email too long.
I just want to mention that gcc 4.3 (snapshot) does not emit any warning even with strongest compiler options (-Wall -Wextra -Wno-long-long). There is again only a missing include statement in trunk: Index: boost/xpressive/proto/eval.hpp =================================================================== --- boost/xpressive/proto/eval.hpp (Revision 43111) +++ boost/xpressive/proto/eval.hpp (Arbeitskopie) @@ -10,6 +10,7 @@ #define BOOST_PROTO_EVAL_HPP_EAN_03_29_2007 #include <boost/xpressive/proto/detail/prefix.hpp> // must be first include +#include <boost/xpressive/proto/proto_fwd.hpp> // BOOST_PROTO_CALLABLE #include <boost/type_traits/remove_reference.hpp> #include <boost/xpressive/proto/detail/suffix.hpp> // must be last include Jens
Jens Seidel wrote:
On Tue, Feb 05, 2008 at 11:19:55AM -0600, Robert Dailey wrote:
I just updated to latest and I'm still getting lots of warnings. I couldn't paste all of the warnings previously because they made the email too long.
I just want to mention that gcc 4.3 (snapshot) does not emit any warning even with strongest compiler options (-Wall -Wextra -Wno-long-long).
Good info, thanks.
There is again only a missing include statement in trunk: <snip>
Fixed. Thanks for keeping me honest. I'm against Boost globally disabling any warnings. IMO, it's really the user's call. -- Eric Niebler Boost Consulting www.boost-consulting.com
On Feb 5, 2008 3:11 PM, Eric Niebler <eric@boost-consulting.com> wrote:
I'm against Boost globally disabling any warnings. IMO, it's really the user's call.
I believe boost should keep itself clean, whether that means fixing warnings properly or hiding them via #pragma directives. It's my responsibility to hide my own warnings in my own source files, not in boosts. That's just my opinion on the subject of warnings.
Robert Dailey wrote:
On Feb 5, 2008 3:11 PM, Eric Niebler <eric@boost-consulting.com> wrote:
I'm against Boost globally disabling any warnings. IMO, it's really the user's call.
I believe boost should keep itself clean, whether that means fixing warnings properly or hiding them via #pragma directives. It's my responsibility to hide my own warnings in my own source files, not in boosts. That's just my opinion on the subject of warnings.
An organization may have a policy to disallow use of "unsafe" constructs that could lead to unchecked buffer overflows. They would want actually want to know if Boost headers were using raw pointers as output iterators, for instance. If Boost disables these warnings for its own code, it presents a barrier to adoption for these organizations. If Boost adopts a policy whereby noisy warnings are disabled for Boost code, there should at least be a well-documented method for re-enabling these warnings for the people who care about them. The concern is that, since nobody reads the docs, and since the lack of warnings actually hides the issue, it could lead to a false sense of security. It seems like the wrong default to me. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler skrev:
Robert Dailey wrote:
On Feb 5, 2008 3:11 PM, Eric Niebler <eric@boost-consulting.com> wrote:
I'm against Boost globally disabling any warnings. IMO, it's really the user's call.
I believe boost should keep itself clean, whether that means fixing warnings properly or hiding them via #pragma directives. It's my responsibility to hide my own warnings in my own source files, not in boosts. That's just my opinion on the subject of warnings.
An organization may have a policy to disallow use of "unsafe" constructs that could lead to unchecked buffer overflows. They would want actually want to know if Boost headers were using raw pointers as output iterators, for instance. If Boost disables these warnings for its own code, it presents a barrier to adoption for these organizations.
If Boost adopts a policy whereby noisy warnings are disabled for Boost code, there should at least be a well-documented method for re-enabling these warnings for the people who care about them. The concern is that, since nobody reads the docs, and since the lack of warnings actually hides the issue, it could lead to a false sense of security. It seems like the wrong default to me.
It would be usefull to have policies on the issue that are used throughout boost. To me the following make sence: Allow code to locally quiet a compilers warnings only if: - it can be asserted that the issue warned about is not going to materialize - the warning is plain wrong All other warnings should be emitted while compiling boost or compiling with boost headers; unless the user read the docs and follow instructions on how to make them quiet. As suggested by others, use of pre/post headers like: #include <boost/config/pre.hpp> code goes here #include <boost/config/post.hpp> used in *all* warning infected boost source files may be the way ahead. It may prove to be a smart way of allowing a central place for boost users to disable warnings. They can then determine if they want the warnings to be disabled globally in their project or only locally for the boost code. It would be neat if we could override pree/post.hpp without touching the distribution sources. Just my 5 cents. -- Bjørn
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Eric Niebler Sent: 05 February 2008 21:12 To: boost@lists.boost.org Subject: Re: [boost] [xpressive] Lots of warnings on VS9
Jens Seidel wrote:
On Tue, Feb 05, 2008 at 11:19:55AM -0600, Robert Dailey wrote:
I just updated to latest and I'm still getting lots of warnings. I couldn't paste all of the warnings previously because they made the email too long.
I just want to mention that gcc 4.3 (snapshot) does not emit any warning even with strongest compiler options (-Wall -Wextra -Wno-long-long).
Good info, thanks.
There is again only a missing include statement in trunk: <snip>
Fixed. Thanks for keeping me honest.
I'm against Boost globally disabling any warnings. IMO, it's really the user's call.
OK, I can accept that - but only as long as Boost releases really do compile warning free. Push'n'Popping warning supression is a load of hassle - as I've found quieting the Math Toolkit - but I feel we've got to do it, at least for the latest compiler releases. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
participants (7)
-
Bjørn Roald -
Eric Niebler -
Jens Seidel -
Paul A Bristow -
Richard Webb -
Robert Dailey -
shunsuke