220 13528 <9462C54C-E91B-4B66-AA8E-CAEA1F190FE6@gmail.com> article Path: news.gmane.org!not-for-mail From: Nicola Gigante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal: Strongly Typed Bitset Date: Thu, 2 Oct 2014 15:59:27 +0200 Lines: 177 Approved: news@gmane.org Message-ID: <9462C54C-E91B-4B66-AA8E-CAEA1F190FE6@gmail.com> 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 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_74B98940-B87B-46F9-995C-4AC4AD695728" X-Trace: ger.gmane.org 1412258377 15148 80.91.229.3 (2 Oct 2014 13:59:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Oct 2014 13:59:37 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDMMZOF5V4KBBQ5UWWQQKGQE537WEVY@isocpp.org Thu Oct 02 15:59:32 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ee0-f72.google.com ([74.125.83.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XZguq-0003Xf-B0 for gclcip-std-proposals@m.gmane.org; Thu, 02 Oct 2014 15:59:32 +0200 Original-Received: by mail-ee0-f72.google.com with SMTP id e51sf1214522eek.11 for ; Thu, 02 Oct 2014 06:59:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=PdvyDI0pc1AuOvR6Nn9Tw7v7i6P5RcdjXm6u9z9gjMs=; b=b3PVpbi4VcR1DrYyQa1CU/SqrqNOjIkYakeS77hTH42LX6O3xnU6fcgxHIjdbSUhb6 g7anCAZ06a/XGuyPtnVcCYauCkNqKtf3ak/cGh3fJ6VUJDESSUmsJ7xo6B6YnnDL4Brc kYuC7C0CjhGB3rLbXQ03enoS7scEXfoAz5JhHNMiD8QXaDQvJRYyYdFvDl7uCZHUoSmV NU1N/QTEkY90LDgvsU9ZPAg2rf6mKWua7ba5iH6HiiZ572g8smV67ah6mFqva4munAks qABEOoI78P//9twc2SXu1tpTUSxs78hwfTeCBhBH/gtYMiibTTuzdYMJ40mW2fnyq6Wy yq+w== X-Gm-Message-State: ALoCoQm2ZtSbbE7GvR4iw4kPjZlEHaO229TJDWi0BDd7wSgE2LQVBDh3I5dISiDDt/25jqqJSDc1 X-Received: by 10.180.81.130 with SMTP id a2mr791421wiy.0.1412258371910; Thu, 02 Oct 2014 06:59:31 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.95.98 with SMTP id dj2ls90015wib.15.canary; Thu, 02 Oct 2014 06:59:31 -0700 (PDT) X-Received: by 10.180.72.239 with SMTP id g15mr4289951wiv.47.1412258371024; Thu, 02 Oct 2014 06:59:31 -0700 (PDT) Original-Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [2a00:1450:400c:c00::22c]) by mx.google.com with ESMTPS id jk5si1305885wid.3.2014.10.02.06.59.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 06:59:31 -0700 (PDT) Received-SPF: pass (google.com: domain of nicola.gigante@gmail.com designates 2a00:1450:400c:c00::22c as permitted sender) client-ip=2a00:1450:400c:c00::22c; Original-Received: by mail-wg0-f44.google.com with SMTP id y10so3222278wgg.3 for ; Thu, 02 Oct 2014 06:59:30 -0700 (PDT) X-Received: by 10.194.179.73 with SMTP id de9mr73111858wjc.87.1412258370681; Thu, 02 Oct 2014 06:59:30 -0700 (PDT) Original-Received: from [192.168.1.105] (adsl-ull-121-178.51-151.net24.it. [151.51.178.121]) by mx.google.com with ESMTPSA id c7sm1356525wib.12.2014.10.02.06.59.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 06:59:29 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.1878.6) X-Original-Sender: nicola.gigante@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of nicola.gigante@gmail.com designates 2a00:1450:400c:c00::22c as permitted sender) smtp.mail=nicola.gigante@gmail.com; dkim=pass header.i=@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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:13528 Archived-At: --Apple-Mail=_74B98940-B87B-46F9-995C-4AC4AD695728 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Il giorno 02/ott/2014, alle ore 15:38, Matthew Fioravante ha scritto: >=20 >=20 > On Thursday, October 2, 2014 3:51:38 AM UTC-4, Nicola Gigante wrote: >=20 > It depends on how bitset_view is implemented. If its implemented on top o= f array_view (which I would recommend), this is a non-starter because the o= bject would contain 2 extra pointers. Defeating the entire purpose of my cu= rrent proposal. My idea would be not to base the class on something specific (array_view or= something else), but to have the class to be wrapped as a template parameter and include an object of such a class inside it. I've implemented once something related for a data structure we're developi= ng at my university: https://github.com/nicola-gigante/bitvector/blob/master/include/bitview.h The interface is tailored to our application and not at all similar to bits= et but the aim is the same: to access the individual bits of a piece of data. If you instantiate bitview you get a non-owning view that, supe= rimposed on array_view, wraps any container you like. If you instantiate bitview (the arity of the template is not the same, you need a typedef, but you'll get the point), you obtain = an equivalent of bit set,=20 without any of the extra pointers you mentioned. With bitview = you get a sort of dynamic_bitset (the class provides resize() only if the underlying contain= er provides it) The interface need to be refined a lot for a serious proposal, but I think = the core idea is good. Also not that this class supports some access to subranges (similar to vala= rray slices), that bitset lacks, and that I think it's not less important. > =20 > Wrapping it over an std::vector, we'll have boost::dynamic_bitset for fre= e. >=20 > Well not quite, a hypothetical bitset_view I imagine would work like arra= y_view in that it just wraps over a pair or pointers and gives you a bit ac= cess 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 can generically wr= ap any kind of buffer by piggybacking off of array_view's capabilities. Suc= h is the power and magnificence of array_view!=20 >=20 > Supporting a dynamic bitset would require some additional logic to handle= growing via push_back(). It probably needs to be its own class. Also I'm n= ot sure I see a value having a dynamic_bitset_view over a std::vector? Do y= ou have a use case for that? > =20 Yes, in my data structure I use the same bitview both backed by an std::arr= ay, an std::array_view and a std::vector in three different places. Of course, that's because I don't have boost::dynamic_bit= set. But being able to use one flexible type in three different use cases instead of three different but highly similar types is = a good thing to me. >=20 > Probably we want separate bitset (std::array), dynamic_bitset (std::vecto= r), and bitset_view (std::array_view). >=20 I understand why it could be simpler, yet I think a sufficiently general un= derlying mechanism could be used to implement all of them. Bye, Nicola --=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/. --Apple-Mail=_74B98940-B87B-46F9-995C-4AC4AD695728 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Il giorn= o 02/ott/2014, alle ore 15:38, Matthew Fioravante <fmatthew5876@gmail.com> ha scritto:



On Thursday, October 2, 2014 3:51:38 AM UTC-4, Nicola Gigante wro= te:

It depends on how bitset_view is imple= mented. If its implemented on top of array_view (which I would recommend), = this is a non-starter because the object would contain 2 extra pointers. De= feating the entire purpose of my current proposal.

My idea would be not to base the class on something= specific (array_view or something else), but to have the class to be wrapp= ed
as a template parameter and include an object of such a class = inside it.

I’ve implemented once something r= elated for a data structure we’re developing at my university:
<= div>

The interface is = tailored to our application and not at all similar to bitset but the aim
is the same: to access the individual bits of a piece of data.

If you instantiate bitview<array_view> you get a= non-owning view that, superimposed on
array_view, wraps any cont= ainer you like. If you instantiate bitview<std::array> (the arity of = the template
is not the same, you need a typedef, but you’l= l get the point), you obtain an equivalent of bit set, 
with= out any of the extra pointers you mentioned. With bitview<std::vector>= ; you get a sort of
 dynamic_bitset (the class provides resi= ze() only if the underlying container provides it)

The interface need to be refined a lot for a serious proposal, but I think= the core idea is good.
Also not that this class supports some ac= cess to subranges (similar to valarray slices), that
bitset lacks= , and that I think it’s not less important.

 
Wrapping it over an std::= vector, we’ll have boost::dynamic_bitset for free.
=

Well not quite, a hypothetical bitset_view I imagine would work li= ke array_view in that it just wraps over a pair or pointers and gives 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 can generic= ally wrap any kind of buffer by piggybacking off of array_view's capabiliti= es. Such is the power and magnificence of array_view!

Supporting a = dynamic bitset would require some additional logic to handle growing via pu= sh_back(). It probably needs to be its own class. Also I'm not sure I see a= value having a dynamic_bitset_view over a std::vector? Do you have a use c= ase for that?
 

Yes= , in my data structure I use the same bitview both backed by an std::array,= an std::array_view and a std::vector in three
different places. = Of course, that’s because I don’t have boost::dynamic_bitset. B= ut being able to use one flexible type in three
different use cas= es instead of three different but highly similar types is a good thing to m= e.


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


I unders= tand why it could be simpler, yet I think a sufficiently general underlying= mechanism could be used to
implement all of them.
Bye,
Nicola

--

---
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>.
--Apple-Mail=_74B98940-B87B-46F9-995C-4AC4AD695728-- .