Topic: <csetjmp> deprecation


Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Fri, 2 Jan 2015 09:50:39 +0000
Raw View
Isn't it time to deprecate the standard headers <csetjmp> and <setjmp.h>?

--

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

.


Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 2 Jan 2015 12:27:49 +0200
Raw View
On 2 January 2015 at 11:50, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> Isn't it time to deprecate the standard headers <csetjmp> and <setjmp.h>?

1) It's non-obvious to me what purpose that deprecation would serve.
2) I'd like to hear vendor feedback on the feasibility and
consequences of such deprecation.

--

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

.


Author: David Krauss <potswa@gmail.com>
Date: Fri, 2 Jan 2015 19:44:33 +0800
Raw View
--Apple-Mail=_4383D9FD-6B17-4199-8A7A-3661F5C897CB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9301=E2=80=9302, at 5:50 PM, Douglas Boffey <douglas.boffey=
@gmail.com> wrote:
>=20
> Isn't it time to deprecate the standard headers <csetjmp> and <setjmp.h>?

Is it time to deprecate the notion of processing C-like code with a C++ com=
piler? C++ has better-developed or more sensible rules in various areas suc=
h as the memory model, threading, and implicit conversions. For programs th=
at can use it (i.e., which seldom use nontrivial destructors), it=E2=80=99s=
 a lighter-weight alternative to C++ exceptions.

Many C programs are valid C++ simply by virtue of overall sensibility. GCC =
4.9 made the switch with little fuss. Closing the migration path would need=
 good justification.

Like most of the C standard library, <setjmp.h> is part of POSIX, so we can=
=E2=80=99t make it go away in any case. Removing <csetjmp> would only force=
 people to remove any namespace-qualified calls to std::longjmp.

--=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=_4383D9FD-6B17-4199-8A7A-3661F5C897CB
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=9301=
=E2=80=9302, at 5:50 PM, Douglas Boffey &lt;<a href=3D"mailto:douglas.boffe=
y@gmail.com" class=3D"">douglas.boffey@gmail.com</a>&gt; wrote:</div><br cl=
ass=3D"Apple-interchange-newline"><div class=3D"">Isn't it time to deprecat=
e the standard headers &lt;csetjmp&gt; and &lt;setjmp.h&gt;?<br class=3D"">=
</div></blockquote></div><br class=3D""><div class=3D"">Is it time to depre=
cate the notion of processing C-like code with a C++ compiler? C++ has bett=
er-developed or more sensible rules in various areas such as the memory mod=
el, threading, and implicit conversions. For programs that can use it (i.e.=
, which seldom use nontrivial destructors), it=E2=80=99s a lighter-weight a=
lternative to C++ exceptions.</div><div class=3D""><br class=3D""></div><di=
v class=3D"">Many C programs are valid C++ simply by virtue of overall sens=
ibility. GCC 4.9 made the switch with little fuss. Closing the migration pa=
th would need good justification.</div><div class=3D""><br class=3D""></div=
><div class=3D"">Like most of the C standard library,&nbsp;<font face=3D"Co=
urier" class=3D"">&lt;setjmp.h&gt;</font> is part of POSIX, so we can=E2=80=
=99t make it go away in any case. Removing&nbsp;<font face=3D"Courier" clas=
s=3D"">&lt;csetjmp&gt;</font> would only force people to remove any namespa=
ce-qualified calls to&nbsp;<font face=3D"Courier" class=3D"">std::longjmp</=
font>.</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=_4383D9FD-6B17-4199-8A7A-3661F5C897CB--

.


Author: "Daniel Gutson" <danielgutson@gmail.com>
Date: Fri, 2 Jan 2015 11:58:10 +0000
Raw View
Why? What the replacement would be?
As an example, Sjlj (or sigsetjmp/siglongjump) is still used in some error handling situations, even from C++ code.
-----Original Message-----
From: Douglas Boffey <douglas.boffey@gmail.com>
Date: Fri, 2 Jan 2015 09:50:39
To: <Std-proposals@isocpp.org>
Reply-To: std-proposals@isocpp.org
Subject: [std-proposals] <csetjmp> deprecation

Isn't it time to deprecate the standard headers <csetjmp> and <setjmp.h>?

--

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

--

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

.


Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Fri, 2 Jan 2015 12:40:55 +0000
Raw View
Obviously a ill-considered suggestion, and I withdraw it :(

On 1/2/15, Daniel Gutson <danielgutson@gmail.com> wrote:
> Why? What the replacement would be?
> As an example, Sjlj (or sigsetjmp/siglongjump) is still used in some error
> handling situations, even from C++ code.
> -----Original Message-----
> From: Douglas Boffey <douglas.boffey@gmail.com>
> Date: Fri, 2 Jan 2015 09:50:39
> To: <Std-proposals@isocpp.org>
> Reply-To: std-proposals@isocpp.org
> Subject: [std-proposals] <csetjmp> deprecation
>
> Isn't it time to deprecate the standard headers <csetjmp> and <setjmp.h>?
>
> --
>
> ---
> 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/.
>
> --
>
> ---
> 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/.
>

--

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

.


Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 2 Jan 2015 14:51:00 +0200
Raw View
On 2 January 2015 at 14:40, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> Obviously a ill-considered suggestion, and I withdraw it :(


Well, it would be philosophically nice to get rid of something as ugly
and evil as the
subject matter. It doesn't cost me anything to have it currently, but
I sure as hell never
use it. Hence my curiosity about implementation vendor feedback, they might know
who still uses these contraptions and where.

Anyway, I think we have better things to do than deprecate such stuff,
deprecation
should target removal, and the benefit of deprecating or removing setjmp seems
rather small, so probably not worth the energy.

--

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

.