Subject: Re: [boost] MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix
From: Damien Buhl (damien.buhl_at_[hidden])
Date: 2015-03-11 03:11:28
On 10/03/2015 14:05, Peter Dimov wrote:
> Damien Buhl wrote:
>> In all the test I ran I got no warning under VC++, but this was on a
>> pretty new version. And some of my test were run before 1.57.
> It probably depends on the VC++ version. 8.0 and 10.0 warn, 11.0 and
> 12.0 (I think) do not.
Yes that's for sure the point.
I'm just quoting the mail from Edward Diener from the other thread here,
so that we get a separate thread for this point.
On 10/03/2015 15:36, Edward Diener wrote:
> The BOOST_PP_IS_EMPTY macro is undocumented in Boost PP and therefore
> was not meant to be used outside the library. I actually changed it to
> be much more reliable when using variadic macros, but unfortunately that
> mean that VC++ puts out more spurious warning messages.
Oh sorry, I wouldn't have used it if I had known, I used it because it
was in the top-level include path aside other things I used ( i.e.
boost/preprocessor/facilities/is_empty.hpp), and therefore thought it
might be used. But I agree that I should have checked in the documentation.
I'll fix this, I can remove the check for emptiness, as I don't really
present it's usage in the doc. I documented that in the case the people
don't have BOOST_PP_VARIADICS, they can use BOOST_FUSION_ADAPT_AUTO
instead of the type. Like this :
// With BOOST_PP_VARIADICS support :
// Without BOOST_PP_VARIADICS support :
Both signatures works on BOOST_PP_VARIADICS enabled compilers. Actually
BOOST_FUSION_ADAPT_AUTO expands to BOOST_PP_EMPTY().
So I will change BOOST_FUSION_ADAPT_AUTO to some constant other than
emptiness and check if it equals. These should not provide any warning
anymore even on VC++ 8.0.
I should be able to have a fix this evening.
> Honestly just getting VC++ to work properly in Boost PP and VMD is hard
> enough. Fixing VC++ warning messages, when there is nothing wrong, is
> nearly impossible. I understand they are irritating but they are totally
> false also. They are part of VC++'s non-conformant C++ preprocessor.
I would also agree to live with the warnings in such old non-conformant
compilers, but as there is another way in my code, I'll use it, so that
it get better everywhere. :)