------=_Part_2_1162300634.1429089260204
Content-Type: multipart/alternative;
 boundary="----=_Part_3_1275502526.1429089260204"

------=_Part_3_1275502526.1429089260204
Content-Type: text/plain; charset=UTF-8



Lots of programs abort / terminate when new fails to allocate memory. Would it be possible to make new noexcept, simplifying programs and possibly allowing more optimizations as noexcept will have a ripple effect?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><pre style=3D"color: rgb(0, 0, 0);">Lots of programs abort=
 / terminate when new fails to allocate memory. Would it be possible to mak=
e new noexcept, simplifying programs and possibly allowing more optimizatio=
ns as noexcept will have a ripple effect?</pre></div>

<p></p>

-- <br />
<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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3_1275502526.1429089260204--
------=_Part_2_1162300634.1429089260204--

.

On Wednesday 15 April 2015 02:14:20 Olaf van der Spek wrote:
> Lots of programs abort / terminate when new fails to allocate memory. Would
> it be possible to make new noexcept, simplifying programs and possibly
> allowing more optimizations as noexcept will have a ripple effect?

There is operator new (size_t, nothrow_t) which returns NULL in case of
failure. You will have to check the result and handle the failure anyway.

If you're proposing a change to return NULL by default then I would disagree.
Better have an exception and a proper handling of errors instead of crashing
the process because of a forgotten manual check.

--

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

.

2015-04-15 11:14 GMT+02:00 Olaf van der Spek <olafvdspek@gmail.com>:
> Lots of programs abort / terminate when new fails to allocate memory. Would
> it be possible to make new noexcept, simplifying programs and possibly
> allowing more optimizations as noexcept will have a ripple effect?

1) What do you expect should the system do, if there is no more memory
available?

2) Why don't you use the non-array variant "new (std::nothrow)"  which
*is* noexcept and returns null on failure?

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_995B6658-CE30-4527-974C-169C9B65296C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9304=E2=80=9315, at 5:14 PM, Olaf van der Spek <olafvdspek@=
gmail.com> wrote:
> Lots of programs abort / terminate when new fails to allocate memory. Wou=
ld it be possible to make new noexcept, simplifying programs and possibly a=
llowing more optimizations as noexcept will have a ripple effect?
As long as you pass std::nothrow, it=E2=80=99s always been noexcept. (Befor=
e C++11, it was spelled throw().)

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_995B6658-CE30-4527-974C-169C9B65296C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9315, at 5:14 PM, Olaf van der Spek &lt;<a href=3D"mailto:olafvdspek=
@gmail.com" class=3D"">olafvdspek@gmail.com</a>&gt; wrote:</div><div class=
=3D""><div dir=3D"ltr" class=3D""><pre style=3D"" class=3D"">Lots of progra=
ms abort / terminate when new fails to allocate memory. Would it be possibl=
e to make new noexcept, simplifying programs and possibly allowing more opt=
imizations as noexcept will have a ripple effect?</pre></div></div></blockq=
uote><div>As long as you pass <font face=3D"Courier" class=3D"">std::nothro=
w</font>, it=E2=80=99s always been <font face=3D"Courier" class=3D"">noexce=
pt</font>. (Before C++11, it was spelled <font face=3D"Courier" class=3D"">=
throw()</font>.)</div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_995B6658-CE30-4527-974C-169C9B65296C--

.

2015-04-15 11:22 GMT+02:00 Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com>:
> 2015-04-15 11:14 GMT+02:00 Olaf van der Spek <olafvdspek@gmail.com>:
>> Lots of programs abort / terminate when new fails to allocate memory. Wo=
uld
>> it be possible to make new noexcept, simplifying programs and possibly
>> allowing more optimizations as noexcept will have a ripple effect?
>
> 1) What do you expect should the system do, if there is no more memory
> available?

abort() / terminate() / call some user-supplied header

> 2) Why don't you use the non-array variant "new (std::nothrow)"  which
> *is* noexcept and returns null on failure?

See 1. ;)


--=20
Olaf

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

2015-04-15 11:27 GMT+02:00 Olaf van der Spek <olafvdspek@gmail.com>:
> 2015-04-15 11:22 GMT+02:00 Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com=
>:
>> 2015-04-15 11:14 GMT+02:00 Olaf van der Spek <olafvdspek@gmail.com>:
>>> Lots of programs abort / terminate when new fails to allocate memory. W=
ould
>>> it be possible to make new noexcept, simplifying programs and possibly
>>> allowing more optimizations as noexcept will have a ripple effect?
>>
>> 1) What do you expect should the system do, if there is no more memory
>> available?
>
> abort() / terminate() / call some user-supplied header

This surely would break the existing contract and looks like a no-go to me.

>> 2) Why don't you use the non-array variant "new (std::nothrow)"  which
>> *is* noexcept and returns null on failure?
>
> See 1. ;)

This looks like a very special use case to me. I'm pretty sure that
changing the existing behaviour is not an acceptable option. You could
provide your own noexcept allocating function that behaves as you
intend. You could actively help working with feature-testing
recommendations as described in this paper,

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4440.html

and take advantage of the recommended feature __cpp_exceptions and
check whether existing systems that would then not define this feature
(embedded system compilers, presumably), would mark operator new as
noexcept in such a special environment.

- Daniel

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--Apple-Mail=_BA1DDD6C-0226-4488-AC76-F0B6C96A5CEB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9304=E2=80=9315, at 5:27 PM, Olaf van der Spek <olafvdspek@=
gmail.com> wrote:
>=20
> 2015-04-15 11:22 GMT+02:00 Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com=
>:
>>=20
>> 1) What do you expect should the system do, if there is no more memory
>> available?
>=20
> abort() / terminate() / call some user-supplied header

You could define your own ::operator new to do this. But, it would have to =
call malloc (or whatever). And, your declaration would have to precede all =
uses, because using the implicitly-declared ::operator new would seem to ru=
n afoul of [except.spec] =C2=A715.4/5, in spirit at least. This rules out l=
inking against any third-party libraries.

It=E2=80=99s likely that the UB won=E2=80=99t bite you, and technically the=
re might be no non-noexcept declaration to which =C2=A715.4/5 would apply. =
However, there=E2=80=99s a real problem that the noexcept operator would yi=
eld wrong results for new-expressions in TUs lacking the declaration.

Why don=E2=80=99t we have a standard library function for the default ::ope=
rator new behavior? It would have quite a few use-cases.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_BA1DDD6C-0226-4488-AC76-F0B6C96A5CEB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9315, at 5:27 PM, Olaf van der Spek &lt;<a href=3D"mailto:olafvdspek=
@gmail.com" class=3D"">olafvdspek@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><div class=3D"">2015-04-15 11:22 GMT+02:00 D=
aniel Kr=C3=BCgler &lt;<a href=3D"mailto:daniel.kruegler@gmail.com" class=
=3D"">daniel.kruegler@gmail.com</a>&gt;:<br class=3D""><blockquote type=3D"=
cite" class=3D""><br class=3D"">1) What do you expect should the system do,=
 if there is no more memory<br class=3D"">available?<br class=3D""></blockq=
uote><br class=3D"">abort() / terminate() / call some user-supplied header<=
br class=3D""></div></blockquote><div><br class=3D""></div><div>You could d=
efine your own <font face=3D"Courier" class=3D"">::operator new</font>&nbsp=
;to do this. But, it would have to call <font face=3D"Courier" class=3D"">m=
alloc</font> (or whatever). And, your declaration would have to precede all=
 uses, because using the implicitly-declared&nbsp;<span style=3D"font-famil=
y: Courier;" class=3D"">::operator new</span>&nbsp;would seem to run afoul =
of [except.spec] =C2=A715.4/5, in spirit at least. This rules out linking a=
gainst any third-party libraries.</div><div><br class=3D""></div><div>It=E2=
=80=99s likely that the UB won=E2=80=99t bite you, and technically there mi=
ght be no non-<font face=3D"Courier" class=3D"">noexcept</font> declaration=
 to which =C2=A715.4/5 would apply. However, there=E2=80=99s a real problem=
 that the&nbsp;<span style=3D"font-family: Courier;" class=3D"">noexcept</s=
pan>&nbsp;operator would yield wrong results for new-expressions in TUs lac=
king the declaration.</div><div><br class=3D""></div><div>Why don=E2=80=99t=
 we have a standard library function for the default <font face=3D"Courier"=
 class=3D"">::operator new</font> behavior? It would have quite a few use-c=
ases.</div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_BA1DDD6C-0226-4488-AC76-F0B6C96A5CEB--

.

On Wednesday 15 April 2015 11:27:57 Olaf van der Spek wrote:
> 2015-04-15 11:22 GMT+02:00 Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com=
>:
> > 2015-04-15 11:14 GMT+02:00 Olaf van der Spek <olafvdspek@gmail.com>:
> >> Lots of programs abort / terminate when new fails to allocate memory.
> >> Would
> >> it be possible to make new noexcept, simplifying programs and possibly
> >> allowing more optimizations as noexcept will have a ripple effect?
> >=20
> > 1) What do you expect should the system do, if there is no more memory
> > available?
>=20
> abort() / terminate() / call some user-supplied header

Isn't set_new_handler() suitable?

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

.

2015-04-15 11:42 GMT+02:00 Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com>:
>> abort() / terminate() / call some user-supplied header
>
> This surely would break the existing contract and looks like a no-go to m=
e.
>
>>> 2) Why don't you use the non-array variant "new (std::nothrow)"  which
>>> *is* noexcept and returns null on failure?
>>
>> See 1. ;)
>
> This looks like a very special use case to me. I'm pretty sure that

Does it? Why? Most programs abort / terminate on out of memory anyway
so it doesn't seem that special to me.


> changing the existing behaviour is not an acceptable option. You could
> provide your own noexcept allocating function that behaves as you
> intend. You could actively help working with feature-testing
> recommendations as described in this paper,
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4440.html
>
> and take advantage of the recommended feature __cpp_exceptions and
> check whether existing systems that would then not define this feature
> (embedded system compilers, presumably), would mark operator new as
> noexcept in such a special environment.

I don't get how this relates to not having exceptions at all.
Obviously if there are no exceptions at all this isn't really an
issue.



--=20
Olaf

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Wednesday 15 April 2015 12:25:22 Olaf van der Spek wrote:
> 2015-04-15 11:42 GMT+02:00 Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com=
>:
> >> abort() / terminate() / call some user-supplied header
> >=20
> > This surely would break the existing contract and looks like a no-go to
> > me.
> >=20
> >>> 2) Why don't you use the non-array variant "new (std::nothrow)"  whic=
h
> >>> *is* noexcept and returns null on failure?
> >>=20
> >> See 1. ;)
> >=20
> > This looks like a very special use case to me. I'm pretty sure that
>=20
> Does it? Why? Most programs abort / terminate on out of memory anyway
> so it doesn't seem that special to me.

I'd say most programs don't care about crashing. The programs that do care=
=20
also handle memory allocation errors in a sensible way. The language helps =
the=20
latter (the former don't care anyway).

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

.

2015-04-15 12:25 GMT+02:00 Olaf van der Spek <olafvdspek@gmail.com>:
> 2015-04-15 11:42 GMT+02:00 Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com=
>:
>>> abort() / terminate() / call some user-supplied header
>>
>> This surely would break the existing contract and looks like a no-go to =
me.
>>
>>>> 2) Why don't you use the non-array variant "new (std::nothrow)"  which
>>>> *is* noexcept and returns null on failure?
>>>
>>> See 1. ;)
>>
>> This looks like a very special use case to me. I'm pretty sure that
>
> Does it? Why? Most programs abort / terminate on out of memory anyway
> so it doesn't seem that special to me.

It is special. Even if your specific application may not intend to
handle it, there exists conforming C++ code that relies on the
existing contract. I see no reason to change this contract based on an
IMO wobbly and narrow argument. The general criterion for functions
marked as unconditionally noexcept is that they cannot fail. But
several of the existing dynamic memory allocation clearly *can* fail.
If *you* intend to decide that such conditions should result in a
program termination, than *you* can easily decide that for such a
behaviour and simply consider these functions as noexcept - Just wrap
them in a function marked as noexcept and forward the call. This will
have the intended effect to terminate, if these memory allocation
functions would fail. But when the committee would follow your
proposal, it would now *constrain* the freedom of existing programs to
decide what happens when these function fail. The latter is IMO
unacceptable to me without seeing good arguments presented.

> I don't get how this relates to not having exceptions at all.
> Obviously if there are no exceptions at all this isn't really an issue.

Your original proposal did not explain much, especially it did not
provide any concrete use-case. Based on your radical proposal for a
clearly failable function the natural interpretation for me was that
you are involved in systems where exceptions have a very little (or
no) usage, such as embedded systems.

I strongly suggest to provide better rationale for such
contract-breaking proposals. It is important to understand what the
reasons are for such a change, who would benefit from it and who would
need to change his code when this change would not be acceptable for
his/her program.

- Daniel

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

.

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

El 15/4/2015 6:46, "Andrey Semashev" <andrey.semashev@gmail.com> escribi=C3=
=B3:
>
> On Wednesday 15 April 2015 11:27:57 Olaf van der Spek wrote:
> > 2015-04-15 11:22 GMT+02:00 Daniel Kr=C3=BCgler <daniel.kruegler@gmail.c=
om>:
> > > 2015-04-15 11:14 GMT+02:00 Olaf van der Spek <olafvdspek@gmail.com>:
> > >> Lots of programs abort / terminate when new fails to allocate memory=
..
> > >> Would
> > >> it be possible to make new noexcept, simplifying programs and
possibly
> > >> allowing more optimizations as noexcept will have a ripple effect?
> > >
> > > 1) What do you expect should the system do, if there is no more memor=
y
> > > available?
> >
> > abort() / terminate() / call some user-supplied header
>
> Isn't set_new_handler() suitable?

