------=_Part_102_17666992.1352607618060
Content-Type: text/plain; charset=ISO-8859-1

how about making it implicit and making multiple inclusion definable by
some pragma...
it is a breaking change but tbh ppl that rely on multiple inclusion(afaik
VT emulation in VS for example) are smart enough to fix their files in no
time.
Call me crazy but I consider include guards one of the few remaining things
that make C++ feel like an old language.


On Wednesday, November 7, 2012 7:19:01 PM UTC+2, Mark Ingram wrote:
>
> As #pragma once is supported by many compilers<http://en.wikipedia.org/wiki/Pragma_once#Portability>as a non-standard add-on, how about it being made into the actual standard
> so that we can rely on it for cross-platform development? It's much neater
> than ugly include guards.

--




------=_Part_102_17666992.1352607618060
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

how about making it implicit and making multiple inclusion definable by som=
e pragma...<br>it is a breaking change but tbh ppl that rely on multiple in=
clusion(afaik VT emulation in VS for example) are smart enough to fix their=
 files in no time.<br>Call me crazy but I consider include guards one of th=
e few remaining things that make C++ feel like an old language. <br><br><br=
>On Wednesday, November 7, 2012 7:19:01 PM UTC+2, Mark Ingram wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">As #pragma once is supported by <a hr=
ef=3D"http://en.wikipedia.org/wiki/Pragma_once#Portability" target=3D"_blan=
k">many compilers</a> as a non-standard add-on, how about it being made int=
o the actual standard so that we can rely on it for cross-platform developm=
ent? It's much neater than ugly include guards.</blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_102_17666992.1352607618060--

.

--f46d043c81e6bca11a04ce365f39
Content-Type: text/plain; charset=ISO-8859-1

> how about making it implicit and making multiple inclusion
> definable by some pragma...
> it is a breaking change but tbh ppl that rely on multiple inclusion
> (afaik VT emulation in VS for example) are smart enough to fix
> their files in no time.

Wouldn't disabling multiple inclusion by default break inclusion-based X
macros, though?


On 11 November 2012 05:20, <nx02columbia@gmail.com> wrote:

> how about making it implicit and making multiple inclusion definable by
> some pragma...
> it is a breaking change but tbh ppl that rely on multiple inclusion(afaik
> VT emulation in VS for example) are smart enough to fix their files in no
> time.
> Call me crazy but I consider include guards one of the few remaining
> things that make C++ feel like an old language.
>
>
> On Wednesday, November 7, 2012 7:19:01 PM UTC+2, Mark Ingram wrote:
>>
>> As #pragma once is supported by many compilers<http://en.wikipedia.org/wiki/Pragma_once#Portability>as a non-standard add-on, how about it being made into the actual standard
>> so that we can rely on it for cross-platform development? It's much neater
>> than ugly include guards.
>
>  --
>
>
>
>

--




--f46d043c81e6bca11a04ce365f39
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>&gt; how about making it implicit and making multiple inclusion</div><=
div>&gt; definable by some pragma...</div><div>&gt;=A0it is a breaking chan=
ge but tbh ppl that rely on multiple inclusion</div><div>&gt; (afaik VT emu=
lation in VS for example) are smart enough to fix</div>
<div>&gt; their files in no time.</div><div><br></div>Wouldn&#39;t disablin=
g multiple inclusion by default break inclusion-based X macros, though?<div=
 class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 11 November 20=
12 05:20,  <span dir=3D"ltr">&lt;<a href=3D"mailto:nx02columbia@gmail.com" =
target=3D"_blank">nx02columbia@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">how about making it implicit and making mult=
iple inclusion definable by some pragma...<br>it is a breaking change but t=
bh ppl that rely on multiple inclusion(afaik VT emulation in VS for example=
) are smart enough to fix their files in no time.<br>
Call me crazy but I consider include guards one of the few remaining things=
 that make C++ feel like an old language. <br><div class=3D"HOEnZb"><div cl=
ass=3D"h5"><br><br>On Wednesday, November 7, 2012 7:19:01 PM UTC+2, Mark In=
gram wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex">
As #pragma once is supported by <a href=3D"http://en.wikipedia.org/wiki/Pra=
gma_once#Portability" target=3D"_blank">many compilers</a> as a non-standar=
d add-on, how about it being made into the actual standard so that we can r=
ely on it for cross-platform development? It&#39;s much neater than ugly in=
clude guards.</blockquote>


<p></p>

-- <br>
=A0<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--f46d043c81e6bca11a04ce365f39--

.

------=_Part_3360_662072251.1413919761655
Content-Type: text/plain; charset=UTF-8

I think that #pragma once should be standardized - at least
partially/optionally/conditionally-supported.  Every major compiler
implements it with identical or nearly-identical semantics.

Defining what it means for a file to be a repeat is rather simple: On
platforms supporting symlinks and hard links, use unique inode numbers (+
device if needed).  On other platforms, use the filename.  Compilers may
assume that files don't change while compiling (i.e. if the filename
matches, it can be assumed to be identical).  On platforms where there
exist special links to the same or parent directory, like "./" or "../" on
NT and POSIX, this assumption can be extended to collapse these.

By the way, why don't _Pragma and #line support concatenating multiple
strings in their respective string parameters?

Melissa

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_3360_662072251.1413919761655
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think that <span style=3D"font-family: courier new,monos=
pace;">#pragma once</span> should be standardized - at least partially/opti=
onally/conditionally-supported.&nbsp; Every major compiler implements it wi=
th identical or nearly-identical semantics.<br><br>Defining what it means f=
or a file to be a repeat is rather simple: On platforms supporting symlinks=
 and hard links, use unique inode numbers (+ device if needed).&nbsp; On ot=
her platforms, use the filename.&nbsp; Compilers may assume that files don'=
t change while compiling (i.e. if the filename matches, it can be assumed t=
o be identical).&nbsp; On platforms where there exist special links to the =
same or parent directory, like "./" or "../" on NT and POSIX, this assumpti=
on can be extended to collapse these.<br><br>By the way, why don't <span st=
yle=3D"font-family: courier new,monospace;">_Pragma</span> and <span style=
=3D"font-family: courier new,monospace;">#line</span> support concatenating=
 multiple strings in their respective string parameters?<br><br>Melissa<br>=
</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3360_662072251.1413919761655--

.

--_ef3e39f8-9b31-4959-9855-c119476b12b3_
Content-Type: text/plain; charset=ISO-8859-1

+1. It's superior to header guards in terms of maintainability, readability and (sometimes) performance. Why isn't it standard?

Vittorio Romeohttp://vittorioromeo.info


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--_ef3e39f8-9b31-4959-9855-c119476b12b3_
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
..hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'>+1. It's superior to header guar=
ds in terms of maintainability, readability and (sometimes) performance. Wh=
y isn't it standard?<br><br>Vittorio Romeo<div><a href=3D"http://vittorioro=
meo.info" target=3D"_blank">http://vittorioromeo.info</a></div><div><br></d=
iv>            </div></body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--_ef3e39f8-9b31-4959-9855-c119476b12b3_--

.

------=_Part_4950_322201839.1413923520392
Content-Type: text/plain; charset=UTF-8

It has been determined that it is more difficult to implement than you
would think:
http://stackoverflow.com/questions/23696115/is-pragma-once-part-of-the-c11-standard
http://stackoverflow.com/questions/1695807/why-isnt-c-cs-pragma-once-an-iso-standard

The Modules proposal aims to solve the problems of include files in a
better way:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf

--Chet

On Tuesday, 21 October 2014 13:15:51 UTC-7, Vittorio Romeo wrote:
>
> +1. It's superior to header guards in terms of maintainability,
> readability and (sometimes) performance. Why isn't it standard?
>
> Vittorio Romeo
> http://vittorioromeo.info
>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4950_322201839.1413923520392
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>It has been determined that it is more difficult to i=
mplement than you would think:</div>http://stackoverflow.com/questions/2369=
6115/is-pragma-once-part-of-the-c11-standard<div>http://stackoverflow.com/q=
uestions/1695807/why-isnt-c-cs-pragma-once-an-iso-standard</div><div><br></=
div><div><span style=3D"color: rgb(0, 0, 0); font-family: Arial, 'Liberatio=
n Sans', 'DejaVu Sans', sans-serif; font-size: 13.3333339691162px; line-hei=
ght: 17.804801940918px;">The Modules proposal aims to solve the problems of=
 include files in a better way:</span></div><div><font color=3D"#000000" fa=
ce=3D"Arial, Liberation Sans, DejaVu Sans, sans-serif"><span style=3D"line-=
height: 17.804801940918px;">http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2014/n4047.pdf</span></font><br></div><div><br></div><div>--Chet</div><=
div><br></div><div>On Tuesday, 21 October 2014 13:15:51 UTC-7, Vittorio Rom=
eo  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">


<div><div dir=3D"ltr">+1. It's superior to header guards in terms of mainta=
inability, readability and (sometimes) performance. Why isn't it standard?<=
br><br>Vittorio Romeo<div><a href=3D"http://vittorioromeo.info" target=3D"_=
blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Fvittorioromeo.info\46sa\75D\46sntz\0751\46usg\75AFQjCNHdnys4DHYhQyp_Xovn=
eOaP7ako3Q';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fvittorioromeo.info\46sa\75D\46sntz\0751\46usg\75AFQjCNHdn=
ys4DHYhQyp_XovneOaP7ako3Q';return true;">http://vittorioromeo.info</a></div=
><div><br></div>            </div></div>
</blockquote></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4950_322201839.1413923520392--

.

