220 14137 <67e8e595-bc97-496a-b656-474cb093b940@isocpp.org> article Path: news.gmane.org!not-for-mail From: Sean Middleditch Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: #pragma once Date: Wed, 22 Oct 2014 12:03:31 -0700 (PDT) Lines: 125 Approved: news@gmane.org Message-ID: <67e8e595-bc97-496a-b656-474cb093b940@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_69_779594313.1414004611066" X-Trace: ger.gmane.org 1414004621 24505 80.91.229.3 (22 Oct 2014 19:03:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Oct 2014 19:03:41 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCDODCNR2QPRBBH7T6RAKGQE5PJPZ3A@isocpp.org Wed Oct 22 21:03:33 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f199.google.com ([209.85.213.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xh1C1-00070x-M9 for gclcip-std-proposals@m.gmane.org; Wed, 22 Oct 2014 21:03:33 +0200 Original-Received: by mail-ig0-f199.google.com with SMTP id hn18sf184413igb.6 for ; Wed, 22 Oct 2014 12:03:32 -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=zd6Cj3EGWna6aOOFOnfmlzm3sFECqgHGyCp3m56/VLs=; b=QxePupgNEBc290Jy32T37jPAFYRIH7QX598QVy7/UQB4qq/4UktmoBmkLK1DWORR5c Ie2aBB8+Uj4wZv2SsTxOESoJhCYmxnePPQ1GElQ5h+EEozRuSkk3xVHhAjqbQCAOA9Qc gCsGVCYROYoTkDkEYDhgvedk8PINVSdBTMLvPqJT393ETZcmL+FX/0pESDsgHIeHkZQ2 3Dt0iua/020qQT96vVIOYAS+5g0slpkKvkX6mnSgXj43/oWQdFHP0/sk8VhylBmhPMOS /QcOYi/S9mZHBTnnu/Ib+FodmTa2xm4yW/tNoZ+D/nwtG990CcwXuBTJ69qTMSsv3MuY 25KA== 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=zd6Cj3EGWna6aOOFOnfmlzm3sFECqgHGyCp3m56/VLs=; b=ULRKH/XOc1dwX3sJq9SQBhIk+lqODd0hPMr/7OnZ9DCYXCbaO1D3HoY8CZM8sRlBCN tO7U8mGks/XWMU/1tU2h2f7bYSkwSo1GfQkipaPO+XkYI57yTHnmly0X3mz1nc00Deaz bKb4h8Qojs+kgNp3sYRTVh6MN81PpboDCf4NMiRRzl8YBLh7xiesE2+uwSPxazYWZZlm inGL5NrJquQcSfKpw0dt1psnxzB4DrP1Vkz30gBviginKOV4uOaxRySnqZEjhD4ypz4D 0BICeeh267Am89Es8CWal82gQk12xRg7ehTGhAgXfR/oGKLTgo59f7NCKzzTL/JXwJeN s/vQ== X-Gm-Message-State: ALoCoQmlVS5CFMwFcphBDqpnhLLVhRfAhWmVBUFv5wktfu5l2jXpqDWz5NM5A4M+nV/6h1oQCZPf X-Received: by 10.182.246.3 with SMTP id xs3mr53921obc.13.1414004612745; Wed, 22 Oct 2014 12:03:32 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.172.2 with SMTP id v2ls682389ioe.1.gmail; Wed, 22 Oct 2014 12:03:32 -0700 (PDT) X-Received: by 10.50.43.232 with SMTP id z8mr106519igl.13.1414004612198; Wed, 22 Oct 2014 12:03:32 -0700 (PDT) In-Reply-To: <11313423.lvzWu67DM3@tjmaciei-mobl4> X-Original-Sender: Sean.Middleditch@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:14137 Archived-At: ------=_Part_69_779594313.1414004611066 Content-Type: text/plain; charset=UTF-8 On Tuesday, October 21, 2014 11:02:35 PM UTC-7, Thiago Macieira wrote: > > On Tuesday 21 October 2014 19:01:36 Myriachan wrote: > > Sure, but that's years off if ever, and there are billions of lines of > code > > in projects using #pragma once now. > > So why do we need to change anything? If that code is already working, > it's 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. 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. A feature similar to #pragma once that simplifies include guards could make sense, but it'll depend on the modules stuff. I'm personally very unimpressed with any of the current modules proposals so perhaps there _is_ value in such a new feature, but it's literally not possible to just standardize #pragma once without forcing most implementations to change their semantics. It would probably have to become something like: #once // must be first directive in file /* rest of file */ which essentially expands to #if !defined() #define /* rest of file */ #endif but maybe with being a separate namespace from preprocessor macros (or not). And perhaps is optional and an implementation-defined one is created based on canonical file path, though that leaves one open to the problems Bo described. Again, it all depends on modules and when they're implemented and how useful they end up being in practice -- --- 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_69_779594313.1414004611066 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, October 21, 2014 11:02:35 PM UTC-7, Thiago Mac= ieira wrote:
On Tuesday 21 Octo= ber 2014 19:01:36 Myriachan wrote:
> Sure, but that's years off if ever, and there are billions of line= s of code=20
> in projects using #pragma once now.

So why do we need to change anything? If that code is already working, = it's

Well, there's value to having de fact= o standards match the de jure standard. See exported templates and their ev= entual removal as an example specific to C++. It's unfortunate when large c= odebases 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 ex= perience, including specifically #pragma once issues.

<= div>
That said, #pragma once couldn't be added to the standar= d any sooner than C++17, and #pragma once _isn't_ a de facto standard becau= se different implementations work differently, and there's the problems wit= h complex source directories Bo mentions, and... I think all the reasons wh= y this won't work were already clearly enumerated in the last thread on thi= s very topic that came up some months ago.

A featu= re similar to #pragma once that simplifies include guards could make sense,= but it'll depend on the modules stuff. I'm personally very unimpressed wit= h any of the current modules proposals so perhaps there _is_ value in such = a new feature, but it's literally not possible to just standardize #pragma = once without forcing most implementations to change their semantics. It wou= ld probably have to become something like:

  =  #once <tag> // must be first directive in file
 =  /* rest of file */

which essentially expand= s to

   #if !defined(<tag>)
<= div>   #define <tag>
   /* rest of file= */
   #endif

but maybe with &= lt;tag> being a separate namespace from preprocessor macros (or not). An= d perhaps <tag> is optional and an implementation-defined one is crea= ted based on canonical file path, though that leaves one open to the proble= ms Bo described.

Again, it all depends on modules = and when they're implemented and how useful they end up being in practice

--

---
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_69_779594313.1414004611066-- .