220 4688 article Path: news.gmane.org!not-for-mail From: Tony V E Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Remove vector? Date: Tue, 28 May 2013 18:29:24 -0400 Lines: 133 Approved: news@gmane.org Message-ID: References:

<7371f4b8-8c47-4f17-af1e-902a5c8b17e4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=14dae9473ae321f93304ddcecc53 X-Trace: ger.gmane.org 1369780166 28509 80.91.229.3 (28 May 2013 22:29:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 May 2013 22:29:26 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCUZ5QWKNQIMLX4URUCRUBEGMSYYE@isocpp.org Wed May 29 00:29:27 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-fa0-f72.google.com ([209.85.161.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UhSOU-0000sg-VR for gclcip-std-proposals@m.gmane.org; Wed, 29 May 2013 00:29:27 +0200 Original-Received: by mail-fa0-f72.google.com with SMTP id v1sf6422977fav.11 for ; Tue, 28 May 2013 15:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:mime-version:in-reply-to:references:date:message-id :subject:from: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=61XjCsPRJXoQpGM6KeNavgx4hMc1Ph3FXkXX7KGpgO4=; b=gwJKYf83BXY4hWwRr7X7iW39yhDPTASnT7BG/Wv8spb7MTxLPeJLz8tvj7Z8Ipg8CC qAuxwK+QlDgGKq+fV0BZATgdTkNf7DIIkwARYomGFbumuG2p7eXHEUjuoTgCfD4/blbt B3ecY/gB5r83C2RnxoGi+t3NLL5C6nmHswzBnglGWkEI6NPkyzceQ5wK4QnK4YDWhayo I+rIeVPODN6Wq02YxPCBd9oFPX622+hwY2aklftSarTTcvI6basoCUCSn7SKpuOVwIY2 luUwfiV20Fb6kIFnjTUEjVmDVcFwsIw/NtmCEDlLbnpEgIb2zkxcBSI34l6ugItncWOd V36g== X-Received: by 10.112.34.225 with SMTP id c1mr129927lbj.2.1369780166055; Tue, 28 May 2013 15:29:26 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.170.133 with SMTP id am5ls204679lac.97.gmail; Tue, 28 May 2013 15:29:24 -0700 (PDT) X-Received: by 10.112.172.40 with SMTP id az8mr221143lbc.88.1369780164809; Tue, 28 May 2013 15:29:24 -0700 (PDT) Original-Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [2a00:1450:4010:c03::230]) by mx.google.com with ESMTPS id q6si10494283lah.241.2013.05.28.15.29.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 May 2013 15:29:24 -0700 (PDT) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 2a00:1450:4010:c03::230 as permitted sender) client-ip=2a00:1450:4010:c03::230; Original-Received: by mail-la0-f48.google.com with SMTP id fs12so7928034lab.21 for ; Tue, 28 May 2013 15:29:24 -0700 (PDT) X-Received: by 10.112.1.38 with SMTP id 6mr208022lbj.100.1369780164620; Tue, 28 May 2013 15:29:24 -0700 (PDT) Original-Received: by 10.112.161.9 with HTTP; Tue, 28 May 2013 15:29:24 -0700 (PDT) In-Reply-To: X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of tvaneerd@gmail.com designates 2a00:1450:4010:c03::230 as permitted sender) smtp.mail=tvaneerd@gmail.com; dkim=pass header.i=@gmail.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:4688 Archived-At: --14dae9473ae321f93304ddcecc53 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 28, 2013 at 4:12 PM, Howard Hinnant wrote: > On May 28, 2013, at 4:00 PM, Nicol Bolas wrote: > > > 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. But the question remains: even with a drop-in replacement, > how much 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 > specialization. /Somehow/ motivate people to migrate. > > Step 2: Not to be done for at least 5-10 years after Step 1, remove the > vector specialization. > > > 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 is > deprecated, and > B. As much code that actually cares that vector was specialized. > > Hopefully, little code will be broken. While I wouldn't dream of removing > auto_ptr today, I have the impression that the auto_ptr -> unique_ptr > migration is going well, thanks to the added sweetener unique_ptr has. > Removing auto_ptr for C++17 is a possibility. If not then, then maybe > C++2x. > > Howard > > I think (and maybe this was implied) we should also NOT add flip() to the otherwise-non-specialized future vector. ie we give users bit_vector with flip(), and do NOT try to help keep their current uses of vector compiling. It would be better for their code to stop compiling until they switch to bit_vector. Tony -- --- 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. --14dae9473ae321f93304ddcecc53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, May 28, 2013 at 4:12 PM, Howard Hinnant &= lt;howard.hin= nant@gmail.com> wrote:

On May 28, 2013, at 4:00 P= M, Nicol Bolas <jmckesson@gmail.c= om> wrote:

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

Model this after the auto_ptr -> unique_ptr transition:

Step 1: =A0Introduce bit_vector (or whatever) and deprecate the vector<b= ool> specialization. =A0/Somehow/ motivate people to migrate.

Step 2: =A0Not to be done for at least 5-10 years after Step 1, remove the = vector<bool> specialization.

> how much code will be broken because of this?

After Step 1, none.

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

=A0 =A0A. =A0Failed to migrate during the lengthy period that vector<boo= l> is deprecated, and
=A0 =A0B. =A0As much code that actually cares that vector<bool> was s= pecialized.

Hopefully, little code will be broken. =A0While I wouldn't dream of rem= oving auto_ptr today, I have the impression that the auto_ptr -> unique_= ptr migration is going well, thanks to the added sweetener unique_ptr has. = =A0Removing auto_ptr for C++17 is a possibility. =A0If not then, then maybe= C++2x.

Howard

I think (and maybe this was implied) we sho= uld also NOT add flip() to the otherwise-non-specialized future vector<b= ool>.=A0 ie we give users bit_vector with flip(), and do NOT try to help= keep their current uses of vector<bool> compiling.=A0 It would be be= tter for their code to stop compiling until they switch to bit_vector.

Tony

--

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

--14dae9473ae321f93304ddcecc53-- .