------=_Part_1896_1637156457.1435325476502
Content-Type: multipart/alternative;
 boundary="----=_Part_1897_2128087435.1435325476502"

------=_Part_1897_2128087435.1435325476502
Content-Type: text/plain; charset=UTF-8

Currently only classes can be forward-declared like

class A;

If the class is defined using struct instead, it also has to be forward
declared like
struct A;

There is no way currently to forward declare typedef and enum.

But sometimes it is not known whether the type will be a class (defined
with class or struct) or a typedef resolving to some class. But to get an
incomplete type it wouldn't matter since the compiler only needs to know
that it is a type. Because of that there is for example the header <iosfwd>
with only forward declarations of classes and of typedefs.

Maybe it would be good to have a universal syntax for forward declarations,
for example

typename A;

That allows the use of A* or A& where A can be later defined as any one of

class A { ... };
struct A { ... };
enum A { ... };
enum class A: long int { ... };
typedef A_<int> A;
using A =A_ <int>;


--

---
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_1897_2128087435.1435325476502
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Currently only classes can be forward-declared like<div><b=
r></div><div><div class=3D"prettyprint" style=3D"background-color: rgb(250,=
 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#66=
0066"><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> A</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span></font></div></c=
ode></div><div><br></div>If the class is defined using <font face=3D"courie=
r new, monospace">struct</font><font face=3D"arial, sans-serif">&nbsp;inste=
ad, it also has to be forward declared like</font></div><div><font face=3D"=
arial, sans-serif"><div class=3D"prettyprint" style=3D"background-color: rg=
b(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-wo=
rd;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><font color=
=3D"#660066"><span style=3D"color: #008;" class=3D"styled-by-prettify">stru=
ct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> A</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span></font><=
/div></code></div><div><font face=3D"arial, sans-serif"><br></font></div>Th=
ere is no way currently to forward declare </font><font face=3D"courier new=
, monospace">typedef</font><font face=3D"arial, sans-serif">&nbsp;and&nbsp;=
</font><font face=3D"courier new, monospace">enum</font><font face=3D"arial=
, sans-serif">.</font></div><div><font face=3D"courier new, monospace"><br>=
</font>But sometimes it is not known whether the type will be a class (defi=
ned with class or struct) or a typedef resolving to some class. But to get =
an incomplete type it wouldn't matter since the compiler only needs to know=
 that it is a type. Because of that there is for example the header <font f=
ace=3D"courier new, monospace">&lt;iosfwd&gt;</font> with only forward decl=
arations of classes and of typedefs.</div><div><br></div><div>Maybe it woul=
d be good to have a universal syntax for forward declarations, for example<=
/div><div><br></div><div><div class=3D"prettyprint" style=3D"background-col=
or: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: br=
eak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><font =
color=3D"#660066"><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>typename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
A</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
/font></div></code></div><div><br></div>That allows the use of <font face=
=3D"courier new, monospace">A*</font><font face=3D"arial, sans-serif">&nbsp=
;or </font><font face=3D"courier new, monospace">A&amp;</font><font face=3D=
"arial, sans-serif"> where </font><font face=3D"courier new, monospace">A</=
font><font face=3D"arial, sans-serif">&nbsp;can be later defined as any one=
 of</font></div><div><font face=3D"arial, sans-serif"><br></font></div><div=
><font face=3D"arial, sans-serif"><div class=3D"prettyprint" style=3D"backg=
round-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word=
-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> A </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </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: #660;" class=3D"style=
d-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> A =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">enum</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> A </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> <br></span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">enum</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> A</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">long</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </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: #660;" class=3D"style=
d-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">typedef</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> A_</span><span st=
yle=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> A</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">using</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> A </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">A_ </span><span style=3D"color: #080;" class=3D"styled-by-prettif=
y">&lt;</span><span style=3D"color: #080;" class=3D"styled-by-prettify">int=
</span><font color=3D"#666600"><span style=3D"color: #080;" class=3D"styled=
-by-prettify">&gt;</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span></font></div></code></div><br><br></font></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_1897_2128087435.1435325476502--
------=_Part_1896_1637156457.1435325476502--

.

On 26 June 2015 at 16:31, tmlen <timlenertz@gmail.com> wrote:
> Currently only classes can be forward-declared like
>
> class A;
>
> If the class is defined using struct instead, it also has to be forward
> declared like
> struct A;

That's not correct. I'm aware of certain implementations *cough*msvc*cough*
that treat that incorrectly, but you can certainly forward-declare
with either keyword
regardless of which keyword is used in the definition.

For the rest of it, this has been discussed before:
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/9hXHc6AS9M8/Zf7jN3K5Hz8J

--

---
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_1660396214.1435364962792
Content-Type: multipart/alternative;
 boundary="----=_Part_70_1876659580.1435364962792"

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

For the record, MSVC isn't the only offender; Clang can't deal with=20
mismatched tags either.
"struct vs. class" is merely a build-breaking "warning" diagnostic; but=20
"union vs. class" is a hard error that can't be worked around AFAIK.
I think what tmlen is asking for is for the Standard to bless both=20
constructs so that compilers (whether MS or otherwise) have no excuse to=20
reject them. I'd certainly like to see that, myself.

=E2=80=93Arthur

$ clang++ x.cc -std=3Dc++11 -Wall -W

*x.cc:3:1: **warning: **'T' defined as a struct here but previously=20
declared as a class [-Wmismatched-tags]*

struct T { };

*^*

*x.cc:1:1: note: *did you mean struct here?

class T;

*^~~~~*

struct

1 warning generated.


*x.cc:3:1: **error: **use of 'U' with tag type that does not match previous=
=20
declaration*

union U { };

*^~~~~*

class

*x.cc:1:7: note: *previous use is here

class U;

*      ^*

1 error generated.


On Friday, June 26, 2015 at 6:37:14 AM UTC-7, Ville Voutilainen wrote:
>
> On 26 June 2015 at 16:31, tmlen <timle...@gmail.com <javascript:>> wrote:=
=20
> > Currently only classes can be forward-declared like=20
> >=20
> > class A;=20
> >=20
> > If the class is defined using struct instead, it also has to be forward=
=20
> > declared like=20
> > struct A;=20
>
> That's not correct. I'm aware of certain implementations=20
> *cough*msvc*cough*=20
> that treat that incorrectly, but you can certainly forward-declare=20
> with either keyword=20
> regardless of which keyword is used in the definition.=20
>
> For the rest of it, this has been discussed before:=20
>
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/9hXHc6AS9M8/Zf=
7jN3K5Hz8J=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_70_1876659580.1435364962792
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">For the record, MSVC isn't the only offender; Clang can't =
deal with mismatched tags either.<div>"struct vs. class" is merely a build-=
breaking "warning" diagnostic; but "union vs. class" is a hard error that c=
an't be worked around AFAIK.</div><div>I think what tmlen is asking for is =
for the Standard to bless both constructs so that compilers (whether MS or =
otherwise) have no excuse to reject them. I'd certainly like to see that, m=
yself.<br><div><br></div><div>=E2=80=93Arthur</div><div><br></div><div><p s=
tyle=3D"font-size: 11px; font-family: Menlo;">$ clang++ x.cc -std=3Dc++11 -=
Wall -W</p>
<p style=3D"font-size: 11px; font-family: Menlo;"><b>x.cc:3:1: </b><span st=
yle=3D"color: #d53bd3"><b>warning: </b></span><b>'T' defined as a struct he=
re but previously declared as a class [-Wmismatched-tags]</b></p>
<p style=3D"font-size: 11px; font-family: Menlo;">struct T { };</p>
<p style=3D"font-size: 11px; font-family: Menlo; color: rgb(52, 189, 38);">=
<b>^</b></p>
<p style=3D"font-size: 11px; font-family: Menlo;"><b>x.cc:1:1: note: </b>di=
d you mean struct here?</p>
<p style=3D"font-size: 11px; font-family: Menlo;">class T;</p>
<p style=3D"font-size: 11px; font-family: Menlo; color: rgb(52, 189, 38);">=
<b>^~~~~</b></p>
<p style=3D"font-size: 11px; font-family: Menlo; color: rgb(52, 189, 38);">=
struct</p>
<p style=3D"font-size: 11px; font-family: Menlo;">1 warning generated.</p><=
p style=3D"font-size: 11px; font-family: Menlo;"><br></p><p style=3D"font-s=
ize: 11px; font-family: Menlo;"><b>x.cc:3:1: </b><span style=3D"color: #c33=
720"><b>error: </b></span><b>use of 'U' with tag type that does not match p=
revious declaration</b></p>
<p style=3D"font-size: 11px; font-family: Menlo;">union U { };</p>
<p style=3D"font-size: 11px; font-family: Menlo; color: rgb(52, 189, 38);">=
<b>^~~~~</b></p>
<p style=3D"font-size: 11px; font-family: Menlo; color: rgb(52, 189, 38);">=
class</p>
<p style=3D"font-size: 11px; font-family: Menlo;"><b>x.cc:1:7: note: </b>pr=
evious use is here</p>
<p style=3D"font-size: 11px; font-family: Menlo;">class U;</p>
<p style=3D"font-size: 11px; font-family: Menlo; color: rgb(52, 189, 38);">=
<b>&nbsp; &nbsp; &nbsp; ^</b></p>
<p style=3D"font-size: 11px; font-family: Menlo;">1 error generated.</p><p =
style=3D"font-size: 11px; font-family: Menlo;"><br></p>On Friday, June 26, =
2015 at 6:37:14 AM UTC-7, Ville Voutilainen wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">On 26 June 2015 at 16:31, tmlen &lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"aHBdCkYtDJoJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.=
href=3D'javascript:';return true;">timle...@gmail.com</a>&gt; wrote:
<br>&gt; Currently only classes can be forward-declared like
<br>&gt;
<br>&gt; class A;
<br>&gt;
<br>&gt; If the class is defined using struct instead, it also has to be fo=
rward
<br>&gt; declared like
<br>&gt; struct A;
<br>
<br>That's not correct. I'm aware of certain implementations *cough*msvc*co=
ugh*
<br>that treat that incorrectly, but you can certainly forward-declare
<br>with either keyword
<br>regardless of which keyword is used in the definition.
<br>
<br>For the rest of it, this has been discussed before:
<br><a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/9=
hXHc6AS9M8/Zf7jN3K5Hz8J" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'https://groups.google.com/a/isocpp.org/d/msg/std-proposals/9hX=
Hc6AS9M8/Zf7jN3K5Hz8J';return true;" onclick=3D"this.href=3D'https://groups=
..google.com/a/isocpp.org/d/msg/std-proposals/9hXHc6AS9M8/Zf7jN3K5Hz8J';retu=
rn true;">https://groups.google.com/a/<wbr>isocpp.org/d/msg/std-<wbr>propos=
als/9hXHc6AS9M8/<wbr>Zf7jN3K5Hz8J</a>
<br></blockquote></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_70_1876659580.1435364962792--
------=_Part_69_1660396214.1435364962792--

.

--Apple-Mail=_3F2D57D4-6609-475C-857E-057709853494
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9306=E2=80=9327, at 8:29 AM, Arthur O'Dwyer <arthur.j.odwye=
r@gmail.com> wrote:
>=20
> For the record, MSVC isn't the only offender; Clang can't deal with misma=
tched tags either.
> "struct vs. class" is merely a build-breaking "warning" diagnostic; but "=
union vs. class" is a hard error that can't be worked around AFAIK.

I can=E2=80=99t find a standard reference to say this is allowed or not at =
the moment, but std::is_class and std::is_union appear to be guaranteed to =
work with incomplete types, so forward declaring a class as a union would b=
reak traits.

Either I missed something just now (likely) or there=E2=80=99s a defect. Wh=
y would such a forward declaration ever happen anyway?

--=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/.

--Apple-Mail=_3F2D57D4-6609-475C-857E-057709853494
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9327, at 8:29 AM, Arthur O'Dwyer &lt;<a href=3D"mailto:arthur.j.odwy=
er@gmail.com" class=3D"">arthur.j.odwyer@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=
=3D"">For the record, MSVC isn't the only offender; Clang can't deal with m=
ismatched tags either.<div class=3D"">"struct vs. class" is merely a build-=
breaking "warning" diagnostic; but "union vs. class" is a hard error that c=
an't be worked around AFAIK.</div></div></div></blockquote><div><br class=
=3D""></div><div>I can=E2=80=99t find a standard reference to say this is a=
llowed or not at the moment, but <font face=3D"Courier" class=3D"">std::is_=
class</font> and <font face=3D"Courier" class=3D"">std::is_union</font> app=
ear to be guaranteed to work with incomplete types, so forward declaring a =
class as a union would break traits.</div><div><br class=3D""></div><div>Ei=
ther I missed something just now (likely) or there=E2=80=99s a defect. Why =
would such a forward declaration ever happen anyway?</div></div><br class=
=3D""></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 />

--Apple-Mail=_3F2D57D4-6609-475C-857E-057709853494--

.

On Friday 26 June 2015 17:29:22 Arthur O'Dwyer wrote:
> I think what tmlen is asking for is for the Standard to bless both
> constructs so that compilers (whether MS or otherwise) have no excuse to
> reject them. I'd certainly like to see that, myself.

That's an ABI issue.

It's far more likely to adapt the standard to reality and explicitly permit
what the compilers already do, plus disallow mixing of struct and class with a
diagnostic.
--
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 27 June 2015 at 07:54, David Krauss <potswa@mac.com> wrote:
>
> On 2015=E2=80=9306=E2=80=9327, at 8:29 AM, Arthur O'Dwyer <arthur.j.odwye=
r@gmail.com> wrote:
>
> For the record, MSVC isn't the only offender; Clang can't deal with
> mismatched tags either.
> "struct vs. class" is merely a build-breaking "warning" diagnostic; but
> "union vs. class" is a hard error that can't be worked around AFAIK.
>
>
> I can=E2=80=99t find a standard reference to say this is allowed or not a=
t the
> moment, but std::is_class and std::is_union appear to be guaranteed to wo=
rk

[dcl.type.elab]/3: "...and either the class
or struct class-key shall be used to refer to a class (Clause 9)
declared using the class or struct class-key."

--=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/.

.

On 27 June 2015 at 09:47, Thiago Macieira <thiago@macieira.org> wrote:
> On Friday 26 June 2015 17:29:22 Arthur O'Dwyer wrote:
>> I think what tmlen is asking for is for the Standard to bless both
>> constructs so that compilers (whether MS or otherwise) have no excuse to
>> reject them. I'd certainly like to see that, myself.
>
> That's an ABI issue.

A forward declaration has nothing to do with an ABI.

> It's far more likely to adapt the standard to reality and explicitly permit
> what the compilers already do, plus disallow mixing of struct and class with a
> diagnostic.


I don't think so.

--

---
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 Saturday 27 June 2015 11:20:06 Ville Voutilainen wrote:
> On 27 June 2015 at 09:47, Thiago Macieira <thiago@macieira.org> wrote:
> > On Friday 26 June 2015 17:29:22 Arthur O'Dwyer wrote:
> >> I think what tmlen is asking for is for the Standard to bless both
> >> constructs so that compilers (whether MS or otherwise) have no excuse to
> >> reject them. I'd certainly like to see that, myself.
> >
> > That's an ABI issue.
>
> A forward declaration has nothing to do with an ABI.

It does if structs and classes are mangled differently.

struct S;
void f(S *);

The above is mangled in MSVC as ?f@@YAXPUS@Z, but if you later do:

class S {};
void f(S *p) { delete p; }

then this function would be mangled as ?f@@YAXPVS@Z.

The difference is the "U" for structs and "V" for classes.

> > It's far more likely to adapt the standard to reality and explicitly
> > permit
> > what the compilers already do, plus disallow mixing of struct and class
> > with a diagnostic.
>
> I don't think so.

--
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 27 June 2015 at 23:44, Thiago Macieira <thiago@macieira.org> wrote:
> On Saturday 27 June 2015 11:20:06 Ville Voutilainen wrote:
>> On 27 June 2015 at 09:47, Thiago Macieira <thiago@macieira.org> wrote:
>> > On Friday 26 June 2015 17:29:22 Arthur O'Dwyer wrote:
>> >> I think what tmlen is asking for is for the Standard to bless both
>> >> constructs so that compilers (whether MS or otherwise) have no excuse to
>> >> reject them. I'd certainly like to see that, myself.
>> >
>> > That's an ABI issue.
>>
>> A forward declaration has nothing to do with an ABI.
>
> It does if structs and classes are mangled differently.

Ok, sorry, it's been a while since I had to deal with that issue and I
had blissfully
forgotten how bad it is.

>> > It's far more likely to adapt the standard to reality and explicitly
>> > permit
>> > what the compilers already do, plus disallow mixing of struct and class
>> > with a diagnostic.
>>
>> I don't think so.

I have always been convinced, and remain so, that mangling struct and
class differently
is utterly broken. I don't support changing the standard to support
that brokenness
at the cost of usability of forward declarations in reasonable implementations.

--

---
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/.

.

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

On Fri, Jun 26, 2015 at 5:29 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

> For the record, MSVC isn't the only offender; Clang can't deal with
> mismatched tags either.
> "struct vs. class" is merely a build-breaking "warning" diagnostic; but
> "union vs. class" is a hard error that can't be worked around AFAIK.
>

Right, Clang is following the rules of the standard. It rejects class/union
mismatch because that's ill-formed, and warns on class/struct mismatch
because it's non-portable (it doesn't work on the MS ABI, which Clang
supports).


