220 29112 article Path: news.gmane.org!.POSTED!not-for-mail From: Andrey Semashev Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: pragma once Date: Wed, 26 Oct 2016 19:15:07 +0300 Lines: 122 Approved: news@gmane.org Message-ID: 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: text/plain; charset=UTF-8; format=flowed X-Trace: blaine.gmane.org 1477498544 28016 195.159.176.226 (26 Oct 2016 16:15:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Oct 2016 16:15:44 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCXY5TXHWYJRBDVNYPAAKGQEECICATA@isocpp.org Wed Oct 26 18:15:36 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f69.google.com ([74.125.82.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bzQr7-00034w-83 for gclcip-std-proposals@m.gmane.org; Wed, 26 Oct 2016 18:15:09 +0200 Original-Received: by mail-wm0-f69.google.com with SMTP id l201sf15866345wmg.13 for ; Wed, 26 Oct 2016 09:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=BM4CJYekoP2+f6nD82ZXgEDUPwSXUcesP9+iBtFHMpg=; b=v5oREnAih30M20G1FpOFUcK410X4Dunic9r8c+KOZzgnA9ZGYn6yNModxQTPFrcmSl Daw38JQYPx+D3TpGHChbcwlurvDOpPSkEDlQsNnexeEMZfmi6mRazK5k4ny52rh2WPGw ojfC7tPv8YNx8Mcy/VzS3mtCacSMDJV+35ioo9EMRteJ9XPnvwxsZvDEPbAy63KlN/wo l9xMXBs+9oN+tI/M9/LPxSDL06tFclipxC2KGKuJI0L8s0IKqBcUvJtY2Et3uC3mfFRD XIrdw1qdBKIr8M3GK1Qzzs6pala2O2C+iSnNaf8qtt13FG/Th/46gtaqzuWX6UBxYIui tVxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=BM4CJYekoP2+f6nD82ZXgEDUPwSXUcesP9+iBtFHMpg=; b=XypZcsM8BANSqA3bM8ed9cg3ZI2m+t7IY1Fe/xlCL5Wm57Ax4IdFnnNkgBlHQtCzhd uh8UJywA3zsh6m2Plc9PRss+0mQQdL2zJA6vwG8X07QTW9myzA1qSTpGpbjyxGGqGOKT UaZPvxO2IVVY4oLN0tkovJd3kHp7yQGpAi/A7nFQEaV++I08i436BDNRefC+ArUFFDu0 Uyacb28lM8JfqqbL8Y258hAjJFxDhwqaAevy/Ol+ppLC8qK5XVSHmq1O/nN3jGgGnWN1 pYbxJg6sTAWRxKFF6bFaU+msGB1Nt0XF6sGm38JOT2PAGuxxbOkioGW1DP8ca826sc5C jifA== X-Gm-Message-State: ABUngvcAOaNqj9jwupkY8xa8E1LGqotVCD3rbZGZi4URBGkM1X9alJolhOVzPP/TWPVJbg== X-Received: by 10.194.134.101 with SMTP id pj5mr267475wjb.15.1477498511728; Wed, 26 Oct 2016 09:15:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.154.196 with SMTP id c187ls164952lfe.48.gmail; Wed, 26 Oct 2016 09:15:09 -0700 (PDT) X-Received: by 10.25.160.21 with SMTP id j21mr2454277lfe.166.1477498509744; Wed, 26 Oct 2016 09:15:09 -0700 (PDT) Original-Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com. [2a00:1450:4010:c07::22f]) by mx.google.com with ESMTPS id n63si1819290lfd.270.2016.10.26.09.15.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Oct 2016 09:15:09 -0700 (PDT) Received-SPF: pass (google.com: domain of andrey.semashev@gmail.com designates 2a00:1450:4010:c07::22f as permitted sender) client-ip=2a00:1450:4010:c07::22f; Original-Received: by mail-lf0-x22f.google.com with SMTP id t133so9563612lff.6 for ; Wed, 26 Oct 2016 09:15:09 -0700 (PDT) X-Received: by 10.25.40.204 with SMTP id o195mr2179907lfo.160.1477498508887; Wed, 26 Oct 2016 09:15:08 -0700 (PDT) Original-Received: from [192.168.1.2] (broadband-90-154-68-136.nationalcablenetworks.ru. [90.154.68.136]) by smtp.googlemail.com with ESMTPSA id 187sm522478ljj.4.2016.10.26.09.15.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Oct 2016 09:15:07 -0700 (PDT) In-Reply-To: <2908d573-f002-4b58-b0da-18420a816c16@isocpp.org> X-Original-Sender: andrey.semashev@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of andrey.semashev@gmail.com designates 2a00:1450:4010:c07::22f as permitted sender) smtp.mailfrom=andrey.semashev@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:29112 Archived-At: On 10/26/16 18:28, Hans Guijt wrote: > On Wednesday, October 26, 2016 at 4:52:45 PM UTC+2, Matthew Woehlke wrote: > > The problem, besides that the C++ language says nothing about > headers in > the first place, is that determining if a header has been included or > not is much more complicated than you think, even on platforms that > *actually have a file system* (which is _not_ a requirement for a C++ > compiler!). > > You're reading a really strange copy of the standard then. Mine has a > table of "C++ library headers", and a definition what a header-name is. > And a great portion of it is dedicated to describing all those headers. > Perhaps you are confused by the fact that headers do not have to be files? For the record, header-name is defined in [lex.header]. In particular, it says: The sequences in both forms of header-names are mapped in an implementation-defined manner to headers or to external source file names as specified in 16.2. And 16.2 leaves the interpretation of the header-name pretty much to the implementation. There may well be no files at all in the filesystem that correspond to headers described in the standard. > What should happen if you include the same header (same inode) via > different names? What about if the compiler sees two identical include > directives (same path, same <> vs. "") that resolve to different files > with different contents? What about platforms with esoteric file > systems, or *no* file system? > > This is an attempt at complication of a painfully simple feature. You > don't want it, so you just ask meaningless questions that have trivial > answers in the hope of convincing others it is all incredibly > complicated, while it really isn't. I think you should do more research before making claims like that. > As for answers: it doesn't matter, as long as some kind of deterministic > behaviour is specified. I don't see a problem with including a file > twice if a symlink exists; after all, you could just copy it and include > it twice that way as well. I'm certainly not ok with ignoring symlinks. There are quite a few symlinks in my /usr/include; if headers used #pragma once there and it didn't work, it would be a disaster. > 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. | |-a | |- x.h | |- a.h | |-b | |- x.h | |- b.h | |- main.cpp main.cpp: #include "a/a.h" #include "b/b.h" a.h: #include "x.h" b.h: #include "x.h" If the implementation includes the directory of the including header into the lookup list for the "" syntax (most compilers do) then a.h and b.h will include different x.h. > And the presence of a file system does not matter - > one way or another, headers are found and read by the compiler. That > process can be influenced using #pragma once, based on nothing more than > the h-char-sequence or q-char-sequence of the header name. Wrong, as shown above. > Yes, there are implementations that "mostly work", but there is a > higher > bar for standardization. Any serious proposal needs to address the > problems that have been raised historically. Claims / requests like > "compilers already do this, why not just make it official" are > inadequate. > > Can you show an example of #pragma once failing? Otherwise claims like > "mostly work" are just so much noise in the wind. Your "historical > problems" seem a collection of far-fetched issues that have no bearing > on real-life development. And thanks to your comments, I can now add the > claim that this is a feature commonly requested by the C++ community. 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. [1]: https://gcc.gnu.org/gcc-3.4/changes.html [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58770 -- 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/bdd21365-4aab-9463-a384-84afaec533b8%40gmail.com. .