------=_Part_942_342251634.1413925440498
Content-Type: text/plain; charset=UTF-8


>
> By the way, why don't _Pragma and #line support concatenating multiple
> strings in their respective string parameters?
>

String concatenation happens later (Phase 6). For _Pragma, this is not too
bad if you're willing to build up *unquoted *pp-tokens and pass them to a
wrapper-macro:

#define RAW_TOKENS_PRAGMA2(...)  _Pragma(#__VA_ARGS__)
#define RAW_TOKENS_PRAGMA(...)   RAW_TOKENS_PRAGMA2(__VA_ARGS__)

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_942_342251634.1413925440498
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">By the way, why don't <span style=3D"font-family:courier new,monospace"=
>_Pragma</span> and <span style=3D"font-family:courier new,monospace">#line=
</span> support concatenating multiple strings in their respective string p=
arameters?<br></div></blockquote><div><br>String concatenation happens late=
r (Phase 6). For _Pragma, this is not too bad if you're willing to build up=
 <i>unquoted </i>pp-tokens and pass them to a wrapper-macro:<br><br><div cl=
ass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-c=
olor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap=
: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><s=
pan style=3D"color: #800;" class=3D"styled-by-prettify">#define</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><code class=3D=
"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">RAW=
_TOKENS_PRAGMA2</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify"></span></code><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(...)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &n=
bsp;_Pragma</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #800;" class=3D"styled-by-prettify">#__VA_AR=
GS__)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">#define</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> RAW_TOKENS_PR=
AGMA</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(...)<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &nbsp; RAW=
_TOKENS_PRAGMA2</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">__VA=
_ARGS__</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"></span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></cod=
e></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_942_342251634.1413925440498--

.

------=_Part_406_1585608615.1413943296483
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 21, 2014 1:32:00 PM UTC-7, Chet wrote:
>
> It has been determined that it is more difficult to implement than you
> would think:
>
> http://stackoverflow.com/questions/23696115/is-pragma-once-part-of-the-c11-standard
>
> http://stackoverflow.com/questions/1695807/why-isnt-c-cs-pragma-once-an-iso-standard
>
>
I had read the second one before I posted.  The only bad case I see so far
is ambiguous remote mounts.  Why not just say that the behavior is
unspecified if two files of different names are, in fact, the same file in
a way in which the implementation cannot reliably determine?


> The Modules proposal aims to solve the problems of include files in a
> better way:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf
>
> --Chet
>

Sure, but that's years off if ever, and there are billions of lines of code
in projects using #pragma once now.

Melissa

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_406_1585608615.1413943296483
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 21, 2014 1:32:00 PM UTC-7, Chet wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>It has b=
een determined that it is more difficult to implement than you would think:=
</div><a href=3D"http://stackoverflow.com/questions/23696115/is-pragma-once=
-part-of-the-c11-standard" target=3D"_blank" onmousedown=3D"this.href=3D'ht=
tp://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fquestions%2F23=
696115%2Fis-pragma-once-part-of-the-c11-standard\46sa\75D\46sntz\0751\46usg=
\75AFQjCNES9TypD5mHdlQK51fkaP9dzdeQOw';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fquestion=
s%2F23696115%2Fis-pragma-once-part-of-the-c11-standard\46sa\75D\46sntz\0751=
\46usg\75AFQjCNES9TypD5mHdlQK51fkaP9dzdeQOw';return true;">http://stackover=
flow.com/<wbr>questions/23696115/is-pragma-<wbr>once-part-of-the-c11-standa=
rd</a><div><a href=3D"http://stackoverflow.com/questions/1695807/why-isnt-c=
-cs-pragma-once-an-iso-standard" target=3D"_blank" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fquestion=
s%2F1695807%2Fwhy-isnt-c-cs-pragma-once-an-iso-standard\46sa\75D\46sntz\075=
1\46usg\75AFQjCNGUPN-4fgYScvLGFc_Uh4rSjYFozA';return true;" onclick=3D"this=
..href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fque=
stions%2F1695807%2Fwhy-isnt-c-cs-pragma-once-an-iso-standard\46sa\75D\46snt=
z\0751\46usg\75AFQjCNGUPN-4fgYScvLGFc_Uh4rSjYFozA';return true;">http://sta=
ckoverflow.com/<wbr>questions/1695807/why-isnt-c-<wbr>cs-pragma-once-an-iso=
-standard</a></div><div><br></div></div></blockquote><div><br>I had read th=
e second one before I posted.&nbsp; The only bad case I see so far is ambig=
uous remote mounts.&nbsp; Why not just say that the behavior is unspecified=
 if two files of different names are, in fact, the same file in a way in wh=
ich the implementation cannot reliably determine?<br>&nbsp;</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div><span s=
tyle=3D"color:rgb(0,0,0);font-family:Arial,'Liberation Sans','DejaVu Sans',=
sans-serif;font-size:13.3333339691162px;line-height:17.804801940918px">The =
Modules proposal aims to solve the problems of include files in a better wa=
y:</span></div><div><font color=3D"#000000" face=3D"Arial, Liberation Sans,=
 DejaVu Sans, sans-serif"><span style=3D"line-height:17.804801940918px"><a =
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf" =
target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\7=
5http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%=
2Fn4047.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNGeTcNge2rjuAQqbtQ84Fhwx3quNg=
';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn404=
7.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNGeTcNge2rjuAQqbtQ84Fhwx3quNg';retu=
rn true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2014/<wbr=
>n4047.pdf</a></span></font><br></div><div><br></div><div>--Chet</div></div=
></blockquote><div><br>Sure, but that's years off if ever, and there are bi=
llions of lines of code in projects using #pragma once now.<br><br>Melissa<=
br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_406_1585608615.1413943296483--

.

------=_Part_4963_1945122689.1413943432607
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 21, 2014 2:04:00 PM UTC-7, Christopher wrote:
>
> By the way, why don't _Pragma and #line support concatenating multiple
>> strings in their respective string parameters?
>>
>
> String concatenation happens later (Phase 6). For _Pragma, this is not too
> bad if you're willing to build up *unquoted *pp-tokens and pass them to a
> wrapper-macro:
>
> #define RAW_TOKENS_PRAGMA2(...)  _Pragma(#__VA_ARGS__)
> #define RAW_TOKENS_PRAGMA(...)   RAW_TOKENS_PRAGMA2(__VA_ARGS__)
>

Could we then define _Pragma as taking one or more string parameters (not
separated by anything but possibly whitespace) that are interpreted
concatenated?

Melissa

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4963_1945122689.1413943432607
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 21, 2014 2:04:00 PM UTC-7, Christopher=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">By the way, why don't <s=
pan style=3D"font-family:courier new,monospace">_Pragma</span> and <span st=
yle=3D"font-family:courier new,monospace">#line</span> support concatenatin=
g multiple strings in their respective string parameters?<br></div></blockq=
uote><div><br>String concatenation happens later (Phase 6). For _Pragma, th=
is is not too bad if you're willing to build up <i>unquoted </i>pp-tokens a=
nd pass them to a wrapper-macro:<br><br><div style=3D"background-color:rgb(=
250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:=
1px;word-wrap:break-word"><code><div><span style=3D"color:#800">#define</sp=
an><span style=3D"color:#000"> </span><code><span style=3D"color:#000">RAW_=
TOKENS_PRAGMA2</span><span style=3D"color:#660"></span></code><span style=
=3D"color:#660">(...)</span><span style=3D"color:#000"> &nbsp;_Pragma</span=
><span style=3D"color:#660">(</span><span style=3D"color:#800">#__VA_ARGS__=
)</span><span style=3D"color:#000"><br></span><span style=3D"color:#800">#d=
efine</span><span style=3D"color:#000"> RAW_TOKENS_PRAGMA</span><span style=
=3D"color:#660">(...)</span><span style=3D"color:#000"> &nbsp; RAW_TOKENS_P=
RAGMA2</span><span style=3D"color:#660">(</span><span style=3D"color:#000">=
__VA_ARGS__</span><span style=3D"color:#660"><wbr>)</span><span style=3D"co=
lor:#000"></span><span style=3D"color:#000"><br></span></div></code></div><=
/div></div></blockquote><div><br>Could we then define _Pragma as taking one=
 or more string parameters (not separated by anything but possibly whitespa=
ce) that are interpreted concatenated?<br><br>Melissa<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4963_1945122689.1413943432607--

.

------=_Part_5171_360901482.1413953333975
Content-Type: text/plain; charset=UTF-8


>
> Could we then define _Pragma as taking one or more string parameters (not
> separated by anything but possibly whitespace) that are interpreted
> concatenated?
>

I'm really curious about the original design intent: why does _Pragma take
a stringized argument in the first place? When it was first added in C99,
why wasn't it specified to take non-stringized tokens like the #pragma
directive or MSVC's __pragma extension?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_5171_360901482.1413953333975
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>Could we then define _Pragma as taking one or more string paramete=
rs (not separated by anything but possibly whitespace) that are interpreted=
 concatenated?<br></div></div></blockquote><div><br>I'm really curious abou=
t the original design intent: why does <span style=3D"font-family: courier =
new,monospace;">_Pragma</span> take a stringized argument in the first plac=
e? When it was first added in C99, why wasn't it specified to take non-stri=
ngized tokens like the #pragma directive or MSVC's <span style=3D"font-fami=
ly: courier new,monospace;">__pragma</span> extension?<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5171_360901482.1413953333975--

.

On Tuesday 21 October 2014 19:01:36 Myriachan wrote:
> Sure, but that's years off if ever, and there are billions of lines of code
> in projects using #pragma once now.

