220 31169 <4f3a70e6-0112-7c8e-8d22-aa2d0ddf2905@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 19:52:36 +0300 Lines: 35 Approved: news@gmane.org Message-ID: <4f3a70e6-0112-7c8e-8d22-aa2d0ddf2905@gmail.com> References: <38052307-8ef9-4d41-b902-826f56630c10@isocpp.org> <3fcee1aa-2092-20c0-ee9c-7b81f1f81d0f@gmail.com> <81ec3e8e-c380-416d-8f02-6f3c5180728f@isocpp.org> <8f092e67-d3d2-b1c2-a20a-6b4bcfd9417c@gmail.com> 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 1488127960 26744 195.159.176.226 (26 Feb 2017 16:52:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Feb 2017 16:52:40 +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+bncBCXY5TXHWYJRBVUPZTCQKGQETBGA7KI@isocpp.org Sun Feb 26 17:52:36 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f70.google.com ([209.85.215.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ci23l-0006Rn-Qf for gclcip-std-proposals@m.gmane.org; Sun, 26 Feb 2017 17:52:33 +0100 Original-Received: by mail-lf0-f70.google.com with SMTP id a198sf30054106lfb.6 for ; Sun, 26 Feb 2017 08:52:40 -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=gwX4ta8eTH0yQnrsZTPeFLj57KKp3vWVCxDgavLjDq8=; b=IvGl66rTBz5ppYk/m3PhSVp4+sVYlNhO/21R7+lWOuDWbTMHU4LlLJyNx8zfYlJ42N gZctG7DiX2GsGlFMYGV9mjjWqrM56EDZVODp1pmNqJaeJrDJSzev5dnGp3hNxcRUvWed QEs1FTdgmgA9nMXjx99yrwJ96WzN4MX85YhmJ2cfEp0EHi2OWEn015SoyHNREgT/SyfO 0eiQD+KalevL0r8zIck8Jd3H9N9Qf7x2mZF3aZPkrscYURPEx05nDysKUuszfawMEBZM Z1+iNHHO/+E8toGIWxKJ1Ix4yQJj+iPZZSOI5Ju4sO7vZqeflOYIaYu8VYSQhtnjoTCx 1M/Q== 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=gwX4ta8eTH0yQnrsZTPeFLj57KKp3vWVCxDgavLjDq8=; b=DAiCuWV2x7CdphKwh2Gicl2AVuOk5pfR91yICO3a7CvmXk36dZm1TLpXwI0e+o8rCa fArAbsK8+EMENwSFNrTy/A7a2ZeecmoUjsWgiWM6FDt1xymTs/9D8Gwz9gENUV6U4BIW wLaL5X3zaJ3SbC6L7K1pIplOf+XzOJNPXI2SsrYW4px/kzE0a+t+R/rxMUBxqdjCAHOb 2NOJWnuwJqf1T6V17EtYYNfgIEL5Zt6udT8EdWJRAsTPntv7LsuDqH2pjmjFp6Iwxxdv jB5rTyY4Y9ipe8VAWZx4WIxCiK3B0Xwuq7Bmiu4iUMxxYNtvUvDokYGCzadkCfMkkqea juVQ== X-Gm-Message-State: AMke39lTi0ezl7NBCZIUNo6m/wqcAVg7+DETA9i+P6YkzEmB5GiddM3K+8CaQL9XjqAUiw== X-Received: by 10.46.92.131 with SMTP id q125mr1327213ljb.15.1488127959970; Sun, 26 Feb 2017 08:52:39 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.46.33.152 with SMTP id h24ls356733lji.53.gmail; Sun, 26 Feb 2017 08:52:38 -0800 (PST) X-Received: by 10.46.13.2 with SMTP id 2mr3035693ljn.124.1488127958377; Sun, 26 Feb 2017 08:52:38 -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 p26si7598543lfg.126.2017.02.26.08.52.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Feb 2017 08:52:38 -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 z127so24884243lfa.2 for ; Sun, 26 Feb 2017 08:52:38 -0800 (PST) X-Received: by 10.46.1.5 with SMTP id 5mr375242ljb.52.1488127957688; Sun, 26 Feb 2017 08:52:37 -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 n142sm3336153lfb.34.2017.02.26.08.52.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Feb 2017 08:52:36 -0800 (PST) In-Reply-To: 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:31169 Archived-At: On 02/26/17 19:08, Nicol Bolas wrote: > On Sunday, February 26, 2017 at 10:24:19 AM UTC-5, Andrey Semashev wrote: > > 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. > > That would needlessly bloat the `vector`. After all, the `vector` still > needs its own 3 pointers. So it would have to have its own storage plus > the storage of the allocator. I'm not sure there's a way around that. The vector has to have the members required to obtain begin/end/size/capacity regardless of the source of the storage. If the storage comes from heap, the local storage becomes unused, however you implement the vector. -- 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/4f3a70e6-0112-7c8e-8d22-aa2d0ddf2905%40gmail.com. .