[boost] [msvc] #warning preprocessor directive

[Beman Dawes via Boost]

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++.

--Beman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Andrey Semashev via Boost]

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%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++.

#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".

[Edward Diener via Boost]

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 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>.

[Robert Ramey via Boost]

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%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++.

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

[Andrey Semashev via Boost]

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.

[Peter Dimov via Boost]

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.

[Beman Dawes via Boost]

On Tue, Oct 17, 2017 at 11:30 AM, Robert Ramey via Boost <
bo...@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

[Andrey Semashev via Boost]

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.

[Beman Dawes via Boost]

On Tue, Oct 17, 2017 at 11:42 AM, Andrey Semashev via Boost <
bo...@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

[Peter Dimov via Boost]

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.

[Beman Dawes via Boost]

On Tue, Oct 17, 2017 at 11:59 AM, Peter Dimov via Boost <
bo...@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

[Robert Ramey via Boost]

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 <
> bo...@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.

[Peter Dimov via Boost]

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. :-)

[Andrey Semashev via Boost]

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.

[Peter Dimov via Boost]

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

[Robert Ramey via Boost]

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

[Andrey Semashev via Boost]

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.
>
> https://gcc.gnu.org/onlinedocs/cpp/Diagnostics.html

Hm, I didn't know it was supported by gcc.

[Peter Dimov via Boost]

Andrey Semashev wrote:

> > https://gcc.gnu.org/onlinedocs/cpp/Diagnostics.html
>
> 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.

[Peter Dimov via 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.

[Edward Diener via Boost]

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 <
> bo...@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.

[Paul A. Bristow via Boost]

> -----Original Message-----
> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of Andrey Semashev via Boost
> Sent: 17 October 2017 16:43
> To: bo...@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