So why do we need to change anything? If that code is already working, it's
working. If it's not working, then it won't magically begin working tomorrow
-- at best, it would become valid from next year on and projects wishing
compatibility would then begin using it in 2016 or 2017.

They may as well simply use include guards if they need compatibility.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_5290_611197915.1413961466434
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 21, 2014 10:32:00 PM UTC+2, Chet wrote:
>
> It has been determined that it is more difficult to implement than you
> would think:
>
> http://stackoverflow.com/questions/23696115/is-pragma-once-part-of-the-c11-standard
>
> http://stackoverflow.com/questions/1695807/why-isnt-c-cs-pragma-once-an-iso-standard
>
> The Modules proposal aims to solve the problems of include files in a
> better way:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf
>

Is it really that difficult?
If the name doesn't match an already seen file but the size does one could
hash the contents and check the hash.


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_5290_611197915.1413961466434
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 21, 2014 10:32:00 PM UTC+2, Chet wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>It has =
been determined that it is more difficult to implement than you would think=
:</div><a href=3D"http://stackoverflow.com/questions/23696115/is-pragma-onc=
e-part-of-the-c11-standard" target=3D"_blank" onmousedown=3D"this.href=3D'h=
ttp://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fquestions%2F2=
3696115%2Fis-pragma-once-part-of-the-c11-standard\46sa\75D\46sntz\0751\46us=
g\75AFQjCNES9TypD5mHdlQK51fkaP9dzdeQOw';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fquestion=
s%2F23696115%2Fis-pragma-once-part-of-the-c11-standard\46sa\75D\46sntz\0751=
\46usg\75AFQjCNES9TypD5mHdlQK51fkaP9dzdeQOw';return true;">http://stackover=
flow.com/<wbr>questions/23696115/is-pragma-<wbr>once-part-of-the-c11-standa=
rd</a><div><a href=3D"http://stackoverflow.com/questions/1695807/why-isnt-c=
-cs-pragma-once-an-iso-standard" target=3D"_blank" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fquestion=
s%2F1695807%2Fwhy-isnt-c-cs-pragma-once-an-iso-standard\46sa\75D\46sntz\075=
1\46usg\75AFQjCNGUPN-4fgYScvLGFc_Uh4rSjYFozA';return true;" onclick=3D"this=
..href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fque=
stions%2F1695807%2Fwhy-isnt-c-cs-pragma-once-an-iso-standard\46sa\75D\46snt=
z\0751\46usg\75AFQjCNGUPN-4fgYScvLGFc_Uh4rSjYFozA';return true;">http://sta=
ckoverflow.com/<wbr>questions/1695807/why-isnt-c-<wbr>cs-pragma-once-an-iso=
-standard</a></div><div><br></div><div><span style=3D"color:rgb(0,0,0);font=
-family:Arial,'Liberation Sans','DejaVu Sans',sans-serif;font-size:13.33333=
39691162px;line-height:17.804801940918px">The Modules proposal aims to solv=
e the problems of include files in a better way:</span></div><div><font col=
or=3D"#000000" face=3D"Arial, Liberation Sans, DejaVu Sans, sans-serif"><sp=
an style=3D"line-height:17.804801940918px"><a href=3D"http://www.open-std.o=
rg/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf" target=3D"_blank" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.or=
g%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4047.pdf\46sa\75D\46sntz\0=
751\46usg\75AFQjCNGeTcNge2rjuAQqbtQ84Fhwx3quNg';return true;" onclick=3D"th=
is.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjt=
c1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4047.pdf\46sa\75D\46sntz\0751\46=
usg\75AFQjCNGeTcNge2rjuAQqbtQ84Fhwx3quNg';return true;">http://www.open-std=
..org/jtc1/<wbr>sc22/wg21/docs/papers/2014/<wbr>n4047.pdf</a></span></font><=
/div></div></blockquote><div><br></div><div>Is it really that difficult?</d=
iv><div>If the name doesn't match an already seen file but the size does on=
e could hash the contents and check the hash.</div><div>&nbsp;<br></div></d=
iv>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5290_611197915.1413961466434--

.

On 10/22/14, Thiago Macieira <thiago@macieira.org> wrote:
> On Tuesday 21 October 2014 19:01:36 Myriachan wrote:
>> Sure, but that's years off if ever, and there are billions of lines of
>> code
>> in projects using #pragma once now.
> So why do we need to change anything? If that code is already working, it's
> working. If it's not working, then it won't magically begin working tomorrow
> -- at best, it would become valid from next year on and projects wishing
> compatibility would then begin using it in 2016 or 2017.
> They may as well simply use include guards if they need compatibility.

I agree with Thiago. Even if both my compilers support the once pragma
I stick to include guards. They work if you provide a meaningful name
(I include my initials and the date of construction so something like
.... _PKL_2014_10_22). I believe it would save me sixty seconds to
write #pragma instead.
If include guards make your compilation slow, you should complain to
your vendor.

/Peter

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Wednesday 22 October 2014 12:39:15 Peter Koch Larsen wrote:
> On 10/22/14, Thiago Macieira <thiago@macieira.org> wrote:
> > On Tuesday 21 October 2014 19:01:36 Myriachan wrote:
> >> Sure, but that's years off if ever, and there are billions of lines of
> >> code
> >> in projects using #pragma once now.
> >
> > So why do we need to change anything? If that code is already working,
> > it's
> > working. If it's not working, then it won't magically begin working
> > tomorrow -- at best, it would become valid from next year on and projects
> > wishing compatibility would then begin using it in 2016 or 2017.
> > They may as well simply use include guards if they need compatibility.
>
> I agree with Thiago. Even if both my compilers support the once pragma
> I stick to include guards. They work if you provide a meaningful name
> (I include my initials and the date of construction so something like
> ... _PKL_2014_10_22). I believe it would save me sixty seconds to
> write #pragma instead.
> If include guards make your compilation slow, you should complain to
> your vendor.

Just out of curiosity, why does it need to be that complex?

The include guard can be based on a rule of formation based on how the header
itself gets #included. You can't have two of such files getting included in the
same translation unit anyway.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Wed, Oct 22, 2014 at 4:52 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On Wednesday 22 October 2014 12:39:15 Peter Koch Larsen wrote:
<snip>
>> I agree with Thiago. Even if both my compilers support the once pragma
>> I stick to include guards. They work if you provide a meaningful name
>> (I include my initials and the date of construction so something like
>> ... _PKL_2014_10_22). I believe it would save me sixty seconds to
>> write #pragma instead.
>> If include guards make your compilation slow, you should complain to
>> your vendor.
>
> Just out of curiosity, why does it need to be that complex?

You mean why I add my initials and a date? It is in my fingers - perhaps that is
the best answer. But if you include stuff from others and they are not
as rigoreous
as e.g. boost, there is a risk that a "FORMAT_HPP" is not unique. I have been
bitten by that once - even if it was a very long time ago.

/Peter
>
> The include guard can be based on a rule of formation based on how the header
> itself gets #included. You can't have two of such files getting included in the
> same translation unit anyway.
You mean something like BOOST_DETAILS_LEXICAL_CAST? You could also do
that (I am not sure this is a proper boost macro, btw). But I know
that I never create
two include-files on the same day with the same name.

/Peter

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-10-22 09:04, Olaf van der Spek wrote:
> On Tuesday, October 21, 2014 10:32:00 PM UTC+2, Chet wrote:
>
>     It has been determined that it is more difficult to implement than
>     you would think:
>     http://stackoverflow.com/questions/23696115/is-pragma-once-part-of-the-c11-standard
>     <http://stackoverflow.com/questions/23696115/is-pragma-once-part-of-the-c11-standard>
>     http://stackoverflow.com/questions/1695807/why-isnt-c-cs-pragma-once-an-iso-standard
>     <http://stackoverflow.com/questions/1695807/why-isnt-c-cs-pragma-once-an-iso-standard>
>
>     The Modules proposal aims to solve the problems of include files in
>     a better way:
>     http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf
>     <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf>
>
>
> Is it really that difficult?
> If the name doesn't match an already seen file but the size does one
> could hash the contents and check the hash.
>

It really IS that difficult.

On my work computer I have mounts to several departmental servers
(located in different cities), some NAS devices that I don't even know
where they are, a ClearCase system on a Unix machine, and the file
system on a z/OS mainframe. Add a local hard disk, a DVD and some
USB-devices, and you get a real world system.

How is the standard supposed to specify what a unique file means? And
how useful is it for every existing compiler to support this?


Bo Persson


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Wed, Oct 22, 2014 at 8:29 PM, Bo Persson <bop@gmb.dk> wrote:
>> Is it really that difficult?
>> If the name doesn't match an already seen file but the size does one
>> could hash the contents and check the hash.
>>
>
> It really IS that difficult.
>
> On my work computer I have mounts to several departmental servers (located
> in different cities), some NAS devices that I don't even know where they
> are, a ClearCase system on a Unix machine, and the file system on a z/OS
> mainframe. Add a local hard disk, a DVD and some USB-devices, and you get a
> real world system.
>
> How is the standard supposed to specify what a unique file means?

See above

> And how
> useful is it for every existing compiler to support this?

