220 38425 <31d6c89e-cbc9-4b25-b9e2-c2f2a98bef0f@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Thumbs Up for No Graphics Date: Fri, 1 Jun 2018 14:16:23 -0700 (PDT) Lines: 468 Approved: news@gmane.org Message-ID: <31d6c89e-cbc9-4b25-b9e2-c2f2a98bef0f@isocpp.org> References: <7915a73c-e305-4bce-bf6e-28f20a7faccb@isocpp.org> <2035f76f-5775-44c1-b9cc-e9249d9b8142@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_13065_608498145.1527887783665" X-Trace: blaine.gmane.org 1527887664 1302 195.159.176.226 (1 Jun 2018 21:14:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Jun 2018 21:14:24 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBKHPY3MAKGQEWOYTGIQ@isocpp.org Fri Jun 01 23:14:20 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f197.google.com ([209.85.161.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fOrNL-00008R-0T for gclcip-std-proposals@m.gmane.org; Fri, 01 Jun 2018 23:14:19 +0200 Original-Received: by mail-yw0-f197.google.com with SMTP id r14-v6sf17392294ywc.12 for ; Fri, 01 Jun 2018 14:16:25 -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=yv3OmbpQ6cefOIiaGEcRRxqca+jPrFk81cwKUTtYuXk=; b=s/sGbCiyD35T7nGYg28Cede0V9p11K6ZdJkaTzGs9R374qX6BzFSVZZ4x6Impz69ir 9B1rzNIoOmmxTdGAcd8QKvv2CuqcQ0I+04NQoORnBCWzPapDeKlu9l3X9GUwHjaLoJj7 POXecINa/AkAt7yxFvcLO9mWR1hZeRzzD5EJ+0qdUajylb3E7HLWFpDzMgzRRSco6lu/ SDZZe3HnWCLaYMbeF1vsswiJejzvdFONlABK0FbOKQDdE47Q1peV2B3H3eNo/K+HT6RO zmxP1yioT25dVcrUja6U1CITQjbJnDZ3l1cOS+P9ODyV01sGZ8hJ+TAVQvZX7tp8dKzJ Tc4g== 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=yv3OmbpQ6cefOIiaGEcRRxqca+jPrFk81cwKUTtYuXk=; b=FIp7P5vAaeIU11gbLKuG4EYQPebth78xG8PgJkUqIa2/gn+cJxK8NPJ4DFXi2w0HLm Sqo26TMX74aVa55x5iTZ/A1x/GHdDT4yVI4xZfNDRw7TLLLoP7LHD4r5ztDVv8kjI1mM eUMLvcrZpqsWLNaw6ulTxjgm2QuLdco2dU9E1b7IR5d9hRybmD8uGuVtCltt02WuSVIK 3RNRuuWbs2XD2/5rLiLyEDKHl4t9i/SfLNqndwYEJCi53QymYvDdAz03ieqousNjfESg atANDTnGmEBXTwIRjW/Tv5IhRcgBMVQOz+Ogy0pYzxtC20RZ/vMuYW8UMMfJjhqY4ZYP QMGQ== 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=yv3OmbpQ6cefOIiaGEcRRxqca+jPrFk81cwKUTtYuXk=; b=ErTPc3blbsBevVg52Bw+56sVn3MUdUtSbvk6vBQGoq7X35Qqm7Ol6GcxxdAIMVOy97 4nUZU8MqvHKtZ73+UTT2wQ7kACBnmgEL7wBybT3f3WfWJ3HFMLuKBxdulcFbumf4BPNj xBwNmJWcsSaQeyYExhaFNpCJHllXw5xrzSLaNP53kXSLDlrt8nQQpAmzfh8Tuw+T5bX+ vjiRgjTYE79jAa9EHxefJaxKMMF7EElHcJCq/NPjhBnv1oahPTcNl5+10z/jlBSoof8y 7dMz4sI84N6bWPTXIvOq7CXKIlUdafLiTMXOpbEowmROKR+ISkG/nV1lEvzFywkMW1yk rB8Q== X-Gm-Message-State: ALKqPwddGjYk5PO/g968BZ9SQ3uCxREthY1gNPwRLjSXLefpwz0Mw2MC LMmGo6cF6No/rRvj58DeZyCiVQ== X-Google-Smtp-Source: ADUXVKL+KjKocDPPbHapWQwhA3KkmOhAbg0+ZRHQtiXY1EE1iUvbawWqmyH0DpwiHYE5uB2J7K2VeQ== X-Received: by 2002:a25:9d03:: with SMTP id i3-v6mr3403310ybp.19.1527887784886; Fri, 01 Jun 2018 14:16:24 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a0d:d5c8:: with SMTP id x191-v6ls1953713ywd.13.gmail; Fri, 01 Jun 2018 14:16:24 -0700 (PDT) X-Received: by 2002:a81:3487:: with SMTP id b129-v6mr461203ywa.13.1527887784112; Fri, 01 Jun 2018 14:16:24 -0700 (PDT) In-Reply-To: <2035f76f-5775-44c1-b9cc-e9249d9b8142@isocpp.org> X-Original-Sender: MihailNajdenov@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:38425 Archived-At: ------=_Part_13065_608498145.1527887783665 Content-Type: multipart/alternative; boundary="----=_Part_13066_1887728245.1527887783666" ------=_Part_13066_1887728245.1527887783666 Content-Type: text/plain; charset="UTF-8" On Friday, June 1, 2018 at 11:15:53 PM UTC+3, Nicol Bolas wrote: > > On Friday, June 1, 2018 at 3:44:06 PM UTC-4, Hyman Rosen wrote: >> >> On Fri, Jun 1, 2018 at 12:32 PM Robert Ramey wrote: >> >>> The problem is that they are not standardized. >>> >> >> The standardization of [filesystem] contributes 46 pages to the C++ >> Standard, >> incorporates POSIX by reference, and is full of "for POSIX it does this >> and for >> Windows it does that" statements along with other waffling. >> > > Not one *normative* statement in the standard has any of this "waffling". > Any platform-specific information are in [notes], and therefore are not > required parts of the actual specification. > > (For example, the >> specification of absolute(const path&p) in [fs.op.absolute] contains >> this: >> *Implementations are strongly encouraged to ... not consider !exists(p) >> an error.*) >> >> I submit that standardizing file system operation in the C++ Standard >> hasn't >> really standardized much, since the underlying system dependencies are >> still >> showing through and have to be accounted for, and has added complexity and >> length to a standard that is already too complex and too long. >> > > If you can write cross-platform code without a single `#ifdef WINDOWS` or > whatever, then the standard is doing its job. The existence of > implementation-dependent aspects of the standard does not mean that you > cannot write your code such that it works on all platforms. > > Consider the statement on `absolute`. All you need to do is handle errors > that happen, to write your code as if you can't call it on a file that > doesn't exist. It's not a problem. > > Adding graphics >> would be a hundred times worse. >> >> Programming language standards should define the programming language. >> > > By that logic, we shouldn't have file APIs, streams, containers, atomics, > threads, or anything of that nature. Those aren't the "programming > language", so there's no need for any part of the standard library outside > of the language support library. > > And what good would that have accomplished? How would that make C++ a > better programming environment? > I guess it is the ratio of uses vs diversity vs dynamic of the task that is to be in a library. Uses must be high, diversity (alternative interpretations of what it is, different attack vectors, different priorities) low and dynamic (rate of change) also low All the things you mentioned fit the criteria ok, well or very well - Many people use them, there are no grotesque alternative views of they are, quite low dynamic (new "inventions" of these come rarely) At higher level libraries things start to lose on these properties. FS is good example. It is saved by the fact the use is high (anyone will want to save a file or list folders contents), but the diversity is also moderate-high (many different attack vectors), dynamic is moderate-to-high as well (for instance mac switched to urls around the time the FS got adopted) As a result FS falls back to a decades old API and if you use the native APIs you will have order of magnate better, as in modern/professional/feature rich, file IO. This is true for all major platforms. Still, as said FS is fine, because of the high potential use and the fact not anyone needs feature rich IO. Things much, much worse for Graphics in any of three criteria and this time around, in contrast to FS, falling back to "some basic principals" risks making it useless outside prototyping and teaching. > > Functionality not required by the core language should be standardized >> separately, if people are moved to do it. >> > -- 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/31d6c89e-cbc9-4b25-b9e2-c2f2a98bef0f%40isocpp.org. ------=_Part_13066_1887728245.1527887783666 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Friday, June 1, 2018 at 11:15:53 PM UTC+3, Nico= l Bolas wrote:
On Friday, June 1, 2018 at 3:44:06 PM UTC-4, Hyman Rosen wrote:
On Fri, Jun 1, 2018 at 12:32 PM Robert Ramey <ra...@rrsd.com> wrote:
The problem is that they are not standardized.

