220 39347 <8866881c-ef1d-4c37-9242-5b1d3327c288@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Alternative proposal for mapping P0709 Deterministic Exceptions into C Date: Tue, 24 Jul 2018 08:58:23 -0700 (PDT) Lines: 103 Approved: news@gmane.org Message-ID: <8866881c-ef1d-4c37-9242-5b1d3327c288@isocpp.org> References: <6a65c934-5d2a-4e75-b88d-9eaaee338bd3@isocpp.org> <1c229827-6d5d-45bd-8766-c3af818b2b0b@isocpp.org> <4ac80882-16fc-4ab4-9a12-64da1ef0e974@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9239_1139466791.1532447903690" X-Trace: blaine.gmane.org 1532447780 4855 195.159.176.226 (24 Jul 2018 15:56:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 24 Jul 2018 15:56:20 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBIEZ3XNAKGQERYJXP5A@isocpp.org Tue Jul 24 17:56:16 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f197.google.com ([209.85.213.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fhzfa-00016X-Ie for gclcip-std-proposals@m.gmane.org; Tue, 24 Jul 2018 17:56:15 +0200 Original-Received: by mail-yb0-f197.google.com with SMTP id c8-v6sf2256409ybi.19 for ; Tue, 24 Jul 2018 08:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=h5iIRpkuhZxV5q5NQCaaNyjyT+nq5l3Om7ovZw3EKWQ=; b=uTCE++5uk1t+EpXBPgqxClc4N3kYOTPrA0T9RfAqoDlBgIqdnthsk59ZHTSgBYu5Kv q/17jzN+os12q4EdlAyV64WSHCIgcblWtiU6Q6zVKJqWdIfP2POH6FWChcevWLiFBkhS 1p8cYrMuw4jGV9qBAzmgQPuYqxsQI/DF6yz+dBY+cQR1UyGJcepwmpnAoDWvI54S9uno jY+nyhtquavT19s0nDHcAkPPcXGAg7aRqouyB8AonzRnOprO13TZWAzv5EgNH3Qw0TaF FCmzA1BytZiKp6OQl6/Ld1LHDAD+PGMk456iP2Ga9AQ90YFNR9Yx14RCCMfDRC32zK4q p1Xw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=h5iIRpkuhZxV5q5NQCaaNyjyT+nq5l3Om7ovZw3EKWQ=; b=Fv7FFO5NWeZeZVMlPtyh42bSy7W/WMwDoXsROe/Kb/QEy5+Wv2Hs//UiWOj9ImuRqC XoHWJ7gTexE3Jm5T2l/2bO7K6KE3+CEJpJchBhh0InLH167NYtQxJBxQjKfj3nPENtmv 6K2eQahvW114SK9J9XyfVGhIeP5vD4VWaqfKGCGTjDmyud5wLThxIe5MfF6+mKEusvep XMRKbYLPzAEfgsX9C60HwQxYQ9e2Da6m3SvCl2g6LQzgJ1wykceBXOTCO156vOBGRwWy c9DCwZtxhDMtfHZARSFo/SbiZnayp0Z7768LA7WmTWix5NWijsh+f+rJIDtRgDXLRZyG sSlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=h5iIRpkuhZxV5q5NQCaaNyjyT+nq5l3Om7ovZw3EKWQ=; b=k0l99G8kl3G40fb89jYlXqjogstnlnJ3vznEY7+lPlppLh0VlMIUUGpe5dERtF+jKy Jlb+0UhNrP0cB1D9tDF3r2C8nqPEryl7HySEO26xfmhxxjQIiriJiwYUTkVp1FoTXrfp nE78LGnfmZKJJUG/Lw9mZUw8HZ5ngq8/Jdoo9NQamFNuA5csYAawVygHmJ5olYCPcv5t iSXQRSeG+n/y3pNs5SFWPo1arRIIkdfGRRDiIEpbRfecRtwsYy/sH4RhU95rg8g83uwL nDGMya6FyI9u5uin27HD0RfgOSVVF3rByr/YWPibQxgxRYEJkL11enjO0SAVBN6IWCZx w6hA== X-Gm-Message-State: AOUpUlFGrFoM/PAo2cywD2IPOOKFdsC5TS3j0mDP5UtZ7bOxCF7XTDQW nfDCwf7NS95ZOTN1lGSP+sQVyA== X-Google-Smtp-Source: AAOMgpdqIdzUTOEui3n0jxN7an49CjSUxb8Wl+yoQ0XOhjZExLplwNr4Tujmw/yZqlANjwkpVKFPsQ== X-Received: by 2002:a0d:c687:: with SMTP id i129-v6mr4879855ywd.58.1532447905388; Tue, 24 Jul 2018 08:58:25 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:fd7:: with SMTP id 206-v6ls1479273ywp.5.gmail; Tue, 24 Jul 2018 08:58:24 -0700 (PDT) X-Received: by 2002:a81:330a:: with SMTP id z10-v6mr320850ywz.5.1532447904205; Tue, 24 Jul 2018 08:58:24 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:39347 Archived-At: ------=_Part_9239_1139466791.1532447903690 Content-Type: multipart/alternative; boundary="----=_Part_9240_2042727669.1532447903691" ------=_Part_9240_2042727669.1532447903691 Content-Type: text/plain; charset="UTF-8" On Tuesday, July 24, 2018 at 11:41:45 AM UTC-4, Jake Arkinstall wrote: > > On Tue, 24 Jul 2018, 05:43 Nicol Bolas, > > wrote: > >> On Monday, July 23, 2018 at 9:55:11 PM UTC-4, Jake Arkinstall wrote: >>> >>> Error handling via an effective static state isn't thread safe. Marking >>> the flag as volatile and telling users to check for errors immediately >>> after the function call goes some way to help, I guess, but it's not >>> sufficient to guarantee that errors won't crop up in the wrong thread (or >>> do I have some reading to do?) >>> >> >> I think this is a misunderstanding of what the paper is saying. It is not >> talking about "static state" (even though it appears to). The >> `funcName.failed` bit is not intended to be a static property of >> `funcName`; it's closer to an invisible stack variable, which you access by >> using the function's name. The compiler turns "funcName.failed" into the >> specific stack location or register or whatever that maps to that data. >> > > Well, that leaves me with egg on my face. The proposal certainly makes > more sense given what you've said. On a similar note, then, what would this > do to our constexpr? > It's a C proposal; it doesn't interact with `constexpr`. Indeed, one of its biggest flaws is that it doesn't allow for inter-operation with C++ static exceptions at all, despite being in part based on the same principle. -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8866881c-ef1d-4c37-9242-5b1d3327c288%40isocpp.org. ------=_Part_9240_2042727669.1532447903691 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tuesday, July 24, 2018 at 11:41:45 AM UTC-4, Ja= ke Arkinstall wrote:
On Tue, 24 Jul 2= 018, 05:43 Nicol Bolas, <jmck...@gmail.com> wrote:
On Monday, July 23, 2018 at 9:55:11 P= M UTC-4, Jake Arkinstall wrote:
Error handli= ng via an effective static state isn't thread safe. Marking the flag as= volatile and telling users to check for errors immediately after the funct= ion call goes some way to help, I guess, but it's not sufficient to gua= rantee that errors won't crop up in the wrong thread (or do I have some= reading to do?)

I = think this is a misunderstanding of what the paper is saying. It is not tal= king about "static state" (even though it appears to). The `funcN= ame.failed` bit is not intended to be a static property of `funcName`; it&#= 39;s closer to an invisible stack variable, which you access by using the f= unction's name. The compiler turns "funcName.failed" into the= specific stack location or register or whatever that maps to that data.

Well, that leaves me with egg on my face. The proposal certainly = makes more sense given what you've said. On a similar note, then, what = would this do to our constexpr?

It's a C proposal; it doesn't interact with `constexpr`. Indeed, o= ne of its biggest flaws is that it doesn't allow for inter-operation wi= th C++ static exceptions at all, despite being in part based on the same pr= inciple.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/8866881c-ef1d-4c37-9242-5b1d3327c288= %40isocpp.org.
------=_Part_9240_2042727669.1532447903691-- ------=_Part_9239_1139466791.1532447903690-- .