Quite useful, nearly 99.99% of the headers probably need an include
guard or something better.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-10-22 20:38, Olaf van der Spek wrote:
> On Wed, Oct 22, 2014 at 8:29 PM, Bo Persson <bop@gmb.dk> wrote:
>>> Is it really that difficult?
>>> If the name doesn't match an already seen file but the size does one
>>> could hash the contents and check the hash.
>>>
>>
>> It really IS that difficult.
>>
>> On my work computer I have mounts to several departmental servers (located
>> in different cities), some NAS devices that I don't even know where they
>> are, a ClearCase system on a Unix machine, and the file system on a z/OS
>> mainframe. Add a local hard disk, a DVD and some USB-devices, and you get a
>> real world system.
>>
>> How is the standard supposed to specify what a unique file means?
>
> See above
>
>> And how
>> useful is it for every existing compiler to support this?
>
> Quite useful, nearly 99.99% of the headers probably need an include
> guard or something better.
>

One advantage of an include guard is that YOU can fix the conflicts you
run into. If the compiler's #pragma once fails to include a file, what
do you do about that?

And should the standard require all compiler developers to have a
mainframe in their test environment, so I can be sure that the pragma
works on my system?


Bo Persson


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Wed, Oct 22, 2014 at 8:43 PM, Bo Persson <bop@gmb.dk> wrote:
> One advantage of an include guard is that YOU can fix the conflicts you run
> into. If the compiler's #pragma once fails to include a file, what do you do
> about that?

File a bug report and fall back to include guards (or something else).

> And should the standard require all compiler developers to have a mainframe
> in their test environment, so I can be sure that the pragma works on my
> system?

Of course :p

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_69_779594313.1414004611066
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 21, 2014 11:02:35 PM UTC-7, Thiago Macieira wrote:
>
> On Tuesday 21 October 2014 19:01:36 Myriachan wrote:
> > Sure, but that's years off if ever, and there are billions of lines of
> code
> > in projects using #pragma once now.
>
> So why do we need to change anything? If that code is already working,
> it's


Well, there's value to having de facto standards match the de jure
standard. See exported templates and their eventual removal as an example
specific to C++. It's unfortunate when large codebases depend on a
non-standard feature that "works" but is non-standard and then new tools
that more closely follow the standard without extensions can't handle the
codebase. Happens all the time with game engines in my experience,
including specifically #pragma once issues.


That said, #pragma once couldn't be added to the standard any sooner than
C++17, and #pragma once _isn't_ a de facto standard because different
implementations work differently, and there's the problems with complex
source directories Bo mentions, and... I think all the reasons why this
won't work were already clearly enumerated in the last thread on this very
topic that came up some months ago.

A feature similar to #pragma once that simplifies include guards could make
sense, but it'll depend on the modules stuff. I'm personally very
unimpressed with any of the current modules proposals so perhaps there _is_
value in such a new feature, but it's literally not possible to just
standardize #pragma once without forcing most implementations to change
their semantics. It would probably have to become something like:

   #once <tag> // must be first directive in file
   /* rest of file */

which essentially expands to

   #if !defined(<tag>)
   #define <tag>
   /* rest of file */
   #endif

but maybe with <tag> being a separate namespace from preprocessor macros
(or not). And perhaps <tag> is optional and an implementation-defined one
is created based on canonical file path, though that leaves one open to the
problems Bo described.

Again, it all depends on modules and when they're implemented and how
useful they end up being in practice

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_69_779594313.1414004611066
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 21, 2014 11:02:35 PM UTC-7, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday 21 Octo=
ber 2014 19:01:36 Myriachan wrote:
<br>&gt; Sure, but that's years off if ever, and there are billions of line=
s of code=20
<br>&gt; in projects using #pragma once now.
<br>
<br>So why do we need to change anything? If that code is already working, =
it's </blockquote><div><br></div><div>Well, there's value to having de fact=
o standards match the de jure standard. See exported templates and their ev=
entual removal as an example specific to C++. It's unfortunate when large c=
odebases depend on a non-standard feature that "works" but is non-standard =
and then new tools that more closely follow the standard without extensions=
 can't handle the codebase. Happens all the time with game engines in my ex=
perience, including specifically #pragma once issues.</div><div><br></div><=
div><br></div><div>That said, #pragma once couldn't be added to the standar=
d any sooner than C++17, and #pragma once _isn't_ a de facto standard becau=
se different implementations work differently, and there's the problems wit=
h complex source directories Bo mentions, and... I think all the reasons wh=
y this won't work were already clearly enumerated in the last thread on thi=
s very topic that came up some months ago.</div><div><br></div><div>A featu=
re similar to #pragma once that simplifies include guards could make sense,=
 but it'll depend on the modules stuff. I'm personally very unimpressed wit=
h any of the current modules proposals so perhaps there _is_ value in such =
a new feature, but it's literally not possible to just standardize #pragma =
once without forcing most implementations to change their semantics. It wou=
ld probably have to become something like:</div><div><br></div><div>&nbsp; =
&nbsp;#once &lt;tag&gt; // must be first directive in file</div><div>&nbsp;=
 &nbsp;/* rest of file */</div><div><br></div><div>which essentially expand=
s to</div><div><br></div><div>&nbsp; &nbsp;#if !defined(&lt;tag&gt;)</div><=
div>&nbsp; &nbsp;#define &lt;tag&gt;</div><div>&nbsp; &nbsp;/* rest of file=
 */</div><div>&nbsp; &nbsp;#endif</div><div><br></div><div>but maybe with &=
lt;tag&gt; being a separate namespace from preprocessor macros (or not). An=
d perhaps &lt;tag&gt; is optional and an implementation-defined one is crea=
ted based on canonical file path, though that leaves one open to the proble=
ms Bo described.</div><div><br></div><div>Again, it all depends on modules =
and when they're implemented and how useful they end up being in practice</=
div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_69_779594313.1414004611066--

.

------=_Part_35_1636256856.1414013276033
Content-Type: text/plain; charset=UTF-8

On Wednesday, October 22, 2014 12:03:31 PM UTC-7, Sean Middleditch wrote:
>
> Well, there's value to having de facto standards match the de jure
> standard. See exported templates and their eventual removal as an example
> specific to C++. It's unfortunate when large codebases depend on a
> non-standard feature that "works" but is non-standard and then new tools
> that more closely follow the standard without extensions can't handle the
> codebase. Happens all the time with game engines in my experience,
> including specifically #pragma once issues.
>
>
^ This (except I'd reverse *de facto *and *de jure* for clarity).


>
> That said, #pragma once couldn't be added to the standard any sooner than
> C++17, and #pragma once _isn't_ a de facto standard because different
> implementations work differently, and there's the problems with complex
> source directories Bo mentions, and... I think all the reasons why this
> won't work were already clearly enumerated in the last thread on this very
> topic that came up some months ago.
>
>
#pragma once's behavior among compilers only really differs when the source
tree is in a traditional directory structure without any weirdness
happening.  Most of the other behavior is obvious: identify files by their
(volume ID, inode) pair.

I would specify #pragma once's behavior to be unspecified (but either
include or not include) in the event that the implementation cannot
reliably determine whether two files coincide.  If you want your code to
work, don't create a situation where you expect a file to not be
double-included when the codebase accesses it through two different mount
points for which the OS cannot identify them as identical or overlapping.

Sometimes #include guards have problems.  You can easily run into cases
where two unrelated headers think they're both the same name.

That said, Bo does have a point about the inability to work around
mistakes, or do sneaky tricks.  For example, how <cstdint> in at least one
Linux installation I saw is implemented as #undefining <stdint.h>'s
#include guard, #define-ing __STDC_CONSTANT_MACROS, and #include-ing
<stdint.h>.

Melissa

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_35_1636256856.1414013276033
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, October 22, 2014 12:03:31 PM UTC-7, Sean Mid=
dleditch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">Well, there's value to having de facto standards match the de jure standa=
rd. See exported templates and their eventual removal as an example specifi=
c to C++. It's unfortunate when large codebases depend on a non-standard fe=
ature that "works" but is non-standard and then new tools that more closely=
 follow the standard without extensions can't handle the codebase. Happens =
all the time with game engines in my experience, including specifically #pr=
agma once issues.<div><br></div></div></blockquote><div><br>^ This (except =
I'd reverse <i>de facto </i>and <i>de jure</i> for clarity).<br>&nbsp;<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></d=
iv><div><br></div><div>That said, #pragma once couldn't be added to the sta=
ndard any sooner than C++17, and #pragma once _isn't_ a de facto standard b=
ecause different implementations work differently, and there's the problems=
 with complex source directories Bo mentions, and... I think all the reason=
s why this won't work were already clearly enumerated in the last thread on=
 this very topic that came up some months ago.</div><div><br></div></div></=
blockquote><div><br>#pragma once's behavior among compilers only really dif=
fers when the source tree is in a traditional directory structure without a=
ny weirdness happening.&nbsp; Most of the other behavior is obvious: identi=
fy files by their (volume ID, inode) pair.<br><br>I would specify #pragma o=
nce's behavior to be unspecified (but either include or not include) in the=
 event that the implementation cannot reliably determine whether two files =
coincide.&nbsp; If you want your code to work, don't create a situation whe=
re you expect a file to not be double-included when the codebase accesses i=
t through two different mount points for which the OS cannot identify them =
as identical or overlapping.</div><br>Sometimes #include guards have proble=
ms.&nbsp; You can easily run into cases where two unrelated headers think t=
hey're both the same name.<br><br>That said, Bo does have a point about the=
 inability to work around mistakes, or do sneaky tricks.&nbsp; For example,=
 how &lt;cstdint&gt; in at least one Linux installation I saw is implemente=
d as #undefining &lt;stdint.h&gt;'s #include guard, #define-ing __STDC_CONS=
TANT_MACROS, and #include-ing &lt;stdint.h&gt;.<br><br>Melissa<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_35_1636256856.1414013276033--

.

On Wednesday 22 October 2014 14:27:56 Myriachan wrote:
> I would specify #pragma once's behavior to be unspecified (but either
> include or not include) in the event that the implementation cannot
> reliably determine whether two files coincide.  If you want your code to
> work, don't create a situation where you expect a file to not be
> double-included when the codebase accesses it through two different mount
> points for which the OS cannot identify them as identical or overlapping.