The= standardization of [filesystem] contributes 46 pages to the C++ Standard,<= br>incorporates POSIX by reference, and is full of "for POSIX it does = this and for
Windows it does that" statements along with other waff= ling.

Not one normativ= e statement in the standard has any of this "waffling". Any p= latform-specific information are in [notes], and therefore are not required= parts of the actual specification.

(Fo= r example, the
specification of=C2=A0absolute(const path&p)=C2=A0in [fs.op.absolute] contains this:<= br>Implementations are strongly encouraged to ... not consider !exists(p) an error.)

I submit= that standardizing file system operation in the C++ Standard hasn'treally standardized much, since the underlying system dependencies are sti= ll
showing through and have to be accounted for, and has added complexit= y and
length to a standard that is already too complex and too long.

If you can write cross-platf= orm code without a single `#ifdef WINDOWS` or whatever, then the standard i= s doing its job. The existence of implementation-dependent aspects of the s= tandard does not mean that you cannot write your code such that it works on= all platforms.

Consider the statement on `absolut= e`. All you need to do is handle errors that happen, to write your code as = if you can't call it on a file that doesn't exist. It's not a p= roblem.

Adding graphics
would be a= hundred times worse.

Programming language standards should define t= he programming language.

<= div>By that logic, we shouldn't have file APIs, streams, containers, at= omics, threads, or anything of that nature. Those aren't the "prog= ramming language", so there's no need for any part of the standard= library outside of the language support library.