FWIW see last page of
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4234.pdf

>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<p dir=3D"ltr"><br>
El 15/4/2015 6:46, &quot;Andrey Semashev&quot; &lt;<a href=3D"mailto:andrey=
..semashev@gmail.com">andrey.semashev@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; On Wednesday 15 April 2015 11:27:57 Olaf van der Spek wrote:<br>
&gt; &gt; 2015-04-15 11:22 GMT+02:00 Daniel Kr=C3=BCgler &lt;<a href=3D"mai=
lto:daniel.kruegler@gmail.com">daniel.kruegler@gmail.com</a>&gt;:<br>
&gt; &gt; &gt; 2015-04-15 11:14 GMT+02:00 Olaf van der Spek &lt;<a href=3D"=
mailto:olafvdspek@gmail.com">olafvdspek@gmail.com</a>&gt;:<br>
&gt; &gt; &gt;&gt; Lots of programs abort / terminate when new fails to all=
ocate memory.<br>
&gt; &gt; &gt;&gt; Would<br>
&gt; &gt; &gt;&gt; it be possible to make new noexcept, simplifying program=
s and possibly<br>
&gt; &gt; &gt;&gt; allowing more optimizations as noexcept will have a ripp=
le effect?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 1) What do you expect should the system do, if there is no m=
ore memory<br>
&gt; &gt; &gt; available?<br>
&gt; &gt;<br>
&gt; &gt; abort() / terminate() / call some user-supplied header<br>
&gt;<br>
&gt; Isn&#39;t set_new_handler() suitable?</p>
<p dir=3D"ltr">FWIW see last page of <a href=3D"http://www.open-std.org/jtc=
1/sc22/wg21/docs/papers/2014/n4234.pdf">http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2014/n4234.pdf</a></p>
<p dir=3D"ltr">&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

<p></p>

-- <br />
<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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113f90365e351a0513c2a6c5--

.

On 15 April 2015 at 13:25, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> Does it? Why? Most programs abort / terminate on out of memory anyway
> so it doesn't seem that special to me.

What sort of a survey is this statement based on?

--

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

.

On 15 April 2015 at 14:45, Andrey Semashev <andrey.semashev@gmail.com> wrote:
>> Does it? Why? Most programs abort / terminate on out of memory anyway
>> so it doesn't seem that special to me.
> I'd say most programs don't care about crashing. The programs that do care
> also handle memory allocation errors in a sensible way. The language helps the
> latter (the former don't care anyway).

I'd say people are flinging out these "I'd say..." statements so
recklessly that it's not
funny. C++ is a general-purpose programming language that happens to direct vast
amounts of uses beyond toy programs that do not care whether allocations fail
or whether the programs themselves crash.

--

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

.

On Wednesday 15 April 2015 15:52:36 Ville Voutilainen wrote:
> On 15 April 2015 at 14:45, Andrey Semashev <andrey.semashev@gmail.com>
wrote:
> >> Does it? Why? Most programs abort / terminate on out of memory anyway
> >> so it doesn't seem that special to me.
> >
> > I'd say most programs don't care about crashing. The programs that do care
> > also handle memory allocation errors in a sensible way. The language helps
> > the latter (the former don't care anyway).
>
> I'd say people are flinging out these "I'd say..." statements so
> recklessly that it's not funny.

That's just my observation.

> C++ is a general-purpose programming language that happens to direct
> vast amounts of uses beyond toy programs that do not care whether
> allocations fail or whether the programs themselves crash.

Not arguing with that.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Wednesday 15 April 2015 02:14:20 Olaf van der Spek wrote:
> Lots of programs abort / terminate when new fails to allocate memory. Would
> it be possible to make new noexcept, simplifying programs and possibly
> allowing more optimizations as noexcept will have a ripple effect?

operator new is overridable. So override it and abort() if malloc() returns
NULL.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Wednesday 15 April 2015 14:45:30 Andrey Semashev wrote:
> I'd say most programs don't care about crashing. The programs that do care
> also handle memory allocation errors in a sensible way. The language helps
> the  latter (the former don't care anyway).

Actually, most userspace programs on modern operating systems with virtual
memory do not care about running out of memory. They don't like crashing, but
it's better to reliably abort execution on OOM than to have problems elsewhere
due to poor coding of the OOM condition.

Or getting killed later by the OOM killer or when you get a SIGBUS as the OS
could not deliver the page you had successfully allocated.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Wed, Apr 15, 2015 at 10:27 AM, Olaf van der Spek <olafvdspek@gmail.com>
wrote:

> 2015-04-15 11:22 GMT+02:00 Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com=
>:
> > 2015-04-15 11:14 GMT+02:00 Olaf van der Spek <olafvdspek@gmail.com>:
> >> Lots of programs abort / terminate when new fails to allocate memory.
> Would
> >> it be possible to make new noexcept, simplifying programs and possibly
> >> allowing more optimizations as noexcept will have a ripple effect?
> >
> > 1) What do you expect should the system do, if there is no more memory
> > available?
>
> abort() / terminate() / call some user-supplied header
>
>
And if a program cannot afford to abort() / terminate() (e.g. servers /
operating systems / embedded systems, etc.)?


> > 2) Why don't you use the non-array variant "new (std::nothrow)"  which
> > *is* noexcept and returns null on failure?
>
> See 1. ;)
>
>
> --
> 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/.
>

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

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

<br>
<div class=3D"gmail_quote">On Wed, Apr 15, 2015 at 10:27 AM, Olaf van der S=
pek <span dir=3D"ltr">&lt;<a href=3D"mailto:olafvdspek@gmail.com" target=3D=
"_blank">olafvdspek@gmail.com</a>&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote"><span>2015-04-15 11:22 GMT+02:00 Dani=
el Kr=C3=BCgler &lt;<a href=3D"mailto:daniel.kruegler@gmail.com">daniel.kru=
egler@gmail.com</a>&gt;:<br>&gt; 2015-04-15 11:14 GMT+02:00 Olaf van der Sp=
ek &lt;<a href=3D"mailto:olafvdspek@gmail.com">olafvdspek@gmail.com</a>&gt;=
:<br>&gt;&gt; Lots of programs abort / terminate when new fails to allocate=
 memory. Would<br>&gt;&gt; it be possible to make new noexcept, simplifying=
 programs and possibly<br>&gt;&gt; allowing more optimizations as noexcept =
will have a ripple effect?<br>&gt;<br>&gt; 1) What do you expect should the=
 system do, if there is no more memory<br>&gt; available?<br><br></span>abo=
rt() / terminate() / call some user-supplied header<br><span><br></span></b=
lockquote>
<div>=C2=A0</div>
<div>And if a program cannot afford to abort() / terminate() (e.g. servers =
/ operating systems / embedded systems, etc.)?</div>
<div>=C2=A0</div>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote"><span>&gt; 2) Why don&#39;t you use t=
he non-array variant &quot;new (std::nothrow)&quot;=C2=A0 which<br>&gt; *is=
* noexcept and returns null on failure?<br><br></span>See 1. ;)<br><span cl=
ass=3D"HOEnZb"><font color=3D"#888888"><br><br>--<br>Olaf<br></font></span>
<div class=3D"HOEnZb">
<div class=3D"h5"><br>--<br><br>---<br>You received this message because yo=
u are subscribed to the Google Groups &quot;ISO C++ Standard - Future Propo=
sals&quot; group.<br>To unsubscribe from this group and stop receiving emai=
ls from it, send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@=
isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>To post to this gr=
oup, send email to <a href=3D"mailto:std-proposals@isocpp.org">std-proposal=
s@isocpp.org</a>.<br>Visit this group at <a href=3D"http://groups.google.co=
m/a/isocpp.org/group/std-proposals/" target=3D"_blank">http://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br></div></div></blockquote></d=
iv><br>

<p></p>

-- <br />
<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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113d3082d563bf0513d93b12--

.

On Thursday 16 April 2015 16:36:56 Douglas Boffey wrote:
> And if a program cannot afford to abort() / terminate() (e.g. servers /
> operating systems / embedded systems, etc.)?

Then they won't opt in to this feature.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_88_1690942134.1429280670804
Content-Type: multipart/alternative;
 boundary="----=_Part_89_2013345387.1429280670804"

------=_Part_89_2013345387.1429280670804
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Op donderdag 16 april 2015 17:36:58 UTC+2 schreef Douglas Boffey:
>
>
> On Wed, Apr 15, 2015 at 10:27 AM, Olaf van der Spek <olafv...@gmail.com=
=20
> <javascript:>> wrote:
>
>> 2015-04-15 11:22 GMT+02:00 Daniel Kr=C3=BCgler <daniel....@gmail.com=20
>> <javascript:>>:
>> > 2015-04-15 11:14 GMT+02:00 Olaf van der Spek <olafv...@gmail.com=20
>> <javascript:>>:
>> >> Lots of programs abort / terminate when new fails to allocate memory.=
=20
>> Would
>> >> it be possible to make new noexcept, simplifying programs and possibl=
y
>> >> allowing more optimizations as noexcept will have a ripple effect?
>> >
>> > 1) What do you expect should the system do, if there is no more memory
>> > available?
>>
>> abort() / terminate() / call some user-supplied header
>>
>> =20
> And if a program cannot afford to abort() / terminate() (e.g. servers /=
=20
> operating systems / embedded systems, etc.)?
>

I think most server processes can abort just fine. Even DB servers should=
=20
be able to, as they've got to handle a power / hardware crash anyway.
Operating systems is a VERY broad term. Are you aware of any kernel code=20
that's using exceptions?
Embedded systems again is a broad term. Some processes can abort just fine.=
=20
Others can't even use dynamic memory..

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>Op donderdag 16 april 2015 17:36:58 UTC+2 schreef =
Douglas Boffey:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>
<div class=3D"gmail_quote">On Wed, Apr 15, 2015 at 10:27 AM, Olaf van der S=
pek <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"begjRt42XjkJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">olafv...@gmail.com</a>&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote"><span>2015-04-15 11:22 GMT+02:00 Dani=
el Kr=C3=BCgler &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"begjRt42XjkJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">d=
aniel....@gmail.com</a>&gt;:<br>&gt; 2015-04-15 11:14 GMT+02:00 Olaf van de=
r Spek &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"begjRt42XjkJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">olafv...@=
gmail.com</a>&gt;:<br>&gt;&gt; Lots of programs abort / terminate when new =
fails to allocate memory. Would<br>&gt;&gt; it be possible to make new noex=
cept, simplifying programs and possibly<br>&gt;&gt; allowing more optimizat=
ions as noexcept will have a ripple effect?<br>&gt;<br>&gt; 1) What do you =
expect should the system do, if there is no more memory<br>&gt; available?<=
br><br></span>abort() / terminate() / call some user-supplied header<br><sp=
an><br></span></blockquote>
<div>&nbsp;</div>
<div>And if a program cannot afford to abort() / terminate() (e.g. servers =
/ operating systems / embedded systems, etc.)?</div></div></blockquote><div=
><br></div><div>I think most server processes can abort just fine. Even DB =
servers should be able to, as they've got to handle a power / hardware cras=
h anyway.</div><div>Operating systems is a VERY broad term. Are you aware o=
f any kernel code that's using exceptions?</div><div>Embedded systems again=
 is a broad term. Some processes can abort just fine. Others can't even use=
 dynamic memory..</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_89_2013345387.1429280670804--
------=_Part_88_1690942134.1429280670804--

.

------=_Part_702_109892049.1429281169046
Content-Type: multipart/alternative;
 boundary="----=_Part_703_119731123.1429281169046"

------=_Part_703_119731123.1429281169046
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Op woensdag 15 april 2015 14:29:10 UTC+2 schreef Daniel Kr=C3=BCgler:
>
> 2015-04-15 12:25 GMT+02:00 Olaf van der Spek <olafv...@gmail.com=20
> <javascript:>>:=20
> > 2015-04-15 11:42 GMT+02:00 Daniel Kr=C3=BCgler <daniel....@gmail.com=20
> <javascript:>>:=20
> >>> abort() / terminate() / call some user-supplied header=20
> >>=20
> >> This surely would break the existing contract and looks like a no-go t=
o=20
> me.=20
> >>=20
> >>>> 2) Why don't you use the non-array variant "new (std::nothrow)"=20
>  which=20
> >>>> *is* noexcept and returns null on failure?=20
> >>>=20
> >>> See 1. ;)=20
> >>=20
> >> This looks like a very special use case to me. I'm pretty sure that=20
> >=20
> > Does it? Why? Most programs abort / terminate on out of memory anyway=
=20
> > so it doesn't seem that special to me.=20
>
> It is special. Even if your specific application may not intend to=20
> handle it, there exists conforming C++ code that relies on the=20
> existing contract. I see no reason to change this contract based on an=20
> IMO wobbly and narrow argument. The general criterion for functions=20
> marked as unconditionally noexcept is that they cannot fail. But=20
> several of the existing dynamic memory allocation clearly *can* fail.=20
> If *you* intend to decide that such conditions should result in a=20
> program termination, than *you* can easily decide that for such a=20
> behaviour and simply consider these functions as noexcept - Just wrap=20
> them in a function marked as noexcept and forward the call. This will=20
> have the intended effect to terminate, if these memory allocation=20
> functions would fail. But when the committee would follow your=20
> proposal, it would now *constrain* the freedom of existing programs to=20
> decide what happens when these function fail. The latter is IMO=20
> unacceptable to me without seeing good arguments presented.=20
>

Let's take a step back and not worry about the standard and compatibility=
=20
for a moment.