Sorry, but I don't think that's useful. If you leave the behaviour unspecified,
it isn't useful because we can't guarantee it will work.

I can't mandate where people should store my source code. Therefore, I can't
guarantee that the source code I write will work on their computers. That
means the feature is useless.

> Sometimes #include guards have problems.  You can easily run into cases
> where two unrelated headers think they're both the same name.

That can't happen, since you can't #include two different headers with the same
name (#include_next doesn't count).

Each include should have its canonical #include mechanism. If you a header is
#include'd with <module/header.h>, then the include guard should have both the
words "module" and "header" in the include guard.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_125_1669189462.1414055040845
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Seriously, I'm fed up with debugging those kind of errors no compiler can=
=20
even diagnose properly ! Just helped a (not so) beginner stuck with this=20
one :

#ifndef CSCWRITER_H_# define CSVWRITER_H_


Erreur 88 error C2995: 'CSV::Writer &CSV::operator <<(CSV::Writer &,const T=
=20
&)' : mod=C3=A8le de fonction d=C3=A9j=C3=A0 d=C3=A9fini CSVWriter.hxx 12

When you have a lot of experience you can at least think to verify those=20
sort of stuff, but hey, when you have under 2 years experience this means=
=20
hours of trying to debug a link error that's in fact a quite unvisible typo=
=20
in a header guard.

I myself also encounter errors myself when i copy a header to start another=
=20
one (without having to recode all the #include and all the namespace=20
a{namespaceb b{ boilerplate), and thanks to murphy I forget to change the=
=20
header guard name, and I do not run into any problem until i eventually=20
include both headers indirectly in one compile unit. If you just wrote the=
=20
second, you often remember to watch the header guards for this error, but=
=20
when you did it two weeks ago, have a good day.


*"It's complicated to implement from a compiler point of view so let the=20
programmer type a lot of super-murphy piece of code instead."*
Seriously ? Are we talking about C or ... ?

Header guards are not superior to anything the compiler can do with a=20
#pragma once equivalent, it's only a trade-off. And i would trade easily=20
sneaky link errors due to preprocessing issues for safety and simplicity.

No matter how hard it is to implement, since it's perfectly feasible (as an=
=20
ultimate resort, just compare the files content).

Although #pragma once would be nice since it's in large use, #once would at=
=20
least solve half the problem.

Le mardi 21 octobre 2014 21:29:21 UTC+2, Myriachan a =C3=A9crit :
>
> I think that #pragma once should be standardized - at least=20
> partially/optionally/conditionally-supported.  Every major compiler=20
> implements it with identical or nearly-identical semantics.
>
> Defining what it means for a file to be a repeat is rather simple: On=20
> platforms supporting symlinks and hard links, use unique inode numbers (+=
=20
> device if needed).  On other platforms, use the filename.  Compilers may=
=20
> assume that files don't change while compiling (i.e. if the filename=20
> matches, it can be assumed to be identical).  On platforms where there=20
> exist special links to the same or parent directory, like "./" or "../" o=
n=20
> NT and POSIX, this assumption can be extended to collapse these.
>
> By the way, why don't _Pragma and #line support concatenating multiple=20
> strings in their respective string parameters?
>
> Melissa
>

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_125_1669189462.1414055040845
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Seriously, I'm fed up with debugging those kind of errors =
no compiler can even diagnose properly ! Just helped a (not so) beginner st=
uck with this one :<br><br><pre><span style=3D"color: black"><span style=3D=
"color: #339933;">#ifndef CSCWRITER_H_</span>
<span style=3D"color: #339933;"># define CSVWRITER_H_<br></span></span></pr=
e><br><div class=3D"citation">Erreur 88 error C2995: 'CSV::Writer=20
&amp;CSV::operator &lt;&lt;(CSV::Writer &amp;,const T &amp;)'&nbsp;: mod=C3=
=A8le=20
de fonction d=C3=A9j=C3=A0 d=C3=A9fini CSVWriter.hxx 12<br><br>When you hav=
e a lot of experience you can at least think to verify those sort of stuff,=
 but hey, when you have under 2 years experience this means hours of trying=
 to debug a link error that's in fact a quite unvisible typo in a header gu=
ard.<br><br>I myself also encounter errors myself when i copy a header to s=
tart another one (without having to recode all the #include and all the nam=
espace a{namespaceb b{ boilerplate), and thanks to murphy I forget to chang=
e the header guard name, and I do not run into any problem until i eventual=
ly include both headers indirectly in one compile unit. If you just wrote t=
he second, you often remember to watch the header guards for this error, bu=
t when you did it two weeks ago, have a good day.<br><br><i>"It's complicat=
ed to implement from a compiler point of view so let the programmer type a =
lot of super-murphy piece of code instead."<br></i></div>Seriously ? Are we=
 talking about C or ... ?<br><br>Header guards are  not superior to anythin=
g the compiler can do with a #pragma once equivalent, it's only a trade-off=
.. And i would trade easily sneaky link errors due to preprocessing issues f=
or safety and simplicity.<br><br>No matter how hard it is to implement, sin=
ce it's perfectly feasible (as an ultimate resort, just compare the files c=
ontent).<br><br>Although #pragma once would be nice since it's in large use=
, #once would at least solve half the problem.<br><br>Le mardi 21 octobre 2=
014 21:29:21 UTC+2, Myriachan a =C3=A9crit&nbsp;:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr">I think that <span style=3D"font-family=
:courier new,monospace">#pragma once</span> should be standardized - at lea=
st partially/optionally/<wbr>conditionally-supported.&nbsp; Every major com=
piler implements it with identical or nearly-identical semantics.<br><br>De=
fining what it means for a file to be a repeat is rather simple: On platfor=
ms supporting symlinks and hard links, use unique inode numbers (+ device i=
f needed).&nbsp; On other platforms, use the filename.&nbsp; Compilers may =
assume that files don't change while compiling (i.e. if the filename matche=
s, it can be assumed to be identical).&nbsp; On platforms where there exist=
 special links to the same or parent directory, like "./" or "../" on NT an=
d POSIX, this assumption can be extended to collapse these.<br><br>By the w=
ay, why don't <span style=3D"font-family:courier new,monospace">_Pragma</sp=
an> and <span style=3D"font-family:courier new,monospace">#line</span> supp=
ort concatenating multiple strings in their respective string parameters?<b=
r><br>Melissa<br></div></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_125_1669189462.1414055040845--

.

On 10/23/2014 6:04 AM, Germinolegrand wrote:
> Seriously, I'm fed up with debugging those kind of errors no compiler
> can even diagnose properly ! Just helped a (not so) beginner stuck with
> this one :
>
> #ifndef CSCWRITER_H_
> # define CSVWRITER_H_
>
>
> Erreur 88 error C2995: 'CSV::Writer &CSV::operator <<(CSV::Writer
> &,const T &)' : mod=C3=A8le de fonction d=C3=A9j=C3=A0 d=C3=A9fini CSVWri=
ter.hxx 12
>

Clang 3.4 says:

prog.cc:1:9: warning: 'CSCWRITER_H_' is used as a header guard here,=20
followed by #define of a different macro [-Wheader-guard] #ifndef=20
CSCWRITER_H_ ^~~~~~~~~~~~

prog.cc:2:10: note: 'CSVWRITER_H_' is defined here; did you mean=20
'CSCWRITER_H_'? # define CSVWRITER_H_ ^~~~~~~~~~~~ CSCWRITER_H_ 1=20
warning generated.

Live demo here: http://melpon.org/wandbox/permlink/4ZNSw5ijsqIoTrOp

Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_695_1647771071.1414068113895
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I wish so much I could use clang... such a great compiler :-).
But when a compiler has to analyse code patterns, I believe those should at=
=20
least be turned into a "language" feature, #once <tag>.
Anyway, this leaves us with the other half, still unsolved even on clang.

Le jeudi 23 octobre 2014 14:20:59 UTC+2, Agust=C3=ADn K-ballo Berg=C3=A9 a =
=C3=A9crit :

>
> Clang 3.4 says:=20
>
> prog.cc:1:9: warning: 'CSCWRITER_H_' is used as a header guard here,=20
> followed by #define of a different macro [-Wheader-guard] #ifndef=20
> CSCWRITER_H_ ^~~~~~~~~~~~=20
>
> prog.cc:2:10: note: 'CSVWRITER_H_' is defined here; did you mean=20
> 'CSCWRITER_H_'? # define CSVWRITER_H_ ^~~~~~~~~~~~ CSCWRITER_H_ 1=20
> warning generated.=20
>
> Live demo here: http://melpon.org/wandbox/permlink/4ZNSw5ijsqIoTrOp=20
>
> Regards,=20
> --=20
> Agust=C3=ADn K-ballo Berg=C3=A9.-=20
> http://talesofcpp.fusionfenix.com=20
>

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_695_1647771071.1414068113895
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I wish so much I could use clang... such a great compiler =
:-).<br>
But when a compiler has to analyse code patterns, I believe those should
 at least be turned into a "language" feature, #once &lt;tag&gt;.<br>
