220 5862 <2521316b-a25c-423d-bb13-514deaf73f28@isocpp.org> article
Path: news.gmane.org!not-for-mail
From: David Krauss <potswa@gmail.com>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: Remove vector<bool>?
Date: Mon, 26 Aug 2013 18:54:48 -0700 (PDT)
Lines: 116
Approved: news@gmane.org
Message-ID: <2521316b-a25c-423d-bb13-514deaf73f28@isocpp.org>
References: <CAGsORuDQdeWAO5yjA6=h0hW9Y0Sj4F1gcHB61udw5JFmtx+g4Q@mail.gmail.com>	<b06daeb3-a585-4c55-aebf-cae643146838@isocpp.org>	<CAGg_6+O_d85CBjT+cTV6vQqepUTXVvUMV_QUioS6ELpQCav6GQ@mail.gmail.com>	<521B07D2.8070000@beamways.com>	<7d0bc129-f8aa-4803-bbd9-bd5ca504d728@isocpp.org>	<CAGsORuB8omCBfjco6i_zENDn23tx-5wg1jeHuhsGsiVMbGk+Ww@mail.gmail.com>	<77e0868c-6aed-4578-acc7-7cf1227465f6@isocpp.org>	<CAGsORuAAZChA8cyx4JTTqRmMNSGQXZyGdzrm9P0WVRMZSSg6Qw@mail.gmail.com>	<4E5B6BD9-363D-4B42-ACA3-029301F3F54E@gmail.com>	<CA+cyFgvGeOJQSfXAQg3z2TKXvFY-OYvhp6_EGMx_mxoskys7LQ@mail.gmail.com>	<CAGsORuCKcuREjDJVyrfL+eHUF8diSENG2sVC2rjGnfOqcyOdBw@mail.gmail.com>	<5EEBFD4F-87A9-4543-8449-B5CAAC2E29E6@gmail.com> <CAGsORuCY_aPGJ37G6Q_HBVBpm51JUybbRot4WbQPC8etcGfGdA@mail.gmail.com>
 <C114924A-C9F9-4F91-900C-C6CD6BBDA8B9@gmail.com>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_61_9520664.1377568488583"
X-Trace: ger.gmane.org 1377568490 17143 80.91.229.3 (27 Aug 2013 01:54:50 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Tue, 27 Aug 2013 01:54:50 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBCW25A7E3QCRB2MN6CIAKGQEOGR2PJQ@isocpp.org Tue Aug 27 03:54:53 2013
Return-path: <std-proposals+bncBCW25A7E3QCRB2MN6CIAKGQEOGR2PJQ@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-ie0-f198.google.com ([209.85.223.198])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBCW25A7E3QCRB2MN6CIAKGQEOGR2PJQ@isocpp.org>)
	id 1VE8Ue-0004el-2M
	for gclcip-std-proposals@m.gmane.org; Tue, 27 Aug 2013 03:54:52 +0200
Original-Received: by mail-ie0-f198.google.com with SMTP id 17sf15603826iea.5
        for <gclcip-std-proposals@m.gmane.org>; Mon, 26 Aug 2013 18:54:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=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=3ir+B0J3qwpysJNehNZbcgStvTKeZFQaZ1C0gKk/QTo=;
        b=dmI9g91NLznapts7HJUpEY+KJd/feeiAEACuxFeGHHwkw16dlxyNNYumOmkZ1lyKy5
         L71PX7NGCJ7nZEGshY0yq39ZfRPHl/ob0r6OsBPbPzo2W4npfuBGEz4l8J6lVzyIQ7w5
         x17/D74Nul1SdSBdTljrKNYciY1TP5r1UmmM1n8arQdLZfuaDQKuZXtKy0nxvMSvySo7
         QIQWrklCB8s2tlNxYGSpYvGko03IEaRAY3N8h2ElCpZW3CRNAWQyXu7u9lVSUHwNb9RA
         EBqL3//nVWHe+XLIGVJIiZ/gb2CucL7aCjE2ltkQe0jqIwffZy62wwLJBI5GzlbxiZO5
         EQTw==
X-Received: by 10.42.90.198 with SMTP id l6mr9761550icm.12.1377568491200;
        Mon, 26 Aug 2013 18:54:51 -0700 (PDT)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.50.93.4 with SMTP id cq4ls2748105igb.17.gmail; Mon, 26 Aug
 2013 18:54:49 -0700 (PDT)
X-Received: by 10.50.73.132 with SMTP id l4mr492979igv.0.1377568489604;
        Mon, 26 Aug 2013 18:54:49 -0700 (PDT)
