220 19920 article Path: news.gmane.org!not-for-mail From: "dgutson ." Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: First working prototype for static allocation: we can have complex containers in ROM Date: Wed, 19 Aug 2015 00:36:26 -0300 Lines: 142 Approved: news@gmane.org Message-ID: References: <5746104.njNQOLNdex@tjmaciei-mobl4> <1764803.DX92B0WFjc@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1140f16e48f14a051da1bd49 X-Trace: ger.gmane.org 1439955405 21034 80.91.229.3 (19 Aug 2015 03:36:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Aug 2015 03:36:45 +0000 (UTC) To: std-proposals Original-X-From: std-proposals+bncBDE3NBMV6UFBBOXTZ6XAKGQEPPK4ZNY@isocpp.org Wed Aug 19 05:36:28 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f69.google.com ([209.85.220.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZRuAu-0008R4-3d for gclcip-std-proposals@m.gmane.org; Wed, 19 Aug 2015 05:36:28 +0200 Original-Received: by pabyb7 with SMTP id yb7sf414846203pab.2 for ; Tue, 18 Aug 2015 20:36:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type: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=E74e9vTk4maRJ087pkVInq8K9A/It5COr9ACilhJhlQ=; b=Bi5EdPZWw2E2dxbDyck0tmX2238nFltl/ycRsCGZ/ERGiSRmJgky3GDSKL2DCOGgUs dXndahOSBbsbTLlaUWawHiMk90yKnHI6LlkXiUL465OobXZTZV/idWmHqebv2AhCqGYH 1s38LSRlEtlljc4ddLbPCFqqfiS1Mk/4j6EyPBGmVH6Gu8G/fbjducf/GW9bg0OamuMT UMm6oibz1PTjgBdY5X/KuDRv0OTSMxOydol8TaGcpXfDxHxm2pVkMG1l+B7iR44AQ0RH enAyHShWDjez/cGxN1fH4c7S5mMOnf4Xj5BcXVUDys3CR248NrXay56lt0C9jU5zlGyS 8/MA== X-Gm-Message-State: ALoCoQk3300T+Dx0ydQ4vV7kKRDxQn1NdNfXiqK/OJGyoubDxqdL7ySej4bl4cs1pgSLYPamgIBJ X-Received: by 10.67.3.40 with SMTP id bt8mr8504218pad.34.1439955387103; Tue, 18 Aug 2015 20:36:27 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.153.84 with SMTP id b81ls397906ioe.48.gmail; Tue, 18 Aug 2015 20:36:26 -0700 (PDT) X-Received: by 10.107.10.30 with SMTP id u30mr11934624ioi.7.1439955386318; Tue, 18 Aug 2015 20:36:26 -0700 (PDT) Original-Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com. [2607:f8b0:4001:c06::22e]) by mx.google.com with ESMTPS id t5si11225128igd.26.2015.08.18.20.36.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Aug 2015 20:36:26 -0700 (PDT) Received-SPF: pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:4001:c06::22e as permitted sender) client-ip=2607:f8b0:4001:c06::22e; Original-Received: by iodv127 with SMTP id v127so197216726iod.3 for ; Tue, 18 Aug 2015 20:36:26 -0700 (PDT) X-Received: by 10.107.154.199 with SMTP id c190mr10134257ioe.154.1439955386165; Tue, 18 Aug 2015 20:36:26 -0700 (PDT) Original-Received: by 10.36.116.147 with HTTP; Tue, 18 Aug 2015 20:36:26 -0700 (PDT) Original-Received: by 10.36.116.147 with HTTP; Tue, 18 Aug 2015 20:36:26 -0700 (PDT) In-Reply-To: X-Original-Sender: danielgutson@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:4001:c06::22e as permitted sender) smtp.mailfrom=danielgutson@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=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-Spam-Checked-In-Group: std-proposals@isocpp.org 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:19920 Archived-At: --001a1140f16e48f14a051da1bd49 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 19/8/2015 0:32, "Jeremy Maitin-Shepard" escribi=C3= =B3: > > On Tue, Aug 18, 2015 at 8:27 PM, dgutson . wrote= : > >> Please see my earlier post in this thread (the initial theorical version had "new" but then we implemented something named different so we could make the program ill formed when the context was not constexpr; OTOH, "new" is valid in both contexts; just a matter of self requirements). I consider this a point of decision (but not central and maybe worth to postpone). > > Would the usual constexpr annotation of the variable holding the result not serve this purpose? On the other hand, without a special allocator it might be hard for the compiler to ensure it ends up in a read-only data segment. > >> >> And I thought a little about the option that would make happy to us all: turn current containers static-alloc friendly. I think that in order for them to develop this double personality (or the personality disorder), methods should be able to be overloaded by ("strong") constexpr, including ctors, dtor (yes, two destructors) and other methods with something like "CVC-qualifiers" (meaning const, volatile, const volatile, and strong constexpr) with the usual name hiding rules (e.g. a strong constexpr ctor hides the implicit constructors unless explicited). I still have to think more about this and talk to my team to see if we could add this ability to the compiler prototype by defining some mean to annotate "strongness" for the constructor. > > This seems very useful as a general matter, but is there anything specific about the current containers that would require it? Random sleepy thoughts. Sorry, you are right, I'm addressing it wrongly. I should take the allocators path. I better go to sleep :) Thanks. > > > -- > > --- > 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. > Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --001a1140f16e48f14a051da1bd49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


El 19/8/2015 0:32, "Jeremy Maitin-Shepard" <jeremy@jeremyms.com> escribi=C3=B3:
>
> On Tue, Aug 18, 2015 at 8:27 PM, dgutson . <danielgutson@gmail.com> wrote:
>
>> Please see my earlier post in this thread (the initial theorical v= ersion had "new" but then we implemented something named differen= t so we could make the program ill formed when the context was not constexp= r; OTOH, "new" is valid in both contexts; just a matter of self r= equirements). I consider this a point of decision (but not central and mayb= e worth to postpone).
>
> Would the usual constexpr annotation of the variable holding the resul= t not serve this purpose?=C2=A0 On the other hand, without a special alloca= tor it might be hard for the compiler to ensure it ends up in a read-only d= ata segment.
> =C2=A0
>>
>> And I thought a little about the option that would make happy to u= s all: turn current containers static-alloc friendly. I think that in order= for them to develop this double personality (or the personality disorder),= methods should be able to be overloaded by ("strong") constexpr,= including ctors, dtor (yes, two destructors) and other methods with someth= ing like "CVC-qualifiers" (meaning const, volatile, const volatil= e, and strong constexpr) with the usual name hiding rules (e.g. a strong co= nstexpr ctor hides the implicit constructors unless explicited). I still ha= ve to think more about this and talk to my team to see if we could add this= ability to the compiler prototype by defining some mean to annotate "= strongness" for the constructor.
>
> This seems very useful as a general matter, but is there anything spec= ific about the current containers that would require it?

Random sleepy thoughts. Sorry, you are right, I'm addres= sing it wrongly. I should take the allocators path. I better go to sleep :)=
Thanks.

> =C2=A0
>
> --
>
> ---
> You received this message because you are subscribed to the Google Gro= ups "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.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propos= als/.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--001a1140f16e48f14a051da1bd49-- .