> I think what tmlen is asking for is for the Standard to bless both
> constructs so that compilers (whether MS or otherwise) have no excuse to
> reject them. I'd certainly like to see that, myself.
>

Such a proposal would need to be accompanied by an explanation of how to
make it work with existing name-matching linker technology, or an
explanation of why the feature is so valuable that it would be reasonable
to require new linker technology to link C++ code (other C++ features have
required this, but it's a very high bar). Without that, I expect you'll
find a lot of opposition.

=E2=80=93Arthur
>
> $ clang++ x.cc -std=3Dc++11 -Wall -W
>
> *x.cc:3:1: **warning: **'T' defined as a struct here but previously
> declared as a class [-Wmismatched-tags]*
>
> struct T { };
>
> *^*
>
> *x.cc:1:1: note: *did you mean struct here?
>
> class T;
>
> *^~~~~*
>
> struct
>
> 1 warning generated.
>
>
> *x.cc:3:1: **error: **use of 'U' with tag type that does not match
> previous declaration*
>
> union U { };
>
> *^~~~~*
>
> class
>
> *x.cc:1:7: note: *previous use is here
>
> class U;
>
> *      ^*
>
> 1 error generated.
>
>
> On Friday, June 26, 2015 at 6:37:14 AM UTC-7, Ville Voutilainen wrote:
>
>> On 26 June 2015 at 16:31, tmlen <timle...@gmail.com> wrote:
>> > Currently only classes can be forward-declared like
>> >
>> > class A;
>> >
>> > If the class is defined using struct instead, it also has to be forwar=
d
>> > declared like
>> > struct A;
>>
>> That's not correct. I'm aware of certain implementations
>> *cough*msvc*cough*
>> that treat that incorrectly, but you can certainly forward-declare
>> with either keyword
>> regardless of which keyword is used in the definition.
>>
>> For the rest of it, this has been discussed before:
>>
>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/9hXHc6AS9M8/Z=
f7jN3K5Hz8J
>>
>  --
>
> ---
> 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/.
>

--=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/.

--089e0118377abcff1c05198dcc93
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 F=
ri, Jun 26, 2015 at 5:29 PM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@g=
mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">For the record, MSVC isn&#39;t the only offender; Clang can&#39;t =
deal with mismatched tags either.<div>&quot;struct vs. class&quot; is merel=
y a build-breaking &quot;warning&quot; diagnostic; but &quot;union vs. clas=
s&quot; is a hard error that can&#39;t be worked around AFAIK.</div></div><=
/blockquote><div><br></div><div>Right, Clang is following the rules of the =
standard. It rejects class/union mismatch because that&#39;s ill-formed, an=
d warns on class/struct mismatch because it&#39;s non-portable (it doesn&#3=
9;t work on the MS ABI, which Clang supports).</div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div>I think what tmlen is asking=
 for is for the Standard to bless both constructs so that compilers (whethe=
r MS or otherwise) have no excuse to reject them. I&#39;d certainly like to=
 see that, myself.</div></div></blockquote><div><br></div><div>Such a propo=
sal would need to be accompanied by an explanation of how to make it work w=
ith existing name-matching linker technology, or an explanation of why the =
feature is so valuable that it would be reasonable to require new linker te=
chnology to link C++ code (other C++ features have required this, but it&#3=
9;s a very high bar). Without that, I expect you&#39;ll find a lot of oppos=
ition.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div><div>=E2=80=93Arthur</div><div><br></div><div><p style=3D"font-size:11=
px;font-family:Menlo">$ clang++ x.cc -std=3Dc++11 -Wall -W</p>
<p style=3D"font-size:11px;font-family:Menlo"><b>x.cc:3:1: </b><span style=
=3D"color:#d53bd3"><b>warning: </b></span><b>&#39;T&#39; defined as a struc=
t here but previously declared as a class [-Wmismatched-tags]</b></p>
<p style=3D"font-size:11px;font-family:Menlo">struct T { };</p>
<p style=3D"font-size:11px;font-family:Menlo;color:rgb(52,189,38)"><b>^</b>=
</p>
<p style=3D"font-size:11px;font-family:Menlo"><b>x.cc:1:1: note: </b>did yo=
u mean struct here?</p>
<p style=3D"font-size:11px;font-family:Menlo">class T;</p>
<p style=3D"font-size:11px;font-family:Menlo;color:rgb(52,189,38)"><b>^~~~~=
</b></p>
<p style=3D"font-size:11px;font-family:Menlo;color:rgb(52,189,38)">struct</=
p>
<p style=3D"font-size:11px;font-family:Menlo">1 warning generated.</p><p st=
yle=3D"font-size:11px;font-family:Menlo"><br></p><p style=3D"font-size:11px=
;font-family:Menlo"><b>x.cc:3:1: </b><span style=3D"color:#c33720"><b>error=
: </b></span><b>use of &#39;U&#39; with tag type that does not match previo=
us declaration</b></p>
<p style=3D"font-size:11px;font-family:Menlo">union U { };</p>
<p style=3D"font-size:11px;font-family:Menlo;color:rgb(52,189,38)"><b>^~~~~=
</b></p>
<p style=3D"font-size:11px;font-family:Menlo;color:rgb(52,189,38)">class</p=
>
<p style=3D"font-size:11px;font-family:Menlo"><b>x.cc:1:7: note: </b>previo=
us use is here</p>
<p style=3D"font-size:11px;font-family:Menlo">class U;</p>
<p style=3D"font-size:11px;font-family:Menlo;color:rgb(52,189,38)"><b>=C2=
=A0 =C2=A0 =C2=A0 ^</b></p>
<p style=3D"font-size:11px;font-family:Menlo">1 error generated.</p><p styl=
e=3D"font-size:11px;font-family:Menlo"><br></p>On Friday, June 26, 2015 at =
6:37:14 AM UTC-7, Ville Voutilainen wrote:<div><div class=3D"h5"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex">On 26 June 2015 at 16:31, tmlen &lt;<a rel=3D=
"nofollow">timle...@gmail.com</a>&gt; wrote:
<br>&gt; Currently only classes can be forward-declared like
<br>&gt;
<br>&gt; class A;
<br>&gt;
<br>&gt; If the class is defined using struct instead, it also has to be fo=
rward
<br>&gt; declared like
<br>&gt; struct A;
<br>
<br>That&#39;s not correct. I&#39;m aware of certain implementations *cough=
*msvc*cough*
<br>that treat that incorrectly, but you can certainly forward-declare
<br>with either keyword
<br>regardless of which keyword is used in the definition.
<br>
<br>For the rest of it, this has been discussed before:
<br><a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/9=
hXHc6AS9M8/Zf7jN3K5Hz8J" rel=3D"nofollow" target=3D"_blank">https://groups.=
google.com/a/isocpp.org/d/msg/std-proposals/9hXHc6AS9M8/Zf7jN3K5Hz8J</a>
<br></blockquote></div></div></div></div></div><div class=3D"HOEnZb"><div c=
lass=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 />

