220 35389 <6e752115-7aea-4c5a-87fc-80940af8d607@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Myriachan Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: On P0829 - a freestanding implementation Date: Fri, 17 Nov 2017 13:09:31 -0800 (PST) Lines: 160 Approved: news@gmane.org Message-ID: <6e752115-7aea-4c5a-87fc-80940af8d607@isocpp.org> References: <32147114.z48B4pQc9d@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_352_2070688029.1510952971672" X-Trace: blaine.gmane.org 1510952972 23244 195.159.176.226 (17 Nov 2017 21:09:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 17 Nov 2017 21:09:32 +0000 (UTC) Cc: ben.craig@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDKLT4PURQHRBDFAXXIAKGQEGO6D42Q@isocpp.org Fri Nov 17 22:09:28 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFnt8-0005cl-Oy for gclcip-std-proposals@m.gmane.org; Fri, 17 Nov 2017 22:09:27 +0100 Original-Received: by mail-vk0-f69.google.com with SMTP id o196sf2065643vkf.4 for ; Fri, 17 Nov 2017 13:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=fMW0hFYXr14+HrQGMpDfCmbBwLhAYo48VxmVO3a3cXk=; b=qV4y/MyKjdQ6XBgT2C5x9/+3i52XTVdqLmt/SOA4NLqFLuJEOyneyq9C2P6/iYw3ZL h/VLryfEGeezgomCEob/RLbD9BFFeRoLKdUrmH/IOBuJ7XRNYwettAnA2k+Ekb4J/z11 DzBVd/l+2xbjkGjDZLw9ZGmWS3WegEqgVHeB+uXQRzU7dqH8kmKMV+EHK2YUFW5Z8icc QdWY0U0MaTCEEpGRCHzloTG854z96ZSjkURZJiR9ogHlp6pAvpKcQoO8rkZCDHAam8vd 6u6+MEOTqUJHIscGf/rwV8NODEfC07E7TVoIcXzb7jD0DM7n2OS0Pr3RKh/0pe8wulgX 8r+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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=fMW0hFYXr14+HrQGMpDfCmbBwLhAYo48VxmVO3a3cXk=; b=eCCbiaLqXzf8nzw1KHuMSdpueiltvaMgjZ63gbksdPnYr2Nw6bSNKR+ZJhtGBa6VON ehPJ4aOrysfS5DyTLw1df4ZKVIG7wOTijY1rkL0XkNnRJRHMFKd3RAUEwTaBnnu81iZY UrFv4arkU48h6QVpfPQXI7REnKhlUDSYzHqxPd0us18gqX4E1IYT/AU4SMuNaG0i2RSu ypIT1RRlvyXLzGt+rHgiD6j7uz9iQ/xMn1sWQhgrRbUoJ/PHB4/7prWLElRLq3Va9QTQ Yasw8jKLaqDttEXId6iiT1qFyO/SwbC3CTZSsJv2qZnxBWXPnDYhLbWE+GyXaXBrOV9A /37Q== 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:cc: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=fMW0hFYXr14+HrQGMpDfCmbBwLhAYo48VxmVO3a3cXk=; b=GaIc19v7mJzKBVIgp0cxoCPyY5BG2cSdHsqOGqbr4sBlYAGZj/DQS3iZevVkPKWNFw qZKgVIXQ6CHXAGv8mKz3B4UQ68mG6BFgaJCPweVCakGjCnS80bsGkZ7lW8aBNMIk6mSC uJyVn9NvNzG/zI/vHWFhU/56k9go7T/lYzYhB+9++1BQwgH/xygt0S5PpfsmFTNiOA9X rZn96+HeHL9PjVDwQ9x12CMZ8QOuXR3VkmtXssVHHKYCHqamw5spDr4h+/c7jWUVLUuc P1ExSdTWnp+EQKeXa/5+gR4NlzjOysRzNqv+Kur1V3xicrH+dRemb/VYUo08tRlxglNm h0sA== X-Gm-Message-State: AJaThX4FX64ICUfwC8bGEun2zrQeCMMMzn27/+htTAQCCUD94mXPTc+M 4jf4Q3eUnsh60MisHVY6wG7m0Q== X-Google-Smtp-Source: AGs4zMa0Xdb1nmmWtxfheOyNZpXd1ZfsLzq1xtGW0jufFYOW5g8ssy8wsmmAcN1gpDyVVew9x9FW5g== X-Received: by 10.31.125.202 with SMTP id y193mr2994672vkc.50.1510952974012; Fri, 17 Nov 2017 13:09:34 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.159.45.140 with SMTP id v12ls1788538uaj.20.gmail; Fri, 17 Nov 2017 13:09:32 -0800 (PST) X-Received: by 10.31.94.198 with SMTP id s189mr546261vkb.9.1510952972328; Fri, 17 Nov 2017 13:09:32 -0800 (PST) In-Reply-To: <32147114.z48B4pQc9d@tjmaciei-mobl1> X-Original-Sender: myriachan@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:35389 Archived-At: ------=_Part_352_2070688029.1510952971672 Content-Type: multipart/alternative; boundary="----=_Part_353_1572546937.1510952971672" ------=_Part_353_1572546937.1510952971672 Content-Type: text/plain; charset="UTF-8" On Wednesday, November 15, 2017 at 6:21:34 PM UTC-8, Thiago Macieira wrote: > > Second, even though a freestanding implementation is not required to have > a > heap, most do, of some sort. So even though the paper is correct in saying > that all new except the placement one should not be required, I'd like to > see > a discussion on them being possible. The same goes for exceptions and > RTTI: > some freestanding uses may want to opt into them, even though they may > have a > certain amount of overhead. > > I would argue that typeid() ought to be allowed even with RTTI disabled, provided that the parameter is not a glvalue that identifies an object of a polymorphic type. Third, what are the criteria used for this selection? The paper talks about > global or thread-specific storage or floating point, which I agree. Some > functions appear to be selected for inclusion because they can be > reasonably > expected to be implemented in exclusively headers, but other ones like > memcpy > or strpbrk, usually quite complex to implement properly, are included too. > > Perhaps the definition ought to be based on a list of features? An implementation could decide whether it wants to implement the "floating point", "exception" or "thread" features, and provide the functionality in that category. > * The ::at() functions whose only purpose is to throw an exception could > simply be modified to not do so and do exactly the same as operator[]. > That's > for ease of porting of existing code that may use them. > > When exceptions are disabled, I suppose that exceptions could be defined as either just calling std::terminate() or be undefined behavior. Which way, I have no idea. > * I agree on and and would suggest studying giving > them > non-exception interfaces. I'd be personally interested in that, since Qt > could > use them if they did not require exceptions. > > As a video game programmer, the fact that and use exceptions is a strong deterrent to using them at all. At my employer, we actually have an entire STL reimplementation designed for performance characteristics we require, and one of our requirements is that we don't have exceptions. vector::at() is identical to vector::operator[] for us, as an example. Similarly, our optional and variant consider misuse to be undefined behavior, with an assertion in debug builds. Melissa -- 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/6e752115-7aea-4c5a-87fc-80940af8d607%40isocpp.org. ------=_Part_353_1572546937.1510952971672 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, November 15, 2017 at 6:21:34 PM UTC-8, Thiag= o Macieira wrote:
Second, even = though a freestanding implementation is not required to have a=20
heap, most do, of some sort. So even though the paper is correct in say= ing=20
that all new except the placement one should not be required, I'd l= ike to see=20
a discussion on them being possible. The same goes for exceptions and R= TTI:=20
some freestanding uses may want to opt into them, even though they may = have a=20
certain amount of overhead.


