------=_Part_362_316834757.1490295946666
Content-Type: multipart/alternative;
 boundary="----=_Part_363_1653227497.1490295946666"

------=_Part_363_1653227497.1490295946666
Content-Type: text/plain; charset=UTF-8

Right now, operator new() will throw if memory allocation fails.

The idea is that in theory your application can catch these exceptions and
properly clean up. In practice, almost nobody actually handles memory
allocation exceptions. Most of the time there is no way to handle it
properly. Aside from very small carefully controlled situations, its
impossible to unit test what happens when each and every allocation fails.
If your application runs of memory you're better off just crashing.

The consequence of this design decision, is that everything that might do a
memory allocation needs to be exception safe. We need to write exception
safe code and the compiler must also assume any allocation can throw and
then setup the unwinding structures.

A good example of this, would be something like vector::push_back(). If
push_back needs to reallocate, it will move construct each element. If move
can throw, it will need to fallback to copy. If copy can throw, there needs
to be cleanup code in place that will destroy all of the previously copied
elements and deallocate the new buffer. Finally, for the programmer calling
push_back. I need to be sure to order the other stuff before and after it
correctly, so my state doesn't get messed up in the off chance that it
throws.

For the case of allocations, all of this exception cleanup code is in
practice dead code. It increases our binary size which also negatively
impacts the Icache.

Most compilers provide some variant of -fno-exceptions which entirely
disables exceptions for a performance gain. But what if we want to use
exceptions carefully in a few places but not suffer the cost of them
globally from allocations?

So the idea is to have some way to make operator new() noexcept at compile
time. Probably via a #define. This differs from the nothrow version of new
because it actually calls std::terminate() if the allocation fails, instead
of returning nullptr. No only can the compiler assume new will never throw,
it could also assume it never returns a nullptr.

Also this approach is better than using an allocator. You just switch it on
and everything works. ABI compatibility should not be a problem as
separately compiled code can be compiled with or without the feature. For
any opaque function call that isn't noexcept, we still need to assume it
can throw anything. This optimization would only be possible in inline
context.

This noexcept new mode could also improve application correctness. Almost
nobody ever writes careful code to handle exceptions thrown by new.

People can write catch blocks for std::exception anticipating other errors.
This will catch allocation errors as well. Since its impossible to unit
test every possible allocation site, its unlikely to be handled properly.
It would be better to just crash at the allocation site, with a ready stack
trace for debugging.

At a minimum, most people write try {} catch {} blocks around the entire
application in main. This completely obscures the source of an exception,
especially an out of memory error which could happen almost anywhere.

If I accidentally try to allocate INT_MAX somewhere, I'd rather get a core
dump at the site of the bug than a clean exit from main in a catch{} block.

I don't have hard data on any of this, but I suspect the following things
are likely true:
1. Most C++ applications don't need to handle out of memory conditions and
just calling std::terminate() immediately at the allocation site is the
best possible solution.
2. The largest source of "possibly can throw" in most applications come
from things that *might* allocate memory. Mostly from std:: containers.
3. This mode could give us most of the performance benefits of
-fno-exceptions while still allowing us to use exceptions in certain parts
of the system.
4. This mode can help us make our systems much simpler and more correct, as
we don't have to worry about the effectively infinite explosion of possible
application states from throwing allocations.
5. After removing allocations from concern, tools that analyse how
exceptions are used in programs might actually be meaningful and possible.

Would you use noexcept new in any of your applications?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6bb1b365-3b72-4d87-8324-fcf3566fe1f0%40isocpp.org.

------=_Part_363_1653227497.1490295946666
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Right now, operator new() will throw if memory allocation =
fails.<div><br></div><div>The idea is that in theory your application can c=
atch these exceptions and properly clean up. In practice, almost nobody act=
ually handles memory allocation exceptions. Most of the time there is no wa=
y to handle it properly. Aside from very small carefully controlled situati=
ons, its impossible to unit test what happens when each and every allocatio=
n fails. If your application runs of memory you&#39;re better off just cras=
hing.</div><div><br></div><div>The consequence of this design decision, is =
that everything that might do a memory allocation needs to be exception saf=
e. We need to write exception safe code and the compiler must also assume a=
ny allocation can throw and then setup the unwinding structures.</div><div>=
<br></div><div>A good example of this, would be something like vector::push=
_back(). If push_back needs to reallocate, it will move construct each elem=
ent. If move can throw, it will need to fallback to copy. If copy can throw=
, there needs to be cleanup code in place that will destroy all of the prev=
iously copied elements and deallocate the new buffer. Finally, for the prog=
rammer calling push_back. I need to be sure to order the other stuff before=
 and after it correctly, so my state doesn&#39;t get messed up in the off c=
hance that it throws.</div><div><br></div><div>For the case of allocations,=
 all of this exception cleanup code is in practice dead code. It increases =
our binary size which also negatively impacts the Icache.</div><div><br></d=
iv><div>Most compilers provide some variant of -fno-exceptions which entire=
ly disables exceptions for a performance gain. But what if we want to use e=
xceptions carefully in a few places but not suffer the cost of them globall=
y from allocations?</div><div><br></div><div>So the idea is to have some wa=
y to make operator new() noexcept at compile time. Probably via a #define. =
This differs from the nothrow version of new because it actually calls std:=
:terminate() if the allocation fails, instead of returning nullptr. No only=
 can the compiler assume new will never throw, it could also assume it neve=
r returns a nullptr.</div><div><br></div><div>Also this approach is better =
than using an allocator. You just switch it on and everything works. ABI co=
mpatibility should not be a problem as separately compiled code can be comp=
iled with or without the feature. For any opaque function call that isn&#39=
;t noexcept, we still need to assume it can throw anything. This optimizati=
on would only be possible in inline context.</div><div><br></div><div>This =
noexcept new mode could also improve application correctness. Almost nobody=
 ever writes careful code to handle exceptions thrown by new.=C2=A0</div><d=
iv><br></div><div>People can write catch blocks for std::exception anticipa=
ting other errors. This will catch allocation errors as well. Since its imp=
ossible to unit test every possible allocation site, its unlikely to be han=
dled properly. It would be better to just crash at the allocation site, wit=
h a ready stack trace for debugging.</div><div><br></div><div>At a minimum,=
 most people write try {} catch {} blocks around the entire application in =
main. This completely obscures the source of an exception, especially an ou=
t of memory error which could happen almost anywhere.</div><div><br></div><=
div>If I accidentally try to allocate INT_MAX somewhere, I&#39;d rather get=
 a core dump at the site of the bug than a clean exit from main in a catch{=
} block.</div><div><br></div><div>I don&#39;t have hard data on any of this=
, but I suspect the following things are likely true:</div><div>1. Most C++=
 applications don&#39;t need to handle out of memory conditions and just ca=
lling std::terminate() immediately at the allocation site is the best possi=
ble solution.</div><div>2. The largest source of &quot;possibly can throw&q=
uot; in most applications come from things that *might* allocate memory. Mo=
stly from std:: containers.</div><div>3. This mode could give us most of th=
e performance benefits of -fno-exceptions while still allowing us to use ex=
ceptions in certain parts of the system.</div><div>4. This mode can help us=
 make our systems much simpler and more correct, as we don&#39;t have to wo=
rry about the effectively infinite explosion of possible application states=
 from throwing allocations.</div><div>5. After removing allocations from co=
ncern, tools that analyse how exceptions are used in programs might actuall=
y be meaningful and possible.</div><div><br></div><div>Would you use noexce=
pt new in any of your applications?</div><div><br></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6bb1b365-3b72-4d87-8324-fcf3566fe1f0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6bb1b365-3b72-4d87-8324-fcf3566fe1f0=
%40isocpp.org</a>.<br />

------=_Part_363_1653227497.1490295946666--

------=_Part_362_316834757.1490295946666--

.

