220 33084 <694163cb-b551-425b-9f08-b229ca487859@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Support for exception-less error handling Date: Mon, 3 Jul 2017 13:42:31 -0700 (PDT) Lines: 115 Approved: news@gmane.org Message-ID: <694163cb-b551-425b-9f08-b229ca487859@isocpp.org> References: <6856d8da-734e-44c9-b45b-890f3142f83b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2027_224609003.1499114551383" X-Trace: blaine.gmane.org 1499114555 24735 195.159.176.226 (3 Jul 2017 20:42:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 3 Jul 2017 20:42:35 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBOGY5LFAKGQEGQFGDCY@isocpp.org Mon Jul 03 22:42:31 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f72.google.com ([74.125.83.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dS8Au-000609-Cv for gclcip-std-proposals@m.gmane.org; Mon, 03 Jul 2017 22:42:28 +0200 Original-Received: by mail-pg0-f72.google.com with SMTP id a2sf109690201pgn.15 for ; Mon, 03 Jul 2017 13:42:33 -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=Sk/Rw+A+EbQC45JPiFK/WBkKd6odM+T0Vph5F0sGr6o=; b=L1eaVJTO1jWRZGLD27r/llbbvQ+vN1mAm53CBIZBpDaUgiy3iMndBJP8k1ASZ6sp0q DdzoVpXmXQXQymiouh1rnHU6ojKSbQHivpQqMO2CZbIT1FnedKuJ18Aka0zPGJ+91Tz6 xbbmmfat6uRk/cC7q8CZ3AZWmCvZs2BSxXbikFualj8aGZze5q8fqeytMzzLn21G2+88 wlgNxWwS2zodsGtirMRwrTESa9nre4Ig8PH8J6PB3DNi+q0VzNGy+pigvk9VMiz4jgE1 4Vojm7jdmjA8fYUUsurhGVx3dHVQtsTeZUnzPHVpid5IxY+yOTXUkj8C17UVAmh9gNJd 7OhQ== 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=Sk/Rw+A+EbQC45JPiFK/WBkKd6odM+T0Vph5F0sGr6o=; b=Bl/w3XH3dTNONo74D7vPjD4149v3z1Pi2dBHGhG5sw+lKev1oAwPhWaQx3WwP0MR0p m1Z3BXWQlh/XB2UH1rzqrvRXT47Mz+uiifW0IabdM6PYUVRuuORZgYJEys9iuQ/AU2Lx BHAw0+StRrQp/1w0EKdn70CypUnGAaibIcMJV4p52JNYL4BkqIX2XGiU7DDXOGZluBf6 1qufg+EmDAevx5ghgD3aNgnkSDWBHnNPacE7i7MOPN4g2WIe/K9GRQgTe0NaAkaBG2Mh r/het9tDTyxd3fIElWudJjkLkB9dQjsikwsbVgEBSmUjpz751v51DEEV1f7ZKWxFBoTP JZ3w== 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=Sk/Rw+A+EbQC45JPiFK/WBkKd6odM+T0Vph5F0sGr6o=; b=Kp/1p+hI1AnG+Q3N7DvFR1/u+DKoo1XZQK/CND7FlyCML3Bm3+v4KTNrixO3RbUXKg EUpt+jekV9Wo2mRc/v8pk75fzxqy/zKQzb+4VUS9+X/86iqweX8oPrKCaK6+W3aRIgmS R1/2nzWDkSjpLa/i9sdu82EF4+9ukyPuN3cAjKqz7m1+ioQzedfSTvhuv7FByavd/9gJ oeqfDgiqijDJJasZFPENbu57lrlNOyz8Xz+2G70Yys1f7Rcotx6zQR2jq3IQYfrVPGjD p2RHn5FQWVSiUQWrNujsdbN37ifmuhultJpZrsgwd5qcIDDJwtVMymqlF6o/08kPAn7l xo6A== X-Gm-Message-State: AIVw112r/+Fywpy8BkaC8fxdzjrTzy3HN5LjdDqLH7Fm0loNuCsKDu8q KSGie3J/yLtl9rcR X-Received: by 10.101.89.6 with SMTP id f6mr8425554pgu.74.1499114553335; Mon, 03 Jul 2017 13:42:33 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.9.132 with SMTP id 126ls1258576itm.8.gmail; Mon, 03 Jul 2017 13:42:31 -0700 (PDT) X-Received: by 10.36.78.203 with SMTP id r194mr1169904ita.3.1499114551875; Mon, 03 Jul 2017 13:42:31 -0700 (PDT) In-Reply-To: <6856d8da-734e-44c9-b45b-890f3142f83b@isocpp.org> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:33084 Archived-At: ------=_Part_2027_224609003.1499114551383 Content-Type: multipart/alternative; boundary="----=_Part_2028_452221702.1499114551383" ------=_Part_2028_452221702.1499114551383 Content-Type: text/plain; charset="UTF-8" On Monday, July 3, 2017 at 4:21:14 PM UTC-4, Bengt Gustafsson wrote: > > I would doubt that the runtime overhead of exceptions is worse than that > of checking return values and continue returning out the call stack. > Especially in the no-error case it should be more efficient as those ifs > have potentially large runtime penalty regardless of if the jump > instruction is taken or not, while the exception unwinding code is > typically very asymmetric with a minimized runtime cost for the non-throw > case. > > So before suggesting another mechanism that simplifies writing code based > on error returns I would suggest actually measuring the performance in the > throwing and non-throwing case compared to a return value/if-based > solution. This article is not totally clear but casts serious doubts about > any speed gain from avoiding exceptions: > > > https://stackoverflow.com/questions/13835817/are-exceptions-in-c-really-slow > > Unfortunately (or fortunately as it is so old) the TS report linked to > does not show numbers for exception handling. Maybe someone else can point > to a paper detailing the performance for the different approaches? > You should really look at the SG14 forum and their various papers. They've made measurements, looking at both the cost of the non-exception case and the cost of the exceptional case. Furthermore, there are different types of users of C++. For some, having a *consistent* cost is more important than being faster most of the time but really slow if something exceptional happens. And consistency of performance can matter more in specific places than others. Overall, I think a pretty decent case has been made that having a functional alternative to exceptions, whether in the language or the library, would be a good thing. The most pernicious case is the difficulty of signaling errors from constructors; such a thing fundamentally requires a language-level solution (or to write constructors that can't fail). -- 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/694163cb-b551-425b-9f08-b229ca487859%40isocpp.org. ------=_Part_2028_452221702.1499114551383 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Monday, July 3, 2017 at 4:21:14 PM UTC-4, Bengt Gustafs= son wrote:
I w= ould doubt that the runtime overhead of exceptions is worse than that of ch= ecking return values and continue returning out the call stack. Especially = in the no-error case it should be more efficient as those ifs have potentia= lly large runtime penalty regardless of if the jump instruction is taken or= not, while the exception unwinding code is typically very asymmetric with = a minimized runtime cost for the non-throw case.

So befo= re suggesting another mechanism that simplifies writing code based on error= returns I would suggest actually measuring the performance in the throwing= and non-throwing case compared to a return value/if-based solution. This a= rticle is not totally clear but casts serious doubts about any speed gain f= rom avoiding exceptions:


Unfortunately (or fortunately as it is so old) the TS rep= ort linked to does not show numbers for exception handling. Maybe someone e= lse can point to a paper detailing the performance for the different approa= ches?

You should really look at the SG= 14 forum and their various papers. They've made measurements, looking a= t both the cost of the non-exception case and the cost of the exceptional c= ase.

Furthermore, there are different types of users of C++. For som= e, having a consistent cost is more important than being faster most= of the time but really slow if something exceptional happens. And consiste= ncy of performance can matter more in specific places than others.

O= verall, I think a pretty decent case has been made that having a functional= alternative to exceptions, whether in the language or the library, would b= e a good thing. The most pernicious case is the difficulty of signaling err= ors from constructors; such a thing fundamentally requires a language-level= solution (or to write constructors that can't fail).

--
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/694163cb-b551-425b-9f08-b229ca487859= %40isocpp.org.
------=_Part_2028_452221702.1499114551383-- ------=_Part_2027_224609003.1499114551383-- .