220 18822 article Path: news.gmane.org!not-for-mail From: Christopher Jefferson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Compressing std::optional Date: Fri, 26 Jun 2015 23:41:38 +0100 Lines: 188 Approved: news@gmane.org Message-ID: 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: multipart/alternative; boundary=001a113496d0737a2b0519737111 X-Trace: ger.gmane.org 1435358509 28933 80.91.229.3 (26 Jun 2015 22:41:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Jun 2015 22:41:49 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCF5NPH6QMFRBJFKW6WAKGQEQJSODCI@isocpp.org Sat Jun 27 00:41:45 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f71.google.com ([209.85.215.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z8cJZ-00011n-Sx for gclcip-std-proposals@m.gmane.org; Sat, 27 Jun 2015 00:41:41 +0200 Original-Received: by laar3 with SMTP id r3sf30163443laa.1 for ; Fri, 26 Jun 2015 15:41:41 -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: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=5Wx3K8yhSt8ZNG/MvFg6SpGD1cc1HqJppebWezO46C4=; b=Ag8PR8PI+yLYoOPY9M5BMbOGb9sA1QmpI1KSWzLi8g75xqqRU+xWRHT85j23XfiZd8 ZrsgEdwsLxQNORDa4WK10+D9WLm9EGOthCpkd+z5v2PF2ro55BdxbN/4MWF1Rft2K4zN 7S1y2N6RnRoWFVlc41kyDbeQBo8g9zZYDtcLGXZB3DGsFJPPlPoMvwu9exfERKEdP3zu NgFumaJuSQJeKFmubFi9om+BtnTHnOIFmq6J/cRwHeJ4GolB/J9qadbWUG9Ux78FURcy HOPndQy4MnX486pm8ePcacwLETcXQPudg+pcU14PRepEnBfHY+8iW3DyIs17xiKU1iVD SFxw== X-Gm-Message-State: ALoCoQlAOmOuwH5zfHdot1qw9uPSPVB134Go2w96BvqcrQ/kqDbApbAZn7BPZCLyIPMG1sS3QE+l X-Received: by 10.180.37.198 with SMTP id a6mr299878wik.7.1435358501391; Fri, 26 Jun 2015 15:41:41 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.7.146 with SMTP id j18ls585582laa.22.gmail; Fri, 26 Jun 2015 15:41:39 -0700 (PDT) X-Received: by 10.112.61.132 with SMTP id p4mr3632480lbr.48.1435358499493; Fri, 26 Jun 2015 15:41:39 -0700 (PDT) Original-Received: from mail-la0-f43.google.com (mail-la0-f43.google.com. [209.85.215.43]) by mx.google.com with ESMTPS id sc4si28553843lbb.99.2015.06.26.15.41.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2015 15:41:39 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.215.43 is neither permitted nor denied by best guess record for domain of chris@bubblescope.net) client-ip=209.85.215.43; Original-Received: by lagi2 with SMTP id i2so71551974lag.2 for ; Fri, 26 Jun 2015 15:41:39 -0700 (PDT) X-Received: by 10.152.246.37 with SMTP id xt5mr3580819lac.83.1435358498872; Fri, 26 Jun 2015 15:41:38 -0700 (PDT) Original-Received: by 10.112.13.198 with HTTP; Fri, 26 Jun 2015 15:41:38 -0700 (PDT) Original-Received: by 10.112.13.198 with HTTP; Fri, 26 Jun 2015 15:41:38 -0700 (PDT) In-Reply-To: X-Original-Sender: chris@bubblescope.net X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.215.43 is neither permitted nor denied by best guess record for domain of chris@bubblescope.net) smtp.mail=chris@bubblescope.net 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:18822 Archived-At: --001a113496d0737a2b0519737111 Content-Type: text/plain; charset=UTF-8 On 26 Jun 2015 10:25 pm, "Tony V E" wrote: > > >> >> I have used an 'optimised optional' of the type suggested in this >> >> paper for years. At some point I decided to forbid this case -- a user >> >> should be completely unable to tell any space optimisation is being >> >> performed (except the object is smaller obviously). That does mean you >> >> can't compress types such as int or double. >> >> >> >> Chris >> > >> > >> > In what cases *can* you compress then? >> >> Any type where at least one bit pattern isn't used in a valid object. >> >> Personally, I mainly compress containers (std::vector, std::list, >> std::map, etc.). >> >> I know on any system I care about malloc is never going to return >> (void*)1, so any object which contains a pointer can assign that value >> to a pointer to represent disengaged. >> >> Chris > > > but how do you know that in my usage of optional, I also use (void*)1 for special meaning (besides the use inside optional). > ie I can still have: > > void * some_function(); // returns (void*)1 in some case > > optional ov = some_function(); > > assert( ! ov.empty() ); > > ie you still need to know the problem domain. Same as using NaN or 0 or whatever. > The user can still "tell" the optimization exists. Or, more likely, trip over in some rare case. > > I think it is valuable to hear that you have experience with a compressed optional, but I wonder if the eventual answer is that you would abandon it completely. > > And/or although it may be reasonable to assume your code base need not worry about (void *)1, the standard has a larger codebase to consider. I certainly wouldn't compress optional for the reasons you outline, but within STD::vector, I might know more, such as promises about the alignment of memory, or knowledge of STD::allocator. In the case of vector, in GCC there are 3 pointers start, end, capacity which satisfy start <= end <= capacity. I can therefore easily make a never occurring state by assigning start > end. I am going to think more carefully about the nan-compression case given earlier. I would not put it in the standard, but I can see the benefit of letting users write it -- if they then assign a nan they are in trouble, but that is their own fault! > -- > > --- > 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/. --001a113496d0737a2b0519737111 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 26 Jun 2015 10:25 pm, "Tony V E" <tvaneerd@gmail.com> wrote:
>
>
>> >> I have used an 'optimised optional' of the type s= uggested in this
>> >> paper for years. At some point I decided to forbid this c= ase -- a user
>> >> should be completely unable to tell any space optimisatio= n is being
>> >> performed (except the object is smaller obviously). That = does mean you
>> >> can't compress types such as int or double.
>> >>
>> >> Chris
>> >
>> >
>> > In what cases *can* you compress then?
>>
>> Any type where at least one bit pattern isn't used in a valid = object.
>>
>> Personally, I mainly compress containers (std::vector, std::list,<= br> >> std::map, etc.).
>>
>> I know on any system I care about malloc is never going to return<= br> >> (void*)1, so any object which contains a pointer can assign that v= alue
>> to a pointer to represent disengaged.
>>
>> Chris
>
>
> but how do you know that in my usage of optional<void*>, I also = use (void*)1 for special meaning (besides the use inside optional).
> ie I can still have:
>
> void * some_function(); // returns (void*)1 in some case
>
> optional<void *> ov =3D some_function();
>
> assert( ! ov.empty() );
>
> ie you still need to know the problem domain.=C2=A0 Same as using NaN = or 0 or whatever.
> The user can still "tell" the optimization exists.=C2=A0 Or,= more likely, trip over in some rare case.
>
> I think it is valuable to hear that you have experience with a compres= sed optional, but I wonder if the eventual answer is that you would abandon= it completely.
>
> And/or although it may be reasonable to assume your code base need not= worry about (void *)1, the standard has a larger codebase to consider.

I certainly wouldn't compress optional<void*> for = the reasons you outline, but within STD::vector, I might know more, such as= promises about the alignment of memory, or knowledge of STD::allocator.

In the case of vector, in GCC there are 3 pointers start, en= d, capacity which satisfy start <=3D end <=3D capacity. I can therefo= re easily make a never occurring state by assigning start > end.

I am going to think more carefully about the nan-compression= case given earlier. I would not put it in the standard, but I can see the = benefit of letting users write it -- if they then assign a nan they are in = trouble, but that is their own fault!

> --
>
> ---
> You received this message because you are subscribed to the Google Gro= ups "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-propos= als/.

--

---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--001a113496d0737a2b0519737111-- .