On quinta-feira, 23 de mar=C3=A7o de 2017 12:05:46 PDT Matthew Fioravante w=
rote:
> The idea is that in theory your application can catch these exceptions an=
d
> properly clean up. In practice, almost nobody actually handles memory
> allocation exceptions. Most of the time there is no way to handle it
> properly. Aside from very small carefully controlled situations, its
> impossible to unit test what happens when each and every allocation fails=
..

Actually, that's not very difficult.

Override your operator new with:

 pid_t pid =3D fork();
 if (!pid) {
  // child process
  throw std::bad_alloc();
 return malloc(size);

To make the output more readable, you probably want to introduce a cross-
process synchronisation before malloc(). It would also help with avoiding l=
ots=20
of COW of the process pages.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2097491.aukDsOJ778%40tjmaciei-mobl1.

.

------=_Part_2495_1570371442.1490322018494
Content-Type: multipart/alternative;
 boundary="----=_Part_2496_246882611.1490322018494"

------=_Part_2496_246882611.1490322018494
Content-Type: text/plain; charset=UTF-8

On Thursday, March 23, 2017 at 3:05:46 PM UTC-4, Matthew Fioravante wrote:
>
> Right now, operator new() will throw if memory allocation fails.
>
> The idea is that in theory your application can catch these exceptions and
> properly clean up. In practice, almost nobody actually handles memory
> allocation exceptions. Most of the time there is no way to handle it
> properly. Aside from very small carefully controlled situations, its
> impossible to unit test what happens when each and every allocation fails.
> If your application runs of memory you're better off just crashing.
>
> So the idea is to have some way to make operator new() noexcept at compile
> time. Probably via a #define. This differs from the nothrow version of new
> because it actually calls std::terminate() if the allocation fails, instead
> of returning nullptr. No only can the compiler assume new will never throw,
> it could also assume it never returns a nullptr.
>

You have been able to do this since at least C++98.

http://en.cppreference.com/w/cpp/memory/new/set_new_handler

std::new_handler set_new_handler( std::new_handler new_p );
Makes new_p the new global new-handler function and returns the previously
installed new-handler.

The new-handler function is the function called by allocation functions
whenever a memory allocation attempt fails. Its intended purpose is one of
three things:

1) make more memory available
2) terminate the program (e.g. by calling std::terminate)
3) throw exception of type std::bad_alloc or derived from std::bad_alloc.
The default implementation throws std::bad_alloc. The user can install his
own new-handler, which may offer behavior different than the default one.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6dd67bb9-b21e-43a7-a490-add7ec259279%40isocpp.org.

------=_Part_2496_246882611.1490322018494
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 23, 2017 at 3:05:46 PM UTC-4, Matthew F=
ioravante 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"lt=
r">Right now, operator new() will throw if memory allocation fails.<div><br=
></div><div>The idea is that in theory your application can catch these exc=
eptions and properly clean up. In practice, almost nobody actually handles =
memory allocation exceptions. Most of the time there is no way to handle it=
 properly. Aside from very small carefully controlled situations, its impos=
sible to unit test what happens when each and every allocation fails. If yo=
ur application runs of memory you&#39;re better off just crashing.</div><di=
v><br></div><div>So the idea is to have some way to make operator new() noe=
xcept at compile time. Probably via a #define. This differs from the nothro=
w version of new because it actually calls std::terminate() if the allocati=
on fails, instead of returning nullptr. No only can the compiler assume new=
 will never throw, it could also assume it never returns a nullptr.<br></di=
v></div></blockquote><div><br></div><div>You have been able to do this sinc=
e at least C++98.</div><div><br></div><div>http://en.cppreference.com/w/cpp=
/memory/new/set_new_handler<br></div><div><br></div><div><div>std::new_hand=
ler set_new_handler( std::new_handler new_p );<span class=3D"Apple-tab-span=
" style=3D"white-space: pre;">  </span><br></div><div>Makes new_p the new g=
lobal new-handler function and returns the previously installed new-handler=
..</div><div><br></div><div>The new-handler function is the function called =
by allocation functions whenever a memory allocation attempt fails. Its int=
ended purpose is one of three things:</div><div><br></div><div>1) make more=
 memory available</div><div>2) terminate the program (e.g. by calling std::=
terminate)</div><div>3) throw exception of type std::bad_alloc or derived f=
rom std::bad_alloc.</div><div>The default implementation throws std::bad_al=
loc. The user can install his own new-handler, which may offer behavior dif=
ferent than the default one.</div></div><div><br></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6dd67bb9-b21e-43a7-a490-add7ec259279%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6dd67bb9-b21e-43a7-a490-add7ec259279=
%40isocpp.org</a>.<br />

------=_Part_2496_246882611.1490322018494--

------=_Part_2495_1570371442.1490322018494--

.

------=_Part_273_755755606.1490323016518
Content-Type: multipart/alternative;
 boundary="----=_Part_274_513755103.1490323016518"

------=_Part_274_513755103.1490323016518
Content-Type: text/plain; charset=UTF-8



On Thursday, March 23, 2017 at 9:20:18 PM UTC-5, Greg Marr wrote:

> You have been able to do this since at least C++98.
>
> http://en.cppreference.com/w/cpp/memory/new/set_new_handler
>
> std::new_handler set_new_handler( std::new_handler new_p );
> Makes new_p the new global new-handler function and returns the previously
> installed new-handler.
>
> The new-handler function is the function called by allocation functions
> whenever a memory allocation attempt fails. Its intended purpose is one of
> three things:
>
> 1) make more memory available
> 2) terminate the program (e.g. by calling std::terminate)
> 3) throw exception of type std::bad_alloc or derived from std::bad_alloc.
> The default implementation throws std::bad_alloc. The user can install his
> own new-handler, which may offer behavior different than the default one.
>
>
set_new_handler() is a runtime operation. You could get the safety benefits
but the compiler will be unable to optimize out exception handling as the
new handler function pointer type is not noexcept.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/27c55ce3-ff85-4217-ae5f-abc33838b128%40isocpp.org.

------=_Part_274_513755103.1490323016518
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, March 23, 2017 at 9:20:18 PM UTC-5, G=
reg Marr wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div>You have been able to do this since at least C++98.</div><div><b=
r></div><div><a href=3D"http://en.cppreference.com/w/cpp/memory/new/set_new=
_handler" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp=
%2Fmemory%2Fnew%2Fset_new_handler\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
4aZUwNKiE5elbLQmXgRqRbLIiMA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2=
Fmemory%2Fnew%2Fset_new_handler\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH4a=
ZUwNKiE5elbLQmXgRqRbLIiMA&#39;;return true;">http://en.cppreference.com/w/<=
wbr>cpp/memory/new/set_new_handler</a><br></div><div><br></div><div><div>st=
d::new_handler set_new_handler( std::new_handler new_p );<span style=3D"whi=
te-space:pre">  </span><br></div><div>Makes new_p the new global new-handle=
r function and returns the previously installed new-handler.</div><div><br>=
</div><div>The new-handler function is the function called by allocation fu=
nctions whenever a memory allocation attempt fails. Its intended purpose is=
 one of three things:</div><div><br></div><div>1) make more memory availabl=
e</div><div>2) terminate the program (e.g. by calling std::terminate)</div>=
<div>3) throw exception of type std::bad_alloc or derived from std::bad_all=
oc.</div><div>The default implementation throws std::bad_alloc. The user ca=
n install his own new-handler, which may offer behavior different than the =
default one.</div></div><div><br></div></div></blockquote><div><br>set_new_=
handler() is a runtime operation. You could get the safety=20
benefits but the compiler will be unable to optimize out exception=20
handling as the new handler function pointer type is not noexcept. <br></di=
v></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/27c55ce3-ff85-4217-ae5f-abc33838b128%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/27c55ce3-ff85-4217-ae5f-abc33838b128=
%40isocpp.org</a>.<br />

------=_Part_274_513755103.1490323016518--

------=_Part_273_755755606.1490323016518--

.

