220 13525 article Path: news.gmane.org!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal: Strongly Typed Bitset Date: Thu, 2 Oct 2014 06:38:32 -0700 (PDT) Lines: 181 Approved: news@gmane.org Message-ID: References: <113390b2-9c74-47e2-a943-5d27dd48bdf1@isocpp.org> <41983d24-efb2-4255-b09b-f84cff7bf56d@isocpp.org> <63de9d71-e3b0-4242-9698-bea3a307b3c7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4084_1718364635.1412257112826" X-Trace: ger.gmane.org 1412257124 30033 80.91.229.3 (2 Oct 2014 13:38:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Oct 2014 13:38:44 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBWNKWWQQKGQEHOLZ3NY@isocpp.org Thu Oct 02 15:38:37 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f71.google.com ([209.85.220.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XZgaZ-0003BF-4m for gclcip-std-proposals@m.gmane.org; Thu, 02 Oct 2014 15:38:35 +0200 Original-Received: by mail-pa0-f71.google.com with SMTP id rd3sf13697708pab.10 for ; Thu, 02 Oct 2014 06:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=Ibj0fVkJoOR3VhujfsMaXnIDHAdMbmYTd4l/b3kti7U=; b=V34hvRSCoVfLXW50Z7G8MQ9iAnAfh4DEG+Hd21EA7CEVYHbH9isblHoCs1WkRILGG1 /JbzXpJrfO1z2W6GrVrlKElXAe8sjKv7HFey1ZhVABCI1uozzpdBpBRLE46s9tPDn/bz 2d4bZ1yZm6+LwOOIEZTCRdPWbSm+K/Rmsu2H7nl1z5+SNsMYqS673KkL13dsPcF3zeNe IPDjueUX4DPCGb8Hwtv8YfzHgb39vEJh1WtROOfFrxR/AXZM2RW1N5EoeG/h98hpQtk9 N9t189ger0AU5dTVwR3vBgHmRB840gtct46Gq36ey9A2hCpAYmIBTmbEXvyhdNp4I6aA Mn8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=Ibj0fVkJoOR3VhujfsMaXnIDHAdMbmYTd4l/b3kti7U=; b=eI8Nh1o6rUZs819WHKlMR23iwQBGps5NlmGA0q6P6GSA2HdztDe/wqxBZ7AVS/vKkR in1BJc+cBACVaGjvPmxwzUlf8/qe0mhJGEE+5o1sA930aKsXXRskMl7mat2RIvZZwxQq owJLuqgFzG0v/44Jojjt2rChtGYE7h6uSoEHpIsPKE5k286SFMUSyyP23rR+qgcMiFJf p3X6MA4xT1KVx3+0s/S0b/IsvNTaVmVIjR7YKxs065Y4kuN3dwhELCpOnyxKrLHo1a/T iBH9ia1NcspG58Xu32J37+fMIoqhG8IkHrnXIUCFRC/1ztYCeRglNnsmhtRgJ9tVR6iJ r6tw== X-Gm-Message-State: ALoCoQnR3mezKeMsfSe4W0hM/p93ygVG6A8J6j80sklNqeXvqbGS3QFNtn3KL82gpkC+GNuRb42B X-Received: by 10.66.141.70 with SMTP id rm6mr107601pab.37.1412257114021; Thu, 02 Oct 2014 06:38:34 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.98.183 with SMTP id o52ls833443qge.70.gmail; Thu, 02 Oct 2014 06:38:33 -0700 (PDT) X-Received: by 10.140.97.117 with SMTP id l108mr92507qge.3.1412257113223; Thu, 02 Oct 2014 06:38:33 -0700 (PDT) In-Reply-To: X-Original-Sender: fmatthew5876@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:13525 Archived-At: ------=_Part_4084_1718364635.1412257112826 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, October 2, 2014 3:51:38 AM UTC-4, Nicola Gigante wrote: > > > In my opinion this is a very useful feature! A lot of times I=E2=80=99ve = wanted to=20 > use bitset but I couldn=E2=80=99t because > I also needed to directly access the underlying data. I think this is a= =20 > fundamental flaw in the current std::bitset > design. I=E2=80=99d farther suggest to make it simple to tie a bitset to = an=20 > already existing buffer. Would it be difficult > to standardize a =E2=80=9Cbitset_view=E2=80=9D class that just adapts an = existing random=20 > access container and expose the > bit access capabilities of bitset?=20 > Its possible. As you pointed out bitset_view would need to be a separate=20 class. =20 > Then the old bitset could be implemented by wrapping this view over > a std::array, while wrapping over an array_view would make it possible to= =20 > access already existing buffers. > It depends on how bitset_view is implemented. If its implemented on top of= =20 array_view (which I would recommend), this is a non-starter because the=20 object would contain 2 extra pointers. Defeating the entire purpose of my= =20 current proposal. =20 > Wrapping it over an std::vector, we=E2=80=99ll have boost::dynamic_bitset= for free. > Well not quite, a hypothetical bitset_view I imagine would work like=20 array_view in that it just wraps over a pair or pointers and gives you a=20 bit access API over the buffer. In fact I'd probably define such a=20 bitset_view to just accept an array_view in its constructor so that it can= =20 generically wrap any kind of buffer by piggybacking off of array_view's=20 capabilities. Such is the power and magnificence of array_view!=20 Supporting a dynamic bitset would require some additional logic to handle= =20 growing via push_back(). It probably needs to be its own class. Also I'm=20 not sure I see a value having a dynamic_bitset_view over a std::vector? Do= =20 you have a use case for that? =20 > In this way you could make the old bitset a simple typedef (given that th= e=20 > current proposal would > break the ABI anyway, why not?), but you could also leave bitset alone,= =20 > not breaking the ABI in any way,=20 > and let users that need more power to use bitset_view over whichever=20 > container they like. > > What do you think about this idea? > > Bye, > Nicola > Probably we want separate bitset (std::array), dynamic_bitset=20 (std::vector), and bitset_view (std::array_view). On Thursday, October 2, 2014 7:23:21 AM UTC-4, Farid Mehrabi wrote: > > > > that is more efficient; when (N % word_size) =3D=3D 0, this= =20 > approach will save us one unused extra word per instance. > That's a bug in my paper. Thanks for catching, I'll fix it in the next=20 revision.=20 --=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/. ------=_Part_4084_1718364635.1412257112826 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thursday, October 2, 2014 3:51:38 AM UTC-4, Nic= ola Gigante wrote:

In my opinion this is a very useful= feature! A lot of times I=E2=80=99ve wanted to use bitset but I couldn=E2= =80=99t because
I also needed to directly access the underlying d= ata. I think this is a fundamental flaw in the current std::bitset
design. I=E2=80=99d farther suggest to make it simple to tie a bitset to = an already existing buffer. Would it be difficult
to standardize = a =E2=80=9Cbitset_view=E2=80=9D class that just adapts an existing random a= ccess container and expose the
bit access capabilities of bitset?=

Its possible. As you pointed out b= itset_view would need to be a separate class.
 
Then the old bitset could be implemented by wrapping this view over
=
a std::array, while wrapping over an array_view would make it possible= to access already existing buffers.
It depends on how bitset_view is implemented. If its implemented on top of= array_view (which I would recommend), this is a non-starter because the ob= ject would contain 2 extra pointers. Defeating the entire purpose of my cur= rent proposal.
 
=
Wrapping it over an std::vect= or, we=E2=80=99ll have boost::dynamic_bitset for free.

Well not quite, a hypothetical bitset_view I imagine wou= ld work like array_view in that it just wraps over a pair or pointers and g= ives you a bit access API over the buffer. In fact I'd probably define such= a bitset_view to just accept an array_view in its constructor so that it c= an generically wrap any kind of buffer by piggybacking off of array_view's = capabilities. Such is the power and magnificence of array_view!

Sup= porting a dynamic bitset would require some additional logic to handle grow= ing via push_back(). It probably needs to be its own class. Also I'm not su= re I see a value having a dynamic_bitset_view over a std::vector? Do you ha= ve a use case for that?
 
In this way you = could make the old bitset a simple typedef (given that the current proposal= would
break the ABI anyway, why not?), but you could also leave = bitset alone, not breaking the ABI in any way, 
and let user= s that need more power to use bitset_view over whichever container they lik= e.

What do you think about this idea?
<= br>
Bye,
Nicola

Probably we want = separate bitset (std::array), dynamic_bitset (std::vector), and bitset_view= (std::array_view).


On Thursday, October 2, 2014 7:23:21 AM UTC-= 4, Farid Mehrabi wrote:


            that is more efficient; = when (N % word_size)=  =3D=3D 0, th= is approach will save us one unused extra word per instance.

That's a bug in my paper. Thanks for = catching, I'll fix it in the next revision.

--

---
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>.
------=_Part_4084_1718364635.1412257112826-- .