220 26648 article Path: news.gmane.org!not-for-mail From: Peter Koch Larsen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allow zero size arrays and let them occupy zero bytes. Date: Fri, 8 Jul 2016 17:58:29 +0200 Lines: 170 Approved: news@gmane.org Message-ID: References: <51e6aec9-a745-4fd9-94f7-bdd78b5798ca@isocpp.org> <8a31c6b9-eba5-4e0a-9b9c-431f3a79c727@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1467993514 10805 80.91.229.3 (8 Jul 2016 15:58:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Jul 2016 15:58:34 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDRIBXXKZQERBJ43765QKGQEFEI753I@isocpp.org Fri Jul 08 17:58:34 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f200.google.com ([209.85.220.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bLYAj-0008Lu-3Q for gclcip-std-proposals@m.gmane.org; Fri, 08 Jul 2016 17:58:33 +0200 Original-Received: by mail-qk0-f200.google.com with SMTP id a123sf22685651qkd.2 for ; Fri, 08 Jul 2016 08:58:32 -0700 (PDT) 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: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=WxhP9xuTOrwNVTu/TPlRj8rKTqEMDwG32h+MBLSl+/Q=; b=dmkcFGxeE3yYVizBqBRe05SKFvNsVBbEhSkWINxdCTB/wGkbodcXWV6AyeKHeD8FHP 0e9UalGzpI465vZOJmfOlQpe58cWPXhXIO63IJAkTGILDwDObKSHiyxLbruNNklvJ4fS LA6nPUbFpT00BXuMdBfdPliI7cuv0MmDrnqYNOiTfpSJYm72Gz2WyMe2oPAuqbzUtF/P o2Pl7ZiX19xM7EiXHJNslL6dL4fM1p9/0aUIdUN54+I8UNPI+5FLQlAYfk2CS6tJtqF9 CjYJ+bL3Cb1zEzJ5jA6FbRVz59eVLw6A5Zz6AWzH5Z9tfX1a6+Tfgd3L8Q36v4CAIZja zfYA== 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: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=WxhP9xuTOrwNVTu/TPlRj8rKTqEMDwG32h+MBLSl+/Q=; b=BXg4ucgIZ1Dj0GxWgyTvC+E9aujvRa3xltsBrtSU3mcerRTUjuXtHzDkah/s3/M1eS TJ40ShSDdmHU23VF1csc9hFVvQuqFjUmLiF9QCSlRq1sF32hMCC4KHhpovwu84Rvi4Su kK9RQiTpX9bLACeNOYKw7KBaJGeMDY+nLSiBn2HM1L6gyfvTRzw6gZN2qRALvA8w43Ud vhroWWcylP471HSfgrVKYyyHBFiTYraG1sJFiJ8+I3p++DzZqUf/tN/A4Oqvwamu61Fw 9bJLGTOmEOIEat8qmqDV8RC58H7AkbCkAKgGU4/ouhqVWPO3WmHPfG+HTkTdfW56FtCo 1yLA== X-Gm-Message-State: ALyK8tKRrHVCc5HBjVXNXpG35LNOo0B7Q4cJ8letUBwjtSxngQG9U24M4IGUJg43fI253w== X-Received: by 10.200.37.170 with SMTP id e39mr5520366qte.20.1467993512140; Fri, 08 Jul 2016 08:58:32 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.153.8 with SMTP id b8ls991658ioe.20.gmail; Fri, 08 Jul 2016 08:58:31 -0700 (PDT) X-Received: by 10.159.34.55 with SMTP id 52mr2904558uad.2.1467993511168; Fri, 08 Jul 2016 08:58:31 -0700 (PDT) Original-Received: from mail-vk0-x241.google.com (mail-vk0-x241.google.com. [2607:f8b0:400c:c05::241]) by mx.google.com with ESMTPS id k72si792271vke.209.2016.07.08.08.58.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jul 2016 08:58:31 -0700 (PDT) Received-SPF: pass (google.com: domain of peter.koch.larsen@gmail.com designates 2607:f8b0:400c:c05::241 as permitted sender) client-ip=2607:f8b0:400c:c05::241; Original-Received: by mail-vk0-x241.google.com with SMTP id d67so11154370vkh.0 for ; Fri, 08 Jul 2016 08:58:31 -0700 (PDT) X-Received: by 10.176.0.39 with SMTP id 36mr2424275uai.137.1467993510731; Fri, 08 Jul 2016 08:58:30 -0700 (PDT) Original-Received: by 10.103.43.6 with HTTP; Fri, 8 Jul 2016 08:58:29 -0700 (PDT) In-Reply-To: X-Original-Sender: peter.koch.larsen@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of peter.koch.larsen@gmail.com designates 2607:f8b0:400c:c05::241 as permitted sender) smtp.mailfrom=peter.koch.larsen@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:26648 Archived-At: Sean Parent in his key-note talk at cppnow proposed making void a regular, empty type. At the same time he proposed that when inheriting from void, you would have a truly empty type. I like that idea. struct empty{}; // Not really empty. struct truly_empty: void {}; //This one is! static assert(sizeof(empty) == 1); static assert(sizeof(truly_empty) == 0); /Peter On Fri, Jul 8, 2016 at 3:22 PM, Nicol Bolas wrote: > On Friday, July 8, 2016 at 12:50:00 AM UTC-4, Matt Calabrese wrote: >> >> On Thu, Jul 7, 2016 at 7:21 PM, Nicol Bolas wrote: >>> >>> On Thursday, July 7, 2016 at 8:09:37 PM UTC-4, Matt Calabrese wrote: >>>> >>>> On Mon, Jul 4, 2016 at 8:15 AM, Bengt Gustafsson >>>> wrote: >>>>> >>>>> I have been following the recent thread about empty base optimization, >>>>> or rather, the lack of empty member optimization possibility. And today I >>>>> again fell in the 0 sized array trap in metaprogramming, noticing that it >>>>> creates quite a few problems requiring extra coding. >>>> >>>> >>>> When I started working on Regular Void (p0146) I initially explored size >>>> 0 types but decided to postpone the effort because it has some difficult >>>> practical concerns regarding backwards compatibility. I think it might be >>>> possible that we will eventually get to a point where the language allows >>>> size 0 types, but it is not something that we can just start introducing >>>> (arrays or otherwise) without broader considerations. If the language had >>>> size 0 types to begin with then there would be no potential issues, but I >>>> half-suspect that the transition to a world where size 0 types exist may be >>>> more difficult than people would care to accept. >>>> >>>> Here's a brief summary of my current conclusions. I'd like to eventually >>>> explore this again once Regular Void either goes into the language or is >>>> killed. >>>> >>>> 1) In order for size 0 types to be useful as a means of minimizing >>>> storage, we'd effectively have to change aliasing rules. No two objects of >>>> the same type can occupy the same address in C++ as it currently is, which >>>> user-level code can and does exploit. >>> >>> >>> Actually that's not quite true, and it is this exception that focused my >>> stateless subobject idea (that I'm still occasionally refining). There are >>> certain cases where two objects can have the same address. Namely, base >>> class subobjects and their derived class. This is why [basic.lval]/10 has an >>> explicit exception in the aliasing rules for types which are "similar to" >>> the actual object's type. >> >> >> That's why I say two /different/ objects of the /same/ type. EBO doesn't >> cover that. > > > And my point is how you define "different". We could say that stateless > subobjects are not different objects from any other object. Which makes > sense, as they are stateless and therefore have no value representation. > >> On Thu, Jul 7, 2016 at 7:21 PM, Nicol Bolas wrote: >>> >>> I would say that the requirement should be stronger than that. Your idea >>> is to make it a hint, that implementations may allow the size to be 0. I say >>> that it should be enforced. If you declare that a type is zero-sized, then >>> put things in it that aren't themselves zero-sized, then I would say that >>> your code is incoherent and does not deserve to compile. It seems likely to >>> me that a user who declares that a type will be zero-sized, then does >>> something that makes this impossible has made a mistake. >> >> >> It must be a hint to be useful in practice and it is not indicative of a >> mistake for the use-cases where it is desired. Basically, the end goal is >> that we want implementations to always prefer to make types such as "struct >> foo {};" or "struct foo { /*all size 0 datamembers*/ };" as size 0. The >> problem is that this wouldn't immediately happen in practice because it >> would be an ABI break. In order for users to actually be able to take >> advantage of this immediately during the transition, they'd need an >> additional way to declare types that didn't exist before (hence the >> specifier) -- this specifier doesn't have to even be a part of the standard, >> technically, but it would be an extension that I'd expect implementations to >> ultimately provide and that users would have to take advantage of in order >> to actually get size 0 types in practice. >> >> The reason I say that the specifier must only be a hint and not cause an >> error if a user were to put a non-static datamember in the type that isn't >> size 0 is because if it caused an error then it wouldn't help for one of the >> primary use-cases, which is where datamembers have dependent types that may >> or may not be size 0 (i.e. a tuple template). You want to be able to declare >> something like a tuple template in such a way that its instantiations are >> size 0 when all datamembers are size 0, yet still have the same exact >> template definition when some of the dependent T types may not be size 0. >> Applying the specifier on the template definition there would do the trick >> if it really were just a hint, but if the "hint" were actually something >> that caused an error if the type couldn't actually be size 0, then the >> specifier wouldn't be usable there. > > > That's why I said: > >> But at the same time, I do think it is important that users can make a >> distinction between "This type will be zero-sided" and "If my declarations >> make this empty, then it should be zero-sized". > > > For that tuple case, you need the latter. But for other cases, people need > the former. > >> >> >> On Thu, Jul 7, 2016 at 7:21 PM, Nicol Bolas wrote: >>> >>> As I've refined my own stateless types idea, I came to realize something. >>> While it is useful to be able to declare that a type will be stateless, it >>> is also useful to declare that a type which was not explicitly declared >>> stateless can be used as a stateless subobject. That way, you don't create a >>> rigid separation between the world of stateless things and the world of >>> non-stateless things. >>> >>> If someone passes you an allocator that is an empty type, but they didn't >>> declare it stateless, that's OK: you can fix that at the point of use. >> >> >> I'm not sure I follow what you mean. I don't think we are drawing a >> distinction between stateful and stateless things here. The idea is that an >> instance of a current C++ type and a size 0 type can be worked with via a >> common set of abstractions. If whatever we end up does not have such a set >> of abstractions, then we've failed. > > > My point is that whatever "common set of abstractions" you work out, this > class definition must not be zero-sized: > > struct empty{}; > > The reason being that it isn't zero-sized today, and making it zero-sized > would represent a breaking, non-backwards-compatible change not only to > itself but to every subobject it is used in. That's not acceptable for > obvious reasons. > > `std::allocator` is an empty class (probably). As such, if I want to make a > member variable of that type which takes up no space, how do I do that? If > you rely only on the type's definition to explicitly say that it is > zero-sized, you can't. Thus, you divide the world into two divisions: code > written after the standard changed, and code written before it changed. > > Yet logically, any empty class ought to be able to be used in a > zero-sized/stateless/whatever-you-call-it way, when declared as a > subobjbect. Thus, any solution to this problem ought needs to also be able > to be employed on a per-use basis. > > -- > 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/f3b99829-432a-47a4-b227-48e70cb18da5%40isocpp.org. -- 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/CANPtknwMe0KS%3DOqrkbUWwRwWQX2Vu90XeXc8XU3oLFPFiunQ%3DQ%40mail.gmail.com. .