220 14139 <4039b7bf-7177-4863-ae3f-3b81b0cfb435@isocpp.org> article Path: news.gmane.org!not-for-mail From: Myriachan Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: #pragma once Date: Wed, 22 Oct 2014 14:27:56 -0700 (PDT) Lines: 115 Approved: news@gmane.org Message-ID: <4039b7bf-7177-4863-ae3f-3b81b0cfb435@isocpp.org> References: <3d0ab5b0-73d9-434a-9ae4-cd47d8275590@isocpp.org> <202c5550-8669-4b45-aa39-9a8d26c37015@isocpp.org> <93885a74-f1c7-4c85-9309-7bd878f08670@isocpp.org> <11313423.lvzWu67DM3@tjmaciei-mobl4> <67e8e595-bc97-496a-b656-474cb093b940@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_35_1636256856.1414013276033" X-Trace: ger.gmane.org 1414013287 6007 80.91.229.3 (22 Oct 2014 21:28:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Oct 2014 21:28:07 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDKLT4PURQHRBXOCUCRAKGQEGO56N3I@isocpp.org Wed Oct 22 23:28:00 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f200.google.com ([209.85.213.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xh3Rm-0001XP-Mx for gclcip-std-proposals@m.gmane.org; Wed, 22 Oct 2014 23:27:58 +0200 Original-Received: by mail-ig0-f200.google.com with SMTP id h3sf760872igd.7 for ; Wed, 22 Oct 2014 14:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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 :content-type; bh=QEH19EjXbtjJAT7HuC8Skj8UshEbvy99N8eo8cOKFo0=; b=BT2zgViKxE4yomr9ytPogLLSrx3nLp9JmJFBXiJsX2h8BdV2kfMLOADZHKOyO8gZKZ c/v+1Xn8+TSJXxMs2Uoma3+TUopegb2Bx0f+PY4ImyHLjVDK8RdXPziE69dhrMYcqvtF ayGr4TDyCr1Oi0iik1K7OGUNzgZKVoZhP2263MPsN9djUG1/Bc/S4DH114nFqBcTqZ1P pVybpgOg/pjZSy+o7tsi45c6P8xCNXbCm8JVe2sx7ZpwAI0nVfH8V7/sThNoQFCHrL0Y iHPpIjLB1zxB+JS3dKapRpT4gDbKptkqLUXkIedOJxa5kuCBmN/umL/TpDEG7JXX/4LP 2zbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=QEH19EjXbtjJAT7HuC8Skj8UshEbvy99N8eo8cOKFo0=; b=MPKlyt7YNjmYPyCCK5BBatU+nhEAN5wo7F54use5VSqVtnY6ewnWMKKrpLWUiAdKKa 8RS4dyDFHChzl2/n8mxu20Ypi6bFr3D/NwsmN4d/+ORpt5poDITjulNqHmYB4FIpuSzK /j3uFIgLizNlKWEK1vBck0UU28Tjptb8R9C4NER5t+cXTKoW9Gh+SP7lCiPMtp7ud3eU rsJHLMyEiewXVIE+oKNyVGqO144tYYwRPNK1QZPwVRvZxew3PsqCRyFYj1LMk+1CELuA RZM/6SzoGMq6FOrj1ScdesmewrY6pyC/RI3kw/28BvSpB1bj0TQSKs6+ulpgpNZ4qp9u yAgg== X-Gm-Message-State: ALoCoQkIlucwL+ogsuyvZ735zc7Rd+1AmSnismLApfjlQd5aeuze2JV/d4J7w9jNQR9t3C94cpMx X-Received: by 10.182.81.199 with SMTP id c7mr648898oby.3.1414013277790; Wed, 22 Oct 2014 14:27:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.20.137 with SMTP id n9ls704750ige.25.gmail; Wed, 22 Oct 2014 14:27:57 -0700 (PDT) X-Received: by 10.50.117.74 with SMTP id kc10mr452492igb.4.1414013277231; Wed, 22 Oct 2014 14:27:57 -0700 (PDT) In-Reply-To: <67e8e595-bc97-496a-b656-474cb093b940@isocpp.org> X-Original-Sender: myriachan@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:14139 Archived-At: ------=_Part_35_1636256856.1414013276033 Content-Type: text/plain; charset=UTF-8 On Wednesday, October 22, 2014 12:03:31 PM UTC-7, Sean Middleditch wrote: > > Well, there's value to having de facto standards match the de jure > standard. See exported templates and their eventual removal as an example > specific to C++. It's unfortunate when large codebases depend on a > non-standard feature that "works" but is non-standard and then new tools > that more closely follow the standard without extensions can't handle the > codebase. Happens all the time with game engines in my experience, > including specifically #pragma once issues. > > ^ This (except I'd reverse *de facto *and *de jure* for clarity). > > That said, #pragma once couldn't be added to the standard any sooner than > C++17, and #pragma once _isn't_ a de facto standard because different > implementations work differently, and there's the problems with complex > source directories Bo mentions, and... I think all the reasons why this > won't work were already clearly enumerated in the last thread on this very > topic that came up some months ago. > > #pragma once's behavior among compilers only really differs when the source tree is in a traditional directory structure without any weirdness happening. Most of the other behavior is obvious: identify files by their (volume ID, inode) pair. I would specify #pragma once's behavior to be unspecified (but either include or not include) in the event that the implementation cannot reliably determine whether two files coincide. If you want your code to work, don't create a situation where you expect a file to not be double-included when the codebase accesses it through two different mount points for which the OS cannot identify them as identical or overlapping. Sometimes #include guards have problems. You can easily run into cases where two unrelated headers think they're both the same name. That said, Bo does have a point about the inability to work around mistakes, or do sneaky tricks. For example, how in at least one Linux installation I saw is implemented as #undefining 's #include guard, #define-ing __STDC_CONSTANT_MACROS, and #include-ing . Melissa -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_35_1636256856.1414013276033 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, October 22, 2014 12:03:31 PM UTC-7, Sean Mid= dleditch wrote:
Well, there's value to having de facto standards match the de jure standa= rd. See exported templates and their eventual removal as an example specifi= c to C++. It's unfortunate when large codebases depend on a non-standard fe= ature that "works" but is non-standard and then new tools that more closely= follow the standard without extensions can't handle the codebase. Happens = all the time with game engines in my experience, including specifically #pr= agma once issues.


^ This (except = I'd reverse de facto and de jure for clarity).
 
<= /div>

That said, #pragma once couldn't be added to the sta= ndard any sooner than C++17, and #pragma once _isn't_ a de facto standard b= ecause different implementations work differently, and there's the problems= with complex source directories Bo mentions, and... I think all the reason= s why this won't work were already clearly enumerated in the last thread on= this very topic that came up some months ago.


#pragma once's behavior among compilers only really dif= fers when the source tree is in a traditional directory structure without a= ny weirdness happening.  Most of the other behavior is obvious: identi= fy files by their (volume ID, inode) pair.

I would specify #pragma o= nce's behavior to be unspecified (but either include or not include) in the= event that the implementation cannot reliably determine whether two files = coincide.  If you want your code to work, don't create a situation whe= re you expect a file to not be double-included when the codebase accesses i= t through two different mount points for which the OS cannot identify them = as identical or overlapping.

Sometimes #include guards have proble= ms.  You can easily run into cases where two unrelated headers think t= hey're both the same name.

That said, Bo does have a point about the= inability to work around mistakes, or do sneaky tricks.  For example,= how <cstdint> in at least one Linux installation I saw is implemente= d as #undefining <stdint.h>'s #include guard, #define-ing __STDC_CONS= TANT_MACROS, and #include-ing <stdint.h>.

Melissa

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_35_1636256856.1414013276033-- .