------=_Part_1739_8817653.1352971077880
Content-Type: text/plain; charset=ISO-8859-1

Assert is quite a handy tool, but it's a bit limited.

Some expressions need to be evaluated regardless of NDEBUG being defined.
BOOST_VERIFY solves this case.

Sometimes, the expression needs to be checked too. Would it be possible to
have standard C++ tools for these use cases?

http://www.boost.org/doc/libs/1_52_0/libs/utility/assert.html

--




------=_Part_1739_8817653.1352971077880
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Assert is quite a handy tool, but it's a bit limited.&nbsp;<div><br></div><=
div>Some expressions need to be evaluated regardless of NDEBUG being define=
d. BOOST_VERIFY solves this case.</div><div><br></div><div>Sometimes, the e=
xpression needs to be checked too. Would it be possible to have standard C+=
+ tools for these use cases?</div><div><br></div><div>http://www.boost.org/=
doc/libs/1_52_0/libs/utility/assert.html<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1739_8817653.1352971077880--

.

On Thu, Nov 15, 2012 at 4:17 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> Assert is quite a handy tool, but it's a bit limited.
>
> Some expressions need to be evaluated regardless of NDEBUG being defined.
> BOOST_VERIFY solves this case.

BOOST_ASSERT_MSG, which is the same as assert(), but with an
additional argument specifying a string associated with an assert
failure, is much more useful than a plain assert(), IMO. I use it a
great deal.

> Sometimes, the expression needs to be checked too. Would it be possible to
> have standard C++ tools for these use cases?

The only way to know for sure is to write a proposal. You can ask on
this list, but that will only give you the opinion of a small subset
of the LWG.

--Beman

> http://www.boost.org/doc/libs/1_52_0/libs/utility/assert.html

--




.

------=_Part_296_17782716.1353366261376
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi I just wanted to say that I agree this would be an interesting addition,=
=20
I can not count the number of macros I have to do this.

To me we really need the boost_verify and the fact that it will be tested=
=20
during execution whatever happens.
Also in general always having the possiility to add a message or context=20
information is good.
I have a macro that forces the test to be done in release and to display a=
=20
message like : %file, %line : %message

And perhaps an assert that evaluates the expression durring execution even=
=20
if the result is not tested.
Because this is ugly:
error_code e =3D myvariable.getData();
bool test =3D e=3D=3Dno_eror;
assert(test);

clearly I would prefer to write:
assert(myvariable.getData()=3D=3Dno_error)

It is not a great exemple but anyway that is the idea.
It could just have a diffrent name, not assert but it would be handy.

best

Le jeudi 15 novembre 2012 10:17:58 UTC+1, Olaf van der Spek a =E9crit :
>
> Assert is quite a handy tool, but it's a bit limited.=20
>
> Some expressions need to be evaluated regardless of NDEBUG being defined.=
=20
> BOOST_VERIFY solves this case.
>
> Sometimes, the expression needs to be checked too. Would it be possible t=
o=20
> have standard C++ tools for these use cases?
>
> http://www.boost.org/doc/libs/1_52_0/libs/utility/assert.html
>

--=20




------=_Part_296_17782716.1353366261376
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi I just wanted to say that I agree this would be an interesting addition,=
 I can not count the number of macros I have to do this.<br><br>To me we re=
ally need the boost_verify and the fact that it will be tested during execu=
tion whatever happens.<br>Also in general always having the possiility to a=
dd a message or context information is good.<br>I have a macro that forces =
the test to be done in release and to display a message like : %file, %line=
 : %message<br><br>And perhaps an assert that evaluates the expression durr=
ing execution even if the result is not tested.<br>Because this is ugly:<br=
>error_code e =3D myvariable.getData();<br>bool test =3D e=3D=3Dno_eror;<br=
>assert(test);<br><br>clearly I would prefer to write:<br>assert(myvariable=
..getData()=3D=3Dno_error)<br><br>It is not a great exemple but anyway that =
is the idea.<br>It could just have a diffrent name, not assert but it would=
 be handy.<br><br>best<br><br>Le jeudi 15 novembre 2012 10:17:58 UTC+1, Ola=
f van der Spek a =E9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>Assert is quite a handy tool, but it's a bit limited.&nbsp;<div><br></div>=
<div>Some expressions need to be evaluated regardless of NDEBUG being defin=
ed. BOOST_VERIFY solves this case.</div><div><br></div><div>Sometimes, the =
expression needs to be checked too. Would it be possible to have standard C=
++ tools for these use cases?</div><div><br></div><div><a href=3D"http://ww=
w.boost.org/doc/libs/1_52_0/libs/utility/assert.html" target=3D"_blank">htt=
p://www.boost.org/doc/libs/<wbr>1_52_0/libs/utility/assert.<wbr>html</a><br=
></div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_296_17782716.1353366261376--

.

------=_Part_788_17648885.1353406957675
Content-Type: text/plain; charset=ISO-8859-1

Op donderdag 15 november 2012 11:30:11 UTC+1 schreef Beman Dawes het
volgende:

> On Thu, Nov 15, 2012 at 4:17 AM, Olaf van der Spek <olafv...@gmail.com<javascript:>>
> wrote:
> > Assert is quite a handy tool, but it's a bit limited.
> >
> > Some expressions need to be evaluated regardless of NDEBUG being
> defined.
> > BOOST_VERIFY solves this case.
>
> BOOST_ASSERT_MSG, which is the same as assert(), but with an
> additional argument specifying a string associated with an assert
> failure, is much more useful than a plain assert(), IMO. I use it a
> great deal.
>

Looks useful, though assert("msg", expression) would work too, wouldn't it?


> > Sometimes, the expression needs to be checked too. Would it be possible
> to
> > have standard C++ tools for these use cases?
>
> The only way to know for sure is to write a proposal. You can ask on
> this list, but that will only give you the opinion of a small subset
> of the LWG.
>

I'll try to write a proposal.

--




------=_Part_788_17648885.1353406957675
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Op donderdag 15 november 2012 11:30:11 UTC+1 schreef Beman Dawes het volgen=
de:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Nov 15, 2012 at=
 4:17 AM, Olaf van der Spek &lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"EVJUsonGwm4J">olafv...@gmail.com</a>&gt; wrote:
<br>&gt; Assert is quite a handy tool, but it's a bit limited.
<br>&gt;
<br>&gt; Some expressions need to be evaluated regardless of NDEBUG being d=
efined.
<br>&gt; BOOST_VERIFY solves this case.
<br>
<br>BOOST_ASSERT_MSG, which is the same as assert(), but with an
<br>additional argument specifying a string associated with an assert
<br>failure, is much more useful than a plain assert(), IMO. I use it a
<br>great deal.
<br></blockquote><div><br></div><div>Looks useful, though assert("msg", exp=
ression) would work too, wouldn't it?</div><div>&nbsp;</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">&gt; Sometimes, the expression needs to be ch=
ecked too. Would it be possible to
<br>&gt; have standard C++ tools for these use cases?
<br>
<br>The only way to know for sure is to write a proposal. You can ask on
<br>this list, but that will only give you the opinion of a small subset
<br>of the LWG.
<br></blockquote><div><br></div><div>I'll try to write a proposal.&nbsp;</d=
iv>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_788_17648885.1353406957675--

.

------=_Part_263_25420450.1353407416526
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 20 listopada 2012 11:22:37 UTC+1 u=BFytkownik Olaf van der=
=20
Spek napisa=B3:
>
> Op donderdag 15 november 2012 11:30:11 UTC+1 schreef Beman Dawes het=20
> volgende:
>
>> On Thu, Nov 15, 2012 at 4:17 AM, Olaf van der Spek <olafv...@gmail.com>=
=20
>> wrote:=20
>> > Assert is quite a handy tool, but it's a bit limited.=20
>> >=20
>> > Some expressions need to be evaluated regardless of NDEBUG being=20
>> defined.=20
>> > BOOST_VERIFY solves this case.=20
>>
>> BOOST_ASSERT_MSG, which is the same as assert(), but with an=20
>> additional argument specifying a string associated with an assert=20
>> failure, is much more useful than a plain assert(), IMO. I use it a=20
>> great deal.=20
>>
>
> Looks useful, though assert("msg", expression) would work too, wouldn't i=
t?
>

I believe that this would be treated as passing two arguments to macro=20
assert() rather than one expression that uses comma operator.=20

--=20




------=_Part_263_25420450.1353407416526
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu wtorek, 20 listopada 2012 11:22:37 UTC+1 u=BFytkownik Olaf v=
an der Spek napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Op donde=
rdag 15 november 2012 11:30:11 UTC+1 schreef Beman Dawes het volgende:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex">On Thu, Nov 15, 2012 at 4:17 AM, Ola=
f van der Spek &lt;<a>olafv...@gmail.com</a>&gt; wrote:
<br>&gt; Assert is quite a handy tool, but it's a bit limited.
<br>&gt;
<br>&gt; Some expressions need to be evaluated regardless of NDEBUG being d=
efined.
<br>&gt; BOOST_VERIFY solves this case.
<br>
<br>BOOST_ASSERT_MSG, which is the same as assert(), but with an
<br>additional argument specifying a string associated with an assert
<br>failure, is much more useful than a plain assert(), IMO. I use it a
<br>great deal.
<br></blockquote><div><br></div><div>Looks useful, though assert("msg", exp=
ression) would work too, wouldn't it?</div></blockquote><div><br>I believe =
that this would be treated as passing two arguments to macro assert() rathe=
r than one expression that uses comma operator. <br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_263_25420450.1353407416526--

.

On Tue, Nov 20, 2012 at 11:30 AM, Andrzej Krzemie=C5=84ski
<akrzemi1@gmail.com> wrote:
>> Looks useful, though assert("msg", expression) would work too, wouldn't
>> it?
>
>
> I believe that this would be treated as passing two arguments to macro
> assert() rather than one expression that uses comma operator.

Right. assert("msg" && expression) then? I'm sure I've seen such a
construct before. The _msg variants are cleaner though.

--=20
Olaf

--=20




.

> Right. assert("msg"&&  expression) then? I'm sure I've seen such a
> construct before. The _msg variants are cleaner though.
>
Yes, I think this is quite common. It is not that bad but I wouln't mind
something cleaner.

btw, I wonder how many people use assert like construct that asserts on
debug build on throws on release build?


Mikael

--




.

On Thu, Nov 15, 2012 at 11:30 AM, Beman Dawes <bdawes@acm.org> wrote:
>> Sometimes, the expression needs to be checked too. Would it be possible to
>> have standard C++ tools for these use cases?
>
> The only way to know for sure is to write a proposal. You can ask on
> this list, but that will only give you the opinion of a small subset
> of the LWG.

How's this for a first revision?

Document number: Nnnnn=yy-nnnn
Date:  2012-11-20
Project: Programming Language C++, Library Working Group
Reply-to: Olaf van der Spek <olafvdspek@gmail.com>


I. Table of Contents


II. Introduction

This proposal introduces new variants of the existing assert()
facility. The new variants serve use cases the original variant
doesn't.


III. Motivation and Scope

The existing assert variant does not allow a message to be passed,
this is sometimes worked around via assert(expression && "message");
The _msg variants provide a cleaner way to pass a message.

The existing variant does not evaluate the expression when NDEBUG is
defined, so it can't be used for expressions with desirable side
effects. Verify solves this.

The existing variant and verify do not check the expression when
NDEBUG is defined, but in some cases that's desirable. For example:
assure_msg(!fclose(os), "fclose() failed"); Assure solves this.

Assure aborts the program if the expression is false, but some use
cases may demand an exception to be thrown instead. A fourth variant
could be created to serve this use case if there's demand for this.

Boost provides BOOST_ASSERT, BOOST_ASSERT_MSG and BOOST_VERIFY, but no
BOOST_VERIFY_MSG. I don't know what other languages and libraries
provide.


IV. Impact On the Standard

The new variants (probably) depend on the existing assert variant.
Nothing depends on the new variants. It's a pure extension and can be
implemented using C++11 compilers and libraries.


V. Design Decisions

The _msg variants are a natural extension of the existing variants.
The names verify and assure are semi-arbitrary, better names might be
available.


VI. Technical Specifications

// equivalent to assert(expression), except it also prints message
when expression is false
void assert_msg(expression, message);

// equivalent to assert(expression), except it always evaluates
expression, even when NDEBUG is defined
void verify(expression);
void verify_msg(expression, message);

// equivalent to assert(expression), except it always evaluates and
checks expression, even when NDEBUG is defined
void assure(expression);
void assure_msg(expression, message);


VII. Acknowledgements


VIII. References

http://www.boost.org/doc/libs/1_52_0/libs/utility/assert.html

--
Olaf

--




.

------=_Part_166_23467178.1353418265501
Content-Type: text/plain; charset=ISO-8859-1



> VI. Technical Specifications
>
> // equivalent to assert(expression), except it also prints message
> when expression is false
> void assert_msg(expression, message);
>

You cannot just say "function assert_msg is equivalent to
assert(expression)". One is a function, the other is a macro (for a good
reason). If function assert_msg takes two arguments: a computed value
(functions - unlike macros - cannot "take" expressions) and a messag, how
could it correctly display information about the line number anf file that
the assertion was planted in?

Also, with macro assert(), you can do the folowing trick:

#define NDEBUG
#include <cassert>
assert(expr1); // evalueate expr1

#undef NDEBUG
#include <cassert>
assert(expr2); // don't evaluate

This may look suspicious, but the behavior of header <assert> was carefully
designed to allow this use case.

--




------=_Part_166_23467178.1353418265501
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">VI. Technical Specificatio=
ns
<br>
<br>// equivalent to assert(expression), except it also prints message
<br>when expression is false
<br>void assert_msg(expression, message);
<br></blockquote><div>&nbsp;<br>You cannot just say "function assert_msg is=
 equivalent to assert(expression)". One is a function, the other is a macro=
 (for a good reason). If function assert_msg takes two arguments: a compute=
d value (functions - unlike macros - cannot "take" expressions) and a messa=
g, how could it correctly display information about the line number anf fil=
e that the assertion was planted in?<br><br>Also, with macro assert(), you =
can do the folowing trick:<br><br><div class=3D"prettyprint" style=3D"backg=
round-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-s=
tyle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #800;" class=
=3D"styled-by-prettify">#define</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> NDEBUG<br></span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">#include</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">&lt;cassert&gt;</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"=
>expr1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">// evalueate expr1</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">#undef</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> NDEBUG<br></span><=
span style=3D"color: #800;" class=3D"styled-by-prettify">#include</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">&lt;cassert&gt;</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: #0=
00;" class=3D"styled-by-prettify">expr2</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-b=
y-prettify">// don't evaluate</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span></div></code></div><br>This may look suspicio=
us, but the behavior of header &lt;assert&gt; was carefully designed to all=
ow this use case.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_166_23467178.1353418265501--

.

On Tue, Nov 20, 2012 at 2:31 PM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
 wrote:
>
>> VI. Technical Specifications
>>
>> // equivalent to assert(expression), except it also prints message
>> when expression is false
>> void assert_msg(expression, message);
>
>
> You cannot just say "function assert_msg is equivalent to

I didn't say/mean function. assert_msg can't be a function.

--=20
Olaf

--=20




.

------=_Part_53_15819299.1353419543111
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 20 listopada 2012 14:40:59 UTC+1 u=BFytkownik Olaf van der=
=20
Spek napisa=B3:
>
> On Tue, Nov 20, 2012 at 2:31 PM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:=20
> >=20
> >> VI. Technical Specifications=20
> >>=20
> >> // equivalent to assert(expression), except it also prints message=20
> >> when expression is false=20
> >> void assert_msg(expression, message);=20
> >=20
> >=20
> > You cannot just say "function assert_msg is equivalent to=20
>
> I didn't say/mean function. assert_msg can't be a function.=20
>

Sorry, then. This "void" confused me.=20

--=20




------=_Part_53_15819299.1353419543111
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu wtorek, 20 listopada 2012 14:40:59 UTC+1 u=BFytkownik Olaf v=
an der Spek napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, =
Nov 20, 2012 at 2:31 PM, Andrzej Krzemie=F1ski &lt;<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"64rJuJQYfSYJ">akrz...@gmail.com<=
/a>&gt; wrote:
<br>&gt;
<br>&gt;&gt; VI. Technical Specifications
<br>&gt;&gt;
<br>&gt;&gt; // equivalent to assert(expression), except it also prints mes=
sage
<br>&gt;&gt; when expression is false
<br>&gt;&gt; void assert_msg(expression, message);
<br>&gt;
<br>&gt;
<br>&gt; You cannot just say "function assert_msg is equivalent to
<br>
<br>I didn't say/mean function. assert_msg can't be a function.
<br></blockquote><div><br>Sorry, then. This "void" confused me. <br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_53_15819299.1353419543111--

.

------=_Part_580_20807076.1353666236367
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Op dinsdag 20 november 2012 14:52:23 UTC+1 schreef Andrzej Krzemie=F1ski he=
t=20
volgende:

>
>
> W dniu wtorek, 20 listopada 2012 14:40:59 UTC+1 u=BFytkownik Olaf van der=
=20
> Spek napisa=B3:
>>
>> On Tue, Nov 20, 2012 at 2:31 PM, Andrzej Krzemie=F1ski <akrz...@gmail.co=
m>=20
>> wrote:=20
>> >=20
>> >> VI. Technical Specifications=20
>> >>=20
>> >> // equivalent to assert(expression), except it also prints message=20
>> >> when expression is false=20
>> >> void assert_msg(expression, message);=20
>> >=20
>> >=20
>> > You cannot just say "function assert_msg is equivalent to=20
>>
>> I didn't say/mean function. assert_msg can't be a function.=20
>>
>
> Sorry, then. This "void" confused me.=20
>

My bad, I'll remove it. Thanks for the feedback.=20

--=20




------=_Part_580_20807076.1353666236367
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Op dinsdag 20 november 2012 14:52:23 UTC+1 schreef Andrzej Krzemie=F1ski he=
t volgende:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>W dniu =
wtorek, 20 listopada 2012 14:40:59 UTC+1 u=BFytkownik Olaf van der Spek nap=
isa=B3:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex">On Tue, Nov 20, 2012 at 2:31=
 PM, Andrzej Krzemie=F1ski &lt;<a>akrz...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt;&gt; VI. Technical Specifications
<br>&gt;&gt;
<br>&gt;&gt; // equivalent to assert(expression), except it also prints mes=
sage
<br>&gt;&gt; when expression is false
<br>&gt;&gt; void assert_msg(expression, message);
<br>&gt;
<br>&gt;
<br>&gt; You cannot just say "function assert_msg is equivalent to
<br>
<br>I didn't say/mean function. assert_msg can't be a function.
<br></blockquote><div><br>Sorry, then. This "void" confused me. <br></div><=
/blockquote><div><br></div><div>My bad, I'll remove it. Thanks for the feed=
back.&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_580_20807076.1353666236367--

.

------=_Part_166_17424468.1353949220523
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Op dinsdag 20 november 2012 11:48:40 UTC+1 schreef Mikael Kilpel=E4inen het=
=20
volgende:
>
> > Right. assert("msg"&&  expression) then? I'm sure I've seen such a=20
> > construct before. The _msg variants are cleaner though.=20
> >=20
> Yes, I think this is quite common. It is not that bad but I wouln't mind=
=20
> something cleaner.=20
>
> btw, I wonder how many people use assert like construct that asserts on=
=20
> debug build on throws on release build?=20
>
> Don't know, do you?
For what kind of errors?
Why not just throw?=20

--=20




------=_Part_166_17424468.1353949220523
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>Op dinsdag 20 november 2012 11:48:40 UTC+1 schreef Mikael Kilpel=E4inen=
 het volgende:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Right. asse=
rt("msg"&amp;&amp; &nbsp;expression) then? I'm sure I've seen such a
<br>&gt; construct before. The _msg variants are cleaner though.
<br>&gt;
<br>Yes, I think this is quite common. It is not that bad but I wouln't min=
d=20
<br>something cleaner.
<br>
<br>btw, I wonder how many people use assert like construct that asserts on=
=20
<br>debug build on throws on release build?
<br><br></blockquote><div>Don't know, do you?</div><div>For what kind of er=
rors?</div><div>Why not just throw?&nbsp;<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_166_17424468.1353949220523--

.

This is a multi-part message in MIME format.
--------------050901020709030304060409
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


>     > Right. assert("msg"&&  expression) then? I'm sure I've seen such a
>     > construct before. The _msg variants are cleaner though.
>     >
>     Yes, I think this is quite common. It is not that bad but I
>     wouln't mind
>     something cleaner.
>
>     btw, I wonder how many people use assert like construct that
>     asserts on
>     debug build on throws on release build?
>
> Don't know, do you?
> For what kind of errors?
> Why not just throw?
> --
Obviously I don't know how many are using such but I know some do (not
me, I just wanted to point out existing use case)

Motivation I can think of..  you want assert (more intrusive, easier to
get call stack) but maybe
you have trust issues?! :) So you don't want undefined behaviour in
release build, could be security consideration.
You could always terminate the program in some ways but maybe that is
just not wanted in productive system.

That said, it doesn't really feel right, does it?


Mikael

--




--------------050901020709030304060409
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <blockquote
      cite="mid:57d90dfe-d444-4c18-ba5a-dc2deb8e7831@isocpp.org"
      type="cite">
      <blockquote class="gmail_quote" style="margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt;
        Right. assert("msg"&amp;&amp; &nbsp;expression) then? I'm sure I've
        seen such a
        <br>
        &gt; construct before. The _msg variants are cleaner though.
        <br>
        &gt;
        <br>
        Yes, I think this is quite common. It is not that bad but I
        wouln't mind <br>
        something cleaner.
        <br>
        <br>
        btw, I wonder how many people use assert like construct that
        asserts on <br>
        debug build on throws on release build?
        <br>
        <br>
      </blockquote>
      <div>Don't know, do you?</div>
      <div>For what kind of errors?</div>
      <div>Why not just throw?&nbsp;<br>
      </div>
      -- <br>
    </blockquote>
    Obviously I don't know how many are using such but I know some do
    (not me, I just wanted to point out existing use case)<br>
    <br>
    Motivation I can think of..&nbsp; you want assert (more intrusive, easier
    to get call stack) but maybe<br>
    you have trust issues?! :) So you don't want undefined behaviour in
    release build, could be security consideration.<br>
    You could always terminate the program in some ways but maybe that
    is just not wanted in productive system.<br>
    <br>
    That said, it doesn't really feel right, does it?<br>
    <br>
    <br>
    Mikael<br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--------------050901020709030304060409--

.

On Mon, Nov 26, 2012 at 1:12 PM, Mikael Kilpel=E4inen
<mikael.kilpelainen@gmail.com> wrote:
>
>> > Right. assert("msg"&&  expression) then? I'm sure I've seen such a
>> > construct before. The _msg variants are cleaner though.
>> >
>> Yes, I think this is quite common. It is not that bad but I wouln't mind
>> something cleaner.
>>
>> btw, I wonder how many people use assert like construct that asserts on
>> debug build on throws on release build?
>>
> Don't know, do you?
> For what kind of errors?
> Why not just throw?
> --
>
> Obviously I don't know how many are using such but I know some do (not me=
, I
> just wanted to point out existing use case)
>
> Motivation I can think of..  you want assert (more intrusive, easier to g=
et
> call stack) but maybe
> you have trust issues?! :) So you don't want undefined behaviour in relea=
se
> build, could be security consideration.
> You could always terminate the program in some ways but maybe that is jus=
t
> not wanted in productive system.
>
> That said, it doesn't really feel right, does it?
>
>
> Mikael
>

It use to be hard to "break on throw" in some debuggers, but that is
now a common/easy thing to do I think.

If you have lots of code that throws for normal flow control, then
"break on throw" is annoying.  But I don't think we need to help that
case.


Tony

--=20




.

> It use to be hard to "break on throw" in some debuggers, but that is
> now a common/easy thing to do I think.

I agree, at least if you can run the program under debugger always.
Sometimes you might want not to,
for example running multiple instances or so. In which case for example
on windows having the assert
gives you still possibility to attach to the failed instance when as the
exception you would not even notice.


Mikael

--




.

------=_Part_85_3887025.1354019920936
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, November 27, 2012 12:27:31 AM UTC+1, Mikael Kilpel=E4inen wrote=
:

> > It use to be hard to "break on throw" in some debuggers, but that is=20
> > now a common/easy thing to do I think.=20
>
> I agree, at least if you can run the program under debugger always.=20
> Sometimes you might want not to,=20
> for example running multiple instances or so. In which case for example=
=20
> on windows having the assert=20
> gives you still possibility to attach to the failed instance when as the=
=20
> exception you would not even notice.=20
>

Isn't that best solved with a compile switch to break on throw, even when=
=20
not in the debugger?=20

--=20




------=_Part_85_3887025.1354019920936
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, November 27, 2012 12:27:31 AM UTC+1, Mikael Kilpel=E4inen wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; It use to be hard to=
 "break on throw" in some debuggers, but that is
<br>&gt; now a common/easy thing to do I think.
<br>
<br>I agree, at least if you can run the program under debugger always.=20
<br>Sometimes you might want not to,
<br>for example running multiple instances or so. In which case for example=
=20
<br>on windows having the assert
<br>gives you still possibility to attach to the failed instance when as th=
e=20
<br>exception you would not even notice.
<br></blockquote><div><br></div><div>Isn't that best solved with a compile =
switch to break on throw, even when not in the debugger?&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_85_3887025.1354019920936--

.

------=_Part_779_21094362.1366893994001
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, November 15, 2012 11:30:11 AM UTC+1, Beman Dawes wrote:

> On Thu, Nov 15, 2012 at 4:17 AM, Olaf van der Spek <olafv...@gmail.com<javascript:>>
> wrote:
> > Assert is quite a handy tool, but it's a bit limited.
> >
> > Some expressions need to be evaluated regardless of NDEBUG being
> defined.
> > BOOST_VERIFY solves this case.
>
> BOOST_ASSERT_MSG, which is the same as assert(), but with an
> additional argument specifying a string associated with an assert
> failure, is much more useful than a plain assert(), IMO. I use it a
> great deal.
>
> > Sometimes, the expression needs to be checked too. Would it be possible
> to
> > have standard C++ tools for these use cases?
>
> The only way to know for sure is to write a proposal. You can ask on
> this list, but that will only give you the opinion of a small subset
> of the LWG.
>
>
LEWG didn't seem too fond on the proposal. Unfortunately I wasn't present
in person, but I'd love to hear the concrete arguments against.

--

---
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/?hl=en.



------=_Part_779_21094362.1366893994001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, November 15, 2012 11:30:11 AM UTC+1, Beman Dawes wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Nov 15, 2012 at 4:17 AM, =
Olaf van der Spek &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"EVJUsonGwm4J">olafv...@gmail.com</a>&gt; wrote:
<br>&gt; Assert is quite a handy tool, but it's a bit limited.
<br>&gt;
<br>&gt; Some expressions need to be evaluated regardless of NDEBUG being d=
efined.
<br>&gt; BOOST_VERIFY solves this case.
<br>
<br>BOOST_ASSERT_MSG, which is the same as assert(), but with an
<br>additional argument specifying a string associated with an assert
<br>failure, is much more useful than a plain assert(), IMO. I use it a
<br>great deal.
<br>
<br>&gt; Sometimes, the expression needs to be checked too. Would it be pos=
sible to
<br>&gt; have standard C++ tools for these use cases?
<br>
<br>The only way to know for sure is to write a proposal. You can ask on
<br>this list, but that will only give you the opinion of a small subset
<br>of the LWG.
<br><br></blockquote><div><br></div><div><span style=3D"font-family: arial,=
 sans-serif;">LEWG</span><span style=3D"font-family: arial, sans-serif;">&n=
bsp;didn't seem too fond on the proposal. Unfortunately I wasn't present in=
 person, but I'd love to hear the concrete arguments against.</span>&nbsp;<=
/div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_779_21094362.1366893994001--

.

------=_Part_612_27961181.1366917615296
Content-Type: text/plain; charset=ISO-8859-1



>
> LEWG didn't seem too fond on the proposal. Unfortunately I wasn't present
> in person, but I'd love to hear the concrete arguments against.
>

What happens was this. In a previous section N3604 was presented and some
suggestions were given to improve it. You paper was discussed later and
those present at the discussion felt that N3654 had a big overlap with
yours. Then someone sugested that your proposal could be a "patch" on top
of a future revision of N3604.

That's what I recall but I might be forgeting something.

HTH
Cassio.

--

---
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/?hl=en.



------=_Part_612_27961181.1366917615296
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div><br></div><div><span =
style=3D"font-family:arial,sans-serif">LEWG</span><span style=3D"font-famil=
y:arial,sans-serif">&nbsp;didn't seem too fond on the proposal. Unfortunate=
ly I wasn't present in person, but I'd love to hear the concrete arguments =
against.</span>&nbsp;</div></blockquote><div><br>What happens was this. In =
a previous section N3604 was presented and some suggestions were given to i=
mprove it. You paper was discussed later and those present at the discussio=
n felt that N3654 had a big overlap with yours. Then someone sugested that =
your proposal could be a "patch" on top of a future revision of N3604.<br><=
br>That's what I recall but I might be forgeting something.<br><br>HTH<br>C=
assio.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_612_27961181.1366917615296--

.

--047d7b3a897aaf0faf04db3bc899
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 20, 2012 at 8:48 AM, Mikael Kilpel=E4inen <
mikael.kilpelainen@gmail.com> wrote:

>
> btw, I wonder how many people use assert like construct that asserts on
> debug build on throws on release build?
>
>
A couple of days ago I was discussing this with a collegue. It was on the
context of some Javascript programming guidelines we were defining for the
team, but the discussion heavily consider C++ practice, so I'd like to
share some points.

I argued that:

1)

asserts should throw in any case and never abort. In Eiffel, the violation
to a preconditon raises an exception. So do the error checks in Ada.  In C,
it doesn't but I believe is just a consequence of C not supporting
exceptions. C++ just inherited from C so teh behavior is the same.

2)

The purpose of asserts is not to aid debugging but to increase program
robustness. As such, the only reason for turning assert off is to increase
performance. Since in C and C++ performance is often, if not always, the
primary concern, the defaut practice is to turn off asserts in a release
build. However, this reasonable practice leads to the false idea that you
only need asserts in a debug build. That's just flipped. What happens is
that you cannot afford asserts in a release run, which is quite different.
In fact, if you program in Eiffel you just can't turn it off, but then you
don't care about performance. Likewise, in a highly dynamic language such
as Smalltalk, or Ruby, or Javascript (etc), performance is not the primary
concern so you get "language asserts" (range checks, message binding
checks, etc) no matter what (can't turn that off)

Now

because of (1) and (2) I believe that C++ needs:

(A)
a *different* (to avoid compat issues) precondition checking macro, say
"ensure", that, when the expression evaluates to false, calls a
user-defined callback and whose default implementation throws (much like
matherr)

(B)
uses NDEBUG to turn it off for performance reasons but provides an separate
version that is always on even in release (say, debug_ensure/release_ensure=
)

Best

--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=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/?hl=3Den.



--047d7b3a897aaf0faf04db3bc899
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Nov 20, 2012 at 8:48 AM, Mikael Kilpel=E4inen <span dir=3D"ltr">&lt;<a =
href=3D"mailto:mikael.kilpelainen@gmail.com" target=3D"_blank">mikael.kilpe=
lainen@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
btw, I wonder how many people use assert like construct that asserts on deb=
ug build on throws on release build?<span class=3D"HOEnZb"><font color=3D"#=
888888"><br>
</font></span><br clear=3D"all"></blockquote><div><br></div><div>A couple o=
f days ago I was discussing this with a collegue. It was on the context of =
some Javascript programming guidelines we were defining for the team, but t=
he discussion heavily consider C++ practice, so I&#39;d like to share some =
points.<br>

<br></div><div>I argued that:<br><br></div><div>1)<br><br>asserts should th=
row in any case and never abort. In Eiffel, the violation to a preconditon =
raises an exception. So do the error checks in Ada.=A0 In C, it doesn&#39;t=
 but I believe is just a consequence of C not supporting exceptions. C++ ju=
