[spirit] Causes a blizzard of warning from Boost.Format under MSVC?
I'm at a loss to explain this, but this program: #include <boost/math/special_functions.hpp> int main() { boost::math::erf(2); } Compiles cleaning with MSVC-8, but as soon as I add a particular spirit #include: #include <boost/math/special_functions.hpp> #include <boost/spirit/utility/distinct.hpp> int main() { boost::math::erf(2); } Then Boost.Format (used internally be Boost.Math for error message formatting) issues a whole blizzard of warnings, that I actually thought I had fixed. I've checked Spirit for mismatched #pragma push/pop declarations, but they all look OK to me. Does anyone have any ideas what may be going on here, 'cos I'm stumped and the warnings are really very annoying! Many thanks, John.
----- Mensaje original ----- De: John Maddock <john@johnmaddock.co.uk> Fecha: Sábado, Diciembre 15, 2007 11:22 am Asunto: [boost] [spirit] Causes a blizzard of warning from Boost.Format under MSVC? Para: Boost mailing list <boost@lists.boost.org>
I'm at a loss to explain this, but this program:
#include <boost/math/special_functions.hpp>
int main() { boost::math::erf(2); }
Compiles cleaning with MSVC-8, but as soon as I add a particular spirit #include:
#include <boost/math/special_functions.hpp> #include <boost/spirit/utility/distinct.hpp>
int main() { boost::math::erf(2); }
Then Boost.Format (used internally be Boost.Math for error message formatting) issues a whole blizzard of warnings, that I actually thought I had fixed.
I'm able to reproduce the behavior you describe and don't have any explanation for it either. But note one thing: the warnings I've got in the second scenario are all C4267 (conversion from size_t to const unsigned int, possible loss of data), which you are not explicitly silencing. If you add the corersponding pragma warning(disable: 4267) at boost/math/policies/error_handling.hpp, compile is clean then in the second scenario as well. Just my 2 cents, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
JOAQUIN LOPEZ MU?Z <joaquin <at> tid.es> writes:
I'm able to reproduce the behavior you describe and don't have any explanation for it either. But note one thing: the warnings I've got in the second scenario are all C4267 (conversion from size_t to const unsigned int, possible loss of data), which you are not explicitly silencing. If you add the corersponding pragma warning(disable: 4267) at boost/math/policies/error_handling.hpp, compile is clean then in the second scenario as well.
Just my 2 cents,
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
I get the same as Joaquín, though only if i compile with the "detect 64-bit portability issues" option turned on. In case it's of any interest, i notice that adding a boost::format formatter("%d"); formatter % 42; into the second case causes a bunch of the warnings to disappear, and a boost\spirit\utility\impl\chset\range_run.ipp(69) : warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data to appear instead.
Richard Webb wrote:
JOAQUIN LOPEZ MU?Z <joaquin <at> tid.es> writes:
I'm able to reproduce the behavior you describe and don't have any explanation for it either. But note one thing: the warnings I've got in the second scenario are all C4267 (conversion from size_t to const unsigned int, possible loss of data), which you are not explicitly silencing. If you add the corersponding pragma warning(disable: 4267) at boost/math/policies/error_handling.hpp, compile is clean then in the second scenario as well.
Just my 2 cents,
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
I get the same as Joaquín, though only if i compile with the "detect 64-bit portability issues" option turned on.
In case it's of any interest, i notice that adding a
boost::format formatter("%d"); formatter % 42;
into the second case causes a bunch of the warnings to disappear, and a
boost\spirit\utility\impl\chset\range_run.ipp(69) : warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data
to appear instead.
This is indeed weird, and I've finally tracked down the cause: it's nothing to do with Spirit and everything to do with Microsoft. If you pass a pair of std::size_t's to std::min or std::max then: * You get no warning if the min/max<unsigned> templates haven't been instantiated yet. * A warning if some other code has already instantiated std::min/max<unsigned>. Truely weird and very annoying indeed ! I'll add some #pragma's to Boost.Format to reduce the warning noise: otherwise the instantiation stack trace is so verbose you miss any important warnings. Sorry for the noise, John.
John Maddock wrote:
If you pass a pair of std::size_t's to std::min or std::max then:
* You get no warning if the min/max<unsigned> templates haven't been instantiated yet. * A warning if some other code has already instantiated std::min/max<unsigned>.
Truely weird and very annoying indeed !
Apparently the template is instantiated per truly different type, but it carries the __w64 annotation of the first such type it is instantiated with. In other words, if the first instantiation is min<unsigned>, passing the "unsigned __w64" size_t causes the warning. Makes me wonder, if the first instantiation is min<unsigned __w64>, does assigning the return value of min(unsigned, unsigned) to unsigned cause the warning, too? In any case, definitely an MS bug. A very tricky one. Sebastian Redl
John Maddock <john <at> johnmaddock.co.uk> writes:
I'll add some #pragma's to Boost.Format to reduce the warning noise: otherwise the instantiation stack trace is so verbose you miss any important warnings.
If you're looking at silencing warnings from Format, is there any chance you could look at http://svn.boost.org/trac/boost/ticket/1510 ? It can produce some pretty substantial warnings as well. On another note (and i apologize for the noise in advance if i'm making things up here) - when i looked at the call stack for the warnings, i noticed void raise_error(const char* function, const char* message, const T& val) { if(function == 0) function = "Unknown function"; ... msg += (boost::format(function) % typeid(T).name()).str(); in math\error_handling.hpp Does that need to be something like function = "Unknown function %1%"; For the format call to work?
Richard Webb wrote:
If you're looking at silencing warnings from Format, is there any chance you could look at http://svn.boost.org/trac/boost/ticket/1510 ? It can produce some pretty substantial warnings as well.
Hopefully now done.
On another note (and i apologize for the noise in advance if i'm making things up here) - when i looked at the call stack for the warnings, i noticed
void raise_error(const char* function, const char* message, const T& val) { if(function == 0) function = "Unknown function"; ... msg += (boost::format(function) % typeid(T).name()).str();
in math\error_handling.hpp Does that need to be something like function = "Unknown function %1%"; For the format call to work?
Quite right: there were a couple of other instances where that was wrong as well: now fixed in SVN. Fortunately none of our code ever calls that function with a NULL-pointer, but it doesn't harm to have a working fallback in that case! Thanks, good spot, John.
John Maddock <john <at> johnmaddock.co.uk> writes:
Richard Webb wrote:
If you're looking at silencing warnings from Format, is there any chance you could look at http://svn.boost.org/trac/boost/ticket/1510 ? It can produce some pretty substantial warnings as well.
Hopefully now done.
Thanks for the change, but i'm now getting the same warning from a few lines down in the file: for(; i<sz && tmp_beg[i] == res[i-prefix_space]; ++i) {} Applying the same change to that line removes the warnings. Thanks for the effort, Richard Webb
Richard Webb wrote:
John Maddock <john <at> johnmaddock.co.uk> writes:
Richard Webb wrote:
If you're looking at silencing warnings from Format, is there any chance you could look at http://svn.boost.org/trac/boost/ticket/1510 ? It can produce some pretty substantial warnings as well.
Hopefully now done.
Thanks for the change, but i'm now getting the same warning from a few lines down in the file: for(; i<sz && tmp_beg[i] == res[i-prefix_space]; ++i) {}
Applying the same change to that line removes the warnings.
Grrr, these things go on and on! Hopefully #2 fixed this time, John.
participants (4)
-
"JOAQUIN LOPEZ MU?Z" -
John Maddock -
Richard Webb -
Sebastian Redl