220 13608 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: Fri, 3 Oct 2014 08:43:59 +0200 Lines: 74 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> <9462C54C-E91B-4B66-AA8E-CAEA1F190FE6@gmail.com> <3e2c6bae-052e-4001-a407-8c69ae41e8cc@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: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1412318716 10857 80.91.229.3 (3 Oct 2014 06:45:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Oct 2014 06:45:16 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDMMZOF5V4KBB34LXGQQKGQE5EVBDMY@isocpp.org Fri Oct 03 08:45:08 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ee0-f69.google.com ([74.125.83.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XZwbx-0000kp-AR for gclcip-std-proposals@m.gmane.org; Fri, 03 Oct 2014 08:45:05 +0200 Original-Received: by mail-ee0-f69.google.com with SMTP id b57sf426898eek.4 for ; Thu, 02 Oct 2014 23:45:04 -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:subject:from:in-reply-to:date :message-id:references: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:content-transfer-encoding; bh=9YZRMYmk/fK4qXpcBptU9AZhdePEgdNgDIkRcsNB/Ek=; b=Du71Neb6ykS7KCtztVGaMV3r7VSJdRcynT8Gq4d4vA+1nJrCXxe8kroYW/yMPlk3mj 7i2QtGtUpwPa4WuSGyBcZW6ncPVkK9P2UJIyGpFBbgCc01F/IMDUbzt8m1nI1v+0FUKg mKF7d8QOn8zml+4uBImnXjwn4UVNv5v8Y6CCJ/kXi8Mw/sHt+y3hV5d9iqCYY2ICaQI7 65SnqpAKVCj7IkilSo9nC6vY5GPvZOY3cwZE1qwYDQ1FdNwAMezzea0/W086tbMb3317 NuE3/+umKlnWOKM/YoEd3DQxpyPL1h91hcfb8gIIeDiPz3Vg9BpQ7GFloGODRA/WHhKQ 0ueQ== X-Gm-Message-State: ALoCoQnNiUholDbvozV6N9G6XatewDFUBKvCVeGilCRvSBBZzMmJ+AmySFzhBJl2fyrpqxZ/SNk0 X-Received: by 10.112.163.39 with SMTP id yf7mr87003lbb.7.1412318704427; Thu, 02 Oct 2014 23:45:04 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.107.226 with SMTP id hf2ls184248wib.8.canary; Thu, 02 Oct 2014 23:45:03 -0700 (PDT) X-Received: by 10.180.9.73 with SMTP id x9mr9992417wia.20.1412318703218; Thu, 02 Oct 2014 23:45:03 -0700 (PDT) Original-Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [2a00:1450:400c:c00::229]) by mx.google.com with ESMTPS id vu2si7750305wjc.139.2014.10.02.23.45.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 23:45:03 -0700 (PDT) Received-SPF: pass (google.com: domain of nicola.gigante@gmail.com designates 2a00:1450:400c:c00::229 as permitted sender) client-ip=2a00:1450:400c:c00::229; Original-Received: by mail-wg0-f41.google.com with SMTP id b13so681890wgh.0 for ; Thu, 02 Oct 2014 23:45:03 -0700 (PDT) X-Received: by 10.181.29.134 with SMTP id jw6mr9783771wid.69.1412318702514; Thu, 02 Oct 2014 23:45:02 -0700 (PDT) Original-Received: from [158.110.153.153] ([158.110.153.153]) by mx.google.com with ESMTPSA id be1sm1048550wib.4.2014.10.02.23.45.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 23:45:01 -0700 (PDT) In-Reply-To: <3e2c6bae-052e-4001-a407-8c69ae41e8cc@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:c00::229 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:13608 Archived-At: Il giorno 02/ott/2014, alle ore 17:25, Matthew Fioravante ha scritto: > This kind of approach is very difficult to do generically. The devil is i= n the details. >=20 > For one, you're assuming the underlying container has a single argument c= onstructor which takes an integral size. This works for std::vector but not= for std::array, a C array, or an array_view which already have an implicit= size and don't need any constructor arguments. You've got to somehow detec= t and handle both concepts correctly. >=20 > This also doesn't really support the full dynamic_bitset semantics. For i= nstance you cannot resize or push_back() into the underlying container if i= t is a dynamic one like a vector. Your bitview only models a fixed size col= lection of bits. Again you've got to determine whether or not your containe= r can be resized and support this behavior if so. >=20 > In order to do this kind of generic thing effectively you need to define = some concepts such as "fixed size buffer" (array_view) and "dynamically gro= wing buffer" (vector). Its better to modularize and outsource those concept= s to more pure interfaces designed only for them such as array_view and dyn= amic_array_view. The array_view handles all of the logic related to a fixed= size buffer. Then built on top of that foundation, your bitset_view only n= eeds to worry about manipulating the bits of that buffer. By leveraging arr= ay_view, bitset_view works on any imaginable kind of fixed size buffer for = free. Its a better separation and encapsulation. >=20 > Once you have those concepts, its better to make different bitview types = over them. If I have a bitset_view and a dynamic_bitset_view I know immedia= tely what to expect and don't have to know or care what the underlying repr= esentation is. If I have a bitview, bitview, bitview, I don't know what the semanics of the bitview is until I l= ook at the underlying container. It also requires more template parameters = to be passed around. I can pass a bitset_view to a normal function. If I'm = passing around a bitview, I have to use templates everywhere. >=20 > Now finally, you mentioned that one benefit of your approach is that std:= :bitset and std::dynamic_bitset could just be implemented trivially using t= he bitview. This is actually not a concern for us we generally don't care h= ow things are implemented, as long as they fit the specification efficientl= y. We hate our implementers and don't care how much work we create for them= ;). >=20 > There's only 1 way to really do a fixed size bitset and that's just creat= e an array and operate on the bits. We don't really need configurability th= ere. For a dynamic bitset, you could argue there are multiple possibilities= , just as there are many ways to implement the equivalent of std::vector. O= r maybe someone wants dequeue or something else crazy. We aren't talking ab= out dynamic_bitset yet so I don't yet want to go there. >=20 > I hope that made sense. Things get fuzzier when we go outside of bits and= bytes and start talking design philosophies. >=20 >=20 Yes, it makes sense. Now I agree with you that a single oversized class is = not the best idea. 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/. .