Anyway, this leaves us with the other half, still unsolved even on clang.<b=
r><br>Le jeudi 23 octobre 2014 14:20:59 UTC+2, Agust=C3=ADn K-ballo Berg=C3=
=A9 a =C3=A9crit&nbsp;:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Clang 3.4 says:
<br>
<br>prog.cc:1:9: warning: 'CSCWRITER_H_' is used as a header guard here,=20
<br>followed by #define of a different macro [-Wheader-guard] #ifndef=20
<br>CSCWRITER_H_ ^~~~~~~~~~~~
<br>
<br>prog.cc:2:10: note: 'CSVWRITER_H_' is defined here; did you mean=20
<br>'CSCWRITER_H_'? # define CSVWRITER_H_ ^~~~~~~~~~~~ CSCWRITER_H_ 1=20
<br>warning generated.
<br>
<br>Live demo here: <a href=3D"http://melpon.org/wandbox/permlink/4ZNSw5ijs=
qIoTrOp" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\75http%3A%2F%2Fmelpon.org%2Fwandbox%2Fpermlink%2F4ZNSw5ijsqIoTrOp\4=
6sa\75D\46sntz\0751\46usg\75AFQjCNEhFIpJgj2UfXCe3u5AQLljxvoqZA';return true=
;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fmelpo=
n.org%2Fwandbox%2Fpermlink%2F4ZNSw5ijsqIoTrOp\46sa\75D\46sntz\0751\46usg\75=
AFQjCNEhFIpJgj2UfXCe3u5AQLljxvoqZA';return true;">http://melpon.org/wandbox=
/<wbr>permlink/4ZNSw5ijsqIoTrOp</a>
<br>
<br>Regards,
<br>--=20
<br>Agust=C3=ADn K-ballo Berg=C3=A9.-
<br><a href=3D"http://talesofcpp.fusionfenix.com" target=3D"_blank" onmouse=
down=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Ftalesofcpp.=
fusionfenix.com\46sa\75D\46sntz\0751\46usg\75AFQjCNGrOc8fm1PhW0305mMc5XVd9N=
U-_Q';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75h=
ttp%3A%2F%2Ftalesofcpp.fusionfenix.com\46sa\75D\46sntz\0751\46usg\75AFQjCNG=
rOc8fm1PhW0305mMc5XVd9NU-_Q';return true;">http://talesofcpp.fusionfenix.<w=
br>com</a>
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_695_1647771071.1414068113895--

.

------=_Part_632_776511418.1414068652822
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Le jeudi 23 octobre 2014 11:04:00 UTC+2, Germinolegrand a =C3=A9crit :
>
>
> *"It's complicated to implement from a compiler point of view so let the=
=20
> programmer type a lot of super-murphy piece of code instead.*
>

The issue is not that it is complex to implement, the issues are first that=
=20
it is complex to *define* what should be the same file, and second
that if pragma once does not allows to solve all the problems in all the=20
situations include guards are currently used, you'll still have to use
include guards, you'll still have to teach about them and you'll have an=20
additional issue "When to use include guards and when to use
pragma once".

Currently include guards are used portably among vastly different systems=
=20
(and so leaving the *same file* definition to the implementation
won't help, they still would have to agree), with linked include files=20
(symbolic or hard link), build system copying include files to cache them
but  where the original is still in the include path and both can in fact=
=20
both be found in the same CU (due to #include "module/file.hpp" and
#include "file.hpp" finding each one or due to #include "" searching in the=
=20
current directory), mounted file systems, VCS masquerading as
file systems, and so on.

I'm not saying it is impossible to get a usable definition solving those=20
issues.  I'm not saying that they all need to be solved to get a
pragma once in the standard.  I've just not seen a proposal at all (I just=
=20
went through the last 10 years of papers searching for once and
preprocessor in the titles and found nothing relevant; if I've missed it,=
=20
just give me the paper number) and a proposal should at least:
- shows what problems it solve (standardizing current state while fixing=20
corner cases is useful, standardizing current state and leaving corner
cases differ between implementations brings nothing IMHO)
- shows how it is fundamentally better than the current states
- at least list the above cases and states what it proposes for it, why it=
=20
proposes so.

Note that the fact there is progress made on a feature which tackles the=20
root cause (i.e. the lack of a module system in C++) instead of a symptom
increases for me the need of a proof that the pragma would be more useful=
=20
than the current situation and not just put a "Standard" stamp on
a unchanged situation.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_632_776511418.1414068652822
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le jeudi 23 octobre 2014 11:04:00 UTC+2, Germinole=
grand a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div><br><i>"It's complicated to implement from a compiler poin=
t of view so let the programmer type a lot of super-murphy piece of code in=
stead.</i></div></div></blockquote><div><br></div><div>The issue is not tha=
t it is complex to implement, the issues are first that it is complex to <b=
>define</b>&nbsp;what should be the same file, and second</div><div>that if=
 pragma once does not allows to solve all the problems in all the situation=
s include guards are currently used, you'll still have to use</div><div>inc=
lude guards, you'll still have to teach about them and you'll have an addit=
ional issue "When to use include guards and when to use</div><div>pragma on=
ce".</div><div><br></div><div>Currently include guards are used portably am=
ong vastly different systems (and so leaving the <i>same file</i>&nbsp;defi=
nition to the implementation</div><div>won't help, they still would have to=
 agree), with linked include files (symbolic or hard link), build system co=
pying include files to cache them</div><div>but &nbsp;where the original is=
 still in the include path and both can in fact both be found in the same C=
U (due to #include "module/file.hpp" and</div><div>#include "file.hpp" find=
ing each one or due to #include "" searching in the current directory), mou=
nted file systems, VCS masquerading as</div><div>file systems, and so on.</=
div><div><br></div><div>I'm not saying it is impossible to get a usable def=
inition solving those issues. &nbsp;I'm not saying that they all need to be=
 solved to get a</div><div>pragma once in the standard. &nbsp;I've just not=
 seen a proposal at all (I just went through the last 10 years of papers se=
arching for once and</div><div>preprocessor in the titles and found nothing=
 relevant; if I've missed it, just give me the paper number) and a proposal=
 should at least:</div><div>- shows what problems it solve (standardizing c=
urrent state while fixing corner cases is useful, standardizing current sta=
te and leaving corner</div><div>cases differ between implementations brings=
 nothing IMHO)</div><div>- shows how it is fundamentally better than the cu=
rrent states</div><div>- at least list the above cases and states what it p=
roposes for it, why it proposes so.</div><div><br></div><div>Note that the =
fact there is progress made on a feature which tackles the root cause (i.e.=
 the lack of a module system in C++) instead of a symptom</div><div>increas=
es for me the need of a proof that the pragma would be more useful than the=
 current situation and not just put a "Standard" stamp on</div><div>a uncha=
nged situation.</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_632_776511418.1414068652822--

.

On Thursday 23 October 2014 05:41:53 Germinolegrand wrote:
> I wish so much I could use clang... such a great compiler :-).
> But when a compiler has to analyse code patterns, I believe those should at
> least be turned into a "language" feature, #once <tag>.

I completely disagree. Taking what you said to the extreme would change the
language completely.

Clang is very good at providing warnings, like "you're memcpying to an object
with virtual table". There are few reasons why you'd want to do that, but they
exist, so it's the correct solution for the compiler to warn you instead of
making it an error.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_1369_1645625040.1414134911944
Content-Type: text/plain; charset=UTF-8

Melissa,

I agree with you. I use GNU compiler and have source files that are
included more than one time.

Because it is harder to write preprocessor directives with an equivalent
functionality than to press Ctrl + C and Ctrl + V, I prefer to copy and
paste all the files inside a giant file for the compilers, which doesn't
support #pragma once, than to write the preprocessor directives for each
source file, that is included more than one time.

PF, ncomputers

Am Dienstag, 21. Oktober 2014 14:29:21 UTC-5 schrieb Myriachan:
>
> I think that #pragma once should be standardized - at least
> partially/optionally/conditionally-supported.  Every major compiler
> implements it with identical or nearly-identical semantics.
>
> Defining what it means for a file to be a repeat is rather simple: On
> platforms supporting symlinks and hard links, use unique inode numbers (+
> device if needed).  On other platforms, use the filename.  Compilers may
> assume that files don't change while compiling (i.e. if the filename
> matches, it can be assumed to be identical).  On platforms where there
> exist special links to the same or parent directory, like "./" or "../" on
> NT and POSIX, this assumption can be extended to collapse these.
>
> By the way, why don't _Pragma and #line support concatenating multiple
> strings in their respective string parameters?
>
> Melissa
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1369_1645625040.1414134911944
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Melissa,<br><br>I agree with you. I use GNU compiler and h=
ave source files that are included more than one time.<br><br>Because it is=
 harder to write preprocessor directives with an equivalent functionality t=
han to press Ctrl + C and Ctrl + V, I prefer to copy and paste all the file=
s inside a giant file for the compilers, which doesn't support <span style=
=3D"background-color: rgb(204, 204, 204);"><span style=3D"color: rgb(0, 0, =
0);"><span style=3D"font-family: courier new,monospace;">#pragma once</span=
></span></span>, than to write the preprocessor directives for each source =
file, that is included more than one time.<br><br>PF, ncomputers<br><br>Am =
Dienstag, 21. Oktober 2014 14:29:21 UTC-5 schrieb Myriachan:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I think that <span style=3D"=
font-family:courier new,monospace">#pragma once</span> should be standardiz=
ed - at least partially/optionally/<wbr>conditionally-supported.&nbsp; Ever=
y major compiler implements it with identical or nearly-identical semantics=
..<br><br>Defining what it means for a file to be a repeat is rather simple:=
 On platforms supporting symlinks and hard links, use unique inode numbers =
