220 13488 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 09:51:34 +0200 Lines: 228 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 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_C9433F83-B7B1-4B1D-A75B-6FFA9FCEE77B" X-Trace: ger.gmane.org 1412236310 17480 80.91.229.3 (2 Oct 2014 07:51:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Oct 2014 07:51:50 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDMMZOF5V4KBBCMIWSQQKGQEWFM6NBI@isocpp.org Thu Oct 02 09:51:44 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wg0-f72.google.com ([74.125.82.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XZbAo-0002Ij-Le for gclcip-std-proposals@m.gmane.org; Thu, 02 Oct 2014 09:51:38 +0200 Original-Received: by mail-wg0-f72.google.com with SMTP id m15sf800827wgh.3 for ; Thu, 02 Oct 2014 00:51:38 -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=8Xxx/j0UArpQ4Gu+CVyk4MlB58/IVZ1VuyAUSwvjHv0=; b=JTEjwkQLNkynJdSxf7zxg4qM7J6EmYZZuUJTk3ia30Qy0NVMUSTMcvMTUtW27DhNkd m5CRxEZnzqkgkYUOuc1JeBbJjzozdkRoHVbAY9xoeEsKxfK2mqdOqR/bRH8F9VAN3XbK 33szDUmBBqnaUHWjMPRIU56eFW7M4Rv+W3roKzv8Aj+SCFL2EsIhKWx4Xd+Egf1C32Lh W7O72HuHSPNTRwU2KeBEh1ldWXImFLvdrgskXCTJ1yYEhxF7w4gNkANEyl35yYiE4N+f CMn58KmAjb22tJWxMI8Mf2qjiciiGL5B5teLgQaYQMKkl3e1HdYwTPD1bi9P6h8uYJRL 0k3A== X-Gm-Message-State: ALoCoQmmQ/WRvTJlzoB9VCINB1iVIBxeFaJXtlr015jcFJ1nd4TRUw0y12LNi7ZKESOyuhzlSayf X-Received: by 10.152.1.136 with SMTP id 8mr1354805lam.5.1412236298388; Thu, 02 Oct 2014 00:51:38 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.106.4 with SMTP id gq4ls32806wib.51.canary; Thu, 02 Oct 2014 00:51:37 -0700 (PDT) X-Received: by 10.194.78.76 with SMTP id z12mr45567593wjw.24.1412236297541; Thu, 02 Oct 2014 00:51:37 -0700 (PDT) Original-Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [2a00:1450:400c:c05::22b]) by mx.google.com with ESMTPS id go6si207777wib.89.2014.10.02.00.51.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 00:51:37 -0700 (PDT) Received-SPF: pass (google.com: domain of nicola.gigante@gmail.com designates 2a00:1450:400c:c05::22b as permitted sender) client-ip=2a00:1450:400c:c05::22b; Original-Received: by mail-wi0-f171.google.com with SMTP id em10so434527wid.16 for ; Thu, 02 Oct 2014 00:51:37 -0700 (PDT) X-Received: by 10.194.71.195 with SMTP id x3mr31488696wju.27.1412236297094; Thu, 02 Oct 2014 00:51:37 -0700 (PDT) Original-Received: from gigamac.fritz.box (adsl-ull-179-183.49-151.net24.it. [151.49.183.179]) by mx.google.com with ESMTPSA id cw6sm3668659wjb.18.2014.10.02.00.51.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 00:51:36 -0700 (PDT) In-Reply-To: <63de9d71-e3b0-4242-9698-bea3a307b3c7@isocpp.org> 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:c05::22b 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:13488 Archived-At: --Apple-Mail=_C9433F83-B7B1-4B1D-A75B-6FFA9FCEE77B Content-Type: text/plain; charset=ISO-8859-1 Hi Il giorno 02/ott/2014, alle ore 03:26, Matthew Fioravante ha scritto: > I've updated the draft with fast_bitset and small_bitset. > > https://github.com/fmatthew5876/stdcxx-bitset > > I had some ideas for additional directions to go into. I've not put these in the paper. > > Some new public members: > > template class bitset { > public: > using underlying_type = T[N / (sizeof(T) * CHAR_BIT) + 1]; > > array get_underlying() const; > void set_underlying(array a); > > > get_underlying() would return an array of T whose bits are identical to the bits stored in the bitset. All of the bits > N would be 0. > set_underlying(a) would set the internal bits to the values of the bits in a. All of the bits > N are ignored. > > Alternatively, instead of value semantics we could do reference semantics: > template class bitset { > public: > using underlying_type = T[N / (sizeof(T) * CHAR_BIT) + 1]; > > array& rep(); > const array& rep() const; > > > This is more dangerous as bitset is a value type which can be freely copied, but it might be more efficient for large bitsets. > In my opinion this is a very useful feature! A lot of times I've wanted to use bitset but I couldn't because I also needed to directly access the underlying data. I think this is a fundamental flaw in the current std::bitset design. I'd farther suggest to make it simple to tie a bitset to an already existing buffer. Would it be difficult to standardize a "bitset_view" class that just adapts an existing random access container and expose the bit access capabilities of bitset? 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. Wrapping it over an std::vector, we'll have boost::dynamic_bitset for free. 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 users that need more power to use bitset_view over whichever container they like. What do you think about this idea? Bye, Nicola -- --- 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/. --Apple-Mail=_C9433F83-B7B1-4B1D-A75B-6FFA9FCEE77B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Hi=