I'd love to see what such programs do with bad_alloc. Could you point me to=
=20
some real programs?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>Op woensdag 15 april 2015 14:29:10 UTC+2 schreef D=
aniel Kr=C3=BCgler:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2015-04-15 =
12:25 GMT+02:00 Olaf van der Spek &lt;<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"th_kl53BQZcJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript=
:';return true;">olafv...@gmail.com</a>&gt;:
<br>&gt; 2015-04-15 11:42 GMT+02:00 Daniel Kr=C3=BCgler &lt;<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"th_kl53BQZcJ" rel=3D"no=
follow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"t=
his.href=3D'javascript:';return true;">daniel....@gmail.com</a>&gt;:
<br>&gt;&gt;&gt; abort() / terminate() / call some user-supplied header
<br>&gt;&gt;
<br>&gt;&gt; This surely would break the existing contract and looks like a=
 no-go to me.
<br>&gt;&gt;
<br>&gt;&gt;&gt;&gt; 2) Why don't you use the non-array variant "new (std::=
nothrow)" &nbsp;which
<br>&gt;&gt;&gt;&gt; *is* noexcept and returns null on failure?
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; See 1. ;)
<br>&gt;&gt;
<br>&gt;&gt; This looks like a very special use case to me. I'm pretty sure=
 that
<br>&gt;
<br>&gt; Does it? Why? Most programs abort / terminate on out of memory any=
way
<br>&gt; so it doesn't seem that special to me.
<br>
<br>It is special. Even if your specific application may not intend to
<br>handle it, there exists conforming C++ code that relies on the
<br>existing contract. I see no reason to change this contract based on an
<br>IMO wobbly and narrow argument. The general criterion for functions
<br>marked as unconditionally noexcept is that they cannot fail. But
<br>several of the existing dynamic memory allocation clearly *can* fail.
<br>If *you* intend to decide that such conditions should result in a
<br>program termination, than *you* can easily decide that for such a
<br>behaviour and simply consider these functions as noexcept - Just wrap
<br>them in a function marked as noexcept and forward the call. This will
<br>have the intended effect to terminate, if these memory allocation
<br>functions would fail. But when the committee would follow your
<br>proposal, it would now *constrain* the freedom of existing programs to
<br>decide what happens when these function fail. The latter is IMO
<br>unacceptable to me without seeing good arguments presented.
<br></blockquote><div><br></div><div>Let's take a step back and not worry a=
bout the standard and compatibility for a moment.</div><div><br></div><div>=
I'd love to see what such programs do with bad_alloc. Could you point me to=
 some real programs?</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_703_119731123.1429281169046--
------=_Part_702_109892049.1429281169046--

.

--Apple-Mail=_1FE922E7-38DB-4B48-8B97-D6CE01C3FD59
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9304=E2=80=9317, at 10:24 PM, Olaf van der Spek <olafvdspek=
@gmail.com> wrote:
>=20
> Op donderdag 16 april 2015 17:36:58 UTC+2 schreef Douglas Boffey:
>=20
> And if a program cannot afford to abort() / terminate() (e.g. servers / o=
perating systems / embedded systems, etc.)?
>=20
> I think most server processes can abort just fine. Even DB servers should=
 be able to, as they've got to handle a power / hardware crash anyway.
> Operating systems is a VERY broad term. Are you aware of any kernel code =
that's using exceptions?
> Embedded systems again is a broad term. Some processes can abort just fin=
e. Others can't even use dynamic memory..

Realistically, a lot of software across the board does reset on failure, an=
d C++ should support the model. The existence of bad_alloc is even misleadi=
ng in many cases. For example, Mac OS X will oversubscribe virtual memory b=
y default (unless a quota is set), so without special configuration you wil=
l never see a new-handler or bad_alloc but only unceremonious termination w=
hen an unallocated page is accessed.

The question should be how, not why.

Who makes the decision whether bad_alloc is thrown? My previous message her=
e shows that it=E2=80=99s impossible to consistently let the user make the =
choice within a translation unit. It should be a platform switch, set by th=
e ABI and/or a compiler flag. Such a flag would be determined by disabling =
exceptions entirely, but it should also be separately accessible.

What changes are needed to allow the implementation this decision?

1. Let x in ::operator new(std::size_t) noexcept(x) be implementation-defin=
ed. This is a matter of blessing a simple extension.
2. Require that replacement ::operator new declarations match the built-in =
declaration. Clang already does this.
3. Make it implementation-defined whether the new-handler is ever called. T=
his would only require documentation of the status quo, so it=E2=80=99s a g=
ood idea anyway.

There could be a feature-test macro, but it seems unnecessary. Generic use =
of the noexcept operator will simply work, and noexcept(new int) will do th=
e rest.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_1FE922E7-38DB-4B48-8B97-D6CE01C3FD59
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9317, at 10:24 PM, Olaf van der Spek &lt;<a href=3D"mailto:olafvdspe=
k@gmail.com" class=3D"">olafvdspek@gmail.com</a>&gt; wrote:</div><div class=
=3D""><div dir=3D"ltr" class=3D""><br class=3D"">Op donderdag 16 april 2015=
 17:36:58 UTC+2 schreef Douglas Boffey:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><br class=3D"">
<div class=3D"gmail_quote"><div class=3D"">And if a program cannot afford t=
o abort() / terminate() (e.g. servers / operating systems / embedded system=
s, etc.)?</div></div></blockquote><div class=3D""><br class=3D""></div><div=
 class=3D"">I think most server processes can abort just fine. Even DB serv=
ers should be able to, as they've got to handle a power / hardware crash an=
yway.</div><div class=3D"">Operating systems is a VERY broad term. Are you =
aware of any kernel code that's using exceptions?</div><div class=3D"">Embe=
dded systems again is a broad term. Some processes can abort just fine. Oth=
ers can't even use dynamic memory..</div></div></div></blockquote><br class=
=3D""></div><div>Realistically, a lot of software across the board does res=
et on failure, and C++ should support the model. The existence of <font fac=
e=3D"Courier" class=3D"">bad_alloc</font> is even misleading in many cases.=
 For example, Mac OS X will oversubscribe virtual memory by default (unless=
 a quota is set), so without special configuration you will never see a new=
-handler or&nbsp;<font face=3D"Courier" class=3D"">bad_alloc</font> but onl=
y unceremonious termination when an unallocated page is accessed.</div><br =
class=3D""><div class=3D"">The question should be how, not why.</div><div c=
lass=3D""><br class=3D""></div><div class=3D"">Who makes the decision wheth=
er <font face=3D"Courier" class=3D"">bad_alloc</font> is thrown? My previou=
s message here shows that it=E2=80=99s impossible to consistently let the u=
ser make the choice within a translation unit. It should be a platform swit=
ch, set by the ABI and/or a compiler flag. Such a flag would be determined =
by disabling exceptions entirely, but it should also be separately accessib=
le.</div><div class=3D""><br class=3D""></div><div class=3D"">What changes =
are needed to allow the implementation this decision?</div><div class=3D"">=
<br class=3D""></div><div class=3D"">1. Let <font face=3D"Courier" class=3D=
"">x</font> in&nbsp;<font face=3D"Courier" class=3D"">::operator new(std::s=
ize_t) noexcept(x)</font> be implementation-defined. This is a matter of bl=
essing a simple extension.</div><div class=3D"">2. Require that replacement=
 <font face=3D"Courier" class=3D"">::operator new</font> declarations match=
 the built-in declaration. Clang already does this.</div><div class=3D"">3.=
 Make it implementation-defined whether the new-handler is ever called. Thi=
s would only require documentation of the status quo, so it=E2=80=99s a goo=
d idea anyway.</div><div class=3D""><br class=3D""></div><div class=3D"">Th=
ere could be a feature-test macro, but it seems unnecessary. Generic use of=
 the&nbsp;<font face=3D"Courier" class=3D"">noexcept</font> operator will s=
imply work, and <font face=3D"Courier" class=3D"">noexcept(new int)</font>&=
nbsp;will do the rest.</div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_1FE922E7-38DB-4B48-8B97-D6CE01C3FD59--

.

On 17 April 2015 at 17:53, David Krauss <potswa@gmail.com> wrote:
> Realistically, a lot of software across the board does reset on failure, =
and
> C++ should support the model. The existence of bad_alloc is even misleadi=
ng

What makes you think C++ doesn't support that model? If you want to abort
on memory allocation failure, new_handler should allow you to do that.

> in many cases. For example, Mac OS X will oversubscribe virtual memory by
> default (unless a quota is set), so without special configuration you wil=
l
> never see a new-handler or bad_alloc but only unceremonious termination w=
hen
> an unallocated page is accessed.

And yet such "special configuration" is a relatively simple matter of
setting a resource
limit, in which case such a system will no longer overcommit, but will
throw bad_allocs
just fine. I don't know whether Mac OS X does so, but Linux certainly does.

> Who makes the decision whether bad_alloc is thrown? My previous message h=
ere
> shows that it=E2=80=99s impossible to consistently let the user make the =
choice
> within a translation unit. It should be a platform switch, set by the ABI

Well, if you want per-translation unit control, perhaps new isn't the
right tool.

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

.

On Friday 17 April 2015 07:32:49 Olaf van der Spek wrote:
> Let's take a step back and not worry about the standard and compatibility
> for a moment.
>
> I'd love to see what such programs do with bad_alloc. Could you point me to
> some real programs?

All or nearly all of those found in your Linux distribution that are written
in C++, including all of KDE as well as Firefox and Chrome/Chromium.
Glib/GNOME programs do the same for their non-C++ memory allocation.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2015-04-17 17:40 GMT+02:00 Thiago Macieira <thiago@macieira.org>:
> On Friday 17 April 2015 07:32:49 Olaf van der Spek wrote:
>> Let's take a step back and not worry about the standard and compatibility
>> for a moment.
>>
>> I'd love to see what such programs do with bad_alloc. Could you point me to
>> some real programs?
>
> All or nearly all of those found in your Linux distribution that are written
> in C++, including all of KDE as well as Firefox and Chrome/Chromium.
> Glib/GNOME programs do the same for their non-C++ memory allocation.

What do they do exactly?


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

.

On Friday 17 April 2015 17:44:04 Olaf van der Spek wrote:
> 2015-04-17 17:40 GMT+02:00 Thiago Macieira <thiago@macieira.org>:
> > On Friday 17 April 2015 07:32:49 Olaf van der Spek wrote:
> >> Let's take a step back and not worry about the standard and compatibility
> >> for a moment.
> >>
> >> I'd love to see what such programs do with bad_alloc. Could you point me
> >> to
> >> some real programs?
> >
> > All or nearly all of those found in your Linux distribution that are
> > written in C++, including all of KDE as well as Firefox and
> > Chrome/Chromium. Glib/GNOME programs do the same for their non-C++ memory
> > allocation.
> What do they do exactly?

Nothing. They don't handle malloc() returning null and they don't catch
std::bad_alloc.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2015-04-17 17:46 GMT+02:00 Thiago Macieira <thiago@macieira.org>:
> On Friday 17 April 2015 17:44:04 Olaf van der Spek wrote:
>> 2015-04-17 17:40 GMT+02:00 Thiago Macieira <thiago@macieira.org>:
>> > On Friday 17 April 2015 07:32:49 Olaf van der Spek wrote:
>> >> Let's take a step back and not worry about the standard and compatibility
>> >> for a moment.
>> >>
>> >> I'd love to see what such programs do with bad_alloc. Could you point me
>> >> to
>> >> some real programs?
>> >
>> > All or nearly all of those found in your Linux distribution that are
>> > written in C++, including all of KDE as well as Firefox and
>> > Chrome/Chromium. Glib/GNOME programs do the same for their non-C++ memory
>> > allocation.
>> What do they do exactly?
>
> Nothing. They don't handle malloc() returning null and they don't catch
> std::bad_alloc.

Sigh, are you kidding me?

The proposal would work fine for these programs wouldn't it?
We're looking for programs that would NOT work with the proposal.



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

.

--Apple-Mail=_A1C5110E-9AEF-4D1E-B3AD-D9556F587606
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9304=E2=80=9317, at 11:10 PM, Ville Voutilainen <ville.vout=
ilainen@gmail.com> wrote:
>=20
> On 17 April 2015 at 17:53, David Krauss <potswa@gmail.com> wrote:
>> Realistically, a lot of software across the board does reset on failure,=
 and
>> C++ should support the model. The existence of bad_alloc is even mislead=
ing
>=20
> What makes you think C++ doesn't support that model? If you want to abort
> on memory allocation failure, new_handler should allow you to do that.

The support is suboptimal because noexcept(new-expression) is excessively c=
onservative in that case.

> And yet such "special configuration" is a relatively simple matter of
> setting a resource
> limit,

What percentage of desktop PC users (never mind mobile users) do you suppos=
e can accomplish that simple matter?

> in which case such a system will no longer overcommit, but will
> throw bad_allocs
> just fine. I don't know whether Mac OS X does so, but Linux certainly doe=
s.

It=E2=80=99s reasonable to write for a platform which is overcommitting. In=
 other words, to not care about bad_alloc, which is really what the OP is a=
sking for.

If ::operator new(size_t) is made noexcept, but it throws, then std::termin=
ate is called. The OP request would be satisfied simply by adjusting the ex=
ception-specification to reflect how the user wants the platform to be, reg=
ardless of the library implementation.

> Well, if you want per-translation unit control, perhaps new isn't the
> right tool.