------=_Part_828_1891425199.1490327207821
Content-Type: multipart/alternative;
 boundary="----=_Part_829_1061190698.1490327207821"

------=_Part_829_1061190698.1490327207821
Content-Type: text/plain; charset=UTF-8

On Thursday, March 23, 2017 at 3:05:46 PM UTC-4, Matthew Fioravante wrote:
>
> Right now, operator new() will throw if memory allocation fails.
>
> The idea is that in theory your application can catch these exceptions and
> properly clean up. In practice, almost nobody actually handles memory
> allocation exceptions. Most of the time there is no way to handle it
> properly. Aside from very small carefully controlled situations, its
> impossible to unit test what happens when each and every allocation fails.
> If your application runs of memory you're better off just crashing.
>
> The consequence of this design decision, is that everything that might do
> a memory allocation needs to be exception safe. We need to write exception
> safe code and the compiler must also assume any allocation can throw and
> then setup the unwinding structures.
>
> A good example of this, would be something like vector::push_back(). If
> push_back needs to reallocate, it will move construct each element. If move
> can throw, it will need to fallback to copy. If copy can throw, there needs
> to be cleanup code in place that will destroy all of the previously copied
> elements and deallocate the new buffer. Finally, for the programmer calling
> push_back. I need to be sure to order the other stuff before and after it
> correctly, so my state doesn't get messed up in the off chance that it
> throws.
>
> For the case of allocations, all of this exception cleanup code is in
> practice dead code. It increases our binary size which also negatively
> impacts the Icache.
>
> Most compilers provide some variant of -fno-exceptions which entirely
> disables exceptions for a performance gain. But what if we want to use
> exceptions carefully in a few places but not suffer the cost of them
> globally from allocations?
>
> So the idea is to have some way to make operator new() noexcept at compile
> time. Probably via a #define. This differs from the nothrow version of new
> because it actually calls std::terminate() if the allocation fails, instead
> of returning nullptr. No only can the compiler assume new will never throw,
> it could also assume it never returns a nullptr.
>
> Also this approach is better than using an allocator. You just switch it
> on and everything works. ABI compatibility should not be a problem as
> separately compiled code can be compiled with or without the feature. For
> any opaque function call that isn't noexcept, we still need to assume it
> can throw anything. This optimization would only be possible in inline
> context.
>
> This noexcept new mode could also improve application correctness. Almost
> nobody ever writes careful code to handle exceptions thrown by new.
>
> People can write catch blocks for std::exception anticipating other
> errors. This will catch allocation errors as well. Since its impossible to
> unit test every possible allocation site, its unlikely to be handled
> properly. It would be better to just crash at the allocation site, with a
> ready stack trace for debugging.
>
> At a minimum, most people write try {} catch {} blocks around the entire
> application in main.
>

.... they do? I don't believe there's a rash of people doing that in `main`.
For obvious reasons.

This completely obscures the source of an exception, especially an out of
> memory error which could happen almost anywhere.
>
> If I accidentally try to allocate INT_MAX somewhere, I'd rather get a core
> dump at the site of the bug than a clean exit from main in a catch{} block.
>
> I don't have hard data on any of this, but I suspect the following things
> are likely true:
> 1. Most C++ applications don't need to handle out of memory conditions and
> just calling std::terminate() immediately at the allocation site is the
> best possible solution.
> 2. The largest source of "possibly can throw" in most applications come
> from things that *might* allocate memory. Mostly from std:: containers.
>

That's a pretty bold statement. You're basically ignoring every other thing
in the standard library that throws something else. Which is quite a lot
(std::filesystem is a big one, just off the top of my head).

Not to mention all of the non-standard library code which might also throw.

3. This mode could give us most of the performance benefits of
> -fno-exceptions while still allowing us to use exceptions in certain parts
> of the system.
>

How, exactly?

It is my understanding that the costs of exception handling are measured in
two ways: executable code size increase, due to the need to provide dynamic
runtime stack unwinding infrastructure; and runtime performance, which in
most implementations is primarily assessed at the time the exception is
thrown/caught. The amount that isn't due to actually throwing/catching
exceptions happens when a `try` block is encountered.

So long as your application can throw exceptions *anywhere*, the compiler
must still provide stack unwinding infrastructure and whatever runtime
performance costs happen on `try` and `throw`s.

The performance problem with exception handling is primarily about the cost
of actually throwing/catching such errors. Which, due in part to the need
to minimize the non-exception case, is quite expensive. That is, people in
the high-performance/real-time world don't want to spend tens of thousands
of cycles just to catch an error condition more conveniently. That causes
unpleasant stalls in systems that really shouldn't have unpleasant stalls.

Of course, there's something else that causes "unpleasant stalls": *memory
allocation*. Which is why that too is avoided in performance-critical code.
So it seems to me that memory allocation already is being avoided in places
where you would turn this feature on.

4. This mode can help us make our systems much simpler and more correct, as
> we don't have to worry about the effectively infinite explosion of possible
> application states from throwing allocations.
>

If you premise #1 is correct, then most systems don't care about the
"infinite explosion of possible application states from throwing
allocations" since they never bother to catch such allocations to begin
with.

5. After removing allocations from concern, tools that analyse how
> exceptions are used in programs might actually be meaningful and possible.
>

In what way are they not "meaningful" or "possible" presently?

Would you use noexcept new in any of your applications?
>

No.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a142da30-270a-4a4b-8c85-b7a2e3cd7169%40isocpp.org.

------=_Part_829_1061190698.1490327207821
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 23, 2017 at 3:05:46 PM UTC-4, Matthew F=
ioravante 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"lt=
r">Right now, operator new() will throw if memory allocation fails.<div><br=
></div><div>The idea is that in theory your application can catch these exc=
eptions and properly clean up. In practice, almost nobody actually handles =
memory allocation exceptions. Most of the time there is no way to handle it=
 properly. Aside from very small carefully controlled situations, its impos=
sible to unit test what happens when each and every allocation fails. If yo=
ur application runs of memory you&#39;re better off just crashing.</div><di=
v><br></div><div>The consequence of this design decision, is that everythin=
g that might do a memory allocation needs to be exception safe. We need to =
write exception safe code and the compiler must also assume any allocation =
can throw and then setup the unwinding structures.</div><div><br></div><div=
>A good example of this, would be something like vector::push_back(). If pu=
sh_back needs to reallocate, it will move construct each element. If move c=
an throw, it will need to fallback to copy. If copy can throw, there needs =
to be cleanup code in place that will destroy all of the previously copied =
elements and deallocate the new buffer. Finally, for the programmer calling=
 push_back. I need to be sure to order the other stuff before and after it =
correctly, so my state doesn&#39;t get messed up in the off chance that it =
throws.</div><div><br></div><div>For the case of allocations, all of this e=
xception cleanup code is in practice dead code. It increases our binary siz=
e which also negatively impacts the Icache.</div><div><br></div><div>Most c=
ompilers provide some variant of -fno-exceptions which entirely disables ex=
ceptions for a performance gain. But what if we want to use exceptions care=
fully in a few places but not suffer the cost of them globally from allocat=
ions?</div><div><br></div><div>So the idea is to have some way to make oper=
ator new() noexcept at compile time. Probably via a #define. This differs f=
rom the nothrow version of new because it actually calls std::terminate() i=
f the allocation fails, instead of returning nullptr. No only can the compi=
ler assume new will never throw, it could also assume it never returns a nu=
llptr.</div><div><br></div><div>Also this approach is better than using an =
allocator. You just switch it on and everything works. ABI compatibility sh=
ould not be a problem as separately compiled code can be compiled with or w=
ithout the feature. For any opaque function call that isn&#39;t noexcept, w=
e still need to assume it can throw anything. This optimization would only =
be possible in inline context.</div><div><br></div><div>This noexcept new m=
ode could also improve application correctness. Almost nobody ever writes c=
areful code to handle exceptions thrown by new.=C2=A0</div><div><br></div><=
div>People can write catch blocks for std::exception anticipating other err=
ors. This will catch allocation errors as well. Since its impossible to uni=
t test every possible allocation site, its unlikely to be handled properly.=
 It would be better to just crash at the allocation site, with a ready stac=