st inherited from C so teh behavior is the same.<br>

<br>2)<br><br></div><div>The purpose of asserts is not to aid debugging but=
 to increase program robustness. As such, the only reason for turning asser=
t off is to increase performance. Since in C and C++ performance is often, =
if not always, the primary concern, the defaut practice is to turn off asse=
rts in a release build. However, this reasonable practice leads to the fals=
e idea that you only need asserts in a debug build. That&#39;s just flipped=
.. What happens is that you cannot afford asserts in a release run, which is=
 quite different. In fact, if you program in Eiffel you just can&#39;t turn=
 it off, but then you don&#39;t care about performance. Likewise, in a high=
ly dynamic language such as Smalltalk, or Ruby, or Javascript (etc), perfor=
mance is not the primary concern so you get &quot;language asserts&quot; (r=
ange checks, message binding checks, etc) no matter what (can&#39;t turn th=
at off)<br>

<br></div><div>Now<br><br></div><div>because of (1) and (2) I believe that =
C++ needs:<br><br>(A) <br>a *different* (to avoid compat issues) preconditi=
on checking macro, say &quot;ensure&quot;, that, when the expression evalua=
tes to false, calls a user-defined callback and whose default implementatio=
n throws (much like matherr)<br>

<br>(B)<br>uses NDEBUG to turn it off for performance reasons but provides =
an separate version that is always on even in release (say, debug_ensure/re=
lease_ensure)<br><br></div><div>Best<br></div></div><br>-- <br>Fernando Cac=
ciola<br>

SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com=
">http://www.scisoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b3a897aaf0faf04db3bc899--

.

------=_Part_1809_29319835.1366958654581
Content-Type: text/plain; charset=ISO-8859-1



On Friday, April 26, 2013 5:14:43 AM UTC+1, Fernando Cacciola wrote:
>
> because of (1) and (2) I believe that C++ needs:
>
> (A)
> a *different* (to avoid compat issues) precondition checking macro, say
> "ensure", that, when the expression evaluates to false, calls a
> user-defined callback and whose default implementation throws (much like
> matherr)
>
> (B)
> uses NDEBUG to turn it off for performance reasons but provides an
> separate version that is always on even in release (say,
> debug_ensure/release_ensure)
>
>
Basically, that is what N3604 is about:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3604.pdf

I'm not sure whether the default behavior for assertions that fail is
throwing an exception. However,  users can customize the handling mechanism
and get this behavior.

Cheers,
Cassio.

--

---
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/?hl=en.



------=_Part_1809_29319835.1366958654581
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, April 26, 2013 5:14:43 AM UTC+1, Fernando Cacciola wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote">because of (1) and (2) I believe that C++ needs:<br><di=
v><br>(A) <br>a *different* (to avoid compat issues) precondition checking =
macro, say "ensure", that, when the expression evaluates to false, calls a =
user-defined callback and whose default implementation throws (much like ma=
therr)<br>

<br>(B)<br>uses NDEBUG to turn it off for performance reasons but provides =
an separate version that is always on even in release (say, debug_ensure/re=
lease_ensure)<br><br></div></div></div></div></blockquote><div><br>Basicall=
y, that is what N3604 is about:<br><br>http://www.open-std.org/jtc1/sc22/wg=
21/docs/papers/2013/n3604.pdf <br><br>I'm not sure whether the default beha=
vior for assertions that fail is throwing an exception. However,&nbsp; user=
s can customize the handling mechanism and get this behavior.<br><br>Cheers=
,<br>Cassio.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1809_29319835.1366958654581--

.

On Fri, Apr 26, 2013 at 6:14 AM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> asserts should throw in any case and never abort. In Eiffel, the violation
> to a preconditon raises an exception. So do the error checks in Ada.  In C,
> it doesn't but I believe is just a consequence of C not supporting
> exceptions. C++ just inherited from C so teh behavior is the same.

Is the only argument for throwing that other languages throw (too)?

> 2)
>
> The purpose of asserts is not to aid debugging but to increase program
> robustness. As such, the only reason for turning assert off is to increase
> performance. Since in C and C++ performance is often, if not always, the
> primary concern, the defaut practice is to turn off asserts in a release
> build. However, this reasonable practice leads to the false idea that you
> only need asserts in a debug build. That's just flipped. What happens is
> that you cannot afford asserts in a release run, which is quite different.
> In fact, if you program in Eiffel you just can't turn it off, but then you
> don't care about performance. Likewise, in a highly dynamic language such as
> Smalltalk, or Ruby, or Javascript (etc), performance is not the primary
> concern so you get "language asserts" (range checks, message binding checks,
> etc) no matter what (can't turn that off)

N3500 proposed a variant that also checks when NDEBUG is defined.

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3500.htm

> (A)
> a *different* (to avoid compat issues) precondition checking macro, say
> "ensure", that, when the expression evaluates to false, calls a user-defined
> callback and whose default implementation throws (much like matherr)
>
> (B)
> uses NDEBUG to turn it off for performance reasons but provides an separate
> version that is always on even in release (say, debug_ensure/release_ensure)

If you want an always checking variant that throws, can't you use if
(!X) throw Y?

IMO the choice (of aborting vs throwing) should be left to the
(program) developer.
--
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/?hl=en.



.

--e89a8f6471cb5b9d1d04db3ec6dd
Content-Type: text/plain; charset=ISO-8859-1

On 25 April 2013 23:14, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:

> asserts should throw in any case and never abort.
>

No.

A precondition violation is a programming error.  When you detect a
programming error, your program is in an unknown state, so you do not know
what the effects of running more user code (such as destructors) will be.
The reason one usually terminates from assert is because that is the
simplest way to get your system back into a known state (safety critical
systems may have more complicated mechanisms).

In C++ (and similarly in C), violating a precondition in the Standard
typically results in undefined behavior, which means your system is allowed
to do whatever it wants, including not running your destructors.

People mix this up all the time.  vector::at() is *not* a precondition
checker; it has *no* preconditions to check; it is a wide contract.  There
is no value that is illegal to call it with.

The purpose of asserts is not to aid debugging but to increase program
> robustness.
>

Well, it's both; otherwise, there is no reason to even print a message when
you assert.


> As such, the only reason for turning assert off is to increase performance.
>

I agree that is why people turn off asserts.


> (A)
> a *different* (to avoid compat issues) precondition checking macro, say
> "ensure", that, when the expression evaluates to false, calls a
> user-defined callback and whose default implementation throws (much like
> matherr)
>

As far as checking preconditions found in the Standard, the only way this
could work is if the Standard turns undefined behavior into defined
behavior.


How these proposed facilities work with code outside of things specified in
the Standard are, of course, beyond what the Standard can address.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/?hl=en.



--e89a8f6471cb5b9d1d04db3ec6dd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 25 April 2013 23:14, Fernando Cacciola <span dir=3D"ltr">&lt;<a href=3D"=
mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacciola@gma=
il.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D"im">asserts should throw in any case and never abort. </div></div=
></div></div></blockquote><div><br></div><div>No.</div><div><br></div><div>=
A precondition violation is a programming error. =A0When you detect a progr=
amming error, your program is in an unknown state, so you do not know what =
the effects of running more user code (such as destructors) will be. The re=
ason one usually terminates from assert is because that is the simplest way=
 to get your system back into a known state (safety critical systems may ha=
ve more complicated mechanisms).</div>

<div><br></div><div>In C++ (and similarly in C), violating a precondition i=
n the Standard typically results in undefined behavior, which means your sy=
stem is allowed to do whatever it wants, including not running your destruc=
tors.</div>

<div><br></div><div>People mix this up all the time. =A0vector::at() is *no=
t* a precondition checker; it has *no* preconditions to check; it is a wide=
 contract. =A0There is no value that is illegal to call it with.</div><div>

<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><div>The purpose of asserts is not to =
aid debugging but to increase program robustness. </div>

</div></div></div></blockquote><div><br></div><div>Well, it&#39;s both; oth=
erwise, there is no reason to even print a message when you assert.</div><d=
iv>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>As such, the only reason for turning assert off is to increase performance=
..</div></div></div></div></blockquote><div><br></div><div>I agree that is w=
hy people turn off asserts.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div>(A)=A0</div><div>a *different=
* (to avoid compat issues) precondition checking macro, say &quot;ensure&qu=
ot;, that, when the expression evaluates to false, calls a user-defined cal=
lback and whose default implementation throws (much like matherr)<br>

</div></div></div></div></blockquote><div><br></div><div>As far as checking=
 preconditions found in the Standard, the only way this could work is if th=
e Standard turns undefined behavior into defined behavior.</div><div><br>

</div><div><br></div><div>How these proposed facilities work with code outs=
ide of things specified in the Standard are, of course, beyond what the Sta=
ndard can address.</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;=
mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@ev=
iloverlord.com</a>&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--e89a8f6471cb5b9d1d04db3ec6dd--

.

------=_Part_1998_30411002.1366967062528
Content-Type: text/plain; charset=ISO-8859-1



> I argued that:
>
> 1)
>
> asserts should throw in any case and never abort. In Eiffel, the violation
> to a preconditon raises an exception. So do the error checks in Ada.  In C,
> it doesn't but I believe is just a consequence of C not supporting
> exceptions. C++ just inherited from C so teh behavior is the same.
>
> 2)
>
> The purpose of asserts is not to aid debugging but to increase program
> robustness. As such, the only reason for turning assert off is to increase
> performance. Since in C and C++ performance is often, if not always, the
> primary concern, the defaut practice is to turn off asserts in a release
> build. However, this reasonable practice leads to the false idea that you
> only need asserts in a debug build. That's just flipped. What happens is
> that you cannot afford asserts in a release run, which is quite different.
> In fact, if you program in Eiffel you just can't turn it off, but then you
> don't care about performance. Likewise, in a highly dynamic language such
> as Smalltalk, or Ruby, or Javascript (etc), performance is not the primary
> concern so you get "language asserts" (range checks, message binding
> checks, etc) no matter what (can't turn that off)
>
> Now
>
> because of (1) and (2) I believe that C++ needs:
>
> (A)
> a *different* (to avoid compat issues) precondition checking macro, say
> "ensure", that, when the expression evaluates to false, calls a
> user-defined callback and whose default implementation throws (much like
> matherr)
>
> (B)
> uses NDEBUG to turn it off for performance reasons but provides an
> separate version that is always on even in release (say,
> debug_ensure/release_ensure)
>

Let me take the opportunity to present my *opinion* here. Preconditions
represent conditions that should have never occurred, which are the
consequences of pieces of code that should have never been written (bugs).
The only proper way of "handling" such preconditions in C++ would be a sort
of static analysis that would report such bugs at compile time. This is too
unrealistic in general, but preconditions could be used as a tool to assist
such static analyser and render the detection of certain bugs possible. In
this post:
http://akrzemi1.wordpress.com/2013/04/18/preconditions-part-iv/#lang_feature
I tried to outline how such support could look like.

Regards,
&rzej

--

---
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/?hl=en.



------=_Part_1998_30411002.1366967062528
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<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><div=
 class=3D"gmail_quote"><div>I argued that:<br><br></div><div>1)<br><br>asse=
rts should throw in any case and never abort. In Eiffel, the violation to a=
 preconditon raises an exception. So do the error checks in Ada.&nbsp; In C=
, it doesn't but I believe is just a consequence of C not supporting except=
ions. C++ just inherited from C so teh behavior is the same.<br>

<br>2)<br><br></div><div>The purpose of asserts is not to aid debugging but=
 to increase program robustness. As such, the only reason for turning asser=
t off is to increase performance. Since in C and C++ performance is often, =
if not always, the primary concern, the defaut practice is to turn off asse=
rts in a release build. However, this reasonable practice leads to the fals=
e idea that you only need asserts in a debug build. That's just flipped. Wh=
at happens is that you cannot afford asserts in a release run, which is qui=
te different. In fact, if you program in Eiffel you just can't turn it off,=
 but then you don't care about performance. Likewise, in a highly dynamic l=
anguage such as Smalltalk, or Ruby, or Javascript (etc), performance is not=
 the primary concern so you get "language asserts" (range checks, message b=
inding checks, etc) no matter what (can't turn that off)<br>

<br></div><div>Now<br><br></div><div>because of (1) and (2) I believe that =
C++ needs:<br><br>(A) <br>a *different* (to avoid compat issues) preconditi=
on checking macro, say "ensure", that, when the expression evaluates to fal=
se, calls a user-defined callback and whose default implementation throws (=
much like matherr)<br>

<br>(B)<br>uses NDEBUG to turn it off for performance reasons but provides =
an separate version that is always on even in release (say, debug_ensure/re=
lease_ensure)</div></div></div></div></blockquote><div><br>Let me take the =
opportunity to present my *opinion* here. Preconditions represent condition=
s that should have never occurred, which are the consequences of pieces of =
code that should have never been written (bugs). The only proper way of "ha=
ndling" such preconditions in C++ would be a sort of static analysis that w=
ould report such bugs at compile time. This is too unrealistic in general, =
but preconditions could be used as a tool to assist such static analyser an=
d render the detection of certain bugs possible. In this post: <br><a href=
=3D"http://akrzemi1.wordpress.com/2013/04/18/preconditions-part-iv/#lang_fe=
ature">http://akrzemi1.wordpress.com/2013/04/18/preconditions-part-iv/#lang=
_feature</a><br>I tried to outline how such support could look like.<br><br=
>Regards,<br>&amp;rzej<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1998_30411002.1366967062528--

.

--089e014950ee6b29d604db41ce89
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think Andzrej position gives a very reasonable route.

Of course, syntax is always a sort of bike shedding. :-)

I should remark that the newest Ada standard (Ada12) has also taken the
preconditions/contracts route
--
  J. Daniel


On Fri, Apr 26, 2013 at 4:04 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om>wrote:

>
> I argued that:
>>
>> 1)
>>
>> asserts should throw in any case and never abort. In Eiffel, the
>> violation to a preconditon raises an exception. So do the error checks i=
n
>> Ada.  In C, it doesn't but I believe is just a consequence of C not
>> supporting exceptions. C++ just inherited from C so teh behavior is the
>> same.
>>
>> 2)
>>
>> The purpose of asserts is not to aid debugging but to increase program
>> robustness. As such, the only reason for turning assert off is to increa=
se
>> performance. Since in C and C++ performance is often, if not always, the
>> primary concern, the defaut practice is to turn off asserts in a release
>> build. However, this reasonable practice leads to the false idea that yo=
u
>> only need asserts in a debug build. That's just flipped. What happens is
>> that you cannot afford asserts in a release run, which is quite differen=
t.
>> In fact, if you program in Eiffel you just can't turn it off, but then y=
ou
>> don't care about performance. Likewise, in a highly dynamic language suc=
h
>> as Smalltalk, or Ruby, or Javascript (etc), performance is not the prima=
ry
>> concern so you get "language asserts" (range checks, message binding
>> checks, etc) no matter what (can't turn that off)
>>
>> Now
>>
>> because of (1) and (2) I believe that C++ needs:
>>
>> (A)
>> a *different* (to avoid compat issues) precondition checking macro, say
>> "ensure", that, when the expression evaluates to false, calls a
>> user-defined callback and whose default implementation throws (much like
>> matherr)
>>
>> (B)
>> uses NDEBUG to turn it off for performance reasons but provides an
>> separate version that is always on even in release (say,
>> debug_ensure/release_ensure)
>>
>
> Let me take the opportunity to present my *opinion* here. Preconditions
> represent conditions that should have never occurred, which are the
> consequences of pieces of code that should have never been written (bugs)=
..
> The only proper way of "handling" such preconditions in C++ would be a so=
rt
> of static analysis that would report such bugs at compile time. This is t=
oo
> unrealistic in general, but preconditions could be used as a tool to assi=
st
> such static analyser and render the detection of certain bugs possible. I=
n
> this post:
>
> http://akrzemi1.wordpress.com/2013/04/18/preconditions-part-iv/#lang_feat=
ure
> I tried to outline how such support could look like.
>
> Regards,
> &rzej
>
> --
>
> ---
> 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/?hl=3Den.
>
>
>

--=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/?hl=3Den.



--089e014950ee6b29d604db41ce89
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think Andzrej position gives a very reasonable route.<di=
v><br></div><div style>Of course, syntax is always a sort of bike shedding.=
 :-)</div><div style><br></div><div style>I should remark that the newest A=
da standard (Ada12) has also taken the preconditions/contracts route</div>

<div style>--</div><div style>=C2=A0 J. Daniel</div><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote">On Fri, Apr 26, 2013 at 4:04 AM, And=
rzej Krzemie=C5=84ski <span dir=3D"ltr">&lt;<a href=3D"mailto:akrzemi1@gmai=
l.com" target=3D"_blank">akrzemi1@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">

<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>I argued that:<br><br=
></div><div>1)<br><br>asserts should throw in any case and never abort. In =
Eiffel, the violation to a preconditon raises an exception. So do the error=
 checks in Ada.=C2=A0 In C, it doesn&#39;t but I believe is just a conseque=
nce of C not supporting exceptions. C++ just inherited from C so teh behavi=
or is the same.<br>



<br>2)<br><br></div><div>The purpose of asserts is not to aid debugging but=
 to increase program robustness. As such, the only reason for turning asser=
t off is to increase performance. Since in C and C++ performance is often, =
if not always, the primary concern, the defaut practice is to turn off asse=
rts in a release build. However, this reasonable practice leads to the fals=
e idea that you only need asserts in a debug build. That&#39;s just flipped=
.. What happens is that you cannot afford asserts in a release run, which is=
 quite different. In fact, if you program in Eiffel you just can&#39;t turn=
 it off, but then you don&#39;t care about performance. Likewise, in a high=
ly dynamic language such as Smalltalk, or Ruby, or Javascript (etc), perfor=
mance is not the primary concern so you get &quot;language asserts&quot; (r=
ange checks, message binding checks, etc) no matter what (can&#39;t turn th=
at off)<br>



<br></div><div>Now<br><br></div><div>because of (1) and (2) I believe that =
C++ needs:<br><br>(A) <br>a *different* (to avoid compat issues) preconditi=
on checking macro, say &quot;ensure&quot;, that, when the expression evalua=
tes to false, calls a user-defined callback and whose default implementatio=
n throws (much like matherr)<br>



<br>(B)<br>uses NDEBUG to turn it off for performance reasons but provides =
an separate version that is always on even in release (say, debug_ensure/re=
lease_ensure)</div></div></div></div></blockquote></div><div><br>Let me tak=
e the opportunity to present my *opinion* here. Preconditions represent con=
ditions that should have never occurred, which are the consequences of piec=
es of code that should have never been written (bugs). The only proper way =
of &quot;handling&quot; such preconditions in C++ would be a sort of static=
 analysis that would report such bugs at compile time. This is too unrealis=
tic in general, but preconditions could be used as a tool to assist such st=
atic analyser and render the detection of certain bugs possible. In this po=
st: <br>

<a href=3D"http://akrzemi1.wordpress.com/2013/04/18/preconditions-part-iv/#=
lang_feature" target=3D"_blank">http://akrzemi1.wordpress.com/2013/04/18/pr=
econditions-part-iv/#lang_feature</a><br>I tried to outline how such suppor=
t could look like.<br>

<br>Regards,<br>&amp;rzej<br></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@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/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=C2=A0<br>
=C2=A0<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div></div><=
/div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e014950ee6b29d604db41ce89--

.

--047d7b33d31c4a582e04db420c71
Content-Type: text/plain; charset=ISO-8859-1

On 26 April 2013 14:25, J. Daniel Garcia <josedaniel.garcia@uc3m.es> wrote:

> I think Andzrej position gives a very reasonable route.
>
> Of course, syntax is always a sort of bike shedding. :-)
>
> I should remark that the newest Ada standard (Ada12) has also taken the
> preconditions/contracts route
>

If that's the route you're looking for, do take a look at
http://open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1962.html

--

---
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/?hl=en.



--047d7b33d31c4a582e04db420c71
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 26 April 2013 14:25, J. Daniel Garcia <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:josedaniel.garcia@uc3m.es" target=3D"_blank">josedaniel.garci=
a@uc3m.es</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I think =
Andzrej position gives a very reasonable route.<div><br></div><div>Of cours=
e, syntax is always a sort of bike shedding. :-)</div>
<div><br></div><div>I should remark that the newest Ada standard (Ada12) ha=
s also taken the preconditions/contracts route</div></div></blockquote><div=
><br></div><div>If that&#39;s the route you&#39;re looking for, do take a l=
ook at<br>
<a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1962.html">=
http://open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1962.html</a><br><br><=
/div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b33d31c4a582e04db420c71--

.

--089e0118279c73730004db425fc5
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 26, 2013 at 4:46 AM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Fri, Apr 26, 2013 at 6:14 AM, Fernando Cacciola
> <fernando.cacciola@gmail.com> wrote:
> > asserts should throw in any case and never abort. In Eiffel, the
> violation
> > to a preconditon raises an exception. So do the error checks in Ada.  In
> C,
> > it doesn't but I believe is just a consequence of C not supporting
> > exceptions. C++ just inherited from C so teh behavior is the same.
>
> Is the only argument for throwing that other languages throw (too)?
>
> No.

In any case, those aren't just other languages. They are the two most
popular languages that have been explicitly designed to address programming
errors (and not just system failures like all the rest)


>
> N3500 proposed a variant that also checks when NDEBUG is defined.
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3500.htm
>

Nice. I'll read it when I finish responding here.


>
> > (A)
> > a *different* (to avoid compat issues) precondition checking macro, say
> > "ensure", that, when the expression evaluates to false, calls a
> user-defined
> > callback and whose default implementation throws (much like matherr)
> >
> > (B)
> > uses NDEBUG to turn it off for performance reasons but provides an
> separate
> > version that is always on even in release (say,
> debug_ensure/release_ensure)
>
> If you want an always checking variant that throws, can't you use if
> (!X) throw Y?
>
>
Yes. Is just that I want more than just that.


> IMO the choice (of aborting vs throwing) should be left to the
> (program) developer.
>

From the POV of library design, I totally agree, that's why I effectively
proposed that assert violations just call a user-defined function. That's
separate however from my claim that the choice should never be to abort
except in very peculiar cases.

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--089e0118279c73730004db425fc5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Apr 26, 2013 at 4:46 AM, Olaf van der Spek <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a=
>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Fri, Apr 26, 2013 at 6:=
14 AM, Fernando Cacciola<br>
&lt;<a href=3D"mailto:fernando.cacciola@gmail.com">fernando.cacciola@gmail.=
com</a>&gt; wrote:<br>
&gt; asserts should throw in any case and never abort. In Eiffel, the viola=
tion<br>
&gt; to a preconditon raises an exception. So do the error checks in Ada. =
=A0In C,<br>
&gt; it doesn&#39;t but I believe is just a consequence of C not supporting=
<br>
&gt; exceptions. C++ just inherited from C so teh behavior is the same.<br>
<br>
</div>Is the only argument for throwing that other languages throw (too)?<b=
r>
<div class=3D"im"><br></div></blockquote><div>No.<br><br></div><div>In any =
case, those aren&#39;t just other languages. They are the two most popular =
languages that have been explicitly designed to address programming errors =
(and not just system failures like all the rest)<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div class=3D"im">
<br>
</div>N3500 proposed a variant that also checks when NDEBUG is defined.<br>
<br>
<a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3500.ht=
m" target=3D"_blank">http://www.open-std.org/JTC1/SC22/WG21/docs/papers/201=
3/n3500.htm</a><br></blockquote><div><br></div><div>Nice. I&#39;ll read it =
when I finish responding here.<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br>
&gt; (A)<br>
&gt; a *different* (to avoid compat issues) precondition checking macro, sa=
y<br>
&gt; &quot;ensure&quot;, that, when the expression evaluates to false, call=
s a user-defined<br>
&gt; callback and whose default implementation throws (much like matherr)<b=
r>
&gt;<br>
&gt; (B)<br>
&gt; uses NDEBUG to turn it off for performance reasons but provides an sep=
arate<br>
&gt; version that is always on even in release (say, debug_ensure/release_e=
nsure)<br>
<br>
</div>If you want an always checking variant that throws, can&#39;t you use=
 if<br>
(!X) throw Y?<br>
<br></blockquote><div><br></div><div>Yes. Is just that I want more than jus=
t that.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
IMO the choice (of aborting vs throwing) should be left to the<br>
(program) developer.<br></blockquote><div><br></div><div>From the POV of li=
brary design, I totally agree, that&#39;s why I effectively proposed that a=
ssert violations just call a user-defined function. That&#39;s separate how=
ever from my claim that the choice should never be to abort except in very =
peculiar cases.<br>

</div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br>=
<a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting=
..com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e0118279c73730004db425fc5--

.

--047d7b344168aaa3d604db42e3fb
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 26, 2013 at 4:48 AM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 25 April 2013 23:14, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>
>> asserts should throw in any case and never abort.
>>
>
> No.
>
> Let's see :)


> A precondition violation is a programming error.
>

Agreed


>  When you detect a programming error, your program is in an unknown state
>

Not really. Your program is in an unknown state when there is a programmer
error *and you don't detect it",or when you do detect it but you don't do
anything to handle it.

The purpose of detecting the error is to prevent the program from entering
unknown state by allowing you to handle it.



> , so you do not know what the effects of running more user code (such as
> destructors) will be.
>

This is something that sometimes occurs in practice but is not a
consequence of throwing as a response to the detection of an error. It is
because the detection of the error happen too late and there where previous
programming errors undetected.

You can wind up in unknown state if a function is properly telling you that
you made a programmer error but you don't handle it properly. In any case,
throwing on precondition violation is never ever the cause for state
corruption.


> The reason one usually terminates from assert is because that is the
> simplest way to get your system back into a known state (safety critical
> systems may have more complicated mechanisms).
>

It might be that people falsely believe that you need to get your system
back into a known state after you detect a programming error. But then the
reason for abort() is just flawed.
Like I said, detecting a programming error *before* it causes a problem
(i.e. checking a *precondition* as opposed to an invariant or a
post-condition) if never a reason to panic and try to get back to a known
state as quick as possible. That would only be needed if you violated other
preconditions before and didn't detect it. And, if you do detect
programming errors bu checking preconditions, you can *and should* handle
it so that it doesn't result in corrupted state even though the failed
function itself didn't cause that (because it failed before doing any harm)


> In C++ (and similarly in C), violating a precondition in the Standard
> typically results in undefined behavior
>

Right.

The reason is that the precondition states what is required in order to
ensure that the execution of a function does not result in UB. Naturally,
if you do execute the function violating its preconditions, you reach UB.

OTOH, a precondition *check*, that is, assert(), is the tool that prevents
the function for ever executing if the preconditions are violated, in which
case there is no UB at all (caused by the function call)

In C++ and C we just don't check preconditions (unless we are debugging)
for performance reasons, but that's it.


> , which means your system is allowed to do whatever it wants, including
> not running your destructors.
>
> IF the function was executed with its preconditions violated. But this
just doesn't happen if you explicitely check for that and abort *the
function" before doing any harm.


> People mix this up all the time.  vector::at() is *not* a precondition
> checker; it has *no* preconditions to check; it is a wide contract.  There
> is no value that is illegal to call it with.
>
> Agreed

OTOH,

vector.at(-1) is a programmer error just as vector[-1] is.

And in the case of at(-1), that error is explicitely *recognized as such*
but the function, which is the reason it throws an exception. If the intent
where to simply winden the contract to make any argument legal, it could do
so and, for instance, return a default constructed T(). But it doesn't do
that because the intention is to widen the contract but also to signal out
that the argument is out of range, and it intends to do that because any
out of range argument is a programming error.

Just like at() provides a convenient mechanism to signal programming
errors, that is, an exception, detecting the violation to a precondition,
which is also a programming error, should also be reported by the same
mechanism. Otherwise, if the response to a precondition violation should be
anything else, so should be the response of at(), since in both cases it is
the response to a programming error (and the exact same error in fact)

Unless you would argue that calling at() with an out of range argument is
not the same programming error as in calling [] with the same argument. If
that's your position, can you present a realistic, sound example?



> The purpose of asserts is not to aid debugging but to increase program
>> robustness.
>>
>
> Well, it's both; otherwise, there is no reason to even print a message
> when you assert.
>
>
OK, yes, it is both. I actually wanted to negate that is only for debugging
but ended up removing it from the purposes.


> As such, the only reason for turning assert off is to increase performance.
>>
>
> I agree that is why people turn off asserts.
>
>
>> (A)
>> a *different* (to avoid compat issues) precondition checking macro, say
>> "ensure", that, when the expression evaluates to false, calls a
>> user-defined callback and whose default implementation throws (much like
>> matherr)
>>
>
> As far as checking preconditions found in the Standard, the only way this
> could work is if the Standard turns undefined behavior into defined
> behavior.
>
> Right.


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--047d7b344168aaa3d604db42e3fb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Apr 26, 2013 at 4:48 AM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 25 April 2013 23:14, Fe=
rnando Cacciola <span dir=3D"ltr">&lt;<a href=3D"mailto:fernando.cacciola@g=
mail.com" target=3D"_blank">fernando.cacciola@gmail.com</a>&gt;</span> wrot=
e:<br>

</div><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>asserts should throw in any case and never abort. </div></div></div></div>=
</blockquote><div><br></div></div><div>No.</div><div><br></div></div></bloc=
kquote>

<div>Let&#39;s see :)<br>=A0<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div c=
lass=3D"gmail_quote"><div></div><div>A precondition violation is a programm=
ing error.</div>

</div></blockquote><div><br></div><div>Agreed<br>=A0<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div class=3D"gmail_quote"><div> =A0When you detect a pro=
gramming error, your program is in an unknown state</div>

</div></blockquote><div><br></div><div>Not really. Your program is in an un=
known state when there is a programmer error *and you don&#39;t detect it&q=
uot;,or when you do detect it but you don&#39;t do anything to handle it.<b=
r>

<br></div><div>The purpose of detecting the error is to prevent the program=
 from entering unknown state by allowing you to handle it.<br></div><br><di=
v>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">

<div class=3D"gmail_quote"><div>, so you do not know what the effects of ru=
nning more user code (such as destructors) will be. </div></div></blockquot=
e><div><br></div><div>This is something that sometimes occurs in practice b=
ut is not a consequence of throwing as a response to the detection of an er=
ror. It is because the detection of the error happen too late and there whe=
re previous programming errors undetected.<br>

<br></div><div>You can wind up in unknown state if a function is properly t=
elling you that you made a programmer error but you don&#39;t handle it pro=
perly. In any case, throwing on precondition violation is never ever the ca=
use for state corruption.<br>

</div><div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_=
quote"><div>The reason one usually terminates from assert is because that i=
s the simplest way to get your system back into a known state (safety criti=
cal systems may have more complicated mechanisms).</div>

</div></blockquote><div><br></div><div>It might be that people falsely beli=
eve that you need to get your system back into a known state after you dete=
ct a programming error. But then the reason for abort() is just flawed.<br>

Like I said, detecting a programming error *before* it causes a problem (i.=
e. checking a *precondition* as opposed to an invariant or a post-condition=
) if never a reason to panic and try to get back to a known state as quick =
as possible. That would only be needed if you violated other preconditions =
before and didn&#39;t detect it. And, if you do detect programming errors b=
u checking preconditions, you can *and should* handle it so that it doesn&#=
39;t result in corrupted state even though the failed function itself didn&=
#39;t cause that (because it failed before doing any harm)<br>

