220 29208 <58137760.6070202@gmail.com> article Path: news.gmane.org!.POSTED!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: pragma once Date: Fri, 28 Oct 2016 12:05:52 -0400 Lines: 77 Approved: news@gmane.org Message-ID: <58137760.6070202@gmail.com> References: <2c278558-0dbc-4568-9b6b-7f159c94707e@isocpp.org> <4610802.tOzma7na2T@tjmaciei-mobl1> <58136277.409@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1477670796 23091 195.159.176.226 (28 Oct 2016 16:06:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Oct 2016 16:06:36 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBBYXOZXAAKGQE6NVYFHQ@isocpp.org Fri Oct 28 18:06:31 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f199.google.com ([209.85.217.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c09fE-0000wr-HU for gclcip-std-proposals@m.gmane.org; Fri, 28 Oct 2016 18:05:52 +0200 Original-Received: by mail-ua0-f199.google.com with SMTP id g16sf588050uab.4 for ; Fri, 28 Oct 2016 09:05:55 -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:content-transfer-encoding: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=Cl0iHzQBRTn0vt+vNlXOn7MYO20cMPehCuIlpsY6L80=; b=Byu/FwM5gi+BjQlSTJkBa5blogRRtAIQqi2yUczu2pzCsyZYMMnG+2n+lVq629w+2p WEpyp5Dm5XRoB0xTG61merb273kx21Ls6L3UTsUs4aSGMdjKMgDHkajt5PrPYzR21JUe TnhzopfYg/6vr2bU/G2KyT85sdh3SNmSgv+CKB8U5vfUol8zVtGE316byiyjIRRjqhEy aNZHqBpocYvouBeZMPRh/OvmcYwB8z5XFS7z2jhMu1N1Gb3RnEBxaGUSLOFs8tMLMEur SkHLYGFZRGx2Ny6mELDCx1p65DEpb8xRvLFegd6pTm6VOLdnVOrXKC1opVtoaxidaryq 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:content-transfer-encoding :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=Cl0iHzQBRTn0vt+vNlXOn7MYO20cMPehCuIlpsY6L80=; b=M53TYpDhzi1rDjYSl7s8M5FeO0DsDhlZffFm89lWtaEtVjX0AWaZ7JiXST194SAsv6 Y9wZYA8H8D4sVTFep+YXqwFzzhxJixpXzF+kgjtqaR0Gi7cDIxaHDHiaO2bzCUOAvqn8 o/5RL2GXrgR9hsC8v/DvWmo0/qGDA9TQ8szvrF91qD3705XfNIrBMGOtvM616uGd/EqW qPVV+R17qLMo46QV41Nbqby4e4wT8+A2IsWMup9CwVIhkc1Ky7ovsk4y2CnNnoYaJPap igeOlErg/+8niibxhtmDTIeoX1Pueup4D5pFRHRuNrsqWYn+AelWt9SnoqBaSJjoU/7L X-Gm-Message-State: ABUngvfD12V8noSRZrr0gDEBoHswjhxOt+UTbVYpgr5xyZ29lqmFyaBl6EiqcMiq1TOyDg== X-Received: by 10.31.193.73 with SMTP id r70mr4809903vkf.40.1477670755035; Fri, 28 Oct 2016 09:05:55 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.60.4 with SMTP id q4ls7196408otc.29.gmail; Fri, 28 Oct 2016 09:05:54 -0700 (PDT) X-Received: by 10.129.177.3 with SMTP id p3mr13076743ywh.24.1477670754251; Fri, 28 Oct 2016 09:05:54 -0700 (PDT) Original-Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com. [2607:f8b0:400d:c09::22a]) by mx.google.com with ESMTPS id d66si5526868ywb.463.2016.10.28.09.05.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Oct 2016 09:05:54 -0700 (PDT) Received-SPF: pass (google.com: domain of mwoehlke.floss@gmail.com designates 2607:f8b0:400d:c09::22a as permitted sender) client-ip=2607:f8b0:400d:c09::22a; Original-Received: by mail-qk0-x22a.google.com with SMTP id z190so91509111qkc.2 for ; Fri, 28 Oct 2016 09:05:54 -0700 (PDT) X-Received: by 10.55.191.135 with SMTP id p129mr13384092qkf.279.1477670753452; Fri, 28 Oct 2016 09:05:53 -0700 (PDT) Original-Received: from [192.168.1.173] (tripoint.kitware.com. [66.194.253.20]) by smtp.googlemail.com with ESMTPSA id 65sm6584785qth.0.2016.10.28.09.05.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Oct 2016 09:05:52 -0700 (PDT) In-Reply-To: X-Original-Sender: mwoehlke.floss@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of mwoehlke.floss@gmail.com designates 2607:f8b0:400d:c09::22a as permitted sender) smtp.mailfrom=mwoehlke.floss@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:29208 Archived-At: On 2016-10-28 11:02, Miro Knejp wrote: > On 28 Oct 2016, at 16:36 , Matthew Woehlke wrote: >> On 2016-10-27 19:48, Miro Knejp wrote: >>> It unfortunately doesn't solve the problem of having to come up wth a >>> guard that is unique within the multiverse. For example boost_date_time >>> has an include guard called ISO_FORMAT_HPP___. That's not exactly the >>> most unique guard in the world. The less this relies on human >>> (non-)creativity or discipline the better. >> >> Um... >> >> #once boost::date_time::iso_format >> >> QED. >> >> I also suggested that compilers *might* be able to go as far as warning >> if the namespace of the guard "looks suspicious". It *will* squawk at >> you if you get the `iso_format` part wrong. > > If you can specify a behavior that is consistent and won=E2=80=99t annoy > anyone, sure. The unqualified name shall match the basename of the included file. (There are some corner cases, but since this is a non-mandated diagnostic, we can figure them out as they come. If the include is via a pipe or something strange, this check would likely be skipped, which is somewhat unfortunate, but no worse than the current situation.) > The author of boost_date_time obviously didn=E2=80=99t consider it necess= ary=20 > to prefix the guard with BOOST_whatever so who knows what the > associated #once guard would have looked like. I believe much of why traditional guards are ugly and inconsistent is... because they're preprocessor symbols. Programmers have ingrained notions about how those should look. #once is explicitly *not* a preprocessor symbol; it is a qualified C++ identifier (albeit one that exists in a namespace that is unrelated to any actual C++ code). By changing the paradigm, the hope is that people would get in the habit of using proper names, the same as for e.g. class names. Besides, it would be easy to warn if you didn't use *any* namespace, which would at least discourage simple laziness / ignorance. And, really, this doesn't need to be hard. The obvious intent is that the guard should have a namespace that is consistent with the namespace of the stuff declared in the header. Or, if you don't namespace your declarations, at least have a namespace that is e.g. the name of your library or project. > Furthermore if you have to specify an identifier that the compiler > should somehow associate with the file and its content then that > means the compiler actually has to fully parse and analyze the > content instead of just preprocessing the header guard with some > heuristics. This is QoI and not required by the proposal. Also, the intent is that the warning would be generated *after* the file is parsed (i.e. at EOF). Trying to guess if you used an appropriate namespace is nice, but if we can't have it, it's not a terrible loss. After all, *any* level of checking is better than we have today. --=20 Matthew --=20 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 e= mail 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/58137760.6070202%40gmail.com. .