220 31159 <8f092e67-d3d2-b1c2-a20a-6b4bcfd9417c@gmail.com> article Path: news.gmane.org!.POSTED!not-for-mail From: Andrey Semashev Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Domains of specialized `vector` variance Date: Sun, 26 Feb 2017 18:24:13 +0300 Lines: 86 Approved: news@gmane.org Message-ID: <8f092e67-d3d2-b1c2-a20a-6b4bcfd9417c@gmail.com> References: <38052307-8ef9-4d41-b902-826f56630c10@isocpp.org> <3fcee1aa-2092-20c0-ee9c-7b81f1f81d0f@gmail.com> <81ec3e8e-c380-416d-8f02-6f3c5180728f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed X-Trace: blaine.gmane.org 1488122658 13749 195.159.176.226 (26 Feb 2017 15:24:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Feb 2017 15:24:18 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCXY5TXHWYJRBIHGZPCQKGQEAJZBLZY@isocpp.org Sun Feb 26 16:24:14 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f69.google.com ([209.85.215.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ci0gG-0002yI-B5 for gclcip-std-proposals@m.gmane.org; Sun, 26 Feb 2017 16:24:12 +0100 Original-Received: by mail-lf0-f69.google.com with SMTP id l6sf29559069lfb.2 for ; Sun, 26 Feb 2017 07:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=L0Ex21TEeSdo4Ea/JAVa1aVH0l1J88NRtDXB4fojyIA=; b=fwUtzkxStET0FS0pPfcDGUUymRZr7tJVqn1OogT/Tg7+nvb6imV9yzbtUxSDpCh2l6 88wbLbLHfZlEdVBFod1DauyFsN/dpx+nB+X4LhMKSYnceu8jSTOhd1yEJgwbFFZy+4P8 ERH/nSUvkDYDYRR0uY7NxPMoNm7k27AdmdK8OXpI0x6dL89tK0vRO5eudXP87d1+3N6J lhugWy7PIAOVvae+SPGQUT0nYZo+ogRUXC5Cv1D65cXkQvCFG8lF8NUaiyq5gY26/Tew SfeEitdlz6mJM8Ef7cMx34qBc6NQraohGOjGXbn8pA0OOyWN2wkQrnCsO8AlM4iOsPxF DpLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=L0Ex21TEeSdo4Ea/JAVa1aVH0l1J88NRtDXB4fojyIA=; b=C25mBL13XaXBzM9hsZMWonDin+Ud8VTUkSc7wv9inVsVEMwY7nCscdxD1Ebd7WsgCR XdDxtZjGvFEqm7bZVpm09wFsszfnLcStYPm7kNc/WAacfOUJAVU0lkXq2hmwKfG61LKs SdXlD+ylbcZRN6LJtD3iuO513V4xRjUBEt6V44oDf3+JNMSoH+gCJ16B+nbwA5AICk2g ISyIis1zh2cSN9CFMCShT/6LVoiE2vSctU20Xdq+Xh1UkSUE4duF4AxCGy70xMrxLSl+ ML0QNC+CJjQmKz2Y2ZiqChe1ydEf3bUKH92iyGILZEZpfXiKjlGuOdL6fFb9uEmlNxLe rR3g== X-Gm-Message-State: AMke39kvfQVDondoL2009jcpmlWfcAbJZTDAdvJd20f+R8nl4pxRxHkoEvugCDsa/EHElg== X-Received: by 10.46.92.131 with SMTP id q125mr1288461ljb.15.1488122658372; Sun, 26 Feb 2017 07:24:18 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.38.143 with SMTP id m137ls697093lfm.51.gmail; Sun, 26 Feb 2017 07:24:16 -0800 (PST) X-Received: by 10.46.8.82 with SMTP id g18mr3189951ljd.1.1488122656437; Sun, 26 Feb 2017 07:24:16 -0800 (PST) Original-Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com. [2a00:1450:4010:c07::22d]) by mx.google.com with ESMTPS id 103si7504357lfv.154.2017.02.26.07.24.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Feb 2017 07:24:16 -0800 (PST) Received-SPF: pass (google.com: domain of andrey.semashev@gmail.com designates 2a00:1450:4010:c07::22d as permitted sender) client-ip=2a00:1450:4010:c07::22d; Original-Received: by mail-lf0-x22d.google.com with SMTP id k202so10808072lfe.1 for ; Sun, 26 Feb 2017 07:24:16 -0800 (PST) X-Received: by 10.25.79.69 with SMTP id a5mr3470087lfk.58.1488122655723; Sun, 26 Feb 2017 07:24:15 -0800 (PST) Original-Received: from [192.168.1.2] (broadband-178-140-146-214.moscow.rt.ru. [178.140.146.214]) by smtp.googlemail.com with ESMTPSA id i20sm3284579ljb.0.2017.02.26.07.24.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Feb 2017 07:24:14 -0800 (PST) In-Reply-To: <81ec3e8e-c380-416d-8f02-6f3c5180728f@isocpp.org> X-Original-Sender: andrey.semashev@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of andrey.semashev@gmail.com designates 2a00:1450:4010:c07::22d as permitted sender) smtp.mailfrom=andrey.semashev@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:31159 Archived-At: On 02/26/17 17:44, Nicol Bolas wrote: > On Sunday, February 26, 2017 at 7:24:48 AM UTC-5, Andrey Semashev wrote: > > Personally, I don't see the benefit of unification of various > flavors of > vector under the common name. Having specialized names, actually, makes > more sense for code readability and searchability. I'm sure, it will > also be better for compile times as there's no need for metaprogramming > layer for sorting out policy template parameters. > > The benefit of putting them under a common name is not to have a common > name. It's to allow users to mix and match behavior as they see fit, > with /guaranteed/ interoperability. > > Here are all of the possibilities that someone might genuinely want: > > static_vector: compile-time maximum size, but allocates memory up to > that size. > static_small_vector: compile-time maximum size with an internal buffer > store. > dynamic_vector: runtime maximum size. > dynamic_small_vector: runtime maximum size with an internal buffer store. > vector: grows as needed. > small_vector: grows as needed, with an internal buffer store. > > Each of those combinations has just as much justification as the others. > An allocating `static_vector` really is useful in some cases; you want > it to allocate, but you don't want it to grow beyond that allocation. A > `static_small_vector` that stores its data internally is also useful; it > does no allocations. For the dynamic case, having small buffer > optimization is useful, but it's also useful to have guarantees of > pointer stability on move operations. And vector vs. small_vector is > similarly well understood. > > So it is clear that there is a need for each and every such combination. > And thus, we should have each and every one of those classes. But what > happens if we add another domain to that, like `stability` from > `boost:stable_vector`? Now all of a sudden, we need /twelve/ classes, > not 6. Why shouldn't someone be able to have a `static_stable_vector`? > Why not a `dynamic_small_stable_vector`? Thing is, some combinations are not possible or practical. For instance, `stable_vector` allocates each element separately, which would prohibit using a local storage for it. Well, you could preallocate storage for max number of elements *and* the table of pointers to them, but that's a different amount of storage than a different kind of `vector` would require, which means the user's code can't predict the amount of storage needed. And internally, these vectors may be very very different - so different in fact that the common name and interface would only complicate the implementation by having to dispatch between the different backends. This also means that anyone who needs only one of those backends must bring in the other ones as well as dependencies. > See the problem? The multiplicative explosion of vectors makes this > unworkable. This leaves us either with lots and lots of vector classes, > or we only provide the lowest common denominator: `vector`, > `small_vector`, `static_vector`, `dynamic_vector` and `stable_vector`. > No combinations of any of those features with each other. Well, I'm not convinced that every combination would be useful in practice, and that the problem you describe needs solving. I guess, if you limit your proposal to only allocation strategies, the ones from your list above, it would make more sense. But then I would rather see a different design based on allocators, something along these lines: template< typename T, typename... Allocators = std::allocator< T > > class multistorage_vector; template< typename T, typename Allocator = std::allocator< T > > using vector = multistorage_vector< T, Allocator >; The `multistorage_vector` container would attempt to use storage provided by the first allocator in the `Allocators` list that succeeds. This way one would be able to specify first an allocator with a static local buffer and then an allocator that uses heap. -- 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/8f092e67-d3d2-b1c2-a20a-6b4bcfd9417c%40gmail.com. .