= And what good would that have accomplished? How would that make C++ a bette= r programming environment?

=
I guess it is the ratio of uses vs diversity vs dynamic of the ta= sk that is to be in a library.=C2=A0

Uses must be high, diversity (alt= ernative interpretations of what it is, different attack vectors, different= priorities) low and dynamic (rate of change) also low

All the things you mentioned fit the c= riteria ok, well or very well - Many people use them, there are no grotesqu= e alternative views of they are, quite low dynamic (new "inventions&qu= ot; of these come rarely)
=C2=A0
At higher level libraries things start to = lose on these properties.=C2=A0

FS is good example.=C2=A0
It is saved = by the fact the use is high (anyone will want to save a file or list folder= s contents), but the diversity is also moderate-high (many different attack= vectors), dynamic is moderate-to-high as = well (for instance mac switched to urls around the time the FS got adopted)=

As a result FS = falls back to a decades old API and if you use the native APIs you will hav= e order of magnate better, as in modern/professional/feature rich, file IO.= This is true for all major platforms.=C2=A0
Still, as said FS is fine, bec= ause of the high potential use and the fact not anyone needs feature rich I= O.

Things much, much worse for Graphics in any of three criteria and t= his time around, in contrast to FS, falling back to "some basic princi= pals" risks making it useless outside prototyping and teaching.
=C2=A0

Functionality not required by the= core language should be standardized
separately, if people are moved to= do it.

--
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/31d6c89e-cbc9-4b25-b9e2-c2f2a98bef0f= %40isocpp.org.
------=_Part_13066_1887728245.1527887783666-- ------=_Part_13065_608498145.1527887783665-- .