220 35432 article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: On P0829 - a freestanding implementation Date: Tue, 21 Nov 2017 14:34:58 -0800 (PST) Lines: 202 Approved: news@gmane.org Message-ID: References: <32147114.z48B4pQc9d@tjmaciei-mobl1> <1747398.ysixVUWvEu@tjmaciei-mobl1> <5d0ae760-d76c-4816-a420-88f8663ae458@isocpp.org> <10213508.VWnTgIxFMp@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9142_1837960168.1511303698649" X-Trace: blaine.gmane.org 1511303699 7321 195.159.176.226 (21 Nov 2017 22:34:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 21 Nov 2017 22:34:59 +0000 (UTC) Cc: ben.craig@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIJHVGS2ACRUBF6YMLG6@isocpp.org Tue Nov 21 23:34:54 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f199.google.com ([209.85.217.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHH81-0001YO-QR for gclcip-std-proposals@m.gmane.org; Tue, 21 Nov 2017 23:34:54 +0100 Original-Received: by mail-ua0-f199.google.com with SMTP id r11sf6872632uah.12 for ; Tue, 21 Nov 2017 14:35:01 -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=uVx2XyUMpfNB247HgJYxMH8V3LHukf9VhIogWT8Fvxg=; b=ZOzmv8MWqqvug6/6Iz3qXXAZUPeZjnWVbU3mA6JXVBaOfu24ThL7nhYAfr6fS/MPDH MJINac4U3AGcMih6lioAW7Fj1BampJytne+8NQW+5Qz6ixJpvQmiFPYd5qTAcVTH6YuP 5K3EmV+ROvYPp5zu+qurQKdXlvh7k0F0L9VwGkRU8Rh31bS2DX6feAciaFrPZgZVhacO /v79vA1gGVQxW8TNzPk9QFBfzoG19uRvFuyU9LIlu9XLcDkIFrCA1Lsp9IIx1JSXyiIt bobhE7g3TcUt4g30x9uI6N5orHiQWJMp6sKTB8Qy4U37K9AAeCYaTv4lrCpqLAupJNNT eLeg== 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=uVx2XyUMpfNB247HgJYxMH8V3LHukf9VhIogWT8Fvxg=; b=PcfChdAlLEorAG2HLouveCeVgrsatVHw5bQnfIAwu1UYQnNI569KkFF/tVHwQ7V38H uwLSXTz+yqlyfGPge46OR2+aeXyVq0kyEMLm9cNRzgWHkAGLk5a+m8nVNZNadEj2J3MZ KsqmoUmGEscSKkJ9kuT4kgTJWWL0Q+dQDDzmfnZJPvthJaT8yxlqpast327pRNEfLM0q IdFUyk5pOIesLXXq31bL82oLZZ2YyLlwbpr/JwFrLYEwA1TVjmV2NRMtW8/b66ghH+9H XbzDLMEGB8Km19hBioB1FS2kEnUQsWUGdxaeFEzX8tUj1egKxicJYdUlYv6nHSXV36TG Kdow== 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=uVx2XyUMpfNB247HgJYxMH8V3LHukf9VhIogWT8Fvxg=; b=mxD7Yc5eYl9onRH6BASY2dN5i50UNm0AIPkPDtrIqgk8YQ+cZJz18oGl60lzv+CNjA 5p/c5czRQdrz3K/G05bz1r68HJKY6ATOSKQo5IxJo+uPgz61YHtHAsf3VysonVn/ANOa tIDTwXINtmgJV95ZPTV7SqvBQ5NQXWfVORLo8PrBwNWtx6iNwTpB4ioJc0Aq9XxIMRBk BDpqJ2n4lbEJn/Xe09SpT5voJ4+bWSSqgw8AKfe2Iu8wUDIRMlsUzSM4quHJJ0bReT2i qSf0o5vmBQcjH86pb6i5ve+9EfiTrN0Q7GFOAAvs9gnC/JtrQdGxzAuVa8Icw/WL+NTS CaWA== X-Gm-Message-State: AJaThX5clXued1ssyLvXLcQ34MpEeI1SR3NOvw8RJ+ZvGawcA7E2sHP/ vj5wab635LaLTYzIvzClFUbunA== X-Google-Smtp-Source: AGs4zMaaTxoJACAgKioDCBBGezQhuydJWeF1SwdRGRfU7uwPCimX7mNr+JlXS5v6G0W94Vu6ba73Fg== X-Received: by 10.176.82.175 with SMTP id v44mr3219962uav.56.1511303700914; Tue, 21 Nov 2017 14:35:00 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.159.62.77 with SMTP id c13ls644875uaj.18.gmail; Tue, 21 Nov 2017 14:34:59 -0800 (PST) X-Received: by 10.31.94.198 with SMTP id s189mr1671173vkb.9.1511303699176; Tue, 21 Nov 2017 14:34:59 -0800 (PST) In-Reply-To: <10213508.VWnTgIxFMp@tjmaciei-mobl1> X-Original-Sender: arthur.j.odwyer@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:35432 Archived-At: ------=_Part_9142_1837960168.1511303698649 Content-Type: multipart/alternative; boundary="----=_Part_9143_354287527.1511303698649" ------=_Part_9143_354287527.1511303698649 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Monday, November 20, 2017 at 7:39:20 PM UTC-8, Thiago Macieira wrote: > > On segunda-feira, 20 de novembro de 2017 18:56:04 PST Ben Craig wrote:=20 > > * The omitted string view functions all throw exceptions on bounds=20 > > violations.=20 > >=20 > > * strtok_r is a posix function, not a c or c++ function.=20 > > Then we fix the C and C++ standards. strtok() is C89 and thus part of the= =20 > C++=20 > standard. If it can't be used but strtok_r can, then let's fix it by=20 > standardising the reentrant variants.=20 > > Sure, another paper.=20 > Minor point: Standardizing strtok_r into C++ seems like it would be=20 accomplished by getting it standardized into C first, and then rebasing=20 C++3a onto the C2a standard library (as was done with C++11/C99 and=20 C++17/C11, or some such mapping: I didn't look it up). So if there's a=20 paper involved, it should target WG14, not WG21. Take, for instance, that the random classes all have state-saving and=20 > -loading=20 > from iostream. If you were to discard those, then the entire =20 > header=20 > would go away.=20 > Minor point: It sounds like Ben is thinking of class APIs in the narrow=20 sense of just "members." Philosophically, yes, the API of a class includes= =20 *all* the operations you can do with the class. My impression from that LEWG discussion was that everybody *implicitly=20 assumed* that removing e.g. just the (non-member) stream operators from a= =20 header would not be controversial if Ben wanted to do it. But there was=20 some opposition to the idea of removing e.g. just the throwing *member=20 functions* from a header. I would bet that in actual practice there is no problem with removing=20 non-virtual member functions. The problems appear when you start messing=20 with ABIs; that is, removing non-static *data* members, or removing=20 *virtual* member functions (this is the death knell of std::error_code), or= =20 (perhaps) changing the *signatures* of existing functions. For an example of changing the signature of an existing function, imagine= =20 if a "freestanding mode" changed the constructor signature of=20 std::random_device=20 = =20 from random_device(const std::string& =3D "implementation-defined") to random_device() // random_device(const std::string&) is not provided in freestanding=20 mode This could result in various link-time failure modes, depending on in which= =20 modes various translation units are compiled and linked. Some of those=20 use-cases might be worth intending to support; others might be silly and=20 okay to break. I'm not qualified to decide which ones are silly and which= =20 ones aren't. > * I will investigate seed_seq.=20 > > I want you to keep it, but the class needs to be fixed not to rely on=20 > heap.=20 > Major point: std::seed_seq is irreparable, and also unnecessary. For each= =20 problem that a naive user might think is solved by std::seed_seq, the=20 correct solution is found in Moritz Klammler's proposal P0205 "Allow=20 Seeding Random Number Engines with std::random_device"=20 ,=20 which (AFAIK) sadly was not discussed at Albuquerque because no champion=20 was present. =E2=80=93Arthur --=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/ac891deb-fd2c-4eb1-a401-c8b470ec4320%40isocpp.or= g. ------=_Part_9143_354287527.1511303698649 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Monday, November 20, 2017 at 7:39:20 PM UTC-8, Thiago M= acieira wrote:
On segunda-feira= , 20 de novembro de 2017 18:56:04 PST Ben Craig wrote:
> * The omitted string view functions all throw exceptions on bounds
> violations.
>=20
> * 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 t= he C++=20
standard. If it can't be used but strtok_r can, then let's fix = it by=20
standardising the reentrant variants.

