220 34256 article Path: news.gmane.org!.POSTED!not-for-mail From: Nevin Liber Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal to add constructors to std::bad_alloc exception class. Date: Fri, 01 Sep 2017 20:42:08 +0000 Lines: 140 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403045c31481070d3055826cc54" X-Trace: blaine.gmane.org 1504298556 19755 195.159.176.226 (1 Sep 2017 20:42:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Sep 2017 20:42:36 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBCE35H5S6IDBBK4MU7GQKGQEPGEHM3Y@isocpp.org Fri Sep 01 22:42:20 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f69.google.com ([74.125.83.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dnsla-000429-M3 for gclcip-std-proposals@m.gmane.org; Fri, 01 Sep 2017 22:42:15 +0200 Original-Received: by mail-pg0-f69.google.com with SMTP id 83sf2772183pgb.12 for ; Fri, 01 Sep 2017 13:42:21 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1504298541; cv=pass; d=google.com; s=arc-20160816; b=TwdgbqGFLayDsCfvYF+PkK7z0k3Ch1Zns4wDvN2gQkCnVALd7zCx5yiKrO4deVXOop fP5BVnSx9q3YXUMr157WOR3ff2ZxeAbJEyjSXJWYuiSaopnukV7uCoInKaNACNwo9CMh 0BkVHKksDJEZkSi2XEHpUHWSH1hAE82vLRTTni5gKvdHqSf9g9J5B+NuFY/NJ+QhZnB0 NXZuF/eL/TWYYdPprhM69jph+/KVgKbZzUXpWOHvGaMMWCXK8nxGrHYk11G6UtYDWSwE tY/3fTebVZgwHodT2nv6RdA8TQpQkCEAnWBRSPgBLMsKtATncTXl7knwiJk1qWwLNgsB /ixQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=3raN46NdiXlDY9kcij9yLk3hwSdZA8pZYK4m2jyXrHw=; b=WddsWxcfyXGLHQA2RlVT/lVgmY/jKWznK31u5zgsZmU/tXWjA6LkyY6hjONzgA1NXF tdzI1bpvw/kBa+lLh1j3CIcj75boHLNtFx/fb7qM6WMC0dwa10Mp40gDRalIbHXfQ4Ka fhxdm4vwyqWq6gyF3QG6j9sA1s+j+uUDKexexUIc7Sfc17djmB2Tf+MZ8KVNmSgYjBFu BgeHbVk1NLqmQ9JXQTP4wjHHdlwScKtlaqHLrBunpgb/gOTvsOVUpi2JlVRIloyiD3mL 8yJVfhah8tCQyl21jlT7Peht/qtUSFcGmdF0r89YDzh3vm9+AmbAG3hk7lAMF044vzJ4 gpIw== ARC-Authentication-Results: i=2; mx.google.com; spf=pass (google.com: domain of nliber@gmail.com designates 209.85.192.172 as permitted sender) smtp.mailfrom=nliber@gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=3raN46NdiXlDY9kcij9yLk3hwSdZA8pZYK4m2jyXrHw=; b=rIGe/BHwYutrGzzwvFm4pLk1DsGzkkz92DjK7V3fnbB36Ljap2AkdSuPk+VWqPq4CU tdL7bpsKLFt4mY6RrvI6XN0KDjaXjalpXL+MaW8uBCZuol3zlRZrx7O4OvnE2ghHilI2 AqXiTRfUhB7GUyUraWvEh0x0NwUyDif4NS7Yf97hLO94hgCTIEaexGSQqPsqg0owyJv7 oiWEdDPqULInTS2C6ICpi8tFfAJRGajKl73Yup98gCXfKS+Xb50rTuSy7mcvZufgeGaZ d42TsR/hyx2Q8ngK3UkVjfOFyo8GDA0HIJrsHgA3hv2/EEYGjhYvUrkC53rrjAFj6eZl NTXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=3raN46NdiXlDY9kcij9yLk3hwSdZA8pZYK4m2jyXrHw=; b=TARb2ihStBdHY7fzP/6SkGq514fkJS+dMUtHrl9CQ9zj4kBxSTx2F1NTpuU1ofBABS 2dKQE8bkp0yhliZIuhzr5qQMQa/IJSOIaw6gBV97/L/T3h3ZKBslQcsp1bgJ0XBmvuBl l90vrBehZl8j673/V18PH0O6sH2qC7oLjk1mnvErJ/iTuYFNiQgSL55SfjUL4ZCLyH84 +gc8Wg+K5MdFC/kKnidahB1QUa9r18LPnwHZW5GPbNh1v49TPRf6GvwlXwLaSBlr5cUH SBHH1tJAl3Bu6TMVK2nIt3Ilx0LH9S2r9lcl6S7zFpEQPH0Ziv+6l3H5Pn6XTiCwdTaX WJcA== X-Gm-Message-State: AHYfb5gNikKokJgCUYBIIiEK37iDm7zkGAYWSqd//HYa+bpQMrYQWB49 V534Vja9wCZjvA== X-Google-Smtp-Source: ADKCNb7g5/0h7HHL2sfXxzQRjgETfIB7ZXGFjGZGY3ncsYm0JVr+1EHx+QBGI7b/7IAoAQUt/gp+tA== X-Received: by 10.99.123.16 with SMTP id w16mr4739669pgc.95.1504298541134; Fri, 01 Sep 2017 13:42:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.29.11 with SMTP id 11ls1668598itj.13.canary-gmail; Fri, 01 Sep 2017 13:42:19 -0700 (PDT) X-Received: by 10.99.3.137 with SMTP id 131mr1278594pgd.441.1504298539736; Fri, 01 Sep 2017 13:42:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1504298539; cv=none; d=google.com; s=arc-20160816; b=zjn8fRAGeINe++8lobenMLMKSIOysOTOzQRgcV13wZHUX6FuupW3LxFj856m6phNrd iY3gPQOsLX1ShyZGk4f7VVPtnE7T/ZryU+fWMFOYwYm+y6XuPUsvNpD9VAwvZ3HYpCdc UUcjyTenv4rnZvvKc42TDTcKrh9ihuHRRR6qLOdJx98lrndAA/USOH9gHkPF5/y9rNRr gF+PeMK94oG/w0CGpk/7sPGKCnhlpfvEtXPHzD9Rr9GErRhxUV73UoyzC73hwm60R8/c 1TwoCarQG/9Saib0IyouYqcI2TmgmFEXWC5E3kkrqLKAl2ZjmQzyVlQUn0ur9p4rnZ/L ztbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :arc-authentication-results; bh=/ry5vBvaWY2z+mnoTMHYdKwhJAeIC/2c8EvoBYcPX+Q=; b=KGbjVKLxhqyq3xaHZHs9REJOqs8rjku8PiZgot5x/IvdFJT2VoAQkVOkcGgPwVMeqN yUsU7hUFgZEw+WAQRkX9sRuz3QkXL6Za7ABdZD3zNkupObIOQSLI/7uEHXiJpYRnBVXS thQLlT2zreyhDS5aILbxLkT6DzXBzbwRXKpGgwi9rMa7Ym0oYXpZbsihur5a0SpwAY03 kGCRsOkDdR1zKWnrXo5LBnnJFpyCPjAHfUpW84PoFN9RKPjHM5RuyOhF6tDcWLBAVOsb iIEG9WlIOHW1becVmtT+Y4IjqTM6KChMFX9GCyYf50etmjp9E6x3+ghlAk1Bb0gBWRWK cAIg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of nliber@gmail.com designates 209.85.192.172 as permitted sender) smtp.mailfrom=nliber@gmail.com Original-Received: from mail-pf0-f172.google.com (mail-pf0-f172.google.com. [209.85.192.172]) by mx.google.com with ESMTPS id d79si729143pfj.466.2017.09.01.13.42.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Sep 2017 13:42:19 -0700 (PDT) Received-SPF: pass (google.com: domain of nliber@gmail.com designates 209.85.192.172 as permitted sender) client-ip=209.85.192.172; Original-Received: by mail-pf0-f172.google.com with SMTP id n73so3516525pfj.0 for ; Fri, 01 Sep 2017 13:42:19 -0700 (PDT) X-Received: by 10.98.211.139 with SMTP id z11mr3754399pfk.304.1504298539182; Fri, 01 Sep 2017 13:42:19 -0700 (PDT) In-Reply-To: X-Original-Sender: nevin@eviloverlord.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of nliber@gmail.com designates 209.85.192.172 as permitted sender) smtp.mailfrom=nliber@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:34256 Archived-At: --f403045c31481070d3055826cc54 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 1, 2017 at 2:35 PM, Ville Voutilainen < ville.voutilainen@gmail.com> wrote: > I have a technical question. The proposed signatures look like > bad_alloc needs to store a copy of > the data passed as an argument for the constructor. How likely is > storing that copy to fail right > after an allocation failure? > You beat me to asking this question. :-) > I have a follow-up question: did you consider the alternative where > the caller of the new constructor must pass an rvalue reference > to a std::string, in which case there would be most likely a much > smaller allocation, as in the case of a dynamically > allocated string that doesn't fit into SSO, there would be none, and > in the SSO case, a very small allocation that > is not dynamic? > I don't think an rvalue reference to a std::string helps. As was recently pointed out to me [exception]p2: Each standard library class T that derives from class exception shall have a publicly accessible copy constructor and a publicly accessible copy assignment operator that do not exit with an exception. std::string doesn't meet that requirement (and cannot, since we effectively no long allow a reference counted std::string implementation as of C++11), so bad_alloc cannot hold one. I suppose it could hold a shared_ptr, but then we have to allocate the shared_ptr... Another question I have is this: what sort of ABI impact will this > change have for existing standard library implementations? > +1 as well. -- Nevin ":-)" Liber +1-847-691-1404 -- Nevin ":-)" Liber +1-847-691-1404 -- 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/CAGg_6%2BP1nWqSwTQWAWt8jJ6YEM7zKjDp1xzK56OT%2BiAc5ayzhQ%40mail.gmail.com. --f403045c31481070d3055826cc54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Sep 1, 2017 at 2:35 PM, Ville Voutilainen <ville.voutilain= en@gmail.com> wrote:
I have a technical question. T= he proposed signatures look like
bad_alloc needs to store a copy of
the data passed as an argument for the constructor. How likely is
storing that copy to fail right
after an allocation failure?