<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote">

<div><br></div><div>In C++ (and similarly in C), violating a precondition i=
n the Standard typically results in undefined behavior</div></div></blockqu=
ote><div><br></div><div>Right.<br><br></div><div>The reason is that the pre=
condition states what is required in order to ensure that the execution of =
a function does not result in UB. Naturally, if you do execute the function=
 violating its preconditions, you reach UB.<br>

</div><div><br></div><div>OTOH, a precondition *check*, that is, assert(), =
is the tool that prevents the function for ever executing if the preconditi=
ons are violated, in which case there is no UB at all (caused by the functi=
on call)<br>

<br></div><div>In C++ and C we just don&#39;t check preconditions (unless w=
e are debugging) for performance reasons, but that&#39;s it.<br></div><div>=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">

<div class=3D"gmail_quote"><div>, which means your system is allowed to do =
whatever it wants, including not running your destructors.</div>

<div><br></div></div></blockquote><div>IF the function was executed with it=
s preconditions violated. But this just doesn&#39;t happen if you explicite=
ly check for that and abort *the function&quot; before doing any harm.<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div=
></div><div>People mix this up all the time. =A0vector::at() is *not* a pre=
condition checker; it has *no* preconditions to check; it is a wide contrac=
t. =A0There is no value that is illegal to call it with.</div>

<div class=3D"im"><div>

<br></div></div></div></blockquote><div>Agreed<br><br></div><div>OTOH,<br><=
br></div><div><a href=3D"http://vector.at">vector.at</a>(-1) is a programme=
r error just as vector[-1] is.<br><br></div><div>And in the case of at(-1),=
 that error is explicitely *recognized as such* but the function, which is =
the reason it throws an exception. If the intent where to simply winden the=
 contract to make any argument legal, it could do so and, for instance, ret=
urn a default constructed T(). But it doesn&#39;t do that because the inten=
tion is to widen the contract but also to signal out that the argument is o=
ut of range, and it intends to do that because any out of range argument is=
 a programming error.<br>

<br></div><div>Just like at() provides a convenient mechanism to signal pro=
gramming errors, that is, an exception, detecting the violation to a precon=
dition, which is also a programming error, should also be reported by the s=
ame mechanism. Otherwise, if the response to a precondition violation shoul=
d be anything else, so should be the response of at(), since in both cases =
it is the response to a programming error (and the exact same error in fact=
)<br>

<br></div><div>Unless you would argue that calling at() with an out of rang=
e argument is not the same programming error as in calling [] with the same=
 argument. If that&#39;s your position, can you present a realistic, sound =
example?<br>

<br></div>=A0<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote">=
<div class=3D"im"><div></div><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"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>The purpose of asserts is not to aid debugging but to increase program rob=
ustness. </div>

</div></div></div></blockquote><div><br></div></div><div>Well, it&#39;s bot=
h; otherwise, there is no reason to even print a message when you assert.</=
div><div class=3D"im"><div>=A0</div></div></div></blockquote><div>OK, yes, =
it is both. I actually wanted to negate that is only for debugging but ende=
d up removing it from the purposes.<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div=
 class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">



<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>As such, the only reason for turning assert off is to increase performance=
..</div></div></div></div></blockquote><div><br></div></div><div>I agree tha=
t is why people turn off asserts.</div>

<div class=3D"im">

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div>(A)=A0</div><div>a *different=
* (to avoid compat issues) precondition checking macro, say &quot;ensure&qu=
ot;, that, when the expression evaluates to false, calls a user-defined cal=
lback and whose default implementation throws (much like matherr)<br>



</div></div></div></div></blockquote><div><br></div></div><div>As far as ch=
ecking preconditions found in the Standard, the only way this could work is=
 if the Standard turns undefined behavior into defined behavior.</div>

<div><br></div></div></blockquote><div>Right.<br></div></div><br clear=3D"a=
ll"><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br><a href=
=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting.com</a=
>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b344168aaa3d604db42e3fb--

.

--f46d0408930bf65a4c04db430b12
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 26, 2013 at 8:43 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 26 April 2013 14:25, J. Daniel Garcia <josedaniel.garcia@uc3m.es>wrote:
>
>> I think Andzrej position gives a very reasonable route.
>>
>> Of course, syntax is always a sort of bike shedding. :-)
>>
>> I should remark that the newest Ada standard (Ada12) has also taken the
>> preconditions/contracts route
>>
>
> If that's the route you're looking for, do take a look at
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1962.html
>
>
There are lots of details to consider in Andrzej ideas and n1962, but for
sure it is this the sort of thing I believe we need in C++.




--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--f46d0408930bf65a4c04db430b12
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Apr 26, 2013 at 8:43 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 26 April 2013 1=
4:25, J. Daniel Garcia <span dir=3D"ltr">&lt;<a href=3D"mailto:josedaniel.g=
arcia@uc3m.es" target=3D"_blank">josedaniel.garcia@uc3m.es</a>&gt;</span> w=
rote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I think =
Andzrej position gives a very reasonable route.<div><br></div><div>Of cours=
e, syntax is always a sort of bike shedding. :-)</div>


<div><br></div><div>I should remark that the newest Ada standard (Ada12) ha=
s also taken the preconditions/contracts route</div></div></blockquote><div=
><br></div></div><div>If that&#39;s the route you&#39;re looking for, do ta=
ke a look at<br>


<a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1962.html" =
target=3D"_blank">http://open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1962=
..html</a><br><br></div></div></div></div></blockquote><div>=A0</div><div>Th=
ere are lots of details to consider in Andrzej ideas and n1962, but for sur=
e it is this the sort of thing I believe we need in C++.<br>

</div><br></div><br><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>SciSo=
ft Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">htt=
p://www.scisoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--f46d0408930bf65a4c04db430b12--

.

--047d7b344168452d2c04db436fcb
Content-Type: text/plain; charset=ISO-8859-1

Allow me to add something,

There is a significant difference between preconditions, invariants and
postconditions.

Invariants and postconditions refer to the state of the program, so a
violation of these correspond to corrupted state. When you detect that, you
are directly detecting the state corruption that has already happened.

A precondition OTOH refers to the function arguments. A violation of that
doesn't *directly* correspond to corrupted state as in the case of
invariants and postconditions. When you detect that, you are preventing the
state corruption for ever ocurring.

I said that assert() should throw and not abort because assert is used to
check for preconditions.

If it where used to check for invariants or postconditions, I would
recommend abort instead as the default behavior because structuring an
application such that it can recover from state already corrupted doesn't
come out of the box. It's entirely possible (and I often do that), but only
then you can throw on violations of invariants and postcnditions.

What I just said implies that if we go for a full DbC approach, I will
argue that the response to a procondition violation should be different
than the response to an invariant/postcondition violation (for the reasons
stated above)

Best


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--047d7b344168452d2c04db436fcb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div>Allow me to add somethi=
ng,<br><br></div>There is a significant difference between preconditions, i=
nvariants and postconditions.<br><br></div>Invariants and postconditions re=
fer to the state of the program, so a violation of these correspond to corr=
upted state. When you detect that, you are directly detecting the state cor=
ruption that has already happened.<br>

<br></div>A precondition OTOH refers to the function arguments. A violation=
 of that doesn&#39;t *directly* correspond to corrupted state as in the cas=
e of invariants and postconditions. When you detect that, you are preventin=
g the state corruption for ever ocurring.<br>

<br></div>I said that assert() should throw and not abort because assert is=
 used to check for preconditions.<br><br></div>If it where used to check fo=
r invariants or postconditions, I would recommend abort instead as the defa=
ult behavior because structuring an application such that it can recover fr=
om state already corrupted doesn&#39;t come out of the box. It&#39;s entire=
ly possible (and I often do that), but only then you can throw on violation=
s of invariants and postcnditions.<br>

<br></div>What I just said implies that if we go for a full DbC approach, I=
 will argue that the response to a procondition violation should be differe=
nt than the response to an invariant/postcondition violation (for the reaso=
ns stated above)<br>

<br></div>Best<br><div class=3D"gmail_extra"><br clear=3D"all"><br>-- <br>F=
ernando Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.sc=
isoft-consulting.com">http://www.scisoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b344168452d2c04db436fcb--

.

On Fri, Apr 26, 2013 at 3:22 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> I said that assert() should throw and not abort because assert is used to
> check for preconditions.

Isn't assert() also used for invariants, postconditions and other things?



--
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/?hl=en.



.

--047d7b3a897a130fa804db43cd44
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 26, 2013 at 10:36 AM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Fri, Apr 26, 2013 at 3:22 PM, Fernando Cacciola
> <fernando.cacciola@gmail.com> wrote:
> > I said that assert() should throw and not abort because assert is used to
> > check for preconditions.
>
> Isn't assert() also used for invariants, postconditions and other things?
>
>
Well, I'd say that it isn't, but well, I guess people can use it for that
as well I guess.

So I'd say the conclusion is this:

We need an utility to check for those 3 explicitely (and not one for all),
in both debug and release separatedly. All of them need to allow the users
to define the behavior but I think the default for preconditions should be
to throw and the default for invariants/postconditions should be to call
std::terminate().

And I like Andrzej idea of making into into Core so that compilers can take
advantage of it.

Best



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--047d7b3a897a130fa804db43cd44
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Apr 26, 2013 at 10:36 AM, Olaf van der Spek <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</=
a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Fri, Apr 26, 2013 at 3:=
22 PM, Fernando Cacciola<br>
&lt;<a href=3D"mailto:fernando.cacciola@gmail.com">fernando.cacciola@gmail.=
com</a>&gt; wrote:<br>
&gt; I said that assert() should throw and not abort because assert is used=
 to<br>
&gt; check for preconditions.<br>
<br>
</div>Isn&#39;t assert() also used for invariants, postconditions and other=
 things?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>Well, I&#39;d say that it isn&#39;t, but well, I gue=
ss people can use it for that as well I guess.<br><br></div><div>So I&#39;d=
 say the conclusion is this:<br>

<br></div><div>We need an utility to check for those 3 explicitely (and not=
 one for all), in both debug and release separatedly. All of them need to a=
llow the users to define the behavior but I think the default for precondit=
ions should be to throw and the default for invariants/postconditions shoul=
d be to call std::terminate().<br>

<br></div><div>And I like Andrzej idea of making into into Core so that com=
pilers can take advantage of it.<br><br></div><div>Best<br><br></div><div><=
br></div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<=
br>

<a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting=
..com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b3a897a130fa804db43cd44--

.

--047d7b3a897a86f21304db43d7b7
Content-Type: text/plain; charset=ISO-8859-1

Adding to my conclusion:

The std libray should explicitely use debug preconditions, which would have
a perfectly defined behavior in case of violation unless NDEBUG is defined,
in which case it defaults to the current UB


On Fri, Apr 26, 2013 at 10:48 AM, Fernando Cacciola <
fernando.cacciola@gmail.com> wrote:

> On Fri, Apr 26, 2013 at 10:36 AM, Olaf van der Spek <olafvdspek@gmail.com>wrote:
>
>> On Fri, Apr 26, 2013 at 3:22 PM, Fernando Cacciola
>> <fernando.cacciola@gmail.com> wrote:
>> > I said that assert() should throw and not abort because assert is used
>> to
>> > check for preconditions.
>>
>> Isn't assert() also used for invariants, postconditions and other things?
>>
>>
> Well, I'd say that it isn't, but well, I guess people can use it for that
> as well I guess.
>
> So I'd say the conclusion is this:
>
> We need an utility to check for those 3 explicitely (and not one for all),
> in both debug and release separatedly. All of them need to allow the users
> to define the behavior but I think the default for preconditions should be
> to throw and the default for invariants/postconditions should be to call
> std::terminate().
>
> And I like Andrzej idea of making into into Core so that compilers can
> take advantage of it.
>
> Best
>
>
>
> --
> Fernando Cacciola
> SciSoft Consulting, Founder
> http://www.scisoft-consulting.com
>



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--047d7b3a897a86f21304db43d7b7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Adding to my conclusion:<br><br></div>The std libray =
should explicitely use debug preconditions, which would have a perfectly de=
fined behavior in case of violation unless NDEBUG is defined, in which case=
 it defaults to the current UB<br>

</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri,=
 Apr 26, 2013 at 10:48 AM, Fernando Cacciola <span dir=3D"ltr">&lt;<a href=
=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacciola=
@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"im">On Fri, Apr 26, 2013 at 10:36 =
AM, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=3D"mailto:olafvdspek@gm=
ail.com" target=3D"_blank">olafvdspek@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Fri, Apr 26, 2013 at 3:22 PM, Fernan=
do Cacciola<br>
&lt;<a href=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernan=
do.cacciola@gmail.com</a>&gt; wrote:<br>
&gt; I said that assert() should throw and not abort because assert is used=
 to<br>
&gt; check for preconditions.<br>
<br>
</div>Isn&#39;t assert() also used for invariants, postconditions and other=
 things?<br>
<span><font color=3D"#888888"><br></font></span></blockquote><div><br></div=
></div><div>Well, I&#39;d say that it isn&#39;t, but well, I guess people c=
an use it for that as well I guess.<br><br></div><div>So I&#39;d say the co=
nclusion is this:<br>


<br></div><div>We need an utility to check for those 3 explicitely (and not=
 one for all), in both debug and release separatedly. All of them need to a=
llow the users to define the behavior but I think the default for precondit=
ions should be to throw and the default for invariants/postconditions shoul=
d be to call std::terminate().<br>


<br></div><div>And I like Andrzej idea of making into into Core so that com=
pilers can take advantage of it.<br><br></div><div>Best<br><br></div><div><=
br></div></div><div class=3D"im"><br>-- <br>Fernando Cacciola<br>SciSoft Co=
nsulting, Founder<br>


<a href=3D"http://www.scisoft-consulting.com" target=3D"_blank">http://www.=
scisoft-consulting.com</a>
</div></div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>Sc=
iSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">=
http://www.scisoft-consulting.com</a>
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b3a897a86f21304db43d7b7--

.

On Fri, Apr 26, 2013 at 3:48 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Fri, Apr 26, 2013 at 10:36 AM, Olaf van der Spek <olafvdspek@gmail.com>
> wrote:
>>
>> On Fri, Apr 26, 2013 at 3:22 PM, Fernando Cacciola
>> <fernando.cacciola@gmail.com> wrote:
>> > I said that assert() should throw and not abort because assert is used
>> > to
>> > check for preconditions.
>>
>> Isn't assert() also used for invariants, postconditions and other things?
>>
>
> Well, I'd say that it isn't, but well, I guess people can use it for that as
> well I guess.

Then what is currently being used for invariants, postconditions and
other things?

Switching between catchable exceptions in debug mode and UB in release
mode doesn't seem like a good idea.


--
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/?hl=en.



.

--001a11c34dcee3494904db448f5c
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 26, 2013 at 11:32 AM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Fri, Apr 26, 2013 at 3:48 PM, Fernando Cacciola
> <fernando.cacciola@gmail.com> wrote:
> > On Fri, Apr 26, 2013 at 10:36 AM, Olaf van der Spek <
> olafvdspek@gmail.com>
> > wrote:
> >>
> >> On Fri, Apr 26, 2013 at 3:22 PM, Fernando Cacciola
> >> <fernando.cacciola@gmail.com> wrote:
> >> > I said that assert() should throw and not abort because assert is used
> >> > to
> >> > check for preconditions.
> >>
> >> Isn't assert() also used for invariants, postconditions and other
> things?
> >>
> >
> > Well, I'd say that it isn't, but well, I guess people can use it for
> that as
> > well I guess.
>
> Then what is currently being used for invariants, postconditions and
> other things?
>
> IME, if a system uses invariants and postconditions it doesn't use
assert() at all. Instead it uses a cutom-made DbC framework. I've did that
several times in the distant past


> Switching between catchable exceptions in debug mode and UB in release
> mode doesn't seem like a good idea.
>
> It is a controversial idea and IME can only be justified in the special
case of C++ porogramming where peformance is (usually) fundamentally
important.

FWIW, this is exactly the effective behavior of even standard library
implementations, so it's largely common practice already.

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--001a11c34dcee3494904db448f5c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Apr 26, 2013 at 11:32 AM, Olaf van der Spek <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</=
a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Fri, Apr 26, 2013 at 3:48 PM, Fernando Ca=
cciola<br>
<div class=3D"im">&lt;<a href=3D"mailto:fernando.cacciola@gmail.com">fernan=
do.cacciola@gmail.com</a>&gt; wrote:<br>
&gt; On Fri, Apr 26, 2013 at 10:36 AM, Olaf van der Spek &lt;<a href=3D"mai=
lto:olafvdspek@gmail.com">olafvdspek@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Apr 26, 2013 at 3:22 PM, Fernando Cacciola<br>
&gt;&gt; &lt;<a href=3D"mailto:fernando.cacciola@gmail.com">fernando.caccio=
la@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; I said that assert() should throw and not abort because asser=
t is used<br>
&gt;&gt; &gt; to<br>
&gt;&gt; &gt; check for preconditions.<br>
&gt;&gt;<br>
&gt;&gt; Isn&#39;t assert() also used for invariants, postconditions and ot=
her things?<br>
&gt;&gt;<br>
&gt;<br>
&gt; Well, I&#39;d say that it isn&#39;t, but well, I guess people can use =
it for that as<br>
&gt; well I guess.<br>
<br>
</div>Then what is currently being used for invariants, postconditions and<=
br>
other things?<br>
<br></blockquote><div>IME, if a system uses invariants and postconditions i=
t doesn&#39;t use assert() at all. Instead it uses a cutom-made DbC framewo=
rk. I&#39;ve did that several times in the distant past<br>=A0<br></div>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Switching between catchable exceptions in debug mode and UB in release<br>
mode doesn&#39;t seem like a good idea.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div>I=
t is a controversial idea and IME can only be justified in the special case=
 of C++ porogramming where peformance is (usually) fundamentally important.=
<br>

<br></div><div>FWIW, this is exactly the effective behavior of even standar=
d library implementations, so it&#39;s largely common practice already.<br>=
</div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br>

<a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting=
..com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c34dcee3494904db448f5c--

.

--047d7bdc8b7263c95604db45369f
Content-Type: text/plain; charset=ISO-8859-1

On 26 April 2013 09:43, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:

> FWIW, this is exactly the effective behavior of even standard library
> implementations, so it's largely common practice already.


What standard library implementation switches between exceptions and UB?
(Bloomberg might, but is there a second one?)
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/?hl=en.



--047d7bdc8b7263c95604db45369f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On 26 April 2013 09:43, Fernando Cacciola <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:fernando.cacciola@gmail.com" target=
=3D"_blank">fernando.cacciola@gmail.com</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">

FWIW, this is exactly the effective behavior of even standard library imple=
mentations, so it&#39;s largely common practice already.</blockquote></div>=
<br>What standard library implementation switches between exceptions and UB=
?=A0 (Bloomberg might, but is there a second one?)<br>

-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847=
) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bdc8b7263c95604db45369f--

.

--089e011604e01d216d04db4a95e3
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 26, 2013 at 12:29 PM, Nevin Liber <nevin@eviloverlord.com>wrote:

>
> On 26 April 2013 09:43, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>
>> FWIW, this is exactly the effective behavior of even standard library
>> implementations, so it's largely common practice already.
>
>
> What standard library implementation switches between exceptions and UB?
> (Bloomberg might, but is there a second one?)
>
> Dinkumware (Visual C++) for example. Or the Debug Mode in STLport

But let me clarify to make sure we are in the same page: Any error checking
that an implementation adds when in a debug build, such as the STL Iterator
Debugging and the Secure SCL features of Visual C++, switchs between the
error checking and UB. In the case of Visual C++, the error checking throws.





--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--089e011604e01d216d04db4a95e3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Apr 26, 2013 at 12:29 PM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br><div class=3D"gmail_qu=
ote">On 26 April 2013 09:43, Fernando Cacciola <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacciol=
a@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

FWIW, this is exactly the effective behavior of even standard library imple=
mentations, so it&#39;s largely common practice already.</blockquote></div>=
<br></div>What standard library implementation switches between exceptions =
and UB?=A0 (Bloomberg might, but is there a second one?)<div class=3D"im">

<br></div></blockquote><div>Dinkumware (Visual C++) for example. Or the Deb=
ug Mode in STLport<br><br></div><div>But let me clarify to make sure we are=
 in the same page: Any error checking that an implementation adds when in a=
 debug build, such as the STL Iterator Debugging and the Secure SCL feature=
s of Visual C++, switchs between the error checking and UB. In the case of =
Visual C++, the error checking throws.<br>

<br></div><br></div><br><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>S=
ciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com"=
>http://www.scisoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e011604e01d216d04db4a95e3--

.

On Fri, Apr 26, 2013 at 11:54 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> Dinkumware (Visual C++) for example. Or the Debug Mode in STLport
>
> But let me clarify to make sure we are in the same page: Any error checking
> that an implementation adds when in a debug build, such as the STL Iterator
> Debugging and the Secure SCL features of Visual C++, switchs between the
> error checking and UB. In the case of Visual C++, the error checking throws.

Got a reference for that?
I don't see it throwing anywhere.

--
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/?hl=en.



.

--089e01229c3090f55d04db4c925c
Content-Type: text/plain; charset=ISO-8859-1

On 27 April 2013 00:54, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:

> On Fri, Apr 26, 2013 at 12:29 PM, Nevin Liber <nevin@eviloverlord.com>wrote:
>
>>
>> On 26 April 2013 09:43, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>>
>>> FWIW, this is exactly the effective behavior of even standard library
>>> implementations, so it's largely common practice already.
>>
>>
>> What standard library implementation switches between exceptions and UB?
>> (Bloomberg might, but is there a second one?)
>>
>> Dinkumware (Visual C++) for example. Or the Debug Mode in STLport
>
> But let me clarify to make sure we are in the same page: Any error
> checking that an implementation adds when in a debug build, such as the STL
> Iterator Debugging and the Secure SCL features of Visual C++, switchs
> between the error checking and UB. In the case of Visual C++, the error
> checking throws.
>
>
>
That's not a switch between checking and UB, the implementation can throw
under the bailiwick of UB, for
functions not marked noexcept.

Another two cents: there's a difference between how the standard library is
designed and how other
code is designed, and I think it's useful to give developers a choice on
what assertions do. However,
the choice those developers make may not be the same as the choice made by
the standard
library semantics, and I don't think we should dictate doctrine like "never
abort but throw instead"
in the library. That doctrine is wrong for some users of the library.
Undefined behaviour allows
library implementations to make that decision.

--

---
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/?hl=en.



--089e01229c3090f55d04db4c925c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 27 April 2013 00:54, Fernando Cacciola <span dir=3D"ltr">&lt;<a =
href=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacc=
iola@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"im">On Fri, Apr 26, 2013 at 12:29 =
PM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.=
com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><br><div class=3D"gmail_quote">On 26 Ap=
ril 2013 09:43, Fernando Cacciola <span dir=3D"ltr">&lt;<a href=3D"mailto:f=
ernando.cacciola@gmail.com" target=3D"_blank">fernando.cacciola@gmail.com</=
a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

FWIW, this is exactly the effective behavior of even standard library imple=
mentations, so it&#39;s largely common practice already.</blockquote></div>=
<br></div>What standard library implementation switches between exceptions =
and UB?=A0 (Bloomberg might, but is there a second one?)<div>


<br></div></blockquote></div><div>Dinkumware (Visual C++) for example. Or t=
he Debug Mode in STLport<br><br></div><div>But let me clarify to make sure =
we are in the same page: Any error checking that an implementation adds whe=
n in a debug build, such as the STL Iterator Debugging and the Secure SCL f=
eatures of Visual C++, switchs between the error checking and UB. In the ca=
se of Visual C++, the error checking throws.<br>


<br><br></div></div></div></div></blockquote><div><br></div><div>That&#39;s=
 not a switch between checking and UB, the implementation can throw under t=
he bailiwick of UB, for<br></div><div>functions not marked noexcept.<br>
<br></div><div>Another two cents: there&#39;s a difference between how the =
standard library is designed and how other<br>code is designed, and I think=
 it&#39;s useful to give developers a choice on what assertions do. However=
,<br>
</div><div>the choice those developers make may not be the same as the choi=
ce made by the standard<br>library semantics, and I don&#39;t think we shou=
ld dictate doctrine like &quot;never abort but throw instead&quot;<br></div=
>
<div>in the library. That doctrine is wrong for some users of the library. =
Undefined behaviour allows<br></div><div>library implementations to make th=
at decision.<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e01229c3090f55d04db4c925c--

.

--e89a8ff2511c1d7d5f04db4cb3ff
Content-Type: text/plain; charset=ISO-8859-1

On 27 April 2013 03:17, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:

>
> Another two cents: there's a difference between how the standard library
> is designed and how other
> code is designed, and I think it's useful to give developers a choice on
> what assertions do. However,
> the choice those developers make may not be the same as the choice made by
> the standard
> library semantics, and I don't think we should dictate doctrine like
> "never abort but throw instead"
> in the library. That doctrine is wrong for some users of the library.
> Undefined behaviour allows
> library implementations to make that decision.
>
>
And lest I forget: I expect assertions to abort by default, and provide
users the ability to make them
throw/whatever instead. I think that's the best default choice. If you want
a precondition that throws by
default, that's not an assertion.

--

---
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/?hl=en.



--e89a8ff2511c1d7d5f04db4cb3ff
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 27 April 2013 03:17, Ville Voutilainen <span dir=3D"ltr">&lt;<a =
href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutila=
inen@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div>Another two cents: there&#39;s a differ=
ence between how the standard library is designed and how other<br>
code is designed, and I think it&#39;s useful to give developers a choice o=
n what assertions do. However,<br>
</div><div>the choice those developers make may not be the same as the choi=
ce made by the standard<br>library semantics, and I don&#39;t think we shou=
ld dictate doctrine like &quot;never abort but throw instead&quot;<br>
</div>
<div>in the library. That doctrine is wrong for some users of the library. =
Undefined behaviour allows<br></div><div>library implementations to make th=
at decision.<br></div></div><br></div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">And lest I forget: =
I expect assertions to abort by default, and provide users the ability to m=
ake them<br>throw/whatever instead. I think that&#39;s the best default cho=
ice. If you want a precondition that throws by<br>
default, that&#39;s not an assertion.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--e89a8ff2511c1d7d5f04db4cb3ff--

.

------=_Part_2191_17417116.1367065282759
Content-Type: text/plain; charset=ISO-8859-1



> And lest I forget: I expect assertions to abort by default, and provide
> users the ability to make them
> throw/whatever instead. I think that's the best default choice. If you
> want a precondition that throws by
> default, that's not an assertion.
>

'Abort' in what sense? "Not throw" or call std::abort? My experience is
that it is preferable to call std::terminate instead of std::abort in
home-made assertions. The former gives the program the chance to clear some
system-critical resources and schedule a program restart, and offers a
considerable safety (compared to exceptions).

--

---
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/?hl=en.



------=_Part_2191_17417116.1367065282759
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<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>And =
lest I forget: I expect assertions to abort by default, and provide users t=
he ability to make them<br>throw/whatever instead. I think that's the best =
default choice. If you want a precondition that throws by<br>
default, that's not an assertion.<br></div></div></blockquote><div><br>'Abo=
rt' in what sense? "Not throw" or call std::abort? My experience is that it=
 is preferable to call std::terminate instead of std::abort in home-made as=
sertions. The former gives the program the chance to clear some system-crit=
ical resources and schedule a program restart, and offers a considerable sa=
fety (compared to exceptions). <br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2191_17417116.1367065282759--

.

On Sat, Apr 27, 2013 at 2:21 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>
>> And lest I forget: I expect assertions to abort by default, and provide
>> users the ability to make them
>> throw/whatever instead. I think that's the best default choice. If you
>> want a precondition that throws by
>> default, that's not an assertion.
>
>
> 'Abort' in what sense? "Not throw" or call std::abort? My experience is t=
hat
> it is preferable to call std::terminate instead of std::abort in home-mad=
e
> assertions. The former gives the program the chance to clear some
> system-critical resources and schedule a program restart, and offers a
> considerable safety (compared to exceptions).

Isn't all that better done by the operating system (or a process monitor)?
What system-critical resources are you referring to?

--=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/?hl=3Den.



.

--Apple-Mail=_EEBB3918-4138-4A28-ABB1-92E2C7E801C5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1

On Apr 26, 2013, at 12:48 AM, Nevin Liber <nevin@eviloverlord.com> wrote:

> The purpose of asserts is not to aid debugging but to increase program ro=
bustness.
>=20
> Well, it's both; otherwise, there is no reason to even print a message wh=
en you assert.

IM(NS)HO, the purpose of asserts is to increase a programmer's understandin=
g of a program, by saying:
 You're doing it wrong - right here!

Whether the mistake is due to carelessness, misunderstanding, poor document=
ation, etc is irrelevant.

As for effects, I agree with Nevin - an assertion failure puts your program=
 into an undefined state; something the designer of the program/library did=
 not anticipate, and did not provide for. The safest solution is to call st=
d::terminate. However, as a library designer, I am loathe to require that o=
f the users of my library, because they _may_ have special requirements (th=
ings that have to be shut down carefully, etc). I think some way of customi=
zing the "termination policy" is in order, but that the default should be s=
td::terminate.

[ I ran into this several years ago with a crypto library. Deep in the bowe=
ls of the library, it called an entropy source to get some random bits. If =
the entropy source could not provide any bits, it called std::abort.  Imagi=
ne trying to build a reliable system around that! ]

-- Marshall

Marshall Clow     Idio Software   <mailto:mclow.lists@gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is prom=
ptly moderated down to (-1, Flamebait).
        -- Yu Suzuki

--=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/?hl=3Den.



--Apple-Mail=_EEBB3918-4138-4A28-ABB1-92E2C7E801C5
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=
=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mo=
de: space; -webkit-line-break: after-white-space; "><div><div>On Apr 26, 20=
13, at 12:48 AM, Nevin Liber &lt;<a href=3D"mailto:nevin@eviloverlord.com">=
nevin@eviloverlord.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-n=
ewline"><blockquote type=3D"cite"><blockquote class=3D"gmail_quote" style=
=3D"font-family: 'Lucida Grande'; font-size: medium; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh=
t: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-tra=
nsform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-te=
xt-size-adjust: auto; -webkit-text-stroke-width: 0px; margin: 0px 0px 0px 0=
..8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border=
-left-style: solid; padding-left: 1ex; "><div dir=3D"ltr"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote">The purpose of asserts is not to aid d=
ebugging but to increase program robustness.</div></div></div></blockquote>=
<div style=3D"font-family: 'Lucida Grande'; font-size: medium; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px=
; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><br></div=
><div style=3D"font-family: 'Lucida Grande'; font-size: medium; font-style:=
 normal; font-variant: normal; font-weight: normal; letter-spacing: normal;=
 line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;=
 -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">Well, it=
's both; otherwise, there is no reason to even print a message when you ass=
ert.</div></blockquote><br></div><div>IM(NS)HO, the purpose of asserts is t=
o increase a programmer's understanding of a program, by saying:</div><div>=
<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>You're doi=
ng it wrong - right here!</div><div><br></div><div>Whether the mistake is d=
ue to carelessness, misunderstanding, poor documentation, etc is irrelevant=
..</div><div><br></div><div>As for effects, I agree with Nevin - an assertio=
n failure puts your program into an undefined state; something the designer=
 of the program/library did not anticipate, and did not provide for. The sa=