Sure, another paper.

Minor point: Standardizing strtok_r in= to C++ seems like it would be accomplished by getting it standardized into = C first, and then rebasing C++3a onto the C2a standard library (as was done= with C++11/C99 and C++17/C11, or some such mapping: I didn't look it u= p). =C2=A0So if there's a paper involved, it should target WG14, not WG= 21.


Take, for instance, that the random classes all have state-saving = and -loading=20
from iostream. If you were to discard those, then the entire <random= > header=20
would go away.

Minor point: It sounds like Ben is thi= nking of class APIs in the narrow sense of just "members." Philos= ophically, yes, the API of a class includes all the operations you c= an do with the class.
My impression from that LEWG discussion was= that everybody=C2=A0implicitly assumed that removing e.g. just the = (non-member) stream operators from a header would not be controversial if B= en wanted to do it. =C2=A0But there was some opposition to the idea of remo= ving e.g. just the throwing member functions from a header.

I would bet that in actual practice there is no problem wi= th removing non-virtual member functions. The problems appear when you star= t messing with ABIs; that is, removing non-static data members, or r= emoving virtual member functions (this is the death knell of std::er= ror_code), or (perhaps) changing the signatures of existing function= s.

For an example of changing the signature of an = existing function, imagine if a "freestanding mode" ch= anged the constructor signature of std::random_device from
=C2=A0 =C2=A0 random_device(const std::string& =3D "i= mplementation-defined")

to
=C2=A0 =C2=A0 random_device()
=C2=A0 =C2=A0 // random= _device(const std::string&) is not provided in freestanding mode
<= /div>

This could result in various link-time failure mod= es, depending on in which modes various translation units are compiled and = linked. Some of those use-cases might be worth intending to support; others= might be silly and okay to break. I'm not qualified to decide which on= es are silly and which ones aren't.


=
> * I will investigate seed= _seq.

I want you to keep it, but the class needs to be fixed not to rely on h= eap.

Major point: std::seed_seq is irrepara= ble, and also unnecessary. For each problem that a naive user might think i= s solved by std::seed_seq, the correct solution is found in Moritz Klammler= 's proposal P0205 "Allow Seeding Random Number Engines with = std::random_device", which (AFAIK) sadly was not discussed at Albu= querque because no champion was present.

=E2=80=93= Arthur

--
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/ac891deb-fd2c-4eb1-a401-c8b470ec4320= %40isocpp.org.
------=_Part_9143_354287527.1511303698649-- ------=_Part_9142_1837960168.1511303698649-- .