You beat me to asking this question. :-)
=C2=A0
I have a follow-up question: did you consider the alte= rnative where
the caller of the new constructor must pass an rvalue reference
to a std::string, in which case there would be most likely a much
smaller allocation, as in the case of a dynamically
allocated string that doesn't fit into SSO, there would be none, and in the SSO case, a very small allocation that
is not dynamic?

I don'= t think an rvalue reference to a std::string helps.=C2=A0 As was recently p= ointed out to me [exception]p2:=C2=A0Each standard library clas= s=C2=A0T=C2=A0that derives from class=C2=A0exception=C2=A0shall have a publicly acces= sible copy constructor and a publicly accessible copy assignment operator t= hat do not exit with an exception.

std::string doesn'= ;t meet that requirement (and cannot, since we effectively no long allow a = reference counted std::string implementation as of C++11), so bad_alloc can= not hold one.

I suppose it could hold a shared_ptr= <string>, but then we have to allocate the shared_ptr...
<= /div>

Another question I have is this: what= sort of ABI impact will this
change have for existing standard library implementations?
=

+1 as well.
<= div>
--
=C2=A0Nevin ":-)" Liber= =C2=A0 <mailto:nevin@eviloverlord.com> =C2=A0+1-847-691-1404
--
=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:nevin@eviloverlord.com> = =C2=A0+1-847-691-1404

--
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/CAGg_6%2BP1nW= qSwTQWAWt8jJ6YEM7zKjDp1xzK56OT%2BiAc5ayzhQ%40mail.gmail.com.
--f403045c31481070d3055826cc54-- .