220 34066 <9824081e-169a-4f23-8938-bc10c048b0f8@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: FrankHB1989 Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: std::vector::expand_uninitialized Date: Tue, 22 Aug 2017 13:24:12 -0700 (PDT) Lines: 207 Approved: news@gmane.org Message-ID: <9824081e-169a-4f23-8938-bc10c048b0f8@isocpp.org> References: <405bc3a4-4fbf-41af-b213-b24894ba2f6e@isocpp.org> <0304ee31-d873-25a5-1ff9-3364e76dff67@gmail.com> <38511f1a-5d75-4c95-a240-89e19a03bbe6@isocpp.org> <2e2acdaf-58ae-4be9-a541-28d0291a09d4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8995_1787597092.1503433452933" X-Trace: blaine.gmane.org 1503433462 29085 195.159.176.226 (22 Aug 2017 20:24:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 22 Aug 2017 20:24:22 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCTJVBPG3QIBB3NF6LGAKGQETO5PWTY@isocpp.org Tue Aug 22 22:24:17 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f198.google.com ([209.85.223.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dkFib-0006uk-0g for gclcip-std-proposals@m.gmane.org; Tue, 22 Aug 2017 22:24:09 +0200 Original-Received: by mail-io0-f198.google.com with SMTP id k22sf1721897iod.5 for ; Tue, 22 Aug 2017 13:24:15 -0700 (PDT) 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=YW/BYsAkugHjpH/EuswN1O31zjYDoiXOV0JLyEerJN0=; b=sQ663NdQP4yvO2nDCbCfnkACkev1kJbsQHAkLHE5vsu/Zql22pD6HQeDFDbybzj4Jl YZ2qmUy6arMVrgxOi/IlITaRkpOTptsPERDz0Tfd9cjtz8iSc0hUe34B+ntQbehWThwh Tuihh59L65fRR+kazylKJnUpVUvwl0DOluKRZV5Q+XOc7Tfm6ApFunTZsWLYuVsNZT1b MAS7d7SRQ//g5YC2KXXwelpP1eu1/xg/YPuAKlSVjG9TJeU2e8W5iWlZh2KgwU726xym fRh4Vyc8gCC94gID3UX0ekql5mpeQ+JPxlPhk50CvHF3wiFfjQcZ18TncYvXocRngSX6 NmRA== 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=YW/BYsAkugHjpH/EuswN1O31zjYDoiXOV0JLyEerJN0=; b=mSr+Kvw54NPH6dMvL4GerzVAuzRXQfpwN6iwRCugOgM/+NKMeXkwcd5OYRhPfCRV6y POFXlVJfVF+ycH+kVY6qSG/i/X844DAgIp94SJDTWtOIWUBubpFBqkaDgMaOqq5Wsslv ZDSJ+JEpNxw7DrgztJ8//HFb6zUE3BP4yjfTaciFA718HK+q6P32cgx9E+ObBQbrdiT4 HLPwW5mXbyhYlTi/rWxFKFCkU80pMyScj8PqHAnD2gehQG4gAtxI9s7hG+qYcXxbt22r E9Ca90bOuk5k2CNGj+PZUtw8aO8gvT4P+gcLrfuA0UKNWvBaOaMI5+3JXafWoZwJq2gz MTsQ== 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=YW/BYsAkugHjpH/EuswN1O31zjYDoiXOV0JLyEerJN0=; b=R8DpPniaSOX3dbSqa0MlR5c096xDPmabEqa+kltMPdxusQ31ytuh5SrToKP9GuCQ+n n1Yofzq6u8zHWBqahuKC/q5OvawMsLPcl1+/IDFlMjwju8HFvycIfBau1IfDHgRXiPCa /b2QUycnj+3LS4/xTkooRaDUkQwqYX8wlVl000ofgQQtzXaEumsBJtH41l1RfEK8h9Da XCMTbt8JDFg3KRFZRsJ3NHqI0BvK7VBPfO8dOF7opQTHprSyTsxFAOZ+TMj/LI47xP9R IjY7Pv+iPDNtoZIGgpwT+Y5RfDmYe1Dx4O20WMaBFpOkZyvoMceCJ9l9oBGkkwnpO4Im aCBw== X-Gm-Message-State: AHYfb5gpgsMa80ACEyoX59rjiR/2++/lsV263+jOzspQfb1ZEC+8sKRf WpyF//FZ665Rkyum X-Received: by 10.36.17.19 with SMTP id 19mr548629itf.26.1503433455123; Tue, 22 Aug 2017 13:24:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.120.20 with SMTP id p20ls8385975itc.6.gmail; Tue, 22 Aug 2017 13:24:13 -0700 (PDT) X-Received: by 10.31.164.205 with SMTP id n196mr4514vke.22.1503433453479; Tue, 22 Aug 2017 13:24:13 -0700 (PDT) In-Reply-To: X-Original-Sender: frankhb1989@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:34066 Archived-At: ------=_Part_8995_1787597092.1503433452933 Content-Type: multipart/alternative; boundary="----=_Part_8996_905942304.1503433452933" ------=_Part_8996_905942304.1503433452933 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E5=9C=A8 2017=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC= +8=E4=B8=8B=E5=8D=8810:16:30=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A > > On Tuesday, August 22, 2017 at 5:42:56 AM UTC-4, FrankHB1989 wrote: >> >> =E5=9C=A8 2017=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C = UTC+8=E4=B8=8A=E5=8D=889:46:26=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC= =9A >>> >>> On Monday, August 21, 2017 at 9:19:46 PM UTC-4, Patrice Roy wrote: >>>> >>>> +1. Really looks like a reserve() use-case to me. >>>> >>>> 2017-08-21 4:29 GMT-04:00 Jonathan M=C3=BCller : >>>> >>>>> On 20.08.2017 22:22, Ryan Nicholl wrote: >>>>> >>>>>> My motivating example consists of a serialization routine. Ideally,= =20 >>>>>> the serialization routine would expand the vector uninitialized and = then=20 >>>>>> write the data in. This can't be done however, because the resize fu= nction=20 >>>>>> writes 0s to the data thanks to the default allocator's construct me= thod. >>>>>> >>>>> >>>>> Could you clarify why reserve + push_back() doesn't work here? >>>>> >>>> >>> I expect it's the reason he stated: he wants to prevent the value=20 >>> initialization of the object, since he's going to initialize it from th= e=20 >>> serialization routine. He wants to avoid the double-initialization. >>> >>> Again, that's a reason to allow default initialization, not to do what= =20 >>> he suggests.=20 >>> >> >> Why? Is it really necessary and intended to avoid uninitialized object= =20 >> owned by vector directly without allocator hacks and/or changing of elem= ent=20 >> types (which are both likely to cause a change on the container type) by= =20 >> design? >> > > It's not "necessary", in the sense that we could avoid it. I appreciate= =20 > the desire to address the problem; what I don't like is these particular= =20 > *means*. It effectively breaks `vector`, since its size would have to=20 > include objects that don't exist. Plus, C++ doesn't allow you to do point= er=20 > arithmetic across objects that don't exist. You can only do pointer=20 > arithmetic over arrays, and arrays require that all of their subobjects= =20 > actually are real, live objects. > You're right that it effectively breaks `vector` when there is no=20 initialization performed later, before these elements destroyed at the end= =20 of the lifetime of the vector. However, is there any real invariant to keep= =20 every element alive during the whole lifetime of the container object? For= =20 instance, what about something like an explicit destructor call and a=20 placement new expression to initialize a new element in the same location? > > Default initialization is a real process in C++ which creates real, live= =20 > objects. It can be used in placement new expressions; as such, there is n= o=20 > technical reason why default initialization cannot be used to solve this= =20 > problem. Those objects would actually exist, and therefore it wouldn't=20 > break the C++ object model or the meaning of `vector`. > The current issue is that there's no way to communicate that you *want*=20 > default initialization rather than value initialization. So let's fix=20 > *that*=20 > ,=20 > and the rest will take care of itself. > --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/9824081e-169a-4f23-8938-bc10c048b0f8%40isocpp.or= g. ------=_Part_8996_905942304.1503433452933 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=E5=9C=A8 2017=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98= =9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=8810:16:30=EF=BC=8CNicol Bolas= =E5=86=99=E9=81=93=EF=BC=9A
On Tuesday, August 22, 2017 at 5:42:56 AM UTC-4, FrankHB1989 = wrote:
=E5=9C=A8 20= 17=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A= =E5=8D=889:46:26=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
On Monday, August 21, 2017 at = 9:19:46 PM UTC-4, Patrice Roy wrote:
+1. Really looks like a reserve() use-case to me.