k trace for debugging.</div><div><br></div><div>At a minimum, most people w=
rite try {} catch {} blocks around the entire application in main.</div></d=
iv></blockquote><div><br>... they do? I don&#39;t believe there&#39;s a ras=
h of people doing that in `main`. For obvious reasons.<br><br></div><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> This completel=
y obscures the source of an exception, especially an out of memory error wh=
ich could happen almost anywhere.</div><div><br></div><div>If I accidentall=
y try to allocate INT_MAX somewhere, I&#39;d rather get a core dump at the =
site of the bug than a clean exit from main in a catch{} block.</div><div><=
br></div><div>I don&#39;t have hard data on any of this, but I suspect the =
following things are likely true:</div><div>1. Most C++ applications don&#3=
9;t need to handle out of memory conditions and just calling std::terminate=
() immediately at the allocation site is the best possible solution.</div><=
div>2. The largest source of &quot;possibly can throw&quot; in most applica=
tions come from things that *might* allocate memory. Mostly from std:: cont=
ainers.</div></div></blockquote><div><br>That&#39;s a pretty bold statement=
.. You&#39;re basically ignoring every other thing in the standard library t=
hat throws something else. Which is quite a lot (std::filesystem is a big o=
ne, just off the top of my head).<br><br>Not to mention all of the non-stan=
dard library code which might also throw.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div>3. This mode could give us m=
ost of the performance benefits of -fno-exceptions while still allowing us =
to use exceptions in certain parts of the system.</div></div></blockquote><=
div><br>How, exactly?<br><br>It is my understanding that the costs of excep=
tion handling are measured in two ways: executable code size increase, due =
to the need to provide dynamic runtime stack unwinding infrastructure; and =
runtime performance, which in most implementations is primarily assessed at=
 the time the exception is thrown/caught. The amount that isn&#39;t due to =
actually throwing/catching exceptions happens when a `try` block is encount=
ered.<br><br>So long as your application can throw exceptions <i>anywhere</=
i>, the compiler must still provide stack unwinding infrastructure and what=
ever runtime performance costs happen on `try` and `throw`s.<br><br>The per=
formance problem with exception handling is primarily about the cost of act=
ually throwing/catching such errors. Which, due in part to the need to mini=
mize the non-exception case, is quite expensive. That is, people in the hig=
h-performance/real-time world don&#39;t want to spend tens of thousands of =
cycles just to catch an error condition more conveniently. That causes unpl=
easant stalls in systems that really shouldn&#39;t have unpleasant stalls.<=
br><br>Of course, there&#39;s something else that causes &quot;unpleasant s=
talls&quot;: <i>memory allocation</i>. Which is why that too is avoided in =
performance-critical code. So it seems to me that memory allocation already=
 is being avoided in places where you would turn this feature on.<br><br></=
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>4. T=
his mode can help us make our systems much simpler and more correct, as we =
don&#39;t have to worry about the effectively infinite explosion of possibl=
e application states from throwing allocations.</div></div></blockquote><di=
v><br>If you premise #1 is correct, then most systems don&#39;t care about =
the &quot;infinite explosion of possible application states from throwing a=
llocations&quot; since they never bother to catch such allocations to begin=
 with.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>5. After removing allocations from concern, tools that analys=
e how exceptions are used in programs might actually be meaningful and poss=
ible.</div></div></blockquote><div><br>In what way are they not &quot;meani=
ngful&quot; or &quot;possible&quot; presently?<br><br></div><blockquote cla=
ss=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><div>Would you us=
e noexcept new in any of your applications?</div></div></blockquote><div><b=
r>No.<br></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a142da30-270a-4a4b-8c85-b7a2e3cd7169%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a142da30-270a-4a4b-8c85-b7a2e3cd7169=
%40isocpp.org</a>.<br />

------=_Part_829_1061190698.1490327207821--

------=_Part_828_1891425199.1490327207821--

.

------=_Part_743_58283069.1490390984585
Content-Type: multipart/alternative;
 boundary="----=_Part_744_1420050307.1490390984585"

------=_Part_744_1420050307.1490390984585
Content-Type: text/plain; charset=UTF-8

On Thursday, March 23, 2017 at 12:05:46 PM UTC-7, Matthew Fioravante wrote:
>
> Right now, operator new() will throw if memory allocation fails.
>

This topic has been discussed by SG14 as one of the possible approaches to
solving the "many projects in games/embedded/realtime/etc. use
-fno-exceptions dialect of C++" problem.

The immediate proto-feedback from the committee is that no option that
bifurcates the standard language will be considered for standardization.
.... which to me just means that they enthusiastically support bifurcating
the language because -fno-exceptions already exists and is widely used and
the whole point is to make it unnecessary, but whatever.

There may very well be a case to be made for non-throwing new as a new
implementation-specific option, e.g. something like -fnoexcept-new, though
I'm unsure who the target audience for that would be.

Most compilers provide some variant of -fno-exceptions which entirely
> disables exceptions for a performance gain. But what if we want to use
> exceptions carefully in a few places but not suffer the cost of them
> globally from allocations?
>

An idea I've seen floated before was something like
-fnoexcept-true-by-default . Again, that would never be a part of standard
C++, and any code relying on it would not be compatible with standard C++
(even more so than -fno-exceptions). The difference between the two being
that one would let you opt in to using exceptions by using noexcept(false)
on a case-by-case basis. Aside from being non-standard and even more of a
compatibly problem than just disabling them completely, I also don't think
it actually solves enough of the problems with exceptions to be worth the
bother.


> Also this approach is better than using an allocator. You just switch it
> on and everything works. ABI compatibility should not be a problem as
> separately compiled code can be compiled with or without the feature. For
> any
>

Separately compiled code will definitely still be an ABI problem here. If
you compile foo.cpp with noexcept new (and so it compiles its push_back to
not support throwing new) but then link it with a module that has throwing
new, you'll have ODR violations of push_back.

Adding optional noexcept new is an ABI breakage. Granted, so is
inconsistent use of -fno-exceptions, so it's not a *ahem* new ABI breakage.


> opaque function call that isn't noexcept, we still need to assume it can
> throw anything. This optimization would only be possible in inline context.
>

This assumes the leaves are inlined. I can compile an inlined push_back
that calls out to extern allocator function implemented in a TU with
throwing new. :)


> 3. This mode could give us most of the performance benefits of
> -fno-exceptions while still allowing us to use exceptions in certain parts
> of the system.
>

Don't worry too much about the performance side of this. Modern compilers
do a fairly good job here in terms of runtime performance in
non-exceptional cases. There's certainly other problems, but I'm not
getting involved with debating those for the 576th time. :)

Would you use noexcept new in any of your applications?
>

No, I already have -fno-exceptions. Any change here is going to need to add
a significant value over the status quo and it's going to have to do it
without trying to split the language into standardized dialects. Good luck
with that. :) Though if you have ideas or want to bounce anything past
folks with lots of experience wrestling with exceptions or operating
without them, you might have luck asking on the SG14 reflector.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a492e740-c12a-4416-ae7b-798209337dd2%40isocpp.org.

