220 4700 <380926f6-352d-43d4-9295-535aeea1d242@isocpp.org> article
Path: news.gmane.org!not-for-mail
From: cornedbee@google.com
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: Remove vector<bool>?
Date: Wed, 29 May 2013 03:16:57 -0700 (PDT)
Lines: 82
Approved: news@gmane.org
Message-ID: <380926f6-352d-43d4-9295-535aeea1d242@isocpp.org>
References: <CAGsORuDQdeWAO5yjA6=h0hW9Y0Sj4F1gcHB61udw5JFmtx+g4Q@mail.gmail.com> <CAGg_6+O9XJucMxwEhU+50Dzx0Tz7XRK0cWyrkUHuPSoEz9TqEw@mail.gmail.com>
 <DBDB593B-7988-4A2E-AD88-0B5D37D136FD@gmail.com>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_4771_13115204.1369822617243"
X-Trace: ger.gmane.org 1369822623 26524 80.91.229.3 (29 May 2013 10:17:03 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Wed, 29 May 2013 10:17:03 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBD43DGWT5IFRBGVLS6GQKGQEHUUACFY@isocpp.org Wed May 29 12:17:04 2013
Return-path: <std-proposals+bncBD43DGWT5IFRBGVLS6GQKGQEHUUACFY@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-ve0-f197.google.com ([209.85.128.197])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBD43DGWT5IFRBGVLS6GQKGQEHUUACFY@isocpp.org>)
	id 1UhdRD-0006DV-D1
	for gclcip-std-proposals@m.gmane.org; Wed, 29 May 2013 12:16:59 +0200
Original-Received: by mail-ve0-f197.google.com with SMTP id d10sf4232202vea.0
        for <gclcip-std-proposals@m.gmane.org>; Wed, 29 May 2013 03:16:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20120113;
        h=x-beenthere:date:from:to:message-id:in-reply-to:references:subject
         :mime-version:x-original-sender:reply-to:precedence:mailing-list
         :list-id:x-google-group-id:list-post:list-help:list-archive
         :list-subscribe:list-unsubscribe:content-type;
        bh=g9k9bZDWsq1urKtY4lueKbYq4369sHi2msmqTiqr6Fs=;
        b=GNJC+oIqlp2qmqm+avD38Spom7ZI15rFbsxdd9kYpeD6sKHzzUgoW09K53rO9lmz19
         SfB4yL3taJhIQllX/qNmyMHL/ORvj/0TlG8L3wC6uaFv8/W34+eSA2oaBZIMV1DurqPm
         0VYZStMOR7kpD3G2Qlpmh2JoO5+ppVXTpKDW7Cgox3v8D2ldrdGGeEJnx38PBy/oYu/S
         pBcXJY4HPVV66Kfj8jtGIwL8yGNviY9U4fi1O0KZu9D6M4F9O9RHtqk6jfe+RD2NnNnA
         WWecS7TaB0d/Oi3o1RG3BD+L1zKNlzIB2JjmZJm55/7Q6KfVpg8f7+xmRfeNSHof1oV/
         3Edw==
X-Received: by 10.224.200.202 with SMTP id ex10mr1406545qab.8.1369822618489;
        Wed, 29 May 2013 03:16:58 -0700 (PDT)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.49.74.137 with SMTP id t9ls3815461qev.23.gmail; Wed, 29 May
 2013 03:16:57 -0700 (PDT)
X-Received: by 10.49.6.201 with SMTP id d9mr73705qea.12.1369822617631;
        Wed, 29 May 2013 03:16:57 -0700 (PDT)
In-Reply-To: <DBDB593B-7988-4A2E-AD88-0B5D37D136FD@gmail.com>
X-Original-Sender: cornedbee@google.com
Precedence: list
Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org
List-ID: <std-proposals.isocpp.org>
X-Google-Group-Id: 399137483710
List-Post: <http://groups.google.com/a/isocpp.org/group/std-proposals/post?hl=en>,
 <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?hl=en&topic=25838>,
 <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe?hl=en>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe?hl=en>,
 <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:4700
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/4700>

------=_Part_4771_13115204.1369822617243
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, May 28, 2013 6:43:36 PM UTC+2, Howard Hinnant wrote:
>
>
> I will oppose deprecating vector<bool> until we put in place something for 
> clients of vector<bool> to migrate to.  That something should have much the 
> same API as vector<bool> to ease said migration.  I.e. clients of 
> vector<bool> should have to do little more than change the name of the 
> container. 
>
> Additionally we could add sweetener to encourage the migration.  For 
> example we could mandate that bit_vector<Allocator> (or whatever the new 
> name is) is hyper efficient when used with std::algorithms such as: 
>
>
And we should add an interface that allows 3rd-party or user-defined 
algorithms to exploit the packed representation of bit_vector. It's all 
nice for standard algorithms to be optimized for vector<bool>, but as a 
user of the library, I can't optimize my own algorithms without reaching 
into the implementation details, such as __bit_reference. So not only would 
I have to optimize my algorithm for packed bits, I'd have to do it for many 
different standard libraries.

Sebastian 

-- 

--- 
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/?hl=en.



------=_Part_4771_13115204.1369822617243
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, May 28, 2013 6:43:36 PM UTC+2, Howard Hinnant wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><br>I will oppose deprecating vec=
tor&lt;bool&gt; until we put in place something for clients of vector&lt;bo=
ol&gt; to migrate to. &nbsp;That something should have much the same API as=
 vector&lt;bool&gt; to ease said migration. &nbsp;I.e. clients of vector&lt=
;bool&gt; should have to do little more than change the name of the contain=
er.
<br>
<br>Additionally we could add sweetener to encourage the migration. &nbsp;F=
or example we could mandate that bit_vector&lt;Allocator&gt; (or whatever t=
he new name is) is hyper efficient when used with std::algorithms such as:
<br><br></blockquote><div><br></div><div>And we should add an interface tha=
t allows 3rd-party or user-defined algorithms to exploit the packed represe=
ntation of bit_vector. It's all nice for standard algorithms to be optimize=
d for vector&lt;bool&gt;, but as a user of the library, I can't optimize my=
 own algorithms without reaching into the implementation details, such as _=
_bit_reference. So not only would I have to optimize my algorithm for packe=
d bits, I'd have to do it for many different standard libraries.</div><div>=
<br></div><div>Sebastian&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4771_13115204.1369822617243--

.