[msvc] #warning preprocessor directive
I find it very irritating that VC++ does not support #warning, and have opened a feature request: https://visualstudio.uservoice.com/forums/121579-visual-studio?query=Add%20C... The last time #warning was suggested it was rejected because not enough people voted for it. So please consider upvoting it on the above link. The lack of #warning affects Boost libraries in that developers avoid otherwise useful warnings because of the hassle for using an extension not supported by VC++. --Beman
On 10/17/17 15:10, Beman Dawes via Boost wrote:
I find it very irritating that VC++ does not support #warning, and have opened a feature request:
https://visualstudio.uservoice.com/forums/121579-visual-studio?query=Add%20C...
The last time #warning was suggested it was rejected because not enough people voted for it. So please consider upvoting it on the above link.
The lack of #warning affects Boost libraries in that developers avoid otherwise useful warnings because of the hassle for using an extension not supported by VC++.
#warning would be a non-standard preprocessor directive. I don't think such a non-standard extension is justified given that other compilers don't support it and that there is a more portable alternative "#pragma message".
On 10/17/2017 8:10 AM, Beman Dawes via Boost wrote:
I find it very irritating that VC++ does not support #warning, and have opened a feature request:
https://visualstudio.uservoice.com/forums/121579-visual-studio?query=Add%20C...
The last time #warning was suggested it was rejected because not enough people voted for it. So please consider upvoting it on the above link.
The lack of #warning affects Boost libraries in that developers avoid otherwise useful warnings because of the hassle for using an extension not supported by VC++.
Maybe someone could promote #warning as an official addition to the C++ standard ? I realize doing anything further with the C++ preprocessor may be seen as negative because C++ usually attempts de-emphasize the preprocessor, but adding #warning officially could hardly be controversial or complicated ( famous last words ). As for vc++ I find it a little amusing that we should ask them to add #warning to their preprocessor when their preprocessor is not standard conforming to begin with. Maybe, like congressman, we could tie the #warning "appropriations" to the general "bill" for creating a conformant preprocessor and submit it to Microsoft as a "congressional" demand <g>.
--Beman
On 10/17/17 16:14, Edward Diener via Boost wrote:
On 10/17/2017 8:10 AM, Beman Dawes via Boost wrote:
I find it very irritating that VC++ does not support #warning, and have opened a feature request:
https://visualstudio.uservoice.com/forums/121579-visual-studio?query=Add%20C...
The last time #warning was suggested it was rejected because not enough people voted for it. So please consider upvoting it on the above link.
The lack of #warning affects Boost libraries in that developers avoid otherwise useful warnings because of the hassle for using an extension not supported by VC++.
Maybe someone could promote #warning as an official addition to the C++ standard ?
I think, if it has to be in a standard, it should become part of C first.
On Tue, Oct 17, 2017 at 11:42 AM, Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 10/17/17 16:14, Edward Diener via Boost wrote:
Maybe someone could promote #warning as an official addition to the C++
standard ?
I think, if it has to be in a standard, it should become part of C first.
Nowadays there is tighter liaison between the C and C++ committees, so if it gets proposed for C++ it will more-or-less automatically also get proposed for C. The C++ committee is really trying to get away from the preprocessor, so my guess is they would be more interested in Robert's static_warning suggestion, although they might want to recast even that as some sort of constexpr function. --Beman
On 10/17/17 9:10 AM, Beman Dawes via Boost wrote:
The C++ committee is really trying to get away from the preprocessor, so my guess is they would be more interested in Robert's static_warning suggestion, although they might want to recast even that as some sort of constexpr function.
Hmmm - the appeal to me of such a standards committee proposal would be the the fact that it's just a minor variation on static_assert. So hopefully the whole saga a standards effort might be reduced to something in scale to the modest nature of such a proposal. (of course this is a pipe dream). But if someone want's to much around with it- as someone will, it could implement as some sort of optional argument to static_assert which of course opens up the field to all sorts of mischief. In the meantime, I would love to see someone come up with a useful implementation of BOOST_STATIC_WARNING. Robert Ramey
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
Hmmm - the appeal to me of such a standards committee proposal would be the the fact that it's just a minor variation on static_assert.
Traditionally, the standard doesn't specify any warnings. It only distinguishes between three types of programs: - ill-formed, diagnostic required - ill-formed, no diagnostic required - well-formed although now that there's precedent for a construct whose purpose is to emit warnings, namely, the 'deprecated' attribute, the committee may be willing to consider including something like static_warning.
On 10/17/2017 12:10 PM, Beman Dawes via Boost wrote:
On Tue, Oct 17, 2017 at 11:42 AM, Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 10/17/17 16:14, Edward Diener via Boost wrote:
Maybe someone could promote #warning as an official addition to the C++
standard ?
I think, if it has to be in a standard, it should become part of C first.
Nowadays there is tighter liaison between the C and C++ committees, so if it gets proposed for C++ it will more-or-less automatically also get proposed for C.
The C++ committee is really trying to get away from the preprocessor, so my guess is they would be more interested in Robert's static_warning suggestion, although they might want to recast even that as some sort of constexpr function.
There is an obvious difference between a preprocessor #warning and a static_warning. I have not used #warning in gcc, but since it is a preprocessor warning I assume it can only be created as part of preprocessor logic, ie. #if something #warning message #endif etc, and on to more complicated things in libraries like boost pp or vmd. Whereas a static_warning can occur in template code, constexpr code, and anything else determined purely at compile time.
--Beman
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev via Boost Sent: 17 October 2017 16:43 To: boost@lists.boost.org Cc: Andrey Semashev Subject: Re: [boost] [msvc] #warning preprocessor directive
On 10/17/17 16:14, Edward Diener via Boost wrote:
On 10/17/2017 8:10 AM, Beman Dawes via Boost wrote:
I find it very irritating that VC++ does not support #warning, and have opened a feature request:
https://visualstudio.uservoice.com/forums/121579-visual- studio?query=Add%20C%2FC%2B%2B%20%23warning%20preprocessor%20directive
The last time #warning was suggested it was rejected because not enough people voted for it. So please consider upvoting it on the above link.
The lack of #warning affects Boost libraries in that developers avoid otherwise useful warnings because of the hassle for using an extension not supported by VC++.
Maybe someone could promote #warning as an official addition to the C++ standard ?
I think, if it has to be in a standard, it should become part of C first.
In my experience, that would put it off forever :-( Paul
On 10/17/17 5:10 AM, Beman Dawes via Boost wrote:
I find it very irritating that VC++ does not support #warning, and have opened a feature request:
https://visualstudio.uservoice.com/forums/121579-visual-studio?query=Add%20C...
The last time #warning was suggested it was rejected because not enough people voted for it. So please consider upvoting it on the above link.
The lack of #warning affects Boost libraries in that developers avoid otherwise useful warnings because of the hassle for using an extension not supported by VC++.
personally I don't see any difference between #warning and the already existing and portable #pragma message - which is what I use on a regular basis. What I have always wanted is the equivalent of static_warning(condition, message). Of course this would be like static_assert except that it wouldn't be an error. The need for this comes up when I can detect at compile time that something is likely not what the user intended, but is not necessarily wrong. One example of this would be an attempt to serialize some data type via a non const reference. This would work, but it leaves open that possibility that the users serialize functions alter the data being serialized, which would break the presumptions made by the serialization library. Robert Ramey
Robert Ramey wrote:
personally I don't see any difference between #warning and the already existing and portable #pragma message - which is what I use on a regular basis.
`#pragma message("foo")` results in the following output: foo and shows nothing in the IDE warning list. So you either don't see it, or if you do, you have no clue where did it come from. `#warning foo` would result in the following output: source_file(source_line): warning C7563: #warning foo which would then be shown as a warning in the IDE.
On 10/17/17 18:59, Peter Dimov via Boost wrote:
Robert Ramey wrote:
personally I don't see any difference between #warning and the already existing and portable #pragma message - which is what I use on a regular basis.
`#pragma message("foo")` results in the following output:
foo
and shows nothing in the IDE warning list. So you either don't see it, or if you do, you have no clue where did it come from.
This is QoI. Gcc does produce this message: 1.cpp:1:22: note: #pragma message: foo #pragma message("foo") ^ The source file and position are present in the message.
On 10/17/17 19:15, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
This is QoI. Gcc does produce this message:
1.cpp:1:22: note: #pragma message: foo #pragma message("foo") ^
We're talking about MSVC here though.
The fact that a particular compiler does not produce enough information in its output is not the reason to ask for a new preprocessor directive noone else supports. If anything, it is the reason to ask the compiler vendor to improve output in this case.
Andrey Semashev wrote:
The fact that a particular compiler does not produce enough information in its output is not the reason to ask for a new preprocessor directive...
"Let's add #warning to MSVC" "Why? Use #pragma message" "#pragma message is not as good on MSVC because..." "It's fine for me on non-MSVC" "..."
... noone else supports.
Hello? #warning is a GCC directive. https://gcc.gnu.org/onlinedocs/cpp/Diagnostics.html
On 10/17/17 19:31, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
The fact that a particular compiler does not produce enough information in its output is not the reason to ask for a new preprocessor directive...
"Let's add #warning to MSVC" "Why? Use #pragma message" "#pragma message is not as good on MSVC because..." "It's fine for me on non-MSVC"
"...and #pragmas are the intended way to extend preprocessor" So, yes, I stand by my opinion. Use "#pragma message", improve MSVC. Or standardize "#warning" both in C and C++ and _then_ ask compiler vendors to support the standard feature. Do *not* ask to support non-standard "#warning" in MSVC and then sprinkle #ifdefs around the code to support this new directive on some compilers and "#pragma message" on others.
... noone else supports.
Hello? #warning is a GCC directive.
Hm, I didn't know it was supported by gcc.
Andrey Semashev wrote:
Hm, I didn't know it was supported by gcc.
It was invented by GCC if I'm not mistaken, and is already close to de-facto standard, if not for MSVC. So it makes sense to include support for it in MSVC as well.
On Tue, Oct 17, 2017 at 11:59 AM, Peter Dimov via Boost < boost@lists.boost.org> wrote:
Robert Ramey wrote:
personally I don't see any difference between #warning and the already existing and portable #pragma message - which is what I use on a regular basis.
`#pragma message("foo")` results in the following output:
foo
and shows nothing in the IDE warning list. So you either don't see it, or if you do, you have no clue where did it come from.
`#warning foo` would result in the following output:
source_file(source_line): warning C7563: #warning foo
which would then be shown as a warning in the IDE.
Yes, that's what make #warning more attractive.
There is a hack on Stackoverflow https://stackoverflow.com/questions/5966594 to use a macro cascade to solve the problem. --Beman
Beman Dawes wrote:
There is a hack on Stackoverflow https://stackoverflow.com/questions/5966594 to use a macro cascade to solve the problem.
Yes, one can always use #define STR(x) STR2(x) #define STR2(x) #x #pragma message( __FILE__ "(" STR(__LINE__) "): warning: " "#warning foo" ) or even #define BOOST_MESSAGE(msg) message( __FILE__ "(" STR(__LINE__) "): warning: " "#warning " #msg ) #pragma BOOST_MESSAGE(foo) but that's not the point, is it. :-)
On Tue, Oct 17, 2017 at 11:30 AM, Robert Ramey via Boost < boost@lists.boost.org> wrote: ...
What I have always wanted is the equivalent of static_warning(condition, message). Of course this would be like static_assert except that it wouldn't be an error. The need for this comes up when I can detect at compile time that something is likely not what the user intended, but is not necessarily wrong. One example of this would be an attempt to serialize some data type via a non const reference. This would work, but it leaves open that possibility that the users serialize functions alter the data being serialized, which would break the presumptions made by the serialization library.
That thought occurred to me after I posted the original message, so you are way ahead of me:-) --Beman
On 10/17/17 9:04 AM, Beman Dawes via Boost wrote:
On Tue, Oct 17, 2017 at 11:30 AM, Robert Ramey via Boost < boost@lists.boost.org> wrote: ...
What I have always wanted is the equivalent of static_warning(condition, message). Of course this would be like static_assert except that it wouldn't be an error. The need for this comes up when I can detect at compile time that something is likely not what the user intended, but is not necessarily wrong. One example of this would be an attempt to serialize some data type via a non const reference. This would work, but it leaves open that possibility that the users serialize functions alter the data being serialized, which would break the presumptions made by the serialization library.
That thought occurred to me after I posted the original message, so you are way ahead of me:-)
FYI - I made multiple attempts to implement BOOST_STATIC_WARNING as a element in the boost serialization library similar to BOOST_STATIC_ASSERT. They had occasional limited success but depended on specific compiler behavior.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (6)
-
Andrey Semashev -
Beman Dawes -
Edward Diener -
Paul A. Bristow -
Peter Dimov -
Robert Ramey