220 18753 article Path: news.gmane.org!not-for-mail From: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Compressing std::optional Date: Wed, 24 Jun 2015 15:58:45 -0700 Lines: 147 Approved: news@gmane.org Message-ID: References: <4359ebfb-5e20-42c1-84a0-16ef6201db33@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 1435186748 31149 80.91.229.3 (24 Jun 2015 22:59:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Jun 2015 22:59:08 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDDM34EO6QDRBOPMVSWAKGQE5SD56FY@isocpp.org Thu Jun 25 00:59:08 2015 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 1Z7tdL-0000TJ-Fi for gclcip-std-proposals@m.gmane.org; Thu, 25 Jun 2015 00:59:07 +0200 Original-Received: by igbqq3 with SMTP id qq3sf101372498igb.2 for ; Wed, 24 Jun 2015 15:59:06 -0700 (PDT) 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: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=RDguaLoMl74XpsY6sox5ya38NJRMuHpIoGrLCk35j7Y=; b=QWYKrm8ryNYsVM/ceFM19jCKDpWi5XvIGZCYRcWki1Fo5R4wFpaG5FufSLso8c3PlE F9+oYazaJZj0Vs7aOTMzZmL8q2aUdWMUStAnIIqBe3gyz89yXtUS9pap9vfhG+zqgaES SQJGWGfbuX9AfWhIGfqX+OnuQO5xq4MHkpf5/olrUvyryOCi+I4hTt7mp6JgQc0PRB+u GHXEpoc63Ys8Hsf0weWXLs4oyM29a0s7+ZKi/hnUUpeTWAYhXeW8tBv15ONXOBQ2kJB4 i8YJ5K758Y8W63tMRNI6iFEKqLgUbYEEXiwMeAJ+HraMRwr+N7Iy6T/l9S0YSZ8fdrKv YktA== X-Gm-Message-State: ALoCoQkmxXx9P4EEWbqabXDPM3YIB2HFXPaO5xJM/FqJpd6Pafsi0Ono6wIMJXLS9XZVSZ3RZE6N X-Received: by 10.182.65.164 with SMTP id y4mr56482633obs.26.1435186746599; Wed, 24 Jun 2015 15:59:06 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.23.82 with SMTP id k18ls725783igf.18.gmail; Wed, 24 Jun 2015 15:59:05 -0700 (PDT) X-Received: by 10.107.11.17 with SMTP id v17mr55419454ioi.83.1435186745821; Wed, 24 Jun 2015 15:59:05 -0700 (PDT) Original-Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com. [2607:f8b0:4001:c05::22b]) by mx.google.com with ESMTPS id i72si12087960iod.27.2015.06.24.15.59.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2015 15:59:05 -0700 (PDT) Received-SPF: pass (google.com: domain of jyasskin@google.com designates 2607:f8b0:4001:c05::22b as permitted sender) client-ip=2607:f8b0:4001:c05::22b; Original-Received: by igbiq7 with SMTP id iq7so107563156igb.1 for ; Wed, 24 Jun 2015 15:59:05 -0700 (PDT) X-Received: by 10.50.87.38 with SMTP id u6mr176382igz.39.1435186745529; Wed, 24 Jun 2015 15:59:05 -0700 (PDT) Original-Received: by 10.64.73.2 with HTTP; Wed, 24 Jun 2015 15:58:45 -0700 (PDT) In-Reply-To: <4359ebfb-5e20-42c1-84a0-16ef6201db33@isocpp.org> X-Original-Sender: jyasskin@google.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of jyasskin@google.com designates 2607:f8b0:4001:c05::22b as permitted sender) smtp.mail=jyasskin@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: Jeffrey Yasskin Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:18753 Archived-At: I'd be happy to see a paper fleshing this out. I don't think anyone was opposed to the idea, but it would have slowed down the initial optional<> proposal if it had been included. Now is a great time to try to add the feature. On Wed, Jun 24, 2015 at 9:55 AM, wrote: > Hi, > > I'd like to bring up this topic again. I know Andrzej brought it up a > couple of years ago for tr2 but I think I have a different take. > First, I'd like to motivate the discussion with the limitations of the > current approach. > > For small types optional can double the size of storage > Overhead can add up when stored in arrays (& most of it due to padding if > the sizeof(T) > 1). > Cannot be used as a drop-in in a memory-mapped structure. In these > scenarios it's not uncommon to have a sentinel value. > Cannot be used in as a drop-in in existing code that uses a sentinel (i.e > type-safety) > Lots of overhead when a struct contains lots of optionals. For example, > protobuf uses bit-packing for this. > > The main limitation, at least as I see it, of the Andrzej's traits > implementation is that it cannot be customized per-instance of optional. > This is probably fine for user-defined types but makes this optimization not > possible for built-in types. It's not uncommon to have only certain > instances of built-in types have invalid bit-patterns (e.g. NaN for double, > maximum value for size_t as reported by std::string). > > > To that end, my proposal to accomplish something like this would require > adding a secondary template parameter that defines the storage of the > initialization state. Here is a straw-man skeleton example of what the > std::optional class interface might look like. constexpr omitted for > simplicity but I don't see anything preventing it & optional_storage is the > hypothetical : > > > template > class optional { > public: > optional(std::nullopt_t) > { > > std::get<0>(_data).set_initialized(reinterpret_cast(&std::get<1>(_data)), > false); > } > > optional(const T&) > { > > std::get<0>(_data).set_initialized(reinterpret_cast(&std::get<1>(_data)), > true); > } > ... > bool is_initialized() const > { > return std::get<0>(_data).is_initialized(); > } > ... > private: > std::tuple> _data; > }; > > default_optional_initialization_storage would comply with the interface for > optional_initialization_storage & look something like: > > > struct default_optional_initialization_storage { > template > bool is_initialized(T*) const > { > return _initialized; > } > > template > void set_initialized(T*, bool initialized) > { > _initialized = initialized; > } > > bool _initialized = false; > }; > > > An example for hiding the state as via NaN for double: > > struct nan_optional_storage { > bool is_initialized(double* value) const > { > return !std::isnan(*value) > } > > void set_initialized(double* value, bool initialized) > { > if (!initialized) { > *value = std::numeric_limits::quite_NaN(); > } > } > }; > > > Some of my thoughts on this sample code: > > It is by no means an exaustive implementation and I'm sure there's lots of > nitpicking to be done over details/naming/etc. I just want to get a sense > of does something like this even make sense. > This is purely a mechanism through which optional can be optimized with > domain-specific knowledge. There is no optimization suggested for built-in > types (e.g. not even pointer types would optimize the nullptr case by > default). > The sentinel-value use-case would probably be important enough that a simple > API for expressing such a sentinel value would be valuable (something like > optional>) > This is purely a customization point to apply domain-specific knowledge to > optimize optional. There is no optimization available by default. > The careful reader will note that the bit-packing case has not been > addressed. I am not quite certain how to actually achieve this since the > storage lives external to the optional<> itself. Passing through some kind > of ctx in all optional APIs? > It has been suggested by some that this no longer represents the CS concept > of an optional monad and should be a distinct type. I'm not sure I really > see why (purity of mapping C++ to theoretical CS aside). > > Thanks for reading, > Vitali > > -- > > --- > 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 > http://groups.google.com/a/isocpp.org/group/std-proposals/. -- --- 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 http://groups.google.com/a/isocpp.org/group/std-proposals/. .