220 4705 <51A638CF.5050905@wanadoo.fr> article
Path: news.gmane.org!not-for-mail
From: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: Remove vector<bool>?
Date: Wed, 29 May 2013 19:20:15 +0200
Lines: 176
Approved: news@gmane.org
Message-ID: <51A638CF.5050905@wanadoo.fr>
References: <CAGsORuDQdeWAO5yjA6=h0hW9Y0Sj4F1gcHB61udw5JFmtx+g4Q@mail.gmail.com> <CAGg_6+O9XJucMxwEhU+50Dzx0Tz7XRK0cWyrkUHuPSoEz9TqEw@mail.gmail.com> <e59c2a57-6068-4098-8667-5d086b2961fd@isocpp.org> <7371f4b8-8c47-4f17-af1e-902a5c8b17e4@isocpp.org> <FF769E17-643C-47FE-8A3E-D28436A4B9A6@gmail.com>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="------------080303080600050001080508"
X-Trace: ger.gmane.org 1369848021 1669 80.91.229.3 (29 May 2013 17:20:21 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Wed, 29 May 2013 17:20:21 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBDH67CONY4PBBU7RTCGQKGQEBVJPCRQ@isocpp.org Wed May 29 19:20:20 2013
Return-path: <std-proposals+bncBDH67CONY4PBBU7RTCGQKGQEBVJPCRQ@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-lb0-f200.google.com ([209.85.217.200])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBDH67CONY4PBBU7RTCGQKGQEBVJPCRQ@isocpp.org>)
	id 1Uhk2t-0000wl-UP
	for gclcip-std-proposals@m.gmane.org; Wed, 29 May 2013 19:20:19 +0200
Original-Received: by mail-lb0-f200.google.com with SMTP id w20sf7367100lbh.7
        for <gclcip-std-proposals@m.gmane.org>; Wed, 29 May 2013 10:20:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20120113;
        h=x-beenthere:message-id:date:from:user-agent:mime-version:to:subject
         :references:in-reply-to:x-original-sender
         :x-original-authentication-results:reply-to:precedence:mailing-list
         :list-id:x-google-group-id:list-post:list-help:list-archive
         :list-subscribe:list-unsubscribe:content-type;
        bh=IZpI5nYPXvh4RWd6PiOp/UPjEfEwtDrTuGTlfgwKccs=;
        b=RORCeA6kvoAZkkHvSdFYfVSGH5nf6nuFtXUEvi06MlYVXDha6sF2DFlhFM0kJL3G/P
         sfQmzJkPDXM7j6KUGy8gQYuSHBnD7Yfxz21ypAoqpUA2lcK1l+tYotrft39dYeTfeD3w
         /vI1U02GWSbNBSm1McT04yaVlrXbUv8lnjPZ55nOScAGVIRnTZKRC8Y6CEjNTdJJQgjr
         bczk5Vo2TxeEYGfcSu6DdVF54BlP0IPlXolExWQ73ruTs0mHfvrypT30f57VB3w79zVh
         3I/MXq7l5HUMgMAF7fCY99kWIYRiGw6aTPRVHpj7rB3Gmnff8XyUJkwPmkNRp9bILOab
         oLOw==
X-Received: by 10.180.76.76 with SMTP id i12mr1236022wiw.6.1369848019393;
        Wed, 29 May 2013 10:20:19 -0700 (PDT)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.180.86.194 with SMTP id r2ls1576377wiz.35.canary; Wed, 29 May
 2013 10:20:18 -0700 (PDT)
X-Received: by 10.15.10.4 with SMTP id f4mr4988692eet.33.1369848018368;
        Wed, 29 May 2013 10:20:18 -0700 (PDT)
Original-Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr. [80.12.242.130])
        by mx.google.com with ESMTP id z42si21427609eel.178.2013.05.29.10.20.18
        for <std-proposals@isocpp.org>;
        Wed, 29 May 2013 10:20:18 -0700 (PDT)
