220 31194 <a9defa27-0579-4705-b1e8-075f47619046@isocpp.org> article
Path: news.gmane.org!.POSTED!not-for-mail
From: Marc <marc.glisse@gmail.com>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: Domains of specialized `vector` variance
Date: Mon, 27 Feb 2017 13:22:02 -0800 (PST)
Lines: 73
Approved: news@gmane.org
Message-ID: <a9defa27-0579-4705-b1e8-075f47619046@isocpp.org>
References: <38052307-8ef9-4d41-b902-826f56630c10@isocpp.org>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: blaine.gmane.org
Mime-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_1060_1292457284.1488230522534"
X-Trace: blaine.gmane.org 1488230526 6287 195.159.176.226 (27 Feb 2017 21:22:06 GMT)
X-Complaints-To: usenet@blaine.gmane.org
NNTP-Posting-Date: Mon, 27 Feb 2017 21:22:06 +0000 (UTC)
To: ISO C++ Standard - Future Proposals <std-proposals@isocpp.org>
Original-X-From: std-proposals+bncBCGJRE7HX4IBB65Q2LCQKGQEQIVLOFY@isocpp.org Mon Feb 27 22:22:01 2017
Return-path: <std-proposals+bncBCGJRE7HX4IBB65Q2LCQKGQEQIVLOFY@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-qk0-f198.google.com ([209.85.220.198])
	by blaine.gmane.org with esmtp (Exim 4.84_2)
	(envelope-from <std-proposals+bncBCGJRE7HX4IBB65Q2LCQKGQEQIVLOFY@isocpp.org>)
	id 1ciSk2-0000rJ-5D
	for gclcip-std-proposals@m.gmane.org; Mon, 27 Feb 2017 22:21:58 +0100
Original-Received: by mail-qk0-f198.google.com with SMTP id n127sf152246868qkf.3
        for <gclcip-std-proposals@m.gmane.org>; Mon, 27 Feb 2017 13:22:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=isocpp-org.20150623.gappssmtp.com; s=20150623;
        h=date:from:to:message-id:in-reply-to:references:subject:mime-version
         :x-original-sender:reply-to:precedence:mailing-list:list-id
         :x-spam-checked-in-group:list-post:list-help:list-archive
         :list-subscribe:list-unsubscribe;
        bh=9oIgy7AfqmF1HDLJhgDBOFUpMW64Qdww95mKjVK6pgQ=;
        b=P/IlSQX8xnqf8l+TypBqQ1GWd9ScEO+dn/EpwdJlNDGnzvh8aFvhHDl21uOFBhZUQ2
         4vqwPyin3YJ3ntpKdav+PBF1RFtRhwEoAUFXBJl7KOmE0z08J3jLIG2t3Vtxv/h4f46R
         6Jj/cHSpKh+0VUD34fpFvEQ1JEb/MVjFYmqRzbAlJ5/Z2o0xWOsPwqN6jfTy+pKG8bvg
         xKqYolKskmxvjiHg2MNTeQnWYyT1Bm8IvRR38HmFVdMrDr6Y9iZHbo4Pol49nlZhz1uN
         1xZdGI2KKT4gAu5iZDX8o7LroHiaKumMfT84UIyz5mUdDsF95n0WFUDh/yHVv94bCfkD
         i3RQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=date:from:to:message-id:in-reply-to:references:subject:mime-version
         :x-original-sender:reply-to:precedence:mailing-list:list-id
         :x-spam-checked-in-group:list-post:list-help:list-archive
         :list-subscribe:list-unsubscribe;
        bh=9oIgy7AfqmF1HDLJhgDBOFUpMW64Qdww95mKjVK6pgQ=;
        b=g6kn7icSRC7Gt8rNp8ntcq0ncpxJ3sx0JCbi3f4fxhqd3C2QZdC9IifACMjHOb6YVd
         kF+EpsR7XNqfX+gWxRhSk9W1toc/Dsm90PoGFNJXdlXrgesCZ17eGxyHtWvSQSdkuMEe
         v8yd80ADiasereKKAWIg28uVaYv1BIv+AFBeLdVpABCEnJlrJ5W7tWcPV11yKp8GHJcR
         JDkBBJx88pJtzBeagYV9oSCRLdWrrvoaChn0MYl+PvNnb1W3Vv3ccRuUJKt3vlLcsA8K
         WWIdpRTmLW/mu7owbYNYeGp/vTlKOj+0jLbrsLTrLtNLQqAPI9aEJu8UeFgENvNMkaKn
         Qhng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:date:from:to:message-id:in-reply-to:references
         :subject:mime-version:x-original-sender:reply-to:precedence
         :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help
         :list-archive:list-subscribe:list-unsubscribe;
        bh=9oIgy7AfqmF1HDLJhgDBOFUpMW64Qdww95mKjVK6pgQ=;
        b=PpldSCbuFR9k0J7u9qQGfFiIF6Su5olvYZzgQY6q3w1xd4qQkxPw/cAsRont66G/F5
         2JXOI/d5g8QBpd014ChdIqinpHk0jNxLGRusQcwLm9XUYZRr3k8HYPk+H8BGfqrwVZq6
         ceZFBERG7M2MtrdnjuBXyn4anRqmR/5TlVceF2qPJPwSO2J5xvzBRaU/VbirHyCaTdUL
         HlXGmg6LS2FAy7ftszxpM/+2iHMbin7jyx52sFEZiItgSyd31+ZME1D7XzlmbBINhJFG
         oD6RKRnVzXbyfIRA7t7j03CTu8AIKjqV6DE3TWVnyZLC17/Hzsp7gArpGkUzssN+jerT
         yQ3Q==
