220 29176 article Path: news.gmane.org!.POSTED!not-for-mail From: Miro Knejp Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: pragma once Date: Fri, 28 Oct 2016 01:48:54 +0200 Lines: 52 Approved: news@gmane.org Message-ID: References: <2c278558-0dbc-4568-9b6b-7f159c94707e@isocpp.org> <4610802.tOzma7na2T@tjmaciei-mobl1> 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 1477612048 17943 195.159.176.226 (27 Oct 2016 23:47:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 27 Oct 2016 23:47:28 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC6ONSXJ54LBBAFEZLAAKGQE27XELDQ@isocpp.org Fri Oct 28 01:47:24 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f70.google.com ([74.125.82.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bzuO5-0002Lm-SX for gclcip-std-proposals@m.gmane.org; Fri, 28 Oct 2016 01:47:09 +0200 Original-Received: by mail-wm0-f70.google.com with SMTP id i128sf19599620wme.2 for ; Thu, 27 Oct 2016 16:47: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=v/yFrMaZvWoGuEQ7N4fZdTxCDE3V6+kZiDwNdMMZ9lk=; b=Y14pxC23HNrrJt37IbKZIFw8Ze17c4uXDGxAJ8kVy9JiZdifxBF/+IuZspbn9NYjqo 0QQhflmCeCLK7MpDETJATxa9SfyiV7vj+JUJvCdLk2XdeUmgovhau3KoHBcKpgOv1gc0 QnHph/1sgxWhC/Rcp56oblTcEjlO92M1UGDIVFrcaCkSWr7hOQBkPytiqUUr589Y8sLT jdxTwgafKXXbQrqxxXvM8yi0bX3bELgrAzD88Ndqp0Arled3QjUDcWClYym02KAx+pxn b8rufgpKbFM7FZdk6WiIjmDFS47+Vfp4D5rJEGikwOgMbmkbqEqqpCPbHJdFFo7d3a0g g6hA== 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=v/yFrMaZvWoGuEQ7N4fZdTxCDE3V6+kZiDwNdMMZ9lk=; b=YuUZJj2GJfKKJ5Wea9tzjxcTtqQ+oZykoEvayT7XaoTKDBOb+VKMY0WELxblB1Ngxy Z5cBLrFUI2Vr+F7024ShPmBac05OiXvL7b+t5qUG2eJwSaqdSJgESTKvNu23fbzIRpTQ zt3aHIp352bt/W2jjEZNBDRJ7gRPt/XXE+GvFiM0/BHROI+Gf3wlRis9w+h6JIpFMcd2 x9s5JzGkn0VJsXHVc6VfUuofHeOhvV9P109prQCegDrrUcPRAbyQQKEl3O5jNbPHtvu7 Ub8ByDAd824shLlX5xR7CuPAfIFye8f8m3k9W8okbe27OxQg+ridSAQCWVIAZpLj7jPp /jfg== X-Gm-Message-State: ABUngvcToGEE7kjCAjMpHHxXiGOgHichk1VhowmxtqU6OKywulWVLBWA0u/IWfdm3iPTbQ== X-Received: by 10.28.184.17 with SMTP id i17mr102417wmf.18.1477612032677; Thu, 27 Oct 2016 16:47:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.45.141 with SMTP id t135ls137957wmt.14.canary-gmail; Thu, 27 Oct 2016 16:47:11 -0700 (PDT) X-Received: by 10.194.21.225 with SMTP id y1mr4224418wje.36.1477612031697; Thu, 27 Oct 2016 16:47:11 -0700 (PDT) Original-Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com. [2a00:1450:400c:c09::232]) by mx.google.com with ESMTPS id bz3si11727846wjc.141.2016.10.27.16.47.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Oct 2016 16:47:11 -0700 (PDT) Received-SPF: pass (google.com: domain of miro.knejp@gmail.com designates 2a00:1450:400c:c09::232 as permitted sender) client-ip=2a00:1450:400c:c09::232; Original-Received: by mail-wm0-x232.google.com with SMTP id e69so65857629wmg.0 for ; Thu, 27 Oct 2016 16:47:11 -0700 (PDT) X-Received: by 10.194.240.129 with SMTP id wa1mr8638218wjc.116.1477612030885; Thu, 27 Oct 2016 16:47:10 -0700 (PDT) Original-Received: from [192.168.42.16] (ppp-93-104-97-116.dynamic.mnet-online.de. [93.104.97.116]) by smtp.gmail.com with ESMTPSA id c198sm5852521wme.24.2016.10.27.16.47.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Oct 2016 16:47:10 -0700 (PDT) In-Reply-To: X-Original-Sender: miro.knejp@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of miro.knejp@gmail.com designates 2a00:1450:400c:c09::232 as permitted sender) smtp.mailfrom=miro.knejp@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:29176 Archived-At: Am 28.10.2016 um 01:06 schrieb Andrey Semashev: > On Fri, Oct 28, 2016 at 1:17 AM, Nevin Liber wrote: >> There are three possibilities: >> >> 1. It is the same file according to the OS (e.g.: inode and device match). >> 2. It must have different contents according to the OS (e.g. the size doesn't >> match). > I think, the above two bullets cannot be implemented reliably. Event > the size may not be available if the source is read from a pipe. > >> 3. The OS doesn't know if the files have the same content. I'm pretty sure >> this would require an extra pass to compute the fingerprint hash, as you >> shouldn't be processing the file until you are sure it is unique. You still >> have to scan for include guards as that is just normal macro processing. > As I shown earlier, basing the decision on the hash can result in > incorrect result. IMO, content equivalence is not the right criteria > for skipping file inclusion. Your example doesn't work precisely *because* the behavior of #pragma once isn't specified. Anyone can come up with a contrived example that breaks a feature which hasn't been defined yet, implying the feature must be impossible because it cannot solve an artificial use case it probably isn't even designed to solve. If such a utility is added (whatever it ends up being called) and it has clearly defined rules then this "trick" only works if it conforms to the rules of the new feature. If it doesn't then you have to simply resolve to include guards for such preprocessor voodoo. But at that point you as the author of the project know whether you can use this feature or not because it has (hopefully) clearly specified behavior and as such you should then know whether or not you can setup your files the way described. > > I think a proposal similar to the previously mentioned "#once > guard_phrase" has more potential. It does give the user a way to > indicate file equivalence (through the guard name) and also is > arguably less expensive than computing a hash value. > 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. Like many modern C++ improvements it's trying to create a sensible default. If that default doesn't work for (hopefully rare) use cases then you can always revert to the previous method. -- 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/fe951191-2e5b-654f-41c5-577a3e106423%40gmail.com. .