For most users, anything besides the default allocator (as used by the usua=
l containers) is a non-starter. But sure, a totally custom interface can do=
 anything.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_A1C5110E-9AEF-4D1E-B3AD-D9556F587606
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9317, at 11:10 PM, Ville Voutilainen &lt;<a href=3D"mailto:ville.vou=
tilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>&gt; wrote:</=
div><br class=3D"Apple-interchange-newline"><div class=3D"">On 17 April 201=
5 at 17:53, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com" class=3D""=
>potswa@gmail.com</a>&gt; wrote:<br class=3D""><blockquote type=3D"cite" cl=
ass=3D"">Realistically, a lot of software across the board does reset on fa=
ilure, and<br class=3D"">C++ should support the model. The existence of bad=
_alloc is even misleading<br class=3D""></blockquote><br class=3D"">What ma=
kes you think C++ doesn't support that model? If you want to abort<br class=
=3D"">on memory allocation failure, new_handler should allow you to do that=
..<br class=3D""></div></blockquote><div><br class=3D""></div><div>The suppo=
rt is suboptimal because <font face=3D"Courier" class=3D"">noexcept(</font>=
<i class=3D"">new-expression</i><font face=3D"Courier" class=3D"">)</font> =
is excessively conservative in that case.</div><div><br class=3D""></div><b=
lockquote type=3D"cite" class=3D""><div class=3D"">And yet such "special co=
nfiguration" is a relatively simple matter of<br class=3D"">setting a resou=
rce<br class=3D"">limit, </div></blockquote><div><br class=3D""></div><div>=
What percentage of desktop PC users (never mind mobile users) do you suppos=
e can accomplish that simple matter?</div><br class=3D""><blockquote type=
=3D"cite" class=3D""><div class=3D"">in which case such a system will no lo=
nger overcommit, but will<br class=3D"">throw bad_allocs<br class=3D"">just=
 fine. I don't know whether Mac OS X does so, but Linux certainly does.</di=
v></blockquote><div><br class=3D""></div><div>It=E2=80=99s reasonable to wr=
ite for a platform which is overcommitting. In other words, to not care abo=
ut <font face=3D"Courier" class=3D"">bad_alloc</font>, which is really what=
 the OP is asking for.</div><div><br class=3D""></div><div>If <font face=3D=
"Courier" class=3D"">::operator new(size_t)</font> is made <font face=3D"Co=
urier" class=3D"">noexcept</font>, but it throws, then <font face=3D"Courie=
r" class=3D"">std::terminate</font> is called. The OP request would be sati=
sfied simply by adjusting the exception-specification to reflect how the us=
er <i class=3D"">wants</i> the platform to be, regardless of the library im=
plementation.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div=
 class=3D"">Well, if you want per-translation unit control, perhaps new isn=
't the<br class=3D"">right tool.<br class=3D""></div></blockquote><div><br =
class=3D""></div></div>For most users, anything besides the default allocat=
or (as used by the usual containers) is a non-starter. But sure, a totally =
custom interface can do anything.</body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_A1C5110E-9AEF-4D1E-B3AD-D9556F587606--

.

On 17 April 2015 at 18:52, David Krauss <potswa@gmail.com> wrote:
> And yet such "special configuration" is a relatively simple matter of
> setting a resource
> limit,
>
> What percentage of desktop PC users (never mind mobile users) do you supp=
ose
> can accomplish that simple matter?

I have no idea, since I wouldn't expect users having to do that. I
would expect the
software designers to make that decision.

> in which case such a system will no longer overcommit, but will
> throw bad_allocs
> just fine. I don't know whether Mac OS X does so, but Linux certainly doe=
s.
>
> It=E2=80=99s reasonable to write for a platform which is overcommitting. =
In other
> words, to not care about bad_alloc, which is really what the OP is asking
> for.

What does that have to do with whether new is noexcept or not? Quite many
programs don't care about any exceptions, let alone bad_alloc.

> If ::operator new(size_t) is made noexcept, but it throws, then
> std::terminate is called. The OP request would be satisfied simply by
> adjusting the exception-specification to reflect how the user wants the
> platform to be, regardless of the library implementation.

That doesn't mean we should standardize that. It seems to be an idea
that would decrease portability.

> Well, if you want per-translation unit control, perhaps new isn't the
> right tool.
>
> For most users, anything besides the default allocator (as used by the us=
ual
> containers) is a non-starter. But sure, a totally custom interface can do
> anything.


I don't suppose those "most users" will want per-translation unit control.

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

.

On Friday 17 April 2015 17:47:51 Olaf van der Spek wrote:
> >> What do they do exactly?
> >
> > Nothing. They don't handle malloc() returning null and they don't catch
> > std::bad_alloc.
>
> Sigh, are you kidding me?

I'm not.

> The proposal would work fine for these programs wouldn't it?
> We're looking for programs that would NOT work with the proposal.

I might have misunderstood the question.

But I still don't think we need to have any proposals considered. Those
programs that don't handle out-of-memory situations can install a new handler
or override operator new or even override malloc() to cause the abort.


--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Friday 17 April 2015 07:24:30 Olaf van der Spek wrote:
>
> I think most server processes can abort just fine. Even DB servers should
> be able to, as they've got to handle a power / hardware crash anyway.

On the contrary, server-side software is the kind of software that is required
to work no matter what. Crashing means hundreds/thousands clients affected.
Working reasonably well in stress conditions, including memory and CPU
resource shortage, is always a requirement in such environments because you
will certainly hit some limit in real world usage, sooner or later.

Power interrupts are tackled by using UPS. Hardware failures are more
difficult to handle but there are ways on both hardware and software design
sides (RAID, ECC memory, duplicate network connections, CPUs and other
components - see HP NonStop for instance). Even effect of a physical
destruction of the server, e.g. because of a nature disaster, can be reduced
by having multiple geographically distant installations.

Of course, all this comes with a cost and have nothing to do with operator
new. Sometimes you can cut down some of the expenses by accepting the risks or
by following some software design guidelines (e.g. REST). But such design
guidelines are specialized solutions. For example, in the areas like media
processing, gaming or realtime billing you will most likely have a server-side
process which simply must not crash. I myself am working on a media processing
engine that in particular handles memory shortage events.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_0569B2A6-2C34-4C5F-AD40-0C2A7A166304
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9304=E2=80=9317, at 11:59 PM, Ville Voutilainen <ville.vout=
ilainen@gmail.com> wrote:
>=20
> On 17 April 2015 at 18:52, David Krauss <potswa@gmail.com> wrote:
>> And yet such "special configuration" is a relatively simple matter of
>> setting a resource
>> limit,
>>=20
>> What percentage of desktop PC users (never mind mobile users) do you sup=
pose
>> can accomplish that simple matter?
>=20
> I have no idea, since I wouldn't expect users having to do that. I
> would expect the
> software designers to make that decision.

Yes. Perhaps we=E2=80=99re violently agreeing. The programmer should be abl=
e to predict the usefulness of bad_alloc.

>> It=E2=80=99s reasonable to write for a platform which is overcommitting.=
 In other
>> words, to not care about bad_alloc, which is really what the OP is askin=
g
>> for.
>=20
> What does that have to do with whether new is noexcept or not? Quite many
> programs don't care about any exceptions, let alone bad_alloc.

Right. (The connection is that, with overcommitment, new becomes noexcept a=
nd malloc never returns nullptr =E2=80=94 at least unless VM is exhausted, =
which is an extreme case implying irrecoverable overcommitment. Might as we=
ll terminate then and there, since VM certainly outstrips physical storage.=
)

>> If ::operator new(size_t) is made noexcept, but it throws, then
>> std::terminate is called. The OP request would be satisfied simply by
>> adjusting the exception-specification to reflect how the user wants the
>> platform to be, regardless of the library implementation.
>=20
> That doesn't mean we should standardize that. It seems to be an idea
> that would decrease portability.

How is portability helped by catching bad_alloc on a system that never thro=
ws it?

Portability is improved by allowing standard ways to investigate the operat=
ing environment, not by narrowing the range of conforming environments or r=
equiring useless stub interfaces.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_0569B2A6-2C34-4C5F-AD40-0C2A7A166304
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9317, at 11:59 PM, Ville Voutilainen &lt;<a href=3D"mailto:ville.vou=
tilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>&gt; wrote:</=
div><br class=3D"Apple-interchange-newline"><div class=3D"">On 17 April 201=
5 at 18:52, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com" class=3D""=
>potswa@gmail.com</a>&gt; wrote:<br class=3D""><blockquote type=3D"cite" cl=
ass=3D"">And yet such "special configuration" is a relatively simple matter=
 of<br class=3D"">setting a resource<br class=3D"">limit,<br class=3D""><br=
 class=3D"">What percentage of desktop PC users (never mind mobile users) d=
o you suppose<br class=3D"">can accomplish that simple matter?<br class=3D"=
"></blockquote><br class=3D"">I have no idea, since I wouldn't expect users=
 having to do that. I<br class=3D"">would expect the<br class=3D"">software=
 designers to make that decision.<br class=3D""></div></blockquote><div><br=
 class=3D""></div><div>Yes. Perhaps we=E2=80=99re violently agreeing. The p=
rogrammer should be able to predict the usefulness of&nbsp;<font face=3D"Co=
urier" class=3D"">bad_alloc</font>.</div><br class=3D""><blockquote type=3D=
"cite" class=3D""><div class=3D""><blockquote type=3D"cite" class=3D"">It=
=E2=80=99s reasonable to write for a platform which is overcommitting. In o=
ther<br class=3D"">words, to not care about bad_alloc, which is really what=
 the OP is asking<br class=3D"">for.<br class=3D""></blockquote><br class=
=3D"">What does that have to do with whether new is noexcept or not? Quite =
many<br class=3D"">programs don't care about any exceptions, let alone bad_=
alloc.<br class=3D""></div></blockquote><div><br class=3D""></div><div>Righ=
t. (The connection is that, with overcommitment, new becomes <font face=3D"=
Courier" class=3D"">noexcept</font> and malloc never returns <font face=3D"=
Courier" class=3D"">nullptr</font> =E2=80=94 at least unless VM is exhauste=
d, which is an extreme case implying irrecoverable overcommitment. Might as=
 well terminate then and there, since VM certainly outstrips physical stora=
ge.)</div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D=
""><blockquote type=3D"cite" class=3D"">If ::operator new(size_t) is made n=
oexcept, but it throws, then<br class=3D"">std::terminate is called. The OP=
 request would be satisfied simply by<br class=3D"">adjusting the exception=
-specification to reflect how the user wants the<br class=3D"">platform to =
be, regardless of the library implementation.<br class=3D""></blockquote><b=
r class=3D"">That doesn't mean we should standardize that. It seems to be a=
n idea<br class=3D"">that would decrease portability.<br class=3D""></div><=
/blockquote><div><br class=3D""></div><div>How is portability helped by cat=
ching <font face=3D"Courier" class=3D"">bad_alloc</font> on a system that n=
ever throws it?</div><div><br class=3D""></div><div>Portability is improved=
 by allowing standard ways to investigate the operating environment, not by=
 narrowing the range of conforming environments or requiring useless stub i=
nterfaces.</div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_0569B2A6-2C34-4C5F-AD40-0C2A7A166304--

.

On 17 April 2015 at 20:10, David Krauss <potswa@gmail.com> wrote:
> What percentage of desktop PC users (never mind mobile users) do you supp=
ose
> can accomplish that simple matter?
>
> I have no idea, since I wouldn't expect users having to do that. I
> would expect the
> software designers to make that decision.
>
> Yes. Perhaps we=E2=80=99re violently agreeing. The programmer should be a=
ble to
> predict the usefulness of bad_alloc.

Yes, across multiple platforms, which is why I find it an odd suggestion to=
 make
new noexcept on some platforms but not others.

> It=E2=80=99s reasonable to write for a platform which is overcommitting. =
In other
> words, to not care about bad_alloc, which is really what the OP is asking
> for.
>
> What does that have to do with whether new is noexcept or not? Quite many
> programs don't care about any exceptions, let alone bad_alloc.
>
> Right. (The connection is that, with overcommitment, new becomes noexcept
> and malloc never returns nullptr =E2=80=94 at least unless VM is exhauste=
d, which is
> an extreme case implying irrecoverable overcommitment. Might as well
> terminate then and there, since VM certainly outstrips physical storage.)

That situation may or may not be irrecoverable.

> If ::operator new(size_t) is made noexcept, but it throws, then
> std::terminate is called. The OP request would be satisfied simply by
> adjusting the exception-specification to reflect how the user wants the
> platform to be, regardless of the library implementation.
>
> That doesn't mean we should standardize that. It seems to be an idea
> that would decrease portability.
>
> How is portability helped by catching bad_alloc on a system that never
> throws it?

By making that code behave sanely when built and run on a system that does
throw bad_allocs.

> Portability is improved by allowing standard ways to investigate the
> operating environment, not by narrowing the range of conforming environme=
nts
> or requiring useless stub interfaces.

Portability is also improved by establishing contracts that don't change wi=
thout
any control by the programmer.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--Apple-Mail=_1FAEBEE5-5029-4F79-ACC2-E200DD6B64AF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9304=E2=80=9318, at 12:28 AM, Andrey Semashev <andrey.semas=
hev@gmail.com> wrote:
>=20
> On the contrary, server-side software is the kind of software that is req=
uired=20
> to work no matter what. Crashing means hundreds/thousands clients affecte=
d.=20

Often, complexity is kept in =E2=80=9Cservlet=E2=80=9D or =E2=80=9CCGI=E2=
=80=9D processes that handle a single client or a single task, to handle th=
e realities of stability and security.

Applications demanding such performance that a single process handles thous=
ands of clients are the exception to the rule. That=E2=80=99s the domain of=
 proper servers, not in general =E2=80=9Cserver-side software.=E2=80=9D The=
 way to write that sort of thing is with hard resource limits. Allowing one=
 user unlimited access to the global memory pool is asking for failure, so =