I would argue that typeid() ought to b= e allowed even with RTTI disabled, provided that the parameter is not a glv= alue that identifies an object of a polymorphic type.

<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">Third, what are the criteria us= ed for this selection? The paper talks about=20
global or thread-specific storage or floating point, which I agree. Som= e=20
functions appear to be selected for inclusion because they can be reaso= nably=20
expected to be implemented in exclusively headers, but other ones like = memcpy=20
or strpbrk, usually quite complex to implement properly, are included t= oo.=20


Perhaps the definition ought to be bas= ed on a list of features?=C2=A0 An implementation could decide whether it w= ants to implement the "floating point", "exception" or = "thread" features, and provide the functionality in that category= ..
=C2=A0
* = The ::at() functions whose only purpose is to throw an exception could=20
simply be modified to not do so and do exactly the same as operator[]. = That's=20
for ease of porting of existing code that may use them.


When exceptions are disabled, I suppos= e that exceptions could be defined as either just calling std::terminate() = or be undefined behavior.=C2=A0 Which way, I have no idea.
= =C2=A0
* I agree on <v= ariant> and <optional> and would suggest studying giving them=20
non-exception interfaces. I'd be personally interested in that, sin= ce Qt could=20
use them if they did not require exceptions.


As a video game programmer, the fact t= hat <variant> and <optional> use exceptions is a strong deterre= nt to using them at all.

At my employer, we actual= ly have an entire STL reimplementation designed for performance characteris= tics we require, and one of our requirements is that we don't have exce= ptions.=C2=A0 vector::at() is identical to vector::operator[] for us, as an= example.=C2=A0 Similarly, our optional and variant consider misuse to be u= ndefined behavior, with an assertion in debug builds.

<= div>Melissa

--
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/6e752115-7aea-4c5a-87fc-80940af8d607= %40isocpp.org.
------=_Part_353_1572546937.1510952971672-- ------=_Part_352_2070688029.1510952971672-- .