--089e0118377abcff1c05198dcc93--

.

On Saturday 27 June 2015 23:58:50 Ville Voutilainen wrote:
> I have always been convinced, and remain so, that mangling struct and
> class differently
> is utterly broken. I don't support changing the standard to support
> that brokenness
> at the cost of usability of forward declarations in reasonable
> implementations.

I understand your position, but I just disagree.
--
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/.

.

--001a11c3c8428bb80d0519a57575
Content-Type: text/plain; charset=UTF-8

Anyone is free to disagree, but I am just curious as of why. The language
considers 'struct' and 'class' to be equivalent except for the default
access specifiers.  Why would you want to mangle both differently? If these
two are exactly equivalent in the language:

class T { public: /*body*/ };
struct T { /*body*/ };

Why would you want the generated code to differ at all?

   David

On Sun, Jun 28, 2015 at 5:41 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Saturday 27 June 2015 23:58:50 Ville Voutilainen wrote:
> > I have always been convinced, and remain so, that mangling struct and
> > class differently
> > is utterly broken. I don't support changing the standard to support
> > that brokenness
> > at the cost of usability of forward declarations in reasonable
> > implementations.
>
> I understand your position, but I just disagree.
> --
> 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/.
>

--

---
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/.

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

<div dir=3D"ltr">Anyone is free to disagree, but I am just curious as of wh=
y. The language considers &#39;struct&#39; and &#39;class&#39; to be equiva=
lent except for the default access specifiers.=C2=A0 Why would you want to =
mangle both differently? If these two are exactly equivalent in the languag=
e:<br><br>class T { public: /*body*/ };<br>struct T { /*body*/ };<br><br>Wh=
y would you want the generated code to differ at all?<br><br>=C2=A0 =C2=A0D=
avid</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun,=
 Jun 28, 2015 at 5:41 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"=
mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Saturday=
 27 June 2015 23:58:50 Ville Voutilainen wrote:<br>
&gt; I have always been convinced, and remain so, that mangling struct and<=
br>
&gt; class differently<br>
&gt; is utterly broken. I don&#39;t support changing the standard to suppor=
t<br>
&gt; that brokenness<br>
&gt; at the cost of usability of forward declarations in reasonable<br>
&gt; implementations.<br>
<br>
</span>I understand your position, but I just disagree.<br>
<span class=3D"im HOEnZb">--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
<br>
</span><div class=3D"HOEnZb"><div class=3D"h5">--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><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 />

--001a11c3c8428bb80d0519a57575--

.

On Monday 29 June 2015 11:21:55 David Rodr=C3=ADguez Ibeas wrote:
> Anyone is free to disagree, but I am just curious as of why. The language
> considers 'struct' and 'class' to be equivalent except for the default
> access specifiers.  Why would you want to mangle both differently? If the=
se
> two are exactly equivalent in the language:
>=20
> class T { public: /*body*/ };
> struct T { /*body*/ };
>=20
> Why would you want the generated code to differ at all?
>=20
>    David

I personally wouldn't. In a blue sky scenario, I wouldn't mangle them=20
differently. I wouldn't even have added a different keyword if it is the sa=
me=20
thing.

But that's not the point. The point is that at least one compiler does mang=
le=20
them differently, has done so for 20 years, and considers class T and struc=
t T=20
to be different types, no more allowed to exist in the same context than cl=
ass=20
T and union T. Given that there are two different keywords and that at leas=
t=20
one compiler treats them differently, I would solve this problem by choosin=
g to=20
standardise current practice.

"if a given aggregate type T is declared with an aggregate tag and later re=
-
declared with a different tag, the program is ill-formed."

--=20
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

--=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/.

.

--001a11c37f7e9138a80519aab68b
Content-Type: text/plain; charset=UTF-8

On 29 June 2015 at 08:55, Thiago Macieira <thiago@macieira.org> wrote:

> The point is that at least one compiler does mangle
> them differently, has done so for 20 years, and considers class T and
> struct T
> to be different types, no more allowed to exist in the same context than
> class
> T and union T. Given that there are two different keywords and that at
> least
> one compiler treats them differently, I would solve this problem by
> choosing to
> standardise current practice.
>

So we should ignore the existing practice of other compilers in favor of
this one?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">On 29 June 2015 at 08:55, Thiag=
o Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" tar=
get=3D"_blank">thiago@macieira.org</a>&gt;</span> wrote:<br><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div id=3D":11n" class=3D"a3s" s=
tyle=3D"overflow:hidden">The point is that at least one compiler does mangl=
e<br>
them differently, has done so for 20 years, and considers class T and struc=
t T<br>
to be different types, no more allowed to exist in the same context than cl=
ass<br>
T and union T. Given that there are two different keywords and that at leas=
t<br>
one compiler treats them differently, I would solve this problem by choosin=
g to<br>
standardise current practice.</div></blockquote></div><br>So we should igno=
re the existing practice of other compilers in favor of this one?<br>-- <br=
><div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt=
;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@e=
viloverlord.com</a>&gt;=C2=A0 (847) 691-1404</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 />

--001a11c37f7e9138a80519aab68b--

.

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

On 29 June 2015 at 17:55, Thiago Macieira <thiago@macieira.org> wrote:

> But that's not the point. The point is that at least one compiler does
> mangle
> them differently, has done so for 20 years, and considers class T and
> struct T
> to be different types, no more allowed to exist in the same context than
> class
> T and union T. Given that there are two different keywords and that at
> least
> one compiler treats them differently, I would solve this problem by
> choosing to
> standardise current practice.
>

I don't think it's a reasonable way to reason unless you know why that
particular implementation
does it differently and the cause is general enough for this interpretation
to be useful for the user.
If it's only a specific implementation problem, it should not be
standardized.

--

---
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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 29 June 2015 at 17:55, Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"=
mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div id=3D":2ur" class=3D"a3=
s" style=3D"overflow:hidden">But that&#39;s not the point. The point is tha=
t at least one compiler does mangle<br>
them differently, has done so for 20 years, and considers class T and struc=
t T<br>
to be different types, no more allowed to exist in the same context than cl=
ass<br>
T and union T. Given that there are two different keywords and that at leas=
t<br>
one compiler treats them differently, I would solve this problem by choosin=
g to<br>
standardise current practice.</div></blockquote></div><br>I don&#39;t think=
 it&#39;s a reasonable way to reason unless you know why that particular im=
plementation</div><div class=3D"gmail_extra">does it differently and the ca=
use is general enough for this interpretation to be useful for the user.</d=
iv><div class=3D"gmail_extra">If it&#39;s only a specific implementation pr=
oblem, it should not be standardized.</div><div class=3D"gmail_extra">=C2=
=A0</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 />

--089e01419e66d350ac0519abda56--

.

--001a113569e26e072c0519abf82c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

mangling doesn't seem to be a major concern; since forward declaration is
 a hint to the compiler that the identifier is to be defined later, the
forward declaration has already been seen at the definition sight. So if
the compiler is supposed to mangle a universally forward declared type
differently from other type declarations, mangled name is already at hand
in the definition sight. And the linker is not going to be modified, since
all the above is compilers task.

regards,
FM.

2015-06-29 20:25 GMT+04:30 Thiago Macieira <thiago@macieira.org>:

> On Monday 29 June 2015 11:21:55 David Rodr=C3=ADguez Ibeas wrote:
> > Anyone is free to disagree, but I am just curious as of why. The langua=
ge
> > considers 'struct' and 'class' to be equivalent except for the default
> > access specifiers.  Why would you want to mangle both differently? If
> these
> > two are exactly equivalent in the language:
> >
> > class T { public: /*body*/ };
> > struct T { /*body*/ };
> >
> > Why would you want the generated code to differ at all?
> >
> >    David
>
> I personally wouldn't. In a blue sky scenario, I wouldn't mangle them
> differently. I wouldn't even have added a different keyword if it is the
> same
> thing.
>
> But that's not the point. The point is that at least one compiler does
> mangle
> them differently, has done so for 20 years, and considers class T and
> struct T
> to be different types, no more allowed to exist in the same context than
> class
> T and union T. Given that there are two different keywords and that at
> least
> one compiler treats them differently, I would solve this problem by
> choosing to
> standardise current practice.
>
> "if a given aggregate type T is declared with an aggregate tag and later
> re-
> declared with a different tag, the program is ill-formed."
>
> --
> 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/.
>



--=20
how am I supposed to end the twisted road of  your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!

--=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/.

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

<div dir=3D"rtl"><div class=3D"gmail_default" style=3D"font-family:&#39;ari=
al narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">mangling doesn&#39;t=
 seem to be a major concern; since forward declaration is =C2=A0a hint to t=
he compiler that the identifier is to be defined later, the forward declara=
tion has already been seen at the definition sight. So if the compiler is s=
upposed to mangle a universally forward declared type differently from othe=
r type declarations, mangled name is already at hand in the definition sigh=
t. And the linker is not going to be modified, since all the above is compi=
lers task.</div><div class=3D"gmail_default" style=3D"font-family:&#39;aria=
l narrow&#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div><div class=
=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;f=
ont-size:large" dir=3D"ltr">regards,</div><div class=3D"gmail_default" styl=
e=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"=
ltr">FM.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr">2015-06-29 20:25 GMT+04:30 Thiago Macieira <span dir=3D=
"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@m=
acieira.org</a>&gt;</span>:</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">On Monday 29 June 2015 11:21:55 David Rodr=C3=ADguez Ibeas wrote:<br>
&gt; Anyone is free to disagree, but I am just curious as of why. The langu=
age<br>
&gt; considers &#39;struct&#39; and &#39;class&#39; to be equivalent except=
 for the default<br>
&gt; access specifiers.=C2=A0 Why would you want to mangle both differently=
? If these<br>
&gt; two are exactly equivalent in the language:<br>
&gt;<br>
&gt; class T { public: /*body*/ };<br>
&gt; struct T { /*body*/ };<br>
&gt;<br>
&gt; Why would you want the generated code to differ at all?<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 David<br>
<br>
</span>I personally wouldn&#39;t. In a blue sky scenario, I wouldn&#39;t ma=
ngle them<br>
differently. I wouldn&#39;t even have added a different keyword if it is th=
e same<br>
thing.<br>
<br>
But that&#39;s not the point. The point is that at least one compiler does =
mangle<br>
them differently, has done so for 20 years, and considers class T and struc=
t T<br>
to be different types, no more allowed to exist in the same context than cl=
ass<br>
T and union T. Given that there are two different keywords and that at leas=
t<br>
one compiler treats them differently, I would solve this problem by choosin=
g to<br>
standardise current practice.<br>
<br>
&quot;if a given aggregate type T is declared with an aggregate tag and lat=
er re-<br>
declared with a different tag, the program is ill-formed.&quot;<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
<br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"rtl"><div><div dir=3D"ltr">how a=
m I supposed to end the twisted road of=C2=A0 your hair in such a dark nigh=
t??<br>unless the candle of your face does shed some light upon my way!!!<b=
r></div></div></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 />

