Re: [boost] patch to silence a MSVC++ warning in trim.hpp
----Original Message---- From: Stefan Seefeld [mailto:seefeld@sympatico.ca] Sent: 17 August 2005 11:59 To: boost@lists.boost.org Subject: Re: [boost] patch to silence a MSVC++ warning in trim.hpp
Vadim Zeitlin wrote:
Hello,
when compiling <boost/algorithm/string/trim.hpp> with MSVC 7.1 at maximal warning level you get a warning 4512 ("assignment operator could not be generated") because of the const members in struct is_classifiedF from boost/algorithm/string/detail/classification.hpp.
The trivial patch below fixes it. Notice that I didn't take the assignment operator in "#ifdef _MSC_VER" because I see no harm in doing this for all compilers but then no other compiler I know about gives such warning so it should be also safe to add the #ifdef if this is preferred.
Wouldn't it be even better to provide a new baseclass boost::nonassignable that is similar to boost::noncopyable ? That makes things even more explicit.
That wouldn't help. If you derive from boost::noncopyable, you get warning 4512 (because MSVC is unable to generate an assignment operator). I think the best fix is for users to #pragma off the warning. -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434
On Wed, 17 Aug 2005 12:25:14 +0100 Martin Bonner <martin.bonner@pitechnology.com> wrote: MB> > Vadim Zeitlin wrote: MB> >> Hello, MB> >> MB> >> when compiling <boost/algorithm/string/trim.hpp> with MSVC 7.1 at MB> >> maximal warning level you get a warning 4512 ("assignment operator MB> >> could not be generated") because of the const members in struct MB> >> is_classifiedF from boost/algorithm/string/detail/classification.hpp. MB> >> MB> >> The trivial patch below fixes it. ... MB> > Wouldn't it be even better to provide a new baseclass MB> > boost::nonassignable that is similar to boost::noncopyable ? That MB> > makes things even more explicit. MB> > MB> That wouldn't help. If you derive from boost::noncopyable, you get warning MB> 4512 (because MSVC is unable to generate an assignment operator). Indeed, sorry for forgetting to mention about this. MB> I think the best fix is for users to #pragma off the warning. Why? The warning can sometimes be useful and it doesn't cost much to work around it. Of course, I do disable it for now but I try to exhaust all the other alternatives before doing it and here it seems to be well possible to fix the warning in the header without any adverse effects. However if the decision is that the proper solution is to use the #pragma, then I'd still like to have this #pragma inside boost header(s) instead of forcing the users to pepper their code with it. I can provide a patch for this too, of course, but basically it is as simple as adding #ifdef _MSC_VER #pragma warning(disable:4512) #endif before and #ifdef _MSC_VER #pragma warning(default:4512) #endif after the offending struct. Thanks, VZ
On 8/17/05, Vadim Zeitlin <vz-boost@zeitlins.org> wrote:
#ifdef _MSC_VER #pragma warning(disable:4512) #endif
before and
#ifdef _MSC_VER #pragma warning(default:4512) #endif
I think using #pragma warning (push) and #pragma warning (pop) to guard the #pragma warning (disable) is preferable. This is for case where the user of the header has disabled this warning in their own code and doesn't want the default behavior restored. -- Caleb Epstein caleb dot epstein at gmail dot com
participants (1)
-
Caleb Epstein -
Martin Bonner -
Vadim Zeitlin