220 29190 <6EE5A060-93D1-465E-BE2C-E386EFAB4BF3@gmail.com> article Path: news.gmane.org!.POSTED!not-for-mail From: Miro Knejp Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: pragma once Date: Fri, 28 Oct 2016 12:53:30 +0200 Lines: 287 Approved: news@gmane.org Message-ID: <6EE5A060-93D1-465E-BE2C-E386EFAB4BF3@gmail.com> References: <2c278558-0dbc-4568-9b6b-7f159c94707e@isocpp.org> <4610802.tOzma7na2T@tjmaciei-mobl1> <511f665a-6c17-79cf-a020-889a4045cc95@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_FA867F6E-3636-4585-972B-86B607DF7472" X-Trace: blaine.gmane.org 1477652025 14531 195.159.176.226 (28 Oct 2016 10:53:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Oct 2016 10:53:45 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC6ONSXJ54LBBLG4ZTAAKGQE3UUPKXQ@isocpp.org Fri Oct 28 12:53:40 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 1c04mw-00024v-RZ for gclcip-std-proposals@m.gmane.org; Fri, 28 Oct 2016 12:53:30 +0200 Original-Received: by mail-wm0-f69.google.com with SMTP id 2sf27887934wmj.0 for ; Fri, 28 Oct 2016 03:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:references:to: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=KB3hWV1Pjs2Q4mrcxrLrw8Yn5ycbM1XWKYWm7t70Les=; b=vw6csxeuHZGa5RSxrP710ud8+HkV3ohZ1GsHVlO+h1j3mYMn2oZAiunkKuzutSUk2Q FHFaX8pbq3AooGD9x4LuRsYKo8HMKp4X9fTuACXpXLIGEIp5IARx+JZAqUWfC1pmM2nc DCDkgE01BBYvAd1UyVFFK2f3akJtTU4/bahhYF6qlLiI/F7n22z+icryjjzRy3jpxVbc Sej0RqUVdaLVQO82NCBe+a5ei1K/DCaVo/h5XXsKvLjkraui8NJYcuxxEERAtVL1nLlv BlmmxGgzcGN+BBnbprVH18WesBFpB/l1qsE9QKXBD4TMb3dxf3w1ylCIQjRPXUDXUpAC v8tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to: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=KB3hWV1Pjs2Q4mrcxrLrw8Yn5ycbM1XWKYWm7t70Les=; b=B++1oB8dPljoZ/VpHt7yOqahrGjFGZTtcx5XV2tXVGBj+w1cCr6yhrlxG9fw03wswM X5QbXjB3wmF03y8CGcDxIz9dhOGViQsj6BD4wJsCUVtakS5+NQbDgLVQAckAy1QEoiE4 V0sBmcjWl/uE0y1dYeLrb698QEdDM1gM947MJyhtDQs1sHr7ckapwqivkDQ+V8lhDIcD ZVHpA7bdd25hosPDymFKybsR1hnOLHCsbExZObj5GGAXFDtQq9lFmZZkploB3+9a27kZ ObrCx/HjlA3D6NIqFLVt+XhGj4WDn80bZD09DWdT70QaR6dJrw1daFx9w7/eiMBpKyFy k+kw== X-Gm-Message-State: ABUngvf1ixUxggWMjtngRl3O2jD+aPlpdStWu7gmNmiSTLzLrUlqqAyKQOmRLU6szmP3CA== X-Received: by 10.28.193.196 with SMTP id r187mr232099wmf.5.1477652013683; Fri, 28 Oct 2016 03:53:33 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.193.74 with SMTP id r71ls365665wmf.6.gmail; Fri, 28 Oct 2016 03:53:32 -0700 (PDT) X-Received: by 10.28.125.67 with SMTP id y64mr2364484wmc.65.1477652012295; Fri, 28 Oct 2016 03:53:32 -0700 (PDT) Original-Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com. [2a00:1450:400c:c09::241]) by mx.google.com with ESMTPS id 7si9236912wmr.108.2016.10.28.03.53.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Oct 2016 03:53:32 -0700 (PDT) Received-SPF: pass (google.com: domain of miro.knejp@gmail.com designates 2a00:1450:400c:c09::241 as permitted sender) client-ip=2a00:1450:400c:c09::241; Original-Received: by mail-wm0-x241.google.com with SMTP id c17so6878108wmc.3 for ; Fri, 28 Oct 2016 03:53:32 -0700 (PDT) X-Received: by 10.194.168.129 with SMTP id zw1mr13288231wjb.26.1477652011574; Fri, 28 Oct 2016 03:53:31 -0700 (PDT) Original-Received: from [172.16.1.80] ([87.191.28.122]) by smtp.gmail.com with ESMTPSA id 194sm8990250wmj.0.2016.10.28.03.53.30 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 28 Oct 2016 03:53:30 -0700 (PDT) In-Reply-To: <511f665a-6c17-79cf-a020-889a4045cc95@gmail.com> X-Mailer: Apple Mail (2.3124) 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::241 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:29190 Archived-At: --Apple-Mail=_FA867F6E-3636-4585-972B-86B607DF7472 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 > On 28 Oct 2016, at 11:50 , Andrey Semashev wr= ote: >=20 > On 10/28/16 02:48, Miro Knejp wrote: >> Am 28.10.2016 um 01:06 schrieb Andrey Semashev: >>> On Fri, Oct 28, 2016 at 1:17 AM, Nevin Liber >>> wrote: >>>> 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 y= ou >>>> 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 processin= g. >>> 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. >=20 > That example breaks assuming #once relies on hashing the header, which is= what you suggested above. That really depends on how your example came into existence. The way I unde= rstood is that =E2=80=9Ca" and =E2=80=9Cb=E2=80=9D are both part of the sam= e project and therefore the project author is in control and responsible fo= r how the files are organized and therefore wouldn=E2=80=99t use #once in t= he first place. Otherwise if =E2=80=9Ca=E2=80=9D and =E2=80=9Cb=E2=80=9D ar= e external libraries why would someone symlink two headers of two libraries= into one? That just seems like a really bad idea to me. Everyone can come up with infinite examples where every new proposed featur= e breaks. The question is always: does it aim at solving them all? I say no= .. >=20 >> 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 describ= ed. >>>=20 >>> 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. >>>=20 >> 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. >=20 > The important benefit of that approach is that the user is still in contr= ol to solve the issue - he can simply modify the guard to be more unique. Y= ou could argue that the user could modify any part of the header to change = its hash, and that's true. But as a user of the library, I would be much mo= re confident modifying the guard - the element that is precisely aimed at s= olving the problem - than any unrelated part of the header, even a comment. >=20 >> 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. >=20 > The problem with the "if it doesn't work for you, use the traditional inc= lude guards" argument is that it doesn't work for library developers becaus= e they generally don't know how their library will be used and whether #onc= e can fail in those conditions. If #once doesn't offer the same degree of p= ortability as include guards, the latter are always preferable and there si= mply is no reason to use #once. If I publish a library I can at least expect that users don=E2=80=99t symli= nk one of my headers into the header of a different library just because th= ey can. Unless this is an exclusively announced and agreed on compatibilit= y feature with the another library author in which case I wouldn=E2=80=99t = use #once for the file. Even though I do not know how someone is going to use my library I can expe= ct a certain amount of common sense. If they *do* break their code because = of symlink shenanigans between libraries then, to be frank, that=E2=80=99s = *their* problem and I=E2=80=99m not gonna lift a finger to fix it for them. --=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/6EE5A060-93D1-465E-BE2C-E386EFAB4BF3%40gmail.com= .. --Apple-Mail=_FA867F6E-3636-4585-972B-86B607DF7472 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
On 28 Oct 2016, at 1= 1:50 , Andrey Semashev <andrey.semashev@gmail.com> wrote:

On 10/28/16 02:48, Miro Knejp wrote:
Am 28.10.2016 um 01:06 sch= rieb Andrey Semashev:
On= Fri, Oct 28, 2016 at 1:17 AM, Nevin Liber <nevin@eviloverlord.com>
wrote= :
3. The OS doesn't know= if the files have the same content.  I'm
pretty surethis would require an extra pass to compute the fingerprint has= h, as you
shouldn't be processing the file until you are sure= it is unique.
You still
have to scan for inclu= de 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 criteri= a
for skipping file inclusion.
>=
Your examp= le doesn't work precisely *because* the behavior of #pragma
o= nce isn't specified. Anyone can come up with a contrived example that
breaks a feature which hasn't been defined yet, implying the featu= re
must be impossible because it cannot solve an artificial u= se case it
probably isn't even designed to solve.

That example breaks assuming #once relies on hashing th= e header, which is what you suggested above.
=
That really depends on how your example came into existence. T= he way I understood is that =E2=80=9Ca" and =E2=80=9Cb=E2=80=9D are both pa= rt of the same project and therefore the project author is in control and r= esponsible for how the files are organized and therefore wouldn=E2=80=99t u= se #once in the first place. Otherwise if =E2=80=9Ca=E2=80=9D and =E2=80=9C= b=E2=80=9D are external libraries why would someone symlink two headers of = two libraries into one? That just seems like a really bad idea to me.=

Everyone can come up with infinite examples = where every new proposed feature breaks. The question is always: does it ai= m at solving them all? I say no.

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 th= en you have to simply resolve
to include guards for such prep= rocessor voodoo. But at that point you as
the author of the p= roject know whether you can use this feature or not
because i= t 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_p= hrase" has more potential. It does give the user a way to
ind= icate file equivalence (through the guard name) and also is
a= rguably 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_FORM= AT_HPP___. That's not exactly the
most unique guard in the wo= rld. The less this relies on human
(non-)creativity or discip= line the better.

The important benefit of = that approach is that the user is still in control to solve the issue - he = can simply modify the guard to be more unique. You could argue that the use= r could modify any part of the header to change its hash, and that's true. = But as a user of the library, I would be much more confident modifying the = guard - the element that is precisely aimed at solving the problem - than a= ny unrelated part of the header, even a comment.
Like many modern C+= + improvements it's trying to create a sensible
default. If t= hat default doesn't work for (hopefully rare) use cases
then = you can always revert to the previous method.
The problem with the "if it doesn't work for you, use the traditional inc= lude guards" argument is that it doesn't work for library developers becaus= e they generally don't know how their library will be used and whether #onc= e can fail in those conditions. If #once doesn't offer the same degree of p= ortability as include guards, the latter are always preferable and there si= mply is no reason to use #once.
If I publish= a library I can at least expect that users don=E2=80=99t symlink one of my= headers into the header of a different library just because they can. Unle= ss this is an exclusively announced and agreed on  compatibility featu= re with the another library author in which case I wouldn=E2=80=99t use #on= ce for the file.

Even t= hough I do not know how someone is going to use my library I can expect a c= ertain amount of common sense. If they *do* break their code because of sym= link shenanigans between libraries then, to be frank, that=E2=80=99s *their= * problem and I=E2=80=99m not gonna lift a finger to fix it for them.

--
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.c= om/a/isocpp.org/d/msgid/std-proposals/6EE5A060-93D1-465E-BE2C-E386EFAB4BF3%= 40gmail.com.
--Apple-Mail=_FA867F6E-3636-4585-972B-86B607DF7472-- .