--001a113569e26e072c0519abf82c--

.

On Monday 29 June 2015 19:59:44 Klaim - Jo=C3=ABl Lamotte wrote:
> On 29 June 2015 at 17:55, Thiago Macieira <thiago@macieira.org> wrote:
> > But that's not the point. The point is that at least one compiler does
> > mangle
> > them differently, has done so for 20 years, and considers class T and
> > struct T
> > to be different types, no more allowed to exist in the same context tha=
n
> > class
> > T and union T. Given that there are two different keywords and that at
> > least
> > one compiler treats them differently, I would solve this problem by
> > choosing to
> > standardise current practice.
>=20
> I don't think it's a reasonable way to reason unless you know why that
> particular implementation
> does it differently and the cause is general enough for this interpretati=
on
> to be useful for the user.
> If it's only a specific implementation problem, it should not be
> standardized.

I can only guess, since I'm not privy to the details.

I have two guesses:

1) This decision was implemented prior to C++98 being standardised and at t=
he=20
time there was no decision one way or the other. It probably wasn't until m=
uch=20
later after standard came about that someone realised the inconsistency.

2) It was implemented so that the linker could give as much information as=
=20
possible when an undefined or redefined symbol happened.

I'm guessing it's a combination of the two. And yet what's important is the=
 20=20
years of practice.

Now, this particular compiler is the only one known to break BC at every=20
release, so it wouldn't be difficult to fix it.

--=20
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

--=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/.

.

On Monday 29 June 2015 22:37:22 Farid Mehrabi wrote:
> mangling doesn't seem to be a major concern; since forward declaration is
>  a hint to the compiler that the identifier is to be defined later, the
> forward declaration has already been seen at the definition sight. So if
> the compiler is supposed to mangle a universally forward declared type
> differently from other type declarations, mangled name is already at hand
> in the definition sight. And the linker is not going to be modified, since
> all the above is compilers task.

So you'd require the universal declaration to always exist?

That is, the code:

===
typename A;
class A : public Base {};
===

Is not the same as
===
class A : public Base {};
===

--
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/.

.

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

No, Thiago has a very valid point: there is ABI breakage here for MSVC.
As I understand it, if a user on a Windows platform writes

    class LibraryCat;
    void userland(LibraryCat *);
    int main() {
        userland(nullptr);  // CALL ?userland@@YAXPEAVLibraryCat@@@Z
    }

whereas if he writes

    struct LibraryCat;
    void userland(LibraryCat *);
    int main() {
        userland(nullptr);  // CALL ?userland@@YAXPEAULibraryCat@@@Z
    }

Now, the binary LIBRARY.DLL will have one or the other of these symbols
defined; but not both. That means that one of the above translations
units *will
compile, but fail to link*.