Il giorno 02/ott/2014, alle ore 03:26, Matthew Fioravan= te <fmatthew5876@gmail.com= > ha scritto:

I've updated the draft with fast_bitset and s= mall_bitset.

<= div>
I had some ideas for additional directions to go into. I= 've not put these in the paper.

Some new public me= mbers:

template <siz= e_t N, typename T> class bitset {
  public:  
    using underlying_type =3D T[N / (sizeof(T) *<= /span> CHAR_BIT)<= /span> + <= span style=3D"color: #066;" class=3D"styled-by-prettify">1];

  &nb= sp; array<T,sizeof(underlying_type) / sizeof(T= )> = get_underlying()<= /span> const;
&nb= sp;   void set_underlying(array&= lt;T,sizeof(underlying_type) / sizeof= (T)> a);
 

get_underlying() would retur= n an array of T whose bits are identical to the bits stored in the bitset. = All of the bits > N would be 0.
set_underlying(a) would set th= e internal bits to the values of the bits in a. All of the bits > N are = ignored.

Alternatively, instead of value semantics= we could do reference semantics:
= template &= lt;size_t N, typenam= e T> class bitset {
  public:  
    using underlying_type= =3D T[N / (sizeof(T) * CHAR_BIT) + 1];
    array<T,= sizeof(underl= ying_type)= / sizeof(T)&= gt;& rep()= ;
&nb= sp;   const<= /span> array<<= /span>T,sizeof(underlying_type= ) / sizeof(T)>&= ; rep() const= ;

<= /code>

This is more dangerous as bitset is a value type= which can be freely copied, but it might be more efficient for large bitse= ts.


In my opinio= n this is a very useful feature! A lot of times I’ve wanted to use bi= tset but I couldn’t because
I also needed to directly acces= s the underlying data. I think this is a fundamental flaw in the current st= d::bitset
design. I’d farther suggest to make it simple to = tie a bitset to an already existing buffer. Would it be difficult
to standardize a “bitset_view” class that just adapts an exist= ing random access container and expose the
bit access capabilitie= s of bitset? 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.
Wrapping it over = an std::vector, we’ll have boost::dynamic_bitset for free.
= 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 c= ould also leave bitset alone, not breaking the ABI in any way, 
<= div>and let users that need more power to use bitset_view over whichever co= ntainer they like.

What do you think about this id= ea?

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=_C9433F83-B7B1-4B1D-A75B-6FFA9FCEE77B-- .