Topic: static_warning
Author: gmisocpp@gmail.com
Date: Wed, 27 Aug 2014 14:46:03 -0700 (PDT)
Raw View
------=_Part_3188_976662427.1409175963219
Content-Type: text/plain; charset=UTF-8
There seems to be know standard way of issuing a warning with
the expectation that compilation will continue.
We have #warning but it isn't standard.
We have static_assert but it always stops compilation.
What about making #warning standard, or introducing static_warning that
works like static_assert but doesn't stop compilation.
Or an additional default parameter to static_assert that determines if
compilation should continue or not - the default being that compilation
stops..
There is a reasonable amount of code that uses #warning on the theory that
it is standard because most compilers do support it, but msvc is one that
doesn't and the work around isn't pretty and often leads to more warnings
on other platforms or clouds the intended warning.
Use case might be something like:
#if defined(__GLIBCXX__)
do_whatever();
#elif defined(_MSC_VER)
do_something_else();
#else
#warning "Default implementation might not be suitable for your platform,
please check"
//OR: static_warning("Default implementation might not be suitable for your
platform, please check");
//OR: static_assert(false, "Default implementation might not be suitable
for your platform, please check",. true); // continue compilation
take_a_punt();
#endif
Providing all of the above might even make sense.
However we go about it, it seems the value of a #warning type feature is
useful - most compilers support it - but their is no standard way to invoke
it.
Thanks
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3188_976662427.1409175963219
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>There seems to be know standard way of issuing a warn=
ing with the expectation that compilation will continue.</di=
v><div><br></div><div>We have #warning but it isn't standard.</div><div>We =
have static_assert but it always stops compilation.</div><div><br></div><di=
v>What about making #warning standard, or introducing static_warn=
ing that works like static_assert but doesn't stop compilation.</div><div>O=
r an additional default parameter to static_assert that determine=
s if compilation should continue or not - the default being that =
compilation stops..</div><div><br></div><div>There is a reasonable amo=
unt of code that uses #warning on the theory that it is standard =
because most compilers do support it, but msvc is one that doesn't and the =
work around isn't pretty and often leads to more warnings on other platform=
s or clouds the intended warning.</div><div><br></div><div>Use case mi=
ght be something like:</div><div>#if defined(__GLIBCXX__)</div>=
<div>do_whatever();</div><div><br></div><div>#elif defined(_MSC_VER)</div><=
div>do_something_else();</div><div><br></div><div>#else</div><div><div>#war=
ning "Default implementation might not be suitable for your platform, pleas=
e check"</div><div>//OR: static_warning("Default implementation might not b=
e suitable for your platform, please check");</div></div><div><div>//OR: st=
atic_assert(false, "Default implementation might not be suitable for your p=
latform, please check",. true); // continue compilation</div><div><br></div=
>take_a_punt();</div><div>#endif</div><div><br></div><div><br></div><div>Pr=
oviding all of the above might even make sense.</div><div><br></div><d=
iv>However we go about it, it seems the value of a #warning type =
feature is useful - most compilers support it - but their is no standa=
rd way to invoke it.</div><div><br></div><div>Thanks</div><div><br></div></=
div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3188_976662427.1409175963219--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 28 Aug 2014 11:23:16 +0800
Raw View
--Apple-Mail=_B095FCB0-66BA-41AF-AE3B-BCD01B068640
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-28, at 5:46 AM, gmisocpp@gmail.com wrote:
> There seems to be know standard way of issuing a warning with the expecta=
tion that compilation will continue.
>=20
> We have #warning but it isn't standard.
> We have static_assert but it always stops compilation.
static_assert only makes the program ill-formed, but an ill-formed program =
may still be used to generate an executable, as long as a diagnostic is iss=
ued. I've not seen any compiler terminate itself at a static_assert. The co=
mmon practice is to continue analysis as with any other error.
Adding an attribute-specificier-seqopt to static_assert-declaration would a=
llow a conforming extension [[warning]] so assertion doesn't preclude gener=
ation of an executable.
Most programmers prefer that a successful build should not generate warning=
s, going so far as to use -Werror. Programs that always generate warnings e=
ven during normal compilation are troublesome.
> #else
> #warning "Default implementation might not be suitable for your platform,=
please check"
A program like this should provide the user with a means to disable the war=
ning, such as by a #define IS_SUPPORTED, or constexpr bool is_supported =3D=
true; after checking their platform. I'd see such a "may not be suitable" =
message as a constant reminder to stop using that library.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_B095FCB0-66BA-41AF-AE3B-BCD01B068640
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–28, at 5:46 AM, <a href=3D"mailto:gmisocpp@gmail.com">gmisoc=
pp@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><block=
quote type=3D"cite"><div dir=3D"ltr"><div>There seems to be know standard w=
ay of issuing a warning with the expectation that compilatio=
n will continue.</div><div><br></div><div>We have #warning but it isn't sta=
ndard.</div><div>We have static_assert but it always stops compilation.</di=
v></div></blockquote><div><br></div><div><font face=3D"Courier">static_asse=
rt</font> only makes the program ill-formed, but an ill-formed program may =
still be used to generate an executable, as long as a diagnostic is issued.=
I’ve not seen any compiler terminate itself at a <font face=3D"Couri=
er">static_assert</font>. The common practice is to continue analysis as wi=
th any other error.</div><div><br></div><div>Adding an <i>attribute-specifi=
cier-seq<font size=3D"1">opt</font></i> to <i>static_assert-declaration</i>=
would allow a conforming extension <font face=3D"Courier">[[warning]]=
</font> so assertion doesn’t preclude generation of an executabl=
e.</div><div><br></div><div>Most programmers prefer that a successful build=
should not generate warnings, going so far as to use <font face=3D"Co=
urier">-Werror</font>. Programs that always generate warnings even during n=
ormal compilation are troublesome.</div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div>#else</div><div><div>#warning "Default implementation migh=
t not be suitable for your platform, please check”</div></div></div><=
/blockquote><br></div><div>A program like this should provide the user with=
a means to disable the warning, such as by a <font face=3D"Courier">#defin=
e IS_SUPPORTED</font>, or <font face=3D"Courier">constexpr bool is_supporte=
d =3D true;</font> after checking their platform. I’d see such a &ldq=
uo;may not be suitable” message as a constant reminder to stop using =
that library.</div><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_B095FCB0-66BA-41AF-AE3B-BCD01B068640--
.
Author: gmisocpp@gmail.com
Date: Thu, 28 Aug 2014 14:30:56 -0700 (PDT)
Raw View
------=_Part_76_1255044658.1409261456624
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Sorry I messed my first post right up. I'll try again.
On Thursday, August 28, 2014 3:23:29 PM UTC+12, David Krauss wrote:
>
> On 2014=E2=80=9308=E2=80=9328, at 5:46 AM, gmis...@gmail.com <javascript:=
> wrote:
>
> There seems to be know standard way of issuing a warning with=20
> the expectation that compilation will continue.
>
> We have #warning but it isn't standard.
> We have static_assert but it always stops compilation.
>
>
> static_assert only makes the program ill-formed, but an ill-formed=20
> program may still be used to generate an executable, as long as a=20
> diagnostic is issued. I=E2=80=99ve not seen any compiler terminate itself=
at a=20
> static_assert. The common practice is to continue analysis as with any=20
> other error.
>
> Adding an *attribute-specificier-seqopt* to *static_assert-declaration* w=
ould=20
> allow a conforming extension [[warning]] so assertion doesn=E2=80=99t pre=
clude=20
> generation of an executable.
>
> Most programmers prefer that a successful build should not generate=20
> warnings, going so far as to use -Werror. Programs that always generate=
=20
> warnings even during normal compilation are troublesome.
>
> #else
> #warning "Default implementation might not be suitable for your platform,=
=20
> please check=E2=80=9D
>
>
> A program like this should provide the user with a means to disable the=
=20
> warning, such as by a #define IS_SUPPORTED, or constexpr bool=20
> is_supported =3D true; after checking their platform. I=E2=80=99d see suc=
h a =E2=80=9Cmay=20
> not be suitable=E2=80=9D message as a constant reminder to stop using tha=
t library.
>
>
Agreed. But the situation I want to improve on is today people are #warning=
=20
because they are finding it useful but getting non standard code they think=
=20
is standard because the feature is so widely available but not fully.
If we can improve on that situation by making a=20
standard #warning/#error/#message facility that addresses the basic need=20
plus provides override flexibility that would be the goal.
What I see is:
1. "#warning" issues a warning message, and in expected situations (being=
=20
intentionally vague here) it typically results in an executable being=20
produced.
2. In contrast, static_assert(false,"oops") issues an error message that=20
in expected situations typically results in an executable NOT being=20
produced.
I feel there is value in having the ability to perform aspect 1 above and=
=20
so I'd like it standardized. That's my goal.
I think aspect 2 above is fine, but not enough.
"#warning" is the most common way of doing aspect 1. and most compilers I=
=20
know of provide it but notably not msvc.
so if #warning could be made standard, more code would work "as is" so this=
=20
might be a way to go for that reason.
But:
we could perhaps enhance static_assert to provide the ability of 1. That=20
might give more flexibility.
OR maybe introducing static_warning is the way.
There may be a case for all of the above they all have some virtue. People=
=20
can debate any of these possibilities and we can see what pans out.
But I definitely think the ability to state an=20
error/warning/info message and suggest the desirability of executable=20
production in a way that could be overridden is something I'd like to see.=
=20
static_assert is to strong and #warning isn't standard or flexible enough.
But my primary goal is give people who use #warning/#pragma message a=20
standard way to achieve what they can do today.
If we can improve on the limitations of #warning, that'd be great.
static_assert works well in macros for example. It'd be nice to get=20
#warning to that space, for example.
I like the default error message aspect of static_assert too.
I can imagine using an enhanced static_assert static_message or=20
static_warning to debug some #if/#else logic paths for example.
#if WHATEVER
#else
static_assert(false, "Huh, we take this path", INFO); // remove me I am=20
just debugging.
#endif
OR
void lift_off()
#if MSVC
do_something();
#else
static_assert(false, "Warning don't press the ignition button in testing=20
this app. It's not implemented yet on this platform.", WARNING);
// Still want .exe produced.
#endif
Having some ability to direct the applicability of the action/message based=
=20
on a constexpr bool parameter would seem desirable
The aim would be to not require macros to direct the applicability of=20
the message/action or needing a static_if to direct such things either but=
=20
still be able to use the facility in a macro easily.
Anyway, if there's any doubt of the basic goal of what I'm trying to=20
do, lookup #warning and start there.
stackoverflow will show you that people are often trying to use this=20
feature and are being surprised it is non standard and the workarounds are=
=20
pretty ugly.
If we can standardize #warning so that makes code out their standard, or=20
provide a better alternative as a migration path that takes some of the=20
things that were mentioned above into account here, I think that's=20
something worth considering, that's the goal
Thanks.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_76_1255044658.1409261456624
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Sorry I messed my first post right up. I'll=
try again.</div><div><br>On Thursday, August 28, 2014 3:23:29 PM UTC+12, D=
avid Krauss wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;"><div style=3D"-ms-word=
-wrap: break-word;"><br><div><div>On 2014=E2=80=9308=E2=80=9328, at 5:46 AM=
, <a onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;" href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"bKeJKBZf_dYJ">gmis...@gmail.com</a> wrote:</div><b=
r><blockquote type=3D"cite"><div dir=3D"ltr"><div>There seems to be know st=
andard way of issuing a warning with the expectation that co=
mpilation will continue.</div><div><br></div><div>We have #warning but it i=
sn't standard.</div><div>We have static_assert but it always stops compilat=
ion.</div></div></blockquote><div><br></div><div><font face=3D"Courier">sta=
tic_assert</font> only makes the program ill-formed, but an ill-formed prog=
ram may still be used to generate an executable, as long as a diagnostic is=
issued. I=E2=80=99ve not seen any compiler terminate itself at a <font fac=
e=3D"Courier">static_assert</font>. The common practice is to continue anal=
ysis as with any other error.</div><div><br></div><div>Adding an <i>attribu=
te-specificier-seq<font size=3D"1">opt</font></i> to <i>static_assert-decla=
ration</i> <wbr>would allow a conforming extension <font face=3D"Couri=
er">[[warning]]</font> so assertion doesn=E2=80=99t preclude generatio=
n of an executable.</div><div><br></div><div>Most programmers prefer that a=
successful build should not generate warnings, going so far as to use =
;<font face=3D"Courier">-Werror</font>. Programs that always generate warni=
ngs even during normal compilation are troublesome.</div><br><blockquote ty=
pe=3D"cite"><div dir=3D"ltr"><div>#else</div><div><div>#warning "Default im=
plementation might not be suitable for your platform, please check=E2=80=9D=
</div></div></div></blockquote><br></div><div>A program like this should pr=
ovide the user with a means to disable the warning, such as by a <font face=
=3D"Courier">#define IS_SUPPORTED</font>, or <font face=3D"Courier">constex=
pr bool is_supported =3D true;</font> after checking their platform. I=E2=
=80=99d see such a =E2=80=9Cmay not be suitable=E2=80=9D message as a const=
ant reminder to stop using that library.</div><br></div></blockquote><div><=
br></div><div>Agreed. But the situation I want to improve on is today&=
nbsp;people are #warning because they are finding it useful but g=
etting non standard code they think is standard because the feature is so w=
idely available but not fully.</div><div><br></div><div>If we can improve o=
n that situation by making a standard #warning/#error/#message facilit=
y that addresses the basic need plus provides override flexibility tha=
t would be the goal.</div><div><br></div><div>What I see is:</div><div><br>=
</div><div>1. "#warning" issues a warning message, and in expecte=
d situations (being intentionally vague here) it typically results in =
an executable being produced.</div><div>2. In contrast, static_as=
sert(false,"oops") issues an error message that in expected situa=
tions typically results in an executable NOT being produced.</div><div=
><br></div><div>I feel there is value in having the ability to pe=
rform aspect 1 above and so I'd like it standardized. That's my goal.<=
/div><div>I think aspect 2 above is fine, but not enough.</div><div><br></d=
iv><div>"#warning" is the most common way of doing aspect 1. and=
most compilers I know of provide it but notably not msvc.</div><=
div>so if #warning could be made standard, more code would work "as is" so =
this might be a way to go for that reason.</div><div><br></div><div>Bu=
t:</div><div><br></div><div>we could perhaps enhance static_assert to provi=
de the ability of 1. That might give more flexibility.</div><div><br></div>=
<div>OR maybe introducing static_warning is the way.</div><div><br></d=
iv><div>There may be a case for all of the above they all have some vi=
rtue. People can debate any of these possibilities and we can see=
what pans out.</div><div><br></div><div>But I definitely think t=
he ability to state an error/warning/info message and sugges=
t the desirability of executable production in a way that could be overridd=
en is something I'd like to see. static_assert is to strong and #warn=
ing isn't standard or flexible enough.</div><div><br></div><div>But my prim=
ary goal is give people who use #warning/#pragma message a s=
tandard way to achieve what they can do today.</div><div><br></div><div>If =
we can improve on the limitations of #warning, that'd be gre=
at.</div><div><br></div><div>static_assert works well in macros for example=
.. It'd be nice to get #warning to that space, for example.</div><div>I like=
the default error message aspect of static_assert too.</div><div><br></div=
><div>I can imagine using an enhanced static_assert static_message or=
static_warning to debug some #if/#else logic paths for exam=
ple.</div><div>#if WHATEVER</div><div>#else</div><div>static_assert(false, =
"Huh, we take this path", INFO); // remove me I am just debugging.</div><di=
v>#endif</div><div><br></div><div>OR</div><div><br></div><div>void lift_off=
()</div><div>#if MSVC</div><div>do_something();</div><div>#else</div><div>s=
tatic_assert(false, "Warning don't press the ignition button in testing thi=
s app. It's not implemented yet on this platform.", WARNING);</div><div>// =
Still want .exe produced.</div><div>#endif</div><div><br></div><div><br></d=
iv><div>Having some ability to direct the applicability of the ac=
tion/message based on a constexpr bool parameter would seem desirable</div>=
<div>The aim would be to not require macros to direct t=
he applicability of the message/action or needing a static_i=
f to direct such things either but still be able to use the facility in a m=
acro easily.</div><div><br></div><div>Anyway, if there's any doubt of the b=
asic goal of what I'm trying to do, lookup #warning and start there.</=
div><div>stackoverflow will show you that people are often trying to u=
se this feature and are being surprised it is non standard and the workarou=
nds are pretty ugly.</div><div><br></div><div>If we can standardize&nb=
sp;#warning so that makes code out their standard, or provide a better alte=
rnative as a migration path that takes some of the things th=
at were mentioned above into account here, I think that's somethi=
ng worth considering, that's the goal</div><div><br></div><div>Thanks.</div=
></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_76_1255044658.1409261456624--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 29 Aug 2014 13:56:09 -0400
Raw View
--001a113467f4373dfc0501c85e73
Content-Type: text/plain; charset=UTF-8
On Wed, Aug 27, 2014 at 5:46 PM, <gmisocpp@gmail.com> wrote:
> There seems to be know standard way of issuing a warning with
> the expectation that compilation will continue.
>
> We have #warning but it isn't standard.
> We have static_assert but it always stops compilation.
>
> What about making #warning standard, or introducing static_warning that
> works like static_assert but doesn't stop compilation.
> Or an additional default parameter to static_assert that determines if
> compilation should continue or not - the default being that compilation
> stops..
>
> There is a reasonable amount of code that uses #warning on the theory that
> it is standard because most compilers do support it, but msvc is one that
> doesn't and the work around isn't pretty and often leads to more warnings
> on other platforms or clouds the intended warning.
>
> Use case might be something like:
> #if defined(__GLIBCXX__)
> do_whatever();
>
> #elif defined(_MSC_VER)
> do_something_else();
>
> #else
> #warning "Default implementation might not be suitable for your platform,
> please check"
> //OR: static_warning("Default implementation might not be suitable for
> your platform, please check");
> //OR: static_assert(false, "Default implementation might not be suitable
> for your platform, please check",. true); // continue compilation
>
> take_a_punt();
> #endif
>
>
> Providing all of the above might even make sense.
>
> However we go about it, it seems the value of a #warning type feature is
> useful - most compilers support it - but their is no standard way to invoke
> it.
>
> Thanks
>
>
There is nothing stopping you from writing a static_warning similar to how
boost wrote BOOST_STATIC_ASSERT. And then, once you have something
working, propose it to boost and/or the committee.
The big question would be what level or warning - or do I get to decide?
Considering that warnings, of any kind, are outside the standard, it might
be hard to get this beyond boost-level.
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113467f4373dfc0501c85e73
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Aug 27, 2014 at 5:46 PM, <span dir=3D"ltr"><<a href=3D"=
mailto:gmisocpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>></sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>There seems to be know=
standard way of issuing a warning=C2=A0with the=C2=A0expectation that=C2=
=A0compilation will continue.</div>
<div><br></div><div>We have #warning but it isn't standard.</div><div>W=
e have static_assert but it always stops compilation.</div><div><br></div><=
div>What about making #warning=C2=A0standard, or introducing=C2=A0static_wa=
rning that works like static_assert but doesn't stop compilation.</div>
<div>Or an additional=C2=A0default parameter to static_assert that=C2=A0det=
ermines if compilation=C2=A0should continue or not - the default being that=
=C2=A0compilation stops..</div><div><br></div><div>There is=C2=A0a reasonab=
le amount of code that uses #warning on the=C2=A0theory that it is=C2=A0sta=
ndard because most compilers do support it, but msvc is one that doesn'=
t and the work around isn't pretty and often leads to more warnings on =
other platforms=C2=A0or clouds the intended warning.</div>
<div><br></div><div>Use case might=C2=A0 be something=C2=A0 like:</div><div=
>#if defined(__GLIBCXX__)</div><div>do_whatever();</div><div><br></div><div=
>#elif defined(_MSC_VER)</div><div>do_something_else();</div><div><br></div=
><div>
#else</div><div><div>#warning "Default implementation might not be sui=
table for your platform, please check"</div><div>//OR: static_warning(=
"Default implementation might not be suitable for your platform, pleas=
e check");</div>
</div><div><div>//OR: static_assert(false, "Default implementation mig=
ht not be suitable for your platform, please check",. true); // contin=
ue compilation</div><div><br></div>take_a_punt();</div><div>#endif</div>
<div><br></div><div><br></div><div>Providing=C2=A0all of the above might ev=
en make sense.</div><div><br></div><div>However we go about it, it seems th=
e=C2=A0value=C2=A0of a #warning type feature is useful -=C2=A0most compiler=
s support it - but their is no standard way to invoke it.</div>
<div><br></div><div>Thanks</div><span class=3D"HOEnZb"></span><br></div></b=
lockquote></div><br><br></div><div class=3D"gmail_extra">There is nothing s=
topping you from writing a static_warning similar to how boost wrote BOOST_=
STATIC_ASSERT.=C2=A0 And then, once you have something working, propose it =
to boost and/or the committee.<br>
<br></div><div class=3D"gmail_extra">The big question would be what level o=
r warning - or do I get to decide?<br><br>Considering that warnings, of any=
kind, are outside the standard, it might be hard to get this beyond boost-=
level.<br>
<br>Tony<br><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113467f4373dfc0501c85e73--
.
Author: gmisocpp@gmail.com
Date: Fri, 29 Aug 2014 14:05:30 -0700 (PDT)
Raw View
------=_Part_1439_1654004815.1409346330486
Content-Type: text/plain; charset=UTF-8
Hi Tony
On Saturday, August 30, 2014 5:56:11 AM UTC+12, Tony V E wrote:
>
>
> There is nothing stopping you from writing a static_warning similar to how
> boost wrote BOOST_STATIC_ASSERT. And then, once you have something
> working, propose it to boost and/or the committee.
>
> The big question would be what level or warning - or do I get to decide?
>
> Considering that warnings, of any kind, are outside the standard, it might
> be hard to get this beyond boost-level.
>
> Tony
>
Well one could propose putting boost's static assert into the standard but
I think we want something better than that, that isn't a macro as a
starting point.
I think what we need is something that works like how #warning works as a
starting point. It has reasonable definition on all compilers that
implement it and there's no reason why Microsoft couldn't enable something
that works similarly for their compiler.
We just don't make it a macro or #pre-processor thing.
So take that as a starting proposition and see how we can improve on it or
not. It seems a step forward to a) standardize something with exactly the
functionality of #warning then b) improve on it by not making it a macro
and c) whatever else we think improves it further.
If people can get motivated to discuss the idea at least on a) and b)
hopefully further improvement for c) will be revealed.
But #warning is clang and gcc implement it seems good, not as a macro
or #pre-processor thing i.e. #pragma.
That's the starting proposition. Who is up or that and what can be done to
improve things further is the other question.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1439_1654004815.1409346330486
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Tony</div><div><br>On Saturday, August 30, 2014 5:=
56:11 AM UTC+12, Tony V E wrote:</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(=
204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><br><div><br></div><div>There is nothing stopping you from writing=
a static_warning similar to how boost wrote BOOST_STATIC_ASSERT. And=
then, once you have something working, propose it to boost and/or the comm=
ittee.<br>
<br></div><div>The big question would be what level or warning - or do I ge=
t to decide?<br><br>Considering that warnings, of any kind, are outside the=
standard, it might be hard to get this beyond boost-level.<br>
<br>Tony<br></div></div></blockquote><div><br></div><div>Well one could pro=
pose putting boost's static assert into the standard but I think we wa=
nt something better than that, that isn't a macro as a starting point.</div=
><div><br></div><div>I think what we need is something that works=
like how #warning works as a starting point. It has reasonable definition =
on all compilers that implement it and there's no reason why Microsoft coul=
dn't enable something that works similarly for their compiler.</div><div><b=
r></div><div>We just don't make it a macro or #pre-processor thing.</div><d=
iv><br></div><div>So take that as a starting proposition and see how we can=
improve on it or not. It seems a step forward to a) standardize somet=
hing with exactly the functionality of #warning then b) improve on it =
by not making it a macro and c) whatever else we think improves it further.=
</div><div><br></div><div>If people can get motivated to discuss the idea a=
t least on a) and b) hopefully further improvement for c) will be revealed.=
</div><div><br></div><div>But #warning is clang and gcc implement it seems =
good, not as a macro or #pre-processor thing i.e. #pragma.</=
div><div>That's the starting proposition. Who is up or that and what can be=
done to improve things further is the other question.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1439_1654004815.1409346330486--
.
Author: John Bytheway <jbytheway@gmail.com>
Date: Wed, 03 Sep 2014 23:35:13 -0400
Raw View
On 2014-08-29 13:56, Tony V E wrote:
<snip>
> There is nothing stopping you from writing a static_warning similar to
> how boost wrote BOOST_STATIC_ASSERT.
Or use the existing one:
<http://www.boost.org/doc/libs/1_56_0/libs/serialization/doc/static_warning.html>
> And then, once you have something
> working, propose it to boost and/or the committee.
>
> The big question would be what level or warning - or do I get to decide?
>
> Considering that warnings, of any kind, are outside the standard, it
> might be hard to get this beyond boost-level.
>
> Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: gmisocpp@gmail.com
Date: Wed, 3 Sep 2014 22:56:22 -0700 (PDT)
Raw View
------=_Part_6599_747796767.1409810182367
Content-Type: text/plain; charset=UTF-8
On Thursday, September 4, 2014 3:35:16 PM UTC+12, John Bytheway wrote:
>
> On 2014-08-29 13:56, Tony V E wrote:
>
> <snip>
>
> > There is nothing stopping you from writing a static_warning similar to
> > how boost wrote BOOST_STATIC_ASSERT.
>
> Or use the existing one:
>
I think this all misses the point, or perhaps makes the point. It's not
that we can't write one, it's that it isn't standard and it's fiddly and
ugly to produce.
The fact that boost has it, and libraries like libcxx also have it too etc.
indicates that it's useful and that each library shouldn't be rolling it's
own.
People seem to want it and use it:
http://embeddedgurus.com/stack-overflow/2011/09/effective-c-tip-9-%E2%80%93-use-warning/
Tbey have a variety of uses for it:
http://stackoverflow.com/questions/12637392/c-preprocessor-expand-macro-in-a-warning
Other languages seem to find it useful too (for those that need that type
of convincing) look C# felt the need to provide it:
http://msdn.microsoft.com/en-us/library/963th5x3.aspx
So the basic functionality that is required is clear and the use cases are
pretty clear.
It needs only to be made standard and slightly improved upon by virtue of
not being a macro etc.
If we don't, people will continue to try to roll their own and have
continue to have issues:
http://stackoverflow.com/questions/171435/portability-of-warning-preprocessor-directive
http://stackoverflow.com/questions/2298387/warning-and-macro-evaluation
http://forums.codeguru.com/showthread.php?309369-warning&p=1010948#post1010948
https://github.com/kentonv/capnproto/pull/79
There are various arguments for and against:
http://goodliffe.blogspot.co.nz/2009/07/c-how-to-say-warning-to-visual-studio-c.html
One use case is that if you write a load of code and chunks aren't
implemented yet, say for a particular platform, I.e. code is left with a
big hole.
#if _WIN32
win32();
#elif _APPLE_
apple();
#else
HeyYouNeedToWriteThis(); /// #warning you're our only hope.
#endif
You can throw some exception at runtime, but that isn't always what you
want.
You don't want to test every feature to find what you forgot to add by
hoping you've caught every NotImplemented exception or whatever and printed
a message at runtime.
You'd like to compile and see what's needed.
There are other use cases too it seems and even though their might
be better ways to get things done, lot's of people find this way simple and
intuitive.
Only to be bitten by finding out it isn't portable.
Who wants to write the kind of hacks that boost_static_warning requires
each time?.
And isn't boost supposed to be the playground for determining what is
useful and a candidate for standardisation. Well it has it.
So why not standardize it now?
Maybe we can also then use things like clang tidy or whatever to convert
our non portable #warning code into portable static_warning code, who knows.
But we can't deprecate features easily until we have valid alternatives for
them either, so give us static_warning and we get that.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_6599_747796767.1409810182367
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, September 4, 2014 3:35:16 PM UTC+12, =
John Bytheway wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid;">On 2014-08-29 13:56, Tony =
V E wrote:
<br>
<br><snip>
<br>
<br>> There is nothing stopping you from writing a static_warning simila=
r to
<br>> how boost wrote BOOST_STATIC_ASSERT.
<br>
<br>Or use the existing one:
<br></blockquote><div><br></div><div>I think this all misses the point, or =
perhaps makes the point. It's not that we can't write one, it's that it isn=
't standard and it's fiddly and ugly to produce.</div><div>The fact that bo=
ost has it, and libraries like libcxx also have it too etc. indicates that =
it's useful and that each library shouldn't be rolling it's own.</div><div>=
<br></div><div>People seem to want it and use it:</div><div><div><a href=3D=
"http://embeddedgurus.com/stack-overflow/2011/09/effective-c-tip-9-%E2%80%9=
3-use-warning/">http://embeddedgurus.com/stack-overflow/2011/09/effective-c=
-tip-9-%E2%80%93-use-warning/</a></div><div><br></div><div><div>Tbey have a=
variety of uses for it:</div><div><a href=3D"http://stackoverflow.com/ques=
tions/12637392/c-preprocessor-expand-macro-in-a-warning">http://stackoverfl=
ow.com/questions/12637392/c-preprocessor-expand-macro-in-a-warning</a></div=
></div></div><div><br></div><div>Other languages seem to find it useful too=
(for those that need that type of convincing) look C# felt =
the need to provide it:</div><div><a href=3D"http://msdn.microsoft.com=
/en-us/library/963th5x3.aspx">http://msdn.microsoft.com/en-us/library/963th=
5x3.aspx</a></div><div><br></div><div>So the basic functionality that is re=
quired is clear and the use cases are pretty clear.</div><div>It needs only=
to be made standard and slightly improved upon by virtue of not being a ma=
cro etc.</div><div><br></div><div>If we don't, people will continue to=
try to roll their own and have continue to have issues:</div><div><a href=
=3D"http://stackoverflow.com/questions/171435/portability-of-warning-prepro=
cessor-directive">http://stackoverflow.com/questions/171435/portability-of-=
warning-preprocessor-directive</a></div><div><a href=3D"http://stackoverflo=
w.com/questions/2298387/warning-and-macro-evaluation">http://stackoverflow.=
com/questions/2298387/warning-and-macro-evaluation</a></div><div><a href=3D=
"http://forums.codeguru.com/showthread.php?309369-warning&p=3D1010948#p=
ost1010948">http://forums.codeguru.com/showthread.php?309369-warning&p=
=3D1010948#post1010948</a></div><div><a href=3D"https://github.com/kentonv/=
capnproto/pull/79">https://github.com/kentonv/capnproto/pull/79</a></div><d=
iv><br></div><div>There are various arguments for and against:</div><div><a=
href=3D"http://goodliffe.blogspot.co.nz/2009/07/c-how-to-say-warning-to-vi=
sual-studio-c.html">http://goodliffe.blogspot.co.nz/2009/07/c-how-to-say-wa=
rning-to-visual-studio-c.html</a></div><div><br></div><div>One use case is =
that if you write a load of code and chunks aren't implemented yet, sa=
y for a particular platform, I.e. code is left with a big hole.</div><=
div>#if _WIN32</div><div>win32();</div><div>#elif _APPLE_</div><div>apple()=
;</div><div>#else</div><div>HeyYouNeedToWriteThis(); /// #warning you're ou=
r only hope.</div><div>#endif</div><div><br></div><div>You can throw some e=
xception at runtime, but that isn't always what you want.</div><div>You don=
't want to test every feature to find what you forgot to add by hoping you'=
ve caught every NotImplemented exception or whatever and printed a mes=
sage at runtime.</div><div>You'd like to compile and see what's needed.</di=
v><div>There are other use cases too it seems and even though their mi=
ght be better ways to get things done, lot's of people find this way s=
imple and intuitive.</div><div>Only to be bitten by finding out it isn't po=
rtable.</div><div><br></div><div>Who wants to write the kind of hacks that =
boost_static_warning requires each time?.</div><div>And isn't boost suppose=
d to be the playground for determining what is useful and a candidate for s=
tandardisation. Well it has it.</div><div><br></div><div>So why not standar=
dize it now?</div><div><br></div><div>Maybe we can also then use thing=
s like clang tidy or whatever to convert our non portable #warning cod=
e into portable static_warning code, who knows.</div><div>But we can't depr=
ecate features easily until we have valid alternatives for them either, so =
give us static_warning and we get that.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_6599_747796767.1409810182367--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 03 Sep 2014 22:59:44 -0700
Raw View
On Wednesday 03 September 2014 22:56:22 gmisocpp@gmail.com wrote:
> One use case is that if you write a load of code and chunks aren't
> implemented yet, say for a particular platform, I.e. code is left with a
> big hole.
> #if _WIN32
> win32();
> #elif _APPLE_
> apple();
> #else
> HeyYouNeedToWriteThis(); /// #warning you're our only hope.
> #endif
This is not a good example of #warning. This is an example of #error.
This code doesn't work. You need to implement the missing function.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: gmisocpp@gmail.com
Date: Thu, 4 Sep 2014 00:05:30 -0700 (PDT)
Raw View
------=_Part_42_623033779.1409814331119
Content-Type: text/plain; charset=UTF-8
On Thursday, September 4, 2014 5:59:51 PM UTC+12, Thiago Macieira wrote:
>
> On Wednesday 03 September 2014 22:56:22 gmis...@gmail.com <javascript:>
> wrote:
> > One use case is that if you write a load of code and chunks aren't
> > implemented yet, say for a particular platform, I.e. code is left with a
> > big hole.
> > #if _WIN32
> > win32();
> > #elif _APPLE_
> > apple();
> > #else
> > HeyYouNeedToWriteThis(); /// #warning you're our only hope.
> > #endif
>
> This is not a good example of #warning. This is an example of #error.
>
Well, yes and no, it perhaps wasn't the best example, but my point was that
you aren't always in a position to finish writing your application before
you want yourself or others to be able to test it.
And if you don't want always to prevent generation of the whole executable
and therefore eliminate any possible use of it, which #error would do
because one element of functionality is missing or unavailable.
And you don't want to lose track of what you haven't written yet or have to
have to exercise every element of your program to remind yourself what
still needs to be implemented either.
In the end gcc, clang, and intel etc, c-sharp, boost, and libcxx have found
static_warning type functionality useful and the links show other people
wanting to use it and having trouble doing so and everyone is
writing non-portable code to do this.
I think we should think very hard why we need them to have to do that? We
are here to standardize existing practice. Is this not existing and
sufficiently practiced now?
Have we better answers to all of these use cases. I haven't seen that yet.
> This code doesn't work. You need to implement the missing function.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_42_623033779.1409814331119
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, September 4, 2014 5:59:51 PM UTC+12, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;">On Wednesday 03 Septembe=
r 2014 22:56:22 <a onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"slgu8aFkAU0J">gmis...@gmail.com</a> =
wrote:
<br>> One use case is that if you write a load of code and chunks aren't=
=20
<br>> implemented yet, say for a particular platform, I.e. code is left =
with a=20
<br>> big hole.
<br>> #if _WIN32
<br>> win32();
<br>> #elif _APPLE_
<br>> apple();
<br>> #else
<br>> HeyYouNeedToWriteThis(); /// #warning you're our only hope.
<br>> #endif
<br>
<br>This is not a good example of #warning. This is an example of #error.
<br></blockquote><div><br></div><div>Well, yes and no, it perhaps wasn=
't the best example, but my point was that you aren't always in a position =
to finish writing your application before you want yourself or others to be=
able to test it.</div><div>And if you don't want always to prevent ge=
neration of the whole executable and therefore eliminate any possible use o=
f it, which #error would do because one element of functionality is missing=
or unavailable.</div><div>And you don't want to lose track of what you hav=
en't written yet or have to have to exercise every element of your pro=
gram to remind yourself what still needs to be implemented either.</di=
v><div><br></div><div>In the end gcc, clang, and intel etc, c-sharp, b=
oost, and libcxx have found static_warning type functionality useful&n=
bsp;and the links show other people wanting to use it and having trouble do=
ing so and everyone is writing non-portable code to do this.</div><div=
><br></div><div>I think we should think very hard why we need them to have =
to do that? We are here to standardize existing practice. Is this not exist=
ing and sufficiently practiced now?</div><div>Have we better answers to all=
of these use cases. I haven't seen that yet.</div><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: =
1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-=
left-style: solid;">
<br>This code doesn't work. You need to implement the missing function.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\07=
51\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" href=3D"http:/=
/macieira.info" target=3D"_blank">macieira.info</a> - thiago (AT) <a onmous=
edown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org\46=
sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;=
" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.or=
g\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return t=
rue;" href=3D"http://kde.org" target=3D"_blank">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_42_623033779.1409814331119--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 4 Sep 2014 07:49:42 -0700 (PDT)
Raw View
------=_Part_232_959608865.1409842182535
Content-Type: text/plain; charset=UTF-8
On Thursday, September 4, 2014 3:49:29 PM UTC+8, gmis...@gmail.com wrote:
>
> I'm happy to write up an initial proposal based on this starting
> proposition.
> I don't intend to present such a paper in person though so I would need
> someone interested in supporting me in that.
> Any further support beyond that, in this endeavour would be great too.
>
I'd get behind a static_log. The term "warning" implies some level of
danger, whereas the only acceptable level of danger is nil.
Tracing through templates without breaking anything is unnecessarily
tricky. I want a facility that simply makes a report or log of what
happened. Everyone knows that logs should never be seen by clients, except
maybe with an obscure diagnostic switch. Warnings on the other hand are
slightly ambiguous in that regard.
Perhaps one reason for the name of Boost static_warning is the fact that it
generates an artificial problem likely to reported as a warning on each
given platform. But warning of a minor problem isn't exactly the best
application, nor even possible under -Werror (unless they've found
something clever, which I suppose might just be beyond my imagination).
A facility specifically dedicated to logging might be more implementation
effort, since it represents a new form of compiler output, but low QOI
works for basic compliance (e.g., simply suppress logging under -Werror).
Any effort to make template instantiation logs usable would be very nice.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_232_959608865.1409842182535
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, September 4, 2014 3:49:29 PM UTC+8, g=
mis...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">I'm happy to write up an initial proposal based on this starting =
proposition.<div>I don't intend to present such a paper in person though&nb=
sp;so I would need someone interested in supporting me in that. <=
/div><div>Any further support beyond that, in this endeavour would be =
great too.</div></div></blockquote><div><br>I'd get behind a static_log. Th=
e term "warning" implies some level of danger, whereas the only acceptable =
level of danger is nil.<br><br>Tracing through templates without breaking a=
nything is unnecessarily tricky. I want a facility that simply makes a repo=
rt or log of what happened. Everyone knows that logs should never be seen b=
y clients, except maybe with an obscure diagnostic switch. Warnings on the =
other hand are slightly ambiguous in that regard.<br><br>Perhaps one reason=
for the name of Boost static_warning is the fact that
it generates an artificial problem likely to reported as a warning on=20
each given platform. But warning of a minor problem isn't exactly the best =
application, nor even possible under -Werror (unless they've found somethin=
g clever, which I suppose might just be beyond my imagination).<br><br>A fa=
cility specifically dedicated to logging might be more implementation effor=
t, since it represents a new form of compiler output, but low QOI works for=
basic compliance (e.g., simply suppress logging under -Werror). Any effort=
to make template instantiation logs usable would be very nice.<br><br></di=
v></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_232_959608865.1409842182535--
.
Author: gmisocpp@gmail.com
Date: Fri, 5 Sep 2014 00:23:19 -0700 (PDT)
Raw View
------=_Part_8217_226688012.1409901799450
Content-Type: text/plain; charset=UTF-8
HI
On Friday, September 5, 2014 2:49:43 AM UTC+12, David Krauss wrote:
>
>
> On Thursday, September 4, 2014 3:49:29 PM UTC+8, gmis...@gmail.com wrote:
>>
>> I'm happy to write up an initial proposal based on this starting
>> proposition.
>> I don't intend to present such a paper in person though so I would need
>> someone interested in supporting me in that.
>> Any further support beyond that, in this endeavour would be great too.
>>
>
> I'd get behind a static_log.
>
Cool. I've started writing up the issues for a draft proposal. I'll
post something more detailed in the next day or two then.
static_log or static_message seem reasonable.
> The term "warning" implies some level of danger, whereas the only
> acceptable level of danger is nil.
>
I think the issues are a little more than that, but not a big deal.
For instance, the claim there is that the danger is nil but most #warning
implementations put the word "Warning" in the message for you.
Right there is a tension to overcome when you want a message that is or
isn't a warning in your mind.
I don't think there's anything to troublesome to overcome though.
But I'll go into the options around this when I post something in the next
few days and everyone can lay into that then maybe.
>
> Tracing through templates without breaking anything is unnecessarily
> tricky. I want a facility that simply makes a report or log of what
> happened. Everyone knows that logs should never be seen by clients, except
> maybe with an obscure diagnostic switch. Warnings on the other hand are
> slightly ambiguous in that regard.
>
> Perhaps one reason for the name of Boost static_warning is the fact that
> it generates an artificial problem likely to reported as a warning on each
> given platform. But warning of a minor problem isn't exactly the best
> application, nor even possible under -Werror (unless they've found
> something clever, which I suppose might just be beyond my imagination).
>
> A facility specifically dedicated to logging might be more implementation
> effort, since it represents a new form of compiler output, but low QOI
> works for basic compliance (e.g., simply suppress logging under -Werror).
> Any effort to make template instantiation logs usable would be very nice.
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_8217_226688012.1409901799450
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>HI</div><div><br>On Friday, September 5, 2014 2:49:43=
AM UTC+12, David Krauss wrote:</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(2=
04, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><br><br>On Thursday, September 4, 2014 3:49:29 PM UTC+8, <a>gmis..=
..@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">I'm hap=
py to write up an initial proposal based on this starting proposition.<div>=
I don't intend to present such a paper in person though so I would nee=
d someone interested in supporting me in that. </div><div>Any fur=
ther support beyond that, in this endeavour would be great too.</div><=
/div></blockquote><div><br>I'd get behind a static_log. </div></div></block=
quote><div><br></div><div>Cool. I've started writing up the issues&nbs=
p;for a draft proposal. I'll post something more detailed in the next =
day or two then.</div><div><br></div><div>static_log or static_messag=
e seem reasonable.</div><div> </div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: r=
gb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div =
dir=3D"ltr"><div>The term "warning" implies some level of danger, whereas t=
he only acceptable level of danger is nil.<br></div></div></blockquote><div=
><br></div><div>I think the issues are a little more than that, but not a b=
ig deal.</div><div>For instance, the claim there is that the danger is=
nil but most #warning implementations put the word "Warning" in =
the message for you. </div><div>Right there is a tensi=
on to overcome when you want a message that is or isn't a warning in your m=
ind.</div><div>I don't think there's anything to troublesome to overcome th=
ough.</div><p>But I'll go into the options around this when I&nbs=
p;post something in the next few days and everyone can lay into that then m=
aybe.</p><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-w=
idth: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><br>Tracing thr=
ough templates without breaking anything is unnecessarily tricky. I want a =
facility that simply makes a report or log of what happened. Everyone knows=
that logs should never be seen by clients, except maybe with an obscure di=
agnostic switch. Warnings on the other hand are slightly ambiguous in that =
regard.<br><br>Perhaps one reason for the name of Boost static_warning is t=
he fact that
it generates an artificial problem likely to reported as a warning on=20
each given platform. But warning of a minor problem isn't exactly the best =
application, nor even possible under -Werror (unless they've found somethin=
g clever, which I suppose might just be beyond my imagination).<br><br>A fa=
cility specifically dedicated to logging might be more implementation effor=
t, since it represents a new form of compiler output, but low QOI works for=
basic compliance (e.g., simply suppress logging under -Werror). Any effort=
to make template instantiation logs usable would be very nice.<br><br></di=
v></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_8217_226688012.1409901799450--
.
Author: Jonathan Coe <jonathanbcoe@gmail.com>
Date: Fri, 5 Sep 2014 08:24:59 +0100
Raw View
--Apple-Mail-FFFC2A04-1627-4135-AA62-E78AD086FCE2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I like static_ message
> On 5 Sep 2014, at 08:23, gmisocpp@gmail.com wrote:
>=20
> HI
>=20
>> On Friday, September 5, 2014 2:49:43 AM UTC+12, David Krauss wrote:
>>=20
>>=20
>>> On Thursday, September 4, 2014 3:49:29 PM UTC+8, gmis...@gmail.com wrot=
e:
>>> I'm happy to write up an initial proposal based on this starting propos=
ition.
>>> I don't intend to present such a paper in person though so I would need=
someone interested in supporting me in that.=20
>>> Any further support beyond that, in this endeavour would be great too.
>>=20
>> I'd get behind a static_log.
>=20
> Cool. I've started writing up the issues for a draft proposal. I'll post =
something more detailed in the next day or two then.
>=20
> static_log or static_message seem reasonable.
> =20
>> The term "warning" implies some level of danger, whereas the only accept=
able level of danger is nil.
>=20
> I think the issues are a little more than that, but not a big deal.
> For instance, the claim there is that the danger is nil but most #warning=
implementations put the word "Warning" in the message for you. =20
> Right there is a tension to overcome when you want a message that is or i=
sn't a warning in your mind.
> I don't think there's anything to troublesome to overcome though.
> But I'll go into the options around this when I post something in the nex=
t few days and everyone can lay into that then maybe.
>=20
>>=20
>> Tracing through templates without breaking anything is unnecessarily tri=
cky. I want a facility that simply makes a report or log of what happened. =
Everyone knows that logs should never be seen by clients, except maybe with=
an obscure diagnostic switch. Warnings on the other hand are slightly ambi=
guous in that regard.
>>=20
>> Perhaps one reason for the name of Boost static_warning is the fact that=
it generates an artificial problem likely to reported as a warning on each=
given platform. But warning of a minor problem isn't exactly the best appl=
ication, nor even possible under -Werror (unless they've found something cl=
ever, which I suppose might just be beyond my imagination).
>>=20
>> A facility specifically dedicated to logging might be more implementatio=
n effort, since it represents a new form of compiler output, but low QOI wo=
rks for basic compliance (e.g., simply suppress logging under -Werror). Any=
effort to make template instantiation logs usable would be very nice.
>=20
> --=20
>=20
> ---=20
> You received this message because you are subscribed to the Google Groups=
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail-FFFC2A04-1627-4135-AA62-E78AD086FCE2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>I like static_ message</div><div><=
br></div><div><br>On 5 Sep 2014, at 08:23, <a href=3D"mailto:gmisocpp@gmail=
..com">gmisocpp@gmail.com</a> wrote:<br><br></div><blockquote type=3D"cite">=
<div><div dir=3D"ltr"><div>HI</div><div><br>On Friday, September 5, 2014 2:=
49:43 AM UTC+12, David Krauss wrote:</div><blockquote class=3D"gmail_quote"=
style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: =
rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div=
dir=3D"ltr"><br><br>On Thursday, September 4, 2014 3:49:29 PM UTC+8, <a>gm=
is...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20=
4); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">I'm=
happy to write up an initial proposal based on this starting proposition.<=
div>I don't intend to present such a paper in person though so I would=
need someone interested in supporting me in that. </div><div>Any=
further support beyond that, in this endeavour would be great too.</d=
iv></div></blockquote><div><br>I'd get behind a static_log. </div></div></b=
lockquote><div><br></div><div>Cool. I've started writing up the issues=
for a draft proposal. I'll post something more detailed in the n=
ext day or two then.</div><div><br></div><div>static_log or static_me=
ssage seem reasonable.</div><div> </div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-colo=
r: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><=
div dir=3D"ltr"><div>The term "warning" implies some level of danger, where=
as the only acceptable level of danger is nil.<br></div></div></blockquote>=
<div><br></div><div>I think the issues are a little more than that, but not=
a big deal.</div><div>For instance, the claim there is that the dange=
r is nil but most #warning implementations put the word "Warning"=
in the message for you. </div><div>Right there is a t=
ension to overcome when you want a message that is or isn't a warning in yo=
ur mind.</div><div>I don't think there's anything to troublesome to overcom=
e though.</div><p>But I'll go into the options around this when I=
post something in the next few days and everyone can lay into that th=
en maybe.</p><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><br>Tracing=
through templates without breaking anything is unnecessarily tricky. I wan=
t a facility that simply makes a report or log of what happened. Everyone k=
nows that logs should never be seen by clients, except maybe with an obscur=
e diagnostic switch. Warnings on the other hand are slightly ambiguous in t=
hat regard.<br><br>Perhaps one reason for the name of Boost static_warning =
is the fact that
it generates an artificial problem likely to reported as a warning on=20
each given platform. But warning of a minor problem isn't exactly the best =
application, nor even possible under -Werror (unless they've found somethin=
g clever, which I suppose might just be beyond my imagination).<br><br>A fa=
cility specifically dedicated to logging might be more implementation effor=
t, since it represents a new form of compiler output, but low QOI works for=
basic compliance (e.g., simply suppress logging under -Werror). Any effort=
to make template instantiation logs usable would be very nice.<br><br></di=
v></div></blockquote></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br>
</div></blockquote></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail-FFFC2A04-1627-4135-AA62-E78AD086FCE2--
.
Author: Tom Honermann <thonermann@coverity.com>
Date: Fri, 5 Sep 2014 09:11:08 -0400
Raw View
I like static_message, static_diagnostic, or static_diagnostic_message
(though that last one is a bit long). All are in line with terminology
in the standard (C++11 1.3.6).
Tom.
On 09/05/2014 03:24 AM, Jonathan Coe wrote:
> I like static_ message
>
>
> On 5 Sep 2014, at 08:23, gmisocpp@gmail.com <mailto:gmisocpp@gmail.com>
> wrote:
>
>> HI
>>
>> On Friday, September 5, 2014 2:49:43 AM UTC+12, David Krauss wrote:
>>
>>
>>
>> On Thursday, September 4, 2014 3:49:29 PM UTC+8, gmis...@gmail.com
>> wrote:
>>
>> I'm happy to write up an initial proposal based on this
>> starting proposition.
>> I don't intend to present such a paper in person though so I
>> would need someone interested in supporting me in that.
>> Any further support beyond that, in this endeavour would be
>> great too.
>>
>>
>> I'd get behind a static_log.
>>
>>
>> Cool. I've started writing up the issues for a draft proposal. I'll
>> post something more detailed in the next day or two then.
>>
>> static_log or static_message seem reasonable.
>>
>> The term "warning" implies some level of danger, whereas the only
>> acceptable level of danger is nil.
>>
>>
>> I think the issues are a little more than that, but not a big deal.
>> For instance, the claim there is that the danger is nil but most
>> #warning implementations put the word "Warning" in the message for you.
>> Right there is a tension to overcome when you want a message that is
>> or isn't a warning in your mind.
>> I don't think there's anything to troublesome to overcome though.
>>
>> But I'll go into the options around this when I post something in the
>> next few days and everyone can lay into that then maybe.
>>
>>
>> Tracing through templates without breaking anything is
>> unnecessarily tricky. I want a facility that simply makes a report
>> or log of what happened. Everyone knows that logs should never be
>> seen by clients, except maybe with an obscure diagnostic switch.
>> Warnings on the other hand are slightly ambiguous in that regard.
>>
>> Perhaps one reason for the name of Boost static_warning is the
>> fact that it generates an artificial problem likely to reported as
>> a warning on each given platform. But warning of a minor problem
>> isn't exactly the best application, nor even possible under
>> -Werror (unless they've found something clever, which I suppose
>> might just be beyond my imagination).
>>
>> A facility specifically dedicated to logging might be more
>> implementation effort, since it represents a new form of compiler
>> output, but low QOI works for basic compliance (e.g., simply
>> suppress logging under -Werror). Any effort to make template
>> instantiation logs usable would be very nice.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to std-proposals+unsubscribe@isocpp.org
>> <mailto:std-proposals+unsubscribe@isocpp.org>.
>> To post to this group, send email to std-proposals@isocpp.org
>> <mailto:std-proposals@isocpp.org>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Sat, 13 Sep 2014 23:51:57 -0700 (PDT)
Raw View
------=_Part_1793_808941602.1410677517746
Content-Type: text/plain; charset=UTF-8
On Friday, August 29, 2014 10:56:11 AM UTC-7, Tony V E wrote:
>
>
> There is nothing stopping you from writing a static_warning similar to how
> boost wrote BOOST_STATIC_ASSERT. And then, once you have something
> working, propose it to boost and/or the committee.
>
There is BOOST_STATIC_WARNING in the boost serialization library. It's
very fragile and always has been. A better solution is needed.
Robert Ramey
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1793_808941602.1410677517746
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, August 29, 2014 10:56:11 AM UTC-7, Tony=
V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><b=
r><div>There is nothing stopping you from writing a static_warning similar =
to how boost wrote BOOST_STATIC_ASSERT. And then, once you have somet=
hing working, propose it to boost and/or the committee.<br></div></div></bl=
ockquote><div><br></div><div>There is BOOST_STATIC_WARNING in the boost ser=
ialization library. It's very fragile and always has been. A be=
tter solution is needed. </div><div><br></div><div>Robert Ramey</div><=
/div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1793_808941602.1410677517746--
.
Author: gmisocpp@gmail.com
Date: Sun, 14 Sep 2014 06:28:02 -0700 (PDT)
Raw View
------=_Part_1886_727045576.1410701282963
Content-Type: text/plain; charset=UTF-8
Hello everyone,
I don't have a dropbox account, but here's some more details,
references and rationale for this static_warning feature.
Feedback please for next steps towards a proper proposal.
Static Warning/Message
Developers like the ability to generate their own compiler warnings and
messages:
http://embeddedgurus.com/stack-overflow/2011/09/effective-c-tip-9-%E2%80%93-use-warning/
If you haven't clicked, the most common way to do it this:
#warning "Standardization is long periods of mind-numbing boredom
interrupted by moments of sheer terror..."
The above statement generates the rather boring message of:
test.cpp:1:1: Warning: ... Well, you get the idea.
If you are new to #warning, you might find it is similar to static_assert,
yet strangely different...
Both display a user defined message. The useful difference is that with
#warning the build typically succeeds (i.e. the target will be generated)
but with static_assert the build typically fails.
#warning is so popular that most vendors already support it:
gcc: https://gcc.gnu.org/onlinedocs/cpp/Diagnostics.html
clang: http://clang.llvm.org/docs/UsersManual.html
ibm:
http://pic.dhe.ibm.com/infocenter/compbg/v121v141/index.jsp?topic=%2Fcom.ibm.xlcpp121.bg.doc%2Flanguage_ref%2Fwar_directive.html
edg: https://www.edg.com/docs/edg_cpp.pdf
Even Microsoft support it:
http://msdn.microsoft.com/en-us/library/963th5x3.aspx
Just not in Visual C++...
Implementations of #warning are pretty consistent. EDG says this:
"The non-standard preprocessing directive #warning is supported. It is
similar to the #error directive, but
results in a warning instead of a catastrophic error when processed. This
directive is not recognized in strict mode.
(This is an extension found in GNU C compilers.)
The details vary slightly, but usability and functionality of #warning is
consistent in all implementations I've seen."
#warning is so widespread people often use it for years before discovering
it's not standard. This is a pain.
stackoverflow is littered with requests for making the feature. Often
spreading more incompatibility in the process...
When #warning is not available, people (even smart ones) go to great
lengths to re-invent it. Even those that have yet to invent it, re-invent
it:
http://support.microsoft.com/kb/155196
And it happens again:
http://goodliffe.blogspot.co.nz/2009/07/c-how-to-say-warning-to-visual-studio-c.html
And again: _LIBCPP_WARNING(msg)
https://github.com/llvm-mirror/libcxx/blob/master/include/__config
And again: BOOST_STATIC_WARNING(expr)
http://www.boost.org/doc/libs/1_56_0/libs/serialization/doc/static_warning.html
Boost's static warning listed above expects an expression instead of a
message, but the concept is the same.
Boost says this about it:
"BOOST_STATIC_WARNING(x), generates a compile time warning message if the
integral-constant-expression x is not true.
Note that if the condition is true, then the macro will generate neither
code nor data - and the macro can also be used at either namespace, class
or function scope. When used in a template, the expression x will be
evaluated at the time the template is instantiated; this is particularly
useful for validating template parameters.
It is intended that the functioning of BOOST_STATIC_WARNING(x) be identical
to that of BOOST_STATIC_ASSERT(x) except that rather than resulting in a
compilation error, it will result in a compiler warning. In all other
respects it should be the same. So for more information on using
BOOST_STATIC_WARNING(x) consult the documentation for
BOOST_STATIC_ASSERT(x)"
So basically it's #warning with a default message and an interface more
consistent with static_assert. Good idea...
Let's recap:
- User defined warnings are popular.
- They have been widely implemented across multiple platforms and pretty
consistently too.
- #warning semantics are the most common type of usage.
- But boost semantics are also popular and more flexible.
- Users keep re-implementing this feature (with difficulty) when it's are
not available.
- #warning and boost static warning seem to point the way for both what we
need and what we need to support.
Proposal: Unify #warning and boost static warning to achieve all of the
above. We need. static_warning(expr, msg) See option #4 below..
People like this idea so much, they'll even pay for it!
http://stackoverflow.com/questions/8936063/does-there-exist-a-static-warning
So, the goals of this proposal are:
1. Justify the value in user defined warnings.
2. Suggest a few options to support getting user defined warnings
accepted as a Standard feature.
3. Propose a solution with an interface that works for both #warning and
boost static warning, so they both can migrate to Standard code:
4. Collect that small reward. :)
Options in more detail:
Option #1: Try to standardize #warning as is.
#warning implementations are close enough that this might be possible. Most
implementations are compatible but differences can be found around the
parsing of quotes in the string after #warning. Single, double, or no
quotes can be a problem but there is a lot of compatibility here still.
It might be possible for Vendors to converge on a Standard pattern for
#warning because code that is broken by any change should be loud and
fixing it should be easy and mechanical and any unfixed "breakages" might
be just cosmetic or not important enough to worry about, as it is a warning
after all...
Pros: This option could make a lot of existing code Standard "as is".
Requires no new keywords.
Cons: Small risk to existing code but why do this if #warning might be
better if it wasn't a #pre-processor feature anyway.
A major con of this route is it doesn't help boost static warning users at
all nor offer consistency with static_assert.
For this reason this option isn't recommended as a sole action.
Option #2: Introduce static_warning(message) as a new non pre-processor
keyword as an exact model of #warning.
Pros: Like option #1 but without risk to existing code and not a
pre-processor solution.
Cons: Doesn't help boost static warning users at all. Doesn't help
consistency with static_assert. Requires a new keyword.
This option isn't recommended because the interface is inflexible and the
pre-processor is still effectively always required to manage when the
warning should occur.
Option #3: Standardize BOOST_STATIC_WARNING(expr) "as is" as
static_warning(expr).
Pros: More like static_assert. Helps boost users move to Standard code.
Cons: Doesn't suit #warning users as it loses their message. Introduces a
new keyword.
Option #4: Combine #warning and boost's static_warning as:
static_warning(expr, msg)
Propose #warning "msg" users migrate to use static_warning(false, "msg")
Propose BOOST_STATIC_WARNING(x) users migrate to use static_warning(expr)
with a default message like static_assert.
Consider if static_message(expr,msg) is also of value. See below.
Pros: Gives both #warning and BOOST_STATIC_WARNING users an easy migration
path to Standard code. Consistent interface.
Cons: New keyword. If informaitonal messages were required also, a
static_message(expr, msg) would also need to be proposed.
Option #5 - Extend static_assert to support warnings and possibly messages
too.
We have: static_assert(expr) and static_assert(expr, msg).
We could add: static_assert(expr, msg, kind = assert_kind::error);
e.g. enum class assert_kind { error, warning /*, info, note*/ };
When assert_kind::warning is specified, the compiler will work like
#warning/static_warning in option #4. rather than the classic static_assert.
assert_kind::info and assert_kind::note could be additional options
provided as not every type of message a developer wants to generate is
really a "warning". assert_kind::note might be a message considered part of
a previous error, warning or info message.
Pros: All the pro's of option #4. Requires no new keyword. Possibly the
most flexible option.
Cons: Interface more complicated that straigh Option #4's
static_warning(expr,msg).
Conclusion:
Recommend Option 4 or 5, based on:
It seems important to give users the opportunity to avoid the pre-processor.
It seems essential to support both #warning users and boost static warning
users.
It seems making the feature consistent with static_assert makes it easier
to learn.
Option 4 seems easier to use but option 5 might be more flexible and
introduces no new keywords.
Option 1 could be done in addition to the proposed option though this isn't
proposed.
Todo:
- consider if example use cases useful, but links above have some use cases
already.
- consider narrowing down proposal, with particular regard to only
presenting options to 4 or 5, based on feedback.
- integrate general feedback on op5ions 4, or 5
- solicit value proposition and details of static_message /
assert_kind::info and assert_kind::note in interface as separate
feature aspect of static_warning
- include references to standard, and static_assert etc.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1886_727045576.1410701282963
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hello everyone,</div><div><br></div><div>I don't have=
a dropbox account, but here's some more details, references and =
rationale for this static_warning feature.</div><div>Feedback please&n=
bsp;for next steps towards a proper proposal.</div><div><br></div><div>Stat=
ic Warning/Message</div><div><br></div><div>Developers like the ability to =
generate their own compiler warnings and messages:<br><a href=3D"http://emb=
eddedgurus.com/stack-overflow/2011/09/effective-c-tip-9-%E2%80%93-use-warni=
ng/">http://embeddedgurus.com/stack-overflow/2011/09/effective-c-tip-9-%E2%=
80%93-use-warning/</a></div><div><br></div><div>If you haven't clicked, the=
most common way to do it this:<br>#warning "Standardization is long period=
s of mind-numbing boredom interrupted by moments of sheer terror..."</div><=
div><br></div><div>The above statement generates the rather boring message =
of:<br>test.cpp:1:1: Warning: ... Well, you get the idea.</div><div><br></d=
iv><div>If you are new to #warning, you might find it is similar to static_=
assert, yet strangely different...</div><div>Both display a user defined me=
ssage. The useful difference is that with #warning the build typically succ=
eeds (i.e. the target will be generated) but with static_assert the build t=
ypically fails.</div><div><br></div><div>#warning is so popular that most v=
endors already support it:</div><div>gcc: <a href=3D"https://gcc.gnu.org/on=
linedocs/cpp/Diagnostics.html">https://gcc.gnu.org/onlinedocs/cpp/Diagnosti=
cs.html</a><br>clang: <a href=3D"http://clang.llvm.org/docs/UsersManual.htm=
l">http://clang.llvm.org/docs/UsersManual.html</a><br>ibm: <a href=3D"http:=
//pic.dhe.ibm.com/infocenter/compbg/v121v141/index.jsp?topic=3D%2Fcom.ibm.x=
lcpp121.bg.doc%2Flanguage_ref%2Fwar_directive.html">http://pic.dhe.ibm.com/=
infocenter/compbg/v121v141/index.jsp?topic=3D%2Fcom.ibm.xlcpp121.bg.doc%2Fl=
anguage_ref%2Fwar_directive.html</a><br>edg: <a href=3D"https://www.edg.com=
/docs/edg_cpp.pdf">https://www.edg.com/docs/edg_cpp.pdf</a></div><div><br><=
/div><div>Even Microsoft support it:<br><a href=3D"http://msdn.microsoft.co=
m/en-us/library/963th5x3.aspx">http://msdn.microsoft.com/en-us/library/963t=
h5x3.aspx</a><br>Just not in Visual C++...</div><div><br></div><div>Impleme=
ntations of #warning are pretty consistent. EDG says this:</div><div>"The n=
on-standard preprocessing directive #warning is supported. It is similar to=
the #error directive, but<br>results in a warning instead of a catastrophi=
c error when processed. This directive is not recognized in strict mode.<br=
>(This is an extension found in GNU C compilers.)<br>The details vary sligh=
tly, but usability and functionality of #warning is consistent in all imple=
mentations I've seen."</div><div><br></div><div>#warning is so widespread p=
eople often use it for years before discovering it's not standard. This is =
a pain.<br>stackoverflow is littered with requests for making the feature. =
Often spreading more incompatibility in the process...</div><div><br></div>=
<div>When #warning is not available, people (even smart ones) go to great l=
engths to re-invent it. Even those that have yet to invent it, re-invent it=
:<br><a href=3D"http://support.microsoft.com/kb/155196">http://support.micr=
osoft.com/kb/155196</a></div><div><br></div><div>And it happens again:<br><=
a href=3D"http://goodliffe.blogspot.co.nz/2009/07/c-how-to-say-warning-to-v=
isual-studio-c.html">http://goodliffe.blogspot.co.nz/2009/07/c-how-to-say-w=
arning-to-visual-studio-c.html</a></div><div><br></div><div>And again: _LIB=
CPP_WARNING(msg) <br><a href=3D"https://github.com/llvm-mirror/libcxx/blob/=
master/include/__config">https://github.com/llvm-mirror/libcxx/blob/master/=
include/__config</a></div><div><br></div><div>And again: BOOST_STATIC_WARNI=
NG(expr)<br><a href=3D"http://www.boost.org/doc/libs/1_56_0/libs/serializat=
ion/doc/static_warning.html">http://www.boost.org/doc/libs/1_56_0/libs/seri=
alization/doc/static_warning.html</a></div><div><br></div><div>Boost's stat=
ic warning listed above expects an expression instead of a message, but the=
concept is the same.<br>Boost says this about it:</div><div>"BOOST_STATIC_=
WARNING(x), generates a compile time warning message if the integral-consta=
nt-expression x is not true. <br>Note that if the condition is true, then t=
he macro will generate neither code nor data - and the macro can also be us=
ed at either namespace, class or function scope. When used in a template, t=
he expression x will be evaluated at the time the template is instantiated;=
this is particularly useful for validating template parameters. <br>It is =
intended that the functioning of BOOST_STATIC_WARNING(x) be identical to th=
at of BOOST_STATIC_ASSERT(x) except that rather than resulting in a compila=
tion error, it will result in a compiler warning. In all other respects it =
should be the same. So for more information on using BOOST_STATIC_WARNING(x=
) consult the documentation for BOOST_STATIC_ASSERT(x)"</div><div><br></div=
><div>So basically it's #warning with a default message and an interface mo=
re consistent with static_assert. Good idea...</div><div><br></div><di=
v>Let's recap:<br>- User defined warnings are popular.<br>- They have been =
widely implemented across multiple platforms and pretty consistently too.<b=
r>- #warning semantics are the most common type of usage.<br>- But boost se=
mantics are also popular and more flexible.<br>- Users keep re-impleme=
nting this feature (with difficulty) when it's are not available.=
<br>- #warning and boost static warning seem to point the way for both what=
we need and what we need to support.</div><div><div><br></div></div><div>P=
roposal: Unify #warning and boost static warning to achieve all of the=
above. We need. static_warning(expr, msg) See option #4 below..</div><div>=
<div>People like this idea so much, they'll even pay for it!<br><a href=3D"=
http://stackoverflow.com/questions/8936063/does-there-exist-a-static-warnin=
g">http://stackoverflow.com/questions/8936063/does-there-exist-a-static-war=
ning</a></div></div><div><br></div><div>So, the goals of this proposal are:=
</div><div><div>1. Justify the value in user defined warnings.</div><div>2.=
Suggest a few options to support getting user defined warnings a=
ccepted as a Standard feature.</div></div><div>3. Propose a solution w=
ith an interface that works for both #warning and boost static warning=
, so they both can migrate to Standard code:<br></div><div>4. Collect&=
nbsp;that small reward. :)</div><div><br></div><div>Options in more detail:=
</div><div><br></div><div>Option #1: Try to standardize #warning as is.</di=
v><div><br></div><div>#warning implementations are close enough that this m=
ight be possible. Most implementations are compatible but differences can b=
e found around the parsing of quotes in the string after #warning. Single, =
double, or no quotes can be a problem but there is a lot of compatibility h=
ere still.</div><div>It might be possible for Vendors to converge on a Stan=
dard pattern for #warning because code that is broken by any change should =
be loud and fixing it should be easy and mechanical and any unfixed "breaka=
ges" might be just cosmetic or not important enough to worry about, as it i=
s a warning after all...</div><div><br></div><div>Pros: This option could m=
ake a lot of existing code Standard "as is". Requires no new keywords.</div=
><div>Cons: Small risk to existing code but why do this if #warning might b=
e better if it wasn't a #pre-processor feature anyway.</div><div><br></div>=
<div>A major con of this route is it doesn't help boost static warning user=
s at all nor offer consistency with static_assert.<br>For this reason this =
option isn't recommended as a sole action.</div><div><br></div><div>Option =
#2: Introduce static_warning(message) as a new non pre-processor keyword as=
an exact model of #warning.</div><div><br></div><div>Pros: Like option #1 =
but without risk to existing code and not a pre-processor solution.</div><d=
iv>Cons: Doesn't help boost static warning users at all. Doesn't help consi=
stency with static_assert. Requires a new keyword. </div><div><br></div><di=
v>This option isn't recommended because the interface is inflexible and the=
pre-processor is still effectively always required to manage when the warn=
ing should occur.</div><div><br></div><div>Option #3: Standardize BOOST_STA=
TIC_WARNING(expr) "as is" as static_warning(expr).</div><div><br></div><div=
>Pros: More like static_assert. Helps boost users move to Standard code.<br=
>Cons: Doesn't suit #warning users as it loses their message. Introduces a =
new keyword.</div><div><br></div><div>Option #4: Combine #warning and boost=
's static_warning as: static_warning(expr, msg)</div><div><br></div><div><d=
iv>Propose #warning "msg" users migrate to use static_warning(fal=
se, "msg")<br>Propose BOOST_STATIC_WARNING(x) users migrate to use&nbs=
p;static_warning(expr) with a default message like static_assert.</div><div=
>Consider if static_message(expr,msg) is also of value. See below.</div><di=
v><br></div></div><div>Pros: Gives both #warning and BOOST_STATIC_WARNING u=
sers an easy migration path to Standard code. Consistent interface.<br>Cons=
: New keyword. If informaitonal messages were required also, a static_messa=
ge(expr, msg) would also need to be proposed.</div><div><br></div><div>Opti=
on #5 - Extend static_assert to support warnings and possibly messages=
too.</div><div>We have: static_assert(expr) and static_assert(expr, msg).<=
br>We could add: static_assert(expr, msg, kind =3D assert_kind::error);<br>=
e.g. enum class assert_kind { error, warning /*, info, note*/ };</div><div>=
<br></div><div>When assert_kind::warning is specified, the compiler will wo=
rk like #warning/static_warning in option #4. rather than the classic stati=
c_assert.</div><div>assert_kind::info and assert_kind::note could be additi=
onal options provided as not every type of message a developer wants to gen=
erate is really a "warning". assert_kind::note might be a message considere=
d part of a previous error, warning or info message.</div><div><br></div><d=
iv>Pros: All the pro's of option #4. Requires no new keyword. Possibly the =
most flexible option.<br>Cons: Interface more complicated that straigh Opti=
on #4's static_warning(expr,msg).</div><div><br></div><div>Conclusion:</div=
><div>Recommend Option 4 or 5, based on:<br>It seems important to give user=
s the opportunity to avoid the pre-processor.<br>It seems essential to supp=
ort both #warning users and boost static warning users.<br>It seems ma=
king the feature consistent with static_assert makes it easier to learn.<br=
>Option 4 seems easier to use but option 5 might be more flexible and intro=
duces no new keywords.<br>Option 1 could be done in addition to the propose=
d option though this isn't proposed.</div><div><br></div><div>Todo:</div><d=
iv>- consider if example use cases useful, but links above have s=
ome use cases already.</div><div>- consider narrowing down proposal, with p=
articular regard to only presenting options to 4 or 5, based on feedba=
ck.</div><div>- integrate general feedback on op5ions 4, or 5</div><di=
v><div>- solicit value proposition and details of static_message =
/ assert_kind::info and assert_kind::note in interface as s=
eparate feature aspect of static_warning</div><div>- include refe=
rences to standard, and static_assert etc.</div></div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1886_727045576.1410701282963--
.
Author: Nicola Gigante <nicola.gigante@gmail.com>
Date: Sun, 14 Sep 2014 17:52:19 +0200
Raw View
Il giorno 14/set/2014, alle ore 15:28, gmisocpp@gmail.com ha scritto:
> Hello everyone,
>
> I don't have a dropbox account, but here's some more details, references and rationale for this static_warning feature.
> Feedback please for next steps towards a proper proposal.
> [cut]
Hello.
I'm quite an outsider in this list but I would like to express my opinion.
There's something quite misleading I see in your summary of the intended proposal,
namely the association between #warning and static_assert.
You list the non-standard alternatives of #warning, #pragma message and so on, and then
you list BOOST_STATIC_WARNING.
You say BOOST_STATIC_WARNING is about "#warning but with an interface more similar to static_assert()",
but it's not totally correct. It's not a matter of interface, it's a matter of capabilities of the feature.
#warning is a preprocessor directive, perfectly similar to #error, and talks about messages generated in
the preprocessing phase.
static_assert(), on the other hand, gets evaluated a lot later in the chain, and can be used to detect
errors during the compilation. It's an entirely different beast.
People use the non-standard #warning directive to warn about unimplemented features in headers
on unsupported platforms or missing macro definitions or things like that, while an hypothetical
static_message() similar to static_assert() would enable the code to talk its users about template
parameters, types etc...
I know everybody on this list knows the difference between this concepts and I don't feel like I
need to explain them better.
My point is that it's not at all clear what this proposal is about. A standard #warning preprocessor
directive, or a compile-time static_message(), similar in principle to static_assert()?
My personal feeling is that standardizing the common practice of #warning could be very reasonable,
given the broad support of this extension. static_message() could be useful too, but I think it should
be proposed together with a revision of the limits of static_assert() (the possibility to compute
at compile time the message instead of being limited to a literal, etc...)
Bye,
Nicola
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: gmisocpp@gmail.com
Date: Sun, 14 Sep 2014 14:25:29 -0700 (PDT)
Raw View
------=_Part_3137_897488345.1410729929352
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi Nicola
On Monday, September 15, 2014 3:52:25 AM UTC+12, Nicola Gigante wrote:
>
>
>
> Hello.=20
>
> I=E2=80=99m quite an outsider in this list but I would like to express my=
opinion.=20
> There=E2=80=99s something quite misleading I see in your summary of the i=
ntended=20
> proposal,=20
> namely the association between #warning and static_assert.=20
>
Ok, I'm happy to try to fix that that if that's the case.
>
> You list the non-standard alternatives of #warning, #pragma message and s=
o=20
> on, and then=20
> you list BOOST_STATIC_WARNING.=20
> You say BOOST_STATIC_WARNING is about =E2=80=9C#warning but with an inter=
face more=20
> similar to static_assert()=E2=80=9D,=20
> but it=E2=80=99s not totally correct. It=E2=80=99s not a matter of interf=
ace, it=E2=80=99s a=20
> matter of capabilities of the feature.=20
> #warning is a preprocessor directive, perfectly similar to #error, and=20
> talks about messages generated in=20
> the preprocessing phase.=20
>
> static_assert(), on the other hand, gets evaluated a lot later in the=20
> chain, and can be used to detect=20
> errors during the compilation. It=E2=80=99s an entirely different beast.=
=20
>
>
I agree mostly except in the conclusion, I'm not sure I agree it's entirely=
=20
different beast for practical purposes.
But I'll see how your argument evolves.
=20
> People use the non-standard #warning directive to warn about unimplemente=
d=20
> features in headers=20
> on unsupported platforms or missing macro definitions or things like that=
,=20
> while an hypothetical=20
> static_message() similar to static_assert() would enable the code to talk=
=20
> its users about template=20
> parameters, types etc=E2=80=A6=20
Let's see if we can get to the heart of your issue like this: Now that we=
=20
have static_assert. Is the ever a case where you will use #error that you=
=20
can't use static_assert instead?=20
>
>
> I know everybody on this list knows the difference between this concepts=
=20
> and I don=E2=80=99t feel like I=20
> need to explain them better.=20
> My point is that it=E2=80=99s not at all clear what this proposal is abou=
t. A=20
> standard #warning preprocessor=20
> directive, or a compile-time static_message(), similar in principle to=20
> static_assert()?=20
>
> My personal feeling is that standardizing the common practice of #warning=
=20
> could be very reasonable,=20
> given the broad support of this extension. static_message() could be=20
> useful too, but I think it should=20
> be proposed together with a revision of the limits of static_assert() (th=
e=20
> possibility to compute=20
> at compile time the message instead of being limited to a literal, etc=E2=
=80=A6)=20
>
I agree in as much as that I put standardizing #warning as a possibility=20
and better than nothing but not my preferred option and certainly not if=20
it's the only thing done. I see boost type static warning as just as useful=
=20
but see that if extended, it makes #warning unnecessary.
Do you disagree with that latter idea and how. And what can I add to the=20
text to make you more happy with it.
The limits of static_warning in evaluating the expression and the content=
=20
of the message are that of static_assert.
I'm keen to ride on the coat tails of that definition than express=20
something differently or even at all depending on what options we are=20
talking about here.
=20
>
> Bye,=20
> Nicola
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_3137_897488345.1410729929352
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Nicola<br><br>On Monday, September 15, 2014 3:52:25 AM =
UTC+12, Nicola Gigante wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204,=
204); border-left-width: 1px; border-left-style: solid;">
<br><br>Hello.
<br>
<br>I=E2=80=99m quite an outsider in this list but I would like to express =
my opinion.
<br>There=E2=80=99s something quite misleading I see in your summary of the=
intended proposal,
<br>namely the association between #warning and static_assert.
<br></blockquote><div><br></div><div>Ok, I'm happy to try to fix =
that that if that's the case.</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<br>You list the non-standard alternatives of #warning, #pragma message and=
so on, and then
<br>you list BOOST_STATIC_WARNING.
<br>You say BOOST_STATIC_WARNING is about =E2=80=9C#warning but with an int=
erface more similar to static_assert()=E2=80=9D,
<br>but it=E2=80=99s not totally correct. It=E2=80=99s not a matter of inte=
rface, it=E2=80=99s a matter of capabilities of the feature.
</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;">
<br>#warning is a preprocessor directive, perfectly similar to #error, and =
talks about messages generated in
<br>the preprocessing phase.=20
<br>
<br>static_assert(), on the other hand, gets evaluated a lot later in the c=
hain, and can be used to detect
<br>errors during the compilation. It=E2=80=99s an entirely different beast=
..
<br>
<br></blockquote><div><div><br></div><div>I agree mostly except in the conc=
lusion, I'm not sure I agree it's entirely different beast for practic=
al purposes.</div><div>But I'll see how your argument evolves.</div> <=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width=
: 1px; border-left-style: solid;">People use the non-standard #warning dire=
ctive to warn about unimplemented features in headers
<br>on unsupported platforms or missing macro definitions or things like th=
at, while an hypothetical
<br>static_message() similar to static_assert() would enable the code to ta=
lk its users about template
<br>parameters, types etc=E2=80=A6 </blockquote><div><br></div><div>Let's s=
ee if we can get to the heart of your issue like this: Now that we have sta=
tic_assert. Is the ever a case where you will use #error that you can'=
t use static_assert instead? </div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-colo=
r: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<br>
<br>I know everybody on this list knows the difference between this concept=
s and I don=E2=80=99t feel like I
<br>need to explain them better.
<br>My point is that it=E2=80=99s not at all clear what this proposal is ab=
out. A standard #warning preprocessor
<br>directive, or a compile-time static_message(), similar in principle to =
static_assert()?
<br>
<br>My personal feeling is that standardizing the common practice of #warni=
ng could be very reasonable,
<br>given the broad support of this extension. static_message() could be us=
eful too, but I think it should
<br>be proposed together with a revision of the limits of static_assert() (=
the possibility to compute
<br>at compile time the message instead of being limited to a literal, etc=
=E2=80=A6)
<br></blockquote><div><br></div><div>I agree in as much as that I put stand=
ardizing #warning as a possibility and better than nothing but not my prefe=
rred option and certainly not if it's the only thing done. I see boost type=
static warning as just as useful but see that if extended, it makes #warni=
ng unnecessary.</div><div><br></div><div>Do you disagree with that latter i=
dea and how. And what can I add to the text to make you more happy with it.=
</div><div>The limits of static_warning in evaluating the expression and th=
e content of the message are that of static_assert.</div><div>I'm keen to r=
ide on the coat tails of that definition than express something differently=
or even at all depending on what options we are talking about here.</div><=
div> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;">
<br>Bye,
<br>Nicola</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3137_897488345.1410729929352--
.
Author: Nicola Gigante <nicola.gigante@gmail.com>
Date: Tue, 16 Sep 2014 09:28:11 +0200
Raw View
Il giorno 14/set/2014, alle ore 23:25, gmisocpp@gmail.com ha scritto:
> Hi Nicola
>=20
Hi!
> I agree mostly except in the conclusion, I'm not sure I agree it's entire=
ly different beast for practical purposes.
> But I'll see how your argument evolves.
> =20
They are indeed. You don't catch wrong template parameters with #warning.
And the happen at completely different stages of compilation. They're
completely different in the same way as #if is completely different
from std::conditional<>.
>=20
> Let's see if we can get to the heart of your issue like this: Now that we=
have static_assert. Is the ever a case where you will use #error that you =
can't use static_assert instead?=20
Of course static_assert is more general.
#ifndef SOMEPLATFORMMACRO
#error This platform is not supported
#endif
You could change it to:
static_assert(SOMEPLATFORMMACRO, "You get the idea");
But you don't get the same behavior. #error stops the preprocessing
phase, so the compiler doesn't bother with anything that could be
wrong in the code (and if you're quitting because your platform is
unsupported, a lot of things are broken down there). If you replace
the #error with the static_assert you get the same error message but
the compiler have to parse the code, so you get flooded with a whole
bunch of other errors that confuse the user and hide the real problem.
This is not the case with #warning and static_message(), since they would
not stop the compilation either way, but since you asked about static_asser=
t=20
I've answered.
>=20
> I agree in as much as that I put standardizing #warning as a possibility =
and better than nothing but not my preferred option and certainly not if it=
's the only thing done. I see boost type static warning as just as useful b=
ut see that if extended, it makes #warning unnecessary.
>=20
> Do you disagree with that latter idea and how. And what can I add to the =
text to make you more happy with it.
> The limits of static_warning in evaluating the expression and the content=
of the message are that of static_assert.
> I'm keen to ride on the coat tails of that definition than express someth=
ing differently or even at all depending on what options we are talking abo=
ut here.
I completely agree that a static_message() facility would be more useful in=
general than #warning. The point is that
they're different things and should be dealt with in different discussions.=
If you want to extend the language by
adding the capability of printing a message during compilation to warn the =
user about dubious things at compile time,
to complement static_assert(), than propose static_message().
If you want to propose the standardization of a common and widespread exten=
sion, thus making compliant a ton=20
of existing code out there, than propose #warning.
I think both have merits and I would be happy the see them in the next stan=
dard. But I would not be completely satisfied by
the inclusion of static_message() but not of #warning, only on the basis th=
at the latter is reducible to the former, because
I would like to see the ton of code already using #warning becoming conform=
ing code.
Bye,
Nicola
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: gmisocpp@gmail.com
Date: Tue, 16 Sep 2014 02:52:10 -0700 (PDT)
Raw View
------=_Part_5125_925393608.1410861130397
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi Nicola
Of course static_assert is more general.=20
>
> #ifndef SOMEPLATFORMMACRO=20
> #error This platform is not supported=20
> #endif=20
>
> You could change it to:=20
> static_assert(SOMEPLATFORMMACRO, =E2=80=9CYou get the idea=E2=80=9D);=20
>
> But you don=E2=80=99t get the same behavior. #error stops the preprocessi=
ng=20
> phase, so the compiler doesn=E2=80=99t bother with anything that could be=
=20
> wrong in the code (and if you=E2=80=99re quitting because your platform i=
s=20
> unsupported, a lot of things are broken down there). If you replace=20
> the #error with the static_assert you get the same error message but=20
> the compiler have to parse the code, so you get flooded with a whole=20
> bunch of other errors that confuse the user and hide the real problem.=20
>
> This is not the case with #warning and static_message(), since they would=
=20
> not stop the compilation either way, but since you asked about=20
> static_assert=20
> I=E2=80=99ve answered.=20
>
ok, I agree.
=20
> I completely agree that a static_message() facility would be more useful=
=20
> in general than #warning. The point is that=20
> they=E2=80=99re different things and should be dealt with in different=20
> discussions. If you want to extend the language by=20
> adding the capability of printing a message during compilation to warn th=
e=20
> user about dubious things at compile time,=20
> to complement static_assert(), than propose static_message().=20
>
> If you want to propose the standardization of a common and widespread=20
> extension, thus making compliant a ton=20
> of existing code out there, than propose #warning.=20
>
> I think both have merits and I would be happy the see them in the next=20
> standard. But I would not be completely satisfied by=20
> the inclusion of static_message() but not of #warning, only on the basis=
=20
> that the latter is reducible to the former, because=20
> I would like to see the ton of code already using #warning becoming=20
> conforming code.=20
>
> Bye,=20
> Nicola
Yes, that's my goals:
1. make code that is using #warning Standard somehow
2. make code that is using BOOST_STATIC_WARNING Standard somehow.
I don't care if that happens directly or indirectly. By that I mean, I=20
don't care if they become Standard "as is" or have a simple mechanical=20
upgrade paths to some other feature that is Standard.
I'm happy that be one proposal or into two if that's the consensus which=20
I'm hearing is your preference.
It seems you voting on:
1. Make #warning Standard so some errors can get reported on in the=20
pre-processing phase where that is wanted.
2. Introduce static_warning(expr,msg) too so errors can get reported after=
=20
the pre-processing phase and in a more flexible way.
That achieves both my goals.
I'm less sure what you may be saying about static_message.
My position on it is that is, conceptually a static_warning and a=20
static_message feature are two very similar but different things.
At the simplest level, I anticipate the compiler=20
processing static_warning and desiring to stick 'Warning' in the message=20
for you not that it has to, but that it could. but you also might want to=
=20
report a version number or some debug info in your code which isn't a=20
warning really, in that instance a static_message type feature is what=20
you'd want and there the compiler would be encouraged to NOT put=20
'Warning' in the message.
static_warning is the essential and useful feature. But I see value in both=
..
I'm keen to try to resolve the terminology and use cases to something that=
=20
is clear in everyone's minds.
At a more complex level, static_warning can be effected by other options=20
like compile with no warnings. Where a static_message feature would=20
be enabled/disabled by other options. This further shows the distinction.
In summary I'm hearing/seeing:
Make #warning standard roughly "as is". Introduce=20
static_message(expr,msg) to cover BOOST_STATIC_WARNING(expr).
Tbd. on value of static_message
Put #warning in one proposal, static_warning in another with perhaps=20
static_message as a sub part of that second proposal.
How do you feel about that?
Thanks
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_5125_925393608.1410861130397
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Nicola</div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-le=
ft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: so=
lid;">Of course static_assert is more general.
<br>
<br>#ifndef SOMEPLATFORMMACRO
<br>#error This platform is not supported
<br>#endif
<br>
<br>You could change it to:
<br>static_assert(<wbr>SOMEPLATFORMMACRO, =E2=80=9CYou get the idea=E2=80=
=9D);
<br>
<br>But you don=E2=80=99t get the same behavior. #error stops the preproces=
sing
<br>phase, so the compiler doesn=E2=80=99t bother with anything that could =
be
<br>wrong in the code (and if you=E2=80=99re quitting because your platform=
is
<br>unsupported, a lot of things are broken down there). If you replace
<br>the #error with the static_assert you get the same error message but
<br>the compiler have to parse the code, so you get flooded with a whole
<br>bunch of other errors that confuse the user and hide the real problem.
<br>
<br>This is not the case with #warning and static_message(), since they wou=
ld
<br>not stop the compilation either way, but since you asked about static_a=
ssert=20
<br>I=E2=80=99ve answered.
<br></blockquote><div><br></div><div>ok, I agree.</div><div> =
;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex=
; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wid=
th: 1px; border-left-style: solid;">
I completely agree that a static_message() facility would be more useful in=
general than #warning. The point is that
<br>they=E2=80=99re different things and should be dealt with in different =
discussions. If you want to extend the language by
<br>adding the capability of printing a message during compilation to warn =
the user about dubious things at compile time,
<br>to complement static_assert(), than propose static_message().
<br>
<br>If you want to propose the standardization of a common and widespread e=
xtension, thus making compliant a ton=20
<br>of existing code out there, than propose #warning.
<br>
<br>I think both have merits and I would be happy the see them in the next =
standard. But I would not be completely satisfied by
<br>the inclusion of static_message() but not of #warning, only on the basi=
s that the latter is reducible to the former, because
<br>I would like to see the ton of code already using #warning becoming con=
forming code.
<br>
<br>Bye,
<br>Nicola</blockquote><div><br></div><div>Yes, that's my goals:</div>=
<div><br></div><div>1. make code that is using #warning Stan=
dard somehow</div><div>2. make code that is using BOOST_STATIC_WARNING=
Standard somehow.</div><div><br></div><div>I don't care if that happe=
ns directly or indirectly. By that I mean, I don't care if they become Stan=
dard "as is" or have a simple mechanical upgrade paths to some other featur=
e that is Standard.</div><div><br></div><div>I'm happy that be on=
e proposal or into two if that's the consensus which I'm hearing is yo=
ur preference.</div><div><br></div><div>It seems you voting on:</div><=
div><br></div><div>1. Make #warning Standard so some errors can get reporte=
d on in the pre-processing phase where that is wanted.</div><div>2. In=
troduce static_warning(expr,msg) too so errors can get reported after the p=
re-processing phase and in a more flexible way.</div><div><br></div><div>Th=
at achieves both my goals.</div><div><br></div><div>I'm less sure what =
;you may be saying about static_message.</div><div><br></div><div>My p=
osition on it is that is, conceptually a static_warning and a static_messag=
e feature are two very similar but different things.</div><div><br></d=
iv><div>At the simplest level, I anticipate the compiler processing&nb=
sp;static_warning and desiring to stick 'Warning' in the message =
for you not that it has to, but that it could. but you also might=
want to report a version number or some debug info in your code which isn'=
t a warning really, in that instance a static_message type feature is =
what you'd want and there the compiler would be encouraged to NOT=
put 'Warning' in the message.</div><div><br></div><div>static_warning=
is the essential and useful feature. But I see value in bot=
h.</div><div><br></div><div>I'm keen to try to resolve the terminology and =
use cases to something that is clear in everyone's minds.</div><div><b=
r></div><div>At a more complex level, static_warning can be effected by oth=
er options like compile with no warnings. Where a static_message feature wo=
uld be enabled/disabled by other options. This further shows the disti=
nction.</div><div><br></div><div>In summary I'm hearing/seeing:</div><div>M=
ake #warning standard roughly "as is". Introduce static_message(expr,msg)&n=
bsp;to cover BOOST_STATIC_WARNING(expr).</div><div>Tbd. on value of st=
atic_message</div><div><br></div><div>Put #warning in one proposal, static_=
warning in another with perhaps static_message as a sub part of that s=
econd proposal.</div><div><br></div><div>How do you feel about that?</div><=
div><br></div><div>Thanks</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5125_925393608.1410861130397--
.
Author: Nicola Gigante <nicola.gigante@gmail.com>
Date: Tue, 16 Sep 2014 12:35:58 +0200
Raw View
--Apple-Mail=_15008703-F00F-4751-A071-028DC5937899
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
Il giorno 16/set/2014, alle ore 11:52, gmisocpp@gmail.com ha scritto:
> Yes, that's my goals:
>=20
> 1. make code that is using #warning Standard somehow
> 2. make code that is using BOOST_STATIC_WARNING Standard somehow.
>=20
> I don't care if that happens directly or indirectly. By that I mean, I do=
n't care if they become Standard "as is" or have a simple mechanical upgrad=
e paths to some other feature that is Standard.
>=20
> I'm happy that be one proposal or into two if that's the consensus which =
I'm hearing is your preference.
>=20
> It seems you voting on:
>=20
> 1. Make #warning Standard so some errors can get reported on in the pre-p=
rocessing phase where that is wanted.
> 2. Introduce static_warning(expr,msg) too so errors can get reported afte=
r the pre-processing phase and in a more flexible way.
>=20
> That achieves both my goals.
>=20
> I'm less sure what you may be saying about static_message.
>=20
> My position on it is that is, conceptually a static_warning and a static_=
message feature are two very similar but different things.
>=20
> At the simplest level, I anticipate the compiler processing static_warnin=
g and desiring to stick 'Warning' in the message for you not that it has to=
, but that it could. but you also might want to report a version number or =
some debug info in your code which isn't a warning really, in that instance=
a static_message type feature is what you'd want and there the compiler wo=
uld be encouraged to NOT put 'Warning' in the message.
>=20
> static_warning is the essential and useful feature. But I see value in bo=
th.
>=20
> I'm keen to try to resolve the terminology and use cases to something tha=
t is clear in everyone's minds.
>=20
> At a more complex level, static_warning can be effected by other options =
like compile with no warnings. Where a static_message feature would be enab=
led/disabled by other options. This further shows the distinction.
>=20
> In summary I'm hearing/seeing:
> Make #warning standard roughly "as is". Introduce static_message(expr,msg=
) to cover BOOST_STATIC_WARNING(expr).
> Tbd. on value of static_message
>=20
> Put #warning in one proposal, static_warning in another with perhaps stat=
ic_message as a sub part of that second proposal.
>=20
> How do you feel about that?
I feel perfectly fine!
Please note, about the "voting" thing: In the standardization process I'm e=
xactly Mr.Nobody,
do I'm not voting anything... Mine were just opinions from a C++ developer =
point of view.
About the static_message/static_warning difference: you're completely right=
that they're different
in scope, especially regarding the options available in some implementation=
s that are used to
see warnings as errors.
static_warning() could be very useful, but keep in mind that a generic stat=
ic_message(), capable of
printing informations calculated at compile-time instead of a simple litera=
l, would be a panacea
for debugging of template metaprogramming code, which is currently a pain. =
If static_message()
gets this capability I don't see why not to extend it to static_assert() an=
d static_warning() of course.
Maybe it is worth considering a more general effort to enhance the static_w=
hatever() architecture to
allow a more flexible compile-time communication from library developers to=
library users.
>=20
> Thanks
Thanks to you,
Nicola
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_15008703-F00F-4751-A071-028DC5937899
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>Il giorn=
o 16/set/2014, alle ore 11:52, <a href=3D"mailto:gmisocpp@gmail.com">gmisoc=
pp@gmail.com</a> ha scritto:</div><br><blockquote type=3D"cite"><div style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px;"><div dir=3D"ltr"><div>Yes, that's my goals:</div><div><b=
r></div><div>1. make code that is using #warning Standard so=
mehow</div><div>2. make code that is using BOOST_STATIC_WARNING Standa=
rd somehow.</div><div><br></div><div>I don't care if that happens dire=
ctly or indirectly. By that I mean, I don't care if they become Standard "a=
s is" or have a simple mechanical upgrade paths to some other feature =
that is Standard.</div><div><br></div></div></div></blockquote><blockquote =
type=3D"cite"><div style=3D"font-family: Helvetica; font-size: 12px; font-s=
tyle: normal; font-variant: normal; font-weight: normal; letter-spacing: no=
rmal; line-height: normal; orphans: auto; text-align: start; text-indent: 0=
px; text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><div>I'm happy that&=
nbsp;be one proposal or into two if that's the consensus which I'm hea=
ring is your preference.</div><div><br></div><div>It seems you voting =
on:</div><div><br></div><div>1. Make #warning Standard so some errors can g=
et reported on in the pre-processing phase where that is wanted.</div><div>=
2. Introduce static_warning(expr,msg) too so errors can get reported a=
fter the pre-processing phase and in a more flexible way.</div><div><br></d=
iv><div>That achieves both my goals.</div><div><br></div><div>I'm less sure=
what you may be saying about static_message.</div><div><br></div><div=
>My position on it is that is, conceptually a static_warning and a sta=
tic_message feature are two very similar but different things.</div><d=
iv><br></div><div>At the simplest level, I anticipate the compiler pro=
cessing static_warning and desiring to stick 'Warning' in th=
e message for you not that it has to, but that it could. but you also&=
nbsp;might want to report a version number or some debug info in your code =
which isn't a warning really, in that instance a static_message type f=
eature is what you'd want and there the compiler would be encoura=
ged to NOT put 'Warning' in the message.</div><div><br></div><div>stat=
ic_warning is the essential and useful feature. But I see va=
lue in both.</div><div><br></div><div>I'm keen to try to resolve the termin=
ology and use cases to something that is clear in everyone's minds.</d=
iv><div><br></div><div>At a more complex level, static_warning can be effec=
ted by other options like compile with no warnings. Where a static_message =
feature would be enabled/disabled by other options. This further shows=
the distinction.</div><div><br></div><div>In summary I'm hearing/seeing:</=
div><div>Make #warning standard roughly "as is". Introduce static_message(e=
xpr,msg) to cover BOOST_STATIC_WARNING(expr).</div><div>Tbd. on v=
alue of static_message</div><div><br></div><div>Put #warning in one proposa=
l, static_warning in another with perhaps static_message as a sub part=
of that second proposal.</div><div><br></div><div>How do you feel about th=
at?</div></div></div></blockquote><div><br></div><div>I feel perfectly fine=
!</div><div><br></div><div>Please note, about the “voting” thin=
g: In the standardization process I’m exactly Mr.Nobody,</div><div>do=
I’m not voting anything… Mine were just opinions from a C++ d=
eveloper point of view.</div><div><br></div><div>About the static_message/s=
tatic_warning difference: you’re completely right that they’re =
different</div><div>in scope, especially regarding the options available in=
some implementations that are used to</div><div>see warnings as errors.</d=
iv><div><br></div><div>static_warning() could be very useful, but keep in m=
ind that a generic static_message(), capable of</div><div>printing informat=
ions calculated at compile-time instead of a simple literal, would be a pan=
acea</div><div>for debugging of template metaprogramming code, which is cur=
rently a pain. If static_message()</div><div>gets this capability I don&rsq=
uo;t see why not to extend it to static_assert() and static_warning() of co=
urse.</div><div><br></div><div>Maybe it is worth considering a more general=
effort to enhance the static_whatever() architecture to</div><div>allow a =
more flexible compile-time communication from library developers to library=
users.</div><br><blockquote type=3D"cite"><div style=3D"font-family: Helve=
tica; font-size: 12px; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; line-height: normal; orphans: auto; text=
-align: start; text-indent: 0px; text-transform: none; white-space: normal;=
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=
=3D"ltr"><div><br></div><div>Thanks</div></div></div></blockquote>Thanks to=
you,</div><div>Nicola</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_15008703-F00F-4751-A071-028DC5937899--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 18 Sep 2014 19:11:43 -0400
Raw View
On 2014-09-14 09:28, gmisocpp@gmail.com wrote:
> [tl;wq]
My 2=C2=A2... standardizing #warning would be good, but I'd reiterate much =
of
what Nicola has said, i.e. that IMO this can/should be separate and in
addition to a static_assert-like diagnostic. (Although... it's not quite
the same dichotomy as static_assert/#error, since a #warning, being
normally non-fatal, won't stop compilation, and thus the argument about
it popping earlier is less relevant.)
That said... I'd go with static_diagnostic<expr, msg, type>, where expr
and msg are just what you'd think, and type is e.g. error, warning, ...
Ideally static_assert<expr, msg> would then be a "shortcut" for
static_diagnostic<expr, msg, ERROR> (for however we prefer to spell
"ERROR"). Using "diagnostic" seems most consistent with existing
practice e.g. gcc's #pragma diagnostic and provides greater flexibility
(for one, preprocessor defines at least can change the diagnostic
level). Bonus points if 'type' itself can somehow be conditional (e.g.
contain a constexpr expression yielding a type).
Additional bonus points if the expr part can be optional. (I'd think
this is possible; it's just an overload problem between (bool, char*,
enum) and (char*, enum); those shouldn't normally be ambiguous.)
My second choice would be the above but use static_assert instead of
static_diagnostic, with the type optional.
p.s. If there is any specification of prefix strings, I'd prefer stating
that they are consistent with other diagnostics of the same type (e.g.
gcc/clang use "warning: "; note the lower case). The goal should be that
downstream tools (IDE's, build bots, etc.) should not need to change
their recognition rules to recognize the warning as such.
p.p.s. When you mentioned version numbers, I had a sudden thought that
you could leverage this to use the compiler as a sort of handy, always
available general purpose "scripting" engine. (Limited to things you can
do with constexpr, of course, but still, I could imagine this being
useful.) It might be a helpful debugging aid also, especially as I
imagine it would be parsed for every template instantiation, e.g. to see
what template instantiations are happening or otherwise inspect the
compile state when things are going screwy.
--=20
Matthew
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Sat, 20 Sep 2014 08:56:57 -0700 (PDT)
Raw View
------=_Part_3190_1322879255.1411228617554
Content-Type: text/plain; charset=UTF-8
On Sunday, 14 September 2014 14:28:03 UTC+1, gmis...@gmail.com wrote:
>
>
> Option #5 - Extend static_assert to support warnings and possibly messages
> too.
> We have: static_assert(expr) and static_assert(expr, msg).
> We could add: static_assert(expr, msg, kind = assert_kind::error);
> e.g. enum class assert_kind { error, warning /*, info, note*/ };
>
> I would like to see fatal as another option to assert_kind. There are
cases where it would be inappropriate to do error recovery (e.g. due to the
compiler) but the necessary information would not be available to the
preprocessor for #error.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3190_1322879255.1411228617554
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, 14 September 2014 14:28:03 UTC+1, gmis.=
...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><div>Option #5 - Extend static_assert to support warnings and&=
nbsp;possibly messages too.</div><div>We have: static_assert(expr) and stat=
ic_assert(expr, msg).<br>We could add: static_assert(expr, msg, kind =3D as=
sert_kind::error);<br>e.g. enum class assert_kind { error, warning /*, info=
, note*/ };</div><br></div></blockquote><div>I would like to see fatal as a=
nother option to assert_kind. There are cases where it would be inapp=
ropriate to do error recovery (e.g. due to the compiler) but the necessary =
information would not be available to the preprocessor for #error. <br></di=
v></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3190_1322879255.1411228617554--
.