220 29119 <5810EC44.50807@gmail.com> article Path: news.gmane.org!.POSTED!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: pragma once Date: Wed, 26 Oct 2016 13:47:48 -0400 Lines: 82 Approved: news@gmane.org Message-ID: <5810EC44.50807@gmail.com> References: <5810C33B.9060503@gmail.com> <2908d573-f002-4b58-b0da-18420a816c16@isocpp.org> <47276183-8ce7-4999-ab1c-4be1cbaf26bb@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 1477504090 18602 195.159.176.226 (26 Oct 2016 17:48:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Oct 2016 17:48:10 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBBSGYYPAAKGQEPBSOQFQ@isocpp.org Wed Oct 26 19:48:06 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bzSIo-0002Sb-Bz for gclcip-std-proposals@m.gmane.org; Wed, 26 Oct 2016 19:47:50 +0200 Original-Received: by mail-vk0-f70.google.com with SMTP id c203sf7849668vke.0 for ; Wed, 26 Oct 2016 10:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-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=6wS66Wgt7zAKRwsoLEMPmCn39sOCWtdqLSCJMZawH2o=; b=xcaZKXKW6MHuhs5uJJTUXtNaQigAUHNgarzvzse1va6WKTyfwQGyw2lNn6zyssZVfX lqBgcvM3osPGW7STJ9KVfy9B+M7nRcRJL5UFaVskAkKm2sNJt2SpY2TIaaipQ3LpYiZ8 2R0rRxDQ2D9iV9QnDQzmCixhkgpshgBETlaLrNYC7euu7h8wuEkdWFNKJZlvtLWPteJW DbKKma+LgBHXgYghXGZTNb3R4VDSky9o905PwlYctEeX5xCMnbwRC4KA2mDbe2K8dkN2 PCGwDXjkFlaLNm2PKuvR7a2FjkK/ZX2njAriz+Ae270slC9mlIQ2zhNwi9EfDqrlWMrq O/FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-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=6wS66Wgt7zAKRwsoLEMPmCn39sOCWtdqLSCJMZawH2o=; b=ZG/gyw7lpASwC7IfzoLmxIaZSLItyp6++CmnA9iZoV7Oe7lcZZaB54sDjoqEQ3oU0F aLde2QgDORqhw+aLarVvvb+8Ndh1iZT7WQanLC6UZ197er5v5hVrxIxiFeP3U1l4OvRX 47rbVFX8B1Eq/OsN2Rl8n6RHYts/wTJeee5KT3/tBfEHEBHLHXr30t5dEMp2ZVotCTrB 3IQhMccGtsFnEzHssMNDelgBtOmNmEfvVMwOEqwCeHjKOC5OKdSL+5saSo7p6bWQ1I0Y lJ5QEANl0MgCVPkBoUXzcgqT1WPYMoSaIodQs9SYYzSZESAh9bflynsLQKqkoXDM//to KA9Q== X-Gm-Message-State: ABUngvcvhR+TIrjSJtZ2CF6GT+MWQhfeZOYDiV9EhAafIfgA7R27u8puvKfadJAe7Lr9gQ== X-Received: by 10.31.33.79 with SMTP id h76mr909847vkh.27.1477504072782; Wed, 26 Oct 2016 10:47:52 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.11.110 with SMTP id p43ls2052404otd.40.gmail; Wed, 26 Oct 2016 10:47:52 -0700 (PDT) X-Received: by 10.176.80.123 with SMTP id z56mr2140310uaz.139.1477504072082; Wed, 26 Oct 2016 10:47:52 -0700 (PDT) Original-Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com. [2607:f8b0:400d:c0d::235]) by mx.google.com with ESMTPS id g60si1253957uag.113.2016.10.26.10.47.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Oct 2016 10:47:52 -0700 (PDT) Received-SPF: pass (google.com: domain of mwoehlke.floss@gmail.com designates 2607:f8b0:400d:c0d::235 as permitted sender) client-ip=2607:f8b0:400d:c0d::235; Original-Received: by mail-qt0-x235.google.com with SMTP id q7so6710852qtq.1 for ; Wed, 26 Oct 2016 10:47:52 -0700 (PDT) X-Received: by 10.200.43.61 with SMTP id 58mr2973952qtu.69.1477504071580; Wed, 26 Oct 2016 10:47:51 -0700 (PDT) Original-Received: from [192.168.1.173] (tripoint.kitware.com. [66.194.253.20]) by smtp.googlemail.com with ESMTPSA id e185sm1504603qkd.13.2016.10.26.10.47.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Oct 2016 10:47:50 -0700 (PDT) In-Reply-To: X-Original-Sender: mwoehlke.floss@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of mwoehlke.floss@gmail.com designates 2607:f8b0:400d:c0d::235 as permitted sender) smtp.mailfrom=mwoehlke.floss@gmail.com; dmarc=pass (p=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:29119 Archived-At: On 2016-10-26 13:22, hguijtra@xs4all.nl wrote: > On Wednesday, October 26, 2016 at 6:24:12 PM UTC+2, Nicol Bolas wrote: >> With include guards, the question is effectively moot. Every user does >> their best to avoid include guard clashing, so there is no question of what >> "same file" means. It means having included that define. > > If you throw the whole issue into the lap of the user you end up with the > exact same problem, reversed: what if two different files have the same > include guards? ....then you don't include the second one. This is not an unreasonable choice; what if the two files with different contents are different versions of the "conceptually" same file? If you include it twice (which is what #pragma once would presumably do), you are also going to have problems. Possibly worse problems than if you only include one of them (e.g. if they are different but source-compatible). > This has actually happened to me - I mistakenly put the same include > guards into two different files. Silly mistake, but it certainly > made for some interesting debugging... There are tools to avoid this sort of problem. > The two situations are symmetric, but #pragma once has a clear > performance advantage (since there is no need to re-parse the entire > header to find out whether what look like include guards, really > are) No, it has no such "clear performance advantage". Compilers can and do implement the same optimization for traditional include guards, so this is moot. As you would know if you had actually *read* the SO answer Andrey posted. Do. Your. Homework. > Any project that has some weird setup where the same header is > included multiple times into the same compilation unit through > hardlinks can still use include guards. Right. And since those headers may come from third party libraries, *everyone* must use include guards. It's more likely that a leaf project might get away with #pragma once than a widely used library. > Or if you truly think it's an issue, make the compiler finds whatever > passes for a unique identifier for includeable objects (whether they > are files or not), and use that as your identifier. Right. That's the problem that *you* need to solve. >> The standard specifies behavior. If some behavior cannot be fully pinned >> down, then the standard cannot specify what happens. > > Don't make me laugh. The standard is absolutely chockful of implementation > defined situations, not to mention throwing around undefined behaviours > like they were going out of style. Adding one more bit of > implementation-defined behaviour will not make a difference. But what is the *point* of standardizing a feature if *the entire definition of the feature* is that it's implementation defined? In what way is that different from the situation today? (Wait... that's *already* the case; #pragma is already implementation defined. What exactly, then, are you proposing to change?) > The compiler is gifted with a method for finding and loading whatever > is specified after #include (whether files, or something else). If it > can figure out where to load it from, it can also figure out whether > it has done that before. Not if it finds an identical file in a different path. -- Matthew -- 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/5810EC44.50807%40gmail.com. .