220 14339 article Path: news.gmane.org!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: #pragma once Date: Thu, 30 Oct 2014 17:54:18 -0700 Lines: 168 Approved: news@gmane.org Message-ID: 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=089e013cb9bed7db460506ad6f71 X-Trace: ger.gmane.org 1414716879 19886 80.91.229.3 (31 Oct 2014 00:54:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Oct 2014 00:54:39 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDVNBJG4YAIBBO53ZORAKGQE2BXBCLQ@isocpp.org Fri Oct 31 01:54:33 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f198.google.com ([209.85.213.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xk0Ts-0000ym-S4 for gclcip-std-proposals@m.gmane.org; Fri, 31 Oct 2014 01:54:21 +0100 Original-Received: by mail-ig0-f198.google.com with SMTP id hl2sf403558igb.5 for ; Thu, 30 Oct 2014 17:54:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from: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:content-type; bh=vYBmuWL9lIeOfG97lhaKpQ9Vc/BhFjzowv5J1slNTOY=; b=C5r8mjAtwkTcBcFLyUmfTGUVLw+IAbNSMJ0U2vPd+6Smu9Ax3cy9tgiEK3NaO4eAXy 1a/hrwWdE62nQWLBs6cSCToVObUaYysXSCZm3j0jwBFeRmhqHHnp5PtcopBI0+1i8vZb R17gKin+R2EB7+VPASnPTm+ZTgQof13uSndp01BAM0MpqrqUO+pl8FXCKvqDL9El6Pbw T7LJ+lPnjxU9H2cNxy2TvvWybB6D0KqmAwj+IBrWvfRr4cDwYQ7R+O8TcRHRfMZEVD5Z Qn69uPC4Bulh+lwDKDcwaA055pt1wTm/DbFun/mjh+K7DYnVfV7/7Pqq+LBsq3eH9p76 fxOw== X-Gm-Message-State: ALoCoQkjyLlcjAUuOL6UHrRnb5s4yrZvZcbeVez/NPUwL8706nuelTNecM1vKVQ6iHjzUQcrWCZa X-Received: by 10.50.43.228 with SMTP id z4mr336884igl.4.1414716860184; Thu, 30 Oct 2014 17:54:20 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.85.115 with SMTP id m106ls1474748qgd.21.gmail; Thu, 30 Oct 2014 17:54:19 -0700 (PDT) X-Received: by 10.236.61.84 with SMTP id v60mr10445997yhc.121.1414716859373; Thu, 30 Oct 2014 17:54:19 -0700 (PDT) Original-Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com. [2607:f8b0:4002:c01::22a]) by mx.google.com with ESMTPS id s7si8650775yha.37.2014.10.30.17.54.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 17:54:19 -0700 (PDT) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:4002:c01::22a as permitted sender) client-ip=2607:f8b0:4002:c01::22a; Original-Received: by mail-yh0-f42.google.com with SMTP id 29so2396946yhl.1 for ; Thu, 30 Oct 2014 17:54:19 -0700 (PDT) X-Received: by 10.221.5.65 with SMTP id of1mr15127477vcb.6.1414716859077; Thu, 30 Oct 2014 17:54:19 -0700 (PDT) Original-Sender: metafoo@gmail.com Original-Received: by 10.220.65.138 with HTTP; Thu, 30 Oct 2014 17:54:18 -0700 (PDT) In-Reply-To: <74333631-4806-48a5-914a-0f186b8c8026@isocpp.org> X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:4002:c01::22a as permitted sender) smtp.mail=metafoo@gmail.com; dkim=pass header.i=@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:14339 Archived-At: --089e013cb9bed7db460506ad6f71 Content-Type: text/plain; charset=UTF-8 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. On Wednesday, October 22, 2014 8:29:21 AM UTC+13, Myriachan wrote: > >> I think that #pragma once should be standardized - at least >> partially/optionally/conditionally-supported. Every major compiler >> implements it with identical or nearly-identical semantics. >> >> Defining what it means for a file to be a repeat is rather simple: On >> platforms supporting symlinks and hard links, use unique inode numbers (+ >> device if needed). On other platforms, use the filename. Compilers may >> assume that files don't change while compiling (i.e. if the filename >> matches, it can be assumed to be identical). On platforms where there >> exist special links to the same or parent directory, like "./" or "../" on >> NT and POSIX, this assumption can be extended to collapse these. >> >> By the way, why don't _Pragma and #line support concatenating multiple >> strings in their respective string parameters? >> >> 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/. > -- --- 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/. --089e013cb9bed7db460506ad6f71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Oct 30, 2014 at 4:54 PM, <gmisocpp@gmail.com> wrote:
Hypothetical:
<= div>
Ignoring compatibility problems....

=
imagine if #pragma once was the default and=C2=A0some other kind of st= atement=C2=A0existed to change the default=C2=A0where needed e.g.=C2=A0#pra= gma multiple=C2=A0or even #include multiple <x>....

Now imagine=C2=A0if something like this extension was implemented i= n clang...

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

Small (a day or so).
=C2=A0
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 o= f textually-included headers, and we build tools that generate headers, all= of which would need to be updated).
=C2=A0
then finally what do people think woul= d be the=C2=A0speed up=C2=A0(in % build time),=C2=A0if=C2=A0clang (or any p= roject like it) were=C2=A0compiled=C2=A0using that extensions?
<= /blockquote>

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

On Wednesday, October 22, 201= 4 8:29:21 AM UTC+13, Myriachan wrote:
I think that #pragma on= ce should be standardized - at least partially/optionally/con= ditionally-supported.=C2=A0 Every major compiler implements it with identic= al or nearly-identical semantics.

Defining what it means for a file = to be a repeat is rather simple: On platforms supporting symlinks and hard = links, use unique inode numbers (+ device if needed).=C2=A0 On other platfo= rms, use the filename.=C2=A0 Compilers may assume that files don't chan= ge while compiling (i.e. if the filename matches, it can be assumed to be i= dentical).=C2=A0 On platforms where there exist special links to the same o= r parent directory, like "./" or "../" on NT and POSIX,= this assumption can be extended to collapse these.

By the way, why = don't _Pragma = and #line support = concatenating multiple strings in their respective string parameters?
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-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/gro= up/std-proposals/.

--

---
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>.
--089e013cb9bed7db460506ad6f71-- .