Topic: Fornux C++ Superset - Forward Declarations of
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 1 May 2018 21:26:49 -0700
Raw View
--00000000000010e017056b3180f8
Content-Type: text/plain; charset="UTF-8"
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0289r0.pdf
The paper received some support from evolution. Some felt that the right
answer was to wait for Modules. As noted in the above paper there are some
open questions as to how this would actually work if we went forward with
it.
On 1 May 2018 at 19:26, Phil Bouchard <philippeb8@gmail.com> wrote:
> Greetings,
>
> In the development of the "Fornux C++ Superset" source-to-source compiler
> and its Open Source memory manager counterpart "root_ptr":
> https://github.com/philippeb8/root_ptr
>
> Like previously mentioned I noticed the following problems with the C++
> language:
> - There is no distinction between a pointer and an iterator.
> - There is no distinction between pointers to arrays of derived classes
> and pointers to arrays of base classes.
>
> But I just realized the following also:
> - The C++ language disallows top-level forward declarations of nested
> classes.
>
> The latter becomes a problem if you want to, for example, specialize
> metadata template classes. Ex:
>
> struct A
> {
> struct B
> {};
> };
>
> The transpiler will generate:
>
> struct A::B;
>
> namespace metadata
> {
> template <>
> struct construct<A::B>
> {
> template <typename... Args>
> A::B operator () (Args const &... args);
> };
> }
>
> But the problem is the following statement is not legal:
> struct A::B;
>
> So nested structures aren't commutative with template specializations
> which makes it impossible to generate metadata on-the-fly. The problem was
> always omnipresent but now it causes important problems in this case but
> also prevents further extensions of the language.
>
> It's just a matter of making C++ less strict in this case...
>
>
> Regards,
> -Phil
>
> --
> 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/cab4cada-1abe-48b2-
> 9a4b-d6c9f994b805%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cab4cada-1abe-48b2-9a4b-d6c9f994b805%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/CAOfiQqnoN-_KQ-AOTsAMCMnJK_nge1c59K0xOFy%2Bu0jQEtFnOw%40mail.gmail.com.
--00000000000010e017056b3180f8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">See <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs=
/papers/2016/p0289r0.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/paper=
s/2016/p0289r0.pdf</a><br><div><br></div><div>The paper received some suppo=
rt from evolution. Some felt that the right answer was to wait for Modules.=
As noted in the above paper there are some open questions as to how this w=
ould actually work if we went forward with it.</div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On 1 May 2018 at 19:26, Phil Bouch=
ard <span dir=3D"ltr"><<a href=3D"mailto:philippeb8@gmail.com" target=3D=
"_blank">philippeb8@gmail.com</a>></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">Greetings,<div><br></div><div>In the developmen=
t of the "Fornux C++ Superset" source-to-source compiler and its =
Open Source memory manager counterpart "root_ptr":</div><div><a h=
ref=3D"https://github.com/philippeb8/root_ptr" target=3D"_blank">https://gi=
thub.com/philippeb8/<wbr>root_ptr</a><br></div><div><br></div><div>Like pre=
viously mentioned I noticed the following problems with the C++ language:</=
div><div>- There is no distinction between a pointer and an iterator.</div>=
<div>- There is no distinction between pointers to arrays of derived classe=
s and pointers to arrays of base classes.</div><div><br></div><div>But I ju=
st realized the following also:</div><div>- The C++ language disallows top-=
level forward declarations of nested classes.</div><div><br></div><div>The =
latter becomes a problem if you want to, for example, specialize metadata t=
emplate classes. Ex:</div><div><br></div><div>struct A</div><div>{</div><di=
v>=C2=A0 =C2=A0 struct B</div><div>=C2=A0 =C2=A0 {};</div><div>};</div><div=
><br></div><div>The transpiler will generate:</div><div><br></div><div><div=
>struct A::B;</div><div><br></div><div>namespace metadata</div><div>{</div>=
<div>=C2=A0 =C2=A0 template <><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 struct construct<A::B></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 {</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 template <typename... =
Args></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
A::B operator () (Args const &... args);</div><div>=C2=A0 =C2=A0 =C2=A0=
=C2=A0 };<br></div><div>}</div></div><div><br></div><div>But the problem i=
s the following statement is not legal:</div><div>struct A::B;<br></div><di=
v><br></div><div>So nested structures aren't commutative with template =
specializations which makes it impossible to generate metadata on-the-fly. =
The problem was always omnipresent but now it causes important problems in =
this case but also prevents further extensions of the language.=C2=A0</div>=
<div><br></div><div>It's just a matter of making C++ less strict in thi=
s case...</div><div><br></div><div><br></div><div>Regards,</div><div>-Phil<=
/div></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cab4cada-1abe-48b2-9a4b-d6c9f994b805%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/cab4=
cada-1abe-48b2-<wbr>9a4b-d6c9f994b805%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnoN-_KQ-AOTsAMCMnJK_nge1c59K0x=
OFy%2Bu0jQEtFnOw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnoN-_KQ-=
AOTsAMCMnJK_nge1c59K0xOFy%2Bu0jQEtFnOw%40mail.gmail.com</a>.<br />
--00000000000010e017056b3180f8--
.
Author: Phil Bouchard <philippeb8@gmail.com>
Date: Wed, 2 May 2018 03:58:06 -0700 (PDT)
Raw View
------=_Part_28220_91832657.1525258686721
Content-Type: multipart/alternative;
boundary="----=_Part_28221_120839366.1525258686721"
------=_Part_28221_120839366.1525258686721
Content-Type: text/plain; charset="UTF-8"
On Wednesday, May 2, 2018 at 12:27:16 AM UTC-4, Richard Smith wrote:
>
> See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0289r0.pdf
>
> The paper received some support from evolution. Some felt that the right
> answer was to wait for Modules. As noted in the above paper there are some
> open questions as to how this would actually work if we went forward with
> it.
>
1) I personally would consider the possibility of declaring pointers of
nested classes based on the forward declaration of the aforementioned
nested class at all times. Ex.:
class X;
struct X::A;
X::A * p = nullptr; // fine
1.1)
class X
{
}; // error caught here: missing class A
1.2)
class X
{
struct A;
}; // error caught here: private member and already used as public
2) The same with template specializations:
class A;
struct A::B;
namespace metadata
{
template <>
struct construct<A::B>
{
template <typename... Args>
A::B operator () (Args const &... args); // fine
};
}
class A
{
struct B
{};
void foo()
{
metadata::construct<B>()(); // fine: but could only be instanciated
within this scope
}
};
So pointer usages and template declarations of that nested class in
question before its full declaration would have to be allowed. I would then
define these error checks as "consistency checks".
Regards,
-Phil
> On 1 May 2018 at 19:26, Phil Bouchard <phili...@gmail.com <javascript:>>
> wrote:
>
>> Greetings,
>>
>> In the development of the "Fornux C++ Superset" source-to-source compiler
>> and its Open Source memory manager counterpart "root_ptr":
>> https://github.com/philippeb8/root_ptr
>>
>> Like previously mentioned I noticed the following problems with the C++
>> language:
>> - There is no distinction between a pointer and an iterator.
>> - There is no distinction between pointers to arrays of derived classes
>> and pointers to arrays of base classes.
>>
>> But I just realized the following also:
>> - The C++ language disallows top-level forward declarations of nested
>> classes.
>>
>> The latter becomes a problem if you want to, for example, specialize
>> metadata template classes. Ex:
>>
>> struct A
>> {
>> struct B
>> {};
>> };
>>
>> The transpiler will generate:
>>
>> struct A::B;
>>
>> namespace metadata
>> {
>> template <>
>> struct construct<A::B>
>> {
>> template <typename... Args>
>> A::B operator () (Args const &... args);
>> };
>> }
>>
>> But the problem is the following statement is not legal:
>> struct A::B;
>>
>> So nested structures aren't commutative with template specializations
>> which makes it impossible to generate metadata on-the-fly. The problem was
>> always omnipresent but now it causes important problems in this case but
>> also prevents further extensions of the language.
>>
>> It's just a matter of making C++ less strict in this case...
>>
>>
>> Regards,
>> -Phil
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cab4cada-1abe-48b2-9a4b-d6c9f994b805%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cab4cada-1abe-48b2-9a4b-d6c9f994b805%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/34fa23ed-1fab-44d5-92ab-217067b68225%40isocpp.org.
------=_Part_28221_120839366.1525258686721
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, May 2, 2018 at 12:27:16 AM UTC-4, Ri=
chard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">See <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016=
/p0289r0.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0289r0.pdf\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNGqKyQh-vd7CE3Iii5tU442rLP0FQ';return true;" onclick=3D=
"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.=
org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0289r0.pdf\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNGqKyQh-vd7CE3Iii5tU442rLP0FQ';return true;">=
http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0289r0.p=
df</a><br><div><br></div><div>The paper received some support from evolutio=
n. Some felt that the right answer was to wait for Modules. As noted in the=
above paper there are some open questions as to how this would actually wo=
rk if we went forward with it.</div></div></blockquote><div><br></div><div>=
1) I personally would consider the possibility of declaring pointers of nes=
ted=C2=A0classes based on the forward declaration of the aforementioned nes=
ted class at all times. Ex.:</div><div><br></div><div>class X;</div><div>st=
ruct X::A;</div><div><br></div><div>X::A=C2=A0* p =3D nullptr; // fine</div=
><div><br></div><div>1.1)</div><div>class X</div><div>{</div><div>}; // err=
or=C2=A0caught here: missing class A</div><div><br></div><div>1.2)</div><di=
v>class X</div><div>{</div><div>=C2=A0 =C2=A0 struct A;</div><div>}; // err=
or caught here: private member and already used as public</div><div><br></d=
iv><div><br></div><div>2) The same with template specializations:</div><div=
><br></div><div><div>class A;</div><div>struct A::B;</div><div><br></div><d=
iv>namespace metadata</div><div>{</div><div>=C2=A0 =C2=A0 template <>=
<br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct construct<A::B></di=
v><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 template <typename... Args></div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A::B operator () (Args const &..=
.. args); // fine</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 };<br></div><div>}</=
div></div><div><br></div><div>class A</div><div>{</div><div>=C2=A0 =C2=A0 s=
truct B</div><div>=C2=A0 =C2=A0 {};</div><div><br></div><div><div>=C2=A0 =
=C2=A0 void foo()</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 metadata::construct<B>()(); // fine: but could only be instanc=
iated within this scope</div><div>=C2=A0 =C2=A0 }</div></div><div>};</div><=
div><br></div><div>So pointer usages and template declarations of that nest=
ed class in question before its full declaration would have to be allowed. =
I would then define these error checks as "consistency checks".</=
div><div><br></div><div><br></div><div>Regards,</div><div>-Phil</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><div class=3D=
"gmail_quote">On 1 May 2018 at 19:26, Phil Bouchard <span dir=3D"ltr"><<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"WP_WLmu6A=
wAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';retu=
rn true;" onclick=3D"this.href=3D'javascript:';return true;">phili.=
...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">Greetings,<div><br></div><div>In the development of the "Fo=
rnux C++ Superset" source-to-source compiler and its Open Source memor=
y manager counterpart "root_ptr":</div><div><a href=3D"https://gi=
thub.com/philippeb8/root_ptr" target=3D"_blank" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.=
com%2Fphilippeb8%2Froot_ptr\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHb1FJuN=
M2X9B4C97VwMmKzp-ZBYw';return true;" onclick=3D"this.href=3D'https:=
//www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fphilippeb8%2Froot_ptr\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHb1FJuNM2X9B4C97VwMmKzp-ZBYw';r=
eturn true;">https://github.com/philippeb8/<wbr>root_ptr</a><br></div><div>=
<br></div><div>Like previously mentioned I noticed the following problems w=
ith the C++ language:</div><div>- There is no distinction between a pointer=
and an iterator.</div><div>- There is no distinction between pointers to a=
rrays of derived classes and pointers to arrays of base classes.</div><div>=
<br></div><div>But I just realized the following also:</div><div>- The C++ =
language disallows top-level forward declarations of nested classes.</div><=
div><br></div><div>The latter becomes a problem if you want to, for example=
, specialize metadata template classes. Ex:</div><div><br></div><div>struct=
A</div><div>{</div><div>=C2=A0 =C2=A0 struct B</div><div>=C2=A0 =C2=A0 {};=
</div><div>};</div><div><br></div><div>The transpiler will generate:</div><=
div><br></div><div><div>struct A::B;</div><div><br></div><div>namespace met=
adata</div><div>{</div><div>=C2=A0 =C2=A0 template <><br></div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct construct<A::B></div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
template <typename... Args></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 A::B operator () (Args const &... args);</div>=
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 };<br></div><div>}</div></div><div><br></d=
iv><div>But the problem is the following statement is not legal:</div><div>=
struct A::B;<br></div><div><br></div><div>So nested structures aren't c=
ommutative with template specializations which makes it impossible to gener=
ate metadata on-the-fly. The problem was always omnipresent but now it caus=
es important problems in this case but also prevents further extensions of =
the language.=C2=A0</div><div><br></div><div>It's just a matter of maki=
ng C++ less strict in this case...</div><div><br></div><div><br></div><div>=
Regards,</div><div>-Phil</div></div><span><font color=3D"#888888">
<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
WP_WLmu6AwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"WP_WLmu6AwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/cab4cada-1abe-48b2-9a4b-d6c9f994b805%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/cab4cada-1abe-48b2-9a4b-d6c9f994b805%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/cab4cada-1abe-48b2-9a4b-d6c9f994b805%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/cab4cada-1abe-48b2-<wbr>9a4b-=
d6c9f994b805%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div>
</blockquote></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/34fa23ed-1fab-44d5-92ab-217067b68225%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/34fa23ed-1fab-44d5-92ab-217067b68225=
%40isocpp.org</a>.<br />
------=_Part_28221_120839366.1525258686721--
------=_Part_28220_91832657.1525258686721--
.
Author: Phil Bouchard <philippeb8@gmail.com>
Date: Wed, 2 May 2018 04:26:52 -0700 (PDT)
Raw View
------=_Part_27889_582949377.1525260412394
Content-Type: multipart/alternative;
boundary="----=_Part_27890_1897469063.1525260412394"
------=_Part_27890_1897469063.1525260412394
Content-Type: text/plain; charset="UTF-8"
On Wednesday, May 2, 2018 at 6:58:06 AM UTC-4, Phil Bouchard wrote:
>
>
>
> On Wednesday, May 2, 2018 at 12:27:16 AM UTC-4, Richard Smith wrote:
>>
>> See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0289r0.pdf
>>
>> The paper received some support from evolution. Some felt that the right
>> answer was to wait for Modules. As noted in the above paper there are some
>> open questions as to how this would actually work if we went forward with
>> it.
>>
>
> 1) I personally would consider the possibility of declaring pointers of
> nested classes based on the forward declaration of the aforementioned
> nested class at all times. Ex.:
>
> class X;
> struct X::A;
>
> X::A * p = nullptr; // fine
>
> 1.1)
> class X
> {
> }; // error caught here: missing class A
>
> 1.2)
> class X
> {
> struct A;
> }; // error caught here: private member and already used as public
>
Unless we bring the notion of "partial declarations" and forward
declarations of nested structures are made like this:
class X
{
struct A;
.... // ellipsis operator here
};
X::A * p = nullptr; // error
class X
{
struct A;
void foo()
{
X::A * p = nullptr; // fine
}
};
This way that would solve the access scope problem cleanly.
Regards,
-Phil
--
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/75fb8736-b92a-480f-9a36-310b3e03b131%40isocpp.org.
------=_Part_27890_1897469063.1525260412394
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, May 2, 2018 at 6:58:06 AM UTC-4, Phi=
l Bouchard wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><br><br>On Wednesday, May 2, 2018 at 12:27:16 AM UTC-4, Richard Smith w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">See <a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0289r0.pdf" re=
l=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fd=
ocs%2Fpapers%2F2016%2Fp0289r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG=
qKyQh-vd7CE3Iii5tU442rLP0FQ';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0289r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNGqKyQh-vd7CE3Iii5tU442rLP0FQ';return true;">http://www.open-st=
d.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0289r0.pdf</a><br><div><br=
></div><div>The paper received some support from evolution. Some felt that =
the right answer was to wait for Modules. As noted in the above paper there=
are some open questions as to how this would actually work if we went forw=
ard with it.</div></div></blockquote><div><br></div><div>1) I personally wo=
uld consider the possibility of declaring pointers of nested=C2=A0classes b=
ased on the forward declaration of the aforementioned nested class at all t=
imes. Ex.:</div><div><br></div><div>class X;</div><div>struct X::A;</div><d=
iv><br></div><div>X::A=C2=A0* p =3D nullptr; // fine</div><div><br></div><d=
iv>1.1)</div><div>class X</div><div>{</div><div>}; // error=C2=A0caught her=
e: missing class A</div><div><br></div><div>1.2)</div><div>class X</div><di=
v>{</div><div>=C2=A0 =C2=A0 struct A;</div><div>}; // error caught here: pr=
ivate member and already used as public</div></div></blockquote><div><br></=
div><div>Unless we bring the notion of "partial declarations" and=
forward declarations of nested structures are made like this:</div><div><b=
r></div><div>class X</div><div>{</div><div>=C2=A0 =C2=A0 struct A;</div><di=
v>=C2=A0 =C2=A0 .... // ellipsis operator here</div><div>};</div><div><br><=
/div><div><div>X::A=C2=A0* p =3D nullptr; // error</div></div><div><br></di=
v><div><div>class X</div><div>{</div><div>=C2=A0 =C2=A0 struct A;</div><div=
>=C2=A0 =C2=A0=C2=A0</div><div>=C2=A0 =C2=A0 void foo()</div><div>=C2=A0 =
=C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 X::A=C2=A0* p =3D nullptr; /=
/ fine</div><div>=C2=A0 =C2=A0 }</div><div>};</div></div><div><br></div><di=
v>This way that would solve the access scope problem cleanly.</div><div><br=
></div><div><br></div><div>Regards,</div><div>-Phil</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/75fb8736-b92a-480f-9a36-310b3e03b131%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/75fb8736-b92a-480f-9a36-310b3e03b131=
%40isocpp.org</a>.<br />
------=_Part_27890_1897469063.1525260412394--
------=_Part_27889_582949377.1525260412394--
.
Author: Phil Bouchard <philippeb8@gmail.com>
Date: Thu, 10 May 2018 19:03:25 -0400
Raw View
On 05/02/2018 07:26 AM, Phil Bouchard wrote:
> Unless we bring the notion of "partial declarations" and forward=20
> declarations of nested structures are made like this:
>=20
> class X
> {
> =C2=A0 =C2=A0 struct A;
> =C2=A0 =C2=A0 .... // ellipsis operator here
> };
>=20
> X::A=C2=A0* p =3D nullptr; // error
>=20
> class X
> {
> =C2=A0 =C2=A0 struct A;
> =C2=A0 =C2=A0 void foo()
> =C2=A0 =C2=A0 {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 X::A=C2=A0* p =3D nullptr; // fine
> =C2=A0 =C2=A0 }
> };
>=20
> This way that would solve the access scope problem cleanly.
Do we all agree this is a good solution? This could provide friend=20
declarations as well:
class X
{
friend struct A;
struct A;
.... // ellipsis operator here
};
Regards,
-Phil
--=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/pd2ivq%24saf%241%40blaine.gmane.org.
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Fri, 11 May 2018 07:30:34 -0700 (PDT)
Raw View
------=_Part_10214_285001668.1526049034592
Content-Type: multipart/alternative;
boundary="----=_Part_10215_1712949569.1526049034593"
------=_Part_10215_1712949569.1526049034593
Content-Type: text/plain; charset="UTF-8"
I'm skeptical to partial declarations as the rules would be quite
complicated. What I have found lacking on various occasions is the ability
to declare inheritance in a forward declaration. Being able to declare
inheritance relations early reduces the need of moving method
implementations of methods out of the class head in certain situations.
When it comes to friend declarations it seems that you would not be helped
by including them in a forward declaration as their sole purpose is to
allow access to private members _which have not been declared yet_.
I would favor a proposal which includes your initial possibility to declare
a nested class after declaring the outer class (or for consistence with
namespace A::B { ... } without having to do so) plus the possibility to
declare inheritance in a forward declaration.
Den fredag 11 maj 2018 kl. 01:03:36 UTC+2 skrev Phil Bouchard:
>
> On 05/02/2018 07:26 AM, Phil Bouchard wrote:
> > Unless we bring the notion of "partial declarations" and forward
> > declarations of nested structures are made like this:
> >
> > class X
> > {
> > struct A;
> > .... // ellipsis operator here
> > };
> >
> > X::A * p = nullptr; // error
> >
> > class X
> > {
> > struct A;
> > void foo()
> > {
> > X::A * p = nullptr; // fine
> > }
> > };
> >
> > This way that would solve the access scope problem cleanly.
>
> Do we all agree this is a good solution? This could provide friend
> declarations as well:
>
> class X
> {
> friend struct A;
>
> struct A;
> .... // ellipsis operator here
> };
>
>
> Regards,
> -Phil
>
>
--
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/228ebe66-fa3d-40e8-a42f-37de41834977%40isocpp.org.
------=_Part_10215_1712949569.1526049034593
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm skeptical to partial declarations as the rules wou=
ld be quite complicated. What I have found lacking on various occasions is =
the ability to declare inheritance in a forward declaration. Being able to =
declare inheritance relations early reduces the need of moving method imple=
mentations of methods out of the class head in certain situations.<div><br>=
</div><div>When it comes to friend declarations it seems that you would not=
be helped by including them in a forward declaration as their sole purpose=
is to allow access to private members _which have not been declared yet_.<=
/div><div><br></div><div>I would favor a proposal which includes your initi=
al possibility to declare a nested class after declaring the outer class (o=
r for consistence with namespace A::B { ... } without having to do so) plus=
the possibility to declare inheritance in a forward declaration.</div><div=
><br><br>Den fredag 11 maj 2018 kl. 01:03:36 UTC+2 skrev Phil Bouchard:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">On 05/02/2018 07:26 AM, Phil Bouch=
ard wrote:
<br>> Unless we bring the notion of "partial declarations" and=
forward=20
<br>> declarations of nested structures are made like this:
<br>>=20
<br>> class X
<br>> {
<br>> =C2=A0=C2=A0 =C2=A0 struct A;
<br>> =C2=A0=C2=A0 =C2=A0 .... // ellipsis operator here
<br>> };
<br>>=20
<br>> X::A=C2=A0* p =3D nullptr; // error
<br>>=20
<br>> class X
<br>> {
<br>> =C2=A0=C2=A0 =C2=A0 struct A;
<br>> =C2=A0=C2=A0 =C2=A0 void foo()
<br>> =C2=A0=C2=A0 =C2=A0 {
<br>> =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 X::A=C2=A0* p =3D nullptr; // fi=
ne
<br>> =C2=A0=C2=A0 =C2=A0 }
<br>> };
<br>>=20
<br>> This way that would solve the access scope problem cleanly.
<br>
<br>Do we all agree this is a good solution? This could provide friend=20
<br>declarations as well:
<br>
<br>class X
<br>{
<br>=C2=A0 =C2=A0 =C2=A0 friend struct A;
<br>
<br>=C2=A0 =C2=A0 =C2=A0 struct A;
<br>=C2=A0 =C2=A0 =C2=A0 .... // ellipsis operator here
<br>};
<br>
<br>
<br>Regards,
<br>-Phil
<br>
<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/228ebe66-fa3d-40e8-a42f-37de41834977%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/228ebe66-fa3d-40e8-a42f-37de41834977=
%40isocpp.org</a>.<br />
------=_Part_10215_1712949569.1526049034593--
------=_Part_10214_285001668.1526049034592--
.
Author: Phil Bouchard <philippeb8@gmail.com>
Date: Fri, 11 May 2018 17:48:54 +0000 (UTC)
Raw View
Bengt Gustafsson <bengt.gustafsson@beamways.com> wrote:
> I'm skeptical to partial declarations as the rules would be quite=20
> complicated. What I have found lacking on various occasions is the abilit=
y=20
> to declare inheritance in a forward declaration. Being able to declare=20
> inheritance relations early reduces the need of moving method=20
> implementations of methods out of the class head in certain situations.
>=20
> When it comes to friend declarations it seems that you would not be helpe=
d=20
> by including them in a forward declaration as their sole purpose is to=20
> allow access to private members _which have not been declared yet_.
>=20
> I would favor a proposal which includes your initial possibility to decla=
re=20
> a nested class after declaring the outer class (or for consistence with=
=20
> namespace A::B { ... } without having to do so) plus the possibility to=
=20
> declare inheritance in a forward declaration.
Ok so let=E2=80=99s forget about partial declarations and consider consiste=
ncy
checks.
But regarding inheritance; there would be no way to see if classes are
virtual or not without their members. This would prevent us from using
dynamic_cast on pointers. Ex.:
struct Y;
struct X : Y;
Y * p =3D nullptr; // fine
X * q =3D dynamic_cast<X *>(p); // error
This might be an obscur use case but worth mentioning.
Regards,
-Phil
--=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/pd4l26%244bv%241%40blaine.gmane.org.
.