220 35423 <10213508.VWnTgIxFMp@tjmaciei-mobl1> article Path: news.gmane.org!.POSTED!not-for-mail From: Thiago Macieira Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: On P0829 - a freestanding implementation Date: Mon, 20 Nov 2017 19:39:15 -0800 Lines: 105 Approved: news@gmane.org Message-ID: <10213508.VWnTgIxFMp@tjmaciei-mobl1> References: <32147114.z48B4pQc9d@tjmaciei-mobl1> <1747398.ysixVUWvEu@tjmaciei-mobl1> <5d0ae760-d76c-4816-a420-88f8663ae458@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1511235560 1295 195.159.176.226 (21 Nov 2017 03:39:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 21 Nov 2017 03:39:20 +0000 (UTC) Cc: Ben Craig To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCB4TK757YBRBZ57Z3IAKGQEE7Z7Y2Q@isocpp.org Tue Nov 21 04:39:15 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f71.google.com ([74.125.82.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGzOy-0008KZ-Vh for gclcip-std-proposals@m.gmane.org; Tue, 21 Nov 2017 04:39:13 +0100 Original-Received: by mail-wm0-f71.google.com with SMTP id m9sf66593wmd.0 for ; Mon, 20 Nov 2017 19:39:20 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1511235560; cv=pass; d=google.com; s=arc-20160816; b=KMW0ESbn5tp5riZkqMVUG1RoRulcakhFlKNUGxXuxlQ8uuwxjVU2E2qqUlbd2JpVjA 8IGo+vIJUm4BI9V3Me4p0ZjmHOpQZQbWOkEdlSS0d88zxs927srbZOk4T9D12eZLc25p HGHR6/WqHi0iZxdbRTdimffRAt0oYt9bcph5NSpFz8OVSxKuEXQ1idvPaI5k+lq2ROvA 7j/ksZk+8eO5jApbyQLnI78HorEStCwzJPmgf1+ECm2I702a4TAe+1KseuvdWEX04wYY 4i2grMXyVi47BFxtL6VjpXMS//gjGF3Cj5HrgCbV0GsKDDBXr9fbMyNZGhrEkjrbdYN+ qGFA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results:arc-message-signature:dkim-signature :arc-authentication-results; bh=6I4VcYoNFIpEUUjLL37ZBYKzlMrFgYSOCE2k6n4pBnE=; b=JTHvNy8rJzdAFFY2VbAkkBgc31dQ7N90kD5+wW9VTHhbWS60RWY90CLnUK4HeyU+X1 0bbJVBJAT2JSeKhLsMNFkyzWzxv9Ozc+0oy8R6yjG2x0xYxqixDefJmCNHVF3tqAW/fJ dOP2RJMPE5iZQL30336CSj3fGSYJKu+KwPFhlniDNFIyLsif0un0KrDluJeLvWALZGOH waVwpMq3vetBotFd/ZU4+z0V0ptuzniJftQrQIrYmJMKJlc84lojRJaAe3ZE3l4pI4Fj XISAQC5i9Yriy49QI0jTT9nXpjd2F2jt6dCMLhTsNnpP0sHnXcXumxRCddEqJ7H/606J 2r7A== ARC-Authentication-Results: i=2; mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) smtp.mailfrom=thiago@macieira.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=6I4VcYoNFIpEUUjLL37ZBYKzlMrFgYSOCE2k6n4pBnE=; b=n1B6Baos+10uW+iPvK1n9tykG4tStEpOQfd0fMGQtssbSpEdUCoaFoOkwfii+jRoq1 mNJJArkZt6hpz3zA7uoVanyM5/Qnmml560YC1DiH5C5lkb1FHoCASTRGvSf5LyZCaFCG 0d8J9F4HBp941YCGKcBSLQplH1xYqH81id76qpbJ6Rv5jONrBI5Jksods3L26Mku3+nd ZVlOrmXG7YtKkgGLyBviPPXWFSGTt7Jau/ZND8vrTpD8FJhDRqvL5Buf/uB4lfqxoiKo 0WGGEuxdvDcDdMeSVFYapVcklMBzZEsjX0FHSMa/Gt9p1ZA/9ITVHvUIzNI+gJMSOT4l RWLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version: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=6I4VcYoNFIpEUUjLL37ZBYKzlMrFgYSOCE2k6n4pBnE=; b=UUPWT1lJRhzvKDjsdEGpds3LGHh/AR9kljjk6qtU4v/KM9xNUEACau3beJnlpLT5Zs 7RWBrmbRKyDDEESEyqP78MCFaDob4oTXfJ4KUN/CRrhre2BSRpq308A3z2rnRBvu5Fke AcIF4gqALgPkF5yy1jXSPYffgNUUUlACPzL47FPnSQ9PaauSOOCB0xMn45XKR/32NSwk aiFVWr7D+aMW1zoo04c7OQVMQ0eLHbftXpASSG5zfqSBjRq1PGzd8tAHVGPVrjPZnh4+ AUZWLzdZ7ek64hf3P7/qToKK3fGgoT71OPBFq1EZ3GZp8JqLqqvjAzsk/sG2uOZw/qor 932g== X-Gm-Message-State: AJaThX4v64DU7MQ3U6+mL4jXazI5aywp1ZaxmQQFkPbViYHzLWgVMdM2 fy/kcmlxmlvCq+1RWKxQgPtHOA== X-Google-Smtp-Source: AGs4zMbkbus29IxWikT6NqEO7xVuDTI3FP0N12UmQz+8OIxWmM+gebQiwTUo8NznrfWL21DrgVvxVg== X-Received: by 10.28.19.5 with SMTP id 5mr4995wmt.7.1511235560348; Mon, 20 Nov 2017 19:39:20 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.223.156.134 with SMTP id d6ls2831104wre.14.gmail; Mon, 20 Nov 2017 19:39:19 -0800 (PST) X-Received: by 10.223.169.100 with SMTP id u91mr12245393wrc.108.1511235559137; Mon, 20 Nov 2017 19:39:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511235559; cv=none; d=google.com; s=arc-20160816; b=Mi4t3pZyOwhvKf0zsE0Xi7w+wi1yBDsvegVOuFgUH4FvUW6m6/7o47bjscvdbEDCiH oT3gZ+DnyWVx2YlI7/qVQH1vfKDx2lkV/Ubx/bXdCpwL3/Nx+usCIAd//1msq4mE1k43 wlvmA1o99RxdRF02GyNIney0zfj79auZzM9B7u9kNeVXEZvvjNIteuYrgCbdrsVPsflq cO+V4Pz6+HW/E6E7i18p/6yixn92qWLKLCDICs+hllvZphRT4i68jdkCaFBUvvWndVzn Vz6L21frY7qGY+VkNNLys9iypMlsxk2U30dqn/I2vNWCyzdDB+7gSt85Wr2XX5Jy+UTP VF5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:arc-authentication-results; bh=KT/NFsVpS+iLcgJptU4OdsGAWKooGhrfU5sdTFIOBJE=; b=RAz32kMbq/EdNC0cGzRsUUwWP2KG4i1VF52cKQHPQl2gS81+G7+bOcaWr3uuEgDbI/ CH/lTb0AiElO18jDE+4urGbmT5kFRiqBDjJXbrI7Anwgnp824WTXwdI/nUa7dQlNTuJI pHZZuq6Tx4Ka/WiF5YXAb2dvx2YQpXleTMRbfaCeSO1offkMIbL5h5euq11YU0g8qFIC y7TN1YYolAIiBNA+PZ3N/wD9UsliqkSeOlh31cz2eGE+o84mJiS6rcI4GSFbnQ/mQS3f z0F2E1ecbVBd66wjmNvnBxp1VWKgQEkgh5F2Bwha0te3PLrdn1m/shEizLkHMlKQ9Rat Lriw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) smtp.mailfrom=thiago@macieira.org Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [78.47.120.188]) by mx.google.com with ESMTP id n17si199472wmi.86.2017.11.20.19.39.18 for ; Mon, 20 Nov 2017 19:39:19 -0800 (PST) Received-SPF: pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) client-ip=78.47.120.188; Original-Received: from tjmaciei-mobl1.localnet (unknown [IPv6:2601:1c0:4501:5f9f:e0ee:4594:419f:8f32]) by gondolin.macieira.info (Postfix) with ESMTPSA id 42E5511A172; Mon, 20 Nov 2017 19:39:18 -0800 (PST) In-Reply-To: <5d0ae760-d76c-4816-a420-88f8663ae458@isocpp.org> X-Original-Sender: thiago@macieira.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) smtp.mailfrom=thiago@macieira.org 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:35423 Archived-At: On segunda-feira, 20 de novembro de 2017 18:56:04 PST Ben Craig wrote: > I'm the author of the paper. Sorry for the slow response. Hello Ben Thank you for replying. > * The omitted string view functions all throw exceptions on bounds > violations. > > * strtok_r is a posix function, not a c or c++ function. Then we fix the C and C++ standards. strtok() is C89 and thus part of the C++ standard. If it can't be used but strtok_r can, then let's fix it by standardising the reentrant variants. Sure, another paper. > > * I didn't want to change the semantics of programs across the freestanding > / hosted divide. So that is why rev0 of the paper deletes the at function. > I got feedback in abq that lewg does not want to remove portions of classes > for freestanding... so all of array, string view, error code, etc... will > be removed in r1. I think that's a huge mistake. I do agree that removing portions of the classes is confusing, but removing the entire classes that make C++ interesting in the first place is a much bigger mistake. Take, for instance, that the random classes all have state-saving and -loading from iostream. If you were to discard those, then the entire header would go away. > * The random distributions I removed had floating point in the interface. I > did not remove all the distributions. I still need some implementation > experience to know if some of the distributions I kept use floats > internally. That's an implementation detail. And I repeat: they're all inline because they are templates. So there's no library impact: if someone wants to have those floating-point-using classes for a specific portion of their code, let them. Even the Linux kernel allows floating point and SIMD -- you just have to remember to call some kernel function to enable them and later disable when you're done. > * I will be sure to omit random stream operators in r1. See above. > * I will investigate seed_seq. I want you to keep it, but the class needs to be fixed not to rely on heap. > * New classes that are freestanding friendly would be great, but I think > that belongs in a different paper. > > Re: memcpy and friends. > These functions are very useful, don't require space overhead, and don't > require is calls. That's why they are included. In practice, most existing > embedded and kernel environments have optimized versions of these functions > already, demonstrating their usefulness and implementability. You're making a judgement call. You're cherry-picking which functions you're expecting kernel developers to add by themselves. If they need to write those in the first place, then they know they've done so and those did not come with their compiler. They don't need the standard to tell them. Most importantly, they don't want to implement functions just because the standard said they had to, before they can start writing their value-add code. Granted, most modern compilers do inline memset and memcpy, but that's an optimisation, not the norm. The compilers are totally free not to use that optimisation. And in fact, they don't use it when -ffreestanding is active. See https://godbolt.org/g/ZE9HVg. So I don't think library functions should be selected based on usefulness. They should only be selected based on whether they are usually and reasonably implemented as inlines in the headers. By this definition, all templates that don't rely on globals or the heap should be included. > I did not ask "why should I include function x"? I asked "is there any > reason not to include function x"? Yes, there are. See above. None of the functions are present in the Linux or Zephyr kernels. Would their developers need to implement those functions in order to have a compliant C++ freestanding implementations? > Other feedback I have received suggests that my removals may go too far. > Killing typeid in the library may be too much. I will likely make r1 focus > more on additions and less on removals. Right, after the discussion here I would suggest bringing typeid() back. It requires a minor ABI change to the IA-64 C++ ABI, but that's easily justified by the -ffreestanding switch. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center -- 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/10213508.VWnTgIxFMp%40tjmaciei-mobl1. .