The compiler could just quietly start treating `class` and `struct` the
same (mangling them both with `YAXPEAU` instead of `YAXPEAV`, or vice
versa, but then that will cause LIBRARY.DLL to break no matter *what* the
user types in his own translation unit!  So that's also bad.

One path forward for MSVC (other than just breaking ABI compatibility
completely, which would be awesome but politically infeasible I'm sure)
would be to go through a transitionary period where every mangled label in
the .obj file (i.e. every *callee*) is emitted with two different spellings
at the same byte-offset:

    ?userland@@YAXPEAULibraryCat@@@Z:
    ?userland@@YAXPEAVLibraryCat@@@Z:
        # code goes here
        RET

Then, wait long enough for LIBRARY.DLL to get recompiled with this
transitionary compiler; and then you can start using the new ABI for the
callers as well.

my $.02,
=E2=80=93Arthur



On Mon, Jun 29, 2015 at 11:07 AM, Farid Mehrabi <farid.mehrabi@gmail.com>
wrote:

> mangling doesn't seem to be a major concern; since forward declaration is
>  a hint to the compiler that the identifier is to be defined later, the
> forward declaration has already been seen at the definition sight. So if
> the compiler is supposed to mangle a universally forward declared type
> differently from other type declarations, mangled name is already at hand
> in the definition sight. And the linker is not going to be modified, sinc=
e
> all the above is compilers task.
>
> regards,
> FM.
>
> 2015-06-29 20:25 GMT+04:30 Thiago Macieira <thiago@macieira.org>:
>
>> On Monday 29 June 2015 11:21:55 David Rodr=C3=ADguez Ibeas wrote:
>> > Anyone is free to disagree, but I am just curious as of why. The
>> language
>> > considers 'struct' and 'class' to be equivalent except for the default
>> > access specifiers.  Why would you want to mangle both differently? If
>> these
>> > two are exactly equivalent in the language:
>> >
>> > class T { public: /*body*/ };
>> > struct T { /*body*/ };
>> >
>> > Why would you want the generated code to differ at all?
>> >
>> >    David
>>
>> I personally wouldn't. In a blue sky scenario, I wouldn't mangle them
>> differently. I wouldn't even have added a different keyword if it is the
>> same
>> thing.
>>
>> But that's not the point. The point is that at least one compiler does
>> mangle
>> them differently, has done so for 20 years, and considers class T and
>> struct T
>> to be different types, no more allowed to exist in the same context than
>> class
>> T and union T. Given that there are two different keywords and that at
>> least
>> one compiler treats them differently, I would solve this problem by
>> choosing to
>> standardise current practice.
>>
>> "if a given aggregate type T is declared with an aggregate tag and later
>> re-
>> declared with a different tag, the program is ill-formed."
>>
>> --
>> 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 Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>>
>
>
>
> --
> how am I supposed to end the twisted road of  your hair in such a dark
> night??
> unless the candle of your face does shed some light upon my way!!!
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/fm-ThgXXjF4/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/.
>

--=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/.

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

<div dir=3D"ltr">No, Thiago has a very valid point: there is ABI breakage h=
ere for MSVC.<div>As I understand it, if a user on a Windows platform write=
s<div><br></div><div>=C2=A0 =C2=A0 class LibraryCat;</div><div>=C2=A0 =C2=
=A0 void userland(LibraryCat *);</div><div>=C2=A0 =C2=A0 int main() {</div>=
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 userland(nullptr); =C2=A0// CALL ?userland=
@@YAXPEAVLibraryCat@@@Z</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div>=
whereas if he writes</div><div><br></div><div><div>=C2=A0 =C2=A0 struct Lib=
raryCat;</div><div>=C2=A0 =C2=A0 void userland(LibraryCat *);</div><div>=C2=
=A0 =C2=A0 int main() {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 userland(null=
ptr); =C2=A0// CALL ?userland@@YAXPEAULibraryCat@@@Z</div><div>=C2=A0 =C2=
=A0 }</div></div><div><br></div><div>Now, the binary LIBRARY.DLL will have =
one or the other of these symbols defined; but not both. That means that on=
e of the above translations units <i>will compile, but fail to link</i>.</d=
iv><div><br></div><div>The compiler could just quietly start treating `clas=
s` and `struct` the same (mangling them both with `YAXPEAU` instead of `YAX=
PEAV`, or vice versa, but then that will cause LIBRARY.DLL to break no matt=
er *what* the user types in his own translation unit!=C2=A0 So that&#39;s a=
lso bad.</div><div><br></div><div>One path forward for MSVC (other than jus=
t breaking ABI compatibility completely, which would be awesome but politic=
ally infeasible I&#39;m sure) would be to go through a transitionary period=
 where every mangled label in the .obj file (i.e. every <i>callee</i>) is e=
mitted with two different spellings at the same byte-offset:</div><div><br>=
</div><div><div>=C2=A0 =C2=A0 ?userland@@YAXPEAULibraryCat@@@Z:</div></div>=
<div><div>=C2=A0 =C2=A0 ?userland@@YAXPEAVLibraryCat@@@Z:</div></div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 # code goes here</div><div>=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 RET</div><div><br></div><div>Then, wait long enough for LIBRARY.DLL=
 to get recompiled with this transitionary compiler; and then you can start=
 using the new ABI for the callers as well.</div><div><br></div><div>my $.0=
2,</div><div>=E2=80=93Arthur</div><div><br></div><div><br></div></div></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jun 29, =
2015 at 11:07 AM, Farid Mehrabi <span dir=3D"ltr">&lt;<a href=3D"mailto:far=
id.mehrabi@gmail.com" target=3D"_blank">farid.mehrabi@gmail.com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"rtl"><div class=3D=
"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font=
-size:large" dir=3D"ltr">mangling doesn&#39;t seem to be a major concern; s=
ince forward declaration is =C2=A0a hint to the compiler that the identifie=
r is to be defined later, the forward declaration has already been seen at =
the definition sight. So if the compiler is supposed to mangle a universall=
y forward declared type differently from other type declarations, mangled n=
ame is already at hand in the definition sight. And the linker is not going=
 to be modified, since all the above is compilers task.</div><div class=3D"=
gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-=
size:large" dir=3D"ltr"><br></div><div class=3D"gmail_default" style=3D"fon=
t-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">reg=
ards,</div><div class=3D"gmail_default" style=3D"font-family:&#39;arial nar=
row&#39;,sans-serif;font-size:large" dir=3D"ltr">FM.</div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote"><div dir=3D"ltr">2015-06-29=
 20:25 GMT+04:30 Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:th=
iago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;</span>:</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><span>On Monday 29 June 2015 11:21:55 Dav=
id Rodr=C3=ADguez Ibeas wrote:<br>
&gt; Anyone is free to disagree, but I am just curious as of why. The langu=
age<br>
&gt; considers &#39;struct&#39; and &#39;class&#39; to be equivalent except=
 for the default<br>
&gt; access specifiers.=C2=A0 Why would you want to mangle both differently=
? If these<br>
&gt; two are exactly equivalent in the language:<br>
&gt;<br>
&gt; class T { public: /*body*/ };<br>
&gt; struct T { /*body*/ };<br>
&gt;<br>
&gt; Why would you want the generated code to differ at all?<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 David<br>
<br>
</span>I personally wouldn&#39;t. In a blue sky scenario, I wouldn&#39;t ma=
ngle them<br>
differently. I wouldn&#39;t even have added a different keyword if it is th=
e same<br>
thing.<span class=3D""><br>
<br>
But that&#39;s not the point. The point is that at least one compiler does =
mangle<br>
them differently, has done so for 20 years, and considers class T and struc=
t T<br>
to be different types, no more allowed to exist in the same context than cl=
ass<br>
T and union T. Given that there are two different keywords and that at leas=
t<br>
one compiler treats them differently, I would solve this problem by choosin=
g to<br>
standardise current practice.<br>
<br></span>
&quot;if a given aggregate type T is declared with an aggregate tag and lat=
er re-<br>
declared with a different tag, the program is ill-formed.&quot;<br>
<div><div><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
<br>
--<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<span class=3D""><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/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</span></div></div></blockquote></div><span class=3D"HOEnZb"><font color=3D=
"#888888"><br><br clear=3D"all"><div><br></div>-- <br><div><div dir=3D"rtl"=
><div><div dir=3D"ltr">how am I supposed to end the twisted road of=C2=A0 y=
our hair in such a dark night??<br>unless the candle of your face does shed=
 some light upon my way!!!<br></div></div></div></div>
</font></span></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/fm-ThgXXjF4/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/fm-ThgXXjF4=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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>

<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 />

--f46d044287e275cb2a0519af050d--

.

--001a11c2664cba7ceb0519afae75
Content-Type: text/plain; charset=UTF-8

On 29 June 2015 at 20:31, Thiago Macieira <thiago@macieira.org> wrote:

> I'm guessing it's a combination of the two. And yet what's important is
> the 20
> years of practice.
>
>
Actually, it's more like years of surprising behaviour of this
implementation (for this particular issue at least) for me as a user
hitting this problem.
I even
reported this issue once believing it was the compiler which was wrong.

I don't see how having one implementation interpretating this case
differently from the rest of the implementations would justify making it
standard practice.
I could point to any other implementation not doing it that way and give
the same argument than you but without standardizing



> Now, this particular compiler is the only one known to break BC at every
> release, so it wouldn't be difficult to fix it.
>

As you pointed before, we don't know about that here.

--

---
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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 29 June 2015 at 20:31, Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"=
mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div id=3D":2y9" class=3D"a3=
s" style=3D"overflow:hidden">I&#39;m guessing it&#39;s a combination of the=
 two. And yet what&#39;s important is the 20<br>
years of practice.<br>
<br></div></blockquote><div><br></div><div>Actually, it&#39;s more like yea=
rs of surprising behaviour of this implementation (for this particular issu=
e at least) for me as a user hitting this problem.</div><div>I even</div><d=
iv>reported this issue once believing it was the compiler which was wrong.<=
/div><div><br></div><div>I don&#39;t see how having one implementation inte=
rpretating this case</div><div>differently from the rest of the implementat=
ions would justify making it standard practice.</div><div>I could point to =
any other implementation not doing it that way and give</div><div>the same =
argument than you but without standardizing=C2=A0</div><div><br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div id=3D":2y9" class=3D"a3s" s=
tyle=3D"overflow:hidden">
Now, this particular compiler is the only one known to break BC at every<br=
>
release, so it wouldn&#39;t be difficult to fix it.</div></blockquote></div=
><br></div><div class=3D"gmail_extra">As you pointed before, we don&#39;t k=
now about that here.</div><div class=3D"gmail_extra"><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 />

--001a11c2664cba7ceb0519afae75--

.

On Tuesday 30 June 2015 00:33:44 Klaim - Jo=C3=ABl Lamotte wrote:
> On 29 June 2015 at 20:31, Thiago Macieira <thiago@macieira.org> wrote:
> > I'm guessing it's a combination of the two. And yet what's important is
> > the 20
> > years of practice.
>=20
> Actually, it's more like years of surprising behaviour of this
> implementation (for this particular issue at least) for me as a user
> hitting this problem.
> I even
> reported this issue once believing it was the compiler which was wrong.

It's no more surprising than discovering that struct and class are the same=
..=20
If there's a keyword, why should they be interchangeable?

Most newbies eventually wonder that and wonder what extra features class ha=
s=20
over struct.=20

> I don't see how having one implementation interpretating this case
> differently from the rest of the implementations would justify making it
> standard practice.

In the three most widely used implementations, we have three different=20
behaviours:

1) error
2) warning
3) accept

So two of the three direct people towards not mixing struct and class.

--=20
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

--=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/.

.

On Monday 29 June 2015 14:46:25 Arthur O'Dwyer wrote:
> The compiler could just quietly start treating `class` and `struct` the
> same (mangling them both with `YAXPEAU` instead of `YAXPEAV`, or vice
> versa, but then that will cause LIBRARY.DLL to break no matter *what* the
> user types in his own translation unit!  So that's also bad.

Note that template aliases are mangled in MSVC 2015 yet differently. They're
using the "Y" prefix instead of "U" and "V", which was previously assigned to
co-interfaces.

("X" is "void" and "W" is enum")
--
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_110_1062211984.1435627178820
Content-Type: multipart/alternative;
 boundary="----=_Part_111_565257577.1435627178820"

------=_Part_111_565257577.1435627178820
Content-Type: text/plain; charset=UTF-8

Is a compiler even required to use the same memory layout for classes and
structs if not constrained by other rules (e.g. standard-layout /
layout-compatible)?  Mixing the struct/class tags is well within the realm
of undefined behavior for multiple reasons.

I did check on anonymous classes, though.  I had expected that only
"struct" would be allowed for anonymous classes, but I was wrong: "class"
works.  GCC, clang, and MSVC all support anonymous classes as an extension,
and they basically implement the same rules as anonymous unions.  All
members must be public, for example.  You can use the tag "class" for
anonymous classes in all three compilers, but if there are any members, you
have to use the "public:" access-specifier to override the default private
access-specifier of "class".

On Monday, June 29, 2015 at 4:11:07 PM UTC-7, Thiago Macieira wrote:
>
> On Monday 29 June 2015 14:46:25 Arthur O'Dwyer wrote:
> > The compiler could just quietly start treating `class` and `struct` the
> > same (mangling them both with `YAXPEAU` instead of `YAXPEAV`, or vice
> > versa, but then that will cause LIBRARY.DLL to break no matter *what*
> the
> > user types in his own translation unit!  So that's also bad.
>
> Note that template aliases are mangled in MSVC 2015 yet differently.
> They're
> using the "Y" prefix instead of "U" and "V", which was previously assigned
> to
> co-interfaces.
>
> ("X" is "void" and "W" is enum")
> --
> 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_111_565257577.1435627178820
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Is a compiler even required to use the same memory layout =
for classes and structs if not constrained by other rules (e.g. standard-la=
yout / layout-compatible)?&nbsp; Mixing the struct/class tags is well withi=
n the realm of undefined behavior for multiple reasons.<br><br>I did check =
on anonymous classes, though.&nbsp; I had expected that only "struct" would=
 be allowed for anonymous classes, but I was wrong: "class" works.&nbsp; GC=
C, clang, and MSVC all support anonymous classes as an extension, and they =
basically implement the same rules as anonymous unions.&nbsp; All members m=
ust be public, for example.&nbsp; You can use the tag "class" for anonymous=
 classes in all three compilers, but if there are any members, you have to =
use the "public:" access-specifier to override the default private access-s=
pecifier of "class".<br><br>On Monday, June 29, 2015 at 4:11:07 PM UTC-7, T=
hiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday=
 29 June 2015 14:46:25 Arthur O'Dwyer wrote:
<br>&gt; The compiler could just quietly start treating `class` and `struct=
` the
<br>&gt; same (mangling them both with `YAXPEAU` instead of `YAXPEAV`, or v=
ice
<br>&gt; versa, but then that will cause LIBRARY.DLL to break no matter *wh=
at* the
<br>&gt; user types in his own translation unit! &nbsp;So that's also bad.
<br>
<br>Note that template aliases are mangled in MSVC 2015 yet differently. Th=
ey're=20
<br>using the "Y" prefix instead of "U" and "V", which was previously assig=
ned to=20
<br>co-interfaces.
<br>
<br>("X" is "void" and "W" is enum")
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
swDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - th=
iago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org=
\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde=
..org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';retur=
n true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<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_111_565257577.1435627178820--
------=_Part_110_1062211984.1435627178820--

.

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

On Mon, Jun 29, 2015 at 6:19 PM, Myriachan <myriachan@gmail.com> wrote:

> Is a compiler even required to use the same memory layout for classes and
> structs if not constrained by other rules (e.g. standard-layout /
> layout-compatible)?
>

No, but the tag keyword is not relevant to that question. A compiler is not
constrained to lay out two non-standard-layout classes the same even if
they have members of the same types in the same order.

Mixing the struct/class tags is well within the realm of undefined behavior
> for multiple reasons.
>

That doesn't follow from your preceding question: the layout depends on the
definition. Usage of 'struct' or 'class' within a non-defining declaration
can't affect the layout in a conforming one-TU-at-a-time implementation
(because the forward declaration may not be visible in all translation
units).

I did check on anonymous classes, though.  I had expected that only
> "struct" would be allowed for anonymous classes, but I was wrong: "class"
> works.  GCC, clang, and MSVC all support anonymous classes as an extension,
> and they basically implement the same rules as anonymous unions.  All
> members must be public, for example.  You can use the tag "class" for
> anonymous classes in all three compilers, but if there are any members, you
> have to use the "public:" access-specifier to override the default private
> access-specifier of "class".
>
>
> On Monday, June 29, 2015 at 4:11:07 PM UTC-7, Thiago Macieira wrote:
>>
>> On Monday 29 June 2015 14:46:25 Arthur O'Dwyer wrote:
>> > The compiler could just quietly start treating `class` and `struct` the
>> > same (mangling them both with `YAXPEAU` instead of `YAXPEAV`, or vice
>> > versa, but then that will cause LIBRARY.DLL to break no matter *what*
>> the
>> > user types in his own translation unit!  So that's also bad.
>>
>> Note that template aliases are mangled in MSVC 2015 yet differently.
>> They're
>> using the "Y" prefix instead of "U" and "V", which was previously
>> assigned to
>> co-interfaces.
>>
>> ("X" is "void" and "W" is enum")
>> --
>> 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/.
>

--

---
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/.

--bcaec5196aab434e440519b24d2f
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 M=
on, Jun 29, 2015 at 6:19 PM, Myriachan <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Is a compiler =
even required to use the same memory layout for classes and structs if not =
constrained by other rules (e.g. standard-layout / layout-compatible)?</div=
></blockquote><div><br></div><div>No, but the tag keyword is not relevant t=
o that question. A compiler is not constrained to lay out two non-standard-=
layout classes the same even if they have members of the same types in the =
same order.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr">Mixing the struct/class tags is well within the realm of undefined beh=
avior for multiple reasons.<br></div></blockquote><div><br></div><div>That =
doesn&#39;t follow from your preceding question: the layout depends on the =
definition. Usage of &#39;struct&#39; or &#39;class&#39; within a non-defin=
ing declaration can&#39;t affect the layout in a conforming one-TU-at-a-tim=
e implementation (because the forward declaration may not be visible in all=
 translation units).</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">I did check on anonymous classes, though.=C2=A0 I had expecte=
d that only &quot;struct&quot; would be allowed for anonymous classes, but =
I was wrong: &quot;class&quot; works.=C2=A0 GCC, clang, and MSVC all suppor=
t anonymous classes as an extension, and they basically implement the same =
rules as anonymous unions.=C2=A0 All members must be public, for example.=
=C2=A0 You can use the tag &quot;class&quot; for anonymous classes in all t=
hree compilers, but if there are any members, you have to use the &quot;pub=
lic:&quot; access-specifier to override the default private access-specifie=
r of &quot;class&quot;.<div><div class=3D"h5"><br><br>On Monday, June 29, 2=
015 at 4:11:07 PM UTC-7, Thiago Macieira wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex">On Monday 29 June 2015 14:46:25 Arthur O&#39;Dwyer wrote:
<br>&gt; The compiler could just quietly start treating `class` and `struct=
` the
<br>&gt; same (mangling them both with `YAXPEAU` instead of `YAXPEAV`, or v=
ice
<br>&gt; versa, but then that will cause LIBRARY.DLL to break no matter *wh=
at* the
<br>&gt; user types in his own translation unit!=C2=A0 So that&#39;s also b=
ad.
<br>
<br>Note that template aliases are mangled in MSVC 2015 yet differently. Th=
ey&#39;re=20
<br>using the &quot;Y&quot; prefix instead of &quot;U&quot; and &quot;V&quo=
t;, which was previously assigned to=20
<br>co-interfaces.
<br>
<br>(&quot;X&quot; is &quot;void&quot; and &quot;W&quot; is enum&quot;)
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http:=
//kde.org" rel=3D"nofollow" target=3D"_blank">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></div></div></div><div class=3D"HOEnZb"><div 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 />

--bcaec5196aab434e440519b24d2f--

.

--001a11345984bce4a70519b89c70
Content-Type: text/plain; charset=UTF-8

On Tue, Jun 30, 2015 at 12:09 AM, Thiago Macieira <thiago@macieira.org>
wrote:

> It's no more surprising than discovering that struct and class are the
> same.
> If there's a keyword, why should they be interchangeable?
>

struct is needed for C backwards compatibility, class is the default for
OO, where members default to private. You cannot make the default access
specifier in 'struct' private without breaking C compatiblity, you cannot
remove 'struct' without breaking C compatibility. The designer of the
language did not want to settle for public as the default access specifier.
That is how we ended with two keywords.


> Most newbies eventually wonder that and wonder what extra features class
> has
> over struct.


This is educational, most interviews I've been in ask precisely that, what
is the difference between 'class' and 'struct', and it is expected that
people know there aren't beyond the default access specifier.


> In the three most widely used implementations, we have three different
> behaviours:
>
> 1) error
> 2) warning
> 3) accept
>

VS is wrong in generating an error (is it still an error?), Clang is being
helpful as it also targets windows in telling you that the code might fail
to compile in a broken compiler. Gcc accepts the code as it is, as the
standard mandates.

If we are going to standardize the behavior of one compiler, we might want
to make these two signatures not equivalent, as Solaris CC mangles them
differently:

void f(int);
void f(const int);

We should also remove two phase lookup, since VS does not implement it
--this would open the question of whether two phase lookup should be
standardized in the next standard since both gcc does it (and clang, and
CC, and xlC)...

We should also let the compiler peek into a .cpp or .cc if the header
contains a template, since Solaris CC does that.

Coming back to a more serious stance, out of all the vendors I believe that
VS is the one that cares the least about breaking binary compatibility
between releases.  They just decided not to fix this particular issue in
the compiler. Standards are for implementations to follow, not the other
way around. A standard should  adapt to existing implementations if they
offer advantages, which I dont' think is the case here. There is no
technical advantage in mangling differently 'struct' and 'class'.

   David

--

---
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/.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Jun 30, 2015 at 12:09 AM, Thiago Macieira <span dir=3D"ltr">&lt=
;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.o=
rg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It&#39;s no more=
 surprising than discovering that struct and class are the same.<br>
If there&#39;s a keyword, why should they be interchangeable?<br></blockquo=
te><div><br></div><div>struct is needed for C backwards compatibility, clas=
s is the default for OO, where members default to private. You cannot make =
the default access specifier in &#39;struct&#39; private without breaking C=
 compatiblity, you cannot remove &#39;struct&#39; without breaking C compat=
ibility. The designer of the language did not want to settle for public as =
the default access specifier. That is how we ended with two keywords.</div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">Most newbies eventually won=
der that and wonder what extra features class has<br>
over struct.</blockquote><div><br>This is educational, most interviews I&#3=
9;ve been in ask precisely that, what is the difference between &#39;class&=
#39; and &#39;struct&#39;, and it is expected that people know there aren&#=
39;t beyond the default access specifier.=C2=A0</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">In the three most widely used implementations, we=
 have three different<br>
behaviours:<br>
<br>
1) error<br>
2) warning<br>
3) accept<br></blockquote><div><br>VS is wrong in generating an error (is i=
t still an error?), Clang is being helpful as it also targets windows in te=
lling you that the code might fail to compile in a broken compiler. Gcc acc=
epts the code as it is, as the standard mandates.<br><br>If we are going to=
 standardize the behavior of one compiler, we might want to make these two =
signatures not equivalent, as Solaris CC mangles them differently:<br><br>v=
oid f(int);<br>void f(const int);<br><br>We should also remove two phase lo=
okup, since VS does not implement it --this would open the question of whet=
her two phase lookup should be standardized in the next standard since both=
 gcc does it (and clang, and CC, and xlC)...<br><br>We should also let the =
compiler peek into a .cpp or .cc if the header contains a template, since S=
olaris CC does that.<br><br>Coming back to a more serious stance, out of al=
l the vendors I believe that VS is the one that cares the least about break=
ing binary compatibility between releases.=C2=A0 They just decided not to f=
ix this particular issue in the compiler. Standards are for implementations=
 to follow, not the other way around. A standard should =C2=A0adapt to exis=
ting implementations if they offer advantages, which I dont&#39; think is t=
he case here. There is no technical advantage in mangling differently &#39;=
struct&#39; and &#39;class&#39;.<br><br>=C2=A0 =C2=A0David</div></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 />

--001a11345984bce4a70519b89c70--

.

--047d7bdcab343ffb670519b8b6b5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Am 30.06.2015 01:09 schrieb "Thiago Macieira" <thiago@macieira.org>:
>
> On Tuesday 30 June 2015 00:33:44 Klaim - Jo=C3=ABl Lamotte wrote:
> > On 29 June 2015 at 20:31, Thiago Macieira <thiago@macieira.org> wrote:
> > > I'm guessing it's a combination of the two. And yet what's important
is
> > > the 20
> > > years of practice.
> >
> > Actually, it's more like years of surprising behaviour of this
> > implementation (for this particular issue at least) for me as a user
> > hitting this problem.
> > I even
> > reported this issue once believing it was the compiler which was wrong.
>
> It's no more surprising than discovering that struct and class are the
same.
> If there's a keyword, why should they be interchangeable?
>

This is not much different from having a toplevel const for a function
parameter type of a function declaration IMO. Up to this point, the const
doesn't make a difference, so "const int" and "int" are interchangable
there. Once you have the function body, in the body it makes a difference.

--=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/.

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

<p dir=3D"ltr"><br>
Am 30.06.2015 01:09 schrieb &quot;Thiago Macieira&quot; &lt;<a href=3D"mail=
to:thiago@macieira.org">thiago@macieira.org</a>&gt;:<br>
&gt;<br>
&gt; On Tuesday 30 June 2015 00:33:44 Klaim - Jo=C3=ABl Lamotte wrote:<br>
&gt; &gt; On 29 June 2015 at 20:31, Thiago Macieira &lt;<a href=3D"mailto:t=
hiago@macieira.org">thiago@macieira.org</a>&gt; wrote:<br>
&gt; &gt; &gt; I&#39;m guessing it&#39;s a combination of the two. And yet =
what&#39;s important is<br>
&gt; &gt; &gt; the 20<br>
&gt; &gt; &gt; years of practice.<br>
&gt; &gt;<br>
&gt; &gt; Actually, it&#39;s more like years of surprising behaviour of thi=
s<br>
&gt; &gt; implementation (for this particular issue at least) for me as a u=
ser<br>
&gt; &gt; hitting this problem.<br>
&gt; &gt; I even<br>
&gt; &gt; reported this issue once believing it was the compiler which was =
wrong.<br>
&gt;<br>
&gt; It&#39;s no more surprising than discovering that struct and class are=
 the same.<br>
&gt; If there&#39;s a keyword, why should they be interchangeable?<br>
&gt;</p>
<p dir=3D"ltr">This is not much different from having a toplevel const for =
a function parameter type of a function declaration IMO. Up to this point, =
the const doesn&#39;t make a difference, so &quot;const int&quot; and &quot=
;int&quot; are interchangable there. Once you have the function body, in th=
e body it makes a difference.</p>

<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 />

--047d7bdcab343ffb670519b8b6b5--

.

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

For the record:

C:\code\fwddecl

=CE=BB cat test.cpp

struct A;

class A {};

int main() {}



C:\code\fwddecl

=CE=BB cl test.cpp

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for
80x86
Copyright (C) Microsoft Corporation.  All rights reserved.



test.cpp

Microsoft (R) Incremental Linker Version 10.00.40219.01

Copyright (C) Microsoft Corporation.  All rights reserved.



/out:test.exe

test.obj

With /W4 you get the following warning:

test.cpp(2) : warning C4099: 'A' : type name first seen using 'struct' now
seen using 'class'
        test.cpp(1) : see declaration of 'A'

So it seems that in the compiler shootout above out of the three (VS,
clang, gcc) two warn with the appropriate warning level and one doesn't.
In the little toy example I wrote, adding two functions before and after
the definition of the class, taking the object by reference, the generated
symbols were mangled exactly the same

   David

On Tue, Jun 30, 2015 at 10:12 AM, David Rodr=C3=ADguez Ibeas <dibeas@ieee.o=
rg>
wrote:

>
>
> On Tue, Jun 30, 2015 at 12:09 AM, Thiago Macieira <thiago@macieira.org>
> wrote:
>
>> It's no more surprising than discovering that struct and class are the
>> same.
>> If there's a keyword, why should they be interchangeable?
>>
>
> struct is needed for C backwards compatibility, class is the default for
> OO, where members default to private. You cannot make the default access
> specifier in 'struct' private without breaking C compatiblity, you cannot
> remove 'struct' without breaking C compatibility. The designer of the
> language did not want to settle for public as the default access specifie=
r.
> That is how we ended with two keywords.
>
>
>> Most newbies eventually wonder that and wonder what extra features class
>> has
>> over struct.
>
>
> This is educational, most interviews I've been in ask precisely that, wha=
t
> is the difference between 'class' and 'struct', and it is expected that
> people know there aren't beyond the default access specifier.
>
>
>> In the three most widely used implementations, we have three different
>> behaviours:
>>
>> 1) error
>> 2) warning
>> 3) accept
>>
>
> VS is wrong in generating an error (is it still an error?), Clang is bein=
g
> helpful as it also targets windows in telling you that the code might fai=
l
> to compile in a broken compiler. Gcc accepts the code as it is, as the
> standard mandates.
>
> If we are going to standardize the behavior of one compiler, we might wan=
t
> to make these two signatures not equivalent, as Solaris CC mangles them
> differently:
>
> void f(int);
> void f(const int);
>
> We should also remove two phase lookup, since VS does not implement it
> --this would open the question of whether two phase lookup should be
> standardized in the next standard since both gcc does it (and clang, and
> CC, and xlC)...
>
> We should also let the compiler peek into a .cpp or .cc if the header
> contains a template, since Solaris CC does that.
>
> Coming back to a more serious stance, out of all the vendors I believe
> that VS is the one that cares the least about breaking binary compatibili=
ty
> between releases.  They just decided not to fix this particular issue in
> the compiler. Standards are for implementations to follow, not the other
> way around. A standard should  adapt to existing implementations if they
> offer advantages, which I dont' think is the case here. There is no
> technical advantage in mangling differently 'struct' and 'class'.
>
>    David
>

--=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/.

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

<div dir=3D"ltr">For the record:<br><br><div>C:\code\fwddecl =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</div>=
<div>=CE=BB cat test.cpp =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</div><div>struct A; =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0</div><div>class A {}; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</div><div>in=
t main() {} =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</div><div>C:\code\fwddecl =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</div><di=
v>=CE=BB cl test.cpp =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</div><div>Microsoft (R) 32-bit C/C++=
 Optimizing Compiler Version 16.00.40219.01 for 80x86 =C2=A0</div><div>Copy=
right (C) Microsoft Corporation.=C2=A0 All rights reserved. =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</div>=
<div>test.cpp =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</div><div>Microsoft (R)=
 Incremental Linker Version 10.00.40219.01 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</div><div>Copyr=
ight (C) Microsoft Corporation.=C2=A0 All rights reserved. =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</div>=
<div>/out:test.exe =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</div><div>test.obj</div><div><br></div><=
div>With /W4 you get the following warning:<br><br><div>test.cpp(2) : warni=
ng C4099: &#39;A&#39; : type name first seen using &#39;struct&#39; now see=
n using &#39;class&#39;</div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 test.cpp(1) : see =
declaration of &#39;A&#39;=C2=A0<br><br>So it seems that in the compiler sh=
ootout above out of the three (VS, clang, gcc) two warn with the appropriat=
e warning level and one doesn&#39;t.=C2=A0 In the little toy example I wrot=
e, adding two functions before and after the definition of the class, takin=
g the object by reference, the generated symbols were mangled exactly the s=
ame<br><br>=C2=A0 =C2=A0David</div></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On Tue, Jun 30, 2015 at 10:12 AM, David Rodr=C3=ADg=
uez Ibeas <span dir=3D"ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" target=
=3D"_blank">dibeas@ieee.org</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote"><span class=3D"">On Tue, Jun 30, 2015 at 12:09 AM, Thiago Maci=
eira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D=
"_blank">thiago@macieira.org</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">It&#39;s no more surprising than discovering that struct and clas=
s are the same.<br>
If there&#39;s a keyword, why should they be interchangeable?<br></blockquo=
te><div><br></div></span><div>struct is needed for C backwards compatibilit=
y, class is the default for OO, where members default to private. You canno=
t make the default access specifier in &#39;struct&#39; private without bre=
aking C compatiblity, you cannot remove &#39;struct&#39; without breaking C=
 compatibility. The designer of the language did not want to settle for pub=
lic as the default access specifier. That is how we ended with two keywords=
..</div><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mos=
t newbies eventually wonder that and wonder what extra features class has<b=
r>
over struct.</blockquote></span><div><br>This is educational, most intervie=
ws I&#39;ve been in ask precisely that, what is the difference between &#39=
;class&#39; and &#39;struct&#39;, and it is expected that people know there=
 aren&#39;t beyond the default access specifier.=C2=A0</div><span class=3D"=
"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">In the three most widely =
used implementations, we have three different<br>
behaviours:<br>
<br>
1) error<br>
2) warning<br>
3) accept<br></blockquote></span><div><br>VS is wrong in generating an erro=
r (is it still an error?), Clang is being helpful as it also targets window=
s in telling you that the code might fail to compile in a broken compiler. =
Gcc accepts the code as it is, as the standard mandates.<br><br>If we are g=
oing to standardize the behavior of one compiler, we might want to make the=
se two signatures not equivalent, as Solaris CC mangles them differently:<b=
r><br>void f(int);<br>void f(const int);<br><br>We should also remove two p=
hase lookup, since VS does not implement it --this would open the question =
of whether two phase lookup should be standardized in the next standard sin=
ce both gcc does it (and clang, and CC, and xlC)...<br><br>We should also l=
et the compiler peek into a .cpp or .cc if the header contains a template, =
since Solaris CC does that.<br><br>Coming back to a more serious stance, ou=
t of all the vendors I believe that VS is the one that cares the least abou=
t breaking binary compatibility between releases.=C2=A0 They just decided n=
ot to fix this particular issue in the compiler. Standards are for implemen=
tations to follow, not the other way around. A standard should =C2=A0adapt =
to existing implementations if they offer advantages, which I dont&#39; thi=
nk is the case here. There is no technical advantage in mangling differentl=
y &#39;struct&#39; and &#39;class&#39;.<span class=3D"HOEnZb"><font color=
=3D"#888888"><br><br>=C2=A0 =C2=A0David</font></span></div></div></div></di=
v>
</blockquote></div><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 />