Received-SPF: neutral (google.com: 80.12.242.130 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.130;
Original-Received: from pc4.home ([2.11.193.225])
	by mwinf5d43 with ME
	id htLF1l00b4sEqES03tLFBf; Wed, 29 May 2013 19:20:18 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
In-Reply-To: <FF769E17-643C-47FE-8A3E-D28436A4B9A6@gmail.com>
X-Original-Sender: vicente.botet@wanadoo.fr
X-Original-Authentication-Results: mx.google.com;       spf=neutral
 (google.com: 80.12.242.130 is neither permitted nor denied by best guess
 record for domain of vicente.botet@wanadoo.fr) smtp.mail=vicente.botet@wanadoo.fr
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:4705
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/4705>

This is a multi-part message in MIME format.
--------------080303080600050001080508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 28/05/13 22:12, Howard Hinnant a =E9crit :
> On May 28, 2013, at 4:00 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> Personally, I agree with Howard; we should add a class that has all of t=
his functionality (presumably with some degree of required sizing) that wou=
ld be a drop-in replacement for those who need the sizing features of vecto=
r<bool>. But the question remains: even with a drop-in replacement, how muc=
h code will be broken because of this?
> Model this after the auto_ptr -> unique_ptr transition:
>
> Step 1:  Introduce bit_vector (or whatever) and deprecate the vector<bool=
> specialization.  /Somehow/ motivate people to migrate.
I think that we will need also to add a std::*new_*vector<T> that=20
behaves like std::vector<T> but doesn't have the bool specialization and=20
*deprecate* std::vector :->
The name of the class and the namespace could have their importance.=20
Maybe if we had a multi-vector that  was as efficient as a vector the=20
name could be multi_vector<T>. Just an idea.
>
> Step 2:  Not to be done for at least 5-10 years after Step 1, remove the =
vector<bool> specialization.
Remove the std::vector<T> from the standard.
>> how much code will be broken because of this?
> After Step 1, none.
>
> After Step 2, as much code as there is that:
>
>     A.  Failed to migrate during the lengthy period that vector<bool> is =
deprecated, and
>     B.  As much code that actually cares that vector<bool> was specialize=
d.
Maybe a lot of, but, not silently.
> Hopefully, little code will be broken.  While I wouldn't dream of removin=
g auto_ptr today, I have the impression that the auto_ptr -> unique_ptr mig=
ration is going well, thanks to the added sweetener unique_ptr has.  Removi=
ng auto_ptr for C++17 is a possibility.  If not then, then maybe C++2x.
>
> Howard
>
Yes, this could seem heretical, but this is the only path I see that=20
could allow a smooth migration and a non silent drop of the unwanted=20
std::vector<bool>.

Best,
Vicente

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



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

<html>
  <head>
    <meta content=3D"text/html; charset=3DISO-8859-1"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 28/05/13 22:12, Howard Hinnant a
      &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
      cite=3D"mid:FF769E17-643C-47FE-8A3E-D28436A4B9A6@gmail.com"
      type=3D"cite">
      <pre wrap=3D"">On May 28, 2013, at 4:00 PM, Nicol Bolas <a class=3D"m=
oz-txt-link-rfc2396E" href=3D"mailto:jmckesson@gmail.com">&lt;jmckesson@gma=
il.com&gt;</a> wrote:

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">Personally, I agree with Howard; we should add a cla=
ss that has all of this functionality (presumably with some degree of requi=
red sizing) that would be a drop-in replacement for those who need the sizi=
ng features of vector&lt;bool&gt;. But the question remains: even with a dr=
op-in replacement, how much code will be broken because of this?
</pre>
      </blockquote>
      <pre wrap=3D"">
Model this after the auto_ptr -&gt; unique_ptr transition:

Step 1:  Introduce bit_vector (or whatever) and deprecate the vector&lt;boo=
l&gt; specialization.  /Somehow/ motivate people to migrate.</pre>
    </blockquote>
    I think that we will need also to add a std::<b>new_</b>vector&lt;T&gt;
    that behaves like std::vector&lt;T&gt; but doesn't have the bool
    specialization and <b>deprecate</b> std::vector :-&gt;<br>
    The name of the class and the namespace could have their importance.
    Maybe if we had a multi-vector that&nbsp; was as efficient as a vector
    the name could be multi_vector&lt;T&gt;. Just an idea. <br>
    <blockquote
      cite=3D"mid:FF769E17-643C-47FE-8A3E-D28436A4B9A6@gmail.com"
      type=3D"cite">
      <pre wrap=3D"">

Step 2:  Not to be done for at least 5-10 years after Step 1, remove the ve=
ctor&lt;bool&gt; specialization.
</pre>
    </blockquote>
    Remove the std::vector&lt;T&gt; from the standard.<br>
    <blockquote
      cite=3D"mid:FF769E17-643C-47FE-8A3E-D28436A4B9A6@gmail.com"
      type=3D"cite">
      <pre wrap=3D"">
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">how much code will be broken because of this?
</pre>
      </blockquote>
      <pre wrap=3D"">
After Step 1, none.

After Step 2, as much code as there is that:

   A.  Failed to migrate during the lengthy period that vector&lt;bool&gt; =
is deprecated, and
   B.  As much code that actually cares that vector&lt;bool&gt; was special=
ized.
</pre>
    </blockquote>
    Maybe a lot of, but, not silently.<br>
    <blockquote
      cite=3D"mid:FF769E17-643C-47FE-8A3E-D28436A4B9A6@gmail.com"
      type=3D"cite">
      <pre wrap=3D"">
Hopefully, little code will be broken.  While I wouldn't dream of removing =
auto_ptr today, I have the impression that the auto_ptr -&gt; unique_ptr mi=
gration is going well, thanks to the added sweetener unique_ptr has.  Remov=
ing auto_ptr for C++17 is a possibility.  If not then, then maybe C++2x.

Howard

</pre>
    </blockquote>
    Yes, this could seem heretical, but this is the only path I see that
    could allow a smooth migration and a non silent drop of the unwanted
    std::vector&lt;bool&gt;.<br>
    <br>
    Best,<br>
    Vicente<br>
  </body>
</html>

<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 />

--------------080303080600050001080508--

.