fest solution is to call std::terminate. However, as a library designer, I =
am loathe to require that of the users of my library, because they _may_ ha=
ve special requirements (things that have to be shut down carefully, etc). =
I think some way of customizing the "termination policy" is in order, but t=
hat the default should be std::terminate.</div><div><br></div><div>[ I ran =
into this several years ago with a crypto library. Deep in the bowels of th=
e library, it called an entropy source to get some random bits. If the entr=
opy source could not provide any bits, it called std::abort. &nbsp;Imagine =
trying to build a reliable system around that! ]</div><div><br></div><div a=
pple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; color:=
 rgb(0, 0, 0); font-family: 'Lucida Grande'; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; wh=
ite-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-=
spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decoration=
s-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-widt=
h: 0px; font-size: medium; ">-- Marshall<br><br>Marshall Clow &nbsp; &nbsp;=
 Idio Software &nbsp; &lt;<a href=3D"mailto:mclow.lists@gmail.com">mailto:m=
clow.lists@gmail.com</a>&gt;<br><br>A.D. 1517: Martin Luther nails his 95 T=
heses to the church door and is promptly moderated down to (-1, Flamebait).=
<br>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;-- Yu Suzuki</span>

</div>
<br></body></html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--Apple-Mail=_EEBB3918-4138-4A28-ABB1-92E2C7E801C5--

.

--047d7b33d31ccad6c004db598dc2
Content-Type: text/plain; charset=ISO-8859-1

On 27 April 2013 18:23, Marshall Clow <mclow.lists@gmail.com> wrote:

> [ I ran into this several years ago with a crypto library. Deep in the
> bowels of the library, it called an entropy source to get some random bits.
> If the entropy source could not provide any bits, it called std::abort.
>  Imagine trying to build a reliable system around that! ]
>
>
>
Here's another war story: I once saw a multimedia driver abort, seven
layers below any code that could reasonably
decide how to cope with the error. People then asked "if the video playback
is in an undefined state, what's the point
of not aborting?", and my response was "I find it a tad unreasonable to
abort a gallery application just because
it can't play videos, since it could still display my photos, which I have
rather more than videos".

Moral of the story: asserts are useful debugging aids when you're in a
development stage. There are, however,
applications that should do their best to avoid aborting. Hence, it's
useful to allow customizing the behaviour
of asserts. The "must abort if an assertion fails" is a doctrine that not
everyone can follow, and it's not suitable
for all applications. That doesn't mean that assertions shouldn't abort by
default (std::terminate, std::abort, take
your pick, the former calls the latter anyway), and people shouldn't
replace actual error recovery strategies
with throwing assertions.

--

---
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/?hl=en.



--047d7b33d31ccad6c004db598dc2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 27 April 2013 18:23, Marshall Clow <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mclow.lists@gmail.com" target=3D"_blank">mclow.lists@gmail.com</=
a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word">[ I ran =
into this several years ago with a crypto library. Deep in the bowels of th=
e library, it called an entropy source to get some random bits. If the entr=
opy source could not provide any bits, it called std::abort. =A0Imagine try=
ing to build a reliable system around that! ]<div>
<br><br></div></div></blockquote><div><br></div><div>Here&#39;s another war=
 story: I once saw a multimedia driver abort, seven layers below any code t=
hat could reasonably<br></div><div>decide how to cope with the error. Peopl=
e then asked &quot;if the video playback is in an undefined state, what&#39=
;s the point<br>
of not aborting?&quot;, and my response was &quot;I find it a tad unreasona=
ble to abort a gallery application just because<br>it can&#39;t play videos=
, since it could still display my photos, which I have rather more than vid=
eos&quot;.<br>
<br></div><div>Moral of the story: asserts are useful debugging aids when y=
ou&#39;re in a development stage. There are, however,<br>applications that =
should do their best to avoid aborting. Hence, it&#39;s useful to allow cus=
tomizing the behaviour<br>
of asserts. The &quot;must abort if an assertion fails&quot; is a doctrine =
that not everyone can follow, and it&#39;s not suitable<br>for all applicat=
ions. That doesn&#39;t mean that assertions shouldn&#39;t abort by default =
(std::terminate, std::abort, take<br>
your pick, the former calls the latter anyway), and people shouldn&#39;t re=
place actual error recovery strategies<br></div><div>with throwing assertio=
ns.<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b33d31ccad6c004db598dc2--

.

--089e012292fa949e9804db5b2bd2
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 26, 2013 at 9:17 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 27 April 2013 00:54, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>
>> On Fri, Apr 26, 2013 at 12:29 PM, Nevin Liber <nevin@eviloverlord.com>wrote:
>>
>>>
>>> On 26 April 2013 09:43, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>>>
>>>> FWIW, this is exactly the effective behavior of even standard library
>>>> implementations, so it's largely common practice already.
>>>
>>>
>>> What standard library implementation switches between exceptions and
>>> UB?  (Bloomberg might, but is there a second one?)
>>>
>>> Dinkumware (Visual C++) for example. Or the Debug Mode in STLport
>>
>> But let me clarify to make sure we are in the same page: Any error
>> checking that an implementation adds when in a debug build, such as the STL
>> Iterator Debugging and the Secure SCL features of Visual C++, switchs
>> between the error checking and UB. In the case of Visual C++, the error
>> checking throws.
>>
>>
>>
> That's not a switch between checking and UB, the implementation can throw
> under the bailiwick of UB, for
> functions not marked noexcept.
>
> IIUC what you are saying, I agree. But let me make sure:

You are saying that UB implies that in a given actual implementation, some
behavior might be well defined. In that sense, you never switch between the
defined behavior and UB, more like you turn UB into "DB". Is that it ?

In any case, the intention was to state that you either "get UB as it is
(not) defined" when building release, or get some behavior defined by the
implementation when you build debug. Olaf mentioned that this was a bad
idea. I think it's controversial but not neccesary bad, and it's common
practice

I was wrong though and VC doesn't just throw but put you through a
user-configurable path that includes UI to retrieve end-user preference
about the course to take next. Still, that's defined behaviour you get only
in debug, which was the point I was making.


> Another two cents: there's a difference between how the standard library
> is designed and how other
> code is designed, and I think it's useful to give developers a choice on
> what assertions do.
>

Absolutely.


>  However,
> the choice those developers make may not be the same as the choice made by
> the standard
> library semantics
>

I almost agree. I consider this myself as well but concluded that a lot, if
not most, of typical C++ code is layer after layer of "library" code, so
drawing a line between "standard library" and "application" seems to me
unrealistic.

Thus, now I think it's better that the same choice is consistent all across
the entire program.



> , and I don't think we should dictate doctrine like "never abort but throw
> instead"
> in the library. That doctrine is wrong for some users of the library.
>

I do present it as a doctrine but I should have clarified much more the
context, so let me try agan:

If there is going to be a fixed, non-customizable behavior, AND, provided
that assertions are also used in release builds, it should never abort but
throw instead (for the simple reason that with a throw you allow the
programmer to do something about it)

OTOH, if the behavior is user-defined, then which is the best default is
much more subtle and I would not have a really strong opinion either way.
Likewise, if asserts are never ever in a release build, then abort() might
even be better.

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--089e012292fa949e9804db5b2bd2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Apr 26, 2013 at 9:17 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div><div class=3D"h5">On 27 April 2=
013 00:54, Fernando Cacciola <span dir=3D"ltr">&lt;<a href=3D"mailto:fernan=
do.cacciola@gmail.com" target=3D"_blank">fernando.cacciola@gmail.com</a>&gt=
;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>On Fri, Apr 26, 2013 at 12:29 PM, Nevin Lib=
er <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br>




<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><br><div class=3D"gmail_quote">On 26 Ap=
ril 2013 09:43, Fernando Cacciola <span dir=3D"ltr">&lt;<a href=3D"mailto:f=
ernando.cacciola@gmail.com" target=3D"_blank">fernando.cacciola@gmail.com</=
a>&gt;</span> wrote:<br>




<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

FWIW, this is exactly the effective behavior of even standard library imple=
mentations, so it&#39;s largely common practice already.</blockquote></div>=
<br></div>What standard library implementation switches between exceptions =
and UB?=A0 (Bloomberg might, but is there a second one?)<div>




<br></div></blockquote></div><div>Dinkumware (Visual C++) for example. Or t=
he Debug Mode in STLport<br><br></div><div>But let me clarify to make sure =
we are in the same page: Any error checking that an implementation adds whe=
n in a debug build, such as the STL Iterator Debugging and the Secure SCL f=
eatures of Visual C++, switchs between the error checking and UB. In the ca=
se of Visual C++, the error checking throws.<br>




<br><br></div></div></div></div></blockquote><div><br></div></div></div><di=
v>That&#39;s not a switch between checking and UB, the implementation can t=
hrow under the bailiwick of UB, for<br></div><div>functions not marked noex=
cept.<br>


<br></div></div></div></div></blockquote><div>IIUC what you are saying, I a=
gree. But let me make sure:<br><br></div><div>You are saying that UB implie=
s that in a given actual implementation, some behavior might be well define=
d. In that sense, you never switch between the defined behavior and UB, mor=
e like you turn UB into &quot;DB&quot;. Is that it ?<br>

<br></div><div>In any case, the intention was to state that you either &quo=
t;get UB as it is (not) defined&quot; when building release, or get some be=
havior defined by the implementation when you build debug. Olaf mentioned t=
hat this was a bad idea. I think it&#39;s controversial but not neccesary b=
ad, and it&#39;s common practice<br>

<br>I was wrong though and VC doesn&#39;t just throw but put you through a =
user-configurable path that includes UI to retrieve end-user preference abo=
ut the course to take next. Still, that&#39;s defined behaviour you get onl=
y in debug, which was the point I was making.<br>

</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div>Another two =
cents: there&#39;s a difference between how the standard library is designe=
d and how other<br>

code is designed, and I think it&#39;s useful to give developers a choice o=
n what assertions do.</div></div></div></div></blockquote><div><br></div><d=
iv>Absolutely.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
> However,<br>
</div><div>the choice those developers make may not be the same as the choi=
ce made by the standard<br>library semantics</div></div></div></div></block=
quote><div><br></div><div>I almost agree. I consider this myself as well bu=
t concluded that a lot, if not most, of typical C++ code is layer after lay=
er of &quot;library&quot; code, so drawing a line between &quot;standard li=
brary&quot; and &quot;application&quot; seems to me unrealistic. <br>

</div><div><br></div><div>Thus, now I think it&#39;s better that the same c=
hoice is consistent all across the entire program.<br></div><div><br>=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>, and I don&#39;t think we should dictate doctrine like &quot;never abort =
but throw instead&quot;<br></div>
<div>in the library. That doctrine is wrong for some users of the library. =
</div></div></div></div></blockquote><div><br></div><div>I do present it as=
 a doctrine but I should have clarified much more the context, so let me tr=
y agan:<br>

<br></div><div>If there is going to be a fixed, non-customizable behavior, =
AND, provided that assertions are also used in release builds, it should ne=
ver abort but throw instead (for the simple reason that with a throw you al=
low the programmer to do something about it)<br>

<br></div><div>OTOH, if the behavior is user-defined, then which is the bes=
t default is much more subtle and I would not have a really strong opinion =
either way.<br></div><div>Likewise, if asserts are never ever in a release =
build, then abort() might even be better.<br>

</div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br>=
<a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting=
..com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e012292fa949e9804db5b2bd2--

.

--089e011604e0302a0904db5b41a2
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 26, 2013 at 9:26 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:


>  If you want a precondition that throws by
> default, that's not an assertion.
>

Why wouldn't it be an assertion?  What is an assertion other than a
precondition check? If you refer to the specific name "assert" then well,
consider that everything I said refered to "a macro a checks
preconditions", whether you cann it assert, ensure, verify, etc...

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--089e011604e0302a0904db5b41a2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Apr 26, 2013 at 9:26 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra">=A0If you want a precondition that throws by<br>
default, that&#39;s not an assertion.<br></div></div></blockquote><div><br>=
</div><div>Why wouldn&#39;t it be an assertion?=A0 What is an assertion oth=
er than a precondition check? If you refer to the specific name &quot;asser=
t&quot; then well, consider that everything I said refered to &quot;a macro=
 a checks preconditions&quot;, whether you cann it assert, ensure, verify, =
etc...<br>

<br></div></div>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br>=
<a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting=
..com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e011604e0302a0904db5b41a2--

.

--001a11c34dce2a682204db5b6acd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 27, 2013 at 9:21 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om>wrote:

>
> And lest I forget: I expect assertions to abort by default, and provide
>> users the ability to make them
>> throw/whatever instead. I think that's the best default choice. If you
>> want a precondition that throws by
>> default, that's not an assertion.
>>
>
> 'Abort' in what sense? "Not throw" or call std::abort? My experience is
> that it is preferable to call std::terminate instead of std::abort in
> home-made assertions.
>

Agreed (and I would bet he meant "abort the application" rather than one
specific way to do it).


>  The former gives the program the chance to clear some system-critical
> resources and schedule a program restart, and offers a considerable safet=
y
> (compared to exceptions).
>

Let me add another ball to the discussion. The reason prople prefer
something like termiante to a throw, even in release, is what you just
said, safety (it is technically true that the program might go astray as it
winds up, even though I almost never experienced it in practice), so I've
consider that what we need is a new thing which is neither terminate nor
throw. Sort of like the longjump of old C days. The part of the exception
mechanism where we resume flow at the catch is what I want in the case of a
condition violation, because that allows the application to keep running.
The unwinding of the stack is what gets in the way. With such a tool, I can
strucutre the applciation in a way such that the any state corruption
ocurring in one branch does not affect any other branch. That is, I can
program a safe rescue point. I prefer a throw in the current C++ because it
allows me to get closer to that, while terminate leave me (and the end
user) hanging.

Best

--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=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/?hl=3Den.



--001a11c34dce2a682204db5b6acd
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Apr 27, 2013 at 9:21 AM, Andrzej Krzemie=F1ski <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a=
>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">

<div dir=3D"ltr"><div>And lest I forget: I expect assertions to abort by de=
fault, and provide users the ability to make them<br>throw/whatever instead=
.. I think that&#39;s the best default choice. If you want a precondition th=
at throws by<br>


default, that&#39;s not an assertion.<br></div></div></blockquote></div><di=
v><br>&#39;Abort&#39; in what sense? &quot;Not throw&quot; or call std::abo=
rt? My experience is that it is preferable to call std::terminate instead o=
f std::abort in home-made assertions.</div>

</blockquote><div><br></div><div>Agreed (and I would bet he meant &quot;abo=
rt the application&quot; rather than one specific way to do it).<br></div><=
div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">

<div> The former gives the program the chance to clear some system-critical=
 resources and schedule a program restart, and offers a considerable safety=
 (compared to exceptions). <br></div></blockquote><div><br></div><div>
Let me add another ball to the discussion. The reason prople prefer somethi=
ng like termiante to a throw, even in release, is what you just said, safet=
y (it is technically true that the program might go astray as it winds up, =
even though I almost never experienced it in practice), so I&#39;ve conside=
r that what we need is a new thing which is neither terminate nor throw. So=
rt of like the longjump of old C days. The part of the exception mechanism =
where we resume flow at the catch is what I want in the case of a condition=
 violation, because that allows the application to keep running. The unwind=
ing of the stack is what gets in the way. With such a tool, I can strucutre=
 the applciation in a way such that the any state corruption ocurring in on=
e branch does not affect any other branch. That is, I can program a safe re=
scue point. I prefer a throw in the current C++ because it allows me to get=
 closer to that, while terminate leave me (and the end user) hanging.<br>

</div><div></div></div><br></div><div class=3D"gmail_extra">Best<br><br></d=
iv><div class=3D"gmail_extra">-- <br>Fernando Cacciola<br>SciSoft Consultin=
g, Founder<br><a href=3D"http://www.scisoft-consulting.com">http://www.scis=
oft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c34dce2a682204db5b6acd--

.

On Sat, Apr 27, 2013 at 7:41 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> In any case, the intention was to state that you either "get UB as it is
> (not) defined" when building release, or get some behavior defined by the
> implementation when you build debug. Olaf mentioned that this was a bad
> idea. I think it's controversial but not neccesary bad, and it's common
> practice

The VC behaviour is fine, throwing a catchable exception (only in
debug mode) isn't.

> If there is going to be a fixed, non-customizable behavior, AND, provided
> that assertions are also used in release builds, it should never abort but
> throw instead (for the simple reason that with a throw you allow the
> programmer to do something about it)

Maybe some examples would help, I have no idea what you can do at
run-time about it.

--

---
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/?hl=en.



.

------=_Part_2339_892298.1367089782909
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu sobota, 27 kwietnia 2013 14:45:34 UTC+2 u=BFytkownik Olaf van der Sp=
ek=20
napisa=B3:
>
> On Sat, Apr 27, 2013 at 2:21 PM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:=20
> >=20
> >> And lest I forget: I expect assertions to abort by default, and provid=
e=20
> >> users the ability to make them=20
> >> throw/whatever instead. I think that's the best default choice. If you=
=20
> >> want a precondition that throws by=20
> >> default, that's not an assertion.=20
> >=20
> >=20
> > 'Abort' in what sense? "Not throw" or call std::abort? My experience is=
=20
> that=20
> > it is preferable to call std::terminate instead of std::abort in=20
> home-made=20
> > assertions. The former gives the program the chance to clear some=20
> > system-critical resources and schedule a program restart, and offers a=
=20
> > considerable safety (compared to exceptions).=20
>
> Isn't all that better done by the operating system (or a process monitor)=
?=20
> What system-critical resources are you referring to?=20
>

In some cases that would be true. I  believe that on Windows when you=20
needed to use the global clipboard, you have to manually lock it and then=
=20
manually unlock it: otherwise it will not be released -- I am not sure=20
about this one though. But note that C++ can be used to write the operating=
=20
system (this is what the Standard calls the free-standing implementation,=
=20
right?). In that case you cannot rely on the OS yet.

Regards,
&rzej=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/?hl=3Den.



------=_Part_2339_892298.1367089782909
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu sobota, 27 kwietnia 2013 14:45:34 UTC+2 u=BFytkownik Olaf va=
n der Spek napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sat, A=
pr 27, 2013 at 2:21 PM, Andrzej Krzemie=F1ski &lt;<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"E4_vhXty0JgJ">akrz...@gmail.com</=
a>&gt; wrote:
<br>&gt;
<br>&gt;&gt; And lest I forget: I expect assertions to abort by default, an=
d provide
<br>&gt;&gt; users the ability to make them
<br>&gt;&gt; throw/whatever instead. I think that's the best default choice=
.. If you
<br>&gt;&gt; want a precondition that throws by
<br>&gt;&gt; default, that's not an assertion.
<br>&gt;
<br>&gt;
<br>&gt; 'Abort' in what sense? "Not throw" or call std::abort? My experien=
ce is that
<br>&gt; it is preferable to call std::terminate instead of std::abort in h=
ome-made
<br>&gt; assertions. The former gives the program the chance to clear some
<br>&gt; system-critical resources and schedule a program restart, and offe=
rs a
<br>&gt; considerable safety (compared to exceptions).
<br>
<br>Isn't all that better done by the operating system (or a process monito=
r)?
<br>What system-critical resources are you referring to?
<br></blockquote><div><br>In some cases that would be true. I&nbsp; believe=
 that on Windows when you needed to use the global clipboard, you have to m=
anually lock it and then manually unlock it: otherwise it will not be relea=
sed -- I am not sure about this one though. But note that C++ can be used t=
o write the operating system (this is what the Standard calls the free-stan=
ding implementation, right?). In that case you cannot rely on the OS yet.<b=
r><br>Regards,<br>&amp;rzej <br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2339_892298.1367089782909--

.

------=_Part_2403_12526643.1367090091286
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu sobota, 27 kwietnia 2013 19:58:56 UTC+2 u=BFytkownik Fernando Caccio=
la=20
napisa=B3:
>
> On Sat, Apr 27, 2013 at 9:21 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>
> > wrote:
>
>>
>> And lest I forget: I expect assertions to abort by default, and provide=
=20
>>> users the ability to make them
>>> throw/whatever instead. I think that's the best default choice. If you=
=20
>>> want a precondition that throws by
>>> default, that's not an assertion.
>>>
>>
>> 'Abort' in what sense? "Not throw" or call std::abort? My experience is=
=20
>> that it is preferable to call std::terminate instead of std::abort in=20
>> home-made assertions.
>>
>
> Agreed (and I would bet he meant "abort the application" rather than one=
=20
> specific way to do it).
> =20
>
>>  The former gives the program the chance to clear some system-critical=
=20
>> resources and schedule a program restart, and offers a considerable safe=
ty=20
>> (compared to exceptions).=20
>>
>
> Let me add another ball to the discussion. The reason prople prefer=20
> something like termiante to a throw, even in release, is what you just=20
> said, safety (it is technically true that the program might go astray as =
it=20
> winds up, even though I almost never experienced it in practice), so I've=
=20
> consider that what we need is a new thing which is neither terminate nor=
=20
> throw. Sort of like the longjump of old C days. The part of the exception=
=20
> mechanism where we resume flow at the catch is what I want in the case of=
 a=20
> condition violation, because that allows the application to keep running.=
=20
> The unwinding of the stack is what gets in the way. With such a tool, I c=
an=20
> strucutre the applciation in a way such that the any state corruption=20
> ocurring in one branch does not affect any other branch. That is, I can=
=20
> program a safe rescue point. I prefer a throw in the current C++ because =
it=20
> allows me to get closer to that, while terminate leave me (and the end=20
> user) hanging.
>

Another approach at providing the "keep running" guarantee is to didide=20
your program into a number of separate processess (which do not share=20
memory among themselves) and terminate each corrupt process separately. The=
=20
master process can detect the termination of the child and restart it. This=
=20
way you provide the impression that your program never terminates.

Regards,
&rzej=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/?hl=3Den.



------=_Part_2403_12526643.1367090091286
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu sobota, 27 kwietnia 2013 19:58:56 UTC+2 u=BFytkownik Fernand=
o Cacciola napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Sat, Apr 27, 2013 at 9:21 AM, A=
ndrzej Krzemie=F1ski <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"QNURZdq58YEJ">akrz...@gmail.com</a>&gt=
;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">

<div dir=3D"ltr"><div>And lest I forget: I expect assertions to abort by de=
fault, and provide users the ability to make them<br>throw/whatever instead=
.. I think that's the best default choice. If you want a precondition that t=
hrows by<br>


default, that's not an assertion.<br></div></div></blockquote></div><div><b=
r>'Abort' in what sense? "Not throw" or call std::abort? My experience is t=
hat it is preferable to call std::terminate instead of std::abort in home-m=
ade assertions.</div>

</blockquote><div><br></div><div>Agreed (and I would bet he meant "abort th=
e application" rather than one specific way to do it).<br></div><div>&nbsp;=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">

<div> The former gives the program the chance to clear some system-critical=
 resources and schedule a program restart, and offers a considerable safety=
 (compared to exceptions). <br></div></blockquote><div><br></div><div>
Let me add another ball to the discussion. The reason prople prefer somethi=
ng like termiante to a throw, even in release, is what you just said, safet=
y (it is technically true that the program might go astray as it winds up, =
even though I almost never experienced it in practice), so I've consider th=
at what we need is a new thing which is neither terminate nor throw. Sort o=
f like the longjump of old C days. The part of the exception mechanism wher=
e we resume flow at the catch is what I want in the case of a condition vio=
lation, because that allows the application to keep running. The unwinding =
of the stack is what gets in the way. With such a tool, I can strucutre the=
 applciation in a way such that the any state corruption ocurring in one br=
anch does not affect any other branch. That is, I can program a safe rescue=
 point. I prefer a throw in the current C++ because it allows me to get clo=
ser to that, while terminate leave me (and the end user) hanging.<br>

</div></div></div></div></blockquote><div><br>Another approach at providing=
 the "keep running" guarantee is to didide your program into a number of se=
parate processess (which do not share memory among themselves) and terminat=
e each corrupt process separately. The master process can detect the termin=
ation of the child and restart it. This way you provide the impression that=
 your program never terminates.<br><br>Regards,<br>&amp;rzej <br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2403_12526643.1367090091286--

.

--089e012292fabf291904db60d15d
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Apr 27, 2013 at 3:15 PM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Sat, Apr 27, 2013 at 7:41 PM, Fernando Cacciola
> <fernando.cacciola@gmail.com> wrote:
> > In any case, the intention was to state that you either "get UB as it is
> > (not) defined" when building release, or get some behavior defined by the
> > implementation when you build debug. Olaf mentioned that this was a bad
> > idea. I think it's controversial but not neccesary bad, and it's common
> > practice
>
> The VC behaviour is fine, throwing a catchable exception (only in
> debug mode) isn't.
>
> > If there is going to be a fixed, non-customizable behavior, AND, provided
> > that assertions are also used in release builds, it should never abort
> but
> > throw instead (for the simple reason that with a throw you allow the
> > programmer to do something about it)
>
> Maybe some examples would help, I have no idea what you can do at
> run-time about it.
>
> Well, the simplest way to give you an example is to ask you to consider
other languages.
(AFAICT) C and by inhetritance, C++, are the only languages which abort in
case of a precondition violation.
Modern languages such as (just to name a few) C#, Java, Ruby/Python and
JavaScript all throw on errors, any kind of errors including programming
errors. None of them abort.

The state corruption that is always put as the reason for aborting ocurrs
in any program that runs into an error no matter what language it is in. I
do and had been doing for a long time work in factories where C++ is just a
piece of the puzzle, and IME I've never ever once see a program run into a
problem *because* the response to an error was to throw, not even a
programmers error. So this theoretically correct fear that the program
won't got back to a stable state if you throw instead of a abort is
something that I never ever experienced not even once in a real program
constructed with the least of the cares (meaning, without throwing in
destructors)

Consider that in dynamic languages like, say Ruby or JavaScript, even a
"syntax error" (which can't be detected until you try to run it), throws an
exception, so there is quite a lot of that.

You could argue that there is key difference between C++ and all those
other languages: in C++, we unwind the stack calling destructors all the
way up. That makes it a harzard, I take that. Now, do any of you had the
actual experience of throwing in asserts and running into trouble because
of that, so much that abort would have been better? Alll this time the only
practical and realisitc reason I've heard that it meses up with diagnosing
the error because you don't get a nice dump, but that's in the past for
most modern IDEs AFAICT.

I insist that the "abort doctrine" as I call it is just an accident of
inheriting assert() from a language, C, that just can't do anything else
because it has no exceptions.

Best




--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--089e012292fabf291904db60d15d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Apr 27, 2013 at 3:15 PM, Olaf van der Spek <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a=
>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im">On Sat,=
 Apr 27, 2013 at 7:41 PM, Fernando Cacciola<br>
&lt;<a href=3D"mailto:fernando.cacciola@gmail.com">fernando.cacciola@gmail.=
com</a>&gt; wrote:<br>
&gt; In any case, the intention was to state that you either &quot;get UB a=
s it is<br>
&gt; (not) defined&quot; when building release, or get some behavior define=
d by the<br>
&gt; implementation when you build debug. Olaf mentioned that this was a ba=
d<br>
&gt; idea. I think it&#39;s controversial but not neccesary bad, and it&#39=
;s common<br>
&gt; practice<br>
<br>
</div>The VC behaviour is fine, throwing a catchable exception (only in<br>
debug mode) isn&#39;t.<br>
<div class=3D"im"><br>
&gt; If there is going to be a fixed, non-customizable behavior, AND, provi=
ded<br>
&gt; that assertions are also used in release builds, it should never abort=
 but<br>
&gt; throw instead (for the simple reason that with a throw you allow the<b=
r>
&gt; programmer to do something about it)<br>
<br>
</div>Maybe some examples would help, I have no idea what you can do at<br>
run-time about it.<br>
<div class=3D""><div class=3D"h5"><br></div></div></blockquote><div>Well, t=
he simplest way to give you an example is to ask you to consider other lang=
uages.<br></div><div>(AFAICT) C and by inhetritance, C++, are the only lang=
uages which abort in case of a precondition violation.<br>

</div><div>Modern languages such as (just to name a few) C#, Java, Ruby/Pyt=
hon and JavaScript all throw on errors, any kind of errors including progra=
mming errors. None of them abort.<br><br></div><div>The state corruption th=
at is always put as the reason for aborting ocurrs
 in any program that runs into an error no matter what language it is=20
in. I do and had been doing for a long time work in factories where C++ is =
just a piece of the puzzle, and IME I&#39;ve never ever once see a program =
run into a problem *because* the response to an error was to throw, not eve=
n a programmers error. So this theoretically correct fear that the program =
won&#39;t got back to a stable state if you throw instead of a abort is som=
ething that I never ever experienced not even once in a real program constr=
ucted with the least of the cares (meaning, without throwing in destructors=
)<br>

<br>Consider that in dynamic languages like, say Ruby or JavaScript, even a=
 &quot;syntax error&quot; (which can&#39;t be detected until you try to run=
 it), throws an exception, so there is quite a lot of that.<br><br>You coul=
d argue that there is key difference between C++ and all those other langua=
ges: in C++, we unwind the stack calling destructors all the way up. That m=
akes it a harzard, I take that. Now, do any of you had the actual experienc=
e of throwing in asserts and running into trouble because of that, so much =
that abort would have been better? Alll this time the only practical and re=
alisitc reason I&#39;ve heard that it meses up with diagnosing the error be=
cause you don&#39;t get a nice dump, but that&#39;s in the past for most mo=
dern IDEs AFAICT.<br>

<br></div><div>I insist that the &quot;abort doctrine&quot; as I call it is=
 just an accident of inheriting assert() from a language, C, that just can&=
#39;t do anything else because it has no exceptions.<br></div><div><br>

</div><div>Best<br><br></div></div><br><br clear=3D"all"><br>-- <br>Fernand=
o Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-=
consulting.com">http://www.scisoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e012292fabf291904db60d15d--

.

--089e013a1978174fab04db60ed8c
Content-Type: text/plain; charset=ISO-8859-1

On 28 April 2013 03:25, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:

> You could argue that there is key difference between C++ and all those
> other languages: in C++, we unwind the stack calling destructors all the
> way up. That makes it a harzard, I take that. Now, do any of you had the
> actual experience of throwing in asserts and running into trouble because
> of that, so much that abort would have been better? Alll this time the only
> practical and
>

I do have such experience. I have seen cases where exceptions would've been
caught and practically
ignored by catch-all blocks, whereas aborts don't end up in those and
trigger operating system dump generation.


> realisitc reason I've heard that it meses up with diagnosing the error
> because you don't get a nice dump, but that's in the past for most modern
> IDEs AFAICT.
>

The IDEs hardly run on devices that fit into your hand.


> I insist that the "abort doctrine" as I call it is just an accident of
> inheriting assert() from a language, C, that just can't do anything else
> because it has no exceptions.
>

That may well be part of the puzzle, but the "abort doctrine" is far more
useful than that, even in languages
that have exceptions.

--

---
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/?hl=en.



--089e013a1978174fab04db60ed8c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 28 April 2013 03:25, Fernando Cacciola <span dir=3D"ltr">&lt;<a =
href=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacc=
iola@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">You could argue that there is key difference bet=
ween C++ and all those other languages: in C++, we unwind the stack calling=
 destructors all the way up. That makes it a harzard, I take that. Now, do =
any of you had the actual experience of throwing in asserts and running int=
o trouble because of that, so much that abort would have been better? Alll =
this time the only practical and </div>
</div></div></blockquote><div><br></div><div>I do have such experience. I h=
ave seen cases where exceptions would&#39;ve been caught and practically<br=
></div><div>ignored by catch-all blocks, whereas aborts don&#39;t end up in=
 those and trigger operating system dump generation.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote">realisitc reason I&#39;ve heard tha=
t it meses up with diagnosing the error because you don&#39;t get a nice du=
mp, but that&#39;s in the past for most modern IDEs AFAICT.<br>
</div></div></div></blockquote><div><br></div><div>The IDEs hardly run on d=
evices that fit into your hand.<br>=A0<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>

I insist that the &quot;abort doctrine&quot; as I call it is just an accide=
nt of inheriting assert() from a language, C, that just can&#39;t do anythi=
ng else because it has no exceptions.<br></div></div></div></div></blockquo=
te>
<div><br></div><div>That may well be part of the puzzle, but the &quot;abor=
t doctrine&quot; is far more useful than that, even in languages<br>that ha=
ve exceptions.<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e013a1978174fab04db60ed8c--

.

--001a11c268048baf9204db60ed84
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 27, 2013 at 4:14 PM, Andrzej Krzemie=F1ski <akrzemi1@gmail.com>=
wrote:

>
>
> W dniu sobota, 27 kwietnia 2013 19:58:56 UTC+2 u=BFytkownik Fernando
> Cacciola napisa=B3:
>
>> On Sat, Apr 27, 2013 at 9:21 AM, Andrzej Krzemie=F1ski <akrz...@gmail.co=
m>wrote:
>>
>>>
>>> And lest I forget: I expect assertions to abort by default, and provide
>>>> users the ability to make them
>>>> throw/whatever instead. I think that's the best default choice. If you
>>>> want a precondition that throws by
>>>> default, that's not an assertion.
>>>>
>>>
>>> 'Abort' in what sense? "Not throw" or call std::abort? My experience is
>>> that it is preferable to call std::terminate instead of std::abort in
>>> home-made assertions.
>>>
>>
>> Agreed (and I would bet he meant "abort the application" rather than one
>> specific way to do it).
>>
>>
>>>  The former gives the program the chance to clear some system-critical
>>> resources and schedule a program restart, and offers a considerable saf=
ety
>>> (compared to exceptions).
>>>
>>
>> Let me add another ball to the discussion. The reason prople prefer
>> something like termiante to a throw, even in release, is what you just
>> said, safety (it is technically true that the program might go astray as=
 it
>> winds up, even though I almost never experienced it in practice), so I'v=
e
>> consider that what we need is a new thing which is neither terminate nor
>> throw. Sort of like the longjump of old C days. The part of the exceptio=
n
>> mechanism where we resume flow at the catch is what I want in the case o=
f a
>> condition violation, because that allows the application to keep running=
..
>> The unwinding of the stack is what gets in the way. With such a tool, I =
can
>> strucutre the applciation in a way such that the any state corruption
>> ocurring in one branch does not affect any other branch. That is, I can
>> program a safe rescue point. I prefer a throw in the current C++ because=
 it
>> allows me to get closer to that, while terminate leave me (and the end
>> user) hanging.
>>
>
> Another approach at providing the "keep running" guarantee is to didide
> your program into a number of separate processess (which do not share
> memory among themselves) and terminate each corrupt process separately. T=
he
> master process can detect the termination of the child and restart it. Th=
is
> way you provide the impression that your program never terminates.
>
> You can of course do that, but at the expense of a huge amount of
boilerplating code.

I would now add something else: would you think that the reason most modern
applications, I'm thinking of say, Excel, or Corel, or Firefox, etc...
don't suddently display an error and quit anymore, like they used to do 20
years ago, it's because they are free from programming errors (i.e. there
are absolutely no  preconditions being violated)?

I'm pretty sure that it is because corrupted stated usually winds up in a
system failure (such as access violation) which, these days, throws an
exception, and the applications are structured to handle that. FWIW, I can
state that this is in fact the case of a few (not so popular) large
applications I've worked with and where I specifically took care of that.



--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--=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/?hl=3Den.



--001a11c268048baf9204db60ed84
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Apr 27, 2013 at 4:14 PM, Andrzej Krzemie=F1ski <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a=
>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>W dniu sobota, 27 kwietnia 2013 19:5=
8:56 UTC+2 u=BFytkownik Fernando Cacciola napisa=B3:<div><div class=3D"h5">=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div><div class=3D"gmail_quote">On Sat, Apr 27, 2013 at 9:=
21 AM, Andrzej Krzemie=F1ski <span dir=3D"ltr">&lt;<a>akrz...@gmail.com</a>=
&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">



<div dir=3D"ltr"><div>And lest I forget: I expect assertions to abort by de=
fault, and provide users the ability to make them<br>throw/whatever instead=
.. I think that&#39;s the best default choice. If you want a precondition th=
at throws by<br>




default, that&#39;s not an assertion.<br></div></div></blockquote></div><di=
v><br>&#39;Abort&#39; in what sense? &quot;Not throw&quot; or call std::abo=
rt? My experience is that it is preferable to call std::terminate instead o=
f std::abort in home-made assertions.</div>



</blockquote><div><br></div><div>Agreed (and I would bet he meant &quot;abo=
rt the application&quot; rather than one specific way to do it).<br></div><=
div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">



<div> The former gives the program the chance to clear some system-critical=
 resources and schedule a program restart, and offers a considerable safety=
 (compared to exceptions). <br></div></blockquote><div><br></div><div>


Let me add another ball to the discussion. The reason prople prefer somethi=
ng like termiante to a throw, even in release, is what you just said, safet=
y (it is technically true that the program might go astray as it winds up, =
even though I almost never experienced it in practice), so I&#39;ve conside=
r that what we need is a new thing which is neither terminate nor throw. So=
rt of like the longjump of old C days. The part of the exception mechanism =
where we resume flow at the catch is what I want in the case of a condition=
 violation, because that allows the application to keep running. The unwind=
ing of the stack is what gets in the way. With such a tool, I can strucutre=
 the applciation in a way such that the any state corruption ocurring in on=
e branch does not affect any other branch. That is, I can program a safe re=
scue point. I prefer a throw in the current C++ because it allows me to get=
 closer to that, while terminate leave me (and the end user) hanging.<br>



</div></div></div></div></blockquote></div></div><div><br>Another approach =
at providing the &quot;keep running&quot; guarantee is to didide your progr=
am into a number of separate processess (which do not share memory among th=
emselves) and terminate each corrupt process separately. The master process=
 can detect the termination of the child and restart it. This way you provi=
de the impression that your program never terminates.<br>

<br></div></blockquote><div>You can of course do that, but at the expense o=
f a huge amount of boilerplating code.<br><br></div><div>I would now add so=
mething else: would you think that the reason most modern applications, I&#=
39;m thinking of say, Excel, or Corel, or Firefox, etc... don&#39;t suddent=
ly display an error and quit anymore, like they used to do 20 years ago, it=
&#39;s because they are free from programming errors (i.e. there are absolu=
tely no=A0 preconditions being violated)?=A0 <br>