2017-08-21 4:29 GMT-04:00 Jonathan M= =C3=BCller <jonathanm...@gmail.com= >:
On 20.08.2017 22:2= 2, Ryan Nicholl wrote:
My motivating example consists of a serialization routine. Ideally, the ser= ialization routine would expand the vector uninitialized and then write the= data in. This can't be done however, because the resize function write= s 0s to the data thanks to the default allocator's construct method.

Could you clarify why reserve + push_back() doesn't work here?

I expect it's th= e reason he stated: he wants to prevent the value initialization of the obj= ect, since he's going to initialize it from the serialization routine. = He wants to avoid the double-initialization.

Again, that's a rea= son to allow default initialization, not to do what he suggests.
=

Why? Is it really necessary and inte= nded to avoid uninitialized object owned by vector directly without allocat= or hacks and/or changing of element types (which are both likely to cause a= change on the container type) by design?

= It's not "necessary", in the sense that we could avoid it. I = appreciate the desire to address the problem; what I don't like is thes= e particular means. It effectively breaks `vector`, since its size w= ould have to include objects that don't exist. Plus, C++ doesn't al= low you to do pointer arithmetic across objects that don't exist. You c= an only do pointer arithmetic over arrays, and arrays require that all of t= heir subobjects actually are real, live objects.
You're right that it effectively breaks `vector` when there is n= o initialization performed later, before these elements destroyed at the en= d of the lifetime of the vector. However, is there any real invariant to ke= ep every element alive during the whole lifetime of the container object? F= or instance, what about something like an explicit destructor call and a pl= acement new expression to initialize a new element in the same location?
<= br>Default initialization is a real process in C++ which creates real, live= objects. It can be used in placement new expressions; as such, there is no= technical reason why default initialization cannot be used to solve this p= roblem. Those objects would actually exist, and therefore it wouldn't b= reak the C++ object model or the meaning of `vector`.
The c= urrent issue is that there's no way to communicate that you want= default initialization rather than value initialization. So let's fix that, a= nd the rest will take care of itself.

--
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/9824081e-169a-4f23-8938-bc10c048b0f8= %40isocpp.org.
------=_Part_8996_905942304.1503433452933-- ------=_Part_8995_1787597092.1503433452933-- .