as you mention, it=E2=80=99s not a matter of operator new. Also, C++ except=
ions are probably not a good idea during peak load conditions, at all.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_1FAEBEE5-5029-4F79-ACC2-E200DD6B64AF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9318, at 12:28 AM, Andrey Semashev &lt;<a href=3D"mailto:andrey.sema=
shev@gmail.com" class=3D"">andrey.semashev@gmail.com</a>&gt; wrote:</div><b=
r class=3D"Apple-interchange-newline"><div class=3D""><span style=3D"font-f=
amily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal=
; font-weight: normal; letter-spacing: normal; line-height: normal; orphans=
: auto; text-align: start; text-indent: 0px; text-transform: none; white-sp=
ace: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0p=
x; float: none; display: inline !important;" class=3D"">On the contrary, se=
rver-side software is the kind of software that is required<span class=3D"A=
pple-converted-space">&nbsp;</span></span><br style=3D"font-family: Helveti=
ca; font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
 normal; letter-spacing: normal; line-height: normal; orphans: auto; text-a=
lign: start; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""=
><span style=3D"font-family: Helvetica; font-size: 12px; font-style: normal=
; font-variant: normal; font-weight: normal; letter-spacing: normal; line-h=
eight: normal; orphans: auto; text-align: start; text-indent: 0px; text-tra=
nsform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit=
-text-stroke-width: 0px; float: none; display: inline !important;" class=3D=
"">to work no matter what. Crashing means hundreds/thousands clients affect=
ed.<span class=3D"Apple-converted-space">&nbsp;</span></span><br style=3D"f=
ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant: n=
ormal; font-weight: normal; letter-spacing: normal; line-height: normal; or=
phans: auto; text-align: start; text-indent: 0px; text-transform: none; whi=
te-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-widt=
h: 0px;" class=3D""></div></blockquote></div><br class=3D""><div class=3D""=
>Often, complexity is kept in =E2=80=9Cservlet=E2=80=9D or =E2=80=9CCGI=E2=
=80=9D processes that handle a single client or a single task, to handle th=
e realities of stability and security.</div><div class=3D""><br class=3D"">=
</div><div class=3D"">Applications demanding such performance that a single=
 process handles thousands of clients are the exception to the rule. That=
=E2=80=99s the domain of proper servers, not in general =E2=80=9Cserver-sid=
e software.=E2=80=9D The way to write that sort of thing is with hard resou=
rce limits. Allowing one user unlimited access to the global memory pool is=
 asking for failure, so as you mention, it=E2=80=99s not a matter of <font =
face=3D"Courier" class=3D"">operator new</font>. Also, C++ exceptions are p=
robably not a good idea during peak load conditions, at all.</div></body></=
html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_1FAEBEE5-5029-4F79-ACC2-E200DD6B64AF--

.

2015-04-17 18:28 GMT+02:00 Andrey Semashev <andrey.semashev@gmail.com>:
> On Friday 17 April 2015 07:24:30 Olaf van der Spek wrote:
>>
>> I think most server processes can abort just fine. Even DB servers should
>> be able to, as they've got to handle a power / hardware crash anyway.
>
> On the contrary, server-side software is the kind of software that is required
> to work no matter what. Crashing means hundreds/thousands clients affected.
> Working reasonably well in stress conditions, including memory and CPU
> resource shortage, is always a requirement in such environments because you
> will certainly hit some limit in real world usage, sooner or later.
>
> Power interrupts are tackled by using UPS. Hardware failures are more
> difficult to handle but there are ways on both hardware and software design
> sides (RAID, ECC memory, duplicate network connections, CPUs and other
> components - see HP NonStop for instance). Even effect of a physical
> destruction of the server, e.g. because of a nature disaster, can be reduced
> by having multiple geographically distant installations.
>
> Of course, all this comes with a cost and have nothing to do with operator
> new. Sometimes you can cut down some of the expenses by accepting the risks or
> by following some software design guidelines (e.g. REST). But such design
> guidelines are specialized solutions. For example, in the areas like media
> processing, gaming or realtime billing you will most likely have a server-side
> process which simply must not crash. I myself am working on a media processing
> engine that in particular handles memory shortage events.

I'm sorry, what's your point?

Important services indeed shouldn't crash but that does NOT imply that
processes can't abort on out of memory. In most cases you want to
avoid running out of memory.
Take Lighttpd for example, a web server. It aborts on out of memory.
PHP? Aborts.
AFAIK Google loves ignoring bad_alloc.

What does your media processing engine do and how does it handle
memory shortage events?

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

.

On Saturday 18 April 2015 01:19:25 David Krauss wrote:
> > On 2015=E2=80=9304=E2=80=9318, at 12:28 AM, Andrey Semashev <andrey.sem=
ashev@gmail.com>
> > wrote:
> >=20
> > On the contrary, server-side software is the kind of software that is
> > required to work no matter what. Crashing means hundreds/thousands
> > clients affected.
>
> Often, complexity is kept in =E2=80=9Cservlet=E2=80=9D or =E2=80=9CCGI=E2=
=80=9D processes that handle a
> single client or a single task, to handle the realities of stability and
> security.

Yes, that's what I meant by specialized software designs. The tasks, or eve=
n=20
individual requests, have to be isolated enough for this to work, and it is=
=20
often not the case.

> Applications demanding such performance that a single process handles
> thousands of clients are the exception to the rule. That=E2=80=99s the do=
main of
> proper servers, not in general =E2=80=9Cserver-side software.=E2=80=9D

What do you mean by "proper servers"?

> The way to write
> that sort of thing is with hard resource limits. Allowing one user
> unlimited access to the global memory pool is asking for failure, so as y=
ou
> mention, it=E2=80=99s not a matter of operator new.

Memory (or resource, in general) quotas are a different matter indeed. They=
=20
are part of the resource management, just as handling of basic memory=20
allocation failures is.

> Also, C++ exceptions are
> probably not a good idea during peak load conditions, at all.

Why?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--Apple-Mail=_BF70A7DE-28B2-4316-850F-502389798F5E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9304=E2=80=9318, at 1:18 AM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> Yes, across multiple platforms, which is why I find it an odd suggestion =
to make
> new noexcept on some platforms but not others.
=E2=80=A6
> Portability is also improved by establishing contracts that don't change =
without
> any control by the programmer.

The proposal doesn=E2=80=99t change the behavior of any system, it just all=
ows the exception-specification to be adjusted to reflect the status quo. I=
f the memory implementation precludes operator new from throwing, or the pr=
ogrammer simply doesn=E2=80=99t want it to throw, then let the noexcept ope=
rator reveal that it doesn=E2=80=99t.

There=E2=80=99s no breakage to catch ( std::bad_alloc ). Only a standard wa=
y to tell that it might not be very productive.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_BF70A7DE-28B2-4316-850F-502389798F5E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9318, at 1:18 AM, Ville Voutilainen &lt;<a href=3D"mailto:ville.vout=
ilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>&gt; wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D"">Yes, across mult=
iple platforms, which is why I find it an odd suggestion to make<br class=
=3D"">new noexcept on some platforms but not others.<br class=3D""></div></=
blockquote><div>=E2=80=A6</div><blockquote type=3D"cite" class=3D""><div cl=
ass=3D"">Portability is also improved by establishing contracts that don't =
change without<br class=3D"">any control by the programmer.<br class=3D""><=
/div></blockquote></div><br class=3D""><div class=3D"">The proposal doesn=
=E2=80=99t change the behavior of any system, it just allows the exception-=
specification to be adjusted to reflect the status quo. If the memory imple=
mentation precludes <font face=3D"Courier" class=3D"">operator new</font> f=
rom throwing, or the programmer simply doesn=E2=80=99t want it to throw, th=
en let the <font face=3D"Courier" class=3D"">noexcept</font> operator revea=
l that it doesn=E2=80=99t.</div><div class=3D""><br class=3D""></div><div c=
lass=3D"">There=E2=80=99s no breakage to&nbsp;<font face=3D"Courier" class=
=3D"">catch ( std::bad_alloc )</font>. Only a standard way to tell that it =
might not be very productive.</div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_BF70A7DE-28B2-4316-850F-502389798F5E--

.

On 17 April 2015 at 20:39, David Krauss <potswa@gmail.com> wrote:
> The proposal doesn=E2=80=99t change the behavior of any system, it just a=
llows the
> exception-specification to be adjusted to reflect the status quo. If the
> memory implementation precludes operator new from throwing, or the

That memory implementation is far less static than the noexcept-specificati=
on
of new is.

> programmer simply doesn=E2=80=99t want it to throw, then let the noexcept=
 operator
> reveal that it doesn=E2=80=99t.

To.. do what with that information?

> There=E2=80=99s no breakage to catch ( std::bad_alloc ). Only a standard =
way to tell
> that it might not be very productive.

I am not convinced that such a standard way is a good idea to provide.

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

.

On Friday 17 April 2015 19:29:36 Olaf van der Spek wrote:
> 2015-04-17 18:28 GMT+02:00 Andrey Semashev <andrey.semashev@gmail.com>:
> > On Friday 17 April 2015 07:24:30 Olaf van der Spek wrote:
> >> I think most server processes can abort just fine. Even DB servers should
> >> be able to, as they've got to handle a power / hardware crash anyway.
> >
> > On the contrary, server-side software is the kind of software that is
> > required to work no matter what. Crashing means hundreds/thousands
> > clients affected. Working reasonably well in stress conditions, including
> > memory and CPU resource shortage, is always a requirement in such
> > environments because you will certainly hit some limit in real world
> > usage, sooner or later.
> >
> > Power interrupts are tackled by using UPS. Hardware failures are more
> > difficult to handle but there are ways on both hardware and software
> > design
> > sides (RAID, ECC memory, duplicate network connections, CPUs and other
> > components - see HP NonStop for instance). Even effect of a physical
> > destruction of the server, e.g. because of a nature disaster, can be
> > reduced by having multiple geographically distant installations.
> >
> > Of course, all this comes with a cost and have nothing to do with operator
> > new. Sometimes you can cut down some of the expenses by accepting the
> > risks or by following some software design guidelines (e.g. REST). But
> > such design guidelines are specialized solutions. For example, in the
> > areas like media processing, gaming or realtime billing you will most
> > likely have a server-side process which simply must not crash. I myself
> > am working on a media processing engine that in particular handles memory
> > shortage events.
>
> I'm sorry, what's your point?

My point is that there are real applications that can and must handle these
problems. And there are ways to do that besides crashing.

> Important services indeed shouldn't crash but that does NOT imply that
> processes can't abort on out of memory. In most cases you want to
> avoid running out of memory.
> Take Lighttpd for example, a web server. It aborts on out of memory.
> PHP? Aborts.
> AFAIK Google loves ignoring bad_alloc.

So what? This only means that that software is not suitable as a reliable
serving platform. It doesn't mean noone needs that kind of software.

Look, if your service doesn't care about crashing on OOM - that's fine. It
says something about its quality and reliability, but it may still be usable.
But the language, IMO, should not make _all_ software as unreliable by
default. Memory allocation failures should be reported, just as file opening
or writing failures, for example.

> What does your media processing engine do and how does it handle
> memory shortage events?

It will report the limitation to the product application. What the product
does depends on the situation. For example, the product may attempt to
allocate resources on another node running the media engine or reject the
participant from entering a videoconference.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_DF0CA4C9-4C59-4697-B5BF-E637377FD596
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9304=E2=80=9318, at 1:47 AM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> That memory implementation is far less static than the noexcept-specifica=
tion
> of new is.

Depends on the system, and the ease of setting that compiler flag. For the =
sake of argument, you could build both ways and select one at application l=
aunch.

Anyway, there=E2=80=99s also:

>> or the programmer simply doesn=E2=80=99t want it to throw, then let the =
noexcept operator
>> reveal that it doesn=E2=80=99t.
>=20
> To.. do what with that information?

See the OP. I=E2=80=99m not really convinced about the benefit, but it=E2=
=80=99s a testable hypothesis.

There are certainly cases where the noexcept operator is used to choose a c=
onservative path.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_DF0CA4C9-4C59-4697-B5BF-E637377FD596
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9318, at 1:47 AM, Ville Voutilainen &lt;<a href=3D"mailto:ville.vout=
ilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>&gt; wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D"">That memory impl=
ementation is far less static than the noexcept-specification<br class=3D""=
>of new is.<br class=3D""></div></blockquote><div><br class=3D""></div><div=
>Depends on the system, and the ease of setting that compiler flag. For the=
 sake of argument, you could build both ways and select one at application =
launch.</div><div><br class=3D""></div><div>Anyway, there=E2=80=99s also:</=
div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><bl=
ockquote type=3D"cite" class=3D""><b class=3D"">or the programmer simply do=
esn=E2=80=99t want it to throw</b>, then let the noexcept operator<br class=
=3D"">reveal that it doesn=E2=80=99t.<br class=3D""></blockquote><br class=
=3D"">To.. do what with that information?<br class=3D""></div></blockquote>=
<div><br class=3D""></div><div>See the OP. I=E2=80=99m not really convinced=
 about the benefit, but it=E2=80=99s a testable hypothesis.</div><div><br c=
lass=3D""></div><div>There are certainly cases where the <font face=3D"Cour=
ier" class=3D"">noexcept</font> operator is used to choose a conservative p=
ath.</div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_DF0CA4C9-4C59-4697-B5BF-E637377FD596--

.

On 17 April 2015 at 21:00, David Krauss <potswa@gmail.com> wrote:
>
> On 2015=E2=80=9304=E2=80=9318, at 1:47 AM, Ville Voutilainen <ville.vouti=
lainen@gmail.com>
> wrote:
>
> That memory implementation is far less static than the
> noexcept-specification
> of new is.
>
> Depends on the system, and the ease of setting that compiler flag. For th=
e

I wouldn't assume that it can be a compiler flag, since those memory
implementation
knobs can change at runtime.

> sake of argument, you could build both ways and select one at application
> launch.

I wouldn't need the noexcept-ness of new for that solution.

> or the programmer simply doesn=E2=80=99t want it to throw, then let the n=
oexcept
> operator
> reveal that it doesn=E2=80=99t.
>
> To.. do what with that information?
>
> See the OP. I=E2=80=99m not really convinced about the benefit, but it=E2=
=80=99s a testable
> hypothesis.
>
> There are certainly cases where the noexcept operator is used to choose a
> conservative path.