<br></div><div>I&#39;m pretty sure that it is because corrupted stated usua=
lly winds up in a system failure (such as access violation) which, these da=
ys, throws an exception, and the applications are structured to handle that=
.. FWIW, I can state that this is in fact the case of a few (not so popular)=
 large applications I&#39;ve worked with and where I specifically took care=
 of that. <br>

=A0<br></div></div><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>SciSof=
t Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">http=
://www.scisoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c268048baf9204db60ed84--

.

--089e01229c30334a4304db6111de
Content-Type: text/plain; charset=ISO-8859-1

On 28 April 2013 03:33, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:

> I'm pretty sure that it is because corrupted stated usually winds up in a
> system failure (such as access violation) which, these days, throws an
> exception, and the applications are structured to handle that. FWIW, I can
> state that this is in fact the case of a few (not so popular) large
> applications I've worked with and where I specifically took care of that.
>
>

Sure, I bet many of us have.. but what are we debating here, really? I
think it's pretty much undisputed
that it's useful to allow programmers to decide what an assert does. Then,
to the question about what
it does by default, I don't think that's a show-stopper either way. I
advocate abort-by-default because
violating the whatever-conditions (pre/post/doesn'treallymatter) has been
undefined behaviour for
quite some time in so many systems that I expect most seasoned-enough
programmers to cope with
that. That is, including enough safeguards in their large applications that
clueless people writing
small plugins or whatever-mundane-snippets can't cause violations of
whatever-conditions.

I could actually live with asserts-throw-by-default, given my background. I
doubt most other people will.

--

---
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/?hl=en.



--089e01229c30334a4304db6111de
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 28 April 2013 03:33, Fernando Cacciola <span dir=3D"ltr">&lt;<a =
href=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacc=
iola@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">I&#39;m pretty sure that it is because corrupted=
 stated usually winds up in a system failure (such as access violation) whi=
ch, these days, throws an exception, and the applications are structured to=
 handle that. FWIW, I can state that this is in fact the case of a few (not=
 so popular) large applications I&#39;ve worked with and where I specifical=
ly took care of that. <br>
<div>

=A0<br></div></div></div></div></blockquote><div><br></div><div>Sure, I bet=
 many of us have.. but what are we debating here, really? I think it&#39;s =
pretty much undisputed<br>that it&#39;s useful to allow programmers to deci=
de what an assert does. Then, to the question about what<br>
it does by default, I don&#39;t think that&#39;s a show-stopper either way.=
 I advocate abort-by-default because<br>violating the whatever-conditions (=
pre/post/doesn&#39;treallymatter) has been undefined behaviour for<br>quite=
 some time in so many systems that I expect most seasoned-enough programmer=
s to cope with<br>
that. That is, including enough safeguards in their large applications that=
 clueless people writing<br></div><div>small plugins or whatever-mundane-sn=
ippets can&#39;t cause violations of whatever-conditions.<br><br></div>
<div>I could actually live with asserts-throw-by-default, given my backgrou=
nd. I doubt most other people will. <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e01229c30334a4304db6111de--

.

--047d7b34416853361c04db611b2c
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Apr 27, 2013 at 9:34 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 28 April 2013 03:25, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>
>> You could argue that there is key difference between C++ and all those
>> other languages: in C++, we unwind the stack calling destructors all the
>> way up. That makes it a harzard, I take that. Now, do any of you had the
>> actual experience of throwing in asserts and running into trouble because
>> of that, so much that abort would have been better? Alll this time the only
>> practical and
>>
>
> I do have such experience. I have seen cases where exceptions would've
> been caught and practically
> ignored by catch-all blocks, whereas aborts don't end up in those and
> trigger operating system dump generation.
>
>
OK.
So abort gives you a post-mortem diagnosis that is impossible with a throw,
But let me ask you something: does that occur only in Debug? or in Release
as well? can you live with the programming quitting in the face of the end
user each time it hits an effect?




> realisitc reason I've heard that it meses up with diagnosing the error
>> because you don't get a nice dump, but that's in the past for most modern
>> IDEs AFAICT.
>>
>
> The IDEs hardly run on devices that fit into your hand.
>
>
Fair enough.



>  I insist that the "abort doctrine" as I call it is just an accident of
>> inheriting assert() from a language, C, that just can't do anything else
>> because it has no exceptions.
>>
>
> That may well be part of the puzzle, but the "abort doctrine" is far more
> useful than that, even in languages
> that have exceptions.
>
>  --
>
> ---
> 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/?hl=en.
>
>
>



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--047d7b34416853361c04db611b2c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Apr 27, 2013 at 9:34 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 28 April 2013 0=
3:25, Fernando Cacciola <span dir=3D"ltr">&lt;<a href=3D"mailto:fernando.ca=
cciola@gmail.com" target=3D"_blank">fernando.cacciola@gmail.com</a>&gt;</sp=
an> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">You could argue that there is key difference bet=
ween C++ and all those other languages: in C++, we unwind the stack calling=
 destructors all the way up. That makes it a harzard, I take that. Now, do =
any of you had the actual experience of throwing in asserts and running int=
o trouble because of that, so much that abort would have been better? Alll =
this time the only practical and </div>


</div></div></blockquote><div><br></div></div><div>I do have such experienc=
e. I have seen cases where exceptions would&#39;ve been caught and practica=
lly<br></div><div>ignored by catch-all blocks, whereas aborts don&#39;t end=
 up in those and trigger operating system dump generation.<br>


=A0<br></div></div></div></div></blockquote><div>OK.<br></div><div>So abort=
 gives you a post-mortem diagnosis that is impossible with a throw, <br>But=
 let me ask you something: does that occur only in Debug? or in Release as =
well? can you live with the programming quitting in the face of the end use=
r each time it hits an effect?<br>

<br><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div clas=
s=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">real=
isitc reason I&#39;ve heard that it meses up with diagnosing the error beca=
use you don&#39;t get a nice dump, but that&#39;s in the past for most mode=
rn IDEs AFAICT.<br>


</div></div></div></blockquote><div><br></div></div><div>The IDEs hardly ru=
n on devices that fit into your hand.<br>=A0<br></div></div></div></div></b=
lockquote><div>Fair enough.<br><br></div><div></div><div>=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
></div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>

I insist that the &quot;abort doctrine&quot; as I call it is just an accide=
nt of inheriting assert() from a language, C, that just can&#39;t do anythi=
ng else because it has no exceptions.<br></div></div></div></div></blockquo=
te>


<div><br></div></div><div>That may well be part of the puzzle, but the &quo=
t;abort doctrine&quot; is far more useful than that, even in languages<br>t=
hat have exceptions.<br></div></div><br></div></div><div class=3D"HOEnZb">

<div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@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/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Fernando Ca=
cciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-cons=
ulting.com">http://www.scisoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b34416853361c04db611b2c--

.

--089e0153853028915104db613b3c
Content-Type: text/plain; charset=ISO-8859-1

On 28 April 2013 03:46, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:

> OK.
> So abort gives you a post-mortem diagnosis that is impossible with a
> throw,
>

I wouldn't say it's impossible. It depends on the system at hand.


> But let me ask you something: does that occur only in Debug? or in Release
> as well? can you live with the programming quitting in the face of the end
> user each time it hits an effect?
>

Sometimes it occurs in both, and in some cases I can live with it, in some
cases I can't. It's a bloody coin-toss
that doesn't have an easy answer. ;) Given the systems I've seen, there
have been many cases where
I have wished for a way to avoid aborting subsystems, but even in those
cases I was glad I had the aborts
so that I was able to build the systems above such subsystems properly,
rather than have to worry about
exception handlers accidentally papering over logic errors.

--

---
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/?hl=en.



--089e0153853028915104db613b3c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 28 April 2013 03:46, Fernando Cacciola <span dir=3D"ltr">&lt;<a =
href=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacc=
iola@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">OK.<br><div>So abort gives you a post-mortem dia=
gnosis that is impossible with a throw, <br>
</div></div></div></div></blockquote><div><br></div><div>I wouldn&#39;t say=
 it&#39;s impossible. It depends on the system at hand.<br>=A0<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>But let me ask you something: does that occur only in Debug? or in Release=
 as well? can you live with the programming quitting in the face of the end=
 user each time it hits an effect?<br>
</div></div></div></div></blockquote><div><br></div><div>Sometimes it occur=
s in both, and in some cases I can live with it, in some cases I can&#39;t.=
 It&#39;s a bloody coin-toss<br></div><div>that doesn&#39;t have an easy an=
swer. ;) Given the systems I&#39;ve seen, there have been many cases where<=
br>
</div><div>I have wished for a way to avoid aborting subsystems, but even i=
n those cases I was glad I had the aborts<br></div><div>so that I was able =
to build the systems above such subsystems properly, rather than have to wo=
rry about<br>
</div><div>exception handlers accidentally papering over logic errors.<br><=
/div></div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e0153853028915104db613b3c--

.

--089e0149405caf4a5204db6175be
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Apr 27, 2013 at 9:44 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 28 April 2013 03:33, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>
>> I'm pretty sure that it is because corrupted stated usually winds up in a
>> system failure (such as access violation) which, these days, throws an
>> exception, and the applications are structured to handle that. FWIW, I can
>> state that this is in fact the case of a few (not so popular) large
>> applications I've worked with and where I specifically took care of that.
>>
>>
>
> Sure, I bet many of us have.. but what are we debating here, really? I
> think it's pretty much undisputed
> that it's useful to allow programmers to decide what an assert does. Then,
> to the question about what
> it does by default, I don't think that's a show-stopper either way. I
> advocate abort-by-default because
> violating the whatever-conditions (pre/post/doesn'treallymatter) has been
> undefined behaviour for
> quite some time in so many systems that I expect most seasoned-enough
> programmers to cope with
> that. That is, including enough safeguards in their large applications
> that clueless people writing
> small plugins or whatever-mundane-snippets can't cause violations of
> whatever-conditions.
>
> I could actually live with asserts-throw-by-default, given my background.
> I doubt most other people will.
>
> Right, let's re-focus the discussion into something usefull.
Which default is better goes nowhere because the bottomline is that none of
the choices are good enough.

In fact, I'm arguing what assert should do, yet I haven't use it myself
since the early 90s.
Since I do care a lot about how programs respond to errors, including
programming errors, what I have been doing is the following (and BTW lots
of "libraries" do something quite similar)

I use my own assert macro which calls a user user-defined function. The
error function calls in turn a user-defined reporting function then a
user-defined response function.

By default, the reporting function does nothing and the response function
throws an exception. However, I never use it like that and I always install
a reporting function that logs into a text file (whenever possible), or the
console if not.

I never install a response function which doesn't throw though, but that's
because whenever I need to diagnose something I use an IDE and put a
breakpoint in there (so I don't have to allow the IDE to break at every
exception which can be quite annoying)

Now something else that it's going to be argued against a lot, but I put it
just for the record: when std exceptions first came out, I hated that the
debugger wouldn't break on throw (it used to be like so in the beggining),
so I had my own hierarchy of exception classes, matching the one in std,
except that they all had a virtual "raise" method. Then, you wouldn't do:
throw std::exception(), instead you would do:  exception().raise(). And all
exception classes ended up calling the base class raise() method. A very
nice consequence of that design is that could you add exceptions where
appropriate all over your code (specially library code) but then just turn
actual throwing off via a simple configuration used by the base
exception::raise() method having it abort() instead.

Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--089e0149405caf4a5204db6175be
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Apr 27, 2013 at 9:44 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 28 April 2013 0=
3:33, Fernando Cacciola <span dir=3D"ltr">&lt;<a href=3D"mailto:fernando.ca=
cciola@gmail.com" target=3D"_blank">fernando.cacciola@gmail.com</a>&gt;</sp=
an> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">I&#39;m pretty sure that it is because corrupted=
 stated usually winds up in a system failure (such as access violation) whi=
ch, these days, throws an exception, and the applications are structured to=
 handle that. FWIW, I can state that this is in fact the case of a few (not=
 so popular) large applications I&#39;ve worked with and where I specifical=
ly took care of that. <br>


<div>

=A0<br></div></div></div></div></blockquote><div><br></div></div><div>Sure,=
 I bet many of us have.. but what are we debating here, really? I think it&=
#39;s pretty much undisputed<br>that it&#39;s useful to allow programmers t=
o decide what an assert does. Then, to the question about what<br>


it does by default, I don&#39;t think that&#39;s a show-stopper either way.=
 I advocate abort-by-default because<br>violating the whatever-conditions (=
pre/post/doesn&#39;treallymatter) has been undefined behaviour for<br>

quite some time in so many systems that I expect most seasoned-enough progr=
ammers to cope with<br>
that. That is, including enough safeguards in their large applications that=
 clueless people writing<br></div><div>small plugins or whatever-mundane-sn=
ippets can&#39;t cause violations of whatever-conditions.<br><br></div>


<div>I could actually live with asserts-throw-by-default, given my backgrou=
nd. I doubt most other people will. <br></div></div><br></div></div></block=
quote><div>Right, let&#39;s re-focus the discussion into something usefull.=
 <br>

Which default is better goes nowhere because the bottomline is that none of=
 the choices are good enough.<br><br></div><div>In fact, I&#39;m arguing wh=
at assert should do, yet I haven&#39;t use it myself since the early 90s.<b=
r>

</div><div>Since I do care a lot about how programs respond to errors, incl=
uding programming errors, what I have been doing is the following (and BTW =
lots of &quot;libraries&quot; do something quite similar)<br><br></div>

<div>I use my own assert macro which calls a user user-defined function. Th=
e error function calls in turn a user-defined reporting function then a use=
r-defined response function.<br><br>By default, the reporting function does=
 nothing and the response function throws an exception. However, I never us=
e it like that and I always install a reporting function that logs into a t=
ext file (whenever possible), or the console if not.<br>

<br></div><div>I never install a response function which doesn&#39;t throw =
though, but that&#39;s because whenever I need to diagnose something I use =
an IDE and put a breakpoint in there (so I don&#39;t have to allow the IDE =
to break at every exception which can be quite annoying)<br>

<br></div><div>Now something else that it&#39;s going to be argued against =
a lot, but I put it just for the record: when std exceptions first came out=
, I hated that the debugger wouldn&#39;t break on throw (it used to be like=
 so in the beggining), so I had my own hierarchy of exception classes, matc=
hing the one in std, except that they all had a virtual &quot;raise&quot; m=
ethod. Then, you wouldn&#39;t do:=A0 throw std::exception(), instead you wo=
uld do:=A0 exception().raise(). And all exception classes ended up calling =
the base class raise() method. A very nice consequence of that design is th=
at could you add exceptions where appropriate all over your code (specially=
 library code) but then just turn actual throwing off via a simple configur=
ation used by the base exception::raise() method having it abort() instead.=
<br>

</div><div><br></div><div>Best<br clear=3D"all"></div></div>-- <br>Fernando=
 Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-c=
onsulting.com">http://www.scisoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e0149405caf4a5204db6175be--

.

On Sat, Apr 27, 2013 at 9:09 PM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
>> Isn't all that better done by the operating system (or a process monitor)?
>> What system-critical resources are you referring to?
>
>
> In some cases that would be true. I  believe that on Windows when you needed
> to use the global clipboard, you have to manually lock it and then manually
> unlock it: otherwise it will not be released -- I am not sure about this one

Sounds like a bad design and error prone.

> though. But note that C++ can be used to write the operating system (this is
> what the Standard calls the free-standing implementation, right?). In that
> case you cannot rely on the OS yet.

In that case you'd better not trip any asserts. The result would
probably be a kernel panic / BSOD.
I'm not sure exceptions are usable for that kind of code either.
Note that operating systems are big, a lot of code should be able to
depend on lower level facilities for process clean up.

--

---
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/?hl=en.



.

On Sun, Apr 28, 2013 at 2:25 AM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
>> Maybe some examples would help, I have no idea what you can do at
>> run-time about it.
>>
> Well, the simplest way to give you an example is to ask you to consider
> other languages.
> (AFAICT) C and by inhetritance, C++, are the only languages which abort in
> case of a precondition violation.
> Modern languages such as (just to name a few) C#, Java, Ruby/Python and
> JavaScript all throw on errors, any kind of errors including programming
> errors. None of them abort.

Other language are not an example, it doesn't tell for what kind of
programs your behaviour is desired.

> You could argue that there is key difference between C++ and all those other
> languages: in C++, we unwind the stack calling destructors all the way up.
> That makes it a harzard, I take that. Now, do any of you had the actual
> experience of throwing in asserts and running into trouble because of that,
> so much that abort would have been better?

I have no experience with throwing asserts but I have no wish for them either.
Note that exceptions also have a performance and complexity cost.

> Alll this time the only practical
> and realisitc reason I've heard that it meses up with diagnosing the error
> because you don't get a nice dump, but that's in the past for most modern
> IDEs AFAICT.

Most users don't have an IDE installed. I certainly don't have IDEs on servers.
That's not really an argument though, you could easily first dump and
then throw.

--

---
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/?hl=en.



.

On Sun, Apr 28, 2013 at 2:33 AM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> I would now add something else: would you think that the reason most modern
> applications, I'm thinking of say, Excel, or Corel, or Firefox, etc... don't
> suddently display an error and quit anymore, like they used to do 20 years
> ago, it's because they are free from programming errors (i.e. there are
> absolutely no  preconditions being violated)?

Why are we speculating? Can't you look into their code and/or coding
guidelines to find out what they're doing?

> I'm pretty sure that it is because corrupted stated usually winds up in a
> system failure (such as access violation) which, these days, throws an
> exception, and the applications are structured to handle that. FWIW, I can
> state that this is in fact the case of a few (not so popular) large
> applications I've worked with and where I specifically took care of that.

I'd prefer a hard error over silent data corruption.
Don't you agree that for a lot of programs aborting on assert failure
is perfectly fine?

--

---
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/?hl=en.



.

--047d7b5d8cff14487404db7b78da
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

2013/4/28 Fernando Cacciola <fernando.cacciola@gmail.com>

> On Sat, Apr 27, 2013 at 4:14 PM, Andrzej Krzemie=F1ski <akrzemi1@gmail.co=
m>wrote:
>
>>
>>
>> W dniu sobota, 27 kwietnia 2013 19:58:56 UTC+2 u=BFytkownik Fernando
>> Cacciola napisa=B3:
>>
>>> On Sat, Apr 27, 2013 at 9:21 AM, Andrzej Krzemie=F1ski <akrz...@gmail.c=
om>wrote:
>>>
>>>>
>>>> And lest I forget: I expect assertions to abort by default, and provid=
e
>>>>> users the ability to make them
>>>>> throw/whatever instead. I think that's the best default choice. If yo=
u
>>>>> want a precondition that throws by
>>>>> default, that's not an assertion.
>>>>>
>>>>
>>>> 'Abort' in what sense? "Not throw" or call std::abort? My experience i=
s
>>>> that it is preferable to call std::terminate instead of std::abort in
>>>> home-made assertions.
>>>>
>>>
>>> Agreed (and I would bet he meant "abort the application" rather than on=
e
>>> specific way to do it).
>>>
>>>
>>>>  The former gives the program the chance to clear some system-critical
>>>> resources and schedule a program restart, and offers a considerable sa=
fety
>>>> (compared to exceptions).
>>>>
>>>
>>> Let me add another ball to the discussion. The reason prople prefer
>>> something like termiante to a throw, even in release, is what you just
>>> said, safety (it is technically true that the program might go astray a=
s it
>>> winds up, even though I almost never experienced it in practice), so I'=
ve
>>> consider that what we need is a new thing which is neither terminate no=
r
>>> throw. Sort of like the longjump of old C days. The part of the excepti=
on
>>> mechanism where we resume flow at the catch is what I want in the case =
of a
>>> condition violation, because that allows the application to keep runnin=
g.
>>> The unwinding of the stack is what gets in the way. With such a tool, I=
 can
>>> strucutre the applciation in a way such that the any state corruption
>>> ocurring in one branch does not affect any other branch. That is, I can
>>> program a safe rescue point. I prefer a throw in the current C++ becaus=
e it
>>> allows me to get closer to that, while terminate leave me (and the end
>>> user) hanging.
>>>
>>
>> Another approach at providing the "keep running" guarantee is to didide
>> your program into a number of separate processess (which do not share
>> memory among themselves) and terminate each corrupt process separately. =
The
>> master process can detect the termination of the child and restart it. T=
his
>> way you provide the impression that your program never terminates.
>>
>> You can of course do that, but at the expense of a huge amount of
> boilerplating code.
>
> I would now add something else: would you think that the reason most
> modern applications, I'm thinking of say, Excel, or Corel, or Firefox,
> etc... don't suddently display an error and quit anymore, like they used =
to
> do 20 years ago, it's because they are free from programming errors (i.e.
> there are absolutely no  preconditions being violated)?
>
> I'm pretty sure that it is because corrupted stated usually winds up in a
> system failure (such as access violation) which, these days, throws an
> exception, and the applications are structured to handle that. FWIW, I ca=
n
> state that this is in fact the case of a few (not so popular) large
> applications I've worked with and where I specifically took care of that.
>

I guess different systems are subject to different expectations. You
mention Excel, Corel and Firefox, and I trust you that the approach I call
"keep running" guarantee is just the thing you need for these systems.

I spent a lot of time with the system that can be characterized as
life-critical but not real-time. The program is making a decision whether
an aircraft is allowed to take off based on how it has been loaded (with
passengers, fuel, cargo). Making the wrong call can have disastrous
consequences. On the other hand stopping the program has no serious
consequences: you do the computation some time before the departure and
even if the program is completely down, the users can do a similar
computation manually on a sheet of paper or use another program.

In case we detect an a bug, we do not want to take the chances of trying to
throw and hoping (even with big confidence) that the bug will go away. We
wouldn't even risk trying. On the other hand, program abort (with an
apologize message) is the best possible indication to the client that the
program has a bug and should not be trusted. It is not even clear if it is
a good idea to restart it -- given that you know there is a bug in it
(although clients still choose to restart).

In my team, the promotion of the "keep running" guarantee (picked up by
some programmers) introduced an unnecessary safety bug to the program. I
personally find it a harm -- in the context of our domain.

But my domain may be a niche one. since we are here discussing only the
default behaviour of assertions it may not be that big of a problem.

On the other hand, the harsh default has a good psychological effect on the
programmers: the fear motivates them to put some thought into what they
want their customized behaviour to be.

Regards,
&rzej

--=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/?hl=3Den.



--047d7b5d8cff14487404db7b78da
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">2013/4/28 Fernando Cacciola <span dir=3D=
"ltr">&lt;<a href=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">=
fernando.cacciola@gmail.com</a>&gt;</span><br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D"im">On Sat, Apr 27, 2013 at 4:14 PM, Andrzej Krzemie=F1ski <span =
dir=3D"ltr">&lt;<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akr=
zemi1@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>W dniu sobota, 27 kwietnia 2013 19:5=
8:56 UTC+2 u=BFytkownik Fernando Cacciola napisa=B3:<div><div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex">


<div dir=3D"ltr"><div><div class=3D"gmail_quote">On Sat, Apr 27, 2013 at 9:=
21 AM, Andrzej Krzemie=F1ski <span dir=3D"ltr">&lt;<a>akrz...@gmail.com</a>=
&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">




<div dir=3D"ltr"><div>And lest I forget: I expect assertions to abort by de=
fault, and provide users the ability to make them<br>throw/whatever instead=
.. I think that&#39;s the best default choice. If you want a precondition th=
at throws by<br>





default, that&#39;s not an assertion.<br></div></div></blockquote></div><di=
v><br>&#39;Abort&#39; in what sense? &quot;Not throw&quot; or call std::abo=
rt? My experience is that it is preferable to call std::terminate instead o=
f std::abort in home-made assertions.</div>




</blockquote><div><br></div><div>Agreed (and I would bet he meant &quot;abo=
rt the application&quot; rather than one specific way to do it).<br></div><=
div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">




<div> The former gives the program the chance to clear some system-critical=
 resources and schedule a program restart, and offers a considerable safety=
 (compared to exceptions). <br></div></blockquote><div><br></div><div>



Let me add another ball to the discussion. The reason prople prefer somethi=
ng like termiante to a throw, even in release, is what you just said, safet=
y (it is technically true that the program might go astray as it winds up, =
even though I almost never experienced it in practice), so I&#39;ve conside=
r that what we need is a new thing which is neither terminate nor throw. So=
rt of like the longjump of old C days. The part of the exception mechanism =
where we resume flow at the catch is what I want in the case of a condition=
 violation, because that allows the application to keep running. The unwind=
ing of the stack is what gets in the way. With such a tool, I can strucutre=
 the applciation in a way such that the any state corruption ocurring in on=
e branch does not affect any other branch. That is, I can program a safe re=
scue point. I prefer a throw in the current C++ because it allows me to get=
 closer to that, while terminate leave me (and the end user) hanging.<br>




</div></div></div></div></blockquote></div></div><div><br>Another approach =
at providing the &quot;keep running&quot; guarantee is to didide your progr=
am into a number of separate processess (which do not share memory among th=
emselves) and terminate each corrupt process separately. The master process=
 can detect the termination of the child and restart it. This way you provi=
de the impression that your program never terminates.<br>


