220 13552 <76a65477-dc4e-4c77-92bd-8123e9ce7c0f@isocpp.org> article Path: news.gmane.org!not-for-mail From: ricky.65@hotmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: Strongly Typed Bitset Date: Thu, 2 Oct 2014 09:04:21 -0700 (PDT) Lines: 130 Approved: news@gmane.org Message-ID: <76a65477-dc4e-4c77-92bd-8123e9ce7c0f@isocpp.org> References: <113390b2-9c74-47e2-a943-5d27dd48bdf1@isocpp.org> <41983d24-efb2-4255-b09b-f84cff7bf56d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6988_756819387.1412265861452" X-Trace: ger.gmane.org 1412265873 20368 80.91.229.3 (2 Oct 2014 16:04:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Oct 2014 16:04:33 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDIITWUOTQNRBBXPWWQQKGQES5MQ3TI@isocpp.org Thu Oct 02 18:04:26 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f199.google.com ([209.85.214.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XZirg-0003Kv-C0 for gclcip-std-proposals@m.gmane.org; Thu, 02 Oct 2014 18:04:24 +0200 Original-Received: by mail-ob0-f199.google.com with SMTP id va2sf11916354obc.2 for ; Thu, 02 Oct 2014 09:04:22 -0700 (PDT) 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=UvAZMNCKlg2fHzz79TfjHu/lwQbf+fCCMiJXniDtOgs=; b=glH2cXBpAIzgMf+CZ8zo9u4Pua7KFUgZcsGU2pymL0SyP/7N/APfdYhwgz2xoKnKyt H/s1WUVb3lHuHfuhinlkyqaNYWK0BvWP5WCX3x5wkZAEiwiugT1775I7DD6Op6fBHvmh ty+8+Jo881oRwzwdA9l5zvOa4Fjcl5bjSgx1FHIeqyri3ma6FK/prVDMsbuP7JHd5Hzl eNVDPYy5DVoiGM9rDP47BejCsKF1JlHfyzbQfBmiuMvyehurimgBUYU7QDgXOYwLwWMz ZPHVURwEa5KU2W5rXoQu2t5gjtYKRPRtngHCXK+sqXzY0ejGoDrMkO/llQ3mv8qEnKev TiaQ== X-Gm-Message-State: ALoCoQlDrP9fZEWJoaCA6tZZgCirqvby+wWkrSm07zK+iv3UkmeORAO5YcqZmO2fe2M2Vhf0B+7i X-Received: by 10.42.62.73 with SMTP id x9mr836470ich.15.1412265862742; Thu, 02 Oct 2014 09:04:22 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.30.55 with SMTP id c52ls949814qgc.8.gmail; Thu, 02 Oct 2014 09:04:22 -0700 (PDT) X-Received: by 10.140.19.2 with SMTP id 2mr6294qgg.35.1412265862029; Thu, 02 Oct 2014 09:04:22 -0700 (PDT) In-Reply-To: <41983d24-efb2-4255-b09b-f84cff7bf56d@isocpp.org> X-Original-Sender: ricky.65@hotmail.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:13552 Archived-At: ------=_Part_6988_756819387.1412265861452 Content-Type: text/plain; charset=UTF-8 On Wednesday, October 1, 2014 4:03:14 PM UTC+1, Matthew Fioravante wrote: > > > A separate type would be better: > > template using fast_bitset = bitset defined */> > template using small_bitset = bitset defined */> > These look reasonable to me and I feel that they would generally appease users in both camps. People who want fine-grain control can always specify their own template parameter. Finally, (this might be a separate proposal) bitset::to_string() is really > an inefficient design. It returns a std::string which will require a memory > allocation. > I also don't like bitset::to_string() but I still like the ability of returning a std::string. It doesn't always require a memory allocation if the implementation uses SSO. I feel it would be preferable if it were a non-member function instead. Instead of that, to_string() could return std::array, which holds > a null terminated bitstring. I like the idea of returning a std::array but I'm not sure if a null terminator is necessary. May I suggest the name "to_array" instead of modifying to_string(). Probably we want separate bitset (std::array), dynamic_bitset > (std::vector), and bitset_view (std::array_view). I agree. That would comprise a suite of bitset containers that would likely satisfy most programmers bitset requirements. Incidentally, does anybody know the status of std::dynamic_bitset? I know it was proposed for TR2 but I haven't read anything since. -Riccardo -- --- 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/. ------=_Part_6988_756819387.1412265861452 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, October 1, 2014 4:03:14 PM UTC+1, Matthew Fi= oravante wrote:

A separate type would be better:

= template <typename N> using fast_bitset =3D bitset<N, /* Implementation define= d */>
template <typename N> using small_bitset =3D bitset<N, /* Implementation defined */= >
<= /div>

 These look reasonable to me and= I feel that they would generally appease users in both camps. People who w= ant fine-grain control can always specify their own template parameter.&nbs= p;

Finally, (this might be= a separate proposal) bitset::to_string() is really an inefficient design. = It returns a std::string which will require a memory allocation.

I also don't like bitset::to_string() but I still= like the ability of returning a std::string. It doesn't always requir= e a memory allocation if the implementation uses SSO. I feel it would be pr= eferable if it were a non-member function instead.

Instead of that, to_string() could return std::arr= ay<char,N+1>, which holds a null terminated bitstring.

I like the idea of returning a std::array but I'm not sur= e if a null terminator is necessary. May I suggest the name "to_array" inst= ead of modifying to_string().

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

I = agree. That would comprise a suite of bitset containers that would likely s= atisfy most programmers bitset requirements. Incidentally, does anybody kno= w the status of std::dynamic_bitset? I know it was proposed for TR2 but I h= aven't read anything since.

-Riccardo

--

---
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_6988_756819387.1412265861452-- .