That sounds like a programmer would _have_ to use that operator to implemen=
t
two paths.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--Apple-Mail=_BBD78FF1-2C3B-46D1-B5E9-5A011D851755
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9304=E2=80=9318, at 2:03 AM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> I wouldn't assume that it can be a compiler flag, since those memory
> implementation
> knobs can change at runtime.

Let the flag be called, =E2=80=9CI intend to install an aborting new-handle=
r.=E2=80=9D

>> sake of argument, you could build both ways and select one at applicatio=
n
>> launch.
>=20
> I wouldn't need the noexcept-ness of new for that solution.

You would compile one binary with operator new noexcept and one with noexce=
pt(false), and run whichever matches the current quota state. Yes, the sysa=
dmin can apply a quota to processes launched with none, but that carries ri=
sks they should be aware of.

Anyway, the main scenario here is desktop, embedded, or other single-user s=
oftware that is not operated by a sysadmin.

>> There are certainly cases where the noexcept operator is used to choose =
a
>> conservative path.
>=20
> That sounds like a programmer would _have_ to use that operator to implem=
ent
> two paths.

With noexcept(auto), the operator immediately applied to the new-expression=
 could be implicit.

Olaf, perhaps you could expand on the intended or expected benefits?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_BBD78FF1-2C3B-46D1-B5E9-5A011D851755
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9318, at 2:03 AM, Ville Voutilainen &lt;<a href=3D"mailto:ville.vout=
ilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>&gt; wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D"">I wouldn't assum=
e that it can be a compiler flag, since those memory<br class=3D"">implemen=
tation<br class=3D"">knobs can change at runtime.<br class=3D""></div></blo=
ckquote><div><br class=3D""></div>Let the flag be called, =E2=80=9CI intend=
 to install an aborting new-handler.=E2=80=9D<br class=3D""><br class=3D"">=
<blockquote type=3D"cite" class=3D""><div class=3D""><blockquote type=3D"ci=
te" class=3D"">sake of argument, you could build both ways and select one a=
t application<br class=3D"">launch.<br class=3D""></blockquote><br class=3D=
"">I wouldn't need the noexcept-ness of new for that solution.<br class=3D"=
"></div></blockquote><div><br class=3D""></div><div>You would compile one b=
inary with operator new noexcept and one with noexcept(false), and run whic=
hever matches the current quota state. Yes, the sysadmin can apply a quota =
to processes launched with none, but that carries risks they should be awar=
e of.</div><div><br class=3D""></div><div>Anyway, the main scenario here is=
 desktop, embedded, or other single-user software that is not operated by a=
 sysadmin.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div cl=
ass=3D""><blockquote type=3D"cite" class=3D"">There are certainly cases whe=
re the noexcept operator is used to choose a<br class=3D"">conservative pat=
h.<br class=3D""></blockquote><br class=3D"">That sounds like a programmer =
would _have_ to use that operator to implement<br class=3D"">two paths.<br =
class=3D""></div></blockquote></div><br class=3D""><div class=3D"">With <fo=
nt face=3D"Courier" class=3D"">noexcept(auto)</font>, the operator immediat=
ely applied to the new-expression could be implicit.</div><div class=3D""><=
br class=3D""></div><div class=3D"">Olaf, perhaps you could expand on the i=
ntended or expected benefits?</div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_BBD78FF1-2C3B-46D1-B5E9-5A011D851755--

.

On 17 April 2015 at 21:32, David Krauss <potswa@gmail.com> wrote:
>
> On 2015=E2=80=9304=E2=80=9318, at 2:03 AM, Ville Voutilainen <ville.vouti=
lainen@gmail.com>
> wrote:
>
> I wouldn't assume that it can be a compiler flag, since those memory
> implementation
> knobs can change at runtime.
>
> Let the flag be called, =E2=80=9CI intend to install an aborting new-hand=
ler.=E2=80=9D

I don't see how that helps, if the knobs are changed to reliably fail
memory allocations
even in recoverable situations. Aborting in such cases isn't sane.

>
> sake of argument, you could build both ways and select one at application
> launch.
>
> I wouldn't need the noexcept-ness of new for that solution.
>
> You would compile one binary with operator new noexcept and one with
> noexcept(false), and run whichever matches the current quota state. Yes, =
the

And when that "quota state" changes, I will have to restart, since I'm
running the
wrong binary. No thanks.

> Anyway, the main scenario here is desktop, embedded, or other single-user
> software that is not operated by a sysadmin.

Right. No wonder I don't recognize such systems, since my desktop is not a
single-user system and neither are my embedded systems.

> There are certainly cases where the noexcept operator is used to choose a
> conservative path.
>
> That sounds like a programmer would _have_ to use that operator to implem=
ent
> two paths.
>
> With noexcept(auto), the operator immediately applied to the new-expressi=
on
> could be implicit.

I don't see how that helps. I still have to cope with both a
non-throwing new and a throwing new.

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

.

On 2015-04-17 13:10, David Krauss wrote:
> With overcommitment, new becomes noexcept and malloc never returns=20
> nullptr =E2=80=94 at least unless VM is exhausted, which is an extreme ca=
se=20
> implying irrecoverable overcommitment. Might as well terminate then
> and there, since VM certainly outstrips physical storage.

Does it? On a 32-bit system with PAE (or just running a 32-bit program
on a 64-bit kernel), I might well have 16 GiB of physical RAM, and a
process could conceivably allocate and use 2 GiB (or whatever the OS
allows when accounting for reserved address space). If I request more
memory, that request must fail, because I have exhausted the available
(permissible) address space... but I'm nowhere near out of actual
available memory (*physical*, much less VM).

Now, obviously this is not the case with a 64-bit address space, but I
don't know that we should be writing the standard to assume that address
space exceeds VM, when there are certainly platforms for which that is
not the case.

Also, don't forget the case of applications erroneously doing things
like requesting terrabytes of memory. (It happens. Due to bugs, of
course, but similarly, I don't think we want to disallow the OS to
refuse such allocations.)

--=20
Matthew

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

> On 2015=E2=80=9304=E2=80=9318, at 2:55 AM, Matthew Woehlke <mw_triad@user=
s.sourceforge.net> wrote:
>=20
> On a 32-bit system with PAE (or just running a 32-bit program
> on a 64-bit kernel), I might well have 16 GiB of physical RAM

Certainly.

> Now, obviously this is not the case with a 64-bit address space, but I
> don't know that we should be writing the standard to assume that address
> space exceeds VM, when there are certainly platforms for which that is
> not the case.

If the proposed extension wouldn=E2=80=99t be appropriate in some environme=
nt, then it wouldn=E2=80=99t be used. I don=E2=80=99t think anyone suggeste=
d that it should ever be mandated by the standard.

I=E2=80=99m just trying to provide motivating examples. Not doing a particu=
larly good job, perhaps. Focusing on overcommitted VM behavior is almost a =
cause-and-effect fallacy. Such operating systems behave that way in part be=
cause they have evolved to run applications lacking in memory exception han=
dling. There are a lot of such programs, and if they can be run more effici=
ently, then why not.

However, it would be nice if Olaf could expand a bit more on what issue or =
observed overhead inspired him to suggest this.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_1498_685928549.1429355791889
Content-Type: multipart/alternative;
 boundary="----=_Part_1499_342977673.1429355791899"

------=_Part_1499_342977673.1429355791899
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Op vrijdag 17 april 2015 20:55:23 UTC+2 schreef Matthew Woehlke:
>
> On 2015-04-17 13:10, David Krauss wrote:=20
> > With overcommitment, new becomes noexcept and malloc never returns=20
> > nullptr =E2=80=94 at least unless VM is exhausted, which is an extreme =
case=20
> > implying irrecoverable overcommitment. Might as well terminate then=20
> > and there, since VM certainly outstrips physical storage.=20
>
> Does it? On a 32-bit system with PAE (or just running a 32-bit program=20
> on a 64-bit kernel), I might well have 16 GiB of physical RAM, and a=20
> process could conceivably allocate and use 2 GiB (or whatever the OS=20
> allows when accounting for reserved address space). If I request more=20
>

4G usually
=20

> Also, don't forget the case of applications erroneously doing things=20
> like requesting terrabytes of memory. (It happens. Due to bugs, of=20
> course, but similarly, I don't think we want to disallow the OS to=20
> refuse such allocations.)=20
>

How did we get into OS land?
Obviously the OS is allowed (even required) to fail this request.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">Op vrijdag 17 april 2015 20:55:23 UTC+2 schreef Matthew Wo=
ehlke:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-04-17 13:10, Dav=
id Krauss wrote:
<br>&gt; With overcommitment, new becomes noexcept and malloc never returns=
=20
<br>&gt; nullptr =E2=80=94 at least unless VM is exhausted, which is an ext=
reme case=20
<br>&gt; implying irrecoverable overcommitment. Might as well terminate the=
n
<br>&gt; and there, since VM certainly outstrips physical storage.
<br>
<br>Does it? On a 32-bit system with PAE (or just running a 32-bit program
<br>on a 64-bit kernel), I might well have 16 GiB of physical RAM, and a
<br>process could conceivably allocate and use 2 GiB (or whatever the OS
<br>allows when accounting for reserved address space). If I request more
<br></blockquote><div><br></div><div>4G usually</div><div>&nbsp;</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">Also, don't forget the case of appl=
ications erroneously doing things
<br>like requesting terrabytes of memory. (It happens. Due to bugs, of
<br>course, but similarly, I don't think we want to disallow the OS to
<br>refuse such allocations.)
<br></blockquote><div><br></div><div>How did we get into OS land?</div><div=
>Obviously the OS is allowed (even required) to fail this request.</div></d=
iv>

<p></p>

-- <br />
<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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1499_342977673.1429355791899--
------=_Part_1498_685928549.1429355791889--

.

------=_Part_235_462648603.1429363678945
Content-Type: multipart/alternative;
 boundary="----=_Part_236_1844268481.1429363678945"

------=_Part_236_1844268481.1429363678945
Content-Type: text/plain; charset=UTF-8

Op vrijdag 17 april 2015 21:29:17 UTC+2 schreef David Krauss:
>
> However, it would be nice if Olaf could expand a bit more on what issue or
> observed overhead inspired him to suggest this.


Mostly personal curiosity.
I see lots of programs that abort on out of memory while finding programs
that do catch bad_alloc and do something interesting seems hard.

I see lots of complexity due to error forwarding code, mostly in C
libraries. I see lots of discussion about noexcept, move constructors etc,
and I'm wondering what performance costs exist due to potential exceptions
from new.

So I'm wondering whether there's opportunity for improvements.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Op vrijdag 17 april 2015 21:29:17 UTC+2 schreef David Krau=
ss:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">However, it would be nice i=
f Olaf could expand a bit more on what issue or observed overhead inspired =
him to suggest this.</blockquote><div><br></div><div>Mostly personal curios=
ity.</div><div>I see lots of programs that abort on out of memory while fin=
ding programs that do catch bad_alloc and do something interesting seems ha=
rd.&nbsp;</div><div><br></div><div>I see lots of complexity due to error fo=
rwarding code, mostly in C libraries. I see lots of discussion about noexce=
pt, move constructors etc, and I'm wondering what performance costs exist d=
ue to potential exceptions from new.</div><div><br></div><div>So I'm wonder=
ing whether there's opportunity for improvements.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_236_1844268481.1429363678945--
------=_Part_235_462648603.1429363678945--

.

On 2015-04-18 07:16, Olaf van der Spek wrote:
> Op vrijdag 17 april 2015 20:55:23 UTC+2 schreef Matthew Woehlke:
>> On 2015-04-17 13:10, David Krauss wrote:=20
>>> With overcommitment, new becomes noexcept and malloc never returns=20
>>> nullptr =E2=80=94 at least unless VM is exhausted, which is an extreme =
case=20
>>> implying irrecoverable overcommitment. Might as well terminate then=20
>>> and there, since VM certainly outstrips physical storage.=20
>>
>> Does it? On a 32-bit system with PAE (or just running a 32-bit program=
=20
>> on a 64-bit kernel), I might well have 16 GiB of physical RAM, and a=20
>> process could conceivably allocate and use 2 GiB (or whatever the OS=20
>> allows when accounting for reserved address space). If I request more=20
>=20
> 4G usually

Er... no? On Linux, the kernel reserves 1 GiB of the addressable space
for its own purposes, so the maximum that a process can actually
allocate is therefore only 3 GiB. On Windows, it used to be only 2 GiB
by default, but there was a way to boot the OS so that it would only
reserve 1 GiB, allowing 3 GiB. I would assume other OS's also need to
reserve memory for the OS for similar reasons, and thus would have
similar limits.

(IIRC, one of the troubles with the 3 GiB switch is that some
applications would be so hard-wired with the assumed 2 GiB limit as to
(ab)use the sign bit of an address for various purposes and would
malfunction as a result when run in 3 GiB mode.)

--=20
Matthew

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

2015-04-24 1:37 GMT+02:00 Matthew Woehlke <mw_triad@users.sourceforge.net>:
> On 2015-04-18 07:16, Olaf van der Spek wrote:
>> Op vrijdag 17 april 2015 20:55:23 UTC+2 schreef Matthew Woehlke:
>>> On 2015-04-17 13:10, David Krauss wrote:
>>>> With overcommitment, new becomes noexcept and malloc never returns
>>>> nullptr =E2=80=94 at least unless VM is exhausted, which is an extreme=
 case