------=_Part_744_1420050307.1490390984585
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>On Thursday, March 23, 2017 at 12:05:46 PM UTC-7, Mat=
thew Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1=
ex;"><div dir=3D"ltr">Right now, operator new() will throw if memory alloca=
tion fails.</div></blockquote></div><div><br></div>This topic has been disc=
ussed by SG14 as one of the possible approaches to solving the &quot;many p=
rojects in games/embedded/realtime/etc. use -fno-exceptions dialect of C++&=
quot; problem.<div><br></div><div>The immediate proto-feedback from the com=
mittee is that no option that bifurcates the standard language will be cons=
idered for standardization. ... which to me just means that they enthusiast=
ically support bifurcating the language because -fno-exceptions already exi=
sts and is widely used and the whole point is to make it unnecessary, but w=
hatever.<br><br>There may very well be a case to be made for non-throwing n=
ew as a new implementation-specific option, e.g. something like -fnoexcept-=
new, though I&#39;m unsure who the target audience for that would be.<br><b=
r></div><div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>Most compilers provide some variant of -fno-exceptions which entirely =
disables exceptions for a performance gain. But what if we want to use exce=
ptions carefully in a few places but not suffer the cost of them globally f=
rom allocations?</div></div></blockquote><div><br>An idea I&#39;ve seen flo=
ated before was something like -fnoexcept-true-by-default . Again, that wou=
ld never be a part of standard C++, and any code relying on it would not be=
 compatible with standard C++ (even more so than -fno-exceptions). The diff=
erence between the two being that one would let you opt in to using excepti=
ons by using noexcept(false) on a case-by-case basis. Aside from being non-=
standard and even more of a compatibly problem than just disabling them com=
pletely, I also don&#39;t think it actually solves enough of the problems w=
ith exceptions to be worth the bother.<br>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div>Also this approach is better =
than using an allocator. You just switch it on and everything works. ABI co=
mpatibility should not be a problem as separately compiled code can be comp=
iled with or without the feature. For any </div></div></blockquote><div><br=
></div><div>Separately compiled code will definitely still be an ABI proble=
m here. If you compile foo.cpp with noexcept new (and so it compiles its pu=
sh_back to not support throwing new) but then link it with a module that ha=
s throwing new, you&#39;ll have ODR violations of push_back.</div><div><br>=
</div><div>Adding optional noexcept new is an ABI breakage. Granted, so is =
inconsistent use of -fno-exceptions, so it&#39;s not a *ahem* new ABI break=
age.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div>opaque function call that isn&#39;t noexcept, we still n=
eed to assume it can throw anything. This optimization would only be possib=
le in inline context.</div></div></blockquote><div><br></div><div>This assu=
mes the leaves are inlined. I can compile an inlined push_back that calls o=
ut to extern allocator function implemented in a TU with throwing new. :)</=
div><div>=C2=A0</div><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>3. This mode could give us most of the performance benefits o=
f -fno-exceptions while still allowing us to use exceptions in certain part=
s of the system.<br></div></div></blockquote><div><br></div><div>Don&#39;t =
worry too much about the performance side of this. Modern compilers do a fa=
irly good job here in terms of runtime performance in non-exceptional cases=
.. There&#39;s certainly other problems, but I&#39;m not getting involved wi=
th debating those for the 576th time. :)<br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div>Would you use noexcept new in=
 any of your applications?</div></div></blockquote><div><br>No, I already h=
ave -fno-exceptions. Any change here is going to need to add a significant =
value over the status quo and it&#39;s going to have to do it without tryin=
g to split the language into standardized dialects. Good luck with that. :)=
 Though if you have ideas or want to bounce anything past folks with lots o=
f experience wrestling with exceptions or operating without them, you might=
 have luck asking on the SG14 reflector.<br></div></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a492e740-c12a-4416-ae7b-798209337dd2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a492e740-c12a-4416-ae7b-798209337dd2=
%40isocpp.org</a>.<br />

------=_Part_744_1420050307.1490390984585--

------=_Part_743_58283069.1490390984585--

.

------=_Part_1477_1677253712.1490490646033
Content-Type: multipart/alternative;
 boundary="----=_Part_1478_1209359855.1490490646033"

------=_Part_1478_1209359855.1490490646033
Content-Type: text/plain; charset=UTF-8

On Thursday, March 23, 2017 at 8:05:46 PM UTC+1, Matthew Fioravante wrote:
>
> Right now, operator new() will throw if memory allocation fails.
>
> The idea is that in theory your application can catch these exceptions and
> properly clean up. In practice, almost nobody actually handles memory
> allocation exceptions. Most of the time there is no way to handle it
> properly. Aside from very small carefully controlled situations, its
> impossible to unit test what happens when each and every allocation fails.
> If your application runs of memory you're better off just crashing.
>
> The consequence of this design decision, is that everything that might do
> a memory allocation needs to be exception safe. We need to write exception
> safe code and the compiler must also assume any allocation can throw and
> then setup the unwinding structures.
>
> A good example of this, would be something like vector::push_back(). If
> push_back needs to reallocate, it will move construct each element. If move
> can throw, it will need to fallback to copy. If copy can throw, there needs
> to be cleanup code in place that will destroy all of the previously copied
> elements and deallocate the new buffer. Finally, for the programmer calling
> push_back. I need to be sure to order the other stuff before and after it
> correctly, so my state doesn't get messed up in the off chance that it
> throws.
>
> For the case of allocations, all of this exception cleanup code is in
> practice dead code. It increases our binary size which also negatively
> impacts the Icache.
>
> Most compilers provide some variant of -fno-exceptions which entirely
> disables exceptions for a performance gain. But what if we want to use
> exceptions carefully in a few places but not suffer the cost of them
> globally from allocations?
>
> So the idea is to have some way to make operator new() noexcept at compile
> time. Probably via a #define. This differs from the nothrow version of new
> because it actually calls std::terminate() if the allocation fails, instead
> of returning nullptr. No only can the compiler assume new will never throw,
> it could also assume it never returns a nullptr.
>
> Also this approach is better than using an allocator. You just switch it
> on and everything works. ABI compatibility should not be a problem as
> separately compiled code can be compiled with or without the feature. For
> any opaque function call that isn't noexcept, we still need to assume it
> can throw anything. This optimization would only be possible in inline
> context.
>
> This noexcept new mode could also improve application correctness. Almost
> nobody ever writes careful code to handle exceptions thrown by new.
>
> People can write catch blocks for std::exception anticipating other
> errors. This will catch allocation errors as well. Since its impossible to
> unit test every possible allocation site, its unlikely to be handled
> properly. It would be better to just crash at the allocation site, with a
> ready stack trace for debugging.
>
> At a minimum, most people write try {} catch {} blocks around the entire
> application in main. This completely obscures the source of an exception,
> especially an out of memory error which could happen almost anywhere.
>
> If I accidentally try to allocate INT_MAX somewhere, I'd rather get a core
> dump at the site of the bug than a clean exit from main in a catch{} block.
>
> I don't have hard data on any of this, but I suspect the following things
> are likely true:
> 1. Most C++ applications don't need to handle out of memory conditions and
> just calling std::terminate() immediately at the allocation site is the
> best possible solution.
> 2. The largest source of "possibly can throw" in most applications come
> from things that *might* allocate memory. Mostly from std:: containers.
> 3. This mode could give us most of the performance benefits of
> -fno-exceptions while still allowing us to use exceptions in certain parts
> of the system.
> 4. This mode can help us make our systems much simpler and more correct,
> as we don't have to worry about the effectively infinite explosion of
> possible application states from throwing allocations.
> 5. After removing allocations from concern, tools that analyse how
> exceptions are used in programs might actually be meaningful and possible.
>
> Would you use noexcept new in any of your applications?
>

Yes, I would, we seem to write the same type of applications ;-) . I
already regularly add an inline definition of operator new (that's illegal
but for no good reason AFAICS) that just calls malloc (I don't even check
for NULL and terminate), but that does not change the noexcept status of
types so any code-level optimization like move_if_noexcept is missed. Note
that to make a noexcept new really useful, many more functions should be
conditionally noexcept, which is really painful to get right without
noexcept(auto). By the way, I cannot use -fno-exceptions, we do use
exceptions for something else (that happens in a normal run, not to report
errors).
I don't really expect anything to happen at the committee level, providing
this kind of option seems more like something you should ask your compiler
vendor.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7de374a5-d251-4ac6-ab93-02a3c9ac3762%40isocpp.org.

