220 35660 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: pragma once Date: Thu, 30 Nov 2017 15:56:59 +0000 Lines: 173 Approved: news@gmane.org Message-ID: References: <3d275c24-dc31-4fa7-a6db-e235ab2e00f1@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11c15b286ef604055f354ddb" X-Trace: blaine.gmane.org 1512057421 12813 195.159.176.226 (30 Nov 2017 15:57:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 30 Nov 2017 15:57:01 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBTOUQDIQKGQEPRPJ5GQ@isocpp.org Thu Nov 30 16:56:56 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot0-f197.google.com ([74.125.82.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKRCp-0002yl-AX for gclcip-std-proposals@m.gmane.org; Thu, 30 Nov 2017 16:56:55 +0100 Original-Received: by mail-ot0-f197.google.com with SMTP id n64sf3630561ota.3 for ; Thu, 30 Nov 2017 07:57:03 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1512057422; cv=pass; d=google.com; s=arc-20160816; b=WqhiW5qtXqFue88wC1SaUzoAdNUvSg2yZUAQJtnqJM163blEd54Tii+qlhAAkzG6QO 9a0U9gu9sQvWYbZiPQZTeGgcfZ1S059T95Fwvd5b4h+YATySdaCMEoEHhE4yLdzyvoSC DfQA4r6Qk/VI6ejWPGqurZni2AdIqlp7f9PO7BbrkIjdmoB6pKIQdRrRvv43dNKzKxNt MLkofk2AinhmeAfX/tb6RmG/OB3Wd8rXOTsQ3oG3pGphHdAS9rvr/VEudH4sCMAVg39W zjJ8RavojGa/hngOCkBohMwWR443ZvG60SuGV3v/vNmkTYLayFuOFxthWtjY2QzsSdCn dfbQ== 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:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=b/Nqai3AdGZLjYTINbTGNhFuwguPxD+cptleryqV47U=; b=o+r8q/WNWZJvPHAszv2ZtPd8LQbdZViTe/fandjZzLK2J8kHzixla7IUIhQI+lJ2xW MkHq0tpmSif+BhjihsJOk61uQoIZQhzRExK7gbxbr9LIKVC61eHFCvBf+Wlzk/YlQqcv c+UOn9mCAh/SUSlB3e4094zxHor97yFAglTynPWj13ePjfL7qLMWswmgXWognDNoVPXc HyQ5h8JERGNAXNk069rgrJYseJfxQIUo+mio+XPHOEy7k5VAPqb39BwLwSD5E3C2ywGc 53ssYqRGn/AWE5DvHsM88bF9ELrIC5ih9I6aDZOh/4/ryZdDoefDTS/XGaJNscXuZ6jl DhhQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=G6NkweQm; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :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=b/Nqai3AdGZLjYTINbTGNhFuwguPxD+cptleryqV47U=; b=jDP25RsdpONE/TFWFkOqS7XBnlVkMFeGTp35LabmY7eAgw0ndfd9Kr9FuOJryTjDG+ xL8pqWf+2KTkkNDXNmVzUQ3mqtHA4JbQPJEc2GjhAPdGgOP4KDNtRCsILAj3mtXcn6ow K6MQWFxISMKIHc1kXdd17aUmcr18A55TBs9jrDjeqye1jPRLUuAzEvSk4CYrcsLlm4eb 3LdZTz8lddjGyIHxDeOaLd6sKyB3erGr+TVDlWCBKYV5sfdfRSbB++aIpeRnGgDpT4vk 2Frei/hkNiCt9YsD1M2gbRhEmUCLrbfnVSUhrM6Yn9GCkn39ogGrP39yFKDipAhNG4lf +PRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to: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=b/Nqai3AdGZLjYTINbTGNhFuwguPxD+cptleryqV47U=; b=G+YNRTtvrS2MBGlz4nM0Eb1wqLK/ywyi8qihT0B9pMFPBGsSQXd3Kx02YAZ68IN8WQ Nnfg5LUnrV/lHqZeIikoxppuaFlvGfiv7ppwRn1jMjXRSi4dMGqJFyt0l7/yhko+r29k jvDaZUBYb2LEopROGdDj0O7/3ru/OfY/CypZH6a5PBRqix9Y0YrLeY9qIdKB6ee9GZsr a9nkUvRPFjRN2bWE/UNPXkmVrQFXFSGh/gwj1WS1ZA0M4rTeO14lwFb1oPjDGNjJEaVd DtW5amGzFZPqzHjsuUMx2AJEhwr9KD8TRhxwI71qLGRkwcQYgj1U4N5/Gsu8GwdXbLbQ y8SQ== X-Gm-Message-State: AJaThX60N/N3f+ofc6LhLLnSKBPr0xI+wIZE2+YZvWk23gCfBmIJqHZj ZHZPQZH/kT1bCKLHB/GMb14KLw== X-Google-Smtp-Source: AGs4zMZ8gzXgumqPKuVTubBm9g6TpCFRMWlzPs6aKzbo9JW3Z0/LzCM1KnTsYQ4egblPsYaBz2OXKA== X-Received: by 10.202.230.13 with SMTP id d13mr2846103oih.21.1512057422399; Thu, 30 Nov 2017 07:57:02 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.202.169.5 with SMTP id s5ls5707884oie.10.gmail; Thu, 30 Nov 2017 07:57:01 -0800 (PST) X-Received: by 10.157.81.111 with SMTP id u44mr5519288oti.130.1512057421104; Thu, 30 Nov 2017 07:57:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512057421; cv=none; d=google.com; s=arc-20160816; b=b0Z0sj6lyPtOZJExYdEU6hJ7zQbVFr+ZMcS9SX2XmJI54gnR8tWSsWhs5++C0mqjlU qoBj2isuNjnt3IpNS2+ymCOi+oCZgBn1IOaK9/rmFrAHljOp3XdPat1pZwo7QQ6KF9tR 9ERBKS1nCxZmn14oh8/hApl+VmIvXKLIs2Vf+GOB/9KBhx4XfoXVdQXAtDWf5AKgtJNf 9QHEnMGn3grqLt9yxvJp7ZfF8QijbZmgEaE7bs+fxlYLf+3UZP76940LiycUA7NVSlvf iWqWSHUFSdY7CfmZTSyJyqWO/mRKPROnO3tD00xlTEBdbDDw9PTBdMcqXET8b+rI85i9 dUvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=vkhI3F7PV4PgK5KM7dgRve6AYR1rr6kWnaVM7VF9Fyc=; b=htRAv0j57ZoxrExejYjBHoCQZt4EgVHrs6jLs8+TsXHBpt7kGrFnlzcwOkjKXW5ROk P0E+J/IaPfVFRxyvM2O4gNjNO9D/AxCrho/ntV3YSAflQC5tEab6qw74Or3Hp7IcfMZz TSXc2VLf/pe06jJa4b2Kg5/tAlRHpTdnCqrzWYVU4vfJ0qh+uPxwc/K4dDgRysGRfEQk 5hZ30712cgMoB8nImsRzdjkirwm6MXp/gO++H2q2EvG0X60BKviR7mAPxg8+2r0dT30G 9tM7JH4dnmFGH/xaN+cpt3ZM6MURhT8MOcMGAcClL56rBT0eU/9HX85pDGoUnpchR/CV BAgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=G6NkweQm; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id s11sor1605870oih.169.2017.11.30.07.57.01 for (Google Transport Security); Thu, 30 Nov 2017 07:57:01 -0800 (PST) Received-SPF: pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.202.76.208 with SMTP id z199mr5030712oia.49.1512057420574; Thu, 30 Nov 2017 07:57:00 -0800 (PST) Original-Received: by 10.168.69.140 with HTTP; Thu, 30 Nov 2017 07:56:59 -0800 (PST) Original-Received: by 10.168.69.140 with HTTP; Thu, 30 Nov 2017 07:56:59 -0800 (PST) In-Reply-To: X-Original-Sender: jake.arkinstall@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=G6NkweQm; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:35660 Archived-At: --001a11c15b286ef604055f354ddb Content-Type: text/plain; charset="UTF-8" I generally agree. Standardizing pragma once makes sense. In fact, it makes so much sense that I think it's worthwhile putting in the elbow grease and solving the issues that arise as part of the "spring cleaning" On 30 Nov 2017 14:51, "Bo Persson" wrote: Pragma once has other problems, like nobody has cared to specify what it means on systems other than Linux and Windows. How it works on other systems is a tough one, as is usually the case, but in general if you have the ability to include a file and parse it, I can't see why you won't also have the ability to hash it (perhaps with two different salts, to give two hashes, to significantly reduce accidental collisions between two different but well-formed files) and compare with already-included files. That isn't to say you *would* have the ability, but that *I can't see* *why not* - perhaps someone can educate me on the matter. If it's a particularly *limited* (rather than just "different") system, isn't it advisable that the compilation side of things be done on a more capable system? And should the compiler writer be required to test the feature on every other file system that can possibly be mounted on your development system? Do compiler writers normally neglect testing on a variety of filesystems as part of their usual process? I mean, surely this is vital regardless? If I'm using a filesystem that hasn't been tested, and I compile something on It, I expect the developer to at least give me the courtesy of a warning at compile time. Compilers do seem to have a fairly nice property, in that general compilers have large enough communities surrounding them to have them tested on a plethora of setups, and very specific compilers that are finely tuned for specific setups only need support those setups. Perhaps I'm being naive here, but it appears that the compiler writers have a pretty good balance going on. Sure, this proposal would shift more weight onto their shoulders, but that is generally what a progressive standardisation process should be doing. At the end of the day, a programming language benefits from usability. Just look at how beautiful code has become since "auto" gained superpowers, as an example. The copy-paste error with the include guard has the advantage that you can fix it yourself. I agree on this point. The compiler shouldn't have to navigate a dev's laziness, and a dev can gain a lot of knowledge from solving such issues themselves. That being said, I do believe a dev shouldn't have to manually create and name a set of distinct constants simply for a compiler to know if it has seen a given file before. This is something that has long been solved with many other languages. It's almost an XY problem: the underlying problem is that the compiler is unaware of where it is, and a fudge of constants that may cause a bad compilation is actually more of a symptom than a problem in itself. I'd personally go as far as saying that I wish the single inclusion could be the DEFAULT and for something like "#pragma many" to be used when a developer wants to have the ability to include a file multiple times. That's the rarer and more obscure case (and arguably a very hacky one that should be discouraged, and for a smoother approach to be created), so should be treated as the exception, not the rule, IMO. However, this being a breaking change, it can safely be designated to the "dream world" bin along with dogs that pick up their own mess, and a virtual reality equivalent of Vim so we can program in 3D with gesture commands and infinite screen space. Jake -- 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/CAC%2B0CCMZW8hoM38WaSE_3kRhcss498gNp7KrnLSCXP7WKr%3DKPg%40mail.gmail.com. --001a11c15b286ef604055f354ddb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I gene= rally agree. Standardizing pragma once makes sense. In fact, it makes so mu= ch sense that I think it's worthwhile putting in the elbow grease and s= olving the issues that arise as part of the "spring cleaning"