--089e01160c0edf883a0519b8c5f5--

.

--001a113b0b78d66b790519becbf9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If keyword affects mangling, yes(just as 'struct A' differs from 'class
A'). As pointed in the previous thread on the discussion, forward
declaration is to be placed in public header - which is included in private
header too  in case of PIMPL. If PIMPL and code hiding is not the case,
forward declaration naturally precedes the definition in the same header.
IMHO when it comes to name-mangling, the case of forward declaration can be
considered as implicit aliasing - just like any other usage of keyword
'typename'. 'typename' has always been used to define/declare type aliases,
and it can still remain so.
=E2=80=8B=E2=80=8B

regards,
FM.



2015-06-30 0:18 GMT+04:30 Thiago Macieira <thiago@macieira.org>:

> On Monday 29 June 2015 22:37:22 Farid Mehrabi wrote:
> > mangling doesn't seem to be a major concern; since forward declaration =
is
> >  a hint to the compiler that the identifier is to be defined later, the
> > forward declaration has already been seen at the definition sight. So i=
f
> > the compiler is supposed to mangle a universally forward declared type
> > differently from other type declarations, mangled name is already at ha=
nd
> > in the definition sight. And the linker is not going to be modified,
> since
> > all the above is compilers task.
>
> So you'd require the universal declaration to always exist?
>
> That is, the code:
>
> =3D=3D=3D
> typename A;
> class A : public Base {};
> =3D=3D=3D
>
> Is not the same as
> =3D=3D=3D
> class A : public Base {};
> =3D=3D=3D
>
> --
> 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/.
>



--=20
how am I supposed to end the twisted road of  your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!

--=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/.

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

<div dir=3D"rtl"><div class=3D"gmail_default" style=3D"font-family:&#39;ari=
al narrow&#39;,sans-serif;font-size:large" dir=3D"ltr">If keyword affects m=
angling, yes(just as &#39;struct A&#39; differs from &#39;class A&#39;). As=
 pointed in the previous thread on the discussion, forward declaration is t=
o be placed in public header - which is included in private header too =C2=
=A0in case of PIMPL. If PIMPL and code hiding is not the case, forward decl=
aration=C2=A0naturally precedes the definition in the same header. IMHO whe=
n it comes to name-mangling, the case of forward declaration can be conside=
red as implicit aliasing - just like any other usage of keyword &#39;typena=
me&#39;. &#39;typename&#39; has always been used to define/declare type ali=
ases, and it can still remain so.</div><div class=3D"gmail_default" style=
=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large">=E2=80=
=8B=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family:&#39;ar=
ial narrow&#39;,sans-serif;font-size:large" dir=3D"ltr"><br></div><div clas=
s=3D"gmail_default" style=3D"font-family:&#39;arial narrow&#39;,sans-serif;=
font-size:large" dir=3D"ltr">regards,</div><div class=3D"gmail_default" sty=
le=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large" dir=3D=
"ltr">FM.</div><div class=3D"gmail_default" style=3D"font-family:&#39;arial=
 narrow&#39;,sans-serif;font-size:large" dir=3D"ltr"><blockquote style=3D"m=
argin:0 0 0 40px;border:none;padding:0px"><div class=3D"gmail_default" styl=
e=3D"font-family:&#39;arial narrow&#39;,sans-serif;font-size:large"><br></d=
iv></blockquote></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr">2015-06-30 0:18 GMT+04:30 Thiago Macieira <span dir=
=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiag=
o@macieira.org</a>&gt;</span>:</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"">On Monday 29 June 2015 22:37:22 Farid Mehrabi wrote:<br>
&gt; mangling doesn&#39;t seem to be a major concern; since forward declara=
tion is<br>
&gt;=C2=A0 a hint to the compiler that the identifier is to be defined late=
r, the<br>
&gt; forward declaration has already been seen at the definition sight. So =
if<br>
&gt; the compiler is supposed to mangle a universally forward declared type=
<br>
&gt; differently from other type declarations, mangled name is already at h=
and<br>
&gt; in the definition sight. And the linker is not going to be modified, s=
ince<br>
&gt; all the above is compilers task.<br>
<br>
</span>So you&#39;d require the universal declaration to always exist?<br>
<br>
That is, the code:<br>
<br>
=3D=3D=3D<br>
typename A;<br>
class A : public Base {};<br>
=3D=3D=3D<br>
<br>
Is not the same as<br>
=3D=3D=3D<br>
class A : public Base {};<br>
=3D=3D=3D<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
<br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"rtl"><div><div dir=3D"ltr">how a=
m I supposed to end the twisted road of=C2=A0 your hair in such a dark nigh=
t??<br>unless the candle of your face does shed some light upon my way!!!<b=
r></div></div></div></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 />

--001a113b0b78d66b790519becbf9--

.

On Tuesday 30 June 2015 10:12:57 David Rodr=C3=ADguez Ibeas wrote:
> On Tue, Jun 30, 2015 at 12:09 AM, Thiago Macieira <thiago@macieira.org>
>=20
> wrote:
> > It's no more surprising than discovering that struct and class are the
> > same.
> > If there's a keyword, why should they be interchangeable?
>=20
> struct is needed for C backwards compatibility, class is the default for
> OO, where members default to private. You cannot make the default access
> specifier in 'struct' private without breaking C compatiblity, you cannot
> remove 'struct' without breaking C compatibility. The designer of the
> language did not want to settle for public as the default access specifie=
r.
> That is how we ended with two keywords.

I understand that, but it's still surprising. The only explanation of why w=
e=20
have "class" is that it defaults to private. I don't know why Bjarne was=20
convinced by this, but it seems like a shallow argument for me.

On the other hand, if you said this is a contrived reason just so we could=
=20
have "class" in the language which was then called "C with classes", I'd=20
believe you more.

> > Most newbies eventually wonder that and wonder what extra features clas=
s
> > has
> > over struct.
>=20
> This is educational, most interviews I've been in ask precisely that, wha=
t
> is the difference between 'class' and 'struct', and it is expected that
> people know there aren't beyond the default access specifier.

Indeed, but that's not the group of people we were talking about. I was=20
referring to newbies.

> > In the three most widely used implementations, we have three different
> > behaviours:
> >=20
> > 1) error
> > 2) warning
> > 3) accept
>=20
> VS is wrong in generating an error (is it still an error?), Clang is bein=
g
> helpful as it also targets windows in telling you that the code might fai=
l
> to compile in a broken compiler. Gcc accepts the code as it is, as the
> standard mandates.
>=20
> If we are going to standardize the behavior of one compiler, we might wan=
t
> to make these two signatures not equivalent, as Solaris CC mangles them
> differently:
>=20
> void f(int);
> void f(const int);