------=_Part_1478_1209359855.1490490646033
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 23, 2017 at 8:05:46 PM UTC+1, Matthew F=
ioravante 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"lt=
r">Right now, operator new() will throw if memory allocation fails.<div><br=
></div><div>The idea is that in theory your application can catch these exc=
eptions and properly clean up. In practice, almost nobody actually handles =
memory allocation exceptions. Most of the time there is no way to handle it=
 properly. Aside from very small carefully controlled situations, its impos=
sible to unit test what happens when each and every allocation fails. If yo=
ur application runs of memory you&#39;re better off just crashing.</div><di=
v><br></div><div>The consequence of this design decision, is that everythin=
g that might do a memory allocation needs to be exception safe. We need to =
write exception safe code and the compiler must also assume any allocation =
can throw and then setup the unwinding structures.</div><div><br></div><div=
>A good example of this, would be something like vector::push_back(). If pu=
sh_back needs to reallocate, it will move construct each element. If move c=
an throw, it will need to fallback to copy. If copy can throw, there needs =
to be cleanup code in place that will destroy all of the previously copied =
elements and deallocate the new buffer. Finally, for the programmer calling=
 push_back. I need to be sure to order the other stuff before and after it =
correctly, so my state doesn&#39;t get messed up in the off chance that it =
throws.</div><div><br></div><div>For the case of allocations, all of this e=
xception cleanup code is in practice dead code. It increases our binary siz=
e which also negatively impacts the Icache.</div><div><br></div><div>Most c=
ompilers provide some variant of -fno-exceptions which entirely disables ex=
ceptions for a performance gain. But what if we want to use exceptions care=
fully in a few places but not suffer the cost of them globally from allocat=
ions?</div><div><br></div><div>So the idea is to have some way to make oper=
ator new() noexcept at compile time. Probably via a #define. This differs f=
rom the nothrow version of new because it actually calls std::terminate() i=
f the allocation fails, instead of returning nullptr. No only can the compi=
ler assume new will never throw, it could also assume it never returns a nu=
llptr.</div><div><br></div><div>Also this approach is better than using an =
allocator. You just switch it on and everything works. ABI compatibility sh=
ould not be a problem as separately compiled code can be compiled with or w=
ithout the feature. For any opaque function call that isn&#39;t noexcept, w=
e still need to assume it can throw anything. This optimization would only =
be possible in inline context.</div><div><br></div><div>This noexcept new m=
ode could also improve application correctness. Almost nobody ever writes c=
areful code to handle exceptions thrown by new.=C2=A0</div><div><br></div><=
div>People can write catch blocks for std::exception anticipating other err=
ors. This will catch allocation errors as well. Since its impossible to uni=
t test every possible allocation site, its unlikely to be handled properly.=
 It would be better to just crash at the allocation site, with a ready stac=
k trace for debugging.</div><div><br></div><div>At a minimum, most people w=
rite try {} catch {} blocks around the entire application in main. This com=
pletely obscures the source of an exception, especially an out of memory er=
ror which could happen almost anywhere.</div><div><br></div><div>If I accid=
entally try to allocate INT_MAX somewhere, I&#39;d rather get a core dump a=
t the site of the bug than a clean exit from main in a catch{} block.</div>=
<div><br></div><div>I don&#39;t have hard data on any of this, but I suspec=
t the following things are likely true:</div><div>1. Most C++ applications =
don&#39;t need to handle out of memory conditions and just calling std::ter=
minate() immediately at the allocation site is the best possible solution.<=
/div><div>2. The largest source of &quot;possibly can throw&quot; in most a=
pplications come from things that *might* allocate memory. Mostly from std:=
: containers.</div><div>3. This mode could give us most of the performance =
benefits of -fno-exceptions while still allowing us to use exceptions in ce=
rtain parts of the system.</div><div>4. This mode can help us make our syst=
ems much simpler and more correct, as we don&#39;t have to worry about the =
effectively infinite explosion of possible application states from throwing=
 allocations.</div><div>5. After removing allocations from concern, tools t=
hat analyse how exceptions are used in programs might actually be meaningfu=
l and possible.</div><div><br></div><div>Would you use noexcept new in any =
of your applications?</div></div></blockquote><div><br>Yes, I would, we see=
m to write the same type of applications ;-) . I already regularly add an i=
nline definition of operator new (that&#39;s illegal but for no good reason=
 AFAICS) that just calls malloc (I don&#39;t even check for NULL and termin=
ate), but that does not change the noexcept status of types so any code-lev=
el optimization like move_if_noexcept is missed. Note that to make a noexce=
pt new really useful, many more functions should be conditionally noexcept,=
 which is really painful to get right without noexcept(auto). By the way, I=
 cannot use -fno-exceptions, we do use exceptions for something else (that =
happens in a normal run, not to report errors).<br>I don&#39;t really expec=
t anything to happen at the committee level, providing this kind of option =
seems more like something you should ask your compiler vendor.<br></div></d=
iv>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7de374a5-d251-4ac6-ab93-02a3c9ac3762%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7de374a5-d251-4ac6-ab93-02a3c9ac3762=
%40isocpp.org</a>.<br />

------=_Part_1478_1209359855.1490490646033--

------=_Part_1477_1677253712.1490490646033--

.

------=_Part_170_1401317546.1490773902605
Content-Type: multipart/alternative;
 boundary="----=_Part_171_1459454297.1490773902606"

------=_Part_171_1459454297.1490773902606
Content-Type: text/plain; charset=UTF-8

Op donderdag 23 maart 2017 20:05:46 UTC+1 schreef Matthew Fioravante:
>
> Would you use noexcept new in any of your applications?
>

 I'd love to use it in all my apps.

I've never seen any app handle out-of-memory better then crashing.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/868626cf-c71a-4e1c-b508-a6c616b75d55%40isocpp.org.

------=_Part_171_1459454297.1490773902606
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Op donderdag 23 maart 2017 20:05:46 UTC+1 schreef Matthew =
Fioravante:<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"><d=
iv>Would you use noexcept new in any of your applications?</div></div></blo=
ckquote><div><br></div><div>=C2=A0I&#39;d love to use it in all my apps.</d=
iv><div><br></div><div>I&#39;ve never seen any app handle out-of-memory bet=
ter then crashing.</div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/868626cf-c71a-4e1c-b508-a6c616b75d55%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/868626cf-c71a-4e1c-b508-a6c616b75d55=
%40isocpp.org</a>.<br />

------=_Part_171_1459454297.1490773902606--

------=_Part_170_1401317546.1490773902605--

.

------=_Part_2270_243830167.1491273331388
Content-Type: multipart/alternative;
 boundary="----=_Part_2271_1199236256.1491273331388"

------=_Part_2271_1199236256.1491273331388
Content-Type: text/plain; charset=UTF-8


>
>
> I've never seen any app handle out-of-memory better then crashing.
>

Ever tried opening a file too large for Photoshop or Notepad++?

At one point last year I did a little survey of just "catch bad_alloc"
(which misses many kinds of OOM handling) in Debian source code and there
were a few hundred opensource packages with perfectly sensible bad_alloc
handling (including Notepad++).

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b3a0d1e5-4f9f-4a6f-9809-a6ded5b082a6%40isocpp.org.

------=_Part_2271_1199236256.1491273331388
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><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><br></div><div>I&#39;ve never seen any app handle out-of-memory be=
tter then crashing.</div></div></blockquote><div><br></div><div>Ever tried =
opening a file too large for Photoshop or Notepad++?<br></div><div><br></di=
v><div>At one point last year I did a little survey of just &quot;catch bad=
_alloc&quot; (which misses many kinds of OOM handling) in Debian source cod=
e and there were a few hundred opensource packages with perfectly sensible =
bad_alloc handling (including Notepad++).=C2=A0<br></div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b3a0d1e5-4f9f-4a6f-9809-a6ded5b082a6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b3a0d1e5-4f9f-4a6f-9809-a6ded5b082a6=
%40isocpp.org</a>.<br />