(+ device if needed).&nbsp; On other platforms, use the filename.&nbsp; Com=
pilers may assume that files don't change while compiling (i.e. if the file=
name matches, it can be assumed to be identical).&nbsp; On platforms where =
there exist special links to the same or parent directory, like "./" or "..=
/" on NT and POSIX, this assumption can be extended to collapse these.<br><=
br>By the way, why don't <span style=3D"font-family:courier new,monospace">=
_Pragma</span> and <span style=3D"font-family:courier new,monospace">#line<=
/span> support concatenating multiple strings in their respective string pa=
rameters?<br><br>Melissa<br></div></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1369_1645625040.1414134911944--

.

------=_Part_9_1051233432.1414713252041
Content-Type: text/plain; charset=UTF-8

Hypothetical:

Ignoring compatibility problems....

imagine if #pragma once was the default and some other kind of
statement existed to change the default where needed e.g. #pragma
multiple or even #include multiple <x>....

Now imagine if something like this extension was implemented in clang...

First, what to people think would be the effort (in days) to implement that
change in the clang compiler itself (i.e. to support the new semantics and
keywords),?

then what do people think would be the effort (in days) to convert the
project itself to use that extension... (i.e. add the keywords where the
default #once doesn't work)?

then finally what do people think would be the speed up (in % build
time), if clang (or any project like it) were compiled using that
extensions?



On Wednesday, October 22, 2014 8:29:21 AM UTC+13, Myriachan wrote:

> I think that #pragma once should be standardized - at least
> partially/optionally/conditionally-supported.  Every major compiler
> implements it with identical or nearly-identical semantics.
>
> Defining what it means for a file to be a repeat is rather simple: On
> platforms supporting symlinks and hard links, use unique inode numbers (+
> device if needed).  On other platforms, use the filename.  Compilers may
> assume that files don't change while compiling (i.e. if the filename
> matches, it can be assumed to be identical).  On platforms where there
> exist special links to the same or parent directory, like "./" or "../" on
> NT and POSIX, this assumption can be extended to collapse these.
>
> By the way, why don't _Pragma and #line support concatenating multiple
> strings in their respective string parameters?
>
> Melissa
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_9_1051233432.1414713252041
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hypothetical:</div><div><br></div><div>Ignoring compa=
tibility problems....</div><div><br></div><div>imagine if #pragma once was =
the default and&nbsp;some other kind of statement&nbsp;existed to change th=
e default&nbsp;where needed e.g.&nbsp;#pragma multiple&nbsp;or even #includ=
e multiple &lt;x&gt;....</div><div><br></div><div>Now imagine&nbsp;if somet=
hing like this extension was implemented in clang...</div><div><br></div><d=
iv>First, what to people think would be the effort (in days) to implement t=
hat change&nbsp;in the clang compiler itself (i.e. to support the new seman=
tics and keywords),?</div><div><br></div><div>then what do people think wou=
ld be the effort (in days) to convert the project itself to use that extens=
ion... (i.e. add the keywords where the default #once doesn't work)?</div><=
div><br></div><div>then finally what do people think would be the&nbsp;spee=
d up&nbsp;(in % build time),&nbsp;if&nbsp;clang (or any project like it) we=
re&nbsp;compiled&nbsp;using that extensions?</div><div><br></div><div><br><=
/div><div><br>On Wednesday, October 22, 2014 8:29:21 AM UTC+13, Myriachan w=
rote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;"><div dir=3D"ltr">I think that <span=
 style=3D"font-family: courier new,monospace;">#pragma once</span> should b=
e standardized - at least partially/optionally/<wbr>conditionally-supported=
..&nbsp; Every major compiler implements it with identical or nearly-identic=
al semantics.<br><br>Defining what it means for a file to be a repeat is ra=
ther simple: On platforms supporting symlinks and hard links, use unique in=
ode numbers (+ device if needed).&nbsp; On other platforms, use the filenam=
e.&nbsp; Compilers may assume that files don't change while compiling (i.e.=
 if the filename matches, it can be assumed to be identical).&nbsp; On plat=
forms where there exist special links to the same or parent directory, like=
 "./" or "../" on NT and POSIX, this assumption can be extended to collapse=
 these.<br><br>By the way, why don't <span style=3D"font-family: courier ne=
w,monospace;">_Pragma</span> and <span style=3D"font-family: courier new,mo=
nospace;">#line</span> support concatenating multiple strings in their resp=
ective string parameters?<br><br>Melissa<br></div></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_9_1051233432.1414713252041--

.

------=_Part_1133_1659417336.1414713597873
Content-Type: text/plain; charset=UTF-8


