220 29120 <30401812-7fc8-481a-abaa-7868d133d778@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: hguijtra@xs4all.nl Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: pragma once Date: Wed, 26 Oct 2016 10:52:19 -0700 (PDT) Lines: 139 Approved: news@gmane.org Message-ID: <30401812-7fc8-481a-abaa-7868d133d778@isocpp.org> References: <5810C33B.9060503@gmail.com> <2908d573-f002-4b58-b0da-18420a816c16@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1965_198579593.1477504339190" X-Trace: blaine.gmane.org 1477504358 10999 195.159.176.226 (26 Oct 2016 17:52:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Oct 2016 17:52:38 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCAJXIV3ZQEBBVG2YPAAKGQEUW4RMRI@isocpp.org Wed Oct 26 19:52:33 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bzSN9-0000k4-Co for gclcip-std-proposals@m.gmane.org; Wed, 26 Oct 2016 19:52:19 +0200 Original-Received: by mail-yw0-f198.google.com with SMTP id u124sf17964110ywg.3 for ; Wed, 26 Oct 2016 10:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=lNOOT2DMBMvdu2yX4ZsaMLep5FWS479x1BnaY8oUuGc=; b=1msz8QeseD4G0oU+oJJxu/v4pZ7hun8D+f8eIlAWln19uU0rsPZi3sT0VTy2UYh+WK JU9wfs7Q46MLuhnrVUBe1SlQxynJ5WmuTdsy0MyJdSwUMaTharkx4lBJ2D4//MGJ8Iwj EBAlVh7vMA5cBg07UlnAVuG6x4VCIPl+de/9rLa5b+bI6L24HtGiEC3Cpx5uxowmw2Au 4PVNeYCI0amtao8zHqD4ITNwLCPRy/y3EMC3/9GPfwm9ARs1tyDosQHeO5Wdz7pBmdAn Q6oqiwRXhYI9wYmqMzUNYm1OmSHACiaqcfou+IdIpWLls5iXXm3kTiClfgxwiQorsMcZ Ozdg== 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:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=lNOOT2DMBMvdu2yX4ZsaMLep5FWS479x1BnaY8oUuGc=; b=IYquICVeKxgss2wET+SX9cEU1N490XfstIKh0l+xUW14sfnIRjem9mrrF/tmit7V/5 bTJSfC3BartXcd4AU1K86UtrEuoXcnw01LC7yy1XbvykTBbbyJVjxP9z2ZDA7uEeuzBW sCG1LsoedfDmv5VBE/Paaomz6NSKYvtXJ+GILgp+rtD1DsZUsKxwtGYr1LtjTWlsXEUq c8EYxUkcwewxoGQcjdHHwqJFjAF1k9k8nlFWUzQX/Kmzr5Q/8LL/cavrTsHenuXhCIN2 txdMsZWWdtnMO+o6fLhPqB4hcCnbyUr45hCE9oEQ7zWWiQHnZYKH8W02cOoh5oqk0bbW qoZg== X-Gm-Message-State: ABUngvffFNJIW0D8KxTArUY5uGQMRtzFShduEtrJ8Eejud6+A4Av3lykH6Zop31BxIpPHw== X-Received: by 10.129.104.86 with SMTP id d83mr768396ywc.78.1477504341467; Wed, 26 Oct 2016 10:52:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.132.21 with SMTP id g21ls607599iod.34.gmail; Wed, 26 Oct 2016 10:52:20 -0700 (PDT) X-Received: by 10.36.103.131 with SMTP id u125mr330088itc.3.1477504340538; Wed, 26 Oct 2016 10:52:20 -0700 (PDT) In-Reply-To: X-Original-Sender: hguijtra@xs4all.nl 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:29120 Archived-At: ------=_Part_1965_198579593.1477504339190 Content-Type: multipart/alternative; boundary="----=_Part_1966_243633418.1477504339190" ------=_Part_1966_243633418.1477504339190 Content-Type: text/plain; charset=UTF-8 On Wednesday, October 26, 2016 at 6:15:12 PM UTC+2, Andrey Semashev wrote: > > Nobody is asking for a text comparison (or > > heaven forbid, a semantic comparison). I have some trouble imagining how > > the same header name could resolve to two different files during the > > same compilation. > > The same header can be accessible by different header-name tokens, > depending on where it is included from and what -I switches were > specified. Conversely, the same header-name may resolve to different > headers depending on the implementation and where they are included from. > Do you agree that ultimately, the compiler manages to find each header, somewhere in the multiverse, in a way that is at least repeatable? I'm not asking for it to be a file. I'm not asking for the characters after #include to be unique. I'm not asking for specific behaviour in the presence of directories or search paths or whatever. I'm only asking that if you compile something twice in a row on the same sytem with the same compiler, it will include the same header at each include statement it encounters. Because if there is a repeatable mapping, it means that headers have an identity. And that means you can reliably determine that something was included before, and you can skip that include operation if you performed it before and encountered #pragma once. Now, maybe you need to figure out the "true name" of the header (underlying inode, or whatever passes for an inode in your implementation). That does not, however, seem like an insurmountable problem. > FWIW, #pragma once was broken in gcc prior to 3.4, it was "confused by > symlinks and hardlinks" [1] before that. The bug is long fixed, but it > indicates that those "historical problems" are not imaginary. You may > also google around and see a few more recent bugs related to #pragma > once, like this[2] for example. > "The bug is long fixed" says it all, really. If it was a fundamental problem, the bug could never have been fixed. As for your bug[2] - I'm amazed that identifying, opening, and parsing the file is actually faster than simply identifying it, but don't you agree that this is probably just an implementation issue that could be easily fixed? If you stick all the #pragma once files in a linked list (as likely a choice as any, given that the number of include files in a given compilation is normally relatively low) then loading it with a huge number of files will be slow. As one of the comments says, this could be fixed by using a hashmap. -- 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/30401812-7fc8-481a-abaa-7868d133d778%40isocpp.org. ------=_Part_1966_243633418.1477504339190 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, October 26, 2016 at 6:15:12 PM UTC+2, Andrey= Semashev wrote:
> Nobody is asking for a text comparison (or
> heaven forbid, a semantic comparison). I have some trouble imagini= ng how
> the same header name could resolve to two different files during t= he
> same compilation.