------=_Part_2271_1199236256.1491273331388--

------=_Part_2270_243830167.1491273331388--

.

------=_Part_905_700954550.1491276007490
Content-Type: multipart/alternative;
 boundary="----=_Part_906_927049526.1491276007490"

------=_Part_906_927049526.1491276007490
Content-Type: text/plain; charset=UTF-8

On Monday, April 3, 2017 at 10:35:31 PM UTC-4, Sergey Zubkov wrote:
>
>
>> I've never seen any app handle out-of-memory better then crashing.
>>
>
> Ever tried opening a file too large for Photoshop or Notepad++?
>

I assumed they just checked the file size before they loaded it, and
changed how they worked based on that.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d567419c-a109-4913-8e67-a64f9d7db329%40isocpp.org.

------=_Part_906_927049526.1491276007490
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, April 3, 2017 at 10:35:31 PM UTC-4, Sergey Zubk=
ov 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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>I&=
#39;ve never seen any app handle out-of-memory better then crashing.</div><=
/div></blockquote><div><br></div><div>Ever tried opening a file too large f=
or Photoshop or Notepad++?<br></div></div></blockquote><div><br>I assumed t=
hey just checked the file size before they loaded it, and changed how they =
worked based on that.</div><br></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d567419c-a109-4913-8e67-a64f9d7db329%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d567419c-a109-4913-8e67-a64f9d7db329=
%40isocpp.org</a>.<br />

------=_Part_906_927049526.1491276007490--

------=_Part_905_700954550.1491276007490--

.

------=_Part_896_1149823690.1491290120672
Content-Type: multipart/alternative;
 boundary="----=_Part_897_1117538141.1491290120672"

------=_Part_897_1117538141.1491290120672
Content-Type: text/plain; charset=UTF-8



Op dinsdag 4 april 2017 04:35:31 UTC+2 schreef Sergey Zubkov:
>
>
>> I've never seen any app handle out-of-memory better then crashing.
>>
>
> Ever tried opening a file too large for Photoshop or Notepad++?
>

Nope


>
> At one point last year I did a little survey of just "catch bad_alloc"
> (which misses many kinds of OOM handling) in Debian source code and there
> were a few hundred opensource packages with perfectly sensible bad_alloc
> handling (including Notepad++).
>

I find bad_alloc 6x in Notepad++'s source. First one is:

} catch (std::bad_alloc&) {
errorStatus = SC_STATUS_BADALLOC;
} catch (...) {
errorStatus = SC_STATUS_FAILURE;
}

AFAIK the catch all isn't recommended practice..

Second one is a comment: wl[i] = new WordList(); // (works or THROWS
bad_alloc EXCEPTION)
in a function with raw new and delete that's obviously not exception safe.

Third, fifth and sixth one are like the first one.

Fourth one:
int SCI_METHOD Document::AddData(char *data, int length) {
try {
int position = Length();
InsertString(position, data, length);
} catch (std::bad_alloc &) {
return SC_STATUS_BADALLOC;
} catch (...) {
return SC_STATUS_FAILURE;
}
return 0;
}

Is this what we call perfectly sensible?
And are we sure all state is in a good state after an exception is thrown
and caught?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b8de1da9-28f6-4be4-b926-02ac1fdbae77%40isocpp.org.

------=_Part_897_1117538141.1491290120672
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Op dinsdag 4 april 2017 04:35:31 UTC+2 schreef Ser=
gey Zubkov:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><b=
lockquote 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><br></div><div>=
I&#39;ve never seen any app handle out-of-memory better then crashing.</div=
></div></blockquote><div><br></div><div>Ever tried opening a file too large=
 for Photoshop or Notepad++?<br></div></div></blockquote><div><br></div><di=
v>Nope</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div></div><div><br></div><div>At one point last year I did=
 a little survey of just &quot;catch bad_alloc&quot; (which misses many kin=
ds of OOM handling) in Debian source code and there were a few hundred open=
source packages with perfectly sensible bad_alloc handling (including Notep=
ad++).=C2=A0<br></div></div></blockquote><div><br></div><div>I find bad_all=
oc 6x in Notepad++&#39;s source. First one is:</div><div><br></div><div><sp=
an class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>} catch (std:=
:bad_alloc&amp;) {</div><div><span class=3D"Apple-tab-span" style=3D"white-=
space:pre">  </span>errorStatus =3D SC_STATUS_BADALLOC;</div><div><span cla=
ss=3D"Apple-tab-span" style=3D"white-space:pre"> </span>} catch (...) {</di=
v><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">  </span>er=
rorStatus =3D SC_STATUS_FAILURE;</div><div><span class=3D"Apple-tab-span" s=
tyle=3D"white-space:pre"> </span>}</div><div>=C2=A0</div><div>AFAIK the cat=
ch all isn&#39;t recommended practice..</div><div><br></div><div>Second one=
 is a comment: wl[i] =3D new WordList();<span class=3D"Apple-tab-span" styl=
e=3D"white-space: pre;"> </span>// (works or THROWS bad_alloc EXCEPTION)</d=
iv><div>in a function with raw new and delete that&#39;s obviously not exce=
ption safe.</div><div><br></div><div>Third, fifth and sixth one are like th=
e first one.</div><div><br></div><div>Fourth one:</div><div><div>int SCI_ME=
THOD Document::AddData(char *data, int length) {</div><div><span class=3D"A=
pple-tab-span" style=3D"white-space:pre"> </span>try {</div><div><span clas=
s=3D"Apple-tab-span" style=3D"white-space:pre">  </span>int position =3D Le=
ngth();</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">=
  </span>InsertString(position, data, length);</div><div><span class=3D"App=
le-tab-span" style=3D"white-space:pre"> </span>} catch (std::bad_alloc &amp=
;) {</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">  <=
/span>return SC_STATUS_BADALLOC;</div><div><span class=3D"Apple-tab-span" s=
tyle=3D"white-space:pre"> </span>} catch (...) {</div><div><span class=3D"A=
pple-tab-span" style=3D"white-space:pre">  </span>return SC_STATUS_FAILURE;=
</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span=
>}</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </sp=
an>return 0;</div><div>}</div></div><div><br></div><div>Is this what we cal=
l perfectly sensible?</div><div>And are we sure all state is in a good stat=
e after an exception is thrown and caught?</div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b8de1da9-28f6-4be4-b926-02ac1fdbae77%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b8de1da9-28f6-4be4-b926-02ac1fdbae77=
%40isocpp.org</a>.<br />

------=_Part_897_1117538141.1491290120672--

------=_Part_896_1149823690.1491290120672--

.

------=_Part_1466_264101403.1491306361059
Content-Type: multipart/alternative;
 boundary="----=_Part_1467_505815596.1491306361059"

------=_Part_1467_505815596.1491306361059
Content-Type: text/plain; charset=UTF-8


>
>
> Is this what we call perfectly sensible?
>

Yes, undo of all data structures built so far and a pop-up informing the
user that operation they requested could not be perfomed (file load, print
preview, image resize, etc) is one of the most common types of OOM handlers
in the wild, though I like seeing non-interactive handling like audacity's
buffer shrinking or scylladb's transaction rollback or xorp's corrupt
packet dropping, or armadillo's STL-like space/time tradeoff etc.

In my professional career, C++ was chosen exactly because of the resilience
and guarantees offered by exception handling and it's a little scary to see
how popular the meme "If your application runs of memory you're better off
just crashing" has become.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c1714549-ede0-42b7-9789-75ee33865d18%40isocpp.org.

------=_Part_1467_505815596.1491306361059
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><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><br></div><div>Is this what we call perfectly sensible?</div></div=
></blockquote><div><br></div><div>Yes, undo of all data structures built so=
 far and a pop-up informing the user that operation they requested could no=