X-Gm-Message-State: AMke39nzF87G93e2PCLFqQBit02AlNQCQ2DtQBcyAH/IsF9a2DUNrUJzxbKSlHFhqSBXUg==
X-Received: by 10.200.53.25 with SMTP id y25mr5082871qtb.45.1488230523981;
        Mon, 27 Feb 2017 13:22:03 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.157.21.124 with SMTP id z57ls14934514otz.38.gmail; Mon, 27 Feb
 2017 13:22:03 -0800 (PST)
X-Received: by 10.157.32.161 with SMTP id x30mr1093037ota.20.1488230523231;
        Mon, 27 Feb 2017 13:22:03 -0800 (PST)
In-Reply-To: <38052307-8ef9-4d41-b902-826f56630c10@isocpp.org>
X-Original-Sender: marc.glisse@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: <https://groups.google.com/a/isocpp.org/group/std-proposals/post>, <mailto:std-proposals@isocpp.org>
List-Help: <https://support.google.com/a/isocpp.org/bin/topic.py?topic=25838>, <mailto:std-proposals+help@isocpp.org>
List-Archive: <https://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <https://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>,
 <https://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:31194
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/31194>

------=_Part_1060_1292457284.1488230522534
Content-Type: multipart/alternative; 
	boundary="----=_Part_1061_1017512527.1488230522534"

------=_Part_1061_1017512527.1488230522534
Content-Type: text/plain; charset=UTF-8

On Saturday, February 25, 2017 at 6:41:01 PM UTC+1, Nicol Bolas wrote:

> What are the other variances that people want?
>

A variant that I find useful is vector optimized for the empty case: the 
class contains just one pointer, which is 0 in the empty case, and 
otherwise points to a buffer that includes both the regular elements of the 
vector and size/capacity. IIRC mozilla also has a container like that (but 
limited to POD). I believe that is a valid implementation of std::vector, 
no functional difference, so it may be hard to specify such a variant...

For the variants you propose, whenever I've needed them, using 
std::vector<T, suitable_allocator> was close to what I needed (they were 
local variables so I didn't mind a couple unnecessary pointers), and it 
might make sense to try and fix those details (in particular let the 
allocator say how much memory it actually allocated, I think there is 
already a proposal about it).

-- 
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a9defa27-0579-4705-b1e8-075f47619046%40isocpp.org.

------=_Part_1061_1017512527.1488230522534
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, February 25, 2017 at 6:41:01 PM UTC+1, Nicol =
Bolas wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">What are the other variances that people want?<br></div></blockquote><di=
v><br>A variant that I find useful is vector optimized for the empty case: =
the class contains just one pointer, which is 0 in the empty case, and othe=
rwise points to a buffer that includes both the regular elements of the vec=
tor and size/capacity. IIRC mozilla also has a container like that (but lim=
ited to POD). I believe that is a valid implementation of std::vector, no f=
unctional difference, so it may be hard to specify such a variant...<br><br=
>For the variants you propose, whenever I&#39;ve needed them, using std::ve=
ctor&lt;T, suitable_allocator&gt; was close to what I needed (they were loc=
al variables so I didn&#39;t mind a couple unnecessary pointers), and it mi=
ght make sense to try and fix those details (in particular let the allocato=
r say how much memory it actually allocated, I think there is already a pro=
posal about it).<br></div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a9defa27-0579-4705-b1e8-075f47619046%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a9defa27-0579-4705-b1e8-075f47619046=
%40isocpp.org</a>.<br />

------=_Part_1061_1017512527.1488230522534--

------=_Part_1060_1292457284.1488230522534--

.
