Topic: Allowing non-static data members of forward
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Mon, 7 Jan 2019 08:40:59 -0800 (PST)
Raw View
------=_Part_1600_73092271.1546879259718
Content-Type: multipart/alternative;
boundary="----=_Part_1601_242615357.1546879259718"
------=_Part_1601_242615357.1546879259718
Content-Type: text/plain; charset="UTF-8"
Il giorno domenica 6 gennaio 2019 12:32:49 UTC+1, Avi Kivity ha scritto:
>
> C++ forbids a NSDM from having a non-pointer, non-reference
> forward-declared type, presumably because it makes it impossible to know
> the size, alignment, and member offsets of the class:
>
> class foo;
>
> class bar {
> foo f; // error
> };
>
>
> A common work around is to use indirection, trading run-time performance
> for compile time:
>
> class foo;
>
> class bar {
> std::unique_ptr<foo> f;
> bar(); // if we aren't satisfied with null f
> ~bar(); // so we don't need foo's destructor here
> };
>
>
Another workaround is to make the class a template:
class foo;
template <class Foo> // requires Same<Foo, foo>
class basic_bar {
Foo f;
};
using bar = basic_bar<foo>;
> I think it would be useful for large code bases battling compile time to
> relax this restriction. It would make any inline (generated or user
> provided) function that requires offsets, alignment, or sizes be
> ill-formed, but we are already used to moving these functions out-of-line,
> or defining them in places where the full types are known.
>
> I think this is a relatively simple change for compilers. The main
> drawback is that errors become less clear, but the situation is so common
> that I think it's worth it.
>
I think you are understating both the complexity of the change and the
drawbacks. Since the template workaround is just two lines longer and
effectively and optimally addresses the problem within the current
language, I believe adding a new feature is not necessary, nor desirable.
Just my opinion.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a2f0bd75-6546-444d-9284-aba6e5f6a16f%40isocpp.org.
------=_Part_1601_242615357.1546879259718
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Il giorno domenica 6 gennaio 2019 12:32:49 UTC+1, =
Avi Kivity ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
C++ forbids a NSDM from having a non-pointer, non-reference
forward-declared type, presumably because it makes it impossible to
know the size, alignment, and member offsets of the class:<br>
=20
<blockquote>class foo;<br>
<br>
class bar {<br>
=C2=A0=C2=A0 foo f; // error<br>
};<br>
</blockquote>
=20
<br>
A common work around is to use indirection, trading run-time
performance for compile time:<br>
=20
<blockquote>class foo;<br>
<br>
class bar {<br>
=C2=A0=C2=A0=C2=A0 std::unique_ptr<foo> f;<br>
=C2=A0=C2=A0=C2=A0 bar(); // if we aren't satisfied with null f<b=
r>
=C2=A0=C2=A0=C2=A0 ~bar(); // so we don't need foo's destruct=
or here<br>
};<br>
</blockquote></div></blockquote><div><br></div><div>Another workaround =
is to make the class a template:</div><div><br></div><div style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettypri=
nt"><code class=3D"prettyprint"><div class=3D"subprettyprint"><div><blockqu=
ote><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span></blockquote><di=
v><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span></div><=
blockquote><span style=3D"color: #008;" class=3D"styled-by-prettify">templa=
te</span><span 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: #008;" class=3D"styled-by-prettify">class</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Foo</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styl=
ed-by-prettify">// requires Same<Foo, foo></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;" cl=
ass=3D"styled-by-prettify"> basic_bar </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Foo</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> f</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></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">using</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> bar </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> basic_bar</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify"><foo></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span></blockquote></div></div>=
</code></div><br><div></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv text=3D"#000000" bgcolor=3D"#FFFFFF">
<br>
I think it would be useful for large code bases battling compile
time to relax this restriction. It would make any inline (generated
or user provided) function that requires offsets, alignment, or
sizes be ill-formed, but we are already used to moving these
functions out-of-line, or defining them in places where the full
types are known.<br>
<br>
=20
I think this is a relatively simple change for compilers. The main
drawback is that errors become less clear, but the situation is so
common that I think it's worth it.<br></div></blockquote><div><br><=
/div><div>I think you are understating both the complexity of the change an=
d the drawbacks. Since the template workaround is just two lines longer and=
effectively and optimally addresses the problem within the current languag=
e, I believe adding a new feature is not necessary, nor desirable. Just my =
opinion.<br></div><div><br></div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a2f0bd75-6546-444d-9284-aba6e5f6a16f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a2f0bd75-6546-444d-9284-aba6e5f6a16f=
%40isocpp.org</a>.<br />
------=_Part_1601_242615357.1546879259718--
------=_Part_1600_73092271.1546879259718--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 7 Jan 2019 09:30:48 -0800 (PST)
Raw View
------=_Part_1594_1393293919.1546882248823
Content-Type: multipart/alternative;
boundary="----=_Part_1595_532695140.1546882248823"
------=_Part_1595_532695140.1546882248823
Content-Type: text/plain; charset="UTF-8"
On Monday, January 7, 2019 at 11:40:59 AM UTC-5, Alberto Barbati wrote:
>
> Il giorno domenica 6 gennaio 2019 12:32:49 UTC+1, Avi Kivity ha scritto:
>>
>> C++ forbids a NSDM from having a non-pointer, non-reference
>> forward-declared type, presumably because it makes it impossible to know
>> the size, alignment, and member offsets of the class:
>>
>> class foo;
>>
>> class bar {
>> foo f; // error
>> };
>>
>>
>> A common work around is to use indirection, trading run-time performance
>> for compile time:
>>
>> class foo;
>>
>> class bar {
>> std::unique_ptr<foo> f;
>> bar(); // if we aren't satisfied with null f
>> ~bar(); // so we don't need foo's destructor here
>> };
>>
>>
> Another workaround is to make the class a template:
>
> class foo;
>
> template <class Foo> // requires Same<Foo, foo>
> class basic_bar {
> Foo f;
> };
>
> using bar = basic_bar<foo>;
>
>
>
>> I think it would be useful for large code bases battling compile time to
>> relax this restriction. It would make any inline (generated or user
>> provided) function that requires offsets, alignment, or sizes be
>> ill-formed, but we are already used to moving these functions out-of-line,
>> or defining them in places where the full types are known.
>>
>> I think this is a relatively simple change for compilers. The main
>> drawback is that errors become less clear, but the situation is so common
>> that I think it's worth it.
>>
>
> I think you are understating both the complexity of the change and the
> drawbacks. Since the template workaround is just two lines longer and
> effectively and optimally addresses the problem within the current
> language, I believe adding a new feature is not necessary, nor desirable.
> Just my opinion.
>
I cannot agree that this "optimally addresses the problem". It requires
`basic_bar` to be a template, which fundamentally changes the nature of the
type. You now *have to* put its member definitions in the header rather
than having a .h/.cpp split. If you misuse `Foo`, calling a typo-ed
function, the error you get will be in a decidedly unexpected place.
It even affects how IDEs work, since they won't automatically know that
`Foo` means `foo`, so it won't be able to handle autocompletion.
I agree that the OP is significantly understating the problems with the
proposed solution. However, I also think that "large code bases battling
compile time" will be better served by actively incorporating modules than
this. So let's see if modules can make such things unimportant before we go
requiring the compiler to do such things.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fcf4798b-d595-44ca-b080-abcbda1e8264%40isocpp.org.
------=_Part_1595_532695140.1546882248823
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, January 7, 2019 at 11:40:59 AM UTC-5, Alberto B=
arbati wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
Il giorno domenica 6 gennaio 2019 12:32:49 UTC+1, Avi Kivity ha scritto:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
C++ forbids a NSDM from having a non-pointer, non-reference
forward-declared type, presumably because it makes it impossible to
know the size, alignment, and member offsets of the class:<br>
=20
<blockquote>class foo;<br>
<br>
class bar {<br>
=C2=A0=C2=A0 foo f; // error<br>
};<br>
</blockquote>
=20
<br>
A common work around is to use indirection, trading run-time
performance for compile time:<br>
=20
<blockquote>class foo;<br>
<br>
class bar {<br>
=C2=A0=C2=A0=C2=A0 std::unique_ptr<foo> f;<br>
=C2=A0=C2=A0=C2=A0 bar(); // if we aren't satisfied with null f<b=
r>
=C2=A0=C2=A0=C2=A0 ~bar(); // so we don't need foo's destruct=
or here<br>
};<br>
</blockquote></div></blockquote><div><br></div><div>Another workaround =
is to make the class a template:</div><div><br></div><div style=3D"backgrou=
nd-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;=
border-width:1px"><code><div><div><blockquote><span style=3D"color:#008">cl=
ass</span><span style=3D"color:#000"> foo</span><span style=3D"color:#660">=
;</span></blockquote><div><span style=3D"color:#000"> </span></div><blockqu=
ote><span style=3D"color:#008">template</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660"><</span><span style=3D"color:#008">clas=
s</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Foo</=
span><span style=3D"color:#660">></span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#800">// requires Same<Foo, foo></span><span =
style=3D"color:#000"><br></span><span style=3D"color:#008">class</span><spa=
n style=3D"color:#000"> basic_bar </span><span style=3D"color:#660">{</span=
><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#=
606">Foo</span><span style=3D"color:#000"> f</span><span style=3D"color:#66=
0">;</span><span style=3D"color:#000"><br></span><span style=3D"color:#660"=
>};</span><span style=3D"color:#000"><br><br></span><span style=3D"color:#0=
08">using</span><span style=3D"color:#000"> bar </span><span style=3D"color=
:#660">=3D</span><span style=3D"color:#000"> basic_bar</span><span style=3D=
"color:#080"><foo></span><span style=3D"color:#660">;</span><span sty=
le=3D"color:#000"><br></span></blockquote></div></div></code></div><br><div=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div text=3D"#000000" bgcolo=
r=3D"#FFFFFF">
<br>
I think it would be useful for large code bases battling compile
time to relax this restriction. It would make any inline (generated
or user provided) function that requires offsets, alignment, or
sizes be ill-formed, but we are already used to moving these
functions out-of-line, or defining them in places where the full
types are known.<br>
<br>
=20
I think this is a relatively simple change for compilers. The main
drawback is that errors become less clear, but the situation is so
common that I think it's worth it.<br></div></blockquote><div><br><=
/div><div>I think you are understating both the complexity of the change an=
d the drawbacks. Since the template workaround is just two lines longer and=
effectively and optimally addresses the problem within the current languag=
e, I believe adding a new feature is not necessary, nor desirable. Just my =
opinion.<br></div></div></blockquote><div><br></div><div>I cannot agree tha=
t this "optimally addresses the problem". It requires `basic_bar`=
to be a template, which fundamentally changes the nature of the type. You =
now <i>have to</i> put its member definitions in the header rather than hav=
ing a .h/.cpp split. If you misuse `Foo`, calling a typo-ed function, the e=
rror you get will be in a decidedly unexpected place.<br></div><div><br></d=
iv><div>It even affects how IDEs work, since they won't automatically k=
now that `Foo` means `foo`, so it won't be able to handle autocompletio=
n.</div><div><br></div><div>I agree that the OP is significantly understati=
ng the problems with the proposed solution. However, I also think that &quo=
t;large code bases battling compile time" will be better served by act=
ively incorporating modules than this. So let's see if modules can make=
such things unimportant before we go requiring the compiler to do such thi=
ngs.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fcf4798b-d595-44ca-b080-abcbda1e8264%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fcf4798b-d595-44ca-b080-abcbda1e8264=
%40isocpp.org</a>.<br />
------=_Part_1595_532695140.1546882248823--
------=_Part_1594_1393293919.1546882248823--
.
Author: Manuel Bergler <berglerma@gmail.com>
Date: Mon, 7 Jan 2019 18:36:24 +0100
Raw View
--000000000000a8b0b0057ee1abee
Content-Type: text/plain; charset="UTF-8"
Am Mo., 7. Jan. 2019 um 18:30 Uhr schrieb Nicol Bolas <jmckesson@gmail.com>:
> On Monday, January 7, 2019 at 11:40:59 AM UTC-5, Alberto Barbati wrote:
>>
>> Il giorno domenica 6 gennaio 2019 12:32:49 UTC+1, Avi Kivity ha scritto:
>>>
>>> C++ forbids a NSDM from having a non-pointer, non-reference
>>> forward-declared type, presumably because it makes it impossible to know
>>> the size, alignment, and member offsets of the class:
>>>
>>> class foo;
>>>
>>> class bar {
>>> foo f; // error
>>> };
>>>
>>>
>>> A common work around is to use indirection, trading run-time performance
>>> for compile time:
>>>
>>> class foo;
>>>
>>> class bar {
>>> std::unique_ptr<foo> f;
>>> bar(); // if we aren't satisfied with null f
>>> ~bar(); // so we don't need foo's destructor here
>>> };
>>>
>>>
>> Another workaround is to make the class a template:
>>
>> class foo;
>>
>> template <class Foo> // requires Same<Foo, foo>
>> class basic_bar {
>> Foo f;
>> };
>>
>> using bar = basic_bar<foo>;
>>
>>
>>
>>> I think it would be useful for large code bases battling compile time to
>>> relax this restriction. It would make any inline (generated or user
>>> provided) function that requires offsets, alignment, or sizes be
>>> ill-formed, but we are already used to moving these functions out-of-line,
>>> or defining them in places where the full types are known.
>>>
>>> I think this is a relatively simple change for compilers. The main
>>> drawback is that errors become less clear, but the situation is so common
>>> that I think it's worth it.
>>>
>>
>> I think you are understating both the complexity of the change and the
>> drawbacks. Since the template workaround is just two lines longer and
>> effectively and optimally addresses the problem within the current
>> language, I believe adding a new feature is not necessary, nor desirable.
>> Just my opinion.
>>
>
> I cannot agree that this "optimally addresses the problem". It requires
> `basic_bar` to be a template, which fundamentally changes the nature of the
> type. You now *have to* put its member definitions in the header rather
> than having a .h/.cpp split.
>
In this particular case you don't *have* to put the definitions in the
header. You can just use `extern template class basic_bar<foo>;` and have
an additional .cpp file with the definitions plus the explicit
instantiation of the template via `template class basic_bar<foo>;`.
> If you misuse `Foo`, calling a typo-ed function, the error you get will be
> in a decidedly unexpected place.
> It even affects how IDEs work, since they won't automatically know that
> `Foo` means `foo`, so it won't be able to handle autocompletion.
>
> I agree that the OP is significantly understating the problems with the
> proposed solution. However, I also think that "large code bases battling
> compile time" will be better served by actively incorporating modules than
> this. So let's see if modules can make such things unimportant before we go
> requiring the compiler to do such things.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fcf4798b-d595-44ca-b080-abcbda1e8264%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fcf4798b-d595-44ca-b080-abcbda1e8264%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM76qmvsPPak18COFpZ1vohiMjY_AXzhm%2B6%2BycsntvWS-B_kkw%40mail.gmail.com.
--000000000000a8b0b0057ee1abee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr">Am Mo., 7. Jan. 2019 um 18:30=C2=A0Uhr schrieb Nicol Bolas=
<<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>>:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">O=
n Monday, January 7, 2019 at 11:40:59 AM UTC-5, Alberto Barbati wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Il giorno dom=
enica 6 gennaio 2019 12:32:49 UTC+1, Avi Kivity ha scritto:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF">
C++ forbids a NSDM from having a non-pointer, non-reference
forward-declared type, presumably because it makes it impossible to
know the size, alignment, and member offsets of the class:<br>
=20
<blockquote>class foo;<br>
<br>
class bar {<br>
=C2=A0=C2=A0 foo f; // error<br>
};<br>
</blockquote>
=20
<br>
A common work around is to use indirection, trading run-time
performance for compile time:<br>
=20
<blockquote>class foo;<br>
<br>
class bar {<br>
=C2=A0=C2=A0=C2=A0 std::unique_ptr<foo> f;<br>
=C2=A0=C2=A0=C2=A0 bar(); // if we aren't satisfied with null f<b=
r>
=C2=A0=C2=A0=C2=A0 ~bar(); // so we don't need foo's destruct=
or here<br>
};<br>
</blockquote></div></blockquote><div><br></div><div>Another workaround =
is to make the class a template:</div><div><br></div><div style=3D"backgrou=
nd-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;=
border-width:1px"><code><div><div><blockquote><span style=3D"color:rgb(0,0,=
136)">class</span><span style=3D"color:rgb(0,0,0)"> foo</span><span style=
=3D"color:rgb(102,102,0)">;</span></blockquote><div><span style=3D"color:rg=
b(0,0,0)"> </span></div><blockquote><span style=3D"color:rgb(0,0,136)">temp=
late</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rg=
b(102,102,0)"><</span><span style=3D"color:rgb(0,0,136)">class</span><sp=
an style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">=
Foo</span><span style=3D"color:rgb(102,102,0)">></span><span style=3D"co=
lor:rgb(0,0,0)"> </span><span style=3D"color:rgb(136,0,0)">// requires Same=
<Foo, foo></span><span style=3D"color:rgb(0,0,0)"><br></span><span st=
yle=3D"color:rgb(0,0,136)">class</span><span style=3D"color:rgb(0,0,0)"> ba=
sic_bar </span><span style=3D"color:rgb(102,102,0)">{</span><span style=3D"=
color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(102,0,1=
02)">Foo</span><span style=3D"color:rgb(0,0,0)"> f</span><span style=3D"col=
or:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br></span><spa=
n style=3D"color:rgb(102,102,0)">};</span><span style=3D"color:rgb(0,0,0)">=
<br><br></span><span style=3D"color:rgb(0,0,136)">using</span><span style=
=3D"color:rgb(0,0,0)"> bar </span><span style=3D"color:rgb(102,102,0)">=3D<=
/span><span style=3D"color:rgb(0,0,0)"> basic_bar</span><span style=3D"colo=
r:rgb(0,136,0)"><foo></span><span style=3D"color:rgb(102,102,0)">;</s=
pan><span style=3D"color:rgb(0,0,0)"><br></span></blockquote></div></div></=
code></div><br><div></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div bgcolor=3D"#FFFFFF">
<br>
I think it would be useful for large code bases battling compile
time to relax this restriction. It would make any inline (generated
or user provided) function that requires offsets, alignment, or
sizes be ill-formed, but we are already used to moving these
functions out-of-line, or defining them in places where the full
types are known.<br>
<br>
=20
I think this is a relatively simple change for compilers. The main
drawback is that errors become less clear, but the situation is so
common that I think it's worth it.<br></div></blockquote><div><br><=
/div><div>I think you are understating both the complexity of the change an=
d the drawbacks. Since the template workaround is just two lines longer and=
effectively and optimally addresses the problem within the current languag=
e, I believe adding a new feature is not necessary, nor desirable. Just my =
opinion.<br></div></div></blockquote><div><br></div><div>I cannot agree tha=
t this "optimally addresses the problem". It requires `basic_bar`=
to be a template, which fundamentally changes the nature of the type. You =
now <i>have to</i> put its member definitions in the header rather than hav=
ing a .h/.cpp split.=C2=A0<br></div></div></blockquote><div>=C2=A0</div><di=
v>In this particular case you don't *have* to put the definitions in th=
e header. You can just use `extern template class basic_bar<foo>;` an=
d have an additional .cpp file with the definitions plus the explicit insta=
ntiation of the template via `template class basic_bar<foo>;`.</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div></div><div>If you misuse `Foo`, calling a typo-ed function, t=
he error you get will be in a decidedly unexpected place.<br></div><div>It =
even affects how IDEs work, since they won't automatically know that `F=
oo` means `foo`, so it won't be able to handle autocompletion.</div><di=
v><br></div><div>I agree that the OP is significantly understating the prob=
lems with the proposed solution. However, I also think that "large cod=
e bases battling compile time" will be better served by actively incor=
porating modules than this. So let's see if modules can make such thing=
s unimportant before we go requiring the compiler to do such things.<br></d=
iv></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fcf4798b-d595-44ca-b080-abcbda1e8264%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fcf4798b-d595-=
44ca-b080-abcbda1e8264%40isocpp.org</a>.<br>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAM76qmvsPPak18COFpZ1vohiMjY_AXzhm%2B=
6%2BycsntvWS-B_kkw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM76qmvsPPak=
18COFpZ1vohiMjY_AXzhm%2B6%2BycsntvWS-B_kkw%40mail.gmail.com</a>.<br />
--000000000000a8b0b0057ee1abee--
.
Author: Mehdi AMINI <joker.eph@gmail.com>
Date: Mon, 7 Jan 2019 10:15:11 -0800
Raw View
--00000000000053c383057ee23662
Content-Type: text/plain; charset="UTF-8"
Hi,
On Mon, Jan 7, 2019 at 8:41 AM Alberto Barbati <albertobarbati@gmail.com>
wrote:
>
>
> Il giorno domenica 6 gennaio 2019 12:32:49 UTC+1, Avi Kivity ha scritto:
>>
>> C++ forbids a NSDM from having a non-pointer, non-reference
>> forward-declared type, presumably because it makes it impossible to know
>> the size, alignment, and member offsets of the class:
>>
>> class foo;
>>
>> class bar {
>> foo f; // error
>> };
>>
>>
>> A common work around is to use indirection, trading run-time performance
>> for compile time:
>>
>> class foo;
>>
>> class bar {
>> std::unique_ptr<foo> f;
>> bar(); // if we aren't satisfied with null f
>> ~bar(); // so we don't need foo's destructor here
>> };
>>
>>
> Another workaround is to make the class a template:
>
> class foo;
>
> template <class Foo> // requires Same<Foo, foo>
> class basic_bar {
> Foo f;
> };
>
> using bar = basic_bar<foo>;
>
>
>
>> I think it would be useful for large code bases battling compile time to
>> relax this restriction. It would make any inline (generated or user
>> provided) function that requires offsets, alignment, or sizes be
>> ill-formed, but we are already used to moving these functions out-of-line,
>> or defining them in places where the full types are known.
>>
>> I think this is a relatively simple change for compilers. The main
>> drawback is that errors become less clear, but the situation is so common
>> that I think it's worth it.
>>
>
Something that I didn't see mentioned is that every time you need to
declare a local variable in a function you would need to transitively
include all the headers.
For example:
Foo.h: // define class Foo
class Foo { ... };
Bar.h: // does not include Foo.h
class Foo;
class Bar {
Foo f;
};
FooBar.h:
class Bar;
class FooBar {
Bar b;
FooBar();
...
};
Some client of FooBar:
void fbar() {
// Need to know the size of FooBar, and thus Bar and Foo as well
FooBar foobar;
}
That means this consumer must include FooBar.h but also Bar.h and FooBar.h.
Also, adding a new member to Foo requires to add a new include in a
transitive consumer (client of FooBar).
--
Mehdi
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANF-O%3DY1O7e%3DVP355jcAeM5Mt%2Br1N4vwZXVqHtSBm1CV_GpjMA%40mail.gmail.com.
--00000000000053c383057ee23662
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div>Hi,</div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr">On Mon, Jan 7, 2019 at 8:41 AM Albert=
o Barbati <<a href=3D"mailto:albertobarbati@gmail.com">albertobarbati@gm=
ail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><br>I=
l giorno domenica 6 gennaio 2019 12:32:49 UTC+1, Avi Kivity ha scritto:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddi=
ng-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF">
C++ forbids a NSDM from having a non-pointer, non-reference
forward-declared type, presumably because it makes it impossible to
know the size, alignment, and member offsets of the class:<br>
=20
<blockquote>class foo;<br>
<br>
class bar {<br>
=C2=A0=C2=A0 foo f; // error<br>
};<br>
</blockquote>
=20
<br>
A common work around is to use indirection, trading run-time
performance for compile time:<br>
=20
<blockquote>class foo;<br>
<br>
class bar {<br>
=C2=A0=C2=A0=C2=A0 std::unique_ptr<foo> f;<br>
=C2=A0=C2=A0=C2=A0 bar(); // if we aren't satisfied with null f<b=
r>
=C2=A0=C2=A0=C2=A0 ~bar(); // so we don't need foo's destruct=
or here<br>
};<br>
</blockquote></div></blockquote><div><br></div><div>Another workaround =
is to make the class a template:</div><div><br></div><div style=3D"backgrou=
nd-color:rgb(250,250,250);border:1px solid rgb(187,187,187)" class=3D"gmail=
-m_-6314809214466867879prettyprint"><code class=3D"gmail-m_-631480921446686=
7879prettyprint"><div class=3D"gmail-m_-6314809214466867879subprettyprint">=
<div><blockquote><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-63148=
09214466867879styled-by-prettify">class</span><span style=3D"color:rgb(0,0,=
0)" class=3D"gmail-m_-6314809214466867879styled-by-prettify"> foo</span><sp=
an style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6314809214466867879styl=
ed-by-prettify">;</span></blockquote><div><span style=3D"color:rgb(0,0,0)" =
class=3D"gmail-m_-6314809214466867879styled-by-prettify"> </span></div><blo=
ckquote><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-63148092144668=
67879styled-by-prettify">template</span><span style=3D"color:rgb(0,0,0)" cl=
ass=3D"gmail-m_-6314809214466867879styled-by-prettify"> </span><span style=
=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6314809214466867879styled-by-pr=
ettify"><</span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-631=
4809214466867879styled-by-prettify">class</span><span style=3D"color:rgb(0,=
0,0)" class=3D"gmail-m_-6314809214466867879styled-by-prettify"> </span><spa=
n style=3D"color:rgb(102,0,102)" class=3D"gmail-m_-6314809214466867879style=
d-by-prettify">Foo</span><span style=3D"color:rgb(102,102,0)" class=3D"gmai=
l-m_-6314809214466867879styled-by-prettify">></span><span style=3D"color=
:rgb(0,0,0)" class=3D"gmail-m_-6314809214466867879styled-by-prettify"> </sp=
an><span style=3D"color:rgb(136,0,0)" class=3D"gmail-m_-6314809214466867879=
styled-by-prettify">// requires Same<Foo, foo></span><span style=3D"c=
olor:rgb(0,0,0)" class=3D"gmail-m_-6314809214466867879styled-by-prettify"><=
br></span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-631480921446=
6867879styled-by-prettify">class</span><span style=3D"color:rgb(0,0,0)" cla=
ss=3D"gmail-m_-6314809214466867879styled-by-prettify"> basic_bar </span><sp=
an style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6314809214466867879styl=
ed-by-prettify">{</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-=
6314809214466867879styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:rgb(102,0,102)" class=3D"gmail-m_-6314809214466867879styled-by-pr=
ettify">Foo</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-631480=
9214466867879styled-by-prettify"> f</span><span style=3D"color:rgb(102,102,=
0)" class=3D"gmail-m_-6314809214466867879styled-by-prettify">;</span><span =
style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6314809214466867879styled-by-p=
rettify"><br></span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-=
6314809214466867879styled-by-prettify">};</span><span style=3D"color:rgb(0,=
0,0)" class=3D"gmail-m_-6314809214466867879styled-by-prettify"><br><br></sp=
an><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-6314809214466867879=
styled-by-prettify">using</span><span style=3D"color:rgb(0,0,0)" class=3D"g=
mail-m_-6314809214466867879styled-by-prettify"> bar </span><span style=3D"c=
olor:rgb(102,102,0)" class=3D"gmail-m_-6314809214466867879styled-by-prettif=
y">=3D</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-63148092144=
66867879styled-by-prettify"> basic_bar</span><span style=3D"color:rgb(0,136=
,0)" class=3D"gmail-m_-6314809214466867879styled-by-prettify"><foo></=
span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-631480921446686=
7879styled-by-prettify">;</span><span style=3D"color:rgb(0,0,0)" class=3D"g=
mail-m_-6314809214466867879styled-by-prettify"><br></span></blockquote></di=
v></div></code></div><br><div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor=3D"#FFFFF=
F">
<br>
I think it would be useful for large code bases battling compile
time to relax this restriction. It would make any inline (generated
or user provided) function that requires offsets, alignment, or
sizes be ill-formed, but we are already used to moving these
functions out-of-line, or defining them in places where the full
types are known.<br>
<br>
=20
I think this is a relatively simple change for compilers. The main
drawback is that errors become less clear, but the situation is so
common that I think it's worth it.</div></blockquote></div></blockq=
uote><div><br></div><div><br></div><div>Something that I didn't see men=
tioned is that every time you need to declare a local variable in a functio=
n you would need to transitively include all the headers.</div><div><br></d=
iv><div>For example:</div><div><br></div><div>Foo.h: // define class Foo</d=
iv><div>class Foo { ... };</div><div><br></div><div>Bar.h: // does not incl=
ude Foo.h</div><div>class Foo;</div><div>class Bar {=C2=A0</div><div>=C2=A0=
Foo f;</div><div>};</div><div><br></div><div>FooBar.h:</div><div>class Bar=
;</div><div>class FooBar {</div><div>=C2=A0 Bar b;<br></div><div>=C2=A0 Foo=
Bar();</div><div>=C2=A0 ...</div><div>};</div><div><br></div><div>Some clie=
nt of FooBar:</div><div><br></div><div>void fbar() {</div><div>=C2=A0 =C2=
=A0 =C2=A0// Need to know the size of FooBar, and thus Bar and Foo as well<=
/div><div>=C2=A0 =C2=A0 FooBar foobar;</div><div>}</div><div>=C2=A0</div><d=
iv>That means this consumer must include FooBar.h but also Bar.h and FooBar=
..h. Also, adding a new member to Foo requires to add a new include in a tra=
nsitive consumer (client of FooBar).</div><div><br></div><div>--=C2=A0</div=
><div>Mehdi</div><div><br></div><div><br></div><div><br></div></div></div><=
/div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANF-O%3DY1O7e%3DVP355jcAeM5Mt%2Br1N4=
vwZXVqHtSBm1CV_GpjMA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANF-O%3DY1=
O7e%3DVP355jcAeM5Mt%2Br1N4vwZXVqHtSBm1CV_GpjMA%40mail.gmail.com</a>.<br />
--00000000000053c383057ee23662--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Wed, 9 Jan 2019 20:17:39 +0200
Raw View
This is a multi-part message in MIME format.
--------------1C1A5B9FFC50864861AE05E6
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 07/01/2019 20.15, Mehdi AMINI wrote:
> Hi,
>
> On Mon, Jan 7, 2019 at 8:41 AM Alberto Barbati=20
> <albertobarbati@gmail.com <mailto:albertobarbati@gmail.com>> wrote:
>
>
>
> Il giorno domenica 6 gennaio 2019 12:32:49 UTC+1, Avi Kivity ha
> scritto:
>
> C++ forbids a NSDM from having a non-pointer, non-reference
> forward-declared type, presumably because it makes it
> impossible to know the size, alignment, and member offsets of
> the class:
>
> class foo;
>
> class bar {
> =C2=A0=C2=A0 foo f; // error
> };
>
>
> A common work around is to use indirection, trading run-time
> performance for compile time:
>
> class foo;
>
> class bar {
> =C2=A0=C2=A0=C2=A0 std::unique_ptr<foo> f;
> =C2=A0=C2=A0=C2=A0 bar(); // if we aren't satisfied with null=
f
> =C2=A0=C2=A0=C2=A0 ~bar(); // so we don't need foo's destruct=
or here
> };
>
>
> Another workaround is to make the class a template:
>
> |
>
> classfoo;
>
> template<classFoo>// requires Same<Foo, foo>
> classbasic_bar {
> Foof;
> };
>
> usingbar =3Dbasic_bar<foo>;
>
> |
>
>
> I think it would be useful for large code bases battling
> compile time to relax this restriction. It would make any
> inline (generated or user provided) function that requires
> offsets, alignment, or sizes be ill-formed, but we are already
> used to moving these functions out-of-line, or defining them
> in places where the full types are known.
>
> I think this is a relatively simple change for compilers. The
> main drawback is that errors become less clear, but the
> situation is so common that I think it's worth it.
>
>
>
> Something that I didn't see mentioned is that every time you need to=20
> declare a local variable in a function you would need to transitively=20
> include all the headers.
>
> For example:
>
> Foo.h: // define class Foo
> class Foo { ... };
>
> Bar.h: // does not include Foo.h
> class Foo;
> class Bar {
> =C2=A0 Foo f;
> };
>
> FooBar.h:
> class Bar;
> class FooBar {
> =C2=A0 Bar b;
> =C2=A0 FooBar();
> =C2=A0 ...
> };
>
> Some client of FooBar:
>
> void fbar() {
> =C2=A0 =C2=A0 =C2=A0// Need to know the size of FooBar, and thus Bar and =
Foo as well
> =C2=A0 =C2=A0 FooBar foobar;
> }
> That means this consumer must include FooBar.h but also Bar.h and=20
> FooBar.h. Also, adding a new member to Foo requires to add a new=20
> include in a transitive consumer (client of FooBar).
>
>
Yes. This is meant for large types that are mostly passed around by=20
references, the top-level directories from where other functionality is=20
reached. Not for leaf types that are commonly instantiated, as you'd=20
need to #include everything anyway.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ea64e17d-17b5-960e-fdd9-0b8427626ff4%40scylladb.=
com.
--------------1C1A5B9FFC50864861AE05E6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<div class=3D"moz-cite-prefix">On 07/01/2019 20.15, Mehdi AMINI wrote:<=
br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:CANF-O=3DY1O7e=3DVP355jcAeM5Mt+r1N4vwZXVqHtSBm1CV_GpjMA@mail.gm=
ail.com">
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF=
-8">
<div dir=3D"ltr">
<div dir=3D"ltr">
<div dir=3D"ltr">
<div>Hi,</div>
<br>
<div class=3D"gmail_quote">
<div dir=3D"ltr">On Mon, Jan 7, 2019 at 8:41 AM Alberto
Barbati <<a href=3D"mailto:albertobarbati@gmail.com"
moz-do-not-send=3D"true">albertobarbati@gmail.com</a>>
wrote:<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(2=
04,204,204);padding-left:1ex">
<div dir=3D"ltr"><br>
<br>
Il giorno domenica 6 gennaio 2019 12:32:49 UTC+1, Avi
Kivity ha scritto:
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(2=
04,204,204);padding-left:1ex">
<div bgcolor=3D"#FFFFFF"> C++ forbids a NSDM from
having a non-pointer, non-reference
forward-declared type, presumably because it makes
it impossible to know the size, alignment, and
member offsets of the class:<br>
<blockquote>class foo;<br>
<br>
class bar {<br>
=C2=A0=C2=A0 foo f; // error<br>
};<br>
</blockquote>
<br>
A common work around is to use indirection,
trading run-time performance for compile time:<br>
<blockquote>class foo;<br>
<br>
class bar {<br>
=C2=A0=C2=A0=C2=A0 std::unique_ptr<foo> f;<br=
>
=C2=A0=C2=A0=C2=A0 bar(); // if we aren't satisfied=
with null f<br>
=C2=A0=C2=A0=C2=A0 ~bar(); // so we don't need foo'=
s destructor
here<br>
};<br>
</blockquote>
</div>
</blockquote>
<div><br>
</div>
<div>Another workaround is to make the class a
template:</div>
<div><br>
</div>
<div
style=3D"background-color:rgb(250,250,250);border:1px
solid rgb(187,187,187)"
class=3D"gmail-m_-6314809214466867879prettyprint"><code
class=3D"gmail-m_-6314809214466867879prettyprint">
<div
class=3D"gmail-m_-6314809214466867879subprettyprint=
">
<div>
<blockquote><span style=3D"color:rgb(0,0,136)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">class</span><span
style=3D"color:rgb(0,0,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">
foo</span><span
style=3D"color:rgb(102,102,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">;</span></blockquote>
<div><span style=3D"color:rgb(0,0,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">
</span></div>
<blockquote><span style=3D"color:rgb(0,0,136)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">template</span><span
style=3D"color:rgb(0,0,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">
</span><span style=3D"color:rgb(102,102,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify"><</span><span
style=3D"color:rgb(0,0,136)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">class</span><span
style=3D"color:rgb(0,0,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">
</span><span style=3D"color:rgb(102,0,102)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">Foo</span><span
style=3D"color:rgb(102,102,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">></span><span
style=3D"color:rgb(0,0,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">
</span><span style=3D"color:rgb(136,0,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">//
requires Same<Foo, foo></span><span
style=3D"color:rgb(0,0,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify"><br>
</span><span style=3D"color:rgb(0,0,136)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">class</span><span
style=3D"color:rgb(0,0,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">
basic_bar </span><span
style=3D"color:rgb(102,102,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">{</span><span
style=3D"color:rgb(0,0,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify"><br>
=C2=A0 =C2=A0 </span><span
style=3D"color:rgb(102,0,102)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">Foo</span><span
style=3D"color:rgb(0,0,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">
f</span><span style=3D"color:rgb(102,102,0)"
class=3D"gmail-m_-6314809214466867879styled-by-prettify">;</span><span
style=3D"color:rgb(0,0,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify"><br>
</span><span style=3D"color:rgb(102,102,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">};</span><span
style=3D"color:rgb(0,0,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify"><br>
<br>
</span><span style=3D"color:rgb(0,0,136)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">using</span><span
style=3D"color:rgb(0,0,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">
bar </span><span
style=3D"color:rgb(102,102,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">=3D</span><span
style=3D"color:rgb(0,0,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">
basic_bar</span><span
style=3D"color:rgb(0,136,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify"><foo></span><span
style=3D"color:rgb(102,102,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify">;</span><span
style=3D"color:rgb(0,0,0)"
class=3D"gmail-m_-6314809214466867879styled-b=
y-prettify"><br>
</span></blockquote>
</div>
</div>
</code></div>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(2=
04,204,204);padding-left:1ex">
<div bgcolor=3D"#FFFFFF"> <br>
I think it would be useful for large code bases
battling compile time to relax this restriction.
It would make any inline (generated or user
provided) function that requires offsets,
alignment, or sizes be ill-formed, but we are
already used to moving these functions
out-of-line, or defining them in places where the
full types are known.<br>
<br>
I think this is a relatively simple change for
compilers. The main drawback is that errors become
less clear, but the situation is so common that I
think it's worth it.</div>
</blockquote>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>Something that I didn't see mentioned is that every
time you need to declare a local variable in a function
you would need to transitively include all the headers.</di=
v>
<div><br>
</div>
<div>For example:</div>
<div><br>
</div>
<div>Foo.h: // define class Foo</div>
<div>class Foo { ... };</div>
<div><br>
</div>
<div>Bar.h: // does not include Foo.h</div>
<div>class Foo;</div>
<div>class Bar {=C2=A0</div>
<div>=C2=A0 Foo f;</div>
<div>};</div>
<div><br>
</div>
<div>FooBar.h:</div>
<div>class Bar;</div>
<div>class FooBar {</div>
<div>=C2=A0 Bar b;<br>
</div>
<div>=C2=A0 FooBar();</div>
<div>=C2=A0 ...</div>
<div>};</div>
<div><br>
</div>
<div>Some client of FooBar:</div>
<div><br>
</div>
<div>void fbar() {</div>
<div>=C2=A0 =C2=A0 =C2=A0// Need to know the size of FooBar, =
and thus Bar
and Foo as well</div>
<div>=C2=A0 =C2=A0 FooBar foobar;</div>
<div>}</div>
<div>=C2=A0</div>
<div>That means this consumer must include FooBar.h but
also Bar.h and FooBar.h. Also, adding a new member to
Foo requires to add a new include in a transitive
consumer (client of FooBar).</div>
<br>
</div>
</div>
</div>
</div>
<br>
</blockquote>
<p><br>
</p>
<p>Yes. This is meant for large types that are mostly passed around
by references, the top-level directories from where other
functionality is reached. Not for leaf types that are commonly
instantiated, as you'd need to #include everything anyway.<br>
</p>
<p><br>
</p>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ea64e17d-17b5-960e-fdd9-0b8427626ff4%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/ea64e17d-17b5-960e-fdd9-0b8427626f=
f4%40scylladb.com</a>.<br />
--------------1C1A5B9FFC50864861AE05E6--
.