220 18857 <5590179C.9090706@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Compressing std::optional Date: Sun, 28 Jun 2015 17:49:48 +0200 Lines: 148 Approved: news@gmane.org Message-ID: <5590179C.9090706@wanadoo.fr> References: <4359ebfb-5e20-42c1-84a0-16ef6201db33@isocpp.org> <33303ec4-d4c3-4080-a7bb-346496e38114@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; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1435506602 8784 80.91.229.3 (28 Jun 2015 15:50:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Jun 2015 15:50:02 +0000 (UTC) Cc: vlovich@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBHNPYCWAKGQELPE3QWI@isocpp.org Sun Jun 28 17:49:50 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f69.google.com ([209.85.215.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z9Eq6-0000mE-Iw for gclcip-std-proposals@m.gmane.org; Sun, 28 Jun 2015 17:49:50 +0200 Original-Received: by laar3 with SMTP id r3sf38855364laa.1 for ; Sun, 28 Jun 2015 08:49:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding: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=ZYe8FYQWHq8eaDP38jAW4GBCUPRC/LDK1tiH/IV4dMQ=; b=a7itCnbLtFsRkSl8ntY9/EuDYaibpJwRcnzhXzktDIPml05sGdvbU352xhl+2r7gB9 /j03TuK4XVGMk3clghu7/iDYKLkW3QQH3CCAp4QO2yHg1tBhMYayo98k3H135PxW3v6d X1vqFKtoEH+EgxjqjfrmSaJjpif/xOTC9NagnA895R4PkI477GVAOjOjrRE+OoZMJvq/ 6H/ZLLHUattdWjrkLhx2fop0qKtKhzkaD3m2e3vXDjnyp6cdBtoYiFeM6Dink3TauPXH n3T0Erz4Rn+pIKW37qjS2CGvBV+Oe/8jGDE5+Mur+DLt X-Gm-Message-State: ALoCoQki2VfgS1u1jMnDhlUjKvr8IJci90XSWpxtEPgi1ATSs901Xd6IfGQyicKhdao/pXwBPtlZ X-Received: by 10.194.179.42 with SMTP id dd10mr8062440wjc.7.1435506589977; Sun, 28 Jun 2015 08:49:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.102.41 with SMTP id fl9ls398828wib.24.canary; Sun, 28 Jun 2015 08:49:48 -0700 (PDT) X-Received: by 10.181.13.172 with SMTP id ez12mr14377065wid.91.1435506588751; Sun, 28 Jun 2015 08:49:48 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr. [80.12.242.123]) by mx.google.com with ESMTPS id wi10si9028633wjb.56.2015.06.28.08.49.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 28 Jun 2015 08:49:48 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.123 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.123; Original-Received: from new-host.home ([86.214.88.178]) by mwinf5d02 with ME id lrpo1q0043qsdMS03rpouc; Sun, 28 Jun 2015 17:49:48 +0200 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Sun, 28 Jun 2015 17:49:48 +0200 X-ME-IP: 86.214.88.178 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 In-Reply-To: <33303ec4-d4c3-4080-a7bb-346496e38114@isocpp.org> X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.123 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mail=vicente.botet@wanadoo.fr 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:18857 Archived-At: Le 26/06/15 22:14, Andrzej Krzemie=C5=84ski a =C3=A9crit : > > W dniu =C5=9Broda, 24 czerwca 2015 18:55:50 UTC+2 u=C5=BCytkownik vlo...@= gmail.com > napisa=C5=82: >> 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 thes= e >> scenarios it's not uncommon to have a sentinel value. >> - Cannot be used in as a drop-in in existing code that uses a sentin= el >> (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 doub= le, >> 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::g= et< >> 1>(_data)), false); >> } >> >> optional(const T&) >> { >> std::get<0>(_data).set_initialized(reinterpret_cast(&std::g= et< >> 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 =3D initialized; >> } >> >> bool _initialized =3D 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 =3D std::numeric_limits::quite_NaN(); >> } >> } >> }; >> >> >> The main criticism of this proposal was that it affects the optional's > semantics: > > optional od {2.3}; > double d =3D compute_val(); > > assert (od); // contains value > *od =3D d; > assert (od); // contains value? > > The second assertion always holds in normal optional. In the "optimized" > version, it depends on the value of d. > > =20 > Andrzej is right *od =3D d; is odd and can only be caught if operator* returns a proxy :( This proxy=20 could check for the value and throw an exception. Clearly this is another possibly null type, with different space and=20 time constraints. Vicente --=20 ---=20 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 e= mail 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-proposa= ls/. .