Does the standard say that the const should be ignored? That is, does the=
=20
standard specifically say that the exact two lines above in the same file s=
hould=20
not produce an error and should be considered otherwise identical?

Anyway, if we look at the four implementations in question, we have a 3x1 w=
in,=20
with those three being the three most widely used implementations. I don't =
buy=20
your argument.

> We should also remove two phase lookup, since VS does not implement it
> --this would open the question of whether two phase lookup should be
> standardized in the next standard since both gcc does it (and clang, and
> CC, and xlC)...

2x1 of the most widely used.

> Coming back to a more serious stance, out of all the vendors I believe th=
at
> VS is the one that cares the least about breaking binary compatibility
> between releases.  They just decided not to fix this particular issue in
> the compiler. Standards are for implementations to follow, not the other
> way around. A standard should  adapt to existing implementations if they
> offer advantages, which I dont' think is the case here. There is no
> technical advantage in mangling differently 'struct' and 'class'.

I actually agree. Yes, VS should be fixed. I don't know why Microsoft won't=
=20
just do it or why they haven't done it in the past 8 releases since the C++=
=20
standard was ratified in 98.

What I am saying is that it shouldn't be a big deal to standardise existing=
=20
practice in this case, since 2 of the three most widely used compilers do=
=20
produce diagnostics for this practice.

--=20
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

--=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/.

.

On Tuesday 30 June 2015 10:24:27 David Rodr=C3=ADguez Ibeas wrote:
> So it seems that in the compiler shootout above out of the three (VS,
> clang, gcc) two warn with the appropriate warning level and one doesn't.
> In the little toy example I wrote, adding two functions before and after
> the definition of the class, taking the object by reference, the generate=
d
> symbols were mangled exactly the same

Please test with two .cpp files.
--=20
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

--=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_1313_490391169.1435704726695
Content-Type: multipart/alternative;
 boundary="----=_Part_1314_2109623844.1435704726695"

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

On Tuesday, June 30, 2015 at 2:13:00 AM UTC-7, David Rodr=C3=ADguez Ibeas w=
rote:
>
> A standard should  adapt to existing implementations if they offer=20
> advantages, which I dont' think is the case here. There is no technical=
=20
> advantage in mangling differently 'struct' and 'class'.
>
>    David
>

The technical advantage of mangling struct and class differently in symbol=
=20
names is catching the use of undefined behavior by the programmer(s): the=
=20
program may not link if you mix them inappropriately.

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_1314_2109623844.1435704726695
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, June 30, 2015 at 2:13:00 AM UTC-7, David Rodr=
=C3=ADguez Ibeas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">A standard should &nbsp;adapt to existing implementations if they=
 offer advantages, which I dont' think is the case here. There is no techni=
