220 24429 article Path: news.gmane.org!not-for-mail From: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Idea of virtual, uncopyable and immovable classes Date: Tue, 16 Feb 2016 17:25:09 -0800 Lines: 149 Approved: news@gmane.org Message-ID: References: <20160214064457.GA25122@noemi> <32fb7b22-aaab-4abe-b71c-d8d6e4ba74e2@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113d5b82ecd3e8052bed1e4e X-Trace: ger.gmane.org 1455672314 13633 80.91.229.3 (17 Feb 2016 01:25:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Feb 2016 01:25:14 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCGNLO5F34OBB5UXR63AKGQEGU7JBGY@isocpp.org Wed Feb 17 02:25:13 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f199.google.com ([209.85.213.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aVqrh-00067F-EA for gclcip-std-proposals@m.gmane.org; Wed, 17 Feb 2016 02:25:13 +0100 Original-Received: by mail-ig0-f199.google.com with SMTP id hb3sf880092igb.2 for ; Tue, 16 Feb 2016 17:25:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type: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=X8Dq3i9nvyXpC+bvNHVpdCUTCc9qel0p+B9IeA72vW8=; b=VhwKdo0IRb3Rr42ZJT/Ce98ij3R56z3BZmaIzUxgnZV7cJLy9CgXfuQvf8MHt/T1ry AxD17l1AknOAYHIoMtkALjt1GLmNVcH2EHEnSKHgBuKh5TFEXnIOhyzJUKJk6ckWKI0L 5yLTRQvt0H3En1rwyiWBvTOcU5cRgfjcBe2BT94a6zrRpBcTIZYAPxP4lmhfnpJleoIO CIv1TBWmwW8mc4JH89nPJZucFuRMVpiD0/fBSCVIhgDy5YIqIgyYte3YOQvL2RbIfkGA 8WnBQtvasR4YQJEQwtcFly0dfcNGxvsDKk8TiicgA7fNpmzC/iPXECejwIZ2X86v0yqN OWNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type: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=X8Dq3i9nvyXpC+bvNHVpdCUTCc9qel0p+B9IeA72vW8=; b=UWwKOXYvUIBSbtTVQonrffrgObhyOqT1gtOsza4Zj9/e8eGRPq1sB9D/BwK6F1eWas K4t68iWpyZ7CkIQJaqVub/q8hlg8eJr/GMmyP4fRF6s/X2Jltda3WFrM7zuw8ScZVhAE b7dSUJILydllzqjrKZDe3KT+pC7qZC8ajYJ8bOuPa8YexmqsZB+idGIQ5wxcNuxjinZz ljas+bErFX9X7kgxttYeI/gWIh82S6Jf08bxYpAHuY+170UAoU2F09G3qPvM5O6L1ba8 Wm7s5oHu19KOBm8Iih5Do3bt7pbo1EUYYh1xoJlu6c7/ecmweyrtiPIGCoTnCFBK0h73 Gdtw== X-Gm-Message-State: AG10YOSI7zr9ft4AWUjDq88PjURYn8Mz0/gWzSKc3uGBPt0culF+5Lqwu9dhm1ve0JgaEw== X-Received: by 10.182.29.10 with SMTP id f10mr25580990obh.36.1455672312224; Tue, 16 Feb 2016 17:25:12 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.14.15 with SMTP id 15ls2017709ioo.92.gmail; Tue, 16 Feb 2016 17:25:09 -0800 (PST) X-Received: by 10.107.8.40 with SMTP id 40mr711141ioi.122.1455672309841; Tue, 16 Feb 2016 17:25:09 -0800 (PST) Original-Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com. [2607:f8b0:4001:c06::22c]) by mx.google.com with ESMTPS id r6si38780742ige.11.2016.02.16.17.25.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Feb 2016 17:25:09 -0800 (PST) Received-SPF: pass (google.com: domain of calabrese@google.com designates 2607:f8b0:4001:c06::22c as permitted sender) client-ip=2607:f8b0:4001:c06::22c; Original-Received: by mail-io0-x22c.google.com with SMTP id g203so13377373iof.2 for ; Tue, 16 Feb 2016 17:25:09 -0800 (PST) X-Received: by 10.202.224.10 with SMTP id x10mr19510490oig.30.1455672309602; Tue, 16 Feb 2016 17:25:09 -0800 (PST) Original-Received: by 10.60.95.201 with HTTP; Tue, 16 Feb 2016 17:25:09 -0800 (PST) In-Reply-To: <32fb7b22-aaab-4abe-b71c-d8d6e4ba74e2@isocpp.org> X-Original-Sender: calabrese@google.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of calabrese@google.com designates 2607:f8b0:4001:c06::22c as permitted sender) smtp.mailfrom=calabrese@google.com; dkim=pass header.i=@google.com; dmarc=pass (p=REJECT dis=NONE) header.from=google.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: , X-Original-From: Matt Calabrese Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:24429 Archived-At: --001a113d5b82ecd3e8052bed1e4e Content-Type: text/plain; charset=UTF-8 On Tue, Feb 16, 2016 at 2:34 PM, Nicol Bolas wrote: > > How does the lack of use of the CRTP bloat the size of the type? EBO > either happens or it doesn't; I don't believe the fact that the empty base > is a template helps or hinders this process. > Imagine four types: noncopyable left right child Say both "left" and "right" inherit from "noncopyable" (basically a boost::noncopyable). Then, "child" inherits from "left" and "right". The two "noncopyable" bases are not allowed to occupy the same storage location in "child", so you can get size bloating that wouldn't have happened had the user just deleted the copy operations. If each of those "noncopyable" bases were different types, then EBO can occur. You can get this easily by using CRTP. Technically, it doesn't have to be strictly CRTP as you can instantiate the "noncopyable" template with any unique type, but just doing CRTP with the immediate child is convenient because a given type cannot (directly) inherit from the same type multiple times, and you don't have to forward declare and maintain uniqueness of tag types. A quick example of the size bloating that can occur (noncopyable here doesn't make the type noncopyable in the example because it's not necessary to show the size bloating): ////////// #include struct noncopyable {}; struct left : noncopyable {}; struct right : noncopyable {}; struct child : left, right {}; int main() { // Compiler I tested outputs 2 here std::cout << sizeof(child) << std::endl; } ////////// Now, if you use CRTP... ////////// #include template struct noncopyable {}; struct left : noncopyable {}; struct right : noncopyable {}; struct child : left, right {}; int main() { // Compiler I tested outputs 1 here std::cout << sizeof(child) << std::endl; } ////////// Perhaps these concerns are for rare cases, but it's a little bit sad that the convenience base would potentially have a size impact when all you want it to do is make something noncopyable. -- --- 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 https://groups.google.com/a/isocpp.org/group/std-proposals/. --001a113d5b82ecd3e8052bed1e4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 16, 2016 at 2:34 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
How does the lack of use = of the CRTP bloat the size of the type? EBO either happens or it doesn'= t; I don't believe the fact that the empty base is a template helps or = hinders this process.

Imagine f= our types:

noncopyable
left
ri= ght
child

Say both "left" and = "right" inherit from "noncopyable" (basically a boost::= noncopyable). Then, "child" inherits from "left" and &q= uot;right". The two "noncopyable" bases are not allowed to o= ccupy the same storage location in "child", so you can get size b= loating that wouldn't have happened had the user just deleted the copy = operations. If each of those "noncopyable" bases were different t= ypes, then EBO can occur. You can get this easily by using CRTP. Technicall= y, it doesn't have to be strictly CRTP as you can instantiate the "= ;noncopyable" template with any unique type, but just doing CRTP with = the immediate child is convenient because a given type cannot (directly) in= herit from the same type multiple times, and you don't have to forward = declare and maintain uniqueness of tag types.

A qu= ick example of the size bloating that can occur (noncopyable here doesn'= ;t make the type noncopyable in the example because it's not necessary = to show the size bloating):

//////////
<= div>#include <iostream>

struct noncopyable {= };

struct left : noncopyable {};
struct = right : noncopyable {};

struct child : left, right= {};

int main() {
=C2=A0 // Compiler I t= ested outputs 2 here
=C2=A0 std::cout << sizeof(child) <= < std::endl;
}
//////////

Now, if you use CRTP...

////////= //
#include <iostream>

templa= te <class>
struct noncopyable {};

= struct left : noncopyable<left> {};
struct right : noncopya= ble<right> {};

struct child : left, right {}= ;

int main() {
=C2=A0 // Compiler I test= ed outputs 1 here
=C2=A0 std::cout << sizeof(child) <<= ; std::endl;
}
//////////

Perhaps these concerns are for= rare cases, but it's a little bit sad that the convenience base would = potentially have a size impact when all you want it to do is make something= noncopyable.


--

---
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals= /.
--001a113d5b82ecd3e8052bed1e4e-- .