<br></div></blockquote></div><div>You can of course do that, but at the exp=
ense of a huge amount of boilerplating code.<br><br></div><div>I would now =
add something else: would you think that the reason most modern application=
s, I&#39;m thinking of say, Excel, or Corel, or Firefox, etc... don&#39;t s=
uddently display an error and quit anymore, like they used to do 20 years a=
go, it&#39;s because they are free from programming errors (i.e. there are =
absolutely no=A0 preconditions being violated)?=A0 <br>


<br></div><div>I&#39;m pretty sure that it is because corrupted stated usua=
lly winds up in a system failure (such as access violation) which, these da=
ys, throws an exception, and the applications are structured to handle that=
.. FWIW, I can state that this is in fact the case of a few (not so popular)=
 large applications I&#39;ve worked with and where I specifically took care=
 of that. <br>
</div></div></div></div></blockquote><div><br>I guess different systems are=
 subject to different expectations. You mention Excel, Corel and Firefox, a=
nd I trust you that the approach I call &quot;keep running&quot; guarantee =
is just the thing you need for these systems. <br>
<br>I spent a lot of time with the system that can be characterized as life=
-critical but not real-time. The program is making a decision whether an ai=
rcraft is allowed to take off based on how it has been loaded (with passeng=
ers, fuel, cargo). Making the wrong call can have disastrous consequences. =
On the other hand stopping the program has no serious consequences: you do =
the computation some time before the departure and even if the program is c=
ompletely down, the users can do a similar computation manually on a sheet =
of paper or use another program.<br>
<br>In case we detect an a bug, we do not want to take the chances of tryin=
g to throw and hoping (even with big confidence) that the bug will go away.=
 We wouldn&#39;t even risk trying. On the other hand, program abort (with a=
n apologize message) is the best possible indication to the client that the=
 program has a bug and should not be trusted. It is not even clear if it is=
 a good idea to restart it -- given that you know there is a bug in it (alt=
hough clients still choose to restart). <br>
<br>In my team, the promotion of the &quot;keep running&quot; guarantee (pi=
cked up by some programmers) introduced an unnecessary safety bug to the pr=
ogram. I personally find it a harm -- in the context of our domain.<br>
<br>But my domain may be a niche one. since we are here discussing only the=
 default behaviour of assertions it may not be that big of a problem.<br><b=
r>On the other hand, the harsh default has a good psychological effect on t=
he programmers: the fear motivates them to put some thought into what they =
want their customized behaviour to be.<br>
<br>Regards,<br>&amp;rzej<br><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b5d8cff14487404db7b78da--

.

------=_Part_151_1367563.1367231236054
Content-Type: text/plain; charset=ISO-8859-1

On Sunday, April 28, 2013 1:25:48 AM UTC+1, Fernando Cacciola wrote:
>
> On Sat, Apr 27, 2013 at 3:15 PM, Olaf van der Spek <olafv...@gmail.com<javascript:>
> > wrote:
>
>> On Sat, Apr 27, 2013 at 7:41 PM, Fernando Cacciola
>> <fernando...@gmail.com <javascript:>> wrote:
>> > In any case, the intention was to state that you either "get UB as it is
>> > (not) defined" when building release, or get some behavior defined by
>> the
>> > implementation when you build debug. Olaf mentioned that this was a bad
>> > idea. I think it's controversial but not neccesary bad, and it's common
>> > practice
>>
>> The VC behaviour is fine, throwing a catchable exception (only in
>> debug mode) isn't.
>>
>> > If there is going to be a fixed, non-customizable behavior, AND,
>> provided
>> > that assertions are also used in release builds, it should never abort
>> but
>> > throw instead (for the simple reason that with a throw you allow the
>> > programmer to do something about it)
>>
>> Maybe some examples would help, I have no idea what you can do at
>> run-time about it.
>>
>> Well, the simplest way to give you an example is to ask you to consider
> other languages.
> (AFAICT) C and by inhetritance, C++, are the only languages which abort in
> case of a precondition violation.
> Modern languages such as (just to name a few) C#, Java, Ruby/Python and
> JavaScript all throw on errors, any kind of errors including programming
> errors. None of them abort.
>

The key difference is that all those languages are memory safe. You cannot
corrupt the stack, the memory arena or the general system integrity;
pointers are always either null or point to a valid allocated object; you
can't write outside of objects; you can't forge pointers; as long as you do
not export pointers to your data, you can always be reasonably sure that
they won't be corrupted by other modules; the garbage collector will always
be there to cleanup any mess. In practice there is always a minimum
guaranteed state you can rely on. A program is at least capable of safely
traverse a data structure and check its integrity.

Some languages even let you partition the heap between modules, giving even
strong guarantees (often in those languages asserts cause the whole module
to be aborted and the recovery can be done only at partition boundaries,
which IMHO is a good thing).

In general you can't do that in C and C++, unless you rely on address space
separation (which some programs which need very high reliability do).

The bottom line is that in C++, if you get a failure in a precondition
check, you can never be sure whether the cause is simply due to a simple
programming error in the caller or a more general corruption of the system.

-- gpd

--

---
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/?hl=en.



------=_Part_151_1367563.1367231236054
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sunday, April 28, 2013 1:25:48 AM UTC+1, Fernando Cacciola wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"g=
mail_quote">On Sat, Apr 27, 2013 at 3:15 PM, Olaf van der Spek <span dir=3D=
"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"PCD_9DOebMcJ">olafv...@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Sat, Apr 27, 2013=
 at 7:41 PM, Fernando Cacciola<br>
&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"PCD_=
9DOebMcJ">fernando...@gmail.com</a>&gt; wrote:<br>
&gt; In any case, the intention was to state that you either "get UB as it =
is<br>
&gt; (not) defined" when building release, or get some behavior defined by =
the<br>
&gt; implementation when you build debug. Olaf mentioned that this was a ba=
d<br>
&gt; idea. I think it's controversial but not neccesary bad, and it's commo=
n<br>
&gt; practice<br>
<br>
</div>The VC behaviour is fine, throwing a catchable exception (only in<br>
debug mode) isn't.<br>
<div><br>
&gt; If there is going to be a fixed, non-customizable behavior, AND, provi=
ded<br>
&gt; that assertions are also used in release builds, it should never abort=
 but<br>
&gt; throw instead (for the simple reason that with a throw you allow the<b=
r>
&gt; programmer to do something about it)<br>
<br>
</div>Maybe some examples would help, I have no idea what you can do at<br>
run-time about it.<br>
<div><div><br></div></div></blockquote><div>Well, the simplest way to give =
you an example is to ask you to consider other languages.<br></div><div>(AF=
AICT) C and by inhetritance, C++, are the only languages which abort in cas=
e of a precondition violation.<br>

</div><div>Modern languages such as (just to name a few) C#, Java, Ruby/Pyt=
hon and JavaScript all throw on errors, any kind of errors including progra=
mming errors. None of them abort.<br></div></div></div></div></blockquote><=
div><br>The key difference is that all those languages are memory safe. You=
 cannot corrupt the stack, the memory arena or the general system integrity=
; pointers are always either null or point to a valid allocated object; you=
 can't write outside of objects; you can't forge pointers; as long as you d=
o not export pointers to your data, you can always be reasonably sure that =
they won't be corrupted by other modules; the garbage collector will always=
 be there to cleanup any mess. In practice there is always a minimum guaran=
teed state you can rely on. A program is at least capable of safely travers=
e a data structure and check its integrity. <br><br>Some languages even let=
 you partition the heap between modules, giving even strong guarantees (oft=
en in those languages asserts cause the whole module to be aborted and the =
recovery can be done only at partition boundaries, which IMHO is a good thi=
ng).<br><br>In general you can't do that in C and C++, unless you rely on a=
ddress space separation (which some programs which need very high reliabili=
ty do).<br>&nbsp;<br>The bottom line is that in C++, if you get a failure i=
n a precondition check, you can never be sure whether the cause is simply d=
ue to a simple programming error in the caller or a more general corruption=
 of the system.<br></div><br>-- gpd<br><br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_151_1367563.1367231236054--

.

--089e013d17a4a674bb04db8008f6
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Apr 28, 2013 at 6:35 AM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Sun, Apr 28, 2013 at 2:25 AM, Fernando Cacciola
> <fernando.cacciola@gmail.com> wrote:
> >> Maybe some examples would help, I have no idea what you can do at
> >> run-time about it.
> >>
> > Well, the simplest way to give you an example is to ask you to consider
> > other languages.
> > (AFAICT) C and by inhetritance, C++, are the only languages which abort
> in
> > case of a precondition violation.
> > Modern languages such as (just to name a few) C#, Java, Ruby/Python and
> > JavaScript all throw on errors, any kind of errors including programming
> > errors. None of them abort.
>
> Other language are not an example, it doesn't tell for what kind of
> programs your behaviour is desired.
>
> I think they do serve to show that it is not really true that throwing is
the safest path in front of state corruption.
Assuming you disagre, let me ask you: why would a C++ program go worse if
you throw on assert then a program written in another language?

> You could argue that there is key difference between C++ and all those
> other
> > languages: in C++, we unwind the stack calling destructors all the way
> up.
> > That makes it a harzard, I take that. Now, do any of you had the actual
> > experience of throwing in asserts and running into trouble because of
> that,
> > so much that abort would have been better?
>
> I have no experience with throwing asserts but I have no wish for them
> either.
>

Fair enough.

For whatever is worth, my claim that throwing on assert is safe (I
explained the details of why before in this thread) is based on experience
that I do have doing this.


> Note that exceptions also have a performance and complexity cost.
>
> Of course. But exceptions are a central part C++ anyway since they are the
mechanism for system failures, not to mention that we have logic_error in
the standard precisely for precondition violations.



> > Alll this time the only practical
> > and realisitc reason I've heard that it meses up with diagnosing the
> error
> > because you don't get a nice dump, but that's in the past for most modern
> > IDEs AFAICT.
>
> Most users don't have an IDE installed. I certainly don't have IDEs on
> servers.
> That's not really an argument though, you could easily first dump and
> then throw.
>
> Exactly.


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--089e013d17a4a674bb04db8008f6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Apr 28, 2013 at 6:35 AM, Olaf van der Spek <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a=
>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Sun, Apr 28, 2013 at 2:=
25 AM, Fernando Cacciola<br>
&lt;<a href=3D"mailto:fernando.cacciola@gmail.com">fernando.cacciola@gmail.=
com</a>&gt; wrote:<br>
&gt;&gt; Maybe some examples would help, I have no idea what you can do at<=
br>
&gt;&gt; run-time about it.<br>
&gt;&gt;<br>
&gt; Well, the simplest way to give you an example is to ask you to conside=
r<br>
&gt; other languages.<br>
&gt; (AFAICT) C and by inhetritance, C++, are the only languages which abor=
t in<br>
&gt; case of a precondition violation.<br>
&gt; Modern languages such as (just to name a few) C#, Java, Ruby/Python an=
d<br>
&gt; JavaScript all throw on errors, any kind of errors including programmi=
ng<br>
&gt; errors. None of them abort.<br>
<br>
</div>Other language are not an example, it doesn&#39;t tell for what kind =
of<br>
programs your behaviour is desired.<br>
<div class=3D"im"><br></div></blockquote><div>I think they do serve to show=
 that it is not really true that throwing is the safest path in front of st=
ate corruption.<br></div><div>Assuming you disagre, let me ask you: why wou=
ld a C++ program go worse if you throw on assert then a program written in =
another language?<br>

<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div class=3D"im">
&gt; You could argue that there is key difference between C++ and all those=
 other<br>
&gt; languages: in C++, we unwind the stack calling destructors all the way=
 up.<br>
&gt; That makes it a harzard, I take that. Now, do any of you had the actua=
l<br>
&gt; experience of throwing in asserts and running into trouble because of =
that,<br>
&gt; so much that abort would have been better?<br>
<br>
</div>I have no experience with throwing asserts but I have no wish for the=
m either.<br></blockquote><div><br></div><div>Fair enough.<br><br></div><di=
v>For whatever is worth, my claim that throwing on assert is safe (I explai=
ned the details of why before in this thread) is based on experience that I=
 do have doing this.<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
Note that exceptions also have a performance and complexity cost.<br>
<div class=3D"im"><br></div></blockquote><div>Of course. But exceptions are=
 a central part C++ anyway since they are the mechanism for system failures=
, not to mention that we have logic_error in the standard precisely for pre=
condition violations.<br>

<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im">
&gt; Alll this time the only practical<br>
&gt; and realisitc reason I&#39;ve heard that it meses up with diagnosing t=
he error<br>
&gt; because you don&#39;t get a nice dump, but that&#39;s in the past for =
most modern<br>
&gt; IDEs AFAICT.<br>
<br>
</div>Most users don&#39;t have an IDE installed. I certainly don&#39;t hav=
e IDEs on servers.<br>
That&#39;s not really an argument though, you could easily first dump and<b=
r>
then throw.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div>E=
xactly.<br>=A0<br></div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consu=
lting, Founder<br><a href=3D"http://www.scisoft-consulting.com">http://www.=
scisoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e013d17a4a674bb04db8008f6--

.

--001a11c2a8845d72e204db801a91
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Apr 28, 2013 at 6:40 AM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Sun, Apr 28, 2013 at 2:33 AM, Fernando Cacciola
> <fernando.cacciola@gmail.com> wrote:
> > I would now add something else: would you think that the reason most
> modern
> > applications, I'm thinking of say, Excel, or Corel, or Firefox, etc...
> don't
> > suddently display an error and quit anymore, like they used to do 20
> years
> > ago, it's because they are free from programming errors (i.e. there are
> > absolutely no  preconditions being violated)?
>
> Why are we speculating? Can't you look into their code and/or coding
> guidelines to find out what they're doing?
>
> > I'm pretty sure that it is because corrupted stated usually winds up in a
> > system failure (such as access violation) which, these days, throws an
> > exception, and the applications are structured to handle that. FWIW, I
> can
> > state that this is in fact the case of a few (not so popular) large
> > applications I've worked with and where I specifically took care of that.
>
> I'd prefer a hard error over silent data corruption.
>

But you don't have to choose between one and the oher, that's the whole
point. You can have as much of a "hard error" you would get with
termination, then, throw *before the data corruption* (as you would with a
*pre*-condition check) to get the application any chance to recover.

Don't you agree that for a lot of programs aborting on assert failure
> is perfectly fine?
>
> Absolutely. For a lot a programs, yes. For the majority of the programs,
I'd think not.

Best


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--001a11c2a8845d72e204db801a91
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Apr 28, 2013 at 6:40 AM, Olaf van der Spek <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a=
>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Sun, Apr 28, 2013 at 2:=
33 AM, Fernando Cacciola<br>
&lt;<a href=3D"mailto:fernando.cacciola@gmail.com">fernando.cacciola@gmail.=
com</a>&gt; wrote:<br>
&gt; I would now add something else: would you think that the reason most m=
odern<br>
&gt; applications, I&#39;m thinking of say, Excel, or Corel, or Firefox, et=
c... don&#39;t<br>
&gt; suddently display an error and quit anymore, like they used to do 20 y=
ears<br>
&gt; ago, it&#39;s because they are free from programming errors (i.e. ther=
e are<br>
&gt; absolutely no =A0preconditions being violated)?<br>
<br>
</div>Why are we speculating? Can&#39;t you look into their code and/or cod=
ing<br>
guidelines to find out what they&#39;re doing?<br>
<div class=3D"im"><br>
&gt; I&#39;m pretty sure that it is because corrupted stated usually winds =
up in a<br>
&gt; system failure (such as access violation) which, these days, throws an=
<br>
&gt; exception, and the applications are structured to handle that. FWIW, I=
 can<br>
&gt; state that this is in fact the case of a few (not so popular) large<br=
>
&gt; applications I&#39;ve worked with and where I specifically took care o=
f that.<br>
<br>
</div>I&#39;d prefer a hard error over silent data corruption.<br></blockqu=
ote><div><br></div><div>But you don&#39;t have to choose between one and th=
e oher, that&#39;s the whole point. You can have as much of a &quot;hard er=
ror&quot; you would get with termination, then, throw *before the data corr=
uption* (as you would with a *pre*-condition check) to get the application =
any chance to recover.<br>

<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
Don&#39;t you agree that for a lot of programs aborting on assert failure<b=
r>
is perfectly fine?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div>A=
bsolutely. For a lot a programs, yes. For the majority of the programs, I&#=
39;d think not.<br><br></div><div>Best</div></div><br clear=3D"all"><br>-- =
<br>

Fernando Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.s=
cisoft-consulting.com">http://www.scisoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c2a8845d72e204db801a91--

.

--047d7b3441682e368b04db803c5f
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 29, 2013 at 5:14 AM, Andrzej Krzemienski <akrzemi1@gmail.com>wrote:

>
>
>> I would now add something else: would you think that the reason most
>> modern applications, I'm thinking of say, Excel, or Corel, or Firefox,
>> etc... don't suddently display an error and quit anymore, like they used to
>> do 20 years ago, it's because they are free from programming errors (i.e.
>> there are absolutely no  preconditions being violated)?
>>
>> I'm pretty sure that it is because corrupted stated usually winds up in a
>> system failure (such as access violation) which, these days, throws an
>> exception, and the applications are structured to handle that. FWIW, I can
>> state that this is in fact the case of a few (not so popular) large
>> applications I've worked with and where I specifically took care of that.
>>
>
> I guess different systems are subject to different expectations. You
> mention Excel, Corel and Firefox, and I trust you that the approach I call
> "keep running" guarantee is just the thing you need for these systems.
>
> Indeed. And I wouldn't be promoting throw on assert failure if what you
described where realistically feasable. It is possible, but there aren't
any tools in C++ itself to make that any easy.


> I spent a lot of time with the system that can be characterized as
> life-critical but not real-time. The program is making a decision whether
> an aircraft is allowed to take off based on how it has been loaded (with
> passengers, fuel, cargo). Making the wrong call can have disastrous
> consequences. On the other hand stopping the program has no serious
> consequences: you do the computation some time before the departure and
> even if the program is completely down, the users can do a similar
> computation manually on a sheet of paper or use another program.
>
> In case we detect an a bug, we do not want to take the chances of trying
> to throw and hoping (even with big confidence) that the bug will go away.
> We wouldn't even risk trying. On the other hand, program abort (with an
> apologize message) is the best possible indication to the client that the
> program has a bug and should not be trusted. It is not even clear if it is
> a good idea to restart it -- given that you know there is a bug in it
> (although clients still choose to restart).
>
> I completely understand this scenario.
It is however sufficiently uncommon to affect what the best default for
assertion failure is.



> In my team, the promotion of the "keep running" guarantee (picked up by
> some programmers) introduced an unnecessary safety bug to the program. I
> personally find it a harm -- in the context of our domain.
>
> And I'd say that you are totally correct, in the context of your domain.


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--047d7b3441682e368b04db803c5f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 29, 2013 at 5:14 AM, Andrzej Krzemienski <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a>&=
gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div class=3D"gmail_quote"><div><div cla=
ss=3D"h5"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><br></div><div>I would now add something else: would you think that the re=
ason most modern applications, I&#39;m thinking of say, Excel, or Corel, or=
 Firefox, etc... don&#39;t suddently display an error and quit anymore, lik=
e they used to do 20 years ago, it&#39;s because they are free from program=
ming errors (i.e. there are absolutely no=A0 preconditions being violated)?=
=A0 <br>




<br></div><div>I&#39;m pretty sure that it is because corrupted stated usua=
lly winds up in a system failure (such as access violation) which, these da=
ys, throws an exception, and the applications are structured to handle that=
.. FWIW, I can state that this is in fact the case of a few (not so popular)=
 large applications I&#39;ve worked with and where I specifically took care=
 of that. <br>


</div></div></div></div></blockquote></div></div><div><br>I guess different=
 systems are subject to different expectations. You mention Excel, Corel an=
d Firefox, and I trust you that the approach I call &quot;keep running&quot=
; guarantee is just the thing you need for these systems. <br>


<br></div></div></blockquote><div>Indeed. And I wouldn&#39;t be promoting t=
hrow on assert failure if what you described where realistically feasable. =
It is possible, but there aren&#39;t any tools in C++ itself to make that a=
ny easy.<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div=
>I spent a lot of time with the system that can be characterized as life-cr=
itical but not real-time. The program is making a decision whether an aircr=
aft is allowed to take off based on how it has been loaded (with passengers=
, fuel, cargo). Making the wrong call can have disastrous consequences. On =
the other hand stopping the program has no serious consequences: you do the=
 computation some time before the departure and even if the program is comp=
letely down, the users can do a similar computation manually on a sheet of =
paper or use another program.<br>


<br>In case we detect an a bug, we do not want to take the chances of tryin=
g to throw and hoping (even with big confidence) that the bug will go away.=
 We wouldn&#39;t even risk trying. On the other hand, program abort (with a=
n apologize message) is the best possible indication to the client that the=
 program has a bug and should not be trusted. It is not even clear if it is=
 a good idea to restart it -- given that you know there is a bug in it (alt=
hough clients still choose to restart). <br>


<br></div></div></blockquote><div>I completely understand this scenario.<br=
></div><div>It is however sufficiently uncommon to affect what the best def=
ault for assertion failure is.<br>=A0<br></div>=A0<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">

<div class=3D"gmail_quote"><div>In my team, the promotion of the &quot;keep=
 running&quot; guarantee (picked up by some programmers) introduced an unne=
cessary safety bug to the program. I personally find it a harm -- in the co=
ntext of our domain.<br>


<br></div></div></blockquote><div class=3D"h5">And I&#39;d say that you are=
 totally correct, in the context of your domain.<br>=A0 <br>
</div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br>=
<a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting=
..com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b3441682e368b04db803c5f--

.

--047d7b343baa7ba16504db80821d
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 29, 2013 at 7:27 AM, Giovanni Piero Deretta <gpderetta@gmail.com
> wrote:

> On Sunday, April 28, 2013 1:25:48 AM UTC+1, Fernando Cacciola wrote:
>>
>> On Sat, Apr 27, 2013 at 3:15 PM, Olaf van der Spek <olafv...@gmail.com>wrote:
>>
>>> On Sat, Apr 27, 2013 at 7:41 PM, Fernando Cacciola
>>> <fernando...@gmail.com> wrote:
>>> > In any case, the intention was to state that you either "get UB as it
>>> is
>>> > (not) defined" when building release, or get some behavior defined by
>>> the
>>> > implementation when you build debug. Olaf mentioned that this was a bad
>>> > idea. I think it's controversial but not neccesary bad, and it's common
>>> > practice
>>>
>>> The VC behaviour is fine, throwing a catchable exception (only in
>>> debug mode) isn't.
>>>
>>> > If there is going to be a fixed, non-customizable behavior, AND,
>>> provided
>>> > that assertions are also used in release builds, it should never abort
>>> but
>>> > throw instead (for the simple reason that with a throw you allow the
>>> > programmer to do something about it)
>>>
>>> Maybe some examples would help, I have no idea what you can do at
>>> run-time about it.
>>>
>>> Well, the simplest way to give you an example is to ask you to consider
>> other languages.
>> (AFAICT) C and by inhetritance, C++, are the only languages which abort
>> in case of a precondition violation.
>> Modern languages such as (just to name a few) C#, Java, Ruby/Python and
>> JavaScript all throw on errors, any kind of errors including programming
>> errors. None of them abort.
>>
>
> The key difference is that all those languages are memory safe. You cannot
> corrupt the stack, the memory arena or the general system integrity
>

I don't think I follow.

In any such language you can have, for example, a buffer overrun, just like
in C++. Well, no really, you can't, because the system performs a
range-check precondition and throws if you try to overrun, but that's the
mechanism that makes it "memory safe" and my point precisely is that I see
no reason for not doing exactly the same in C++, except performance.

In C# you can even corrupt the stack since it has stack variables just like
C/C++


> ; pointers are always either null or point to a valid allocated object;
> you can't write outside of objects
>

That's not entirely true.
You can dispose of an object (conceptually the same as destroying it), then
access it and even modify it.

Well, again, not really, but because the system has a precondition that
throws if it detects that the object has been disposed. So, again, the
"memory safety" is not the consequence of a different memory model, it is
the consequence of the heavy use of precondition checks and throwing in
case of failure.



> ; you can't forge pointers; as long as you do not export pointers to your
> data, you can always be reasonably sure that they won't be corrupted by
> other modules; the garbage collector will always be there to cleanup any
> mess. In practice there is always a minimum guaranteed state you can rely
> on. A program is at least capable of safely traverse a data structure and
> check its integrity.
>
> Right, but it is the use of (release mode included) preconditions and
throwing in response which gives you such a minimum guaranteed state, not
the use of a garbage-collector.

Some languages even let you partition the heap between modules, giving even
> strong guarantees (often in those languages asserts cause the whole module
> to be aborted and the recovery can be done only at partition boundaries,
> which IMHO is a good thing).
>
> In general you can't do that in C and C++, unless you rely on address
> space separation (which some programs which need very high reliability do).
>
> The bottom line is that in C++, if you get a failure in a precondition
> check, you can never be sure whether the cause is simply due to a simple
> programming error in the caller or a more general corruption of the system.
>
>
This last statement is my reason for this whole thread: that is just plain
untrue for a really large class of errors and for most applications. With
all due respect, it is IMHO a myth that people just keep repeating. My
experience with throwing as a response to failures of any kind, including
programming errors, largely shown (to me) otherwise.

>
I understand and accept the other reasons such as increased diagnosability,
or that for certain applications, keep-running is not that much important
so quiting it's fine, but I will insist in that aborting to avoid cascading
state corruption is just ungrounded.

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--047d7b343baa7ba16504db80821d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 29, 2013 at 7:27 AM, Giovanni Piero Deretta <span dir=3D"ltr">&lt;<=
a href=3D"mailto:gpderetta@gmail.com" target=3D"_blank">gpderetta@gmail.com=
</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Sunday, April 28, 2013 1:25:48 AM UTC+1, =
Fernando Cacciola 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"><div><div class=3D"gmail_quote"><div>On Sat, Apr 27, 2013 =
at 3:15 PM, Olaf van der Spek <span dir=3D"ltr">&lt;<a>olafv...@gmail.com</=
a>&gt;</span> wrote:<br>

</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>On Sat, A=
pr 27, 2013 at 7:41 PM, Fernando Cacciola<br></div><div>

&lt;<a>fernando...@gmail.com</a>&gt; wrote:<br>
&gt; In any case, the intention was to state that you either &quot;get UB a=
s it is<br>
&gt; (not) defined&quot; when building release, or get some behavior define=
d by the<br>
&gt; implementation when you build debug. Olaf mentioned that this was a ba=
d<br>
&gt; idea. I think it&#39;s controversial but not neccesary bad, and it&#39=
;s common<br>
&gt; practice<br>
<br>
</div></div><div>The VC behaviour is fine, throwing a catchable exception (=
only in<br>
debug mode) isn&#39;t.<br>
<div><br>
&gt; If there is going to be a fixed, non-customizable behavior, AND, provi=
ded<br>
&gt; that assertions are also used in release builds, it should never abort=
 but<br>
&gt; throw instead (for the simple reason that with a throw you allow the<b=
r>
&gt; programmer to do something about it)<br>
<br>
</div>Maybe some examples would help, I have no idea what you can do at<br>
run-time about it.<br>
<div><div><br></div></div></div></blockquote><div><div>Well, the simplest w=
ay to give you an example is to ask you to consider other languages.<br></d=
iv><div>(AFAICT) C and by inhetritance, C++, are the only languages which a=
bort in case of a precondition violation.<br>




</div><div>Modern languages such as (just to name a few) C#, Java, Ruby/Pyt=
hon and JavaScript all throw on errors, any kind of errors including progra=
mming errors. None of them abort.<br></div></div></div></div></div></blockq=
uote>


<div><br>The key difference is that all those languages are memory safe. Yo=
u cannot corrupt the stack, the memory arena or the general system integrit=
y</div></blockquote><div><br></div><div>I don&#39;t think I follow.<br>


<br></div><div>In any such language you can have, for example, a buffer ove=
rrun, just like in C++. Well, no really, you can&#39;t, because the system =
performs a range-check precondition and throws if you try to overrun, but t=
hat&#39;s the mechanism that makes it &quot;memory safe&quot; and my point =
precisely is that I see no reason for not doing exactly the same in C++, ex=
cept performance.<br>


<br></div><div>In C# you can even corrupt the stack since it has stack vari=
ables just like C/C++<br></div><div>=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>

<div>; pointers are always either null or point to a valid allocated object=
; you can&#39;t write outside of objects</div>
</blockquote><div><br></div><div>That&#39;s not entirely true.<br></div><di=
v>You can dispose of an object (conceptually the same as destroying it), th=
en access it and even modify it.<br><br></div><div>Well, again, not really,=
 but because the system has a precondition that throws if it detects that t=
he object has been disposed. So, again, the &quot;memory safety&quot; is no=
t the consequence of a different memory model, it is the consequence of the=
 heavy use of precondition checks and throwing in case of failure.<br>


</div><div><br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>; you can&#39;t=
 forge pointers; as long as you do not export pointers to your data, you ca=
n always be reasonably sure that they won&#39;t be corrupted by other modul=
es; the garbage collector will always be there to cleanup any mess. In prac=
tice there is always a minimum guaranteed state you can rely on. A program =
is at least capable of safely traverse a data structure and check its integ=
rity. <br>


<br></div></blockquote><div>Right, but it is the use of (release mode inclu=
ded) preconditions and throwing in response which gives you such a minimum =
guaranteed state, not the use of a garbage-collector.<br><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">


<div>Some languages even let you partition the heap between modules, giving=
 even strong guarantees (often in those languages asserts cause the whole m=
odule to be aborted and the recovery can be done only at partition boundari=
es, which IMHO is a good thing).<br>


<br>In general you can&#39;t do that in C and C++, unless you rely on addre=
ss space separation (which some programs which need very high reliability d=
o).<br>=A0<br>The bottom line is that in C++, if you get a failure in a pre=
condition check, you can never be sure whether the cause is simply due to a=
 simple programming error in the caller or a more general corruption of the=
 system.<span><font color=3D"#888888"><br>


</font></span></div><span><font color=3D"#888888"><br></font></span></block=
quote><div><br></div><div>This last statement is my reason for this whole t=
hread: that is just plain untrue for a really large class of errors and for=
 most applications. With all due respect, it is IMHO a myth that people jus=
t keep repeating. My experience with throwing as a response to failures of =
any kind, including programming errors, largely shown (to me) otherwise.<br=
>


</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span></span></blockquote></div><br></=
div><div class=3D"gmail_extra">I understand and accept the other reasons su=
ch as increased diagnosability, or that for certain applications, keep-runn=
ing is not that much important so quiting it&#39;s fine, but I will insist =
in that aborting to avoid cascading state corruption is just ungrounded.<br=
 clear=3D"all">


</div><div class=3D"gmail_extra"><br>-- <br>Fernando Cacciola<br>SciSoft Co=
nsulting, Founder<br><a href=3D"http://www.scisoft-consulting.com" target=
=3D"_blank">http://www.scisoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b343baa7ba16504db80821d--

.

------=_Part_121_20248224.1367245226009
Content-Type: text/plain; charset=ISO-8859-1

On Monday, April 29, 2013 2:54:38 PM UTC+1, Fernando Cacciola wrote:
>
> On Mon, Apr 29, 2013 at 5:14 AM, Andrzej Krzemienski <akrz...@gmail.com<javascript:>
> > wrote:
>
>>
>>
>>> I would now add something else: would you think that the reason most
>>> modern applications, I'm thinking of say, Excel, or Corel, or Firefox,
>>> etc... don't suddently display an error and quit anymore, like they used to
>>> do 20 years ago, it's because they are free from programming errors (i.e.
>>> there are absolutely no  preconditions being violated)?
>>>
>>> I'm pretty sure that it is because corrupted stated usually winds up in
>>> a system failure (such as access violation) which, these days, throws an
>>> exception, and the applications are structured to handle that. FWIW, I can
>>> state that this is in fact the case of a few (not so popular) large
>>> applications I've worked with and where I specifically took care of that.
>>>
>>
>> I guess different systems are subject to different expectations. You
>> mention Excel, Corel and Firefox, and I trust you that the approach I call
>> "keep running" guarantee is just the thing you need for these systems.
>>
>> Indeed. And I wouldn't be promoting throw on assert failure if what you
> described where realistically feasable. It is possible, but there aren't
> any tools in C++ itself to make that any easy.
>
>

