220 4677 <7371f4b8-8c47-4f17-af1e-902a5c8b17e4@isocpp.org> article
Path: news.gmane.org!not-for-mail
From: Nicol Bolas <jmckesson@gmail.com>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: Remove vector<bool>?
Date: Tue, 28 May 2013 13:00:05 -0700 (PDT)
Lines: 105
Approved: news@gmane.org
Message-ID: <7371f4b8-8c47-4f17-af1e-902a5c8b17e4@isocpp.org>
References: <CAGsORuDQdeWAO5yjA6=h0hW9Y0Sj4F1gcHB61udw5JFmtx+g4Q@mail.gmail.com>
 <CAGg_6+O9XJucMxwEhU+50Dzx0Tz7XRK0cWyrkUHuPSoEz9TqEw@mail.gmail.com>
 <e59c2a57-6068-4098-8667-5d086b2961fd@isocpp.org>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_860_17531738.1369771205667"
X-Trace: ger.gmane.org 1369771213 30259 80.91.229.3 (28 May 2013 20:00:13 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Tue, 28 May 2013 20:00:13 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBCEKFTV6ZUMBBR4ZSSGQKGQE23RWTWA@isocpp.org Tue May 28 22:00:14 2013
Return-path: <std-proposals+bncBCEKFTV6ZUMBBR4ZSSGQKGQE23RWTWA@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-ie0-f197.google.com ([209.85.223.197])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBCEKFTV6ZUMBBR4ZSSGQKGQE23RWTWA@isocpp.org>)
	id 1UhQ40-0001fs-RC
	for gclcip-std-proposals@m.gmane.org; Tue, 28 May 2013 22:00:09 +0200
Original-Received: by mail-ie0-f197.google.com with SMTP id s9sf2298725iec.4
        for <gclcip-std-proposals@m.gmane.org>; Tue, 28 May 2013 13:00:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.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=3C64KBO7CMyw+43fk7vv7u64FNNcMcdSSkyRYEZTkqk=;
        b=GGgT0EStXi67aBNmkTOwjTN/K1j4Zz3u1awJ9bcYczUBz1GIJVJhGTUL+VZLElPet+
         F+WfzVkw+rnMsv+w8/j3CfoqwAlea+R70X7YEViGev2pa/mscTb6d0OibA7OZdi/LXn3
         l4eUVgP38Q1yMyOyxAtrXkqomalXX0H3LMK+/1J/7If4aU9BczELBFd+YdTabI82yLkI
         pNO+duiTNV7EmQkU2Q2ZsKLePtGPRzx3Soq7F5Ofgv9IIuifcUkRMtQCcbggcmPBseGZ
         tWxXRtHNNtdhoDXWUvh7ObXhOtRFTxrIcvr7YoFHpMnYSO4yPJNSAPT2WsCxdOp7qbsr
         YAzg==
X-Received: by 10.42.49.72 with SMTP id v8mr25204177icf.3.1369771207905;
        Tue, 28 May 2013 13:00:07 -0700 (PDT)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.50.79.198 with SMTP id l6ls2882724igx.42.gmail; Tue, 28 May
 2013 13:00:06 -0700 (PDT)
X-Received: by 10.50.109.136 with SMTP id hs8mr1750673igb.8.1369771206757;
        Tue, 28 May 2013 13:00:06 -0700 (PDT)
In-Reply-To: <e59c2a57-6068-4098-8667-5d086b2961fd@isocpp.org>
X-Original-Sender: jmckesson@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?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:4677
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/4677>

------=_Part_860_17531738.1369771205667
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, May 28, 2013 9:33:07 AM UTC-7, DeadMG wrote:
>
> I don't believe it could break users- as far as I'm aware, the 
> vector<bool> specialization offers strictly less functionality than a real 
> vector<bool>.


Ignoring the space optimization issue (and `flip`), there is one place 
where vector<bool> has substantive differences from vector<T>: 
`vector<bool>::reference` and `vector<bool>::const_reference`.

For any other type `T`, `vector<T>::const_reference` is *required* to be a 
`const T&`. However, the standard requires `vector<bool>::const_reference` 
to be a `bool`, not a `const bool &`.

Of greater concern is the fact that `vector<bool>::reference` is *required*to be a specific inner class of `vector<bool>`, with specific behavior like 
a `flip` member function. If someone relies on being able to do this:

std::vector<bool> bvec{ ... };
bvec[2].flip();

That could be a problem. Especially since this is not an unreasonable use 
of the `vector<bool>` interface as it currently stands.

Personally, I agree with Howard; we should add a class that has all of this 
functionality (presumably with some degree of required sizing) that would 
be a drop-in replacement for those who need the sizing features of 
vector<bool>. But the question remains: even with a drop-in replacement, 
how much code will be *broken* because of this?

-- 

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

On Tuesday, May 28, 2013 9:33:07 AM UTC-7, DeadMG wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">I don't believe it could break users- as far as=
 I'm aware, the vector&lt;bool&gt; specialization offers strictly less func=
tionality than a real vector&lt;bool&gt;.</blockquote><div><br>Ignoring the=
 space optimization issue (and `flip`), there is one place where vector&lt;=
bool&gt; has substantive differences from vector&lt;T&gt;: `vector&lt;bool&=
gt;::reference` and `vector&lt;bool&gt;::const_reference`.<br><br>For any o=
ther type `T`, `vector&lt;T&gt;::const_reference` is <i>required</i> to be =
a `const T&amp;`. However, the standard requires `vector&lt;bool&gt;::const=
_reference` to be a `bool`, not a `const bool &amp;`.<br><br>Of greater con=
cern is the fact that `vector&lt;bool&gt;::reference` is <i>required</i> to=
 be a specific inner class of `vector&lt;bool&gt;`, with specific behavior =
like a `flip` member function. If someone relies on being able to do this:<=
br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, =
250); border-color: rgb(187, 187, 187); border-style: solid; border-width: =
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span s=
tyle=3D"color: #080;" class=3D"styled-by-prettify">&lt;bool&gt;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> bvec</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>bvec</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">[</span><span style=3D"color: #066;" class=3D"styled-by-prettify">2</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">].</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">flip</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">();</span></div></code></di=
v><br>That could be a problem. Especially since this is not an unreasonable=
 use of the `vector&lt;bool&gt;` interface as it currently stands.<br><br>P=
ersonally, I agree with Howard; we should add a class that has all of this =
functionality (presumably with some degree of required sizing) that would b=
e a drop-in replacement for those who need the sizing features of vector&lt=
;bool&gt;. But the question remains: even with a drop-in replacement, how m=
uch code will be <i>broken</i> because of this?<br></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_860_17531738.1369771205667--

.