In-Reply-To: <C114924A-C9F9-4F91-900C-C6CD6BBDA8B9@gmail.com>
X-Original-Sender: potswa@gmail.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>, <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?topic=25838>, <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:5862
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/5862>

------=_Part_61_9520664.1377568488583
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, August 27, 2013 9:06:37 AM UTC+8, Howard Hinnant wrote:
>
>
> On Aug 26, 2013, at 8:58 PM, Zhihao Yuan <z...@miator.net <javascript:>> 
> wrote: 
>
> > Ah, I see... We should be able to specialize iterator_traits to unblock 
> > proxy iterators... 
>
> And actually we already have done this for input iterators and output 
> iterators.  We just have this legacy requirement hanging around that 
> forward iterators (and bi and rand) must return a value_type& from 
> operator*() (const value_type& for non-mutable variants).  The T& return 
> from forward iterator operator*() is kind of like dandelions.  It kind of 
> looks pretty.  And it is very hard to get rid of. :-)  But I think we 
> should make an effort to do so. 
>

Amen brother. Fleshing out the generic semantics will clean a mess that 
trying to scrub out details will only worsen. And progress forward rather 
than trip over trying to run backwards.

But the cleanup should extend into allocators as well. The allocator 
supplies the mapping (Allocator::address) from Iterator::reference to 
Iterator::pointer.

Conceptually, packing bits is an optimization of allocation. Aside from 
special functions like vector<bool>::flip, vector<bool> shouldn't need to 
be a specialization at all. With appropriately generic address arithmetic, 
and concepts to enable the special members, std::vector<bool> could be the 
generic instantiation of std::vector< bool, bitpacking_allocator >. Then 
std::deque could benefit from the same optimized algorithms, because its 
node and iterator classes would have internal bit-pointers.

The default allocator type argument of std::vector would be an alias 
template to select either std::allocator<T> or std::bitpacking_allocator. 
Users who want the non-packed functionality would explicitly specify 
std::allocator<T>. Migration would be reduced to deprecating that alias 
template.

Properly generic iterators/allocators should also allow range access to 
files, or if you prefer, user-space virtual memory. Interleaved arrays 
would be another application. I think we're missing out on a lot.

-- 

--- 
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_61_9520664.1377568488583
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, August 27, 2013 9:06:37 AM UTC+8, Howa=
rd Hinnant wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>On Aug 26, 2013, at 8:58 PM, Zhihao Yuan &lt;<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"8FOovpnGUh0J">z...@miator.net</a>&=
gt; wrote:
<br>
<br>&gt; Ah, I see... We should be able to specialize iterator_traits to un=
block
<br>&gt; proxy iterators...
<br>
<br>And actually we already have done this for input iterators and output i=
terators. &nbsp;We just have this legacy requirement hanging around that fo=
rward iterators (and bi and rand) must return a value_type&amp; from operat=
or*() (const value_type&amp; for non-mutable variants). &nbsp;The T&amp; re=
turn from forward iterator operator*() is kind of like dandelions. &nbsp;It=
 kind of looks pretty. &nbsp;And it is very hard to get rid of. :-) &nbsp;B=
ut I think we should make an effort to do so.
<br></blockquote><div><br>Amen brother. Fleshing out the generic semantics =
will clean a mess that trying to scrub out details will only worsen. And pr=
ogress forward rather than trip over trying to run backwards.<br><br>But th=
e cleanup should extend into allocators as well. The allocator supplies the=
 mapping (Allocator::address) from Iterator::reference to Iterator::pointer=
..<br><br>Conceptually, packing bits is an optimization of allocation. Aside=
 from special functions like vector&lt;bool&gt;::flip, vector&lt;bool&gt; s=
houldn't need to be a specialization at all. With appropriately generic add=
ress arithmetic, and concepts to enable the special members, std::vector&lt=
;bool&gt; could be the generic instantiation of std::vector&lt; bool, bitpa=
cking_allocator &gt;. Then std::deque could benefit from the same optimized=
 algorithms, because its node and iterator classes would have internal bit-=
pointers.<br><br>The default allocator type argument of std::vector would b=
e an alias template to select either std::allocator&lt;T&gt; or std::bitpac=
king_allocator. Users who want the non-packed functionality would explicitl=
y specify std::allocator&lt;T&gt;. Migration would be reduced to deprecatin=
g that alias template.<br><br>Properly generic iterators/allocators should =
also allow range access to files, or if you prefer, user-space virtual memo=
ry. Interleaved arrays would be another application. I think we're missing =
out on a lot.<br></div></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_61_9520664.1377568488583--

.