>>>> implying irrecoverable overcommitment. Might as well terminate then
>>>> and there, since VM certainly outstrips physical storage.
>>>
>>> Does it? On a 32-bit system with PAE (or just running a 32-bit program
>>> on a 64-bit kernel), I might well have 16 GiB of physical RAM, and a
>>> process could conceivably allocate and use 2 GiB (or whatever the OS
>>> allows when accounting for reserved address space). If I request more
>>
>> 4G usually
>
> Er... no? On Linux, the kernel reserves 1 GiB of the addressable space
> for its own purposes, so the maximum that a process can actually
> allocate is therefore only 3 GiB. On Windows, it used to be only 2 GiB
> by default, but there was a way to boot the OS so that it would only
> reserve 1 GiB, allowing 3 GiB. I would assume other OS's also need to
> reserve memory for the OS for similar reasons, and thus would have
> similar limits.

Are you talking about a 32-bit or a 64-bit kernel? Sounds like a
32-bit kernel (perhaps without PAE).

> (IIRC, one of the troubles with the 3 GiB switch is that some
> applications would be so hard-wired with the assumed 2 GiB limit as to
> (ab)use the sign bit of an address for various purposes and would
> malfunction as a result when run in 3 GiB mode.)

Right, a 32-bit process only gets more than 2G if it's
LARGEADDRESSAWARE on Windows.



--=20
Olaf

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 2015-04-24 01:35, Olaf van der Spek wrote:
> 2015-04-24 1:37 GMT+02:00 Matthew Woehlke <mw_triad@users.sourceforge.net=
>:
>> On 2015-04-18 07:16, Olaf van der Spek wrote:
>>> Op vrijdag 17 april 2015 20:55:23 UTC+2 schreef Matthew Woehlke:
>>>> On 2015-04-17 13:10, David Krauss wrote:
>>>>> With overcommitment, new becomes noexcept and malloc never returns
>>>>> nullptr =E2=80=94 at least unless VM is exhausted, which is an extrem=
e case
>>>>> implying irrecoverable overcommitment. Might as well terminate then
>>>>> and there, since VM certainly outstrips physical storage.
>>>>
>>>> Does it? On a 32-bit system with PAE (or just running a 32-bit program
>>>> on a 64-bit kernel), I might well have 16 GiB of physical RAM, and a
>>>> process could conceivably allocate and use 2 GiB (or whatever the OS
>>>> allows when accounting for reserved address space). If I request more
>>>
>>> 4G usually
>>
>> Er... no? On Linux, the kernel reserves 1 GiB of the addressable space
>> for its own purposes, so the maximum that a process can actually
>> allocate is therefore only 3 GiB. On Windows, it used to be only 2 GiB
>> by default, but there was a way to boot the OS so that it would only
>> reserve 1 GiB, allowing 3 GiB. I would assume other OS's also need to
>> reserve memory for the OS for similar reasons, and thus would have
>> similar limits.
>=20
> Are you talking about a 32-bit or a 64-bit kernel? Sounds like a
> 32-bit kernel (perhaps without PAE).

Either, I think. As I understand it, the reserved address space is so
that certain kernel memory can be kept in the application's address
space so that memory can be exchanged more readily (and without page
table surgery).

Basically, my understanding is that within a process, part of the
address space is set aside for kernel purposes (e.g. video, file/socket
buffers, other syscalls...). This memory may be *useful* to the
application (e.g. file buffers) and indeed the application may read from
or even write to it, but it cannot be obtained via malloc().

In that sense, the application may have *access* to the full 4 GiB, but
the application (userland) cannot *allocate* 4 GiB; the 'reserved' area
can only be obtained via OS resources.

--=20
Matthew

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

2015-04-27 22:25 GMT+02:00 Matthew Woehlke <mw_triad@users.sourceforge.net>:
>>>> 4G usually
>>>
>>> Er... no? On Linux, the kernel reserves 1 GiB of the addressable space
>>> for its own purposes, so the maximum that a process can actually
>>> allocate is therefore only 3 GiB. On Windows, it used to be only 2 GiB
>>> by default, but there was a way to boot the OS so that it would only
>>> reserve 1 GiB, allowing 3 GiB. I would assume other OS's also need to
>>> reserve memory for the OS for similar reasons, and thus would have
>>> similar limits.
>>
>> Are you talking about a 32-bit or a 64-bit kernel? Sounds like a
>> 32-bit kernel (perhaps without PAE).
>
> Either, I think. As I understand it, the reserved address space is so
> that certain kernel memory can be kept in the application's address
> space so that memory can be exchanged more readily (and without page
> table surgery).

> Basically, my understanding is that within a process, part of the
> address space is set aside for kernel purposes (e.g. video, file/socket
> buffers, other syscalls...). This memory may be *useful* to the
> application (e.g. file buffers) and indeed the application may read from
> or even write to it, but it cannot be obtained via malloc().
>
> In that sense, the application may have *access* to the full 4 GiB, but
> the application (userland) cannot *allocate* 4 GiB; the 'reserved' area
> can only be obtained via OS resources.

AFAIK that's not true, 32-bit apps on 64-bit Windows can use the full
4G address space.


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

.

On Tuesday 28 April 2015 00:21:20 Olaf van der Spek wrote:
> 2015-04-27 22:25 GMT+02:00 Matthew Woehlke <mw_triad@users.sourceforge.net>:
> >>>> 4G usually
> >>>
> >>> Er... no? On Linux, the kernel reserves 1 GiB of the addressable space
> >>> for its own purposes, so the maximum that a process can actually
> >>> allocate is therefore only 3 GiB. On Windows, it used to be only 2 GiB
> >>> by default, but there was a way to boot the OS so that it would only
> >>> reserve 1 GiB, allowing 3 GiB. I would assume other OS's also need to
> >>> reserve memory for the OS for similar reasons, and thus would have
> >>> similar limits.
> >>
> >> Are you talking about a 32-bit or a 64-bit kernel? Sounds like a
> >> 32-bit kernel (perhaps without PAE).
> >
> > Either, I think. As I understand it, the reserved address space is so
> > that certain kernel memory can be kept in the application's address
> > space so that memory can be exchanged more readily (and without page
> > table surgery).
> >
> > Basically, my understanding is that within a process, part of the
> > address space is set aside for kernel purposes (e.g. video, file/socket
> > buffers, other syscalls...). This memory may be *useful* to the
> > application (e.g. file buffers) and indeed the application may read from
> > or even write to it, but it cannot be obtained via malloc().
> >
> > In that sense, the application may have *access* to the full 4 GiB, but
> > the application (userland) cannot *allocate* 4 GiB; the 'reserved' area
> > can only be obtained via OS resources.
>
> AFAIK that's not true, 32-bit apps on 64-bit Windows can use the full
> 4G address space.

Out of curiosity, do you know how this works? A link to an article, perhaps?

--

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

.

2015-04-28 0:34 GMT+02:00 Andrey Semashev <andrey.semashev@gmail.com>:
> On Tuesday 28 April 2015 00:21:20 Olaf van der Spek wrote:
>> 2015-04-27 22:25 GMT+02:00 Matthew Woehlke <mw_triad@users.sourceforge.net>:
>> >>>> 4G usually
>> >>>
>> >>> Er... no? On Linux, the kernel reserves 1 GiB of the addressable space
>> >>> for its own purposes, so the maximum that a process can actually
>> >>> allocate is therefore only 3 GiB. On Windows, it used to be only 2 GiB
>> >>> by default, but there was a way to boot the OS so that it would only
>> >>> reserve 1 GiB, allowing 3 GiB. I would assume other OS's also need to
>> >>> reserve memory for the OS for similar reasons, and thus would have
>> >>> similar limits.
>> >>
>> >> Are you talking about a 32-bit or a 64-bit kernel? Sounds like a
>> >> 32-bit kernel (perhaps without PAE).
>> >
>> > Either, I think. As I understand it, the reserved address space is so
>> > that certain kernel memory can be kept in the application's address
>> > space so that memory can be exchanged more readily (and without page
>> > table surgery).
>> >
>> > Basically, my understanding is that within a process, part of the
>> > address space is set aside for kernel purposes (e.g. video, file/socket
>> > buffers, other syscalls...). This memory may be *useful* to the
>> > application (e.g. file buffers) and indeed the application may read from
>> > or even write to it, but it cannot be obtained via malloc().
>> >
>> > In that sense, the application may have *access* to the full 4 GiB, but
>> > the application (userland) cannot *allocate* 4 GiB; the 'reserved' area
>> > can only be obtained via OS resources.
>>
>> AFAIK that's not true, 32-bit apps on 64-bit Windows can use the full
>> 4G address space.
>
> Out of curiosity, do you know how this works? A link to an article, perhaps?

https://support2.microsoft.com/default.aspx?scid=889654

Or Google for LargeAddressAware


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

.

This is a multi-part message in MIME format.
--------------060003060200060802030803
Content-Type: text/plain; charset=UTF-8

On 28/04/15 01:34, Andrey Semashev wrote:
> On Tuesday 28 April 2015 00:21:20 Olaf van der Spek wrote:
>>
>> AFAIK that's not true, 32-bit apps on 64-bit Windows can use the full
>> 4G address space.
> Out of curiosity, do you know how this works? A link to an article, perhaps?
>
Here's the gist of it.

The kernel wants to have syscalls and other switches into the kernel to
be as quick and painless as possible. To facilitate that, we want to
avoid a full MMU context switch into and out of the kernel (with the
resulting TLB flush). In other words, when a syscall or interrupt
happens, the kernel wishes to have its memory already mapped in place.

In order to have that, the kernel memory map must be present in each and
every context running in the system. This way, no matter which user
space process was running, the kernel's memory is there and mapped.

To facilitate that, the kernel allocates a certain fixed amount out of
the *kernel's* virtual address space, which will always be the kernel
mapping. These addresses are unavailable to user space processes,
regardless of how much physical memory exists.

Under 32 bit kernels, the kernel's virtual address space is 4GB. Some
kernel reserve 2GB, leaving user space with 2GB, some 1GB, leaving user
space with 3GB. Under 64 bit kernels, this depends on how many bits the
CPU has for virtual memory (48 on my machine). This means that there is
usually more than enough left for user space.

When a 32 bit process runs over a 64 bit kernel, the kernel reserved
addresses are still allocated out of the 48 bit address space, and the
user space can see the whole 4GB.

When the kernel uses PAE, user space has less, not more, memory left.
Managing each page of physical memory requires memory, and under the 3:1
split there sometimes simply isn't enough. I've seen a case where a
company running a 16GB Ram machine would get processes killed by the oom
killer (out of memory killer, look it up). After some investigation it
turned out that the kernel was running out of virtual addresses to store
the mappings for the physical memory, and was killing random user space
processes to free up space. Removing memory resolved this problem
(switching to 64 bit was not possible due to a missing driver).

Shachar

--

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

--------------060003060200060802030803
Content-Type: text/html; charset=UTF-8

<html style="direction: ltr;">
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
    <style type="text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;" bidimailui-charset-is-forced="true"
    bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 28/04/15 01:34, Andrey Semashev
      wrote:<br>
    </div>
    <blockquote cite="mid:7453565.KkE4OVT2iW@lastique-pc" type="cite">
      <pre wrap="">On Tuesday 28 April 2015 00:21:20 Olaf van der Spek wrote:
</pre>
      <blockquote type="cite"><br>
        <pre wrap="">
AFAIK that's not true, 32-bit apps on 64-bit Windows can use the full
4G address space.
</pre>
      </blockquote>
      <pre wrap="">
Out of curiosity, do you know how this works? A link to an article, perhaps?

</pre>
    </blockquote>
    Here's the gist of it.<br>
    <br>
    The kernel wants to have syscalls and other switches into the kernel
    to be as quick and painless as possible. To facilitate that, we want
    to avoid a full MMU context switch into and out of the kernel (with
    the resulting TLB flush). In other words, when a syscall or
    interrupt happens, the kernel wishes to have its memory already
    mapped in place.<br>
    <br>
    In order to have that, the kernel memory map must be present in each
    and every context running in the system. This way, no matter which
    user space process was running, the kernel's memory is there and
    mapped.<br>
    <br>
    To facilitate that, the kernel allocates a certain fixed amount out
    of the <b>kernel's</b> virtual address space, which will always be
    the kernel mapping. These addresses are unavailable to user space
    processes, regardless of how much physical memory exists.<br>
    <br>
    Under 32 bit kernels, the kernel's virtual address space is 4GB.
    Some kernel reserve 2GB, leaving user space with 2GB, some 1GB,
    leaving user space with 3GB. Under 64 bit kernels, this depends on
    how many bits the CPU has for virtual memory (48 on my machine).
    This means that there is usually more than enough left for user
    space.<br>
    <br>
    When a 32 bit process runs over a 64 bit kernel, the kernel reserved
    addresses are still allocated out of the 48 bit address space, and
    the user space can see the whole 4GB.<br>
    <br>
    When the kernel uses PAE, user space has less, not more, memory
    left. Managing each page of physical memory requires memory, and
    under the 3:1 split there sometimes simply isn't enough. I've seen a
    case where a company running a 16GB Ram machine would get processes
    killed by the oom killer (out of memory killer, look it up). After
    some investigation it turned out that the kernel was running out of
    virtual addresses to store the mappings for the physical memory, and
    was killing random user space processes to free up space. Removing
    memory resolved this problem (switching to 64 bit was not possible
    due to a missing driver).<br>
    <br>
    Shachar<br>
  </body>
</html>

<p></p>

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

--------------060003060200060802030803--

.

This is a multi-part message in MIME format.
--------------090903070405090201030205
Content-Type: text/plain; charset=UTF-8

On 24/04/15 02:37, Matthew Woehlke wrote:
> IIRC, one of the troubles with the 3 GiB switch is that some
> applications would be so hard-wired with the assumed 2 GiB limit as to
> (ab)use the sign bit of an address for various purposes and would
> malfunction as a result when run in 3 GiB mode.
Not exactly. It is easy to accidentally put in an extra bit dependence.
Imagine the following code to find the middle point of a binary search:

e *middle( e *start, e *end ) {
    return (e *)(((unsigned long)start+(unsigned long)end)/2);
}

Yes, this code is horrible for a bunch of reasons, but one of them is
that if end is past the 2GB mark, the addition might overflow, resulting
in a very small pointer leading nowhere. Apparently, Microsoft was
worried enough about this[1] to put in a flag that means you do not get
a 3:1 split unless you flag that your program can take it.

Shachar

1 - From my experience, there are two options. Either lots of programs
were suffering from this, or just one or two were, but those were very
important. "Important", here, usually means something every computer has
installed, or MS would like that every computer would have it installed.

--

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

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

<html style=3D"direction: ltr;">
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
    <style type=3D"text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt=
; } </style>
  </head>
  <body style=3D"direction: ltr;" bidimailui-charset-is-forced=3D"true"
    bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 24/04/15 02:37, Matthew Woehlke
      wrote:<br>
    </div>
    <blockquote cite=3D"mid:mhbvn4$dlv$1@ger.gmane.org" type=3D"cite">
      <pre wrap=3D"">IIRC, one of the troubles with the 3 GiB switch is tha=
t some
applications would be so hard-wired with the assumed 2 GiB limit as to
(ab)use the sign bit of an address for various purposes and would
malfunction as a result when run in 3 GiB mode.</pre>
    </blockquote>
    Not exactly. It is easy to accidentally put in an extra bit
    dependence. Imagine the following code to find the middle point of a
    binary search:<br>
    <br>
    e *middle( e *start, e *end ) {<br>
    =C2=A0=C2=A0=C2=A0 return (e *)(((unsigned long)start+(unsigned long)en=
d)/2);<br>
    }<br>
    <br>
    Yes, this code is horrible for a bunch of reasons, but one of them
    is that if end is past the 2GB mark, the addition might overflow,
    resulting in a very small pointer leading nowhere. Apparently,
    Microsoft was worried enough about this[1] to put in a flag that
    means you do not get a 3:1 split unless you flag that your program
    can take it.<br>
    <br>
    Shachar<br>
    <br>
    1 - From my experience, there are two options. Either lots of
    programs were suffering from this, or just one or two were, but
    those were very important. "Important", here, usually means
    something every computer has installed, or MS would like that every
    computer would have it installed.<br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------090903070405090201030205--

.

On Tuesday 28 April 2015 02:58:19 Shachar Shemesh wrote:
> On 28/04/15 01:34, Andrey Semashev wrote:
> > On Tuesday 28 April 2015 00:21:20 Olaf van der Spek wrote:
> >> AFAIK that's not true, 32-bit apps on 64-bit Windows can use the full
> >> 4G address space.
> >
> > Out of curiosity, do you know how this works? A link to an article,
> > perhaps?
> Here's the gist of it.
>
> The kernel wants to have syscalls and other switches into the kernel to
> be as quick and painless as possible. To facilitate that, we want to
> avoid a full MMU context switch into and out of the kernel (with the
> resulting TLB flush). In other words, when a syscall or interrupt
> happens, the kernel wishes to have its memory already mapped in place.
>
> In order to have that, the kernel memory map must be present in each and
> every context running in the system. This way, no matter which user
> space process was running, the kernel's memory is there and mapped.
>
> To facilitate that, the kernel allocates a certain fixed amount out of
> the *kernel's* virtual address space, which will always be the kernel
> mapping. These addresses are unavailable to user space processes,
> regardless of how much physical memory exists.
>
> Under 32 bit kernels, the kernel's virtual address space is 4GB. Some
> kernel reserve 2GB, leaving user space with 2GB, some 1GB, leaving user
> space with 3GB. Under 64 bit kernels, this depends on how many bits the
> CPU has for virtual memory (48 on my machine). This means that there is
> usually more than enough left for user space.
>
> When a 32 bit process runs over a 64 bit kernel, the kernel reserved
> addresses are still allocated out of the 48 bit address space, and the
> user space can see the whole 4GB.

Thanks for the explanation, this last part is what I was wondering about. So
the kernel does not need to reserve address space from the application in the
case of a 32-bit app running on a 64-bit kernel. This means that there can be
no system API that can work in userspace with the kernel memory. This is
something that is used in Linux on x86, AFAIK, where some frequent system
calls like clock_gettime are done as direct access to the kernel memory from
userspace without transitioning into kernel execution mode. Although the
number of such fast system routines is small, so as the amount of the address
space needed for that.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

This is a multi-part message in MIME format.
--------------070903090504090305040805
Content-Type: text/plain; charset=UTF-8

On 28/04/15 07:24, Andrey Semashev wrote:
> This means that there can be
> no system API that can work in userspace with the kernel memory.
No. That's not correct. The kernel memory just needs to be mapped to a
userspace address.
>  This is
> something that is used in Linux on x86, AFAIK, where some frequent system
> calls like clock_gettime are done as direct access to the kernel memory from
> userspace without transitioning into kernel execution mode.
If you cat any process' /proc/pid/maps, you will see a line labeled
"vdso". That what you're referring to. It's also available on x86_64.

Shachar

--

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

--------------070903090504090305040805
Content-Type: text/html; charset=UTF-8

<html style="direction: ltr;">
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
    <style type="text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;" bidimailui-charset-is-forced="true"
    bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 28/04/15 07:24, Andrey Semashev
      wrote:<br>
    </div>
    <blockquote cite="mid:1550898.eQ9kmvXYS7@lastique-pc" type="cite">
      <pre wrap="">
This means that there can be
no system API that can work in userspace with the kernel memory.</pre>
    </blockquote>
    No. That's not correct. The kernel memory just needs to be mapped to
    a userspace address.<br>
    <blockquote cite="mid:1550898.eQ9kmvXYS7@lastique-pc" type="cite">
      <pre wrap=""> This is
something that is used in Linux on x86, AFAIK, where some frequent system
calls like clock_gettime are done as direct access to the kernel memory from
userspace without transitioning into kernel execution mode.</pre>
    </blockquote>
    If you cat any process' /proc/pid/maps, you will see a line labeled
    "vdso". That what you're referring to. It's also available on
    x86_64.<br>
    <br>
    Shachar<br>
  </body>
</html>

<p></p>

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

--------------070903090504090305040805--

.

On Tue, Apr 28, 2015 at 8:25 AM, Shachar Shemesh <shachar@lingnu.com> wrote:
> On 28/04/15 07:24, Andrey Semashev wrote:
>
> This means that there can be
> no system API that can work in userspace with the kernel memory.
>
> No. That's not correct. The kernel memory just needs to be mapped to a
> userspace address.

Yes, and that basically reserves some amount of address space from the
application use, doesn't 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/.

.

This is a multi-part message in MIME format.
--------------080606060406040206010902
Content-Type: text/plain; charset=UTF-8

On 28/04/15 10:12, Andrey Semashev wrote:
> On Tue, Apr 28, 2015 at 8:25 AM, Shachar Shemesh <shachar@lingnu.com> wrote:
>> On 28/04/15 07:24, Andrey Semashev wrote:
>>
>> This means that there can be
>> no system API that can work in userspace with the kernel memory.
>>
>> No. That's not correct. The kernel memory just needs to be mapped to a
>> userspace address.
> Yes, and that basically reserves some amount of address space from the
> application use, doesn't it?
>
A single page, give or take. Nothing you'd miss, even on a 32 bit
platform with only 3GB of available RAM.

Shachar

--

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

--------------080606060406040206010902
Content-Type: text/html; charset=UTF-8

<html style="direction: ltr;">
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
    <style type="text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;" bidimailui-charset-is-forced="true"
    bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 28/04/15 10:12, Andrey Semashev
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAEhD+6COTMvnn9nZmYfi1GFLitgo6Hnio+1HHCa6nkobZWHdSw@mail.gmail.com"
      type="cite">
      <pre wrap="">On Tue, Apr 28, 2015 at 8:25 AM, Shachar Shemesh <a class="moz-txt-link-rfc2396E" href="mailto:shachar@lingnu.com">&lt;shachar@lingnu.com&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 28/04/15 07:24, Andrey Semashev wrote:

This means that there can be
no system API that can work in userspace with the kernel memory.

No. That's not correct. The kernel memory just needs to be mapped to a
userspace address.
</pre>
      </blockquote>
      <pre wrap="">
Yes, and that basically reserves some amount of address space from the
application use, doesn't it?

</pre>
    </blockquote>
    A single page, give or take. Nothing you'd miss, even on a 32 bit
    platform with only 3GB of available RAM.<br>
    <br>
    Shachar<br>
  </body>
</html>

<p></p>

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

--------------080606060406040206010902--

.

On Tuesday 28 April 2015 20:06:18 Shachar Shemesh wrote:
> On 28/04/15 10:12, Andrey Semashev wrote:
> > On Tue, Apr 28, 2015 at 8:25 AM, Shachar Shemesh <shachar@lingnu.com>
wrote:
> >> On 28/04/15 07:24, Andrey Semashev wrote:
> >>
> >> This means that there can be
> >> no system API that can work in userspace with the kernel memory.
> >>
> >> No. That's not correct. The kernel memory just needs to be mapped to a
> >> userspace address.
> >
> > Yes, and that basically reserves some amount of address space from the
> > application use, doesn't it?
>
> A single page, give or take. Nothing you'd miss, even on a 32 bit
> platform with only 3GB of available RAM.

The Linux vDSO is exactly one page in size by construction. Also note that you
have two more pages reserved anyway: the bottommost and the topmost page.

The bottommost page is the simplest to understand: it contains the NULL
pointer, so any dereferencing of the null-pointer usually results in
segmentation faults. The topmost page also helps in that, in case you subtract
from the NULL pointer and for internal reasons.

IIRC, there's still a way to ask most Unix systems (not just Linux) to map a
zero page at the 0 address, so you *can* dereference a null pointer. Yikes!

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_244_373212590.1430430343757
Content-Type: multipart/alternative;
 boundary="----=_Part_245_1931750890.1430430343757"

------=_Part_245_1931750890.1430430343757
Content-Type: text/plain; charset=UTF-8

Back on topic..
Is nobody able to provide an example of a real program that does something
interesting with bad_alloc?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_245_1931750890.1430430343757
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Back on topic..<div>Is nobody able to provide an example of a real program that does something interesting with bad_alloc?</div></div>

<p></p>

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

------=_Part_245_1931750890.1430430343757--
------=_Part_244_373212590.1430430343757--

.

--bcaec511e1321c547e0514fb4e74
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 30, 2015 at 2:45 PM, Olaf van der Spek <olafvdspek@gmail.com>
wrote:

> Back on topic..
> Is nobody able to provide an example of a real program that does something
> interesting with bad_alloc?
>

Depends on what is considered interesting: You are in an application and
open a large file from disk into memory, but it is too big. You can handle
the exception by alerting the user that the file cannot be opened and
continue executing the application as usual.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Apr 30, 2015 at 2:45 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:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Back=
 on topic..<div>Is nobody able to provide an example of a real program that=
 does something interesting with bad_alloc?</div></div></blockquote><div><b=
r></div><div>Depends on what is considered interesting: You are in an appli=
cation and open a large file from disk into memory, but it is too big. You =
can handle the exception by alerting the user that the file cannot be opene=
d and continue executing the application as usual.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec511e1321c547e0514fb4e74--

.

------=_Part_1781_88977748.1430591570869
Content-Type: multipart/alternative;
 boundary="----=_Part_1782_800392324.1430591570869"

------=_Part_1782_800392324.1430591570869
Content-Type: text/plain; charset=UTF-8



On Thursday, April 30, 2015 at 11:45:43 PM UTC+2, Olaf van der Spek wrote:
>
> Back on topic..
> Is nobody able to provide an example of a real program that does something
> interesting with bad_alloc?
>

std::bad_alloc is derived from std::exception -- I'd say about 9x% of our
catch handlers just catch std::exception, so we're implicitly catching
bad_alloc too -- we don't do anything interesting with it specifically, but
we've certainly seen bad_alloc and we *certainly* do not wan't to terminate.

bad_alloc is actually something that can reasonably easily happen on a 32
bit process on a modern system because you'll also get it when you're OOM
because of address space fragmentation, so say, that subsystem tried to
ramp up a buffer of 100MB, which should easily be possible because the
system has 9 GB free RAM, but oh my, that 32 bit process has just loaded
way too many plugins, so while there's quite some room for still a few 10
or 20 MB blocks, there's no 100MB block left.

And you really propose to terminate the app because plugin X cannot
allocate a 100MB buffer??

cheers.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Thursday, April 30, 2015 at 11:45:43 PM UTC+2, =
Olaf van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">Back on topic..<div>Is nobody able to provide an example of a re=
al program that does something interesting with bad_alloc?</div></div></blo=
ckquote><div><br>std::bad_alloc is derived from std::exception -- I'd say a=
bout 9x% of our catch handlers just catch std::exception, so we're implicit=
ly catching bad_alloc too -- we don't do anything interesting with it speci=
fically, but we've certainly seen bad_alloc and we *certainly* do not wan't=
 to terminate.<br><br>bad_alloc is actually something that can reasonably e=
asily happen on a 32 bit process on a modern system because you'll also get=
 it when you're OOM because of address space fragmentation, so say, that su=
bsystem tried to ramp up a buffer of 100MB, which should easily be possible=
 because the system has 9 GB free RAM, but oh my, that 32 bit process has j=
ust loaded way too many plugins, so while there's quite some room for still=
 a few 10 or 20 MB blocks, there's no 100MB block left.<br><br>And you real=
ly propose to terminate the app because plugin X cannot allocate a 100MB bu=
ffer??<br><br>cheers.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1782_800392324.1430591570869--
------=_Part_1781_88977748.1430591570869--

.