Topic: [RFC] #pragma once... yes, really...
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Fri, 28 Oct 2016 23:08:32 +0200
Raw View
On Fri, Oct 28, 2016 at 03:58:10PM -0400, Matthew Woehlke wrote:
> On 2016-10-28 15:27, T. C. wrote:
> > The technical specification needs reworking, and having some examples would
> > be nice to illustrate what is and isn't proposed to be permitted.
> > [details]
>
> Okay, I think I see what you're saying. I'll add some examples.
>
> While I agree having a good initial version is desirable, I hope to not
> get too bogged down in details at this time. I think it will be more
> useful to see first what the committee's general stance is on adding
> such a feature.
>
> > *version'*s actual production is unclear, and as described it seems to
> > result in ambiguities as to where the "identifier" ends and where "version"
> > begins.
>
> They are separated by whitespace.
I think that is a mistake and that a "string" would be much better for the
version argument. The reason is that I imagine that it would be pretty
useful to write
#once my::awesome::library "$Revision$"
and have the VCS handle the generation and updating of the version field.
/MF
--
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/20161028210832.GA5300%40noemi.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Sat, 29 Oct 2016 00:00:25 +0300
Raw View
On 10/28/16 23:46, T. C. wrote:
>
>
> On Friday, October 28, 2016 at 4:33:23 PM UTC-4, Matthew Woehlke
> wrote:On 2016-10-28 16:01, T. C. wrote:
>
> > #pragma once (std :: vector :: foo :: bar :: 1.0).
> >
> > Where does the "qualified C++ identifier" end and where does
> "version"
> > begin?
>
> Um... I think this would be an error; `1.0` isn't a valid identifier.
>
>
>
> > Or are you saying that unlike actual "qualified C++ identifier"s,
> > you can't have whitespace here?
>
> I wasn't thinking about whitespace, actually... Okay, I see the
> problem:
>
> #once hello ::world
>
> If we allow whitespace between 'parts' of the name, is that 'hello',
> version '::world', or 'hello::world' with no version?
>
> That's easy to fix; forbid the version starting with `:`. Maybe the
> version doesn't even need `:`; that usually only shows up in
> distribution package versions for unusual reasons related to
> distribution packaging (that delve into the horribly complicated realm
> of version number sorting).
>
> I believe this makes the parsing simple: whitespace followed by
> not-a-`:` separates the version from the name. Then we can also allow
> (and ignore) whitespace around `::`.
>
> Note: the version may *not* contain whitespace.
>
>
> That may work, but "version" as described can be several preprocessing
> tokens (1.0.1-1 is three: "1.0.1", "-", "1"), so you either need a
> special rule that says there can't be whitespace between those pp-tokens
> (unlike most other cases), or introduce a new type of preprocessing
> token formed only in #once, like header-names. Neither approach sounds
> particularly appealing to me compared to just using a string-literal.
Maybe just make the version an unsigned integer?
--
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/75abf111-7808-84df-be82-6fddcd5d1e8c%40gmail.com.
.
Author: Patrice Roy <patricer@gmail.com>
Date: Fri, 28 Oct 2016 21:04:15 -0400
Raw View
--f403045e2f12c17c96053ff68dee
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I've exchanged with others on this topic in the past and their positions
were similar to Arthur's : they were actually worried that any proposed
standard solution to this problem would deviate from existing (#pragma
once) practice, which I understand (even though I personally prefer -- and
use -- include guards, reserving #pragma for actual non-portable cases).
This should not stop anyone from sumbitting solutions or =C2=ABsolutions=C2=
=BB to the
problem, but I thought it would be nice to know there would be resistance.
2016-10-28 17:52 GMT-04:00 Arthur O'Dwyer <arthur.j.odwyer@gmail.com>:
> On Thursday, October 27, 2016 at 9:34:25 AM UTC-7, Matthew Woehlke wrote:
>>
>> After the recent thread rehashing this yet again, I'm sure some folks
>> will be surprised to see me on the other side of the issue. However, all
>> the noise got me to thinking how we might actually do this correctly...
>>
>> This is *not* a proposal for *unqualified* `#pragma once` [...]
>>
>
> I'm not a Committee member, but if I were, I would strongly oppose any
> proposal that tried to solve the "#pragma once" problem in any way other
> than:
> (1) Standardizing existing vendor practice, i.e., #pragma once; or
> (2) Helping to move the Modules proposal more quickly toward
> standardization.
>
> Remember, ordinary programmers (such as myself) can already use "#pragma
> once" with every C or C++ compiler we encounter in daily practice. Relyin=
g
> on "#pragma once" is no weirder than relying on ,##__VA_ARGS__
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2023.pdf>[a] or system
> include paths or __builtin_unreachable() or -Wall -Werror or any of the
> other things we use in our daily practice that have been "standardized"
> only by vendors, not by ISO.
>
> Include-guards and #pragma once were originally invented to solve a
> problem (breakage from double-inclusion) that in the medium term here wil=
l
> be solved by the Modules proposal, rendering the two existing solutions
> obsolete. I strongly encourage anyone currently dealing with
> double-inclusion problems to either:[b]
> (1) Adopt the existing ISO Standard solution (include guards); or
> (2) Adopt the existing solution documented by your compiler vendor
> (#pragma once); or
> (3) Adopt and/or pitch in and/or wait eagerly for the
> soon-to-be-ISO-Standard solution (the Modules draft TS
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4610.pdf>).
>
> Creating a *third* *legacy* solution to the double-inclusion problem
> doesn't help anyone, least of all the ordinary programmers who are just
> trying to figure out the best practice and use it to do their daily work.
> [c]
>
> =E2=80=93Arthur
>
> [a] My kudos to Thomas K=C3=B6ppe for attempting to standardize existing
> practice in N2023
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2023.pdf> instead of
> inventing a new thing.
> [b] If you use any third-party headers, you have already done either (1)
> or (2) anyway, whether you know it or not. (And you've probably done
> *both*.)
> [c] As usual, there is an XKCD for this. <https://xkcd.com/927/>
>
> --
> 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/8422f73d-e04f-49e4-
> aede-0399cd4d01db%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8422f73d-e0=
4f-49e4-aede-0399cd4d01db%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAKiZDp2g8Hhb4cKEBmn2HAUE1mb5YP-gpZktwTb6310mCDQ=
ivA%40mail.gmail.com.
--f403045e2f12c17c96053ff68dee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I've exchanged with others on this topic in the p=
ast and their positions were similar to Arthur's : they were actually w=
orried that any proposed standard solution to this problem would deviate fr=
om existing (#pragma once) practice, which I understand (even though I pers=
onally prefer -- and use -- include guards, reserving #pragma for actual no=
n-portable cases).<br><br></div>This should not stop anyone from sumbitting=
solutions or =C2=ABsolutions=C2=BB to the problem, but I thought it would =
be nice to know there would be resistance.<br></div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote">2016-10-28 17:52 GMT-04:00 Arthur O'=
Dwyer <span dir=3D"ltr"><<a href=3D"mailto:arthur.j.odwyer@gmail.com" ta=
rget=3D"_blank">arthur.j.odwyer@gmail.com</a>></span>:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Thursday, October 27,=
2016 at 9:34:25 AM UTC-7, Matthew Woehlke wrote:</span><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><span class=3D"">After the recent thread rehashing t=
his yet again, I'm sure some folks
<br>will be surprised to see me on the other side of the issue. However, al=
l
<br>the noise got me to thinking how we might actually do this correctly...
<br>
<br></span>This is *not* a proposal for *unqualified* `#pragma once` [...]=
=C2=A0<br></blockquote><div><br></div><div>I'm not a Committee member, =
but if I were, I would strongly oppose any proposal that tried to solve the=
"#pragma once" problem in any way other than:</div><div>(1) Stan=
dardizing existing vendor practice, i.e., #pragma once; or</div><div>(2) He=
lping to move the Modules proposal more quickly toward standardization.</di=
v><div><br></div><div>Remember, ordinary programmers (such as myself) can a=
lready use "#pragma once" with every C or C++ compiler we encount=
er in daily practice. Relying on "#pragma once" is no weirder tha=
n relying on <font face=3D"courier new, monospace"><a href=3D"http://www.op=
en-std.org/jtc1/sc22/wg14/www/docs/n2023.pdf" target=3D"_blank">,##__VA_ARG=
S__</a></font><font size=3D"1">[a]</font> or system include paths or <font =
face=3D"courier new, monospace">__builtin_unreachable()</font> or <font fac=
e=3D"courier new, monospace">-Wall -Werror</font> or any of the other thing=
s we use in our daily practice that have been "standardized" only=
by vendors, not by ISO.</div><div><br></div><div>Include-guards and #pragm=
a once were originally invented to solve a problem (breakage from double-in=
clusion) that in the medium term here will be solved by the Modules proposa=
l, rendering the two existing solutions obsolete. I strongly encourage anyo=
ne currently dealing with double-inclusion problems to either:<font size=3D=
"1">[b]</font></div><div>(1) Adopt the existing ISO Standard solution (incl=
ude guards); or</div><div>(2) Adopt the existing solution documented by you=
r compiler vendor (#pragma once); or</div><div>(3) Adopt and/or pitch in an=
d/or wait eagerly for the soon-to-be-ISO-Standard solution (<a href=3D"http=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4610.pdf" target=3D"_b=
lank">the Modules draft TS</a>).</div><div><br></div><div>Creating a <b>thi=
rd</b>=C2=A0<i>legacy</i> solution to the double-inclusion problem doesn=
9;t help anyone, least of all the ordinary programmers who are just trying =
to figure out the best practice and use it to do their daily work.<font siz=
e=3D"1">[c]</font></div><div><br></div><div>=E2=80=93Arthur</div><div><br><=
/div><div>[a] My kudos to Thomas K=C3=B6ppe for attempting to standardize e=
xisting practice in <a href=3D"http://www.open-std.org/jtc1/sc22/wg14/www/d=
ocs/n2023.pdf" target=3D"_blank">N2023</a> instead of inventing a new thing=
..<br></div><div><div>[b] If you use any third-party headers, you have alrea=
dy done either (1) or (2) anyway, whether you know it or not. (And you'=
ve probably done=C2=A0<i>both</i>.)</div></div><div><div>[c] As usual,=C2=
=A0<a href=3D"https://xkcd.com/927/" target=3D"_blank">there is an XKCD for=
this.</a></div></div><div><br></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8422f73d-e04f-49e4-aede-0399cd4d01db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/8422=
f73d-e04f-49e4-<wbr>aede-0399cd4d01db%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2g8Hhb4cKEBmn2HAUE1mb5YP-gpZkt=
wTb6310mCDQivA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2g8Hhb4cKE=
Bmn2HAUE1mb5YP-gpZktwTb6310mCDQivA%40mail.gmail.com</a>.<br />
--f403045e2f12c17c96053ff68dee--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 29 Oct 2016 09:12:53 -0700
Raw View
On sexta-feira, 28 de outubro de 2016 23:08:32 PDT Magnus Fromreide wrote:
> I think that is a mistake and that a "string" would be much better for the
> version argument. The reason is that I imagine that it would be pretty
> useful to write
>
> #once my::awesome::library "$Revision$"
>
> and have the VCS handle the generation and updating of the version field.
And that's something you *shouldn't* do because if someone has a different
checkout of the same header elsewhere in their build tree, with some typos
corrected, it would be included and cause a build error.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/3454801.ONyH2fmSmH%40tjmaciei-mobl1.
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Sat, 29 Oct 2016 23:40:00 +0200
Raw View
On Sat, Oct 29, 2016 at 09:12:53AM -0700, Thiago Macieira wrote:
> On sexta-feira, 28 de outubro de 2016 23:08:32 PDT Magnus Fromreide wrote:
> > I think that is a mistake and that a "string" would be much better for the
> > version argument. The reason is that I imagine that it would be pretty
> > useful to write
> >
> > #once my::awesome::library "$Revision$"
> >
> > and have the VCS handle the generation and updating of the version field.
>
> And that's something you *shouldn't* do because if someone has a different
> checkout of the same header elsewhere in their build tree, with some typos
> corrected, it would be included and cause a build error.
I suppose this means you think a hash of the file content is a bad idea as
well, and for the same reason?
Anyway, I won't say anything more on this subject save that if I was on the
committe and it came before me I would be weakly against it on the grounds
that it adds to little to late.
/MF
--
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/20161029214000.GA32434%40noemi.
.