cal advantage in mangling differently 'struct' and 'class'.<br><div><div cl=
ass=3D"gmail_quote"><div><br>&nbsp; &nbsp;David</div></div></div></div></bl=
ockquote><div><br>The technical advantage of mangling <span style=3D"font-f=
amily: courier new,monospace;">struct</span> and <span style=3D"font-family=
: courier new,monospace;">class</span> differently in symbol names is catch=
ing the use of undefined behavior by the programmer(s): the program may not=
 link if you mix them inappropriately.<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_1314_2109623844.1435704726695--
------=_Part_1313_490391169.1435704726695--

.

--Apple-Mail=_9F2F321D-A75B-45EC-8BED-F9F52D300EE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9307=E2=80=9301, at 6:52 AM, Myriachan <myriachan@gmail.com=
> wrote:
>=20
> The technical advantage of mangling struct and class differently in symbo=
l names is catching the use of undefined behavior by the programmer(s): the=
 program may not link if you mix them inappropriately.

There=E2=80=99s no undefined behavior. MSVC link errors are not conforming.

--=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/.

--Apple-Mail=_9F2F321D-A75B-45EC-8BED-F9F52D300EE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9307=
=E2=80=9301, at 6:52 AM, Myriachan &lt;<a href=3D"mailto:myriachan@gmail.co=
m" class=3D"">myriachan@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-in=
terchange-newline"><div class=3D""><span style=3D"font-family: Helvetica; f=
ont-size: 12px; font-style: normal; font-variant: normal; font-weight: norm=
al; letter-spacing: normal; line-height: normal; orphans: auto; text-align:=
 start; text-indent: 0px; text-transform: none; white-space: normal; widows=
: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; dis=
play: inline !important;" class=3D"">The technical advantage of mangling<sp=
an class=3D"Apple-converted-space">&nbsp;</span></span><span style=3D"font-=
size: 12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: sta=
rt; text-indent: 0px; text-transform: none; white-space: normal; widows: au=
to; word-spacing: 0px; -webkit-text-stroke-width: 0px; font-family: 'courie=
r new', monospace;" class=3D"">struct</span><span style=3D"font-family: Hel=
vetica; font-size: 12px; font-style: normal; font-variant: normal; font-wei=
ght: normal; letter-spacing: normal; line-height: normal; orphans: auto; te=
xt-align: start; text-indent: 0px; text-transform: none; white-space: norma=
l; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: =
none; display: inline !important;" class=3D""><span class=3D"Apple-converte=
d-space">&nbsp;</span>and<span class=3D"Apple-converted-space">&nbsp;</span=
></span><span style=3D"font-size: 12px; font-style: normal; font-variant: n=
ormal; font-weight: normal; letter-spacing: normal; line-height: normal; or=
phans: auto; text-align: start; text-indent: 0px; text-transform: none; whi=
te-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-widt=
h: 0px; font-family: 'courier new', monospace;" class=3D"">class</span><spa=
n style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon=
t-variant: normal; font-weight: normal; letter-spacing: normal; line-height=
: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text=
-stroke-width: 0px; float: none; display: inline !important;" class=3D""><s=
pan class=3D"Apple-converted-space">&nbsp;</span>differently in symbol name=
s is catching the use of undefined behavior by the programmer(s): the progr=
am may not link if you mix them inappropriately.</span><br style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
 font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
 auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
;" class=3D""></div></blockquote></div><br class=3D""><div class=3D"">There=
=E2=80=99s no undefined behavior. MSVC link errors are not conforming.</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 />

--Apple-Mail=_9F2F321D-A75B-45EC-8BED-F9F52D300EE1--

.

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

On Tue, Jun 30, 2015 at 9:36 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> I actually agree. Yes, VS should be fixed.
>


> What I am saying is that it shouldn't be a big deal to standardise existing
> practice in this case


I feel a strong contradiction here. Either they should fix it or the
standard should accept *one* implementations choice against all others.
Note that the change in the standard can potentially break an unknown
number of programs that are legal today in any platform other than Windows,
the alternatives that we are discussing is:

- The implementation does the right thing and complies with the standard,
all  programs that worked in VS-current will work in VS-fixed

- We change the standard, force all other implementations to adjust, break
existing code.

Which do you think is the sensible way to proceed?

    David

--

---
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/.

--089e0160bd709e88250519cd4ed8
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=
ue, Jun 30, 2015 at 9:36 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">I actually agree. Yes, V=
S should be fixed.<br></blockquote><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
What I am saying is that it shouldn&#39;t be a big deal to standardise exis=
ting<br>
practice in this case</blockquote><div><br>I feel a strong contradiction he=
re. Either they should fix it or the standard should accept *one* implement=
ations choice against all others.=C2=A0 Note that the change in the standar=
d can potentially break an unknown number of programs that are legal today =
in any platform other than Windows, the alternatives that we are discussing=
 is:<br><br>- The implementation does the right thing and complies with the=
 standard, all =C2=A0programs that worked in VS-current will work in VS-fix=
ed<br><br>- We change the standard, force all other implementations to adju=
st, break existing code.<br><br>Which do you think is the sensible way to p=
roceed?<br><br>=C2=A0 =C2=A0 David<br><br></div></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 />

--089e0160bd709e88250519cd4ed8--

.

On Tue, Jun 30, 2015 at 7:34 PM, Farid Mehrabi <farid.mehrabi@gmail.com> wrote:
> If keyword affects mangling, yes(just as 'struct A' differs from 'class A').
> As pointed in the previous thread on the discussion, forward declaration is
> to be placed in public header - which is included in private header too  in
> case of PIMPL. If PIMPL and code hiding is not the case, forward declaration
> naturally precedes the definition in the same header. IMHO when it comes to
> name-mangling, the case of forward declaration can be considered as implicit
> aliasing - just like any other usage of keyword 'typename'. 'typename' has
> always been used to define/declare type aliases, and it can still remain so.

The 'kind' of the type is essential in forward declarations because
the forward-declared types can affect mangling of other symbols. For
instance:

  typename A;

  void foo(A*);

  template< typename T >
  class bar
  {
    void hello(); // how to mangle bar<A>::hello?
  };

It is debatable whether it is reasonable to consider structs and
classes distinct kinds of types but unions and enums are certainly
distinct and should be mangled differently.

--

---
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 01 July 2015 10:54:21 David Rodr=C3=ADguez Ibeas wrote:
> On Tue, Jun 30, 2015 at 9:36 PM, Thiago Macieira <thiago@macieira.org>
>=20
> wrote:
> > I actually agree. Yes, VS should be fixed.
> >=20
> >=20
> >=20
> > What I am saying is that it shouldn't be a big deal to standardise
> > existing
> > practice in this case
>=20
> I feel a strong contradiction here. Either they should fix it or the
> standard should accept *one* implementations choice against all others.

My point is that, if it were up to me, in a blue sky scenario, I would fix =
VS.=20
I'd even go further and make it use the portable IA-64 C++ ABI instead of=
=20
rolling out its own.

But Microsoft has had 8 major releases of its C++ compiler since the C++98=
=20
standard, so there might be a reason we're not privy to that prevents them=
=20
from fixing this. So I wouldn't be opposed to changing the standard instead=
..

> Note that the change in the standard can potentially break an unknown
> number of programs that are legal today in any platform other than Window=
s,
> the alternatives that we are discussing is:

True, but as I said, of the three major C++ compilers in use, one makes it =
an=20
error and another makes it a warning. So there's a good chance that portabl=
e=20
programs have already "fixed" the issue. I wouldn't know how big that numbe=
r of=20
programs that could break is.

> - The implementation does the right thing and complies with the standard,
> all  programs that worked in VS-current will work in VS-fixed
>=20
> - We change the standard, force all other implementations to adjust, brea=
k
> existing code.
>=20
> Which do you think is the sensible way to proceed?

The first, but why hasn't Microsoft done it in the last 18 years? Is there =
an=20
issue we're not seeing? They have deprecated features of their mangling sch=
eme=20
in the past -- exception specification, for example[*] -- so why not this?

Would be nice to ask someone at Microsoft.

[*] the Z at the end of function names stands for throw(...), but all=20
functions are mangled like that, even those that have different exception=
=20
specifications or have noexcept.

--=20
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

--=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_357_1971937832.1436413005204
Content-Type: multipart/alternative;
 boundary="----=_Part_358_1824087011.1436413005205"

------=_Part_358_1824087011.1436413005205
Content-Type: text/plain; charset=UTF-8

On Monday, June 29, 2015 at 6:41:15 PM UTC-7, Richard Smith wrote:
>
> On Mon, Jun 29, 2015 at 6:19 PM, Myriachan <myri...@gmail.com
> <javascript:>> wrote:
>
>> Is a compiler even required to use the same memory layout for classes and
>> structs if not constrained by other rules (e.g. standard-layout /
>> layout-compatible)?
>>
>
> No, but the tag keyword is not relevant to that question. A compiler is
> not constrained to lay out two non-standard-layout classes the same even if
> they have members of the same types in the same order.
>
>
>
It seems to me that the Standard as-is implies that at the least, member
pointers have to be format-compatible between struct and class.  For
example, an implementation using a classic vtable design for virtual
functions could not store the vtable pointer at a different offset for
structs versus classes (unless this offset itself or means of determining
it were stored in the member pointer).

Even without the struct/class difference, MSVC is broken in its handling of
member pointers to forward-declared classes, but that's another issue.

struct Meow;

void Test(Meow *object, void (Meow::*function)())
{
    (object->*function)();
}

// A definition that the translation unit may not ever see
class Meow
{
public:
    virtual void Function() { }
};

int main()
{
    Meow meow;
    Test(&meow, &Meow::Function);
    return 0;
}



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_358_1824087011.1436413005205
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Monday, June 29, 2015 at 6:41:15 PM UTC-7, Richard Smith wrote:<blockquo=
te 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 class=3D"gma=
il_quote">On Mon, Jun 29, 2015 at 6:19 PM, Myriachan <span dir=3D"ltr">&lt;=
<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;=
javascript:&#39;;return true;">myri...@gmail.com</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr">Is a compiler even required =
to use the same memory layout for classes and structs if not constrained by=
 other rules (e.g. standard-layout / layout-compatible)?</div></blockquote>=
<div><br></div><div>No, but the tag keyword is not relevant to that questio=
n. A compiler is not constrained to lay out two non-standard-layout classes=
 the same even if they have members of the same types in the same order.</d=
iv><br></div><br></div></div></blockquote><div><br>It seems to me that the =
Standard as-is implies that at the least, member pointers have to be format=
-compatible between <span style=3D"font-family: courier new,monospace;">str=
uct</span> and <span style=3D"font-family: courier new,monospace;">class</s=
pan>.=C2=A0 For example, an implementation using a classic vtable design fo=
r virtual functions could not store the vtable pointer at a different offse=
t for structs versus classes (unless this offset itself or means of determi=
ning it were stored in the member pointer).<br><br>Even without the <span s=
tyle=3D"font-family: courier new,monospace;">struct</span>/<span style=3D"f=
ont-family: courier new,monospace;">class</span> difference, MSVC is broken=
 in its handling of member pointers to forward-declared classes, but that&#=
39;s another issue.<br><br><div class=3D"prettyprint" style=3D"background-c=
olor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: s=
olid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint=
"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"style=
d-by-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify=
">Meow</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Test</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">Meow</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">*</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">object</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Meow</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::*</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">function</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)())</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">object</span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&=
gt;*</span><span style=3D"color: #008;" class=3D"styled-by-prettify">functi=
on</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)();</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// A definition that the tra=
nslation unit may not ever see</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
Meow</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">public</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">virtual</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">Function</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> main</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">Meow</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> m=
eow</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Test</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(&amp;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">meow</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: #=
660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">Meow</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">Function</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></=
div><br><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_358_1824087011.1436413005205--
------=_Part_357_1971937832.1436413005204--

.