220 14340 <65f5388d-d22e-4ba0-8aad-248ed0512be3@isocpp.org> article Path: news.gmane.org!not-for-mail From: gmisocpp@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: #pragma once Date: Thu, 30 Oct 2014 19:02:15 -0700 (PDT) Lines: 143 Approved: news@gmane.org Message-ID: <65f5388d-d22e-4ba0-8aad-248ed0512be3@isocpp.org> References: <3d0ab5b0-73d9-434a-9ae4-cd47d8275590@isocpp.org> <74333631-4806-48a5-914a-0f186b8c8026@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_585_1022706586.1414720935367" X-Trace: ger.gmane.org 1414720949 17152 80.91.229.3 (31 Oct 2014 02:02:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Oct 2014 02:02:29 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCM3TRNUXUDBBKG3ZORAKGQEUDCMOUA@isocpp.org Fri Oct 31 03:02:23 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f71.google.com ([209.85.220.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xk1Xe-0000Iw-Tq for gclcip-std-proposals@m.gmane.org; Fri, 31 Oct 2014 03:02:19 +0100 Original-Received: by mail-pa0-f71.google.com with SMTP id rd3sf35739401pab.10 for ; Thu, 30 Oct 2014 19:02:17 -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=un5N5rBrxnC+8Vcemqwn0kS1cqaaqU21ibB3PqVBkb4=; b=ZXaBLdnEwWJG4h0COalXsh7NLyrZiIleOT9V+6XNiWCcsxgLwu/DHRSCbbRNSOkTpB JrQUVfCC7J2hECrWeB3GlcTg9ACbfYoAr+L9/GTgxLLk8Wg2s/UQPI+sS2dVhEkqvT6D 9t8IPyjvm9KjjU0UVkeLVHJhx8lz/nzLnOAI2xTyNJYfl9txhGORi1aIaZ5z9suRNjKC 3nrb548rfbBpOuiDJ7lMetD7J8maHaKIdKizZP3LuJjXXamAy3PvV41b2QeFrlbr9AHk gY9qdatGj2yARyLpkhcCocyA5O+Nnp5zqeDOh0/pbLIWVMbpbN59/NeiUjO2wbBoPTC5 Erhg== 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=un5N5rBrxnC+8Vcemqwn0kS1cqaaqU21ibB3PqVBkb4=; b=YAlml6gJB0Yf0bBpg/oQXu+9oigM5XsomwDStHDkbxWRU6MNyZUhCHtinu+p/75G9F zX+VFPoG4Vscu5sPPABaMyydWweGv3IBHyfg7yPANlSZmTRz3FyatU/M7Ie1Rp8kUKNV tFNRaZTl+TurUVm8DN5TJV3d+jsCfjfeQDEXZLhEfkyHmwiZC/1MKdF2n2AEEmd+tZ/i umqYZbMBcWPxrPJ8BfmZqHN07au82kaE1SKq9kHpgEBX8b1NmDtn9YlzWZsKkks+V5Gw WE7zXPsRTbgQLmjHkXoHOG62XHIslPxLSy9nbi6LnUpucizX3fLHCE6+wXgwjfS1YjBR +hHQ== X-Gm-Message-State: ALoCoQnOEqAIRNdUs1ijgAzx3Zo4ec8syv6thw+U/0MMD016cPHmKRyOuTtrGA9o82BrGrwVT35C X-Received: by 10.66.150.162 with SMTP id uj2mr15119261pab.35.1414720937534; Thu, 30 Oct 2014 19:02:17 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.20.3 with SMTP id j3ls67003ige.18.canary; Thu, 30 Oct 2014 19:02:16 -0700 (PDT) X-Received: by 10.50.112.67 with SMTP id io3mr6647igb.14.1414720936814; Thu, 30 Oct 2014 19:02:16 -0700 (PDT) In-Reply-To: X-Original-Sender: gmisocpp@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:14340 Archived-At: ------=_Part_585_1022706586.1414720935367 Content-Type: text/plain; charset=UTF-8 On Friday, October 31, 2014 1:54:20 PM UTC+13, Richard Smith wrote: > > On Thu, Oct 30, 2014 at 4:54 PM, > wrote: > >> Hypothetical: >> >> Ignoring compatibility problems.... >> >> imagine if #pragma once was the default and some other kind of >> statement existed to change the default where needed e.g. #pragma >> multiple or even #include multiple .... >> >> Now imagine if something like this extension was implemented in clang... >> >> First, what to people think would be the effort (in days) to implement >> that change in the clang compiler itself (i.e. to support the new semantics >> and keywords),? >> > > Small (a day or so). > > >> then what do people think would be the effort (in days) to convert the >> project itself to use that extension... (i.e. add the keywords where the >> default #once doesn't work)? >> > > Small (a day or so; we have a lot of textually-included headers, and we > build tools that generate headers, all of which would need to be updated). > > >> then finally what do people think would be the speed up (in % build >> time), if clang (or any project like it) were compiled using that >> extensions? >> > > I would not expect any measurable difference. We already detect include > guards and get all the performance benefits of #pragma once from them. > > Thanks Richard! ok, so does that mean then that making #pragma once Standard does nothing for performance, it just adds a nice convenience of not having to have #include guards but one still has to be mindful of multiple inclusion each time. Making #pragma once Standard would also helps by making some existing code, Standard code. By contrast, #pragma multiple (or whatever) as a new feature, would mean breaking some existing code, but even for pretty large projects, fixing it would only be a days work and some of that time would be recouped by the fact that nobody would need to write or fix a broken include guard ever again in the project, or any new one ever... I don't imagine anyone would ever go for that contrasting option, but I thought it was worth throwing it out there to see if it was viable. -- --- 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_585_1022706586.1414720935367 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, October 31, 2014 1:54:20 PM UTC+13, Ric= hard Smith wrote:
On Thu, Oct 30, 2014 at 4:54 PM, <= ;gmis...@gmail.com> wrot= e:
Hypothetical:

Ignoring compatibility problems....

imagine if #pragma once was the default and some other kind of = statement existed to change the default where needed e.g. #p= ragma multiple or even #include multiple <x>....

<= /div>
Now imagine if something like this extension was implemented= in clang...

First, what to people think would be = the effort (in days) to implement that change in the clang compiler it= self (i.e. to support the new semantics and keywords),?

Small (a day or so).
 
then what do people think would= be the effort (in days) to convert the project itself to use that extensio= n... (i.e. add the keywords where the default #once doesn't work)?

Small (a day or so; we have a lot of te= xtually-included headers, and we build tools that generate headers, all of = which would need to be updated).
 
then finally what do people think would be t= he speed up (in % build time), if clang (or any project= like it) were compiled using that extensions?

I would not expect any measurable difference. We = already detect include guards and get all the performance benefits of #prag= ma once from them.

=
Thanks Richard!

ok, so does that me= an then that making #pragma once Standard does nothing for performance= , it just adds a nice convenience of not having to have #inc= lude guards but one still has to be mindful of multiple inclusion each time= .. Making #pragma once Standard would also helps by making so= me existing code, Standard code.

By contrast, = ; #pragma multiple (or whatever) as a new feature, would mean bre= aking some existing code, but even for pretty large projects, fixing i= t would only be a days work and some of that time would= be recouped by the fact that nobody would need to write or fix a= broken include guard ever again in the project, or any new one ever...

I don't imagine anyone would ever go for that contras= ting option, but I thought it was worth throwing it out there to see if it = was viable.

--

---
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_585_1022706586.1414720935367-- .