On= 30 Nov 2017 14:51, "Bo Persson" <bop@gmb.dk> wrote:
Pragma once has other problems, like nobody has cared to specify what it me= ans on systems other than Linux and Windows.

How it works = on other systems is a tough one, as is usually the case, but in general if = you have the ability to include a file and parse it, I can't see why yo= u won't also have the ability to hash it (perhaps with two different sa= lts, to give two hashes, to significantly reduce accidental collisions betw= een two different but well-formed files) and compare with already-included = files.

That isn't to= say you would have the ability, but that I can't see = why not - perhaps someone can educate me on the matter. If it's a p= articularly limited (rather than just "different") system,= isn't it advisable that the compilation side of things be done on a mo= re capable system?

= And should the compiler writer be required to test the feature on every oth= er file system that can possibly be mounted on your development system?
=

Do compiler writers normally neglect tes= ting on a variety of filesystems as part of their usual process? I mean, su= rely this is vital regardless? If I'm using a filesystem that hasn'= t been tested, and I compile something on It, I expect the developer to at = least give me the courtesy of a warning at compile time.

Compilers do seem to have= a fairly nice property, in that general compilers have large enough commun= ities surrounding them to have them tested on a plethora of setups, and ver= y specific compilers that are finely tuned for specific setups only need su= pport those setups. Perhaps I'm being naive here, but it appears that t= he compiler writers have a pretty good balance going on. Sure, this proposa= l would shift more weight onto their shoulders, but that is generally what = a progressive standardisation process should be doing. At the end of the da= y, a programming language benefits from usability. Just look at how beautif= ul code has become since "auto" gained superpowers, as an example= ..

