Topic: Draft: operator assert
Author: David Krauss <potswa@gmail.com>
Date: Sun, 28 Sep 2014 16:31:13 +0800
Raw View
--Apple-Mail=_A383505F-9E7A-4DBF-A05D-5F31DB8F9242
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
Inspired by the recent "constexpr assert" thread, I've written a short prop=
osal to make assert an operator. The user selects the novel functionality u=
sing e.g. -DNDEBUG=3Dstrong .
No standardese yet, but I wonder if the proposal is complete enough without=
it?
Abstract:
---
The assert macro has never behaved much like a real function, and for the f=
oreseeable future, it will look and smell like an operator. The way the mac=
ro is specified by C precludes it from providing optimization hints in prod=
uction mode, but allows it to execute arbitrary side effects in debug mode.=
Adding assert as a keyword and built-in operator would have benefits but e=
ssentially no downside.
---
Link: http://bit.ly/1rsHeyJ
--=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=_A383505F-9E7A-4DBF-A05D-5F31DB8F9242
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;">Inspired by the recent=
“constexpr assert” thread, I’ve written a short proposal=
to make assert an operator. The user selects the novel functionality using=
e.g. <font face=3D"Courier">-DNDEBUG=3Dstrong</font> .<div><br></div>=
<div>No standardese yet, but I wonder if the proposal is complete enough wi=
thout it?</div><div><br></div><div>Abstract:</div><div>––&ndash=
;</div><div>The assert macro has never behaved much like a real f=
unction, and for the foreseeable future, it will look and smell like an ope=
rator. The way the macro is specified by C precludes it from providing=
optimization hints in production mode, but allows it to execute arbitrary =
side effects in debug mode. Adding assert as a keyword and built-=
in operator would have benefits but essentially no downside.<br>&ndash=
;––<br></div><div><br></div><div>Link: <a href=3D"http://bit.ly=
/1rsHeyJ">http://bit.ly/1rsHeyJ</a></div><div><br></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=_A383505F-9E7A-4DBF-A05D-5F31DB8F9242--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Sun, 28 Sep 2014 01:43:51 -0700 (PDT)
Raw View
------=_Part_1699_1799765220.1411893831572
Content-Type: text/plain; charset=UTF-8
This looks good!
I would further give leeway in the wording for implementations to diagnose
a false condition on compile time.
Not just if the condition is constexpr which evaluates to false, but if the
compiler for any reason can deduce it is false (eh due to optimizations).
The above could work even if debugging is disabled (ie non-debugging mode
should only not incur any runtime check penalty).
--
---
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_1699_1799765220.1411893831572
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This looks good!<br><br>I would further give leeway in the=
wording for implementations to diagnose a false condition on compile time.=
<br>Not just if the condition is constexpr which evaluates to false, but if=
the compiler for any reason can deduce it is false (eh due to optimization=
s).<br>The above could work even if debugging is disabled (ie non-debugging=
mode should only not incur any runtime check penalty).<br></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_1699_1799765220.1411893831572--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Sun, 28 Sep 2014 02:16:25 -0700 (PDT)
Raw View
------=_Part_89_1484217403.1411895785120
Content-Type: text/plain; charset=UTF-8
Another idea would be for the "debug mode selection" not be so tied to the
legacy way of redefining NDEBUG and including assert.h
So suppose that instead of assert, the operator is "dynamic_assert" or some
such, and this dynamic_assert takes an enum non-type template parameter
called "mode".
So this enum could have elements like:
enum class dynamic_assert_mode {
DEFAULT,
NO_RUNTIME_CHECKS,
RUNTIME_CHECKS,
};
And then assert.h is just a shim which defines assert in terms of
dynamic_assert and using NDEBUG to fill that parameter.
Now this way if the user opts to use dynamic_assert, he can control groups
of them at once by defining globals of that enum type and passing those
into the respective "dynamic_assert" groups.
The idea behind that DEFAULT mode is so you can say that it is
implementation defined whether it's equivalent to NO_RUNTIME_CHECKS or
RUNTIME_CHECKS.
This would give all the wording required for implementations to give users
control of what default mode does by a command line switch for example.
To fit your idea of making optional the "ill-formed if false" thing
(STRICT, STRONG), you can just add more members to that enum I suppose.
--
---
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_89_1484217403.1411895785120
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Another idea would be for the "debug mode selection" not b=
e so tied to the legacy way of redefining NDEBUG and including assert.h<br>=
<br>So suppose that instead of assert, the operator is "dynamic_assert" or =
some such, and this dynamic_assert takes an enum non-type template paramete=
r called "mode".<br><br>So this enum could have elements like:<br><br>enum =
class dynamic_assert_mode {<br> DEFAULT,<br> &=
nbsp; NO_RUNTIME_CHECKS,<br> RUNTIME_CHECKS,<br>};<br><br=
>And then assert.h is just a shim which defines assert in terms of dynamic_=
assert and using NDEBUG to fill that parameter.<br><br>Now this way if the =
user opts to use dynamic_assert, he can control groups of them at once by d=
efining globals of that enum type and passing those into the respective "dy=
namic_assert" groups.<br><br>The idea behind that DEFAULT mode is so you ca=
n say that it is implementation defined whether it's equivalent to NO_RUNTI=
ME_CHECKS or RUNTIME_CHECKS.<br>This would give all the wording required fo=
r implementations to give users control of what default mode does by a comm=
and line switch for example.<br><br>To fit your idea of making optional the=
"ill-formed if false" thing (STRICT, STRONG), you can just add more member=
s to that enum I suppose.<br></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_89_1484217403.1411895785120--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Sun, 28 Sep 2014 03:04:01 -0700 (PDT)
Raw View
------=_Part_1692_58574669.1411898641776
Content-Type: text/plain; charset=UTF-8
To clarify what I said above, here is an example of what it could look
like, in a more modern c++ way:
static constexpr auto group1_mode = dynamic_assert_mode::RUNTIME_CHECKS;
static constexpr auto group2_mode = dynamic_assert_mode::NO_RUNTIME_CHECKS;
void foo(int a, int b) {
dynamic_assert<group1_mode>(a < b, "error!");
// ...
}
void bar(char c) {
dynamic_assert<group2_mode>(c >= '0' && c <= '9', "error!!");
// ...
}
void baz(int *d) {
dynamic_assert<group1_mode>(d != nullptr, "error!!!");
// ...
}
void baz(int *e) {
dynamic_assert(e != nullptr, "error!!!"); // default template parameter
would be dynamic_assert_mode::DEFAULT
// ...
}
Though I realize now that the enum type name and elements name are not very
good as I proposed, too long!
--
---
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_1692_58574669.1411898641776
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">To clarify what I said above, here is an example of what i=
t could look like, in a more modern c++ way:<br><br><div class=3D"prettypri=
nt" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 1=
87, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">static constexpr auto group1_mode =
=3D dynamic_assert_mode::RUNTIME_CHECKS;<br></span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">static constexpr auto group2=
_mode =3D dynamic_assert_mode::NO_RUNTIME_CHECKS;</span></code><br><br>void=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> b</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br> dynamic=
_assert</span><span style=3D"color: #080;" class=3D"styled-by-prettify"><=
;group1_mode></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080=
;" class=3D"styled-by-prettify">"error!"</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// ...</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br><br></span><code class=3D"prettyprint"><code class=3D"pr=
ettyprint">void<span style=3D"color: #000;" class=3D"styled-by-prettify"> b=
ar</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify"></span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"></span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &n=
bsp; dynamic_assert</span><span style=3D"color: #080;" class=3D"styled-by-p=
rettify"><group2_mode></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span>c >=3D '0' && c <=3D '9'<span style=
=3D"color: #000;" class=3D"styled-by-prettify"></span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"s=
tyled-by-prettify">"error!!"</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br> // ...<br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span></code></code><code class=3D"prettyp=
rint"><code class=3D"prettyprint"><code class=3D"prettyprint">void<span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> baz</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">int </span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">*d</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify"></span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"></span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br> dynamic_assert</spa=
n><span style=3D"color: #080;" class=3D"styled-by-prettify"><group1_mode=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n>d !=3D nullptr<span style=3D"color: #000;" class=3D"styled-by-prettify"><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">"error!!!"</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br> // ...<br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span></code>=
</code></code><br><code class=3D"prettyprint"><code class=3D"prettyprint"><=
code class=3D"prettyprint"><code class=3D"prettyprint">void<span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> baz</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">int </span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">*e</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify"></span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"></span><span style=3D"color: #000;" class=3D"styled-by-prettify"></span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br> dynamic_assert</span><span=
style=3D"color: #080;" class=3D"styled-by-prettify"></span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(e</span> !=3D nullptr<span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"=
styled-by-prettify">"error!!!"</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> // default template parameter would be dynamic_assert_mode::DE=
FAULT<br> // ...<br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span></code></code></code></code></div></code></di=
v><br>Though I realize now that the enum type name and elements name are no=
t very good as I proposed, too long!<br><br></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_1692_58574669.1411898641776--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Sun, 28 Sep 2014 08:53:34 -0700 (PDT)
Raw View
------=_Part_2187_1823771485.1411919614389
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, September 28, 2014 10:32:18 AM UTC+2, David Krauss wrote:
>
> Inspired by the recent =E2=80=9Cconstexpr assert=E2=80=9D thread, I=E2=80=
=99ve written a short=20
> proposal to make assert an operator. The user selects the novel=20
> functionality using e.g. -DNDEBUG=3Dstrong .
>
> No standardese yet, but I wonder if the proposal is complete enough=20
> without it?
>
> Abstract:
> =E2=80=93=E2=80=93=E2=80=93
> The assert macro has never behaved much like a real function, and for the=
=20
> foreseeable future, it will look and smell like an operator. The way the=
=20
> macro is specified by C precludes it from providing optimization hints in=
=20
> production mode, but allows it to execute arbitrary side effects in debug=
=20
> mode. Adding assert as a keyword and built-in operator would have benefit=
s=20
> but essentially no downside.
> =E2=80=93=E2=80=93=E2=80=93
>
> Link: http://bit.ly/1rsHeyJ=20
> <http://www.google.com/url?q=3Dhttp%3A%2F%2Fbit.ly%2F1rsHeyJ&sa=3DD&sntz=
=3D1&usg=3DAFQjCNF6o5yAUemBMJGjJu4CNGKgr5R3eA>
>
>
> NDEBUG =3D strong: assert has no side effects, but the implementation may=
=20
use the=20
condition, and if it would fail, the behavior is undefined. =20
This part could break existing code, which seems like a downside to me.
--=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_2187_1823771485.1411919614389
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, September 28, 2014 10:32:18 AM UTC+2, D=
avid Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=
=3D"word-wrap:break-word">Inspired by the recent =E2=80=9Cconstexpr assert=
=E2=80=9D thread, I=E2=80=99ve written a short proposal to make assert an o=
perator. The user selects the novel functionality using e.g. <font fac=
e=3D"Courier">-DNDEBUG=3Dstrong</font> .<div><br></div><div>No standardese =
yet, but I wonder if the proposal is complete enough without it?</div><div>=
<br></div><div>Abstract:</div><div>=E2=80=93=E2=80=93=E2=80=93</div><div>Th=
e assert macro has never behaved much like a real function, and f=
or the foreseeable future, it will look and smell like an operator. The way=
the macro is specified by C precludes it from providing optimization =
hints in production mode, but allows it to execute arbitrary side effects i=
n debug mode. Adding assert as a keyword and built-in operator&nb=
sp;would have benefits but essentially no downside.<br>=E2=80=93=E2=80=93=
=E2=80=93<br></div><div><br></div><div>Link: <a href=3D"http://www.google.c=
om/url?q=3Dhttp%3A%2F%2Fbit.ly%2F1rsHeyJ&sa=3DD&sntz=3D1&usg=3D=
AFQjCNF6o5yAUemBMJGjJu4CNGKgr5R3eA" target=3D"_blank" onmousedown=3D"this.h=
ref=3D'http://www.google.com/url?q\75http%3A%2F%2Fbit.ly%2F1rsHeyJ\46sa\75D=
\46sntz\0751\46usg\75AFQjCNF6o5yAUemBMJGjJu4CNGKgr5R3eA';return true;" oncl=
ick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fbit.ly%2F1rs=
HeyJ\46sa\75D\46sntz\0751\46usg\75AFQjCNF6o5yAUemBMJGjJu4CNGKgr5R3eA';retur=
n true;">http://bit.ly/1rsHeyJ</a></div><div><br></div></div></blockquote><=
div><br></div><div>> NDEBUG =3D strong: assert has no side effects, but =
the implementation may use the </div><div>condition, and if it would f=
ail, the behavior is undefined. </div><div><br></div><div>This part c=
ould break existing code, which seems like a downside to me.</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_2187_1823771485.1411919614389--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 29 Sep 2014 00:17:39 +0800
Raw View
--Apple-Mail=_4BC38E21-3896-4447-8204-BF7E08259202
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-28, at 4:43 PM, Matheus Izvekov <mizvekov@gmail.com> wrote:
> I would further give leeway in the wording for implementations to diagnos=
e a false condition on compile time.
There was a recent discussion on the UB mailing list, and I'm inclined to g=
o the other way and say that an always-firing assert is OK, except...
On 2014-09-28, at 4:54 PM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:
> so if your assert happens to result in code that is never constexpr, you =
have an ill-formed
> program. I suppose that should be clarified in order to be able to sanely=
use asserts
> in constexpr functions.
An always-firing assert in a constexpr function should be ill-formed in the=
same way that always throwing would be.
On 2014-09-28, at 6:04 PM, Matheus Izvekov <mizvekov@gmail.com> wrote:
> dynamic_assert<group2_mode>(c >=3D '0' && c <=3D '9', "error!!");
I still prefer NDEBUG because it will integrate with build systems. You're =
going to end up tying group2_mode to a macro anyway.
On 2014-09-28, at 11:53 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> > NDEBUG =3D strong: assert has no side effects, but the implementation m=
ay use the=20
> condition, and if it would fail, the behavior is undefined. =20
>=20
> This part could break existing code, which seems like a downside to me.
That's why it's opt-in. NDEBUG is typically set by build settings, so nobod=
y should get this policy by accident. (Strong mode is not recommended as a =
default, perhaps I should mention so in the proposal.) Because of how <asse=
rt.h> works (and has always worked), you can apply the policy to just one s=
ection of code:
#ifdef NDEBUG
#undef NDEBUG
#define NDEBUG strong
#include <cassert> // switch to strong mode
#endif
void clean_fn() {
assert ( x + y > 3, "fooey" );
}
#ifdef NDEBUG
#undef NDEBUG
#define NDEBUG
#include <cassert> // switch back to relaxed mode
#endif
void messy_fn() {
ONLY_IN_DEBUG_MODE( int xyz =3D 3; )
assert ( some_macro( xyz ) + nonsense =3D !!! );
}
This is ugly, but it's also quite advanced usage and somewhat specific to h=
eader libraries. I think most folks would just configure one source file to=
be different from the others.
--=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=_4BC38E21-3896-4447-8204-BF7E08259202
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;09–28, at 4:43 PM, Matheus Izvekov <<a href=3D"mailto:mizvek=
ov@gmail.com">mizvekov@gmail.com</a>> wrote:</div><br class=3D"Apple-int=
erchange-newline"><blockquote type=3D"cite"><span style=3D"font-family: Hel=
vetica; font-size: 12px; font-style: normal; font-variant: normal; font-wei=
ght: normal; letter-spacing: normal; line-height: normal; orphans: auto; te=
xt-align: start; text-indent: 0px; text-transform: none; white-space: norma=
l; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: =
none; display: inline !important;">I would further give leeway in the wordi=
ng for implementations to diagnose a false condition on compile time.</span=
><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; line-hei=
ght: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px;"></blockquote></div><br><div>There was a recent disc=
ussion on the UB mailing list, and I’m inclined to go the other way a=
nd say that an always-firing assert is OK, except…</div><div><br></d=
iv><div><div>On 2014–09–28, at 4:54 PM, Ville Voutilainen <<=
a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</=
a>> wrote:</div><br class=3D"Apple-interchange-newline"><blockquote type=
=3D"cite">so if your assert happens to result in code that is never constex=
pr, you have an ill-formed<br>program. I suppose that should be clarif=
ied in order to be able to sanely use asserts<br>in constexpr function=
s.<br></blockquote></div><div><br></div><div>An always-firing assert in a c=
onstexpr function should be ill-formed in the same way that always throwing=
would be.</div><div><br></div><div><div>On 2014–09–28, at 6:04=
PM, Matheus Izvekov <<a href=3D"mailto:mizvekov@gmail.com">mizvekov@gma=
il.com</a>> wrote:</div><br class=3D"Apple-interchange-newline"><blockqu=
ote type=3D"cite"><span class=3D"styled-by-prettify" style=3D"font-family: =
monospace; background-color: rgb(250, 250, 250);"> dynamic_ass=
ert</span><span class=3D"styled-by-prettify" style=3D"font-family: monospac=
e; background-color: rgb(250, 250, 250); color: rgb(0, 136, 0);"><group2=
_mode></span><span class=3D"styled-by-prettify" style=3D"font-family: mo=
nospace; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">(<=
/span><span style=3D"font-family: monospace; background-color: rgb(250, 250=
, 250);">c >=3D '0' && c <=3D '9'</span><span class=3D"styled=
-by-prettify" style=3D"font-family: monospace; background-color: rgb(250, 2=
50, 250);"></span><span class=3D"styled-by-prettify" style=3D"font-family: =
monospace; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">=
,</span><span class=3D"styled-by-prettify" style=3D"font-family: monospace;=
background-color: rgb(250, 250, 250);"> </span><span class=3D"styled-=
by-prettify" style=3D"font-family: monospace; background-color: rgb(250, 25=
0, 250); color: rgb(0, 136, 0);">"error!!"</span><span class=3D"styled-by-p=
rettify" style=3D"font-family: monospace; background-color: rgb(250, 250, 2=
50); color: rgb(102, 102, 0);">);</span><span class=3D"styled-by-prettify" =
style=3D"font-family: monospace; background-color: rgb(250, 250, 250);"><br=
></span></blockquote></div><div><br></div><div>I still prefer NDEBUG becaus=
e it will integrate with build systems. You’re going to end up tying =
<font face=3D"Courier">group2_mode</font> to a macro anyway.</div><div><br>=
</div><div><br></div><div><div>On 2014–09–28, at 11:53 PM, Olaf=
van der Spek <<a href=3D"mailto:olafvdspek@gmail.com">olafvdspek@gmail.=
com</a>> wrote:</div><br class=3D"Apple-interchange-newline"><blockquote=
type=3D"cite"><div dir=3D"ltr"><div>> NDEBUG =3D strong: assert has no =
side effects, but the implementation may use the </div><div>condition,=
and if it would fail, the behavior is undefined. </div><div><br></di=
v><div>This part could break existing code, which seems like a downside to =
me.</div></div></blockquote><br></div><div>That’s why it’s opt-=
in. <font face=3D"Courier">NDEBUG</font> is typically set by build settings=
, so nobody should get this policy by accident. (Strong mode is not recomme=
nded as a default, perhaps I should mention so in the proposal.) Because of=
how <font face=3D"Courier"><assert.h></font> works (and has always w=
orked), you can apply the policy to just one section of code:</div><div><br=
></div><div><font face=3D"Courier">#ifdef NDEBUG</font></div><div><font fac=
e=3D"Courier">#undef NDEBUG</font></div><div><font face=3D"Courier">#define=
NDEBUG strong</font></div><div><font face=3D"Courier">#include <cassert=
> // switch to strong mode</font></div><div><font face=3D"Courier">#endi=
f</font></div><div><font face=3D"Courier"><br></font></div><div><font face=
=3D"Courier">void clean_fn() {</font></div><div><font face=3D"Courier">&nbs=
p; assert ( x + y > 3, "fooey" );</font></div><div><font face=3D"=
Courier">}</font></div><div><font face=3D"Courier"><br></font></div><div><d=
iv><font face=3D"Courier">#ifdef NDEBUG</font></div><div><font face=3D"Cour=
ier">#undef NDEBUG</font></div><div><font face=3D"Courier">#define NDEBUG</=
font></div><div><font face=3D"Courier">#include <cassert> // switch b=
ack to relaxed mode</font></div><div><font face=3D"Courier">#endif</font></=
div><div><font face=3D"Courier"><br></font></div><div><font face=3D"Courier=
">void messy_fn() {</font></div><div><font face=3D"Courier"> O=
NLY_IN_DEBUG_MODE( int xyz =3D 3; )</font></div><div><font face=3D"Courier"=
> assert ( some_macro( xyz ) + nonsense =3D !!! );</font></div=
><div><font face=3D"Courier">}</font></div><div><br></div></div><div>This i=
s ugly, but it’s also quite advanced usage and somewhat specific to h=
eader libraries. I think most folks would just configure one source file to=
be different from the others.</div><div><br></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=_4BC38E21-3896-4447-8204-BF7E08259202--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 29 Sep 2014 00:22:24 +0800
Raw View
--Apple-Mail=_3EAA5DF0-D7D6-4AD4-86F7-FC5A3900AC6A
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-29, at 12:17 AM, David Krauss <potswa@gmail.com> wrote:
> There was a recent discussion on the UB mailing list
* A somewhat related discussion about eager diagnosis and consistency between platforms. Not anything about assert in particular.
--
---
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/.
--Apple-Mail=_3EAA5DF0-D7D6-4AD4-86F7-FC5A3900AC6A
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;09–29, at 12:17 AM, David Krauss <<a href=3D"mailto:potswa@g=
mail.com">potswa@gmail.com</a>> wrote:</div><br class=3D"Apple-interchan=
ge-newline"><blockquote type=3D"cite"><div style=3D"font-family: Helvetica;=
font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">There was a r=
ecent discussion on the UB mailing list</div></blockquote><br></div><div>* =
A somewhat related discussion about eager diagnosis and consistency between=
platforms. Not anything about assert in particular.</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=_3EAA5DF0-D7D6-4AD4-86F7-FC5A3900AC6A--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 28 Sep 2014 19:27:27 +0300
Raw View
On 28 September 2014 19:17, David Krauss <potswa@gmail.com> wrote:
> On 2014=E2=80=9309=E2=80=9328, at 4:54 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com>
> wrote:
>
> so if your assert happens to result in code that is never constexpr, you
> have an ill-formed
> program. I suppose that should be clarified in order to be able to sanely
> use asserts
> in constexpr functions.
>
>
> An always-firing assert in a constexpr function should be ill-formed in t=
he
> same way that always throwing would be.
Note that I'm not talking just about always-firing asserts, but also
about asserts
for which the condition is never constexpr.
--=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: Brent Friedman <fourthgeek@gmail.com>
Date: Sun, 28 Sep 2014 11:27:48 -0500
Raw View
--047d7b6772fc85bbff050422a1aa
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
N3997 has already been doing a lot of work on new assertion support.
Perhaps we should just get constexpr support added to that.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3997.pdf
On Sun, Sep 28, 2014 at 11:22 AM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9309=E2=80=9329, at 12:17 AM, David Krauss <potswa@gmail.co=
m> wrote:
>
> There was a recent discussion on the UB mailing list
>
>
> * A somewhat related discussion about eager diagnosis and consistency
> between platforms. Not anything about assert in particular.
>
> --
>
> ---
> 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/.
>
--=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/.
--047d7b6772fc85bbff050422a1aa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">N3997 has already been doing a lot of work on new assertio=
n support. Perhaps we should just get constexpr support added to that.<div>=
<br></div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/paper=
s/2014/n3997.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n=
3997.pdf</a><br></div><div><br></div><div><br></div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Sun, Sep 28, 2014 at 11:22 AM, =
David Krauss <span dir=3D"ltr"><<a href=3D"mailto:potswa@gmail.com" targ=
et=3D"_blank">potswa@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div style=3D"word-wrap:break-word"><span class=3D""><br><div=
><div>On 2014=E2=80=9309=E2=80=9329, at 12:17 AM, David Krauss <<a href=
=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>> wro=
te:</div><br><blockquote type=3D"cite"><div style=3D"font-family:Helvetica;=
font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;let=
ter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text=
-transform:none;white-space:normal;word-spacing:0px">There was a recent dis=
cussion on the UB mailing list</div></blockquote><br></div></span><div>* A =
somewhat related discussion about eager diagnosis and consistency between p=
latforms. Not anything about assert in particular.</div><br></div><div clas=
s=3D"HOEnZb"><div class=3D"h5">
<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></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 />
--047d7b6772fc85bbff050422a1aa--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Sun, 28 Sep 2014 18:31:30 +0200
Raw View
Wasn't N3997 rejected?
On Sun, Sep 28, 2014 at 6:27 PM, Brent Friedman <fourthgeek@gmail.com> wrot=
e:
> N3997 has already been doing a lot of work on new assertion support. Perh=
aps
> we should just get constexpr support added to that.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3997.pdf
>
>
>
> On Sun, Sep 28, 2014 at 11:22 AM, David Krauss <potswa@gmail.com> wrote:
>>
>>
>> On 2014=E2=80=9309=E2=80=9329, at 12:17 AM, David Krauss <potswa@gmail.c=
om> wrote:
>>
>> There was a recent discussion on the UB mailing list
>>
>>
>> * A somewhat related discussion about eager diagnosis and consistency
>> between platforms. Not anything about assert in particular.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/rQiHnGAXU3M/=
unsubscribe.
> To unsubscribe from this group and all its topics, 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/.
--=20
Olaf
--=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: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 28 Sep 2014 19:36:13 +0300
Raw View
On 28 September 2014 19:31, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> Wasn't N3997 rejected?
EWG wants to take a closer look at it, so it was postponed rather than rejected.
--
---
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: David Krauss <potswa@gmail.com>
Date: Mon, 29 Sep 2014 00:40:28 +0800
Raw View
--Apple-Mail=_02D2DFE9-D258-43E6-B702-83E1D1A1540B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-29, at 12:27 AM, Ville Voutilainen <ville.voutilainen@gmail.com>=
wrote:
> Note that I'm not talking just about always-firing asserts, but also abou=
t asserts
> for which the condition is never constexpr.
If the condition has to be evaluated, it has to constrain its context.
Strict (production) mode should require that debug mode works too, despite =
not evaluating the operand. [expr.const] would just get an extra item,
-- an assert expression with a condition that is not a constant expression,=
except in relaxed assertion mode
Perhaps there's also a use for assertions that simply don't apply at compil=
e time, but I'd rather not be the one to propose that. The controlling expr=
ession can still have side-effects and that would allow discrimination of r=
untime vs. compile time. There could certainly be a follow-on proposal.
--=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=_02D2DFE9-D258-43E6-B702-83E1D1A1540B
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;09–29, at 12:27 AM, Ville Voutilainen <<a href=3D"mailto:vil=
le.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><=
br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">Note that =
I'm not talking just about always-firing asserts, but also about asser=
ts<br>for which the condition is never constexpr.<br></blockquote><div><br>=
</div><div>If the condition has to be evaluated, it has to constrain its co=
ntext.</div><div><br></div><div>Strict (production) mode should require tha=
t debug mode works too, despite not evaluating the operand. [expr.const] wo=
uld just get an extra item,</div><div><br></div><div>— an <font face=
=3D"Courier">assert</font> expression with a condition that is not a consta=
nt expression, except in relaxed assertion mode</div><div><br></div><div>Pe=
rhaps there’s also a use for assertions that simply don’t apply=
at compile time, but I’d rather not be the one to propose that. The =
controlling expression can still have side-effects and that would allow dis=
crimination of runtime vs. compile time. There could certainly be a follow-=
on proposal.</div><div><br></div></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=_02D2DFE9-D258-43E6-B702-83E1D1A1540B--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 28 Sep 2014 11:22:15 -0700
Raw View
On Monday 29 September 2014 00:17:39 David Krauss wrote:
> > so if your assert happens to result in code that is never constexpr, you
> > have an ill-formed program. I suppose that should be clarified in order
> > to be able to sanely use asserts in constexpr functions.
>
> An always-firing assert in a constexpr function should be ill-formed in the
> same way that always throwing would be.
Example:
void f(int x)
{
if (x == 1)
return doOne();
else if (x == 2)
return doTwo();
assert(false); /* Impossible condition */
}
Perfectly valid code.
And with the failed assertion function getting a [[noreturn]] attribute, the
compiler can do dead code elimination if it wants to.
--
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: David Krauss <potswa@gmail.com>
Date: Mon, 29 Sep 2014 05:05:04 +0800
Raw View
--Apple-Mail=_23BDF627-7D4D-4A2F-A4C5-A769F5D7A7EF
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-29, at 2:22 AM, Thiago Macieira <thiago@macieira.org> wrote:
> Perfectly valid code.
Yes, but in this context "always-firing" means for any execution of the function. There is no problem with that example (if it were declared constexpr).
--
---
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/.
--Apple-Mail=_23BDF627-7D4D-4A2F-A4C5-A769F5D7A7EF
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;09–29, at 2:22 AM, Thiago Macieira <<a href=3D"mailto:thiago=
@macieira.org">thiago@macieira.org</a>> wrote:</div><br class=3D"Apple-i=
nterchange-newline"><blockquote type=3D"cite"><span style=3D"font-family: H=
elvetica; font-size: 12px; font-style: normal; font-variant: normal; font-w=
eight: normal; letter-spacing: normal; line-height: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: nor=
mal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float=
: none; display: inline !important;">Perfectly valid code.</span><br 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;"></blockquote></div><br><div>Yes, but in this context&nbs=
p;“always-firing” means for any execution of the function. Ther=
e is no problem with that example (if it were declared constexpr).</div><di=
v><br></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=_23BDF627-7D4D-4A2F-A4C5-A769F5D7A7EF--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 28 Sep 2014 16:13:07 -0700
Raw View
On Monday 29 September 2014 05:05:04 David Krauss wrote:
> On 2014-09-29, at 2:22 AM, Thiago Macieira <thiago@macieira.org> wrote:
> > Perfectly valid code.
>
> Yes, but in this context "always-firing" means for any execution of the
> function. There is no problem with that example (if it were declared
> constexpr).
Right. It's a good QoI warning to have that "unreachable code is reached". The
compiler should tag failed assertion paths as unreachable code and warn if
they get reached.
How they do that, it should be their business, though. So, with that said, do
we need to do anything?
--
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: David Krauss <potswa@gmail.com>
Date: Mon, 29 Sep 2014 11:46:34 +0800
Raw View
--Apple-Mail=_02ADA186-D2C0-4C9C-B959-CC3EA3DDE42D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-29, at 7:13 AM, Thiago Macieira <thiago@macieira.org> wrote:
> Right. It's a good QoI warning to have that "unreachable code is reached"=
..
It seems like you mean QoI of a library, not C++ implementation QoI, but it=
's not clear. The compiler can't issue warnings at runtime.
This is quite different from the constexpr discussion.
> The=20
> compiler should tag failed assertion paths as unreachable code and warn i=
f=20
> they get reached.
Without NDEBUG, the assertion fires and the program aborts.
Given NDEBUG, and a non-constant condition, the program can't discern failu=
re from success because the controlling expression is unevaluated.
Given NDEBUG=3Dstrong and assert(false), the compiler could add something t=
o the unreachable path, but in the name of optimization, it would be more l=
ikely to eliminate the path instead.
> How they do that, it should be their business, though. So, with that said=
, do=20
> we need to do anything?
It sounds like you're asking for a version of assert which is unconditional=
and always works, even given NDEBUG. That would basically be a call to abo=
rt(), plus a diagnostic message. But the default diagnostics produced by as=
sert aren't suitable for production code anyway, since the stderr stream is=
unlikely to be going anywhere.
So that rules out all the special qualities of assert. You'd be better off =
with your own logging facility, which can also query NDEBUG, and production=
-worthy error recovery techniques.
--=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=_02ADA186-D2C0-4C9C-B959-CC3EA3DDE42D
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;09–29, at 7:13 AM, Thiago Macieira <<a href=3D"mailto:thiago=
@macieira.org">thiago@macieira.org</a>> wrote:</div><br class=3D"Apple-i=
nterchange-newline"><blockquote type=3D"cite">Right. It's a good QoI warnin=
g to have that "unreachable code is reached”. </blockquote><div><br><=
/div><div>It seems like you mean QoI of a library, not C++ implementation Q=
oI, but it’s not clear. The compiler can’t issue warnings at ru=
ntime.</div><div><br></div><div>This is quite different from the constexpr =
discussion.</div><br><blockquote type=3D"cite">The <br>compiler should tag =
failed assertion paths as unreachable code and warn if <br>they get reached=
..<br></blockquote><div><br></div><div>Without NDEBUG, the assertion fires a=
nd the program aborts.</div><div><br></div><div>Given NDEBUG, and a non-con=
stant condition, the program can’t discern failure from success becau=
se the controlling expression is unevaluated.</div><div><br></div><div>Give=
n NDEBUG=3Dstrong and <font face=3D"Courier">assert(false)</font>, the comp=
iler could add something to the unreachable path, but in the name of optimi=
zation, it would be more likely to eliminate the path instead.</div><br><bl=
ockquote type=3D"cite">How they do that, it should be their business, thoug=
h. So, with that said, do <br>we need to do anything?<br></blockquote>=
</div><br><div>It sounds like you’re asking for a version of assert w=
hich is unconditional and always works, even given NDEBUG. That would basic=
ally be a call to abort(), plus a diagnostic message. But the default diagn=
ostics produced by assert aren’t suitable for production code anyway,=
since the stderr stream is unlikely to be going anywhere.</div><div><br></=
div><div>So that rules out all the special qualities of assert. You’d=
be better off with your own logging facility, which can also query NDEBUG,=
and production-worthy error recovery techniques.</div><div><br></div></bod=
y></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=_02ADA186-D2C0-4C9C-B959-CC3EA3DDE42D--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 28 Sep 2014 21:51:13 -0700
Raw View
On Monday 29 September 2014 11:46:34 David Krauss wrote:
> On 2014-09-29, at 7:13 AM, Thiago Macieira <thiago@macieira.org> wrote:
> > Right. It's a good QoI warning to have that "unreachable code is reached".
>
> It seems like you mean QoI of a library, not C++ implementation QoI, but
> it's not clear. The compiler can't issue warnings at runtime.
>
> This is quite different from the constexpr discussion.
No, I really meant QoI of the C++ compiler implementation.
If it can show that the code execution will reach a failed assertion, it
should report that as a warning.
> > The
> > compiler should tag failed assertion paths as unreachable code and warn if
> > they get reached.
>
> Without NDEBUG, the assertion fires and the program aborts.
Indeed. But why not report it at compile time too, if the compiler can detect
what conditions will trigger it and it has reason to believe that the user-
code is not properly written?
> Given NDEBUG, and a non-constant condition, the program can't discern
> failure from success because the controlling expression is unevaluated.
Right, in that case, no diagnostic.
> Given NDEBUG=strong and assert(false), the compiler could add something to
> the unreachable path, but in the name of optimization, it would be more
> likely to eliminate the path instead.
I don't buy NDEBUG=strong because I think it's the wrong tool for the job.
assert is a macro, so changing NDEBUG after <cassert> has been included has no
effect.
That said, I do agree we should have a strong optimisation or dead code
elimination hint for the NDEBUG case, just probably not for assert().
> > How they do that, it should be their business, though. So, with that said,
> > do we need to do anything?
>
> It sounds like you're asking for a version of assert which is unconditional
> and always works, even given NDEBUG. That would basically be a call to
> abort(), plus a diagnostic message. But the default diagnostics produced by
> assert aren't suitable for production code anyway, since the stderr stream
> is unlikely to be going anywhere.
>
> So that rules out all the special qualities of assert. You'd be better off
> with your own logging facility, which can also query NDEBUG, and
> production-worthy error recovery techniques.
No, I'm not asking for an unconditional assert. NDEBUG simply controls what
happens at runtime.
But with or without NDEBUG, the compiler may use the fact that the user wrote
assert as a hint and it could produce a compile-time diagnostic when it
detects a condition leading to a failed assertion, like "if these two
conditions happen, your program will assert false; if that can't happen,
here's how you should modify your code".
--
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: David Krauss <potswa@gmail.com>
Date: Mon, 29 Sep 2014 13:11:05 +0800
Raw View
--Apple-Mail=_751155CF-7ECE-4747-8DBD-B6D4F4D9F5A8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-29, at 12:51 PM, Thiago Macieira <thiago@macieira.org> wrote:
> No, I really meant QoI of the C++ compiler implementation.
>=20
> If it can show that the code execution will reach a failed assertion, it=
=20
> should report that as a warning.
"Will" is a strong term. The compiler can warn at the slightest whiff of da=
nger, but unless it's called with a value out of bounds, I personally would=
n't want to be warned about your example function.
> Indeed. But why not report it at compile time too, if the compiler can de=
tect=20
> what conditions will trigger it and it has reason to believe that the use=
r-
> code is not properly written?
Sure, a static analyzer can lump assertions together with undefined behavio=
r.
> I don't buy NDEBUG=3Dstrong because I think it's the wrong tool for the j=
ob.=20
> assert is a macro, so changing NDEBUG after <cassert> has been included h=
as no=20
> effect.
The title of the proposal is "operator assert."
I could have proposed that redefining NDEBUG has immediate effect, but I we=
nt with the status quo that it takes effect when you include <assert.h>, pe=
rhaps via <cassert>. The main issue is that preprocessor state is inaccessi=
ble to the parser without a pragma. I could have proposed a pragma or other=
state adjustment, but we already have one, because assert is specified to =
be undefined and redefined by <assert.h>.
> That said, I do agree we should have a strong optimisation or dead code=
=20
> elimination hint for the NDEBUG case, just probably not for assert().
From where would hints be extracted if not from assert? I assume you mean f=
or any case, not only the NDEBUG case.
> But with or without NDEBUG, the compiler may use the fact that the user w=
rote=20
> assert as a hint and it could produce a compile-time diagnostic when it=
=20
> detects a condition leading to a failed assertion, like "if these two=20
> conditions happen, your program will assert false; if that can't happen,=
=20
> here's how you should modify your code".
Any possible "if that can't happen" precludes "will reach."
I'm not trying to introduce a contract paradigm. I'm just trying to let ass=
ert() do all it can do.
--=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=_751155CF-7ECE-4747-8DBD-B6D4F4D9F5A8
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;09–29, at 12:51 PM, Thiago Macieira <<a href=3D"mailto:thiag=
o@macieira.org">thiago@macieira.org</a>> wrote:</div><br class=3D"Apple-=
interchange-newline"><blockquote type=3D"cite">No, I really meant QoI of th=
e C++ compiler implementation.<br><br>If it can show that the code executio=
n will reach a failed assertion, it <br>should report that as a warning.<br=
></blockquote><div><br></div><div>“Will” is a strong term. The =
compiler can warn at the slightest whiff of danger, but unless it’s c=
alled with a value out of bounds, I personally wouldn’t want to be wa=
rned about your example function.</div><div><br></div><blockquote type=3D"c=
ite">Indeed. But why not report it at compile time too, if the compiler can=
detect <br>what conditions will trigger it and it has reason to believe th=
at the user-<br>code is not properly written?<br></blockquote><div><br></di=
v><div>Sure, a static analyzer can lump assertions together with undefined =
behavior.</div><br><blockquote type=3D"cite">I don't buy NDEBUG=3Dstrong be=
cause I think it's the wrong tool for the job. <br>assert is a macro, so ch=
anging NDEBUG after <cassert> has been included has no <br>effect.<br=
></blockquote><div><br></div><div>The title of the proposal is “<i>op=
erator</i> assert.”</div><div><br></div><div>I could have proposed th=
at redefining NDEBUG has immediate effect, but I went with the status quo t=
hat it takes effect when you include <assert.h>, perhaps via <cass=
ert>. The main issue is that preprocessor state is inaccessible to the p=
arser without a pragma. I could have proposed a pragma or other state adjus=
tment, but we already have one, because assert is specified to be undefined=
and redefined by <assert.h>.</div><br><blockquote type=3D"cite">That=
said, I do agree we should have a strong optimisation or dead code <br>eli=
mination hint for the NDEBUG case, just probably not for assert().<br></blo=
ckquote><div><br></div><div>From where would hints be extracted if not from=
assert? I assume you mean for any case, not only the NDEBUG case.</div><br=
><blockquote type=3D"cite">But with or without NDEBUG, the compiler may use=
the fact that the user wrote <br>assert as a hint and it could produc=
e a compile-time diagnostic when it <br>detects a condition leading to a fa=
iled assertion, like "if these two <br>conditions happen, your program will=
assert false; if that can't happen, <br>here's how you should modify your =
code”.<br></blockquote><div><br></div><div>Any possible “if tha=
t can’t happen” precludes “will reach.”</div></div>=
<br><div>I’m not trying to introduce a contract paradigm. I’m j=
ust trying to let assert() do all it can do.</div><div><br></div></body></h=
tml>
<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=_751155CF-7ECE-4747-8DBD-B6D4F4D9F5A8--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 28 Sep 2014 23:40:51 -0700
Raw View
On Monday 29 September 2014 13:11:05 David Krauss wrote:
> On 2014-09-29, at 12:51 PM, Thiago Macieira <thiago@macieira.org> wrote:
> > No, I really meant QoI of the C++ compiler implementation.
> >
> > If it can show that the code execution will reach a failed assertion, it
> > should report that as a warning.
>
> "Will" is a strong term. The compiler can warn at the slightest whiff of
> danger, but unless it's called with a value out of bounds, I personally
> wouldn't want to be warned about your example function.
Agreed, warnings should be printed only when there's clear reason for them and
the user can reasonably edit the code so it won't happen.
As a counter-example of this warning, take GCC's "X > X + c is always false"
warning.
> > I don't buy NDEBUG=strong because I think it's the wrong tool for the job.
> > assert is a macro, so changing NDEBUG after <cassert> has been included
> > has no effect.
>
> The title of the proposal is "operator assert."
Operators don't change according to macros either.
> I could have proposed that redefining NDEBUG has immediate effect, but I
> went with the status quo that it takes effect when you include <assert.h>,
> perhaps via <cassert>. The main issue is that preprocessor state is
> inaccessible to the parser without a pragma. I could have proposed a pragma
> or other state adjustment, but we already have one, because assert is
> specified to be undefined and redefined by <assert.h>.
I'm not sure what this accomplishes. We can't redefine NDEBUG and change
behaviour. So if you want to change the behaviour according to the section of
code, you need another function/macro.
And I'm saying I don't see why an operator is needed or what it could do that
a macro couldn't.
> > That said, I do agree we should have a strong optimisation or dead code
> > elimination hint for the NDEBUG case, just probably not for assert().
>
> From where would hints be extracted if not from assert? I assume you mean
> for any case, not only the NDEBUG case.
A new macro/function.
> > But with or without NDEBUG, the compiler may use the fact that the user
> > wrote assert as a hint and it could produce a compile-time diagnostic
> > when it detects a condition leading to a failed assertion, like "if these
> > two conditions happen, your program will assert false; if that can't
> > happen, here's how you should modify your code".
>
> Any possible "if that can't happen" precludes "will reach."
I meant in the sense of Clang suggestions to modify your code so the warning
isn't triggered.
> I'm not trying to introduce a contract paradigm. I'm just trying to let
> assert() do all it can do.
--
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: David Krauss <potswa@gmail.com>
Date: Mon, 29 Sep 2014 16:11:40 +0800
Raw View
--Apple-Mail=_5324CB18-767A-4298-9667-16C89B08DC7E
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-29, at 2:40 PM, Thiago Macieira <thiago@macieira.org> wrote:
> Operators don't change according to macros either.
C99 defines standard #pragmas which affect floating-point operators in much the same way as implementation-internal pragmas in my proposal affect my proposed operator.
> I'm not sure what this accomplishes. We can't redefine NDEBUG and change
> behaviour. So if you want to change the behaviour according to the section of
> code, you need another function/macro.
Yes we can, and that is the way NDEBUG has always worked. <assert.h> contains a #undef assert directive. You can redefine NDEBUG and re-include <assert.h> to your heart's content.
> And I'm saying I don't see why an operator is needed or what it could do that
> a macro couldn't.
Did you read the proposal? There's a whole section on how to emulate the operator with a macro, and how it may be a tolerable stopgap but still falls short.
>> From where would hints be extracted if not from assert? I assume you mean
>> for any case, not only the NDEBUG case.
>
> A new macro/function.
Then legacy code needs to be instrumented.
We already have platform-specific ways of doing this, such as __builtin_unreachable and __assume. There's plenty of usage experience with those, but I'm not familiar with standardization efforts so far.
Again, I want to extract as much value as possible from assert(), but I'm not trying for an end-all, be-all solution. There's more work to be done in expressing dynamic preconditions and postconditions.
--
---
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/.
--Apple-Mail=_5324CB18-767A-4298-9667-16C89B08DC7E
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;09–29, at 2:40 PM, Thiago Macieira <<a href=3D"mailto:thiago=
@macieira.org">thiago@macieira.org</a>> wrote:</div><br class=3D"Apple-i=
nterchange-newline"><blockquote type=3D"cite">Operators don't change accord=
ing to macros either.<br></blockquote><div><br></div>C99 defines standard #=
pragmas which affect floating-point operators in much the same way as imple=
mentation-internal pragmas in my proposal affect my proposed operator.</div=
><div><br><blockquote type=3D"cite">I'm not sure what this accomplishes. We=
can't redefine NDEBUG and change <br>behaviour. So if you want to change t=
he behaviour according to the section of <br>code, you need another functio=
n/macro.<br></blockquote><div><br></div><div>Yes we can, and that is the wa=
y NDEBUG has always worked. <assert.h> contains a <font face=3D"Couri=
er">#undef assert</font> directive. You can redefine NDEBUG and re-include =
<assert.h> to your heart’s content.</div><br><blockquote type=
=3D"cite">And I'm saying I don't see why an operator is needed or what it c=
ould do that <br>a macro couldn’t.<br></blockquote><div><br></di=
v><div>Did you read the proposal? There’s a whole section on how to e=
mulate the operator with a macro, and how it may be a tolerable stopgap but=
still falls short.</div><br><blockquote type=3D"cite"><blockquote type=3D"=
cite">From where would hints be extracted if not from assert? I assume you =
mean<br>for any case, not only the NDEBUG case.<br></blockquote><br>A new m=
acro/function.<br></blockquote><div><br></div><div>Then legacy code needs t=
o be instrumented.</div><div><br></div><div>We already have platform-specif=
ic ways of doing this, such as __builtin_unreachable and __assume. There&rs=
quo;s plenty of usage experience with those, but I’m not familiar wit=
h standardization efforts so far.</div><div><br></div><div>Again, I want to=
extract as much value as possible from assert(), but I’m not trying =
for an end-all, be-all solution. There’s more work to be done in expr=
essing dynamic preconditions and postconditions.</div></div><br></body></ht=
ml>
<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=_5324CB18-767A-4298-9667-16C89B08DC7E--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 29 Sep 2014 12:13:15 +0200
Raw View
On Mon, Sep 29, 2014 at 5:46 AM, David Krauss <potswa@gmail.com> wrote:
> It sounds like you=E2=80=99re asking for a version of assert which is unc=
onditional
> and always works, even given NDEBUG. That would basically be a call to
> abort(), plus a diagnostic message. But the default diagnostics produced =
by
> assert aren=E2=80=99t suitable for production code anyway, since the stde=
rr stream
> is unlikely to be going anywhere.
Is assert() required to use stderr? MSVC for example pops up a message
box. It could also hook into automatic error reporting.
Maybe the implementation even allows you to hook the assert handler.
> So that rules out all the special qualities of assert. You=E2=80=99d be b=
etter off
> with your own logging facility, which can also query NDEBUG, and
> production-worthy error recovery techniques.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3500.txt
Something like assure is what I'm looking for quite often, especially
in 'prototyping' etc code.
Of course one is free to write "production-worthy error recovery
techniques" but I really think sometimes assure is appropriate and as
simple as possible.
--=20
Olaf
--=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: David Krauss <potswa@gmail.com>
Date: Mon, 29 Sep 2014 21:43:03 +0800
Raw View
--Apple-Mail=_9D24C97D-DBFF-44C4-822D-2011FC9D710E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-29, at 6:13 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> Is assert() required to use stderr? MSVC for example pops up a message
> box.
Yes, it's specified that way in the C standard. I don't use Windows; perhap=
s that's simply what stderr does? Or, maybe that aspect of compliance isn't=
to their taste. Anyway, I don't intend to break anything, except for line-=
noise allowed by the quirkiness of preprocessor argument parsing.
> It could also hook into automatic error reporting.
> Maybe the implementation even allows you to hook the assert handler.
I've proposed:
If you supply no diagnostic information, a message will be generated just a=
s assert already does.
If you supply a string literal, it will be used for the message.
Otherwise, if you supply some expression besides a string literal, it simpl=
y gets evaluated before the abort() call.
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3500.txt
>=20
> Something like assure is what I'm looking for quite often, especially
> in 'prototyping' etc code.
Why would you define NDEBUG while prototyping?
> Of course one is free to write "production-worthy error recovery
> techniques" but I really think sometimes assure is appropriate and as
> simple as possible.
It sounds like you might want asserts to apply in your code, but you don't =
want it to be bogged down by the debugging stdlib.
You can already do this by #undefining NDEBUG after #including the standard=
headers, and then #including <cassert>.
--=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=_9D24C97D-DBFF-44C4-822D-2011FC9D710E
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;09–29, at 6:13 PM, Olaf van der Spek <<a href=3D"mailto:olaf=
vdspek@gmail.com">olafvdspek@gmail.com</a>> wrote:</div><br class=3D"App=
le-interchange-newline"><blockquote type=3D"cite">Is assert() required to u=
se stderr? MSVC for example pops up a message<br>box. </blockquote><div><br=
></div><div>Yes, it’s specified that way in the C standard. I don&rsq=
uo;t use Windows; perhaps that’s simply what stderr does? Or, maybe t=
hat aspect of compliance isn’t to their taste. Anyway, I don’t =
intend to break anything, except for line-noise allowed by the quirkiness o=
f preprocessor argument parsing.</div><br><blockquote type=3D"cite">It coul=
d also hook into automatic error reporting.<br>Maybe the implementation eve=
n allows you to hook the assert handler.<br></blockquote><div><br></div><di=
v>I’ve proposed:</div><div><br></div><div><ul class=3D"MailOutline"><=
li>If you supply no diagnostic information, a message will be generated jus=
t as assert already does.</li><li>If you supply a string literal, it will b=
e used for the message.</li><li>Otherwise, if you supply some expression be=
sides a string literal, it simply gets evaluated before the abort() call.</=
li></ul></div><div><br></div><blockquote type=3D"cite"><a href=3D"http://ww=
w.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3500.txt">http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2013/n3500.txt</a><br><br>Something like =
assure is what I'm looking for quite often, especially<br>in 'prototyping' =
etc code.<br></blockquote><div><br></div><div>Why would you define NDEBUG w=
hile prototyping?</div><br><blockquote type=3D"cite">Of course one is free =
to write "production-worthy error recovery<br>techniques" but I really thin=
k sometimes assure is appropriate and as<br>simple as possible.<br></blockq=
uote></div><br><div>It sounds like you might want asserts to apply in your =
code, but you don’t want it to be bogged down by the debugging stdlib=
..</div><div><br></div><div>You can already do this by #undefining NDEBUG af=
ter #including the standard headers, and then #including <cassert>.</=
div><div><br></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=_9D24C97D-DBFF-44C4-822D-2011FC9D710E--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Mon, 29 Sep 2014 08:09:03 -0700 (PDT)
Raw View
------=_Part_104_1484707725.1412003343326
Content-Type: text/plain; charset=UTF-8
This seems like a good way to give optimization hints to the compiler with
the added benefit of a runtime assertion for debug builds. A few use cases
I can think of right away:
void foo(int& a, int& b) {
assert(&a != &b, "a and b cannot alias one another!");
//Compiler can assume from here on there is no aliasing, equivalent to
using restrict.
}
int bar(int x) {
assert(x != 0);
int b = count_trailing_zeroes(x); //single bsf instruction on intel,
which is not defined when x is 0
//....
}
void process_simd(char* s) {
assert(is_aligned(s, 16));
auto x = simd_load(s); //Compiler can do a faster aligned simd load here
//...
}
I mentioned this in another thread, and perhaps its another proposal but
would also be great is assert specifications on functions to specify their
preconditions. These would be evaluated at the call site before the
function is called.
constexpr int bar(int x) assert(x != 0);
int x = 1;
bar(x); //Runtime assert failure, also possibly a compiler warning
bar(1); //Compile time 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_104_1484707725.1412003343326
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This seems like a good way to give optimization hints to t=
he compiler with the added benefit of a runtime assertion for debug builds.=
A few use cases I can think of right away:<br><br><div class=3D"prettyprin=
t" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 18=
7, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">assert</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(&</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>a </span><span style=3D"color: #660;" class=3D"styled-by-prettify">!=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">&</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">b</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D=
"styled-by-prettify">"a and b cannot alias one another!"</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br> </span><span style=3D"col=
or: #800;" class=3D"styled-by-prettify">//Compiler can assume from here on =
there is no aliasing, equivalent to using restrict.</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> bar</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br> </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">assert</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">x </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">!=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> b </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> count_trailing_zeroes</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">//single bsf instruction on intel, which is not defined wh=
en x is 0</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">=
//....</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> process_simd</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> s</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">assert<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">is_aligned</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">s</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">16</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">));</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> simd_load</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">s</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">//Compiler can do a faster aligned simd load here=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">//...</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><br>I mentioned this in another thread, and perhaps its another proposal =
but would also be great is assert specifications on functions to specify th=
eir preconditions. These would be evaluated at the call site before the fun=
ction is called.<br><br><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">constexpr</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> bar<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">assert</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">x </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">!=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> x </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"sty=
led-by-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>bar</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">//Runtime assert failure</span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">, also possibly a compi=
ler warning</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br><br>bar</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">//Compile time error</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span></div></=
code></div><br><br></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_104_1484707725.1412003343326--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Mon, 29 Sep 2014 08:12:39 -0700 (PDT)
Raw View
------=_Part_1374_662593836.1412003559608
Content-Type: text/plain; charset=UTF-8
Typo on this:
constexpr int bar(int x) assert(x != 0);
>
> int x = 0;
> bar(x); //Runtime assert failure, also possibly a compiler warning
>
> bar(0); //Compile time 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_1374_662593836.1412003559608
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>Typo on this:<br><br><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"><div style=3D"background-color:rgb(250,250,250=
);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wr=
ap:break-word"><code><div><span style=3D"color:#008">constexpr</span><span =
style=3D"color:#000"> </span><span style=3D"color:#008">int</span><span sty=
le=3D"color:#000"> bar</span><span style=3D"color:#660">(</span><span style=
=3D"color:#008">int</span><span style=3D"color:#000"> x</span><span style=
=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">assert</span><span style=3D"color:#660">(</span><span style=3D"c=
olor:#000">x </span><span style=3D"color: rgb(102, 102, 0);">!=3D</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#066">0</span><span st=
yle=3D"color:#660">);</span><span style=3D"color:#000"><br><br></span><span=
style=3D"color:#008">int</span><span style=3D"color:#000"> x </span><span =
style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#066">0</span><span style=3D"color:#660">;</span><span style=3D=
"color:#000"><br>bar</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">x</span><span style=3D"color:#660">);</span><span style=3D"=
color:#000"> </span><span style=3D"color:#800">//Runtime assert failure</sp=
an><span style=3D"color:#800">, also possibly a compiler warning</span><spa=
n style=3D"color:#000"><br><br>bar</span><span style=3D"color:#660">(</span=
><span style=3D"color:#066">0</span><span style=3D"color:#660">);</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#800">//Compile time e=
rror</span><span style=3D"color:#000"><br><br></span></div></code></div><br=
><br></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_1374_662593836.1412003559608--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 29 Sep 2014 23:20:27 +0800
Raw View
--Apple-Mail=_E9A16360-327A-4D77-A953-9B02A08EEBAC
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-29, at 11:09 PM, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
> I mentioned this in another thread, and perhaps its another proposal but would also be great is assert specifications on functions to specify their preconditions. These would be evaluated at the call site before the function is called.
Yeah, I touched on this design direction in the "future work" section.
By the way, the latest update which has been posted is the formal submission.
Thanks all for the comments!
--
---
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/.
--Apple-Mail=_E9A16360-327A-4D77-A953-9B02A08EEBAC
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;09–29, at 11:09 PM, Matthew Fioravante <<a href=3D"mailto:fm=
atthew5876@gmail.com">fmatthew5876@gmail.com</a>> wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span style=3D"fon=
t-family: Helvetica; font-size: 12px; font-style: normal; font-variant: nor=
mal; font-weight: normal; letter-spacing: normal; line-height: normal; orph=
ans: auto; text-align: start; text-indent: 0px; text-transform: none; white=
-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width:=
0px; float: none; display: inline !important;">I mentioned this in another=
thread, and perhaps its another proposal but would also be great is assert=
specifications on functions to specify their preconditions. These would be=
evaluated at the call site before the function is called.</span><br 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;"></blockquote></div><br><div>Yeah, I touched on this design di=
rection in the “future work” section.</div><div><br></div><div>=
By the way, the latest update which has been posted is the formal submissio=
n.</div><div><br></div><div>Thanks all for the comments!</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=_E9A16360-327A-4D77-A953-9B02A08EEBAC--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 29 Sep 2014 09:17:30 -0700
Raw View
On Monday 29 September 2014 16:11:40 David Krauss wrote:
> >> From where would hints be extracted if not from assert? I assume you mean
> >> for any case, not only the NDEBUG case.
> >
> > A new macro/function.
>
> Then legacy code needs to be instrumented.
Yes, and that should be the intention.
It's a partial behaviour change, so why shouldn't library authors get to
decide what they want to happen to their code?
--
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: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 29 Sep 2014 22:52:29 +0200
Raw View
On Mon, Sep 29, 2014 at 3:43 PM, David Krauss <potswa@gmail.com> wrote:
> Why would you define NDEBUG while prototyping?
Performance
> It sounds like you might want asserts to apply in your code, but you don=
=E2=80=99t
> want it to be bogged down by the debugging stdlib.
>
> You can already do this by #undefining NDEBUG after #including the standa=
rd
> headers, and then #including <cassert>.
I know, but IMO that's very ugly. I'd like to be able to decide on an
assert by assert basis. Using different names for the different
functionality seems best.
--=20
Olaf
--=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: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Mon, 29 Sep 2014 17:05:23 -0700 (PDT)
Raw View
------=_Part_3538_1724187865.1412035523122
Content-Type: text/plain; charset=UTF-8
How effectively do you think this feature can be applied to solving the
question of programmer controlled aliasing constraints?
C has restrict and there has always been the open question of adopting it
for C++. (I think we should for compatibility because it would be wrong
headed to use the same keyword restrict with different non-C compatable
syntax.) I remember a few proposals talking about different solutions to
the aliasing problem.
Specifying aliasing is actually complex. Sometimes its not so simple
because there are a lot of possibilities. Using assert() would allow you to
specify aliasing constraints precisely in a declarative form with automatic
debug runtime enforcement. People get scared of restrict because of the
kinds of bugs it can allow for. Using assert() would allow all of these
violations to be checked automatically in debug builds.
void transform(void* a, void* b);
template <typename A, typename B> void transform(std::array_view<A*> a, std
::array_view<B*>);
There could be many specific relationships we which to enforce, such as:
assert(a != b); //restrict symantics
assert(a <= b); //copy-left-to-right symantics
assert(b >= a); //copy-right-to-left symantics
assert(a.end() <= b.begin() || b.end() <= a.begin()); //AoS symantics
Future Work from here:
- create a higher level restrict() declarative prodecural library built
on top of operator assert() primitives to easily specify common pollicies
like above.
- restrict containers / tuples for passing around collections of
pointers which share aliasing constraints, to enforce those constraints on
the group. Possibly this could be hooked into allocators?
- restrict specifications on function pre-conditions, using function
assert specifications.
--
---
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_3538_1724187865.1412035523122
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">How effectively do you think this feature can be applied t=
o solving the question of programmer controlled aliasing constraints? =
<div><br></div><div>C has restrict and there has always been the open quest=
ion of adopting it for C++. (I think we should for compatibility because it=
would be wrong headed to use the same keyword restrict with different non-=
C compatable syntax.) I remember a few proposals talking about different so=
lutions to the aliasing problem.</div><div><br></div><div>Specifying aliasi=
ng is actually complex. Sometimes its not so simple because there are a lot=
of possibilities. Using assert() would allow you to specify aliasing const=
raints precisely in a declarative form with automatic debug runtime enforce=
ment. People get scared of restrict because of the kinds of bugs it can all=
ow for. Using assert() would allow all of these violations to be checked au=
tomatically in debug builds.</div><div><br></div><div><div class=3D"prettyp=
rint" style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(=
187, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
transform</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">void</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> b</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">template</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> A</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> B</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">></span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">void=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> transform=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">array_view</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify"><</span><font color=3D"#000088"=
><span style=3D"color: #000;" class=3D"styled-by-prettify">A</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">*></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> a</span></font><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">array_view</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">B</span><font color=3D"#666600"><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">*>);</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span></font></div></code></div><div><br></=
div>There could be many specific relationships we which to enforce, such as=
:</div><div><br></div><div><div class=3D"prettyprint" style=3D"background-c=
olor: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">assert</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">a </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">!=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">//restrict symantics</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">assert</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a </spa=
n><font color=3D"#666600"><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><=3D</span></font><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> b</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #800;" class=3D"styled-by-prettify">//copy-left-=
to-right symantics</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">assert</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">b </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">>=3D</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;"=
class=3D"styled-by-prettify">//copy-right-to-left symantics</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">assert</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">a</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">end</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">begin</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><font color=3D"#666600"><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">||</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">.</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">end</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
<=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">begin</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">());</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
800;" class=3D"styled-by-prettify">//AoS symantics</span></font><font color=
=3D"#666600"></font></div></code></div> </div><div>Future Work from he=
re:</div><div><ul><li><span style=3D"line-height: normal;">create a higher =
level restrict() declarative prodecural library built on top of operator as=
sert() primitives to easily specify common pollicies like above.</span></li=
><li><span style=3D"line-height: normal;">restrict containers / tuples for =
passing around collections of pointers which share aliasing constraints, to=
enforce those constraints on the group. Possibly this could be hooked into=
allocators?</span></li><li><span style=3D"line-height: normal;">restrict s=
pecifications on function pre-conditions, using function assert specificati=
ons.</span></li></ul></div><div><br><br></div><div><br><br></div><div><br><=
/div><div><br></div><div><br></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_3538_1724187865.1412035523122--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Mon, 29 Sep 2014 17:13:27 -0700 (PDT)
Raw View
------=_Part_3333_396393197.1412036007760
Content-Type: text/plain; charset=UTF-8
On Monday, September 29, 2014 9:05:23 PM UTC-3, Matthew Fioravante wrote:
>
> How effectively do you think this feature can be applied to solving the
> question of programmer controlled aliasing constraints?
>
I think that it would be too hard for implementations to understand that.
MSVC implements the most complete mechanism that ideally would be able to
implement what you suggested, thru it's assume__ intrinsic,
but unfortunately it's not able to do anything with complex expressions
like those.
--
---
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_3333_396393197.1412036007760
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, September 29, 2014 9:05:23 PM UTC-3, Matthew Fi=
oravante 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=
">How effectively do you think this feature can be applied to solving the q=
uestion of programmer controlled aliasing constraints? </div></blockqu=
ote><div><br>I think that it would be too hard for implementations to under=
stand that.<br><br>MSVC implements the most complete mechanism that ideally=
would be able to implement what you suggested, thru it's assume__ intrinsi=
c,<br>but unfortunately it's not able to do anything with complex expressio=
ns like those.<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_3333_396393197.1412036007760--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 30 Sep 2014 08:54:05 +0800
Raw View
--Apple-Mail=_3747DDEA-4EE3-4065-BD5E-01192A77E736
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-30, at 8:05 AM, Matthew Fioravante <fmatthew5876@gmail.com> wrot=
e:
> How effectively do you think this feature can be applied to solving the q=
uestion of programmer controlled aliasing constraints?=20
Who, me? I wouldn't know more than the next guy. Well, I just reviewed rest=
rict now, but as I said in the proposal, "no particular considerations have=
been made in this regard."
> C has restrict and there has always been the open question of adopting it=
for C++. (I think we should for compatibility because it would be wrong he=
aded to use the same keyword restrict with different non-C compatable synta=
x.) I remember a few proposals talking about different solutions to the ali=
asing problem.
>=20
> Specifying aliasing is actually complex. Sometimes its not so simple beca=
use there are a lot of possibilities. Using assert() would allow you to spe=
cify aliasing constraints precisely in a declarative form with automatic de=
bug runtime enforcement. People get scared of restrict because of the kinds=
of bugs it can allow for. Using assert() would allow all of these violatio=
ns to be checked automatically in debug builds.
assert would check the condition that it enforces, but that condition is mu=
ch, much weaker than what restrict implies.
My impression is that restrict is hard to understand because guarantees tha=
t are strong enough to be actionable by the compiler are intrinsically hard=
to grasp. Also, as far as I understand, restrict was formally adopted in C=
a long time before it actually became useful in practice, and some may sti=
ll debate its utility.
That said, restrict really should be adopted. It can be "implemented" by ig=
noring it, after all, and the keyword reservation will need to happen soone=
r or later.
> Future Work from here:
> create a higher level restrict() declarative prodecural library built on =
top of operator assert() primitives to easily specify common pollicies like=
above.
That doesn't sound feasible. restrict makes a guarantee about all lvalues e=
valuated in the scope of the variable it modifies, and all values that its =
variable has over its lifetime.
> restrict containers / tuples for passing around collections of pointers w=
hich share aliasing constraints, to enforce those constraints on the group.=
Possibly this could be hooked into allocators?
I think the more pressing issue is allowing restrict to be applied to itera=
tors.
> restrict specifications on function pre-conditions, using function assert=
specifications.
It's an interesting area, but personally I'd prefer to see more work on som=
e state of the art, such as N3997 (which I haven't read through and can't y=
et endorse, but looks reasonable at a glance), than a seemingly simple and =
self-contained proposal.
--=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=_3747DDEA-4EE3-4065-BD5E-01192A77E736
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;09–30, at 8:05 AM, Matthew Fioravante <<a href=3D"mailto:fma=
tthew5876@gmail.com">fmatthew5876@gmail.com</a>> wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">H=
ow effectively do you think this feature can be applied to solving the ques=
tion of programmer controlled aliasing constraints? </div></blockquote=
><div><br></div><div>Who, me? I wouldn’t know more than the next guy.=
Well, I just reviewed <font face=3D"Courier">restrict</font> now, but as I=
said in the proposal, "no particular considerations have been made in this=
regard."</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>C has re=
strict and there has always been the open question of adopting it for C++. =
(I think we should for compatibility because it would be wrong headed to us=
e the same keyword restrict with different non-C compatable syntax.) I reme=
mber a few proposals talking about different solutions to the aliasing prob=
lem.</div></div></blockquote><blockquote type=3D"cite"><br></blockquote><bl=
ockquote type=3D"cite"><div dir=3D"ltr"><div>Specifying aliasing is actuall=
y complex. Sometimes its not so simple because there are a lot of possibili=
ties. Using assert() would allow you to specify aliasing constraints precis=
ely in a declarative form with automatic debug runtime enforcement. People =
get scared of restrict because of the kinds of bugs it can allow for. Using=
assert() would allow all of these violations to be checked automatically i=
n debug builds.</div></div></blockquote><div><br></div><div><font face=3D"C=
ourier">assert</font> would check the condition that it enforces, but that =
condition is much, much weaker than what <font face=3D"Courier">restri=
ct</font> implies.</div><div><br></div><div>My impression is that =
;<span style=3D"font-family: Courier;">restrict</span> is hard to unde=
rstand because guarantees that are strong enough to be actionable by the co=
mpiler are intrinsically hard to grasp. Also, as far as I understand, =
<span style=3D"font-family: Courier;">restrict</span> was formally ado=
pted in C a long time before it actually became useful in practice, and som=
e may still debate its utility.</div><div><br></div><div>That said, <f=
ont face=3D"Courier">restrict</font> really should be adopted. It can =
be “implemented” by ignoring it, after all, and the keyword res=
ervation will need to happen sooner or later.</div><br><blockquote type=3D"=
cite"><div dir=3D"ltr"><div></div><div>Future Work from here:</div><div><ul=
><li><span style=3D"line-height: normal;">create a higher level restrict() =
declarative prodecural library built on top of operator assert() primitives=
to easily specify common pollicies like above.</span></li></ul></div></div=
></blockquote><div>That doesn’t sound feasible. <font face=3D"Courier=
">restrict</font> makes a guarantee about all lvalues evaluated in the scop=
e of the variable it modifies, and all values that its variable has over it=
s lifetime.</div><blockquote type=3D"cite"><div dir=3D"ltr"><div><ul><li><s=
pan style=3D"line-height: normal;">restrict containers / tuples for passing=
around collections of pointers which share aliasing constraints, to enforc=
e those constraints on the group. Possibly this could be hooked into alloca=
tors?</span></li></ul></div></div></blockquote><div>I think the more pressi=
ng issue is allowing <font face=3D"Courier">restrict</font> to be applied t=
o iterators.</div><blockquote type=3D"cite"><div dir=3D"ltr"><div><ul><li><=
span style=3D"line-height: normal;">restrict specifications on function pre=
-conditions, using function assert specifications.</span></li></ul></div></=
div></blockquote>It’s an interesting area, but personally I’d p=
refer to see more work on some state of the art, such as N3997 (which I hav=
en’t read through and can’t yet endorse, but looks reasonable a=
t a glance), than a seemingly simple and self-contained proposal.</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=_3747DDEA-4EE3-4065-BD5E-01192A77E736--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Mon, 29 Sep 2014 18:19:02 -0700 (PDT)
Raw View
------=_Part_1074_311956978.1412039942809
Content-Type: text/plain; charset=UTF-8
Aliasing control (keyword restrict being one varienty) is useful in some
domains:
http://cellperformance.beyond3d.com/articles/2006/05/demystifying-the-restrict-keyword.html
The restrict keyword also works well as a cvr (const volatile restrict)
qualifier in that it expresses a constraint and the type system helps you
enforce it, similar to const and volatile.
The interesting thing is that specifying aliasing constraints using
assert() falls out automatically from your proposal. There is no new
proposal to be written here. Compilers are allowed and encouraged to
optimize based on the assertions. So if you specify that 2 pointers don't
alias in a particular way, this paper allows that the optimizer can try to
omit redundant writes and data dependencies by checking whether it can
prove that the pointer operations being performed cannot possible violate
the aliasing constraints. At worse case, it's just a debug runtime check
and no actual optimization.
--
---
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_1074_311956978.1412039942809
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Aliasing control (keyword restrict being one varienty=
) is useful in some domains:</div><div>http://cellperformance.beyond3d.com/=
articles/2006/05/demystifying-the-restrict-keyword.html<br></div><div><br><=
/div><div>The restrict keyword also works well as a cvr (const volatile res=
trict) qualifier in that it expresses a constraint and the type system help=
s you enforce it, similar to const and volatile.</div><div><br></div>The in=
teresting thing is that specifying aliasing constraints using assert() fall=
s out automatically from your proposal. There is no new proposal to be writ=
ten here. Compilers are allowed and encouraged to optimize based on the ass=
ertions. So if you specify that 2 pointers don't alias in a particular way,=
this paper allows that the optimizer can try to omit redundant writes and =
data dependencies by checking whether it can prove that the pointer operati=
ons being performed cannot possible violate the aliasing constraints. At wo=
rse case, it's just a debug runtime check and no actual optimization.</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_1074_311956978.1412039942809--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Mon, 29 Sep 2014 22:32:32 -0300
Raw View
--047d7b5d89aba88b8f05043e5c1b
Content-Type: text/plain; charset=UTF-8
On Mon, Sep 29, 2014 at 10:19 PM, Matthew Fioravante <fmatthew5876@gmail.com
> wrote:
> The interesting thing is that specifying aliasing constraints using
> assert() falls out automatically from your proposal. There is no new
> proposal to be written here. Compilers are allowed and encouraged to
> optimize based on the assertions. So if you specify that 2 pointers don't
> alias in a particular way, this paper allows that the optimizer can try to
> omit redundant writes and data dependencies by checking whether it can
> prove that the pointer operations being performed cannot possible violate
> the aliasing constraints. At worse case, it's just a debug runtime check
> and no actual optimization.
>
Sure, assert would allow it, but it doesn't help anything if it's too hard
to implement restrict semantics that way.
A proposal like
http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2013/n3635.pdf would
still have more value because it tackles the problem in a more 'realistic'
and usable way.
--
---
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/.
--047d7b5d89aba88b8f05043e5c1b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Sep 29, 2014 at 10:19 PM, Matthew Fioravante <span dir=3D"ltr"><<a h=
ref=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.=
com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">The interesting thing is that specifying aliasing constraints using asser=
t() falls out automatically from your proposal. There is no new proposal to=
be written here. Compilers are allowed and encouraged to optimize based on=
the assertions. So if you specify that 2 pointers don't alias in a par=
ticular way, this paper allows that the optimizer can try to omit redundant=
writes and data dependencies by checking whether it can prove that the poi=
nter operations being performed cannot possible violate the aliasing constr=
aints. At worse case, it's just a debug runtime check and no actual opt=
imization.</div></blockquote><div><br></div><div>Sure, assert would allow i=
t, but it doesn't help anything if it's too hard to implement restr=
ict semantics that way.<br><br></div><div>A proposal like <a href=3D"http:/=
/www.open-std.org/Jtc1/sc22/wg21/docs/papers/2013/n3635.pdf">http://www.ope=
n-std.org/Jtc1/sc22/wg21/docs/papers/2013/n3635.pdf</a> would still have mo=
re value because it tackles the problem in a more 'realistic' and u=
sable way.<br></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 />
--047d7b5d89aba88b8f05043e5c1b--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 30 Sep 2014 09:50:01 +0800
Raw View
On 2014-09-30, at 9:19 AM, Matthew Fioravante <fmatthew5876@gmail.com> wrot=
e:
> Aliasing control (keyword restrict being one varienty) is useful in some =
domains:
> http://cellperformance.beyond3d.com/articles/2006/05/demystifying-the-res=
trict-keyword.html
>=20
> The restrict keyword also works well as a cvr (const volatile restrict) q=
ualifier in that it expresses a constraint and the type system helps you en=
force it, similar to const and volatile.
restrict cannot modify a type because it is not allowed to change program s=
emantics. (Actually, standardizing [[restrict]] might be a viable option.)
> The interesting thing is that specifying aliasing constraints using asser=
t() falls out automatically from your proposal.
To be clear, I do not endorse such a statement. The intent is to opportunis=
tically expose some such optimizations, but implementations should be conse=
rvative and allow users to opt-in to strong mode after reading an informati=
ve warning.
Even strict mode will break a lot of users' code, depending on their curren=
t practices, and that implies some migration process.
> There is no new proposal to be written here. Compilers are allowed and en=
couraged to optimize based on the assertions. So if you specify that 2 poin=
ters don't alias in a particular way, this paper allows that the optimizer =
can try to omit redundant writes and data dependencies by checking whether =
it can prove that the pointer operations being performed cannot possible vi=
olate the aliasing constraints. At worse case, it's just a debug runtime ch=
eck and no actual optimization.
I don't know what fraction of pointer inequality assertions are likely to p=
rovide a real optimization, but it might not be very high. Users should be =
encouraged to validate their code as best as possible, but saying it's an o=
ptimization when the chances may be slim is ethically questionable.
assert is far less powerful than restrict or any other purpose-designed fea=
ture. It's a pocket-knife compared to a jackhammer. I just want to provide =
a steel pocket-knife instead of one carved from flint.
--=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: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 2 Oct 2014 02:40:03 -0700 (PDT)
Raw View
------=_Part_175_1771117156.1412242803767
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu niedziela, 28 wrze=C5=9Bnia 2014 10:32:18 UTC+2 u=C5=BCytkownik Davi=
d Krauss=20
napisa=C5=82:
>
> Inspired by the recent =E2=80=9Cconstexpr assert=E2=80=9D thread, I=E2=80=
=99ve written a short=20
> proposal to make assert an operator. The user selects the novel=20
> functionality using e.g. -DNDEBUG=3Dstrong .
>
> No standardese yet, but I wonder if the proposal is complete enough=20
> without it?
>
Hi, I have got two small questions regarding the proposal.
1.=20
This form: assert ( assignment-expression , assignment-expression ), with=
=20
two expressions, what do you intend the second expression to be?=20
2. In section 2.1, I read "[...] and furthermore assume that the entire=20
first operand evaluates to *false*. (If the first
operand would evaluate to *true*, the behavior is undefined.)" I do not=20
understand it. Should it not be the inverse: assume that it will evaluate=
=20
to true, and if it evaluates to false it means UB?
--=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_175_1771117156.1412242803767
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu niedziela, 28 wrze=C5=9Bnia 2014 10:32:18 U=
TC+2 u=C5=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div style=3D"word-wrap:break-word">Inspired by the recent=
=E2=80=9Cconstexpr assert=E2=80=9D thread, I=E2=80=99ve written a short pr=
oposal to make assert an operator. The user selects the novel functionality=
using e.g. <font face=3D"Courier">-DNDEBUG=3Dstrong</font> .<div><br>=
</div><div>No standardese yet, but I wonder if the proposal is complete eno=
ugh without it?</div></div></blockquote><div><br>Hi, I have got two small q=
uestions regarding the proposal.<br><br>1. <br>This form: assert ( assignme=
nt-expression , assignment-expression ), with two expressions, what do you =
intend the second expression to be? <br><br>2. In section 2.1, I read "[...=
] and furthermore assume that the entire first operand evaluates to <b>fals=
e</b>. (If the first<br>operand would evaluate to <b>true</b>, the behavior=
is undefined.)" I do not understand it. Should it not be the inverse: assu=
me that it will evaluate to true, and if it evaluates to false it means UB?=
<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_175_1771117156.1412242803767--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 2 Oct 2014 18:23:54 +0800
Raw View
--Apple-Mail=_F62DBCFF-A668-49AF-A1EA-810C7FA9104D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On 2014=E2=80=9310=E2=80=9302, at 5:40 PM, Andrzej Krzemie=C5=84ski <akrzem=
i1@gmail.com> wrote:
> 1.=20
> This form: assert ( assignment-expression , assignment-expression ), with=
two expressions, what do you intend the second expression to be?=20
From the paragraph preceding the grammar, "it is simply evaluated to produc=
e the diagnostic.=E2=80=9D
> 2. In section 2.1, I read "[...] and furthermore assume that the entire f=
irst operand evaluates to false. (If the first
> operand would evaluate to true, the behavior is undefined.)" I do not und=
erstand it. Should it not be the inverse: assume that it will evaluate to t=
rue, and if it evaluates to false it means UB?
Yes, this is an erratum. I never noticed this, and it=E2=80=99s too late to=
fix it now :( . Thanks for pointing it out, though.
--=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=_F62DBCFF-A668-49AF-A1EA-810C7FA9104D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;"><br><div><div>On 2014=E2=80=
=9310=E2=80=9302, at 5:40 PM, Andrzej Krzemie=C5=84ski <<a href=3D"mailt=
o:akrzemi1@gmail.com">akrzemi1@gmail.com</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">1.&nbs=
p;<br><div>This form: assert ( assignment-expression , assignment-expressio=
n ), with two expressions, what do you intend the second expression to be? =
<br></div></div></blockquote><div><br></div>From the paragraph preceding th=
e grammar, "it is simply evaluated to produce the diagnostic.=E2=80=9D=
</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>2. In sectio=
n 2.1, I read "[...] and furthermore assume that the entire first operand e=
valuates to <b>false</b>. (If the first<br>operand would evaluate to <b>tru=
e</b>, the behavior is undefined.)" I do not understand it. Should it not b=
e the inverse: assume that it will evaluate to true, and if it evaluates to=
false it means UB?<br></div></div></blockquote><div><br></div><div>Yes, th=
is is an erratum. I never noticed this, and it=E2=80=99s too late to fix it=
now :( . Thanks for pointing it out, though.</div></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=_F62DBCFF-A668-49AF-A1EA-810C7FA9104D--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 2 Oct 2014 04:00:32 -0700 (PDT)
Raw View
------=_Part_3683_1489768575.1412247632957
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 2 pa=C5=BAdziernika 2014 12:24:11 UTC+2 u=C5=BCytkownik Da=
vid Krauss=20
napisa=C5=82:
>
>
> On 2014=E2=80=9310=E2=80=9302, at 5:40 PM, Andrzej Krzemie=C5=84ski <akrz=
....@gmail.com=20
> <javascript:>> wrote:
>
> 1.=20
> This form: assert ( assignment-expression , assignment-expression ), with=
=20
> two expressions, what do you intend the second expression to be?=20
>
>
> From the paragraph preceding the grammar, "it is simply evaluated to=20
> produce the diagnostic.=E2=80=9D
>
Do you mean it is a constant expression that evaluates to something of type=
=20
const char * ?
--=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_3683_1489768575.1412247632957
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu czwartek, 2 pa=C5=BAdziernika 2014 12:24:11=
UTC+2 u=C5=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 201=
4=E2=80=9310=E2=80=9302, at 5:40 PM, Andrzej Krzemie=C5=84ski <<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"4-GpqaWzRYcJ" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">akrz...@gmail.com</a>> wrote:</div><br><b=
lockquote type=3D"cite"><div dir=3D"ltr">1. <br><div>This form: assert=
( assignment-expression , assignment-expression ), with two expressions, w=
hat do you intend the second expression to be? <br></div></div></blockquote=
><div><br></div>From the paragraph preceding the grammar, "it is simply&nbs=
p;evaluated to produce the diagnostic.=E2=80=9D</div></div></blockquote><br=
>Do you mean it is a constant expression that evaluates to something of typ=
e const char * ?<br></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_3683_1489768575.1412247632957--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 2 Oct 2014 13:08:50 +0200
Raw View
What about defining (operator) assume instead of altering the
semantics of assert?
I don't think having (more) modes for assert is a good idea.
--
---
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: David Krauss <potswa@gmail.com>
Date: Thu, 2 Oct 2014 19:35:20 +0800
Raw View
--Apple-Mail=_7CA44819-FFDE-40A6-AE45-9174714B6D53
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On 2014=E2=80=9310=E2=80=9302, at 7:00 PM, Andrzej Krzemie=C5=84ski <akrzem=
i1@gmail.com> wrote:
> Do you mean it is a constant expression that evaluates to something of ty=
pe const char * ?
Whether or not it=E2=80=99s a constant expression makes no difference. By t=
he time it=E2=80=99s evaluated, the machine is already on the failure path,=
which leads to abort().
The const char * case is covered by the string literal. Any expression othe=
r than a string literal will need to have the side effect of outputting a m=
essage for the user. So, the implementation could reasonably provide diagno=
se a warning when the second argument is a constant expression, because tha=
t cannot have side effects.
--=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=_7CA44819-FFDE-40A6-AE45-9174714B6D53
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;"><br><div><div>On 2014=E2=80=
=9310=E2=80=9302, at 7:00 PM, Andrzej Krzemie=C5=84ski <<a href=3D"mailt=
o:akrzemi1@gmail.com">akrzemi1@gmail.com</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">Do you=
mean it is a constant expression that evaluates to something of type const=
char * ?</div></blockquote><div><br></div>Whether or not it=E2=80=99s a co=
nstant expression makes no difference. By the time it=E2=80=99s evaluated, =
the machine is already on the failure path, which leads to abort().</div><d=
iv><br></div><div>The const char * case is covered by the string literal. A=
ny expression other than a string literal will need to have the side effect=
of outputting a message for the user. So, the implementation could reasona=
bly provide diagnose a warning when the second argument <i>is</i> a constan=
t expression, because that cannot have side effects.</div><div><br></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=_7CA44819-FFDE-40A6-AE45-9174714B6D53--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 2 Oct 2014 04:47:09 -0700 (PDT)
Raw View
------=_Part_262_519958129.1412250429045
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu czwartek, 2 pa=C5=BAdziernika 2014 13:35:35 UTC+2 u=C5=BCytkownik Da=
vid Krauss=20
napisa=C5=82:
>
>
> On 2014=E2=80=9310=E2=80=9302, at 7:00 PM, Andrzej Krzemie=C5=84ski <akrz=
....@gmail.com=20
> <javascript:>> wrote:
>
> Do you mean it is a constant expression that evaluates to something of=20
> type const char * ?
>
>
> Whether or not it=E2=80=99s a constant expression makes no difference. By=
the time=20
> it=E2=80=99s evaluated, the machine is already on the failure path, which=
leads to=20
> abort().
>
> The const char * case is covered by the string literal. Any expression=20
> other than a string literal will need to have the side effect of outputti=
ng=20
> a message for the user. So, the implementation could reasonably provide=
=20
> diagnose a warning when the second argument *is* a constant expression,=
=20
> because that cannot have side effects.
>
I am not sure I understand. Can I use it like this:
assert(input !=3D 0, std::terminate());
Can you give me an example of how you imagine this will be used?=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 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_262_519958129.1412250429045
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu czwartek, 2 pa=C5=BAdziernika 2014 13:35:35=
UTC+2 u=C5=BCytkownik David Krauss napisa=C5=82:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 201=
4=E2=80=9310=E2=80=9302, at 7:00 PM, Andrzej Krzemie=C5=84ski <<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"A2RaWXRt74AJ" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">akrz...@gmail.com</a>> wrote:</div><br><b=
lockquote type=3D"cite"><div dir=3D"ltr">Do you mean it is a constant expre=
ssion that evaluates to something of type const char * ?</div></blockquote>=
<div><br></div>Whether or not it=E2=80=99s a constant expression makes no d=
ifference. By the time it=E2=80=99s evaluated, the machine is already on th=
e failure path, which leads to abort().</div><div><br></div><div>The const =
char * case is covered by the string literal. Any expression other than a s=
tring literal will need to have the side effect of outputting a message for=
the user. So, the implementation could reasonably provide diagnose a warni=
ng when the second argument <i>is</i> a constant expression, because that c=
annot have side effects.</div></div></blockquote><div><br>I am not sure I u=
nderstand. Can I use it like this:<br><br> assert(input !=3D 0, std::=
terminate());<br><br>Can you give me an example of how you imagine this wil=
l be used? <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_262_519958129.1412250429045--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 2 Oct 2014 22:41:57 +0800
Raw View
--Apple-Mail=_13B3D3B7-4BC6-4686-8CF4-35943FA728BB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-10-02, at 7:08 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> What about defining (operator) assume instead of altering the
> semantics of assert?
I wouldn't be opposed to assume, except why wouldn't you want it to flag in=
valid assumptions during debugging?
> I don't think having (more) modes for assert is a good idea.
The new modes don't change the production-mode behavior, unless the user ha=
s (ab)used NDEBUG in such a way that its definition changes program semanti=
cs, which intrinsically tends to invalidate test results. Users who do this=
will be stuck in strict mode or (ugh) default/relaxed mode, and then they =
will need a separate assume. However, they will hopefully be in the minorit=
y, and migration to cleaner, standardized verification practices is always =
a viable option.
--=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=_13B3D3B7-4BC6-4686-8CF4-35943FA728BB
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;10–02, at 7:08 PM, Olaf van der Spek <<a href=3D"mailto:olaf=
vdspek@gmail.com">olafvdspek@gmail.com</a>> wrote:</div><br class=3D"App=
le-interchange-newline"><blockquote type=3D"cite">What about defining (oper=
ator) assume instead of altering the<br>semantics of assert?<br></blockquot=
e><div><br></div><div>I wouldn’t be opposed to <font face=3D"Courier"=
>assume</font>, except why wouldn’t you want it to flag invalid assum=
ptions during debugging?</div><br><blockquote type=3D"cite">I don't think h=
aving (more) modes for assert is a good idea.<br></blockquote><div><br></di=
v><div>The new modes don’t change the production-mode behavior, unles=
s the user has (ab)used NDEBUG in such a way that its definition changes pr=
ogram semantics, which intrinsically tends to invalidate test results. User=
s who do this will be stuck in <font face=3D"Courier">strict</font> mode or=
(ugh) default/relaxed mode, and then they will need a separate <font face=
=3D"Courier">assume</font>. However, they will hopefully be in the minority=
, and migration to cleaner, standardized verification practices is always a=
viable option.</div><div><br></div></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=_13B3D3B7-4BC6-4686-8CF4-35943FA728BB--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 2 Oct 2014 22:51:23 +0800
Raw View
--Apple-Mail=_D4F298FE-A091-4329-AE98-4DFFE000D65D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On 2014=E2=80=9310=E2=80=9302, at 7:47 PM, Andrzej Krzemie=C5=84ski <akrzem=
i1@gmail.com> wrote:
> I am not sure I understand. Can I use it like this:
>=20
> assert(input !=3D 0, std::terminate());
>=20
> Can you give me an example of how you imagine this will be used?=20
More like
assert( input !=3D 0, std::cerr << "invalid input " << input << '\n' );
The abort call happens automatically, but I guess you could also defeat tha=
t by putting a throw-expression in the second argument.
However, the aliased syntax is definitely a bad thing and that could change=
.. And given some of the ship-with-assert abuse that=E2=80=99s come up on th=
is thread and the other one, I suspect that users will pervert this facilit=
y too. I look forward to the debate :) .
--=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=_D4F298FE-A091-4329-AE98-4DFFE000D65D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;"><br><div><div>On 2014=E2=80=
=9310=E2=80=9302, at 7:47 PM, Andrzej Krzemie=C5=84ski <<a href=3D"mailt=
o:akrzemi1@gmail.com">akrzemi1@gmail.com</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">I am n=
ot sure I understand. Can I use it like this:<br><div><br> assert(inp=
ut !=3D 0, std::terminate());<br><br>Can you give me an example of how you =
imagine this will be used? <br></div></div></blockquote><div><br></div></di=
v>More like<div><br></div><div><font face=3D"Courier"> assert( input !=
=3D 0, std::cerr << "invalid input " << input << '\n' );<=
/font></div><div><br></div><div>The <font face=3D"Courier">abort</font> cal=
l happens automatically, but I guess you could also defeat that by putting =
a throw-expression in the second argument.</div><div><br></div><div>However=
, the aliased syntax is definitely a bad thing and that could change. And g=
iven some of the ship-with-assert abuse that=E2=80=99s come up on this thre=
ad and the other one, I suspect that users will pervert this facility too. =
I look forward to the debate :) .</div><div><br></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=_D4F298FE-A091-4329-AE98-4DFFE000D65D--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 2 Oct 2014 17:35:55 +0200
Raw View
On Thu, Oct 2, 2014 at 4:41 PM, David Krauss <potswa@gmail.com> wrote:
> I wouldn=E2=80=99t be opposed to assume, except why wouldn=E2=80=99t you =
want it to flag
> invalid assumptions during debugging?
I'm not saying I don't want to. The problem is with the additional
semantics with NDEBUG.
> I don't think having (more) modes for assert is a good idea.
>
>
> The new modes don=E2=80=99t change the production-mode behavior, unless t=
he user has
> (ab)used NDEBUG in such a way that its definition changes program semanti=
cs,
> which intrinsically tends to invalidate test results. Users who do this w=
ill
> be stuck in strict mode or (ugh) default/relaxed mode, and then they will
> need a separate assume. However, they will hopefully be in the minority, =
and
> migration to cleaner, standardized verification practices is always a via=
ble
> option.
What I'm trying to say is that I don't think you can flag such uses of
assert as wrong.
--=20
Olaf
--=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: David Krauss <potswa@gmail.com>
Date: Fri, 3 Oct 2014 00:12:26 +0800
Raw View
On 2014-10-02, at 11:35 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 4:41 PM, David Krauss <potswa@gmail.com> wrote:
>> I wouldn't be opposed to assume, except why wouldn't you want it to flag
>> invalid assumptions during debugging?
>
> I'm not saying I don't want to. The problem is with the additional
> semantics with NDEBUG.
How else besides a preprocessor macro (or something just like one) can the build environment tell the compiler about debugging vs. production?
> What I'm trying to say is that I don't think you can flag such uses of
> assert as wrong.
By default, they won't be, for compatibility. However, I think most users will tend to prefer that the code they debug has exactly the same semantics as what they ship.
Lambda functions (and my inline variables proposal) provide ways to express invariants with complicated or interrelated computations, without introducing overhead nor debug-only variables.
The committee has a lot more experience than I have, so we'll see.
--
---
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: Olaf van der Spek <olafvdspek@gmail.com>
Date: Thu, 2 Oct 2014 20:33:44 +0200
Raw View
On Thu, Oct 2, 2014 at 6:12 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014-10-02, at 11:35 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>
>> On Thu, Oct 2, 2014 at 4:41 PM, David Krauss <potswa@gmail.com> wrote:
>>> I wouldn't be opposed to assume, except why wouldn't you want it to flag
>>> invalid assumptions during debugging?
>>
>> I'm not saying I don't want to. The problem is with the additional
>> semantics with NDEBUG.
>
> How else besides a preprocessor macro (or something just like one) can the build environment tell the compiler about debugging vs. production?
It's not NDEBUG that's the problem, it's the additional semantics.
>
>> What I'm trying to say is that I don't think you can flag such uses of
>> assert as wrong.
>
> By default, they won't be, for compatibility. However, I think most users will tend to prefer that the code they debug has exactly the same semantics as what they ship.
Ideally yes. But in the presence of bugs the debug build probably has
different behaviour then the release build. The debug one might catch
the bug while the release one wanders off into undefined territory.
--
Olaf
--
---
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: David Krauss <potswa@gmail.com>
Date: Fri, 3 Oct 2014 02:54:38 +0800
Raw View
--Apple-Mail=_5B37D003-3736-46D2-A2BF-2757CD29C842
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-10-03, at 2:33 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> It's not NDEBUG that's the problem, it's the additional semantics.
Meaning, you don't want separate debug and release modes?
>> By default, they won't be, for compatibility. However, I think most user=
s will tend to prefer that the code they debug has exactly the same semanti=
cs as what they ship.
>=20
> Ideally yes. But in the presence of bugs the debug build probably has
> different behaviour then the release build. The debug one might catch
> the bug while the release one wanders off into undefined territory.
The only well-defined behavior for an exception with no exception handling =
is terminate() or abort(), and that's not much of a catch. It looks like I =
should have specified the former because it's the preferred C++ facility, b=
ut whatever. It's immaterial whether a shipping product logs something to s=
tderr before vanishing from the user's screen. If that is so preferable to =
the UB lottery, then build the release in debug mode.
And, the language does have a well-defined way to get the release mode stdl=
ib with debug mode user assertions.
--=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=_5B37D003-3736-46D2-A2BF-2757CD29C842
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;10–03, at 2:33 AM, Olaf van der Spek <<a href=3D"mailto:olaf=
vdspek@gmail.com">olafvdspek@gmail.com</a>> wrote:</div><br class=3D"App=
le-interchange-newline"><blockquote type=3D"cite">It's not NDEBUG that's th=
e problem, it's the additional semantics.<br></blockquote><div><br></div><d=
iv>Meaning, you don’t want separate debug and release modes?</div><br=
><blockquote type=3D"cite"><blockquote type=3D"cite">By default, they won't=
be, for compatibility. However, I think most users will tend to prefer tha=
t the code they debug has exactly the same semantics as what they ship.</bl=
ockquote><br>Ideally yes. But in the presence of bugs the debug build proba=
bly has<br>different behaviour then the release build. The debug one might =
catch<br>the bug while the release one wanders off into undefined territory=
..<br></blockquote><div><br></div><div>The only well-defined behavior for an=
exception with no exception handling is <font face=3D"Courier">terminate()=
</font> or <font face=3D"Courier">abort()</font>, and that’s not much=
of a catch. It looks like I should have specified the former because it&rs=
quo;s the preferred C++ facility, but whatever. It’s immaterial wheth=
er a shipping product logs something to <font face=3D"Courier">stderr</font=
> before vanishing from the user’s screen. If that is so preferable t=
o the UB lottery, then build the release in debug mode.</div></div><br><div=
>And, the language does have a well-defined way to get the release mode std=
lib with debug mode user assertions.</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=_5B37D003-3736-46D2-A2BF-2757CD29C842--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 3 Oct 2014 02:56:54 +0800
Raw View
--Apple-Mail=_F6655063-A59D-4153-B115-11D42CD5621E
Content-Type: text/plain; charset=ISO-8859-1
On 2014-10-03, at 2:54 AM, David Krauss <potswa@gmail.com> wrote:
> And, the language does have a well-defined way to get the release mode stdlib with debug mode user assertions.
.... but if that's too inconvenient, you could ask your library vendor to make it easier. Library performance dependency on NDEBUG is definitely outside the spec.
--
---
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/.
--Apple-Mail=_F6655063-A59D-4153-B115-11D42CD5621E
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;10–03, at 2:54 AM, David Krauss <<a href=3D"mailto:potswa@gm=
ail.com">potswa@gmail.com</a>> wrote:</div><br class=3D"Apple-interchang=
e-newline"><blockquote type=3D"cite"><span style=3D"font-family: Helvetica;=
font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; d=
isplay: inline !important;">And, the language does have a well-defined way =
to get the release mode stdlib with debug mode user assertions.</span></blo=
ckquote></div><br><div>… but if that’s too inconvenient, you c=
ould ask your library vendor to make it easier. Library performance depende=
ncy on NDEBUG is definitely outside the spec.</div><div><br></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=_F6655063-A59D-4153-B115-11D42CD5621E--
.