220 4706 article Path: news.gmane.org!not-for-mail From: Nevin Liber Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Remove vector? Date: Wed, 29 May 2013 12:37:19 -0500 Lines: 158 Approved: news@gmane.org Message-ID: References:

<7371f4b8-8c47-4f17-af1e-902a5c8b17e4@isocpp.org> <51A638CF.5050905@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=14dae9d70f8cc1401504ddded7fb X-Trace: ger.gmane.org 1369849081 14289 80.91.229.3 (29 May 2013 17:38:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 May 2013 17:38:01 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCE35H5S6IDBB6HZTCGQKGQE5Q34UKQ@isocpp.org Wed May 29 19:38:01 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gh0-f200.google.com ([209.85.160.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UhkK1-0006MB-ED for gclcip-std-proposals@m.gmane.org; Wed, 29 May 2013 19:38:01 +0200 Original-Received: by mail-gh0-f200.google.com with SMTP id 10sf10401869ghy.7 for ; Wed, 29 May 2013 10:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:mime-version:sender:in-reply-to:references:from:date :message-id:subject: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=mpat52aeY/yLt+4kOUL1oZK52LYVscqQaoUTmJe7omE=; b=jRCXOMLg4bQY03W5mDzf7/bbdP7TTHI6K7WMAE57B2wg/rMVyxyAaQ+939/rOj99Nq wKM+7yn+GGHORvCT7KjmUT6O0ZTKkqlHTQpZRCKnnzbg8xODUPC2rCaKnEoINqirQ3T3 rd3dEd057iYtE2n2oIbuFlVit7lT6EscvGo09AExVdgt97eeRe79nOeouKEVkR9BudyS 4gGOcE+wxwn77zI+9CbttYv4ymuayFG7veghfR/kFjhOfQxaGcDRoqpCPP0QMGTHwGnQ MtPbgIwkuJuoUAULtrEkUvtP0mxXKOjSj/THV1SpHMkG8g4XUlRXJrlzFHrUTSNu6Mpr YUbg== X-Received: by 10.224.59.205 with SMTP id m13mr2154977qah.7.1369849080482; Wed, 29 May 2013 10:38:00 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.108.201 with SMTP id hm9ls1404374qeb.65.gmail; Wed, 29 May 2013 10:37:59 -0700 (PDT) X-Received: by 10.229.124.80 with SMTP id t16mr1328738qcr.93.1369849079422; Wed, 29 May 2013 10:37:59 -0700 (PDT) Original-Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by mx.google.com with ESMTPS id e9si12513421qag.44.2013.05.29.10.37.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 10:37:59 -0700 (PDT) Received-SPF: pass (google.com: domain of nliber@gmail.com designates 209.85.128.47 as permitted sender) client-ip=209.85.128.47; Original-Received: by mail-qe0-f47.google.com with SMTP id f6so4399729qej.34 for ; Wed, 29 May 2013 10:37:59 -0700 (PDT) X-Received: by 10.229.22.138 with SMTP id n10mr1382823qcb.84.1369849079083; Wed, 29 May 2013 10:37:59 -0700 (PDT) Original-Sender: nliber@gmail.com Original-Received: by 10.49.64.165 with HTTP; Wed, 29 May 2013 10:37:19 -0700 (PDT) In-Reply-To: <51A638CF.5050905@wanadoo.fr> X-Original-Sender: nevin@eviloverlord.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of nliber@gmail.com designates 209.85.128.47 as permitted sender) smtp.mail=nliber@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:4706 Archived-At: --14dae9d70f8cc1401504ddded7fb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 29 May 2013 12:20, Vicente J. Botet Escriba wr= ote: > Le 28/05/13 22:12, Howard Hinnant a =E9crit : > > 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 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. 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 specialization. /Somehow/ motivate people to migrate. > > I think that we will need also to add a std::*new_*vector that > behaves like std::vector but doesn't have the bool specialization and = * > deprecate* std::vector :-> > -100. * Annoying 99% of all C++ users is a horrible, horrible idea. * I'd hate to use a code base that had two different, unrelated types for doing the exact same thing, since ultimately these things end up interfaces. Actually, I already have that, as people are trying to migrate from Boost over to std (such as shared_ptr), and it is anything but easy (because we are dependent on libraries developed for/by other groups, and changing those interfaces is a scheduling nightmare). I like Howard's plan, as we not only don't leave current users of vector out in the cold but we give them incentive to move, as well as "fixing up" vector (although I'd still like to see some actual use cases for the non-specialized vector). The part I disagree with is the timeframe; we only have to wait one standard cycle of having the current vector deprecated before removing the specialization. The only promise we make to users about deprecated features is in n3690 Dp2: "These are deprecated features, where deprecated is defined as: Normative for the current edition of the Standard, but having been identified as a candidate for removal from future revisions." Of course, getting the Committee to actually remove deprecated libraries is a whole different issue... (And auto_ptr needs to go, even if library vendors decide to keep it around forever, because it appears in other interfaces in the Standard.) --=20 Nevin ":-)" Liber (847) 691-1404 --=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. --14dae9d70f8cc1401504ddded7fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 29 May 2013 12:20, Vicente J. Botet Escriba <vicente.botet@wanad= oo.fr> wrote:

=20 =20 =20
Le 28/05/13 22:12, Howard Hinnant a =E9crit=A0:
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 ha=
s all of this functionality (presumably with some degree of required sizing=
) that would be a drop-in replacement for those who need the sizing feature=
s of vector<bool>. But the question remains: even with a drop-in repl=
acement, 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<boo=
l> specialization.  /Somehow/ motivate people to migrate.
I think that we will need also to add a std::new_vector<T> that behaves like std::vector<T> but doesn't have the bool specialization and deprecate std::vector :->
-100.

* Annoying 99% of all C++ users is a horrible, = horrible idea.

* I'd hate to use a code base that had two differ= ent, unrelated types for doing the exact same thing, since ultimately these= things end up interfaces.=A0 Actually, I already have that, as people are = trying to migrate from Boost over to std (such as shared_ptr), and it is an= ything but easy (because we are dependent on libraries developed for/by oth= er groups, and changing those interfaces is a scheduling nightmare).

I like Howard's plan, as we not only don't leave current users = of vector<bool> out in the cold but we give them incentive to move, a= s well as "fixing up" vector (although I'd still like to see = some actual use cases for the non-specialized vector<bool>).

The part I disagree with is the timeframe; we only have to wait one sta= ndard cycle of having the current vector<bool> deprecated before remo= ving the specialization.=A0 The only promise we make to users about depreca= ted features is in n3690 Dp2: "These are deprecated features, where de= precated is defined as: Normative for the current edition of the Standard, = but having been identified as a candidate for removal from future revisions= .."=A0 Of course, getting the Committee to actually remove deprecated l= ibraries is a whole different issue...

(And auto_ptr needs to go, even if library vendors decide to keep it ar= ound forever, because it appears in other interfaces in the Standard.)

--
=A0Nevin ":-)" Liber=A0 <mailt= o:nevin@evilove= rlord.com>=A0 (847) 691-1404

--

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

--14dae9d70f8cc1401504ddded7fb-- .