>
>
> then what do people think would be the effort (in days) to convert the
> project itself to use that extension... (i.e. add the keywords where the
> default #once doesn't work)?
>
>
>
To try to be clearer here.., I'm talking about changing clang to support an
extension, then changing the clang project to use the extension and then
comparing build times of building the clang project with clang (or any
compiler really that supports those extension) and what might we expect to
see as a % speed up.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1133_1659417336.1414713597873
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><br></d=
iv><div>then what do people think would be the effort (in days) to convert =
the project itself to use that extension... (i.e. add the keywords where th=
e default #once doesn't work)?</div><div><br></div><div><br></div></div></b=
lockquote><div>&nbsp;</div><div>To try to be clearer here.., I'm talking ab=
out changing&nbsp;clang to support an extension, then&nbsp;changing the cla=
ng project to use the extension and then comparing build times of building =
the clang project with clang (or any compiler really that supports&nbsp;tho=
se extension) and what might we expect to see as a % speed up.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1133_1659417336.1414713597873--

.

--part3146-boundary-509980198-1164075283
Content-Type: text/plain; charset=UTF-8

Why any speedup at all should be expected?

After all, it is just a cpp directive that saves to write other three.

If *you* want to write an extension, write the shorthand equivalent, e.g.

#guard guardname
....
#endguard

being a shorthand of

#ifdef guardname
#define guardname
....
#endif

which is still of doubtful usefulness (and if so, only in terms of writing one less line and avoiding errors because of typos, but not in terms of building speedup).
-----Original Message-----
From: gmisocpp@gmail.com
Date: Thu, 30 Oct 2014 16:59:57
To: <std-proposals@isocpp.org>
Reply-To: std-proposals@isocpp.org
Cc: <gmisocpp@gmail.com>
Subject: [std-proposals] Re: #pragma once


>
>
> then what do people think would be the effort (in days) to convert the
> project itself to use that extension... (i.e. add the keywords where the
> default #once doesn't work)?
>
>
>
To try to be clearer here.., I'm talking about changing clang to support an
extension, then changing the clang project to use the extension and then
comparing build times of building the clang project with clang (or any
compiler really that supports those extension) and what might we expect to
see as a % speed up.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--part3146-boundary-509980198-1164075283
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html><head><=
meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type"></h=
ead><body>Why any speedup at all should be expected?<br/><br/>After all, it=
 is just a cpp directive that saves to write other three.<br/><br/>If *you*=
 want to write an extension, write the shorthand equivalent, e.g.<br/><br/>=
#guard guardname<br/>...<br/>#endguard<br/><br/>being a shorthand of<br/><b=
r/>#ifdef guardname<br/>#define guardname<br/>...<br/>#endif<br/><br/>which=
 is still of doubtful usefulness (and if so, only in terms of writing one l=
ess line and avoiding errors because of typos, but not in terms of building=
 speedup).<hr/><div><b>From: </b> gmisocpp@gmail.com
</div><div><b>Date: </b>Thu, 30 Oct 2014 16:59:57 -0700 (PDT)</div><div><b>=
To: </b>&lt;std-proposals@isocpp.org&gt;</div><div><b>ReplyTo: </b> std-pro=
posals@isocpp.org
</div><div><b>Cc: </b>&lt;gmisocpp@gmail.com&gt;</div><div><b>Subject: </b>=
[std-proposals] Re: #pragma once</div><div><br/></div><div dir=3D"ltr"><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-l=
eft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bo=
rder-left-style: solid;"><div dir=3D"ltr"><div><br></div><div>then what do =
people think would be the effort (in days) to convert the project itself to=
 use that extension... (i.e. add the keywords where the default #once doesn=
't work)?</div><div><br></div><div><br></div></div></blockquote><div>&nbsp;=
</div><div>To try to be clearer here.., I'm talking about changing&nbsp;cla=
ng to support an extension, then&nbsp;changing the clang project to use the=
 extension and then comparing build times of building the clang project wit=
h clang (or any compiler really that supports&nbsp;those extension) and wha=
t might we expect to see as a % speed up.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

</body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--part3146-boundary-509980198-1164075283--


.

--089e013cb9bed7db460506ad6f71
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 30, 2014 at 4:54 PM, <gmisocpp@gmail.com> wrote:

> Hypothetical:
>
> Ignoring compatibility problems....
>
> imagine if #pragma once was the default and some other kind of
> statement existed to change the default where needed e.g. #pragma
> multiple or even #include multiple <x>....
>
> Now imagine if something like this extension was implemented in clang...
>
> First, what to people think would be the effort (in days) to implement
> that change in the clang compiler itself (i.e. to support the new semantics
> and keywords),?
>

Small (a day or so).


> then what do people think would be the effort (in days) to convert the
> project itself to use that extension... (i.e. add the keywords where the
> default #once doesn't work)?
>

Small (a day or so; we have a lot of textually-included headers, and we
build tools that generate headers, all of which would need to be updated).


> then finally what do people think would be the speed up (in % build
> time), if clang (or any project like it) were compiled using that
> extensions?
>

I would not expect any measurable difference. We already detect include
guards and get all the performance benefits of #pragma once from them.

On Wednesday, October 22, 2014 8:29:21 AM UTC+13, Myriachan wrote:
>
>> I think that #pragma once should be standardized - at least
>> partially/optionally/conditionally-supported.  Every major compiler
>> implements it with identical or nearly-identical semantics.
>>
>> Defining what it means for a file to be a repeat is rather simple: On
>> platforms supporting symlinks and hard links, use unique inode numbers (+
>> device if needed).  On other platforms, use the filename.  Compilers may
>> assume that files don't change while compiling (i.e. if the filename
>> matches, it can be assumed to be identical).  On platforms where there
>> exist special links to the same or parent directory, like "./" or "../" on
>> NT and POSIX, this assumption can be extended to collapse these.
>>
>> By the way, why don't _Pragma and #line support concatenating multiple
>> strings in their respective string parameters?
>>
>> Melissa
>>
>  --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e013cb9bed7db460506ad6f71
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Oct 30, 2014 at 4:54 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:gmiso=
cpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Hypothetical:</div><=
div><br></div><div>Ignoring compatibility problems....</div><div><br></div>=
<div>imagine if #pragma once was the default and=C2=A0some other kind of st=
atement=C2=A0existed to change the default=C2=A0where needed e.g.=C2=A0#pra=
gma multiple=C2=A0or even #include multiple &lt;x&gt;....</div><div><br></d=
iv><div>Now imagine=C2=A0if something like this extension was implemented i=
n clang...</div><div><br></div><div>First, what to people think would be th=
e effort (in days) to implement that change=C2=A0in the clang compiler itse=
lf (i.e. to support the new semantics and keywords),?</div></div></blockquo=
te><div><br></div><div>Small (a day or so).</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div>then what do people think would=
 be the effort (in days) to convert the project itself to use that extensio=
n... (i.e. add the keywords where the default #once doesn&#39;t work)?</div=
></div></blockquote><div><br></div><div>Small (a day or so; we have a lot o=
f textually-included headers, and we build tools that generate headers, all=
 of which would need to be updated).</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>then finally what do people think woul=
d be the=C2=A0speed up=C2=A0(in % build time),=C2=A0if=C2=A0clang (or any p=
roject like it) were=C2=A0compiled=C2=A0using that extensions?</div></div><=
/blockquote><div><br></div><div>I would not expect any measurable differenc=
e. We already detect include guards and get all the performance benefits of=
 #pragma once from them.</div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><div class=3D"h5"><div>On Wednesday, October 22, 201=
4 8:29:21 AM UTC+13, Myriachan wrote:</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(=
204,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr=
">I think that <span style=3D"font-family:courier new,monospace">#pragma on=
ce</span> should be standardized - at least partially/optionally/<u></u>con=
ditionally-supported.=C2=A0 Every major compiler implements it with identic=
al or nearly-identical semantics.<br><br>Defining what it means for a file =
to be a repeat is rather simple: On platforms supporting symlinks and hard =
links, use unique inode numbers (+ device if needed).=C2=A0 On other platfo=
rms, use the filename.=C2=A0 Compilers may assume that files don&#39;t chan=
ge while compiling (i.e. if the filename matches, it can be assumed to be i=
dentical).=C2=A0 On platforms where there exist special links to the same o=
r parent directory, like &quot;./&quot; or &quot;../&quot; on NT and POSIX,=
 this assumption can be extended to collapse these.<br><br>By the way, why =
don&#39;t <span style=3D"font-family:courier new,monospace">_Pragma</span> =
and <span style=3D"font-family:courier new,monospace">#line</span> support =
concatenating multiple strings in their respective string parameters?<br><b=
r>Melissa<br></div></blockquote></div></div></div><div class=3D"HOEnZb"><di=
v class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e013cb9bed7db460506ad6f71--

.

------=_Part_585_1022706586.1414720935367
Content-Type: text/plain; charset=UTF-8



On Friday, October 31, 2014 1:54:20 PM UTC+13, Richard Smith wrote:
>
> On Thu, Oct 30, 2014 at 4:54 PM, <gmis...@gmail.com <javascript:>> wrote:
>
>> Hypothetical:
>>
>> Ignoring compatibility problems....
>>
>> imagine if #pragma once was the default and some other kind of
>> statement existed to change the default where needed e.g. #pragma
>> multiple or even #include multiple <x>....
>>
>> Now imagine if something like this extension was implemented in clang...
>>
>> First, what to people think would be the effort (in days) to implement
>> that change in the clang compiler itself (i.e. to support the new semantics
>> and keywords),?
>>
>
> Small (a day or so).
>
>
>> then what do people think would be the effort (in days) to convert the
>> project itself to use that extension... (i.e. add the keywords where the
>> default #once doesn't work)?
>>
>
> Small (a day or so; we have a lot of textually-included headers, and we
> build tools that generate headers, all of which would need to be updated).
>
>
>> then finally what do people think would be the speed up (in % build
>> time), if clang (or any project like it) were compiled using that
>> extensions?
>>
>
> I would not expect any measurable difference. We already detect include
> guards and get all the performance benefits of #pragma once from them.
>
>
Thanks Richard!

ok, so does that mean then that making #pragma once Standard does nothing
for performance, it just adds a nice convenience of not having to have
#include guards but one still has to be mindful of multiple inclusion each
time. Making #pragma once Standard would also helps by making some existing
code, Standard code.

By contrast,  #pragma multiple (or whatever) as a new feature, would mean
breaking some existing code, but even for pretty large projects, fixing
it would only be a days work and some of that time would be recouped by the
fact that nobody would need to write or fix a broken include guard ever
again in the project, or any new one ever...

I don't imagine anyone would ever go for that contrasting option, but I
thought it was worth throwing it out there to see if it was viable.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_585_1022706586.1414720935367
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, October 31, 2014 1:54:20 PM UTC+13, Ric=
hard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote">On Thu, Oct 30, 2014 at 4:54 PM,  <span dir=3D"ltr">&lt=
;<a onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.=
href=3D'javascript:';return true;" href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"0ncy0qZxxFEJ">gmis...@gmail.com</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
 padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-widt=
h: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>Hypothetical:</div=
><div><br></div><div>Ignoring compatibility problems....</div><div><br></di=
v><div>imagine if #pragma once was the default and&nbsp;some other kind of =
statement&nbsp;existed to change the default&nbsp;where needed e.g.&nbsp;#p=
ragma multiple&nbsp;or even #include multiple &lt;x&gt;....</div><div><br><=
/div><div>Now imagine&nbsp;if something like this extension was implemented=
 in clang...</div><div><br></div><div>First, what to people think would be =
the effort (in days) to implement that change&nbsp;in the clang compiler it=
self (i.e. to support the new semantics and keywords),?</div></div></blockq=
uote><div><br></div><div>Small (a day or so).</div><div>&nbsp;</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;"><div dir=3D"ltr"><div>then what do people think would=
 be the effort (in days) to convert the project itself to use that extensio=
n... (i.e. add the keywords where the default #once doesn't work)?</div></d=
iv></blockquote><div><br></div><div>Small (a day or so; we have a lot of te=
xtually-included headers, and we build tools that generate headers, all of =
which would need to be updated).</div><div>&nbsp;</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border=
-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style:=
 solid;"><div dir=3D"ltr"><div>then finally what do people think would be t=
he&nbsp;speed up&nbsp;(in % build time),&nbsp;if&nbsp;clang (or any project=
 like it) were&nbsp;compiled&nbsp;using that extensions?</div></div></block=
quote><div><br></div><div>I would not expect any measurable difference. We =
already detect include guards and get all the performance benefits of #prag=
ma once from them.</div><div><br></div></div></div></div></blockquote><div>=
<br></div><div>Thanks Richard!</div><div><br></div><div>ok, so does that me=
an then that making #pragma once Standard&nbsp;does nothing for performance=
,&nbsp;it just&nbsp;adds a nice convenience&nbsp;of not having to have #inc=
lude guards but one still has to be mindful of multiple inclusion each time=
.. Making #pragma once Standard&nbsp;would also&nbsp;helps by&nbsp;making so=
me existing code, Standard code.</div><div><br></div><div>By contrast,&nbsp=
; #pragma multiple&nbsp;(or whatever) as a new feature,&nbsp;would mean bre=
aking some existing code, but even for pretty large projects,&nbsp;fixing i=
t&nbsp;would only be&nbsp;a days work&nbsp;and some of that time&nbsp;would=
 be&nbsp;recouped by the fact that nobody&nbsp;would need to write or fix a=
 broken include guard ever again in the project, or any new one ever...</di=
v><div><br></div><div>I don't imagine anyone would ever go for that contras=
ting option, but I thought it was worth throwing it out there to see if it =
was viable.</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_585_1022706586.1414720935367--

.

On Fri, Oct 31, 2014 at 3:02 AM,  <gmisocpp@gmail.com> wrote:
> By contrast,  #pragma multiple (or whatever) as a new feature, would mean
> breaking some existing code, but even for pretty large projects, fixing it
> would only be a days work and some of that time would be recouped by the
> fact that nobody would need to write or fix a broken include guard ever
> again in the project, or any new one ever...
>
> I don't imagine anyone would ever go for that contrasting option, but I
> thought it was worth throwing it out there to see if it was viable.

#pragma multiple sounds quite nice. How many headers can be included
multiple times? cassert maybe

A warning to warn about files without header guards would allow such
files to be easily detected.



--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.