=
The copy-paste error with the include guard h= as the advantage that you can fix it yourself.

I agree on this point. The compil= er shouldn't have to navigate a dev's laziness, and a dev can gain = a lot of knowledge from solving such issues themselves.

That being said, I do believe a dev shouldn= 't have to manually create and name a set of distinct constants simply = for a compiler to know if it has seen a given file before. This is somethin= g that has long been solved with many other languages. It's almost an X= Y problem: the underlying problem is that the compiler is unaware of where = it is, and a fudge of constants that may cause a bad compilation is actuall= y more of a symptom than a problem in itself.

I'd personally go as far as saying that I wish th= e single inclusion could be the DEFAULT and for something like "#pragm= a many" to be used when a developer wants to have the ability to inclu= de a file multiple times. That's the rarer and more obscure case (and a= rguably a very hacky one that should be discouraged, and for a smoother app= roach to be created), so should be treated as the exception, not the rule, = IMO. However, this being a breaking change, it can safely be designated to = the "dream world" bin along with dogs that pick up their own mess= , and a virtual reality equivalent of Vim so we can program in 3D with gest= ure commands and infinite screen space.

Jake

--
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/CAC%2B0CCMZW8= hoM38WaSE_3kRhcss498gNp7KrnLSCXP7WKr%3DKPg%40mail.gmail.com.
--001a11c15b286ef604055f354ddb-- .