t be perfomed (file load, print preview, image resize, etc) is one of the m=
ost common types of OOM handlers in the wild, though I like seeing non-inte=
ractive handling like audacity&#39;s buffer shrinking or scylladb&#39;s tra=
nsaction rollback or xorp&#39;s corrupt packet dropping, or armadillo&#39;s=
 STL-like space/time tradeoff etc.</div><div><br></div><div>In my professio=
nal career, C++ was chosen exactly because of the resilience and guarantees=
 offered by exception handling and it&#39;s a little scary to see how popul=
ar the meme &quot;If your application runs of memory you&#39;re better off =
just crashing&quot; has become.</div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c1714549-ede0-42b7-9789-75ee33865d18%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c1714549-ede0-42b7-9789-75ee33865d18=
%40isocpp.org</a>.<br />

------=_Part_1467_505815596.1491306361059--

------=_Part_1466_264101403.1491306361059--

.

------=_Part_1210_883348678.1491333517716
Content-Type: multipart/alternative;
 boundary="----=_Part_1211_918508521.1491333517716"

------=_Part_1211_918508521.1491333517716
Content-Type: text/plain; charset=UTF-8

Op dinsdag 4 april 2017 13:46:01 UTC+2 schreef Sergey Zubkov:
>
>
>> Is this what we call perfectly sensible?
>>
>
> Yes, undo of all data structures built so far
>

Are we sure this is done correctly? Is it tested properly? I'm not a fan of
silent data corruption.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7fd4fd54-b049-449f-8258-b76eb66e9b5e%40isocpp.org.

------=_Part_1211_918508521.1491333517716
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Op dinsdag 4 april 2017 13:46:01 UTC+2 schreef Sergey Zubk=
ov:<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"><blockquot=
e 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><br></div><div>Is this =
what we call perfectly sensible?</div></div></blockquote><div><br></div><di=
v>Yes, undo of all data structures built so far </div></div></blockquote><d=
iv><br></div><div>Are we sure this is done correctly? Is it tested properly=
? I&#39;m not a fan of silent data corruption.</div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7fd4fd54-b049-449f-8258-b76eb66e9b5e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7fd4fd54-b049-449f-8258-b76eb66e9b5e=
%40isocpp.org</a>.<br />

------=_Part_1211_918508521.1491333517716--

------=_Part_1210_883348678.1491333517716--

.

------=_Part_3377_1874903050.1491396091000
Content-Type: multipart/alternative;
 boundary="----=_Part_3378_772420435.1491396091000"

------=_Part_3378_772420435.1491396091000
Content-Type: text/plain; charset=UTF-8


>
>
>>> Yes, undo of all data structures built so far
>>
>
> Are we sure this is done correctly? Is it tested properly? I'm not a fan
> of silent data corruption.
>

I am sure stack unwinding is done correctly and, in acceptable C++ code,
invariants are guaranteed by construction. Testing of error handling is a
worthwhile discussion, but that would take the focus away from the topic of
this thread - I'm just here to point out that many (though not a majority)
C++ applications handle OOM conditions by means other than termination, and
for some it is a critical part of operation.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d33f9368-8515-476b-a412-b13c7fa516e5%40isocpp.org.

------=_Part_3378_772420435.1491396091000
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><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"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div></div></blockquot=
e><div>Yes, undo of all data structures built so far </div></div></blockquo=
te><div><br></div><div>Are we sure this is done correctly? Is it tested pro=
perly? I&#39;m not a fan of silent data corruption.</div></div></blockquote=
><div><br></div><div>I am sure stack unwinding is done correctly and, in ac=
ceptable C++ code, invariants are guaranteed by construction. Testing of er=
ror handling is a worthwhile discussion, but that would take the focus away=
 from the topic of this thread - I&#39;m just here to point out that many (=
though not a majority) C++ applications handle OOM conditions by means othe=
r than termination, and for some it is a critical part of operation.</div><=
/div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d33f9368-8515-476b-a412-b13c7fa516e5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d33f9368-8515-476b-a412-b13c7fa516e5=
%40isocpp.org</a>.<br />

------=_Part_3378_772420435.1491396091000--

------=_Part_3377_1874903050.1491396091000--

.

2017-04-05 14:41 GMT+02:00 Sergey Zubkov <cubbimew@gmail.com>:
>>>>
>>> Yes, undo of all data structures built so far
>>
>>
>> Are we sure this is done correctly? Is it tested properly? I'm not a fan
>> of silent data corruption.
>
>
> I am sure stack unwinding is done correctly and, in acceptable C++ code,
> invariants are guaranteed by construction. Testing of error handling is a
> worthwhile discussion, but that would take the focus away from the topic of
> this thread - I'm just here to point out that many (though not a majority)
> C++ applications handle OOM conditions by means other than termination, and
> for some it is a critical part of operation.

Fair enough. But for apps that don't catch bad_alloc having it be
noexcept would be a benefit, wouldn't it?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7U3HM5ReRVcYsE1B5MJskH%3Da8jb1fR_uzAqvHaB1vMirZeBA%40mail.gmail.com.

.

------=_Part_3423_1088738254.1491397625896
Content-Type: multipart/alternative;
 boundary="----=_Part_3424_2096975476.1491397625897"

------=_Part_3424_2096975476.1491397625897
Content-Type: text/plain; charset=UTF-8


>
> Fair enough. But for apps that don't catch bad_alloc having it be
> noexcept would be a benefit, wouldn't it?
>
> Well.. yes, there are benefits to being able to put "noexcept" on many
functions that might transitively end up allocating something.
This is viral. In fact, there is precedent: g_malloc from the ubiquitous
glib terminates on OOM. They have a "try" variant, but numerous libraries
that use glib just call g_malloc, and that infects a large part of the
Linux ecosystem. For example, Mozilla does some heroics to survive many
OOMs, except when the last straw allocation happens to be a g_malloc deep
in the call stack across several third-party libraries.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b74cd4bc-e54d-43ad-a7c9-4bfb878530b8%40isocpp.org.

------=_Part_3424_2096975476.1491397625897
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Fair enough. =
But for apps that don&#39;t catch bad_alloc having it be
<br>noexcept would be a benefit, wouldn&#39;t it?
<br><br></blockquote><div>Well.. yes, there are benefits to being able to p=
ut &quot;noexcept&quot; on many functions that might transitively end up al=
locating something.</div><div>This is viral. In fact, there is precedent: g=
_malloc from the ubiquitous glib terminates on OOM. They have a &quot;try&q=
uot; variant, but numerous libraries that use glib just call g_malloc, and =
that infects a large part of the Linux ecosystem. For example, Mozilla does=
 some heroics to survive many OOMs, except when the last straw allocation h=
appens to be a g_malloc deep in the call stack across several third-party l=
ibraries.=C2=A0</div></div>

<p></p>

-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b74cd4bc-e54d-43ad-a7c9-4bfb878530b8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b74cd4bc-e54d-43ad-a7c9-4bfb878530b8=
%40isocpp.org</a>.<br />

------=_Part_3424_2096975476.1491397625897--

------=_Part_3423_1088738254.1491397625896--

.

2017-04-05 15:07 GMT+02:00 Sergey Zubkov <cubbimew@gmail.com>:
>> Fair enough. But for apps that don't catch bad_alloc having it be
>> noexcept would be a benefit, wouldn't it?
>>
> Well.. yes, there are benefits to being able to put "noexcept" on many
> functions that might transitively end up allocating something.

I'm not sure 'manual' noexcept is the right a recipe here. It'd be
nice if the compiler could take care of this.

> This is viral. In fact, there is precedent: g_malloc from the ubiquitous
> glib terminates on OOM. They have a "try" variant, but numerous libraries
> that use glib just call g_malloc, and that infects a large part of the Linux
> ecosystem. For example, Mozilla does some heroics to survive many OOMs,
> except when the last straw allocation happens to be a g_malloc deep in the
> call stack across several third-party libraries.



--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7U3HO-NxQ%3D_1DgM%2BhM55rAyj%2BwDTJTdmwiZbVgsg-JzeZFpA%40mail.gmail.com.

.