Actually, I bet that at least Excel and Firefox do abort on precondition
failure. It is just that those checks may be compiled out in release
binaries. In fact even on normal builds, you can still sometime have those
programs die on you!

What those two programs do have is the ability to recover from the last
known good state upon restart, plus the ability to send home (the moral
equivalent of) the memory dump for debugging.

In fact those programs are good example of the kind of programs I would
like to fail-fast on error. Do you really want to spend hours debugging a
complex Excel table that has been corrupted by some errors? Are you sure
that the precondition failure in Firefox was a simple programming error and
not the symptom of a malicious web page attempt to exploit some
vulnerability?

-- gpd

--

---
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/?hl=en.



------=_Part_121_20248224.1367245226009
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Monday, April 29, 2013 2:54:38 PM UTC+1, Fernando Cacciola wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"g=
mail_quote">On Mon, Apr 29, 2013 at 5:14 AM, Andrzej Krzemienski <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"wLfD6CSgL9kJ">akrz...@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div class=3D"gmail_quote"><div><div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>I woul=
d now add something else: would you think that the reason most modern appli=
cations, I'm thinking of say, Excel, or Corel, or Firefox, etc... don't sud=
dently display an error and quit anymore, like they used to do 20 years ago=
, it's because they are free from programming errors (i.e. there are absolu=
tely no&nbsp; preconditions being violated)?&nbsp; <br>




<br></div><div>I'm pretty sure that it is because corrupted stated usually =
winds up in a system failure (such as access violation) which, these days, =
throws an exception, and the applications are structured to handle that. FW=
IW, I can state that this is in fact the case of a few (not so popular) lar=
ge applications I've worked with and where I specifically took care of that=
.. <br>


</div></div></div></div></blockquote></div></div><div><br>I guess different=
 systems are subject to different expectations. You mention Excel, Corel an=
d Firefox, and I trust you that the approach I call "keep running" guarante=
e is just the thing you need for these systems. <br>


<br></div></div></blockquote><div>Indeed. And I wouldn't be promoting throw=
 on assert failure if what you described where realistically feasable. It i=
s possible, but there aren't any tools in C++ itself to make that any easy.=
<br>

&nbsp;<br></div></div></div></div></blockquote><div><br>Actually, I bet tha=
t at least Excel and Firefox do abort on precondition failure. It is just t=
hat those checks may be compiled out in release binaries. In fact even on n=
ormal builds, you can still sometime have those programs die on you! <br><b=
r>What those two programs do have is the ability to recover from the last k=
nown good state upon restart, plus the ability to send home (the moral equi=
valent of) the memory dump for debugging. <br><br>In fact those programs ar=
e good example of the kind of programs I would like to fail-fast on error. =
Do you really want to spend hours debugging a complex Excel table that has =
been corrupted by some errors? Are you sure that the precondition failure i=
n Firefox was a simple programming error and not the symptom of a malicious=
 web page attempt to exploit some vulnerability?<br><br>-- gpd<br></div><br=
>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_121_20248224.1367245226009--

.

--047d7b2e0887d321d904db80965a
Content-Type: text/plain; charset=ISO-8859-1

On 29 April 2013 17:14, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:

> The bottom line is that in C++, if you get a failure in a precondition
> check, you can never be sure whether the cause is simply due to a simple
> programming error in the caller or a more general corruption of the system.
>
> This last statement is my reason for this whole thread: that is just plain
> untrue for a really large class of errors and for most applications. With
> all due respect, it is IMHO a myth that people just keep repeating. My
> experience with throwing as a response to failures of any kind, including
> programming errors, largely shown (to me) otherwise.
>
>>
>
For what it's worth, I completely agree. As mentioned previously, I have
seen many cases where aborting is a good
thing. I have seen at least an equal amount of cases where a throw might
have been preferable, and it slightly
depends on whether you're in a debugger (why did this PoS abort? whyyy?!
why couldn't the author allow upper
layers a chance to recover?) or analysing things post mortem (why doesn't
this PoS abort when it goes crazy? whyyy?!
why couldn't the author allow sensible post-mortem analysis?). NEITHER
approach works for all cases, and it's
of paramount importance to give library/middleware authors the tools they
can use to choose the right approach
for their problem domain.



> I understand and accept the other reasons such as increased
> diagnosability, or that for certain applications, keep-running is not that
> much important so quiting it's fine, but I will insist in that aborting to
> avoid cascading state corruption is just ungrounded.
>
>
>
Sometimes is, sometimes isn't. ;)

--

---
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/?hl=en.



--047d7b2e0887d321d904db80965a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 April 2013 17:14, Fernando Cacciola <span dir=3D"ltr">&lt;<a =
href=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacc=
iola@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">The bottom line is that in C++, if you get a fai=
lure in a precondition check, you can never be sure whether the cause is si=
mply due to a simple programming error in the caller or a more general corr=
uption of the system.<span><font color=3D"#888888"><br>



</font></span><div class=3D"im"><div><br></div></div><div>This last stateme=
nt is my reason for this whole thread: that is just plain untrue for a real=
ly large class of errors and for most applications. With all due respect, i=
t is IMHO a myth that people just keep repeating. My experience with throwi=
ng as a response to failures of any kind, including programming errors, lar=
gely shown (to me) otherwise.<br>



</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span></span></blockquote></div><br></=
div></div></blockquote><div><br></div><div>For what it&#39;s worth, I compl=
etely agree. As mentioned previously, I have seen many cases where aborting=
 is a good<br>
</div><div>thing. I have seen at least an equal amount of cases where a thr=
ow might have been preferable, and it slightly<br>depends on whether you&#3=
9;re in a debugger (why did this PoS abort? whyyy?! why couldn&#39;t the au=
thor allow upper<br>
layers a chance to recover?) or analysing things post mortem (why doesn&#39=
;t this PoS abort when it goes crazy? whyyy?!<br>why couldn&#39;t the autho=
r allow sensible post-mortem analysis?). NEITHER approach works for all cas=
es, and it&#39;s<br>
of paramount importance to give library/middleware authors the tools they c=
an use to choose the right approach<br>for their problem domain.<br><br>=A0=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"></div><div class=3D"gmail_extra=
">I understand and accept the other reasons such as increased diagnosabilit=
y, or that for certain applications, keep-running is not that much importan=
t so quiting it&#39;s fine, but I will insist in that aborting to avoid cas=
cading state corruption is just ungrounded.<br clear=3D"all">



</div><div class=3D"im"><div class=3D"gmail_extra"><br><br></div></div></di=
v></blockquote><div><br></div><div>Sometimes is, sometimes isn&#39;t. ;)=A0=
 <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b2e0887d321d904db80965a--

.

--047d7bd6c2e40a205e04db80b117
Content-Type: text/plain; charset=ISO-8859-1

On 28 April 2013 04:40, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> I'd prefer a hard error over silent data corruption.
>

This is, of course, the crux of the matter.  The rest is pretty much
handwaving that throwing allows you to recover from the data corruption.
To be fair, it probably "works" 99% of the time.  But can you afford the
result of the 1%?

I worked at a place which thought that.  Well, at least until bad error
recovery resulted in my management getting fired and us pulling our main
product out of the market for a year and a half.


> Don't you agree that for a lot of programs aborting on assert failure
> is perfectly fine?


I just don't see the other side of that coin.  How can you any risk
analysis if you cannot reason about either the root cause of the
programming error you detected or the state your program is in after you've
detected the error?


But we are just going around in circles.  What does that exactly have to do
with the standard?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/?hl=en.



--047d7bd6c2e40a205e04db80b117
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 28 April 2013 04:40, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=3D"=
mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>&gt;=
</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>

I&#39;d prefer a hard error over silent data corruption.<br></blockquote><d=
iv><br>This is, of course, the crux of the matter.=A0 The rest is pretty mu=
ch handwaving that throwing allows you to recover from the data corruption.=
=A0 To be fair, it probably &quot;works&quot; 99% of the time.=A0 But can y=
ou afford the result of the 1%?<br>

<br>I worked at a place which thought that.=A0 Well, at least until bad err=
or recovery resulted in my management getting fired and us pulling our main=
 product out of the market for a year and a half.<br>=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">


Don&#39;t you agree that for a lot of programs aborting on assert failure<b=
r>
is perfectly fine?</blockquote></div><br>I just don&#39;t see the other sid=
e of that coin.=A0 How can you any risk analysis if you cannot reason about=
 either the root cause of the programming error you detected or the state y=
our program is in after you&#39;ve detected the error?<br clear=3D"all">

<br><br>But we are just going around in circles.=A0 What does that exactly =
have to do with the standard?<br>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &=
lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin=
@eviloverlord.com</a>&gt;=A0 (847) 691-1404

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bd6c2e40a205e04db80b117--

.

------=_Part_2508_25800044.1367246374031
Content-Type: text/plain; charset=ISO-8859-1

On Monday, April 29, 2013 3:14:18 PM UTC+1, Fernando Cacciola wrote:
>
> On Mon, Apr 29, 2013 at 7:27 AM, Giovanni Piero Deretta <gpde...@gmail.com<javascript:>
> > wrote:
>
>> On Sunday, April 28, 2013 1:25:48 AM UTC+1, Fernando Cacciola wrote:
>>>
>>> On Sat, Apr 27, 2013 at 3:15 PM, Olaf van der Spek <olafv...@gmail.com>wrote:
>>>
>>>> On Sat, Apr 27, 2013 at 7:41 PM, Fernando Cacciola
>>>> <fernando...@gmail.com> wrote:
>>>> > In any case, the intention was to state that you either "get UB as it
>>>> is
>>>> > (not) defined" when building release, or get some behavior defined by
>>>> the
>>>> > implementation when you build debug. Olaf mentioned that this was a
>>>> bad
>>>> > idea. I think it's controversial but not neccesary bad, and it's
>>>> common
>>>> > practice
>>>>
>>>> The VC behaviour is fine, throwing a catchable exception (only in
>>>> debug mode) isn't.
>>>>
>>>> > If there is going to be a fixed, non-customizable behavior, AND,
>>>> provided
>>>> > that assertions are also used in release builds, it should never
>>>> abort but
>>>> > throw instead (for the simple reason that with a throw you allow the
>>>> > programmer to do something about it)
>>>>
>>>> Maybe some examples would help, I have no idea what you can do at
>>>> run-time about it.
>>>>
>>>> Well, the simplest way to give you an example is to ask you to consider
>>> other languages.
>>> (AFAICT) C and by inhetritance, C++, are the only languages which abort
>>> in case of a precondition violation.
>>> Modern languages such as (just to name a few) C#, Java, Ruby/Python and
>>> JavaScript all throw on errors, any kind of errors including programming
>>> errors. None of them abort.
>>>
>>
>> The key difference is that all those languages are memory safe. You
>> cannot corrupt the stack, the memory arena or the general system integrity
>>
>
> I don't think I follow.
>
> In any such language you can have, for example, a buffer overrun, just
> like in C++. Well, no really, you can't, because the system performs a
> range-check precondition and throws if you try to overrun, but that's the
> mechanism that makes it "memory safe" and my point precisely is that I see
> no reason for not doing exactly the same in C++, except performance.
>

It is not just precondition checking. The runtime itself, which is separate
and isolated from the application guarantees memory safety (and provably
so, for many VM). In practice (with the exception of region based type
systems like Cyclone or Rust), you need a GC. How would you write a
precondition that verifies that a pointer points to a valid non-freed value
in C++?

BTW, it is quite likely possible to write a memory safe implementation of
C++, but the overhead is probably going to be quite large and it would
disallow many common idioms.


>
> In C# you can even corrupt the stack since it has stack variables just
> like C/C++
>

That does not follow. I'm pretty sure you can't corrupt the stack in C#
outside of an unsafe block.


>
>
>> ; pointers are always either null or point to a valid allocated object;
>> you can't write outside of objects
>>
>
> That's not entirely true.
> You can dispose of an object (conceptually the same as destroying it),
> then access it and even modify it.
>

They are conceptually the same in C++. On "managed" languages, the reality
is that often invariants are necessarily less strong than in C++ and the
set of valid states for an object is pretty much all possible values of its
field. Think for example of the way that Java allows virtual functions to
retain their polymorphic behaviour in constructors.

The bottom line is that in C++, if you get a failure in a precondition
check, you can never be sure whether the cause is simply due to a simple
programming error in the caller or a more general corruption of the system.

-- gpd

--

---
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/?hl=en.



------=_Part_2508_25800044.1367246374031
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Monday, April 29, 2013 3:14:18 PM UTC+1, Fernando Cacciola wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"g=
mail_quote">On Mon, Apr 29, 2013 at 7:27 AM, Giovanni Piero Deretta <span d=
ir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"n0dNAiD5b64J">gpde...@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Sunday, April 28, 2013 1:25:48 AM UTC+1, =
Fernando Cacciola 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"><div><div class=3D"gmail_quote"><div>On Sat, Apr 27, 2013 =
at 3:15 PM, Olaf van der Spek <span dir=3D"ltr">&lt;<a>olafv...@gmail.com</=
a>&gt;</span> wrote:<br>

</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>On Sat, A=
pr 27, 2013 at 7:41 PM, Fernando Cacciola<br></div><div>

&lt;<a>fernando...@gmail.com</a>&gt; wrote:<br>
&gt; In any case, the intention was to state that you either "get UB as it =
is<br>
&gt; (not) defined" when building release, or get some behavior defined by =
the<br>
&gt; implementation when you build debug. Olaf mentioned that this was a ba=
d<br>
&gt; idea. I think it's controversial but not neccesary bad, and it's commo=
n<br>
&gt; practice<br>
<br>
</div></div><div>The VC behaviour is fine, throwing a catchable exception (=
only in<br>
debug mode) isn't.<br>
<div><br>
&gt; If there is going to be a fixed, non-customizable behavior, AND, provi=
ded<br>
&gt; that assertions are also used in release builds, it should never abort=
 but<br>
&gt; throw instead (for the simple reason that with a throw you allow the<b=
r>
&gt; programmer to do something about it)<br>
<br>
</div>Maybe some examples would help, I have no idea what you can do at<br>
run-time about it.<br>
<div><div><br></div></div></div></blockquote><div><div>Well, the simplest w=
ay to give you an example is to ask you to consider other languages.<br></d=
iv><div>(AFAICT) C and by inhetritance, C++, are the only languages which a=
bort in case of a precondition violation.<br>




</div><div>Modern languages such as (just to name a few) C#, Java, Ruby/Pyt=
hon and JavaScript all throw on errors, any kind of errors including progra=
mming errors. None of them abort.<br></div></div></div></div></div></blockq=
uote>


<div><br>The key difference is that all those languages are memory safe. Yo=
u cannot corrupt the stack, the memory arena or the general system integrit=
y</div></blockquote><div><br></div><div>I don't think I follow.<br>


<br></div><div>In any such language you can have, for example, a buffer ove=
rrun, just like in C++. Well, no really, you can't, because the system perf=
orms a range-check precondition and throws if you try to overrun, but that'=
s the mechanism that makes it "memory safe" and my point precisely is that =
I see no reason for not doing exactly the same in C++, except performance.<=
br></div></div></div></div></blockquote><div><br>It is not just preconditio=
n checking. The runtime itself, which is separate and isolated from the app=
lication guarantees memory safety (and provably so, for many VM). In practi=
ce (with the exception of region based type systems like Cyclone or Rust), =
you need a GC. How would you write a precondition that verifies that a poin=
ter points to a valid non-freed value in C++?<br><br>BTW, it is quite likel=
y possible to write a memory safe implementation of C++, but the overhead i=
s probably going to be quite large and it would disallow many common idioms=
..<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><div>


<br></div><div>In C# you can even corrupt the stack since it has stack vari=
ables just like C/C++<br></div></div></div></div></blockquote><div><br>That=
 does not follow. I'm pretty sure you can't corrupt the stack in C# outside=
 of an unsafe block.<br>&nbsp;</div><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><div class=3D"gmail_quote"><div></div><div>&nbs=
p;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">

<div>; pointers are always either null or point to a valid allocated object=
; you can't write outside of objects</div>
</blockquote><div><br></div><div>That's not entirely true.<br></div><div>Yo=
u can dispose of an object (conceptually the same as destroying it), then a=
ccess it and even modify it.<br></div></div></div></div></blockquote><div><=
br>They are conceptually the same in C++. On "managed" languages, the reali=
ty is that often invariants are necessarily less strong than in C++ and the=
 set of valid states for an object is pretty much all possible values of it=
s field. Think for example of the way that Java allows virtual functions to=
 retain their polymorphic behaviour in constructors.<br> <br>The bottom lin=
e is that in C++, if you get a failure in a precondition check, you can nev=
er be sure whether the cause is simply due to a simple programming error in=
 the caller or a more general corruption of the system.<span></span></div><=
br>-- gpd<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2508_25800044.1367246374031--

.

On 4/29/13, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 28 April 2013, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> > I'd prefer a hard error over silent data corruption.
>
> This is, of course, the crux of the matter.  The rest is pretty
> much handwaving that throwing allows you to recover from the data
> corruption.  To be fair, it probably "works" 99% of the time.
> But can you afford the result of the 1%?
>
> I worked at a place which thought that.  Well, at least until
> bad error recovery resulted in my management getting fired and us
> pulling our main product out of the market for a year and a half.
>
> > Don't you agree that for a lot of programs aborting on assert
> > failure is perfectly fine?
>
> I just don't see the other side of that coin.  How can you any
> risk analysis if you cannot reason about either the root cause
> of the programming error you detected or the state your program
> is in after you've detected the error?
>
> But we are just going around in circles.  What does that exactly
> have to do with the standard?

Exceptions are good for handling conditions that are rare but
reasonable.  For example, memory allocation failure is (presumably)
rare, but it can reasonably happen.  The exception mechanism enables
us to handle such rare events in a few code locations, rather than
all throughout the code.  We need the behavior of our program to
be fully defined while handling such events.

In contrast, where the standard says "doing X has undefined behavior"
it means "the program doing X is erroneous and the standard does not
define the behavior of erroneous programs".  Failing an assertion
says "the program is erroneous".

When we detect erroneous behavior, we do not want to a-priori throw
an exception for several reasons.

* Doing so turns an undefined behavior into a defined behavior.
That is, programmers could deliberately violate the assertion in
order to generate an exception.  It is bad engineering, but would
still be conforming.  More insidiously, one can never fix code to
avoid errors because then they would cease to throw exceptions.

* Erroneous programs are erroneous when written, not when run.
It is possible to do static analysis and reject the program.
But if the erroneous bit means "throw", we cannot do so.

* If an assertion is defined to throw, then we can no longer
invoke the debugger on dynamically detecting erroneous behavior.
We must throw to match the defined behavior.

* Programs that are not erroneous are more optimizable.  E.g.,
if I have an assertion p!=NULL, then the compiler can propogate
that knowledge through the code to eliminate subsequent tests for
NULL in the code.

We really want erroneous programs to have undefined behavior
because that gives us the best hope for making the code better.

However, erroneous programs may still interact with the real world.
We want most, if not all, of our systems to recover from erroneous
programs.  We can recover externally.  E.g. compiler front ends can
abort on error and rely on the compiler driver to delete partially
built object files.  To recover internally, we need some mechanism
to run code after detecting erroneous behavior.  We also need to
reserve that mechanism to the final application developer, but cause
only then is the recovery task completely knowable.  My opinion is
that the termination handler (for example) is a better mechanism
than exceptions.  Even so, it is important to remember that any
code run in a termination handler is still undefined, the system
is doing "best effort" to help recovery.  That effort may include
invoking the debugger when the program's execution is being piloted
by the programmer.

I would like to see the standard support the notion of erroneous
behavior and programs more directly.  Assertion violations are one
more way to specify when programs are erroneous.

--
Lawrence Crowl

--

---
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/?hl=en.



.

--047d7b3441fe7ff5cd04db8664e7
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 29, 2013 at 10:14 AM, Fernando Cacciola <
fernando.cacciola@gmail.com> wrote:

> I don't think I follow.
>
> In any such language you can have, for example, a buffer overrun, just
> like in C++. Well, no really, you can't, because the system performs a
> range-check precondition and throws if you try to overrun, but that's the
> mechanism that makes it "memory safe" and my point precisely is that I see
> no reason for not doing exactly the same in C++, except performance.
>
> In C# you can even corrupt the stack since it has stack variables just
> like C/C++
>
>
>> ; pointers are always either null or point to a valid allocated object;
>> you can't write outside of objects
>>
>
> That's not entirely true.
> You can dispose of an object (conceptually the same as destroying it),
> then access it and even modify it.
>
> Well, again, not really, but because the system has a precondition that
> throws if it detects that the object has been disposed. So, again, the
> "memory safety" is not the consequence of a different memory model, it is
> the consequence of the heavy use of precondition checks and throwing in
> case of failure.
>
>
> Right, but it is the use of (release mode included) preconditions and
> throwing in response which gives you such a minimum guaranteed state, not
> the use of a garbage-collector.
>
>
>> The bottom line is that in C++, if you get a failure in a precondition
>> check, you can never be sure whether the cause is simply due to a simple
>> programming error in the caller or a more general corruption of the system.
>>
>>
> This last statement is my reason for this whole thread: that is just plain
> untrue for a really large class of errors and for most applications. With
> all due respect, it is IMHO a myth that people just keep repeating. My
> experience with throwing as a response to failures of any kind, including
> programming errors, largely shown (to me) otherwise.
>
>>
> I understand and accept the other reasons such as increased
> diagnosability, or that for certain applications, keep-running is not that
> much important so quiting it's fine, but I will insist in that aborting to
> avoid cascading state corruption is just ungrounded.
>
>
So that I understand:

Is your position that

A.1) - an assert fires before "corruption"?
A.2) - before "there is a problem"?

Because obviously there is a problem, else the assert wouldn't fire.  How
do we know whether the problem was caught soon enough?

Is your position more like:

B) - if you assert *enough*, then you will catch problems early enough that
nothing has really gone wrong yet.  (Still, obviously something has gone
wrong...) But no "harm" yet.  ie at least assert, say, before writing
anything.  (I guess this is similar to A.1 - before corruption)


I want to be clear, because I think that is where opinions differ.  I think
many people consider an assert to mean some code was broken, therefore you
can't be sure that the code didn't already cause corruption (ie it is bad
code, therefore maybe it was lax on asserting when it should have).

Or is your opinion of the form:

C) in reality, throwing typically works


I somewhat share the opinion of C - because _typically_ the program *was*
in a valid state just a moment ago.  And *IF* you assert enough, it hasn't
gone far from that state before you catch the bug.  Throwing to roll things
back typically gets you back to that valid state. (Transactional memory
might be nice here!).

But this requires lots of asserts, and it is hard to doubt the logic of "an
assert fired, therefore the calling code is wrong, therefore why do you
think the calling code didn't already break things"...

Basically, Why do you think asserts catch things early enough?

---

P.S. Beyond that, if you throw only in debug, and someone writes code to
catch that exception and do something special, you can end up writing a
program that *only* works in debug... :-(

Tony

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--047d7b3441fe7ff5cd04db8664e7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote">On Mon, Apr 29, 2013 at 10:14 AM, Fernando Cacciola <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">ferna=
ndo.cacciola@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">I don&#39;t think I follow.<br><div>


<br></div><div>In any such language you can have, for example, a buffer ove=
rrun, just like in C++. Well, no really, you can&#39;t, because the system =
performs a range-check precondition and throws if you try to overrun, but t=
hat&#39;s the mechanism that makes it &quot;memory safe&quot; and my point =
precisely is that I see no reason for not doing exactly the same in C++, ex=
cept performance.<br>



<br></div><div>In C# you can even corrupt the stack since it has stack vari=
ables just like C/C++<br></div><div class=3D"im"><div>=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">


<div>; pointers are always either null or point to a valid allocated object=
; you can&#39;t write outside of objects</div>
</blockquote><div><br></div></div><div>That&#39;s not entirely true.<br></d=
iv><div>You can dispose of an object (conceptually the same as destroying i=
t), then access it and even modify it.<br><br></div><div>Well, again, not r=
eally, but because the system has a precondition that throws if it detects =
that the object has been disposed. So, again, the &quot;memory safety&quot;=
 is not the consequence of a different memory model, it is the consequence =
of the heavy use of precondition checks and throwing in case of failure.<br=
>



</div><div class=3D"im"><div>=A0</div><br></div><div>Right, but it is the u=
se of (release mode included) preconditions and throwing in response which =
gives you such a minimum guaranteed state, not the use of a garbage-collect=
or.<br>
<br></div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>=A0<br>The bottom line is that in C++, if you get a failure in a preco=
ndition check, you can never be sure whether the cause is simply due to a s=
imple programming error in the caller or a more general corruption of the s=
ystem.<span><font color=3D"#888888"><br>



</font></span></div><span><font color=3D"#888888"><br></font></span></block=
quote><div><br></div></div><div>This last statement is my reason for this w=
hole thread: that is just plain untrue for a really large class of errors a=
nd for most applications. With all due respect, it is IMHO a myth that peop=
le just keep repeating. My experience with throwing as a response to failur=
es of any kind, including programming errors, largely shown (to me) otherwi=
se.<br>



</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span></span></blockquote></div><br></=
div><div class=3D"gmail_extra">I understand and accept the other reasons su=
ch as increased diagnosability, or that for certain applications, keep-runn=
ing is not that much important so quiting it&#39;s fine, but I will insist =
in that aborting to avoid cascading state corruption is just ungrounded.<br=
 clear=3D"all">



</div><div class=3D"im"><div class=3D"gmail_extra"><br></div></div></div></=
blockquote></div><br></div><div class=3D"gmail_extra">So that I understand:=
<br><br></div><div class=3D"gmail_extra">Is your position that <br><br>A.1)=
 - an assert fires before &quot;corruption&quot;?<br>
A.2) - before &quot;there is a problem&quot;?<br><br></div><div class=3D"gm=
ail_extra">Because obviously there is a problem, else the assert wouldn&#39=
;t fire.=A0 How do we know whether the problem was caught soon enough?<br><=
br>
</div><div class=3D"gmail_extra">Is your position more like:<br><br></div><=
div class=3D"gmail_extra">B) - if you assert *enough*, then you will catch =
problems early enough that nothing has really gone wrong yet.=A0 (Still, ob=
viously something has gone wrong...) But no &quot;harm&quot; yet.=A0 ie at =
least assert, say, before writing anything.=A0 (I guess this is similar to =
A.1 - before corruption)<br>
<br><br></div><div class=3D"gmail_extra">I want to be clear, because I thin=
k that is where opinions differ.=A0 I think many people consider an assert =
to mean some code was broken, therefore you can&#39;t be sure that the code=
 didn&#39;t already cause corruption (ie it is bad code, therefore maybe it=
 was lax on asserting when it should have).<br>
<br></div><div class=3D"gmail_extra">Or is your opinion of the form:<br><br=
>C) in reality, throwing typically works<br><br></div><div class=3D"gmail_e=
xtra"><br></div><div class=3D"gmail_extra">I somewhat share the opinion of =
C - because _typically_ the program *was* in a valid state just a moment ag=
o.=A0 And *IF* you assert enough, it hasn&#39;t gone far from that state be=
fore you catch the bug.=A0 Throwing to roll things back typically gets you =
back to that valid state. (Transactional memory might be nice here!).<br>
<br></div><div class=3D"gmail_extra">But this requires lots of asserts, and=
 it is hard to doubt the logic of &quot;an assert fired, therefore the call=
ing code is wrong, therefore why do you think the calling code didn&#39;t a=
lready break things&quot;... <br>
<br>Basically, Why do you think asserts catch things early enough?<br></div=
><br>---<br><br></div>P.S. Beyond that, if you throw only in debug, and som=
eone writes code to catch that exception and do something special, you can =
end up writing a program that *only* works in debug... :-(<br>
<br></div>Tony<br><div><div><div class=3D"gmail_extra"><br></div></div></di=
v></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b3441fe7ff5cd04db8664e7--

.

--001a11c2a884c44d1104db872287
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 29, 2013 at 6:16 PM, Tony V E <tvaneerd@gmail.com> wrote:

> On Mon, Apr 29, 2013 at 10:14 AM, Fernando Cacciola <
> fernando.cacciola@gmail.com> wrote:
>
>> I don't think I follow.
>>
>> In any such language you can have, for example, a buffer overrun, just
>> like in C++. Well, no really, you can't, because the system performs a
>> range-check precondition and throws if you try to overrun, but that's the
>> mechanism that makes it "memory safe" and my point precisely is that I see
>> no reason for not doing exactly the same in C++, except performance.
>>
>> In C# you can even corrupt the stack since it has stack variables just
>> like C/C++
>>
>>
>>> ; pointers are always either null or point to a valid allocated object;
>>> you can't write outside of objects
>>>
>>
>> That's not entirely true.
>> You can dispose of an object (conceptually the same as destroying it),
>> then access it and even modify it.
>>
>> Well, again, not really, but because the system has a precondition that
>> throws if it detects that the object has been disposed. So, again, the
>> "memory safety" is not the consequence of a different memory model, it is
>> the consequence of the heavy use of precondition checks and throwing in
>> case of failure.
>>
>>
>> Right, but it is the use of (release mode included) preconditions and
>> throwing in response which gives you such a minimum guaranteed state, not
>> the use of a garbage-collector.
>>
>>
>>>
>>> The bottom line is that in C++, if you get a failure in a precondition
>>> check, you can never be sure whether the cause is simply due to a simple
>>> programming error in the caller or a more general corruption of the system.
>>>
>>>
>> This last statement is my reason for this whole thread: that is just
>> plain untrue for a really large class of errors and for most applications.
>> With all due respect, it is IMHO a myth that people just keep repeating. My
>> experience with throwing as a response to failures of any kind, including
>> programming errors, largely shown (to me) otherwise.
>>
>>>
>> I understand and accept the other reasons such as increased
>> diagnosability, or that for certain applications, keep-running is not that
>> much important so quiting it's fine, but I will insist in that aborting to
>> avoid cascading state corruption is just ungrounded.
>>
>>
> So that I understand:
>
> Is your position that
>
> A.1) - an assert fires before "corruption"?
> A.2) - before "there is a problem"?
>
> Because obviously there is a problem, else the assert wouldn't fire.  How
> do we know whether the problem was caught soon enough?
>
> Is your position more like:
>
> B) - if you assert *enough*, then you will catch problems early enough
> that nothing has really gone wrong yet.  (Still, obviously something has
> gone wrong...) But no "harm" yet.  ie at least assert, say, before writing
> anything.  (I guess this is similar to A.1 - before corruption)
>
>
> I want to be clear, because I think that is where opinions differ.  I
> think many people consider an assert to mean some code was broken,
> therefore you can't be sure that the code didn't already cause corruption
> (ie it is bad code, therefore maybe it was lax on asserting when it should
> have).
>
> Or is your opinion of the form:
>
> C) in reality, throwing typically works
>
>
> I somewhat share the opinion of C - because _typically_ the program *was*
> in a valid state just a moment ago.  And *IF* you assert enough, it hasn't
> gone far from that state before you catch the bug.  Throwing to roll things
> back typically gets you back to that valid state. (Transactional memory
> might be nice here!).
>
> But this requires lots of asserts, and it is hard to doubt the logic of
> "an assert fired, therefore the calling code is wrong, therefore why do you
> think the calling code didn't already break things"...
>
> Basically, Why do you think asserts catch things early enough?
>
>
Nice summary of options. I like it because it allows me to say that my
opinion:

Would ideally be (A.1), while in reality is more like (B), except that for
all practical matters, it is (C).

So I can explain, let me repeat what I said earlier in the thread:

There is fundamental difference between detecting and responding to an
invariant or postcondition violation and detecting and responding to a
precondition violation. Preconditions state requirements to avoid state
corruption (examples: don't access this array outside it's boundaries,
don't talk to this object that has been destroyed, don't try to use this
undefined value, etc..). If a program where to be structured with 100%
coverage for preconditions, invariants and postconditions (an idealized
DbC), then I would say that a *precondition* assert corresponds to (A.1) in
all cases. However, the only realistic expectation is that only a fraction
of the code would check for preconditions, so my practical opinion about
assert becomes closer to (B).

OTOH, as has been noted before, assert() (alone) is not neccesarily for
preconditions, and only if you respond to that you are preventing the
problem, so if my opinion extends to all current uses of assert(), then
it's definitely (C)


> ---
>
> P.S. Beyond that, if you throw only in debug, and someone writes code to
> catch that exception and do something special, you can end up writing a
> program that *only* works in debug... :-(
>
>
Good point.Anyway, I don't really like to throw on assert, I just like
abort even less.

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--001a11c2a884c44d1104db872287
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 29, 2013 at 6:16 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> =
wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><di=
v><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im">O=
n Mon, Apr 29, 2013 at 10:14 AM, Fernando Cacciola <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cac=
ciola@gmail.com</a>&gt;</span> wrote:<br>


</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im">I don=
&#39;t think I follow.<br>

<div>


<br></div><div>In any such language you can have, for example, a buffer ove=
rrun, just like in C++. Well, no really, you can&#39;t, because the system =
performs a range-check precondition and throws if you try to overrun, but t=
hat&#39;s the mechanism that makes it &quot;memory safe&quot; and my point =
precisely is that I see no reason for not doing exactly the same in C++, ex=
cept performance.<br>





<br></div><div>In C# you can even corrupt the stack since it has stack vari=
ables just like C/C++<br></div><div><div>=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">




<div>; pointers are always either null or point to a valid allocated object=
; you can&#39;t write outside of objects</div>
</blockquote><div><br></div></div><div>That&#39;s not entirely true.<br></d=
iv><div>You can dispose of an object (conceptually the same as destroying i=
t), then access it and even modify it.<br><br></div><div>Well, again, not r=
eally, but because the system has a precondition that throws if it detects =
that the object has been disposed. So, again, the &quot;memory safety&quot;=
 is not the consequence of a different memory model, it is the consequence =
of the heavy use of precondition checks and throwing in case of failure.<br=
>





</div><div><div>=A0</div><br></div></div><div class=3D"im"><div>Right, but =
it is the use of (release mode included) preconditions and throwing in resp=
onse which gives you such a minimum guaranteed state, not the use of a garb=
age-collector.<br>


<br></div></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<div>=A0<div class=3D"im"><br>The bottom line is that in C++, if you get a =
failure in a precondition check, you can never be sure whether the cause is=
 simply due to a simple programming error in the caller or a more general c=
orruption of the system.<span><font color=3D"#888888"><br>





</font></span></div></div><span><font color=3D"#888888"><br></font></span><=
/blockquote><div><br></div></div><div class=3D"im"><div>This last statement=
 is my reason for this whole thread: that is just plain untrue for a really=
 large class of errors and for most applications. With all due respect, it =
is IMHO a myth that people just keep repeating. My experience with throwing=
 as a response to failures of any kind, including programming errors, large=
ly shown (to me) otherwise.<br>





</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><span></span></bloc=
kquote></div></div><br></div><div class=3D"im"><div class=3D"gmail_extra">I=
 understand and accept the other reasons such as increased diagnosability, =
or that for certain applications, keep-running is not that much important s=
o quiting it&#39;s fine, but I will insist in that aborting to avoid cascad=
ing state corruption is just ungrounded.<br clear=3D"all">





</div><div><div class=3D"gmail_extra"><br></div></div></div></div></blockqu=
ote></div><br></div><div class=3D"gmail_extra">So that I understand:<br><br=
></div><div class=3D"gmail_extra">Is your position that <br><br>A.1) - an a=
ssert fires before &quot;corruption&quot;?<br>


A.2) - before &quot;there is a problem&quot;?<br><br></div><div class=3D"gm=
ail_extra">Because obviously there is a problem, else the assert wouldn&#39=
;t fire.=A0 How do we know whether the problem was caught soon enough?<br>

<br>
</div><div class=3D"gmail_extra">Is your position more like:<br><br></div><=
div class=3D"gmail_extra">B) - if you assert *enough*, then you will catch =
problems early enough that nothing has really gone wrong yet.=A0 (Still, ob=
viously something has gone wrong...) But no &quot;harm&quot; yet.=A0 ie at =
least assert, say, before writing anything.=A0 (I guess this is similar to =
A.1 - before corruption)<br>


<br><br></div><div class=3D"gmail_extra">I want to be clear, because I thin=
k that is where opinions differ.=A0 I think many people consider an assert =
to mean some code was broken, therefore you can&#39;t be sure that the code=
 didn&#39;t already cause corruption (ie it is bad code, therefore maybe it=
 was lax on asserting when it should have).<br>


<br></div><div class=3D"gmail_extra">Or is your opinion of the form:<br><br=
>C) in reality, throwing typically works<br><br></div><div class=3D"gmail_e=
xtra"><br></div><div class=3D"gmail_extra">I somewhat share the opinion of =
C - because _typically_ the program *was* in a valid state just a moment ag=
o.=A0 And *IF* you assert enough, it hasn&#39;t gone far from that state be=
fore you catch the bug.=A0 Throwing to roll things back typically gets you =
back to that valid state. (Transactional memory might be nice here!).<br>


<br></div><div class=3D"gmail_extra">But this requires lots of asserts, and=
 it is hard to doubt the logic of &quot;an assert fired, therefore the call=
ing code is wrong, therefore why do you think the calling code didn&#39;t a=
lready break things&quot;... <br>


<br>Basically, Why do you think asserts catch things early enough?<br></div=
><br></div></div></div></blockquote><div><br></div><div>Nice summary of opt=
ions. I like it because it allows me to say that my opinion:<br><br></div>

<div>Would ideally be (A.1), while in reality is more like (B), except that=
 for all practical matters, it is (C).<br><br></div><div>So I can explain, =
let me repeat what I said earlier in the thread:<br><br></div><div>There is=
 fundamental difference between detecting and responding to an invariant or=
 postcondition violation and detecting and responding to a precondition vio=
lation. Preconditions state requirements to avoid state corruption (example=
s: don&#39;t access this array outside it&#39;s boundaries, don&#39;t talk =
to this object that has been destroyed, don&#39;t try to use this undefined=
 value, etc..). If a program where to be structured with 100% coverage for =
preconditions, invariants and postconditions (an idealized DbC), then I wou=
ld say that a *precondition* assert corresponds to (A.1) in all cases. Howe=
ver, the only realistic expectation is that only a fraction of the code wou=
ld check for preconditions, so my practical opinion about assert becomes cl=
oser to (B).<br>

<br></div><div>OTOH, as has been noted before, assert() (alone) is not necc=
esarily for preconditions, and only if you respond to that you are preventi=
ng the problem, so if my opinion extends to all current uses of assert(), t=
hen it&#39;s definitely (C)<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr"><div><div>---<br><br></div>P.S. Beyond that, if you throw only in debu=
g, and someone writes code to catch that exception and do something special=
, you can end up writing a program that *only* works in debug... :-(<br>


<br></div></div></blockquote><div><br></div><div>Good point.Anyway, I don&#=
39;t really like to throw on assert, I just like abort even less.<br></div>=
</div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br><a hre=
f=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting.com</=
a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c2a884c44d1104db872287--

.

--f46d0408930b67337604db876054
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 29, 2013 at 6:02 PM, Lawrence Crowl <crowl@googlers.com> wrote:

> On 4/29/13, Nevin Liber <nevin@eviloverlord.com> wrote:
> > On 28 April 2013, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> > > I'd prefer a hard error over silent data corruption.
> >
> > This is, of course, the crux of the matter.  The rest is pretty
> > much handwaving that throwing allows you to recover from the data
> > corruption.  To be fair, it probably "works" 99% of the time.
> > But can you afford the result of the 1%?
> >
> > I worked at a place which thought that.  Well, at least until
> > bad error recovery resulted in my management getting fired and us
> > pulling our main product out of the market for a year and a half.
> >
> > > Don't you agree that for a lot of programs aborting on assert
> > > failure is perfectly fine?
> >
> > I just don't see the other side of that coin.  How can you any
> > risk analysis if you cannot reason about either the root cause
> > of the programming error you detected or the state your program
> > is in after you've detected the error?
> >
> > But we are just going around in circles.  What does that exactly
> > have to do with the standard?
>
> Exceptions are good for handling conditions that are rare but
> reasonable.  For example, memory allocation failure is (presumably)
> rare, but it can reasonably happen.  The exception mechanism enables
> us to handle such rare events in a few code locations, rather than
> all throughout the code.  We need the behavior of our program to
> be fully defined while handling such events.
>
> Agreed.
Though of course you are implying that exceptions are not neccesarily good
for events that should never happen such are programming errors.
I agree provided there is a "similar" mechanism for "impossible but
happening" events (there must be a word for that)



> In contrast, where the standard says "doing X has undefined behavior"
> it means "the program doing X is erroneous and the standard does not
> define the behavior of erroneous programs".  Failing an assertion
> says "the program is erroneous".
>
> Agreed


> When we detect erroneous behavior, we do not want to a-priori throw
> an exception for several reasons.
>
> * Doing so turns an undefined behavior into a defined behavior.
> That is, programmers could deliberately violate the assertion in
> order to generate an exception.  It is bad engineering, but would
> still be conforming.  More insidiously, one can never fix code to
> avoid errors because then they would cease to throw exceptions.
>
> OK. I take this point to mean that we don't want to define throwing
behavior. And in that case I agree.


> * Erroneous programs are erroneous when written, not when run.
>

Agreed


> It is possible to do static analysis and reject the program.
> But if the erroneous bit means "throw", we cannot do so.
>
> IMO, vector.at(-1) is just as erroneous as vector[-1], but I accept that
this is a bit of a corner case. Against a wider contract is very difficult
to determine that there is a programming error just because the program
causes the interface to throw.

So, in principle, I agree.

What that means is that we want an explicit assertion and not: if ( ! pre )
throw



> * If an assertion is defined to throw, then we can no longer
> invoke the debugger on dynamically detecting erroneous behavior.
> We must throw to match the defined behavior.
>
> Right, which is why I don't really like throw, just like it better than
quit() which won't invoke the debugger either.


> * Programs that are not erroneous are more optimizable.  E.g.,
> if I have an assertion p!=NULL, then the compiler can propogate
> that knowledge through the code to eliminate subsequent tests for
> NULL in the code.
>
> Right


> We really want erroneous programs to have undefined behavior
> because that gives us the best hope for making the code better.
>
> Now I'm not sure I follow you here. How does UB does that, can you clarify?


> However, erroneous programs may still interact with the real world.
> We want most, if not all, of our systems to recover from erroneous
> programs.


Exactly!
Which is why I take a throwing assert over abort if I don't have anything
better.

But here in std-proposal we can think of something better :)



>  We can recover externally.  E.g. compiler front ends can
> abort on error and rely on the compiler driver to delete partially
> built object files.  To recover internally, we need some mechanism
> to run code after detecting erroneous behavior.  We also need to
> reserve that mechanism to the final application developer, but cause
> only then is the recovery task completely knowable.


Agreed


>  My opinion is
> that the termination handler (for example) is a better mechanism
> than exceptions.


Absolutely. Or FWIW any mechanism specifically desgined for this is better
than exceptions and/or abort.


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--f46d0408930b67337604db876054
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 29, 2013 at 6:02 PM, Lawrence Crowl <span dir=3D"ltr">&lt;<a href=
=3D"mailto:crowl@googlers.com" target=3D"_blank">crowl@googlers.com</a>&gt;=
</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On 4/29/13, Nevin Liber &lt;<a href=3D"mailt=
o:nevin@eviloverlord.com">nevin@eviloverlord.com</a>&gt; wrote:<br>
<div class=3D"im">&gt; On 28 April 2013, Olaf van der Spek &lt;<a href=3D"m=
ailto:olafvdspek@gmail.com">olafvdspek@gmail.com</a>&gt; wrote:<br>
&gt; &gt; I&#39;d prefer a hard error over silent data corruption.<br>
&gt;<br>
&gt; This is, of course, the crux of the matter. =A0The rest is pretty<br>
&gt; much handwaving that throwing allows you to recover from the data<br>
&gt; corruption. =A0To be fair, it probably &quot;works&quot; 99% of the ti=
me.<br>
&gt; But can you afford the result of the 1%?<br>
&gt;<br>
&gt; I worked at a place which thought that. =A0Well, at least until<br>
&gt; bad error recovery resulted in my management getting fired and us<br>
&gt; pulling our main product out of the market for a year and a half.<br>
&gt;<br>
&gt; &gt; Don&#39;t you agree that for a lot of programs aborting on assert=
<br>
&gt; &gt; failure is perfectly fine?<br>
&gt;<br>
&gt; I just don&#39;t see the other side of that coin. =A0How can you any<b=
r>
&gt; risk analysis if you cannot reason about either the root cause<br>
&gt; of the programming error you detected or the state your program<br>
&gt; is in after you&#39;ve detected the error?<br>
&gt;<br>
&gt; But we are just going around in circles. =A0What does that exactly<br>
&gt; have to do with the standard?<br>
<br>
</div>Exceptions are good for handling conditions that are rare but<br>
reasonable. =A0For example, memory allocation failure is (presumably)<br>
rare, but it can reasonably happen. =A0The exception mechanism enables<br>
us to handle such rare events in a few code locations, rather than<br>
all throughout the code. =A0We need the behavior of our program to<br>
be fully defined while handling such events.<br>
<br></blockquote><div>Agreed.<br></div><div>Though of course you are implyi=
ng that exceptions are not neccesarily good for events that should never ha=
ppen such are programming errors.<br></div><div>I agree provided there is a=
 &quot;similar&quot; mechanism for &quot;impossible but happening&quot; eve=
nts (there must be a word for that)<br>

<br></div><div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In contrast, where the standard says &quot;doing X has undefined behavior&q=
uot;<br>
it means &quot;the program doing X is erroneous and the standard does not<b=
r>
define the behavior of erroneous programs&quot;. =A0Failing an assertion<br=
>
says &quot;the program is erroneous&quot;.<br>
<br></blockquote><div>Agreed<br>=A0<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
When we detect erroneous behavior, we do not want to a-priori throw<br>
an exception for several reasons.<br>
<br>
* Doing so turns an undefined behavior into a defined behavior.<br>
That is, programmers could deliberately violate the assertion in<br>
order to generate an exception. =A0It is bad engineering, but would<br>
still be conforming. =A0More insidiously, one can never fix code to<br>
avoid errors because then they would cease to throw exceptions.<br>
<br></blockquote><div>OK. I take this point to mean that we don&#39;t want =
to define throwing behavior. And in that case I agree.<br>=A0<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">


* Erroneous programs are erroneous when written, not when run.<br></blockqu=
ote><div><br></div><div>Agreed<br>=A0<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">


It is possible to do static analysis and reject the program.<br>
But if the erroneous bit means &quot;throw&quot;, we cannot do so.<br>
<br></blockquote><div>IMO, <a href=3D"http://vector.at">vector.at</a>(-1) i=
s just as erroneous as vector[-1], but I accept that this is a bit of a cor=
ner case. Against a wider contract is very difficult to determine that ther=
e is a programming error just because the program causes the interface to t=
hrow.<br>

<br></div><div>So, in principle, I agree.<br><br></div><div>What that means=
 is that we want an explicit assertion and not: if ( ! pre ) throw<br><br><=
/div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">


* If an assertion is defined to throw, then we can no longer<br>
invoke the debugger on dynamically detecting erroneous behavior.<br>
We must throw to match the defined behavior.<br>
<br></blockquote><div>Right, which is why I don&#39;t really like throw, ju=
st like it better than quit() which won&#39;t invoke the debugger either.<b=
r>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">


* Programs that are not erroneous are more optimizable. =A0E.g.,<br>
if I have an assertion p!=3DNULL, then the compiler can propogate<br>
that knowledge through the code to eliminate subsequent tests for<br>
NULL in the code.<br>
<br></blockquote><div>Right<br>=A0<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We really want erroneous programs to have undefined behavior<br>
because that gives us the best hope for making the code better.<br>
<br></blockquote><div>Now I&#39;m not sure I follow you here. How does UB d=
oes that, can you clarify?<br></div><div>=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">


However, erroneous programs may still interact with the real world.<br>
We want most, if not all, of our systems to recover from erroneous<br>
programs.</blockquote><div><br></div><div>Exactly! <br></div>Which is why I=
 take a throwing assert over abort if I don&#39;t have anything better.<br>=
<br></div><div class=3D"gmail_quote">But here in std-proposal we can think =
of something better :)<br>

</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><div>=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"> =A0We can recover externally. =A0E=
..g. compiler front ends can<br>


abort on error and rely on the compiler driver to delete partially<br>
built object files. =A0To recover internally, we need some mechanism<br>
to run code after detecting erroneous behavior. =A0We also need to<br>
reserve that mechanism to the final application developer, but cause<br>
only then is the recovery task completely knowable.</blockquote><div><br></=
div><div>Agreed<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> =A0My opini=
on is<br>


that the termination handler (for example) is a better mechanism<br>
than exceptions. </blockquote><div><br></div><div>Absolutely. Or FWIW any m=
echanism specifically desgined for this is better than exceptions and/or ab=
ort.<br></div><div></div><div></div><br></div><br>-- <br>Fernando Cacciola<=
br>

SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com=
">http://www.scisoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--f46d0408930b67337604db876054--

.

--089e011604e089016104db87b4f8
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 29, 2013 at 6:02 PM, Lawrence Crowl <crowl@googlers.com> wrote:

>
>
> I would like to see the standard support the notion of erroneous
> behavior and programs more directly.  Assertion violations are one
> more way to specify when programs are erroneous.
>
> Me too, so let's try to wrap up the discussion with some conclusions
useful to this forum:

1) I want the std to define certain elements to allow C++ programs to
explicitely address programming errors. I want this to be standarized so I
can compose an application with a number of heterogeneous libraries and
still have a consistent way to handle defects at the highest level.

2) IMO, such definitions should address violations to preconditions,
invariants and postconditions separatedly, because as I (tried to)
explained, the consequence of such violations have fundamentally different
effects.

3) Application programmers should be able to consistently and globally turn
on or off all detection (and response) to such programming errors (i.e.
NDEBUG but for this)

4) The response to such violations should be left as undefined behaviour
even in the case where detection is on (i.e. the std would simply define
that a call to a user defined precondition_assertion_failure is made)

5) The language should provide a mechanism for program recovery. A naive
but illustrative example would be that, the default
precondition_assertion_failure calls a non-unwinding
std::precondition_failed() function, which would in turn call a
std::at_precondition_failure()  user-registered handler, if any, or
std::terminate() if none is given. This would provide programs with a
chance to register a safe re-entry point to return after an assertion
failure. NOTE: based on (2)  I want all distinct 3 falvours of the
_failed() functions.

Best

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--089e011604e089016104db87b4f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 29, 2013 at 6:02 PM, Lawrence Crowl <span dir=3D"ltr">&lt;<a href=
=3D"mailto:crowl@googlers.com" target=3D"_blank">crowl@googlers.com</a>&gt;=
</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
I would like to see the standard support the notion of erroneous<br>
behavior and programs more directly. =A0Assertion violations are one<br>
more way to specify when programs are erroneous.<br>
<span><font color=3D"#888888"><br></font></span></blockquote><div>Me too, s=
o let&#39;s try to wrap up the discussion with some conclusions useful to t=
his forum:<br></div></div><br></div><div class=3D"gmail_extra">1) I want th=
e std to define certain elements to allow C++ programs to explicitely addre=
ss programming errors. I want this to be standarized so I can compose an ap=
plication with a number of heterogeneous libraries and still have a consist=
ent way to handle defects at the highest level.<br>


<br></div><div class=3D"gmail_extra">2) IMO, such definitions should addres=
s violations to preconditions, invariants and postconditions separatedly, b=
ecause as I (tried to) explained, the consequence of such violations have f=
undamentally different effects.<br>


<br></div><div class=3D"gmail_extra">3) Application programmers should be a=
ble to consistently and globally turn on or off all detection (and response=
) to such programming errors (i.e. NDEBUG but for this)<br><br></div><div c=
lass=3D"gmail_extra">


4) The response to such violations should be left as undefined behaviour ev=
en in the case where detection is on (i.e. the std would simply define that=
 a call to a user defined precondition_assertion_failure is made)<br><br>


</div><div class=3D"gmail_extra">5) The language should provide a mechanism=
 for program recovery. A naive but illustrative example would be that, the =
default precondition_assertion_failure calls a non-unwinding std::precondit=
ion_failed() function, which would in turn call a=A0 std::at_precondition_f=
ailure()=A0 user-registered handler, if any, or std::terminate() if none is=
 given. This would provide programs with a chance to register a safe re-ent=
ry point to return after an assertion failure. NOTE: based on (2)=A0 I want=
 all distinct 3 falvours of the _failed() functions. <br>


<br></div><div class=3D"gmail_extra">Best<br></div><div class=3D"gmail_extr=
a"><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br><a href=
=3D"http://www.scisoft-consulting.com" target=3D"_blank">http://www.scisoft=
-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e011604e089016104db87b4f8--

.

On 4/29/13, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> On Apr 29, 2013 Lawrence Crowl <crowl@googlers.com> wrote:
> > We really want erroneous programs to have undefined behavior
> > because that gives us the best hope for making the code better.
>
> Now I'm not sure I follow you here. How does UB does that, can
> you clarify?

Undefined behavior does that by leaving the choice to the programming
system.  The programmer, the audit committee, the online support
staff, etc., can all use different behaviors as needed.  Some of
those behaviors will catch more bugs earlier, which gives us
better code.  Some will make the code runs faster, which is better.

--
Lawrence Crowl

--

---
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/?hl=en.



.

On 4/29/13, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> On Apr 29, 2013 Lawrence Crowl <crowl@googlers.com> wrote:
> > I would like to see the standard support the notion of erroneous
> > behavior and programs more directly.  Assertion violations are
> > one more way to specify when programs are erroneous.
>
> Me too, so let's try to wrap up the discussion with some
> conclusions useful to this forum:
>
> 1) I want the std to define certain elements to allow C++
> programs to explicitely address programming errors. I want this
> to be standarized so I can compose an application with a number
> of heterogeneous libraries and still have a consistent way to
> handle defects at the highest level.
>
> 2) IMO, such definitions should address violations to
> preconditions, invariants and postconditions separatedly, because
> as I (tried to) explained, the consequence of such violations
> have fundamentally different effects.
>
> 3) Application programmers should be able to consistently and
> globally turn on or off all detection (and response) to such
> programming errors (i.e.  NDEBUG but for this)
>
> 4) The response to such violations should be left as undefined
> behaviour even in the case where detection is on (i.e. the
> std would simply define that a call to a user defined
> precondition_assertion_failure is made)
>
> 5) The language should provide a mechanism for program
> recovery. A naive but illustrative example would be that, the
> default precondition_assertion_failure calls a non-unwinding
> std::precondition_failed() function, which would in turn call a
> std::at_precondition_failure() user-registered handler, if any,
> or std::terminate() if none is given. This would provide programs
> with a chance to register a safe re-entry point to return after
> an assertion failure. NOTE: based on (2) I want all distinct 3
> falvours of the _failed() functions.

That all looks reasonable to me, though I would want the behavior
to have more than one control.  In particular, I would enable
precondition checking long after I have disabled invariant and
postcondition checking.

--
Lawrence Crowl

--

---
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/?hl=en.



.

--047d7b3a897a9745b704db9264d9
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 29, 2013 at 9:29 PM, Lawrence Crowl <crowl@googlers.com> wrote:

> On 4/29/13, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> > On Apr 29, 2013 Lawrence Crowl <crowl@googlers.com> wrote:
> > > We really want erroneous programs to have undefined behavior
> > > because that gives us the best hope for making the code better.
> >
> > Now I'm not sure I follow you here. How does UB does that, can
> > you clarify?
>
> Undefined behavior does that by leaving the choice to the programming
> system.  The programmer, the audit committee, the online support
> staff, etc., can all use different behaviors as needed.  Some of
> those behaviors will catch more bugs earlier, which gives us
> better code.  Some will make the code runs faster, which is better.
>
> OK.

It feels a bit weird that leaving something undefined in a language has
such a positive effect, but I can see how it does in this case.



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--047d7b3a897a9745b704db9264d9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 29, 2013 at 9:29 PM, Lawrence Crowl <span dir=3D"ltr">&lt;<a href=
=3D"mailto:crowl@googlers.com" target=3D"_blank">crowl@googlers.com</a>&gt;=
</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On 4/29/13, Fernando Cacciola &lt;<a href=3D=
"mailto:fernando.cacciola@gmail.com">fernando.cacciola@gmail.com</a>&gt; wr=
ote:<br>


<div class=3D"im">&gt; On Apr 29, 2013 Lawrence Crowl &lt;<a href=3D"mailto=
:crowl@googlers.com">crowl@googlers.com</a>&gt; wrote:<br>
&gt; &gt; We really want erroneous programs to have undefined behavior<br>
&gt; &gt; because that gives us the best hope for making the code better.<b=
r>
&gt;<br>
&gt; Now I&#39;m not sure I follow you here. How does UB does that, can<br>
&gt; you clarify?<br>
<br>
</div>Undefined behavior does that by leaving the choice to the programming=
<br>
system. =A0The programmer, the audit committee, the online support<br>
staff, etc., can all use different behaviors as needed. =A0Some of<br>
those behaviors will catch more bugs earlier, which gives us<br>
better code. =A0Some will make the code runs faster, which is better.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div>O=
K.<br><br></div><div>It feels a bit weird that leaving something undefined =
in a language has such a positive effect, but I can see how it does in this=
 case.</div>

</div><br><br clear=3D"all"><br>-- <br>Fernando Cacciola<br>SciSoft Consult=
ing, Founder<br><a href=3D"http://www.scisoft-consulting.com">http://www.sc=
isoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b3a897a9745b704db9264d9--

.

--089e011604e02d558e04db926854
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 29, 2013 at 9:32 PM, Lawrence Crowl <crowl@googlers.com> wrote:

> On 4/29/13, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> > On Apr 29, 2013 Lawrence Crowl <crowl@googlers.com> wrote:
> > > I would like to see the standard support the notion of erroneous
> > > behavior and programs more directly.  Assertion violations are
> > > one more way to specify when programs are erroneous.
> >
> > Me too, so let's try to wrap up the discussion with some
> > conclusions useful to this forum:
> >
> > 1) I want the std to define certain elements to allow C++
> > programs to explicitely address programming errors. I want this
> > to be standarized so I can compose an application with a number
> > of heterogeneous libraries and still have a consistent way to
> > handle defects at the highest level.
> >
> > 2) IMO, such definitions should address violations to
> > preconditions, invariants and postconditions separatedly, because
> > as I (tried to) explained, the consequence of such violations
> > have fundamentally different effects.
> >
> > 3) Application programmers should be able to consistently and
> > globally turn on or off all detection (and response) to such
> > programming errors (i.e.  NDEBUG but for this)
> >
> > 4) The response to such violations should be left as undefined
> > behaviour even in the case where detection is on (i.e. the
> > std would simply define that a call to a user defined
> > precondition_assertion_failure is made)
> >
> > 5) The language should provide a mechanism for program
> > recovery. A naive but illustrative example would be that, the
> > default precondition_assertion_failure calls a non-unwinding
> > std::precondition_failed() function, which would in turn call a
> > std::at_precondition_failure() user-registered handler, if any,
> > or std::terminate() if none is given. This would provide programs
> > with a chance to register a safe re-entry point to return after
> > an assertion failure. NOTE: based on (2) I want all distinct 3
> > falvours of the _failed() functions.
>
> That all looks reasonable to me, though I would want the behavior
> to have more than one control.  In particular, I would enable
> precondition checking long after I have disabled invariant and
> postcondition checking.
>
> Good point. And indeed I would do the same.


--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
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/?hl=en.



--089e011604e02d558e04db926854
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 29, 2013 at 9:32 PM, Lawrence Crowl <span dir=3D"ltr">&lt;<a href=
=3D"mailto:crowl@googlers.com" target=3D"_blank">crowl@googlers.com</a>&gt;=
</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On 4/29/13, Fernando Cacciola &lt;<a href=3D=
"mailto:fernando.cacciola@gmail.com">fernando.cacciola@gmail.com</a>&gt; wr=
ote:<br>


<div><div class=3D"h5">&gt; On Apr 29, 2013 Lawrence Crowl &lt;<a href=3D"m=
ailto:crowl@googlers.com">crowl@googlers.com</a>&gt; wrote:<br>
&gt; &gt; I would like to see the standard support the notion of erroneous<=
br>
&gt; &gt; behavior and programs more directly. =A0Assertion violations are<=
br>
&gt; &gt; one more way to specify when programs are erroneous.<br>
&gt;<br>
&gt; Me too, so let&#39;s try to wrap up the discussion with some<br>
&gt; conclusions useful to this forum:<br>
&gt;<br>
&gt; 1) I want the std to define certain elements to allow C++<br>
&gt; programs to explicitely address programming errors. I want this<br>
&gt; to be standarized so I can compose an application with a number<br>
&gt; of heterogeneous libraries and still have a consistent way to<br>
&gt; handle defects at the highest level.<br>
&gt;<br>
&gt; 2) IMO, such definitions should address violations to<br>
&gt; preconditions, invariants and postconditions separatedly, because<br>
&gt; as I (tried to) explained, the consequence of such violations<br>
&gt; have fundamentally different effects.<br>
&gt;<br>
&gt; 3) Application programmers should be able to consistently and<br>
&gt; globally turn on or off all detection (and response) to such<br>
&gt; programming errors (i.e. =A0NDEBUG but for this)<br>
&gt;<br>
&gt; 4) The response to such violations should be left as undefined<br>
&gt; behaviour even in the case where detection is on (i.e. the<br>
&gt; std would simply define that a call to a user defined<br>
&gt; precondition_assertion_failure is made)<br>
&gt;<br>
&gt; 5) The language should provide a mechanism for program<br>
&gt; recovery. A naive but illustrative example would be that, the<br>
&gt; default precondition_assertion_failure calls a non-unwinding<br>
&gt; std::precondition_failed() function, which would in turn call a<br>
&gt; std::at_precondition_failure() user-registered handler, if any,<br>
&gt; or std::terminate() if none is given. This would provide programs<br>
&gt; with a chance to register a safe re-entry point to return after<br>
&gt; an assertion failure. NOTE: based on (2) I want all distinct 3<br>
&gt; falvours of the _failed() functions.<br>
<br>
</div></div>That all looks reasonable to me, though I would want the behavi=
or<br>
to have more than one control. =A0In particular, I would enable<br>
precondition checking long after I have disabled invariant and<br>
postcondition checking.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div>G=
ood point. And indeed I would do the same. <br></div></div><br clear=3D"all=
"><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br><a href=3D=
"http://www.scisoft-consulting.com">http://www.scisoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e011604e02d558e04db926854--

.