The same header can be accessible by different header-name tokens,=20
depending on where it is included from and what -I switches were=20
specified. Conversely, the same header-name may resolve to different=20
headers depending on the implementation and where they are included fro= m.

Do you agree that ultimately, the compiler manage= s to find each header, somewhere in the multiverse, in a way that is at lea= st repeatable? I'm not asking for it to be a file. I'm not asking f= or the characters after #include to be unique. I'm not asking for speci= fic behaviour in the presence of directories or search paths or whatever. I= 'm only asking that if you compile something twice in a row on the same= sytem with the same compiler, it will include the same header at each incl= ude statement it encounters.

Because if there is a repeatable mappi= ng, it means that headers have an identity. And that means you can reliably= determine that something was included before, and you can skip that includ= e operation if you performed it before and encountered #pragma once.
Now, maybe you need to figure out the "true name" of the header = (underlying inode, or whatever passes for an inode in your implementation).= That does not, however, seem like an insurmountable problem.
=C2=A0
=
FWIW, #pragma= once was broken in gcc prior to 3.4, it was "confused by=20
symlinks and hardlinks" [1] before that. The bug is long fixed, bu= t it=20
indicates that those "historical problems" are not imaginary.= You may=20
also google around and see a few more recent bugs related to #pragma=20
once, like this[2] for example.

"The bug is long fixed" says it all, really= .. If it was a fundamental problem, the bug could never have been fixed.
=
As for your bug[2] - I'm amazed that identifying, opening, and pars= ing the file is actually faster than simply identifying it, but don't y= ou agree that this is probably just an implementation issue that could be e= asily fixed? If you stick all the #pragma once files in a linked list (as l= ikely a choice as any, given that the number of include files in a given co= mpilation is normally relatively low) then loading it with a huge number of= files will be slow. As one of the comments says, this could be fixed by us= ing a hashmap.


--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/30401812-7fc8-481a-abaa-7868d133d778= %40isocpp.org.
------=_Part_1966_243633418.1477504339190-- ------=_Part_1965_198579593.1477504339190-- .