220 31155 <81ec3e8e-c380-416d-8f02-6f3c5180728f@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Domains of specialized `vector` variance Date: Sun, 26 Feb 2017 06:44:57 -0800 (PST) Lines: 218 Approved: news@gmane.org Message-ID: <81ec3e8e-c380-416d-8f02-6f3c5180728f@isocpp.org> References: <38052307-8ef9-4d41-b902-826f56630c10@isocpp.org> <3fcee1aa-2092-20c0-ee9c-7b81f1f81d0f@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4139_677269076.1488120297200" X-Trace: blaine.gmane.org 1488120309 10920 195.159.176.226 (26 Feb 2017 14:45:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Feb 2017 14:45:09 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB2WTZPCQKGQERCBJCPY@isocpp.org Sun Feb 26 15:45:01 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ci04D-0001SF-1P for gclcip-std-proposals@m.gmane.org; Sun, 26 Feb 2017 15:44:53 +0100 Original-Received: by mail-yw0-f199.google.com with SMTP id 204sf61604983ywo.6 for ; Sun, 26 Feb 2017 06:44:59 -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=OD9+pk68q2e3CPPCGgABXaemoFNhHixa+l9GeuDv2x4=; b=mPwM2BgZPiZda+xj/KU+5nfHnBmDUPG61AUOZkyRajr9seppqc27vOzkpXGhn3tytC WjOmknAx+gBJQvaCoQLeGYraJ4f+ZFLaJQu9DhnRd15SGC4elWA56nzRATEfKlECKBxj Z4RyYO636VUUOqA8s+yCxo0QVF+Rx3+c4PvnsaU3pCkReqaCpK581akREEgOtfzU3EA3 Iqyk/G4sOL7vCDDqqWnukRtxLJwOjJih0QnzMeXqW2XO5RGZ0ew8IRoLtZ54ZEfTW3eW 8V8gx7CXAZ3nvfCE1YCCX+xb6Se34N2VU6d/zBNVWKLipp8zNO4N7Nm9M57DtybnciTI Z4BA== 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=OD9+pk68q2e3CPPCGgABXaemoFNhHixa+l9GeuDv2x4=; b=R3Xog8HDzJiXlCXZyOqCFf3mAulOqSKXKq57cb6exAay0TdOxyJcdro/8kSHXxerhV vTm4QnbqisSvBH37fctt/PzLIW1/iI9Vw66typnm71E9KETIbPRsy4PAHFifCiB6w6FI i6+T+5pc37mAD+4puOsNrTT+a75Xwl2dpk3UlsobrTQ7xta7K+sQHeR1cnSABAutW9VN dZxjuVmpZmIDkg1T3Py1W15zw/USI02Afv7PjQSFjhstDY5mqXP56PVJFefrMp4cr4Cq AyYCFK85D5Wv5DmyDHU0YEP2tNAthVKkk8YhVT8jbgNhUUQx763SqDpjRwx4cdhVX+Gf zfpg== 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=OD9+pk68q2e3CPPCGgABXaemoFNhHixa+l9GeuDv2x4=; b=moG+tJhy8Hqgxzf9S+gbHJK4RJqcf3CRx42PBWMZRS2MR2IGn5KULVBlUe4ggIKpT5 MNlgG7NrRFCGagmIfgztqyZrSUcnGnXQW3jZOvobiX3q5HRsF1g4jmAt0V6Vm+CLvgk2 hk9UaBFsqdszF8J+DXRv6HW9YHQWpA6bwo+wx7gSvG5hw4sUxQ0/3SAHrMUaAoGWYalY hnCKi0xRRdIjvEu4PyV8wu0zCuF/gBLeA1LcU4nFxcS4LjyTT4h1xL9SxlUdfEg2ccNR d2hULAos91zEz12Pp57ijesqr0CwjsqwzTkLEvdxKJAOdc1e/tHIEzdUMIZXaaZIUIuZ 3LMA== X-Gm-Message-State: AMke39lF8mcqBjhY/kdK2+n7V0piCuvp0chHYxRiGixMWwcuZyVeyEjQf7EtLfFDZbecpw== X-Received: by 10.129.141.69 with SMTP id w5mr4637355ywj.64.1488120298710; Sun, 26 Feb 2017 06:44:58 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.5.176 with SMTP id 45ls2337444otd.37.gmail; Sun, 26 Feb 2017 06:44:57 -0800 (PST) X-Received: by 10.157.32.3 with SMTP id n3mr744439ota.1.1488120297904; Sun, 26 Feb 2017 06:44:57 -0800 (PST) In-Reply-To: <3fcee1aa-2092-20c0-ee9c-7b81f1f81d0f@gmail.com> X-Original-Sender: jmckesson@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:31155 Archived-At: ------=_Part_4139_677269076.1488120297200 Content-Type: multipart/alternative; boundary="----=_Part_4140_244571798.1488120297200" ------=_Part_4140_244571798.1488120297200 Content-Type: text/plain; charset=UTF-8 On Sunday, February 26, 2017 at 7:24:48 AM UTC-5, Andrey Semashev wrote: > > On 02/25/17 20:41, Nicol Bolas wrote: > > There have been a lot of proposals and ideas thrown about for various > > `vector` classes that have identical interfaces but different behaviors. > > I'm wondering if it might not be better to have them all aggregated into > > some `omni_vector` type that uses a template parameter to pick which > > particular options you want. > > > > A necessary first step is to figure out what all of the options such an > > `omni_vector` might provide. Here are the ones I know about: > > > > * Small storage buffer (SSB) space: 0 to arbitrary number. > > * Maximum size: compile-time > > static/runtime-upon-construction/always-unbounded > > > > One of the advantages of having all of these variances in one type is to > > more easily require movement between them. So an `omni_vector` with > > SSB/16 and an `omni_vector` that has no SSB but has a fixed size can > > still be efficiently moved between so long as the allocators are the > > same (and if the SSB vector's current size is greater than its SSB > size). > > > > Also, by putting them all in one type, you can create useful > > combinations. Like a vector that never allocates memory, because the SSB > > size is equal to the compile-time maximum size. > > > > Instantiating such a type might look like this: `omni_vector > ov_params, ov_max_static<32>>`. The order of such parameters > > would not be fixed; it would use template metaprogramming to pick the > > first parameter from the list for a particular option. > > > > What are the other variances that people want? > > As a reference, see a few vector variants provided by Boost.Container: > > > http://www.boost.org/doc/libs/1_63_0/doc/html/container/non_standard_containers.html > > 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`? 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. -- 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/81ec3e8e-c380-416d-8f02-6f3c5180728f%40isocpp.org. ------=_Part_4140_244571798.1488120297200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sunday, February 26, 2017 at 7:24:48 AM UTC-5, = Andrey Semashev wrote:
On 02/25= /17 20:41, Nicol Bolas wrote:
> There have been a lot of proposals and ideas thrown about for vari= ous
> `vector` classes that have identical interfaces but different beha= viors.
> I'm wondering if it might not be better to have them all aggre= gated into
> some `omni_vector` type that uses a template parameter to pick whi= ch
> particular options you want.
>
> A necessary first step is to figure out what all of the options su= ch an
> `omni_vector` might provide. Here are the ones I know about:
>
> * Small storage buffer (SSB) space: 0 to arbitrary number.
> * Maximum size: compile-time
> static/runtime-upon-construction/always-unbounded
>
> One of the advantages of having all of these variances in one type= is to
> more easily require movement between them. So an `omni_vector` wit= h
> SSB/16 and an `omni_vector` that has no SSB but has a fixed size c= an
> still be efficiently moved between so long as the allocators are t= he
> same (and if the SSB vector's current size is greater than its= SSB size).
>
> Also, by putting them all in one type, you can create useful
> combinations. Like a vector that never allocates memory, because t= he SSB
> size is equal to the compile-time maximum size.
>
> Instantiating such a type might look like this: `omni_vector<Ty= pename,
> ov_params<ov_ssb<32>, ov_max_static<32>>`. The o= rder of such parameters
> would not be fixed; it would use template metaprogramming to pick = the
> first parameter from the list for a particular option.
>
> What are the other variances that people want?

As a reference, see a few vector variants provided by Boost.Container:

http://www.boost.org/doc/libs/<= wbr>1_63_0/doc/html/container/non_standard_containers.html

Personally, I don't see the benefit of unification of various flavo= rs of=20
vector under the common name. Having specialized names, actually, makes= =20
more sense for code readability and searchability. I'm sure, it wil= l=20
also be better for compile times as there's no need for metaprogram= ming=20
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, w= ith guaranteed interoperability.

Here are all of the possibil= ities 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_vecto= r: runtime maximum size.
dynamic_small_vector: runtime maximum size with= an internal buffer store.
vector: grows as needed.
small_vector: gro= ws as needed, with an internal buffer store.

Each of those combinati= ons has just as much justification as the others. An allocating `static_vec= tor` really is useful in some cases; you want it to allocate, but you don&#= 39;t want it to grow beyond that allocation. A `static_small_vector` that s= tores its data internally is also useful; it does no allocations. For the d= ynamic case, having small buffer optimization is useful, but it's also = useful to have guarantees of pointer stability on move operations. And vect= or vs. small_vector is similarly well understood.

So it is clear tha= t 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 anothe= r 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_vec= tor`?

See the problem? The multiplicative explosion of vectors makes= this unworkable. This leaves us either with lots and lots of vector classe= s, or we only provide the lowest common denominator: `vector`, `small_vecto= r`, `static_vector`, `dynamic_vector` and `stable_vector`. No combinations = of any of those features with each other.

--
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-proposa= ls+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/81ec3e8e-c380-416d-8f02-6f3c5180728f= %40isocpp.org.
------=_Part_4140_244571798.1488120297200-- ------=_Part_4139_677269076.1488120297200-- .