Topic: Proposal: Private extension methods
Author: fmatthew5876@gmail.com
Date: Mon, 9 Dec 2013 18:20:46 -0800 (PST)
Raw View
------=_Part_3321_30072482.1386642046895
Content-Type: text/plain; charset=ISO-8859-1
Hello everyone, I am going to submit a proposal for relaxing the
restriction on requiring private non-virtual class methods and static
private class methods to be declared in the class definition.
The github repository with the current draft of the proposal is here:
https://github.com/fmatthew5876/stdcxx-privext
The proposal came out of the discussion from this thread:
https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4NBUJ
--
---
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_3321_30072482.1386642046895
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><span style=3D"font-size: 13px;">Hello everyone, I am=
going to submit a proposal for relaxing the restriction on requiring priva=
te non-virtual class methods and static private class methods to be declare=
d in the class definition.</span><br></div><div><br></div><div>The github r=
epository with the current draft of the proposal is here:</div><div><a href=
=3D"https://github.com/fmatthew5876/stdcxx-privext">https://github.com/fmat=
thew5876/stdcxx-privext</a><br></div><div><br></div><div>The proposal came =
out of the discussion from this thread:<div><a href=3D"https://groups.googl=
e.com/a/isocpp.org/forum/#!searchin/std-proposals/private/std-proposals/xuk=
d1mgd21I/akgZSTG4NBUJ">https://groups.google.com/a/isocpp.org/forum/#!searc=
hin/std-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4NBUJ</a><br></d=
iv></div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_3321_30072482.1386642046895--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Mon, 9 Dec 2013 19:26:26 -0800 (PST)
Raw View
------=_Part_57_6428257.1386645986683
Content-Type: text/plain; charset=ISO-8859-1
Hi Matthew,
I did briefly read your proposal.
You touch on this a little in your proposal, but just to be clear 9.4p5
[class.static]:
> When used in the declaration of a class member, the static specifier
shall only be used in the member declarations that appear within the
member-specification of the class definition.
So this is currently ill-formed:
struct X
{
void f();
};
static void X::f() {} // ERROR
This frees the static specifier up to be used to specify a static member
function if that is what you want. There is no ambiguity with the internal
linkage meaning on a free function. In the event someone accidentally
places static in front of a private extension method, intending internal
linkage but getting a static member function, then the only effect is a
compile-time error when they try to access the implicit object parameter
that doesn't exist. It isn't dangerous.
You might also want to consider giving private extension methods implicit
internal linkage (both static and non-static member functions), the only
use case I can imagine is placing them in the .cpp so the linker doesn't
even need to see the symbol, and if you really do want them to have
external linkage you can always declare them in the class specifier as
normal.
Your proposal breaks a current rule that a qualified declarator id has to
be declared unqualified previously in the TU. This might cause a minor
hassle to implementors with name lookup on declarator ids during parsing.
I think the main resistance you will receive is from people that claim that
this would break encapsulation. Currently the only entities that can
access private members are all declared in the class specifier (either as
members or friends). Some will claim that this is a nice property for
programming in the large, as you can isolate what can be messing with
private data to a list of possible culprits all in one place. A private
extension method, on the other hand, can be declared anywhere in the
codebase. I'm however on your side fwiw, and think that having private
member functions not cluttering the class specifier outweighs the loss.
Also you might want to spend some time studying the interaction with
template classes. I assume you can also define private extension methods
of template classes too? How will they interact with
specialization/instantiation?
Good luck,
Andrew.
On Tuesday, December 10, 2013 3:20:46 AM UTC+1, fmatth...@gmail.com wrote:
>
> Hello everyone, I am going to submit a proposal for relaxing the
> restriction on requiring private non-virtual class methods and static
> private class methods to be declared in the class definition.
>
> The github repository with the current draft of the proposal is here:
> https://github.com/fmatthew5876/stdcxx-privext
>
> The proposal came out of the discussion from this thread:
>
> https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4NBUJ
>
>
--
---
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_57_6428257.1386645986683
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Matthew,<div><br></div><div>I did briefly read your pro=
posal.</div><div><br></div><div>You touch on this a little in your proposal=
, but just to be clear 9.4p5 [class.static]:<div><br></div><div><div>> W=
hen used in the declaration of a class member, the static specifier shall o=
nly be used in the member declarations that appear within the member-specif=
ication of the class definition.</div><div><br></div><div>So this is curren=
tly ill-formed:</div><div><br></div><div>struct X</div><div>{</div><div>&nb=
sp; void f();</div><div>};</div><div><br></div><div>static void X::f=
() {} // ERROR</div><div><br></div><div>This frees the static specifier up =
to be used to specify a static member function if that is what you want. &n=
bsp;There is no ambiguity with the internal linkage meaning on a free funct=
ion. In the event someone accidentally places static in front of a pr=
ivate extension method, intending internal linkage but getting a static mem=
ber function, then the only effect is a compile-time error when they try to=
access the implicit object parameter that doesn't exist. It isn't da=
ngerous.</div><div><br></div><div>You might also want to consider giving pr=
ivate extension methods implicit internal linkage (both static and non-stat=
ic member functions), the only use case I can imagine is placing them in th=
e .cpp so the linker doesn't even need to see the symbol, and if you really=
do want them to have external linkage you can always declare them in the c=
lass specifier as normal.</div><div><br></div><div>Your proposal breaks a c=
urrent rule that a qualified declarator id has to be declared unqualified p=
reviously in the TU. This might cause a minor hassle to implementors =
with name lookup on declarator ids during parsing.</div><div><br></div><div=
>I think the main resistance you will receive is from people that claim tha=
t this would break encapsulation. Currently the only entities that ca=
n access private members are all declared in the class specifier (either as=
members or friends). Some will claim that this is a nice property fo=
r programming in the large, as you can isolate what can be messing with pri=
vate data to a list of possible culprits all in one place. A private =
extension method, on the other hand, can be declared anywhere in the codeba=
se. I'm however on your side fwiw, and think that having private memb=
er functions not cluttering the class specifier outweighs the loss.</div><d=
iv><br></div><div>Also you might want to spend some time studying the inter=
action with template classes. I assume you can also define private ex=
tension methods of template classes too? How will they interact with =
specialization/instantiation?</div><div><br></div><div>Good luck,</div><div=
>Andrew.<br></div><div><br></div><br>On Tuesday, December 10, 2013 3:20:46 =
AM UTC+1, fmatth...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><span style=3D"font-size:13px">Hello everyone, =
I am going to submit a proposal for relaxing the restriction on requiring p=
rivate non-virtual class methods and static private class methods to be dec=
lared in the class definition.</span><br></div><div><br></div><div>The gith=
ub repository with the current draft of the proposal is here:</div><div><a =
href=3D"https://github.com/fmatthew5876/stdcxx-privext" target=3D"_blank" o=
nmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgit=
hub.com%2Ffmatthew5876%2Fstdcxx-privext\46sa\75D\46sntz\0751\46usg\75AFQjCN=
HUdaGAiICCLmRPFXPiWoor3W2hjA';return true;" onclick=3D"this.href=3D'https:/=
/www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-pr=
ivext\46sa\75D\46sntz\0751\46usg\75AFQjCNHUdaGAiICCLmRPFXPiWoor3W2hjA';retu=
rn true;">https://github.com/<wbr>fmatthew5876/stdcxx-privext</a><br></div>=
<div><br></div><div>The proposal came out of the discussion from this threa=
d:<div><a href=3D"https://groups.google.com/a/isocpp.org/forum/#!searchin/s=
td-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4NBUJ" target=3D"_bla=
nk" onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/foru=
m/#!searchin/std-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4NBUJ';=
return true;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.or=
g/forum/#!searchin/std-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4=
NBUJ';return true;">https://groups.google.com/a/<wbr>isocpp.org/forum/#!sea=
rchin/<wbr>std-proposals/private/std-<wbr>proposals/xukd1mgd21I/<wbr>akgZST=
G4NBUJ</a><br></div></div><div><br></div></div></blockquote></div></div></d=
iv>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_57_6428257.1386645986683--
.
Author: fmatthew5876@gmail.com
Date: Mon, 9 Dec 2013 19:57:26 -0800 (PST)
Raw View
------=_Part_3495_21731866.1386647846260
Content-Type: text/plain; charset=ISO-8859-1
On Monday, December 9, 2013 10:26:26 PM UTC-5, Andrew Tomazos wrote:
>
> Hi Matthew,
>
> I did briefly read your proposal.
>
> You touch on this a little in your proposal, but just to be clear 9.4p5
> [class.static]:
>
> > When used in the declaration of a class member, the static specifier
> shall only be used in the member declarations that appear within the
> member-specification of the class definition.
>
> So this is currently ill-formed:
>
> struct X
> {
> void f();
> };
>
> static void X::f() {} // ERROR
>
> This frees the static specifier up to be used to specify a static member
> function if that is what you want. There is no ambiguity with the internal
> linkage meaning on a free function. In the event someone accidentally
> places static in front of a private extension method, intending internal
> linkage but getting a static member function, then the only effect is a
> compile-time error when they try to access the implicit object parameter
> that doesn't exist. It isn't dangerous.
>
True, but then we are unable to use the static keyword to specify internal
linkage for private extension methods. We will be forced to use an
anonymous namespace. I usually prefer the static keyword for file scope
functions to anonymous namespaces as it avoids an extra scope, but that's
minor style point. Making the static prefix indicate a static method is the
path of least resistance and I'd be happy go that way should the committee
prefer that direction.
>
> You might also want to consider giving private extension methods implicit
> internal linkage (both static and non-static member functions), the only
> use case I can imagine is placing them in the .cpp so the linker doesn't
> even need to see the symbol, and if you really do want them to have
> external linkage you can always declare them in the class specifier as
> normal.
>
Not sure I agree here. I have had plenty of situations where my class is
implemented in multiple .cc files. In these situations, you may want to
declare one or more private extension methods in an internal header use
them in multiple translation units. You can also
declare extension methods directly in the public header file if you want to
access them from inlined public/protected methods.
>
> Your proposal breaks a current rule that a qualified declarator id has to
> be declared unqualified previously in the TU. This might cause a minor
> hassle to implementors with name lookup on declarator ids during parsing.
>
> If necessary, I'd be happy to consider writing a reference implementation
patchfor clang and/or gcc to show feasibility. I'm no compiler writer but
it seems to me that this should not be a difficult feature to implement.
> I think the main resistance you will receive is from people that claim
> that this would break encapsulation.
>
Indeed, I've taken great pains to show that this feature does in fact not
break encapsulation in order to counter that
argument. In fact I argue it even strengthens encapsulation because it
removes unnecessary details from the class interface.
> Currently the only entities that can access private members are all
> declared in the class specifier (either as members or friends). Some will
> claim that this is a nice property for programming in the large, as you can
> isolate what can be messing with private data to a list of possible
> culprits all in one place.
>
I find this to be more restrictive then helpful. Procedural C APIs can be
implemented with multiple functions under the hood, why not allow the same
for C++ object oriented APIs? It seems like we just have this arbitrary
rule that restricts the number of functions we are allow to use to
implement our class behavior.
> A private extension method, on the other hand, can be declared anywhere in
> the codebase. I'm however on your side fwiw, and think that having private
> member functions not cluttering the class specifier outweighs the loss.
>
Also you might want to spend some time studying the interaction with
> template classes. I assume you can also define private extension methods
> of template classes too? How will they interact with
> specialization/instantiation?
>
Yes templates will be supported. One should be able to specialize using a
syntax like the following:
template <typename T>
class Foo {
};
//A private extension method only for specialized Foo<int>
template <>
Foo<int>::_f() {
}
Thanks for mentioning this. Its a good point which needs to be analyzed and
addressed. I will add a section for it.
>
> Good luck,
> Andrew.
>
>
Thank you for your feedback, much appreciated!
>
> On Tuesday, December 10, 2013 3:20:46 AM UTC+1, fmatth...@gmail.com wrote:
>>
>> Hello everyone, I am going to submit a proposal for relaxing the
>> restriction on requiring private non-virtual class methods and static
>> private class methods to be declared in the class definition.
>>
>> The github repository with the current draft of the proposal is here:
>> https://github.com/fmatthew5876/stdcxx-privext
>>
>> The proposal came out of the discussion from this thread:
>>
>> https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4NBUJ
>>
>>
--
---
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_3495_21731866.1386647846260
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, December 9, 2013 10:26:26 PM UTC-5, And=
rew Tomazos 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">Hi Matthew,<div><br></div><div>I did briefly read your proposal.</div>=
<div><br></div><div>You touch on this a little in your proposal, but just t=
o be clear 9.4p5 [class.static]:<div><br></div><div><div>> When used in =
the declaration of a class member, the static specifier shall only be used =
in the member declarations that appear within the member-specification of t=
he class definition.</div><div><br></div><div>So this is currently ill-form=
ed:</div><div><br></div><div>struct X</div><div>{</div><div> v=
oid f();</div><div>};</div><div><br></div><div>static void X::f() {} // ERR=
OR</div><div><br></div><div>This frees the static specifier up to be used t=
o specify a static member function if that is what you want. There is=
no ambiguity with the internal linkage meaning on a free function. I=
n the event someone accidentally places static in front of a private extens=
ion method, intending internal linkage but getting a static member function=
, then the only effect is a compile-time error when they try to access the =
implicit object parameter that doesn't exist. It isn't dangerous.</di=
v></div></div></div></blockquote><div><br></div><div>True, but then we are =
unable to use the static keyword to specify internal linkage for private ex=
tension methods. We will be forced to use an anonymous namespace. I usually=
prefer the static keyword for file scope functions to anonymous namespaces=
as it avoids an extra scope, but that's minor style point. Making the stat=
ic prefix indicate a static method is the path of least resistance and I'd =
be happy go that way should the committee prefer that direction.</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><div><br=
></div><div>You might also want to consider giving private extension method=
s implicit internal linkage (both static and non-static member functions), =
the only use case I can imagine is placing them in the .cpp so the linker d=
oesn't even need to see the symbol, and if you really do want them to have =
external linkage you can always declare them in the class specifier as norm=
al.</div></div></div></div></blockquote><div><br></div><div>Not sure I agre=
e here. I have had plenty of situations where my class is implemented in mu=
ltiple .cc files. In these situations, you may want to declare one or more =
private extension methods in an internal header use them in multiple transl=
ation units. You can also</div><div>declare extension methods directly in t=
he public header file if you want to access them from inlined public/protec=
ted methods.</div><div> </div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><div><div><br></div><div>Your proposal breaks a=
current rule that a qualified declarator id has to be declared unqualified=
previously in the TU. This might cause a minor hassle to implementor=
s with name lookup on declarator ids during parsing.</div><div><br></div></=
div></div></div></blockquote><div>If necessary, I'd be happy to consider wr=
iting a reference implementation patchfor clang and/or gcc to show feasibil=
ity. I'm no compiler writer but it seems to me that this should not be a di=
fficult feature to implement.</div><div> </div><div> </div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><div></di=
v><div>I think the main resistance you will receive is from people that cla=
im that this would break encapsulation. </div></div></div></div></blo=
ckquote><div><br></div><div>Indeed, I've taken great pains to show that thi=
s feature does in fact not break encapsulation in order to counter that</di=
v><div>argument. In fact I argue it even strengthens encapsulation because =
it removes unnecessary details from the class interface.</div><div> </=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div=
><div>Currently the only entities that can access private members are all d=
eclared in the class specifier (either as members or friends). Some w=
ill claim that this is a nice property for programming in the large, as you=
can isolate what can be messing with private data to a list of possible cu=
lprits all in one place. </div></div></div></div></blockquote><div><b=
r></div><div>I find this to be more restrictive then helpful. Procedural C =
APIs can be implemented with multiple functions under the hood, why not all=
ow the same for C++ object oriented APIs? It seems like we just have this a=
rbitrary rule that restricts the number of functions we are allow to use to=
implement our class behavior.</div><div> </div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div><div><div>A private extension =
method, on the other hand, can be declared anywhere in the codebase. =
I'm however on your side fwiw, and think that having private member functio=
ns not cluttering the class specifier outweighs the loss.</div></div></div>=
</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div><div>Also you might want to spend some time studying the in=
teraction with template classes. I assume you can also define private=
extension methods of template classes too? How will they interact wi=
th specialization/instantiation?</div></div></div></div></blockquote><div><=
br></div><div>Yes templates will be supported. One should be able to specia=
lize using a syntax like the following:</div><div><br></div><div>template &=
lt;typename T></div><div>class Foo {<br>};</div><div><br></div><div>//A =
private extension method only for specialized Foo<int></div><div>temp=
late <><br>Foo<int>::_f() {<br>}</div><div><br></div><div>Thank=
s for mentioning this. Its a good point which needs to be analyzed and addr=
essed. I will add a section for it.</div><div> </div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><div><br></div><div>=
Good luck,</div><div>Andrew.<br></div><div><br></div></div></div></div></bl=
ockquote><div><br></div><div>Thank you for your feedback, much appreciated!=
</div><div> </div><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"><div><div><div></div><br>On Tuesday, December 10, 2013 3:20:46 AM=
UTC+1, <a>fmatth...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div><span style=3D"font-size:13px">Hello everyone, =
I am going to submit a proposal for relaxing the restriction on requiring p=
rivate non-virtual class methods and static private class methods to be dec=
lared in the class definition.</span><br></div><div><br></div><div>The gith=
ub repository with the current draft of the proposal is here:</div><div><a =
href=3D"https://github.com/fmatthew5876/stdcxx-privext" target=3D"_blank" o=
nmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgit=
hub.com%2Ffmatthew5876%2Fstdcxx-privext\46sa\75D\46sntz\0751\46usg\75AFQjCN=
HUdaGAiICCLmRPFXPiWoor3W2hjA';return true;" onclick=3D"this.href=3D'https:/=
/www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-pr=
ivext\46sa\75D\46sntz\0751\46usg\75AFQjCNHUdaGAiICCLmRPFXPiWoor3W2hjA';retu=
rn true;">https://github.com/<wbr>fmatthew5876/stdcxx-privext</a><br></div>=
<div><br></div><div>The proposal came out of the discussion from this threa=
d:<div><a href=3D"https://groups.google.com/a/isocpp.org/forum/#!searchin/s=
td-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4NBUJ" target=3D"_bla=
nk" onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/foru=
m/#!searchin/std-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4NBUJ';=
return true;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.or=
g/forum/#!searchin/std-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4=
NBUJ';return true;">https://groups.google.com/a/<wbr>isocpp.org/forum/#!sea=
rchin/<wbr>std-proposals/private/std-<wbr>proposals/xukd1mgd21I/<wbr>akgZST=
G4NBUJ</a><br></div></div><div><br></div></div></blockquote></div></div></d=
iv></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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_3495_21731866.1386647846260--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Tue, 10 Dec 2013 06:46:06 +0100
Raw View
On Mon, 2013-12-09 at 18:20 -0800, fmatthew5876@gmail.com wrote:
> Hello everyone, I am going to submit a proposal for relaxing the
> restriction on requiring private non-virtual class methods and static
> private class methods to be declared in the class definition.
>
> The github repository with the current draft of the proposal is here:
> https://github.com/fmatthew5876/stdcxx-privext
How does this interact with overload resolution?
Consider the following:
---vvv--- foo.hh ---vvv---
class foo {
public:
void bar() { gaz(17); }
void gaz(long);
private:
some_type secret;
};
foo getAFoo();
---^^^--- foo.hh ---^^^---
and
---vvv--- evil.cc ---vvv---
#include "foo.hh"
void doTheDeed(some_type&);
void foo::gaz(int i)
{
doTheDeed(secret);
}
void doEvil() { getAFoo().bar(); }
---^^^--- evil.cc ---^^^---
Does a call to doEvil() result in a call to gaz(long) or gaz(int)?
I would also like to ask if I understand you correctly in that you are
suggesting to allow
#include "foo.hh"
namespace {
void foo::gazonk() { /* something */ }
}
and here foo::gazonk is a private member of foo?
/MF
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: fmatthew5876@gmail.com
Date: Tue, 10 Dec 2013 05:16:36 -0800 (PST)
Raw View
------=_Part_139_29640301.1386681396105
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, December 10, 2013 12:46:06 AM UTC-5, Magnus Fromreide wrote:
>
> On Mon, 2013-12-09 at 18:20 -0800, fmatth...@gmail.com <javascript:>wrote:
> > Hello everyone, I am going to submit a proposal for relaxing the
> > restriction on requiring private non-virtual class methods and static
> > private class methods to be declared in the class definition.
> >
> > The github repository with the current draft of the proposal is here:
> > https://github.com/fmatthew5876/stdcxx-privext
>
> How does this interact with overload resolution?
> Consider the following:
>
> ---vvv--- foo.hh ---vvv---
> class foo {
> public:
> void bar() { gaz(17); }
> void gaz(long);
> private:
> some_type secret;
> };
>
> foo getAFoo();
> ---^^^--- foo.hh ---^^^---
> and
> ---vvv--- evil.cc ---vvv---
> #include "foo.hh"
>
> void doTheDeed(some_type&);
>
> void foo::gaz(int i)
> {
> doTheDeed(secret);
> }
>
> void doEvil() { getAFoo().bar(); }
> ---^^^--- evil.cc ---^^^---
>
> Does a call to doEvil() result in a call to gaz(long) or gaz(int)?
>
> It should call gaz(long), because that is what was visible at the time
foo() was inlined.
Its the same as this:
void gaz(long);
void foo() { gaz(17); {
void gaz(int);
I'll add a section talking about overloading.
>
> I would also like to ask if I understand you correctly in that you are
> suggesting to allow
>
> #include "foo.hh"
> namespace {
> void foo::gazonk() { /* something */ }
> }
>
> and here foo::gazonk is a private member of foo?
>
That's right, although it does seem kind of wierd because any foo member
function should be in the same namespace as foo. This would require a
special exception for anonymous name spaces. Internal linkage is a very
important feature I want to be sure to enable. In order to do that we need
either the static keyword or anonymous namespace support.
>
> /MF
>
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_139_29640301.1386681396105
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, December 10, 2013 12:46:06 AM UTC-5, M=
agnus Fromreide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon, =
2013-12-09 at 18:20 -0800, <a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"uI5yaNef_vgJ" onmousedown=3D"this.href=3D'javascript:';r=
eturn true;" onclick=3D"this.href=3D'javascript:';return true;">fmatth...@g=
mail.com</a> wrote:
<br>> Hello everyone, I am going to submit a proposal for relaxing the
<br>> restriction on requiring private non-virtual class methods and sta=
tic
<br>> private class methods to be declared in the class definition.
<br>>=20
<br>> The github repository with the current draft of the proposal is he=
re:
<br>> <a href=3D"https://github.com/fmatthew5876/stdcxx-privext" target=
=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75http=
s%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-privext\46sa\75D\46sntz\0751\4=
6usg\75AFQjCNHUdaGAiICCLmRPFXPiWoor3W2hjA';return true;" onclick=3D"this.hr=
ef=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ffmatthew587=
6%2Fstdcxx-privext\46sa\75D\46sntz\0751\46usg\75AFQjCNHUdaGAiICCLmRPFXPiWoo=
r3W2hjA';return true;">https://github.com/<wbr>fmatthew5876/stdcxx-privext<=
/a>
<br>
<br>How does this interact with overload resolution?
<br>Consider the following:
<br>
<br>---vvv--- foo.hh ---vvv---
<br>class foo {
<br>public:
<br> void bar() { gaz(17); }
<br> void gaz(long);
<br>private:
<br> some_type secret;
<br>};
<br>
<br>foo getAFoo();
<br>---^^^--- foo.hh ---^^^---
<br>and
<br>---vvv--- evil.cc ---vvv---
<br>#include "foo.hh"
<br>
<br>void doTheDeed(some_type&);
<br>
<br>void foo::gaz(int i)
<br>{
<br> doTheDeed(secret);
<br>}
<br>
<br>void doEvil() { getAFoo().bar(); }
<br>---^^^--- evil.cc ---^^^---
<br>
<br>Does a call to doEvil() result in a call to gaz(long) or gaz(int)?
<br>
<br></blockquote><div>It should call gaz(long), because that is what was vi=
sible at the time foo() was inlined.</div><div><br></div><div>Its the same =
as this:</div><div><br></div><div>void gaz(long);</div><div><br></div><div>=
void foo() { gaz(17); {</div><div><br></div><div>void gaz(int);</div><div><=
br></div><div>I'll add a section talking about overloading.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>
<br>I would also like to ask if I understand you correctly in that you are
<br>suggesting to allow
<br>
<br>#include "foo.hh"
<br>namespace {
<br> void foo::gazonk() { /* something */ }
<br>}
<br>
<br>and here foo::gazonk is a private member of foo?
<br></blockquote><div><br></div><div>That's right, although it does seem ki=
nd of wierd because any foo member function should be in the same namespace=
as foo. This would require a special exception for anonymous name spaces. =
Internal linkage is a very important feature I want to be sure to enable. I=
n order to do that we need either the static keyword or anonymous namespace=
support.</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>/MF
<br>
<br>
<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_139_29640301.1386681396105--
.
Author: cornedbee@google.com
Date: Tue, 10 Dec 2013 07:17:29 -0800 (PST)
Raw View
------=_Part_230_31250092.1386688649981
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, December 10, 2013 3:20:46 AM UTC+1, fmatth...@gmail.com wrote:
>
> Hello everyone, I am going to submit a proposal for relaxing the
> restriction on requiring private non-virtual class methods and static
> private class methods to be declared in the class definition.
>
> The github repository with the current draft of the proposal is here:
> https://github.com/fmatthew5876/stdcxx-privext
>
>
Hi,
I love this proposal and wanted to do pretty much the same thing for some
time.
In "Alternate Syntax", you say: "One downside of the current approach is
that previously if the user wrote a typo when writing a member function
name in the definition they would get a helpful compilation error."
In my opinion, this is a deal breaker. I think it's absolutely necessary to
use a keyword for this, and I strongly recommend using 'private'. I
consider the objection that this will confuse people to be weak; compilers
can easily be taught to acknowledge the syntax with more than an
"unexpected 'public'" and say something like "only private member functions
can be declared outside the class". If a user is still curious as to why
that is so, StackOverflow or std-discussion will readily supply the
necessary "Because it breaks encapsulation" answer.
On a side note, if you want some evidence for the value of this proposal,
you should check out the Sema implementation of Clang. There's lots of
static helper functions in the implementation files, they all get passed
the Sema object, and quite a few of them should have been private members,
because they force Sema members to be public that shouldn't have been.
--
---
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_230_31250092.1386688649981
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, December 10, 2013 3:20:46 AM UTC+1, fm=
atth...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div><span style=3D"font-size:13px">Hello everyone, I am going t=
o submit a proposal for relaxing the restriction on requiring private non-v=
irtual class methods and static private class methods to be declared in the=
class definition.</span><br></div><div><br></div><div>The github repositor=
y with the current draft of the proposal is here:</div><div><a href=3D"http=
s://github.com/fmatthew5876/stdcxx-privext" target=3D"_blank" onmousedown=
=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2F=
fmatthew5876%2Fstdcxx-privext\46sa\75D\46sntz\0751\46usg\75AFQjCNHUdaGAiICC=
LmRPFXPiWoor3W2hjA';return true;" onclick=3D"this.href=3D'https://www.googl=
e.com/url?q\75https%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-privext\46sa=
\75D\46sntz\0751\46usg\75AFQjCNHUdaGAiICCLmRPFXPiWoor3W2hjA';return true;">=
https://github.com/<wbr>fmatthew5876/stdcxx-privext</a><br></div><div><br><=
/div></div></blockquote><div><br></div><div>Hi,</div><div><br></div><div>I =
love this proposal and wanted to do pretty much the same thing for some tim=
e.</div><div><br></div><div>In "Alternate Syntax", you say: "<span style=3D=
"color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-size: medium;">O=
ne downside of the current approach is that previously if the user wrote a =
typo when writing a member function name in the definition they would get a=
helpful compilation error."</span></div><div><br></div><div>In my opinion,=
this is a deal breaker. I think it's absolutely necessary to use a keyword=
for this, and I strongly recommend using 'private'. I consider the objecti=
on that this will confuse people to be weak; compilers can easily be taught=
to acknowledge the syntax with more than an "unexpected 'public'" and say =
something like "only private member functions can be declared outside the c=
lass". If a user is still curious as to why that is so, StackOverflow or st=
d-discussion will readily supply the necessary "Because it breaks encapsula=
tion" answer.</div><div><br></div><div><br></div><div>On a side note, if yo=
u want some evidence for the value of this proposal, you should check out t=
he Sema implementation of Clang. There's lots of static helper functions in=
the implementation files, they all get passed the Sema object, and quite a=
few of them should have been private members, because they force Sema memb=
ers to be public that shouldn't have been.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_230_31250092.1386688649981--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Tue, 10 Dec 2013 22:53:34 +0100
Raw View
--089e015376b6e10d1a04ed3524b6
Content-Type: text/plain; charset=ISO-8859-1
This proposal is interesting.
Minor side comment: I'm not sure if the word "method" is used correctly
here. I see what you mean but my understanding is that depending on the
language, method can mean virtual member function.
I remember C++ people saying that in C++ we should use member function to
clarify that it have nothing to do with dynamic dispatch.
More importantly:
I would like to see a paragraph exploring if it feature could or not allow
of the interface "leak", potentially breaking the encapsulation, maybe not
in a harmful way, I'm not sure.
I mean: at first read of this proposal, it looks like it's not possible to
call an extended private member function without it being called by another
member function that ultimately
would be in the class interface.
However, it seems possible to break the encapsulation this way:
///////////////////////////////////////////////////////////////////
// Header "mylib.hpp" from an library "MyLib"
namespace mylib
{
class Foo
{
// ...
private:
int k; // never exposed in the public interface
};
}
///////////////////////////////////////////////////////////////////////
// header "mycode.hpp" in the user code
#include <mylib.hpp>
namespace mylib
{
int* Foo::get_k() { return &this->k; } // private extension
}
///////////////////////////////////////////////////////////////////
// cpp in the user code
#include <mycode.hpp>
void break_in( mylib::Foo& foo )
{
auto private_k_ptr = foo.get_k(); // accessing private members
"legally"
}
////////////////////////////////////////////////////////////////////////
Could you clarify what would prevent this to be allowed? If it is allowed,
then maybe clarifying if it's not a problem?
And if it is a problem, then I think the proposal is problematic.
However I'm not expert so I certainly missed something?
--
---
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/.
--089e015376b6e10d1a04ed3524b6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">This proposal is interesting.</=
div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Minor s=
ide comment: I'm not sure if the word "method" is used correc=
tly here. I see what you mean but my understanding is that depending on the=
language, method can mean virtual member function.<br>
I remember C++ people saying that in C++ we should use member function to c=
larify that it have nothing to do with dynamic dispatch.</div><div class=3D=
"gmail_extra"><br></div><div class=3D"gmail_extra">More importantly:</div><=
div class=3D"gmail_extra">
I would like to see a paragraph exploring if it feature could or not allow =
of the interface "leak", potentially breaking the encapsulation, =
maybe not in a harmful way, I'm not sure.</div><div class=3D"gmail_extr=
a">
I mean: at first read of this proposal, it looks like it's not possible=
to call an extended private member function without it being called by ano=
ther member function that ultimately<br>would be in the class interface.</d=
iv>
<div class=3D"gmail_extra">However, it seems possible to break the encapsul=
ation this way:</div><div class=3D"gmail_extra"><br></div><div class=3D"gma=
il_extra">/////////////////////////////////////////////////////////////////=
//<br>
</div><div class=3D"gmail_extra">// Header "mylib.hpp" from an li=
brary "MyLib"</div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">namespace mylib</div><div class=3D"gmail_extra">{</div><d=
iv class=3D"gmail_extra">
<br></div><div class=3D"gmail_extra">=A0 =A0class Foo</div><div class=3D"gm=
ail_extra">=A0 =A0{</div><div class=3D"gmail_extra">=A0 =A0 =A0 =A0// ...</=
div><div class=3D"gmail_extra">=A0 =A0private:</div><div class=3D"gmail_ext=
ra">=A0 =A0 =A0 =A0 int k; // never exposed in the public interface</div>
<div class=3D"gmail_extra">=A0 =A0};</div><div class=3D"gmail_extra">}</div=
><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">//////////=
/////////////////////////////////////////////////////////////</div><div cla=
ss=3D"gmail_extra">
// header "mycode.hpp" in the user code</div><div class=3D"gmail_=
extra"><br></div><div class=3D"gmail_extra">#include <mylib.hpp></div=
><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_extra">
namespace mylib</div><div class=3D"gmail_extra">{</div><div class=3D"gmail_=
extra">=A0 =A0 int* Foo::get_k() { return &this->k; } // private ext=
ension</div><div class=3D"gmail_extra">}</div><div class=3D"gmail_extra"><b=
r></div>
<div class=3D"gmail_extra"><div class=3D"gmail_extra">/////////////////////=
//////////////////////////////////////////////<br></div></div></div><div cl=
ass=3D"gmail_extra">// cpp in the user code</div><div class=3D"gmail_extra"=
>#include <mycode.hpp></div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra"><div class=3D"gmail_extra">=A0 =A0void break_in( =
mylib::Foo& foo )</div><div class=3D"gmail_extra">=A0 =A0{</div><div cl=
ass=3D"gmail_extra">
=A0 =A0 =A0 =A0 auto private_k_ptr =3D =A0foo.get_k(); =A0// accessing priv=
ate members "legally"</div><div class=3D"gmail_extra">=A0 =A0}</d=
iv><div><br></div></div><div class=3D"gmail_extra">////////////////////////=
////////////////////////////////////////////////</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Could you c=
larify what would prevent this to be allowed? If it is allowed, then maybe =
clarifying if it's not a problem?<br>And if it is a problem, then I thi=
nk the proposal is problematic.<br>
However I'm not expert so I certainly missed something?</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--089e015376b6e10d1a04ed3524b6--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Tue, 10 Dec 2013 22:57:30 +0100
Raw View
--001a11c33b02eb4b0204ed3532f4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tue, Dec 10, 2013 at 10:53 PM, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com=
>wrote:
> I would like to see a paragraph exploring if it feature could or not allo=
w
> of the interface "leak", potentially breaking the encapsulation, maybe no=
t
> in a harmful way, I'm not sure.
Sorry, I forgot to fix this sentence, I meant:
I would like to see a paragraph exploring how the feature could or not
allow of the interface to "leak" it's data, potentially breaking the
encapsulation, maybe not in a harmful way, I'm not sure.
To add to my previous comment:
Basically it looks to me that until we have a way to hide the types of the
private member data, I can't see how it would be possible to avoid this
kind of encapsulation breakage.
--=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/.
--001a11c33b02eb4b0204ed3532f4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Dec 10, 2013 at 10:53 PM, Klaim - Jo=EBl Lamotte <span dir=3D"ltr">=
<<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.co=
m</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">I would like to see a paragraph exploring if it feature co=
uld or not allow of the interface "leak", potentially breaking th=
e encapsulation, maybe not in a harmful way, I'm not sure.</blockquote>
</div><br>Sorry, I forgot to fix this sentence, I meant:</div><div class=3D=
"gmail_extra">I would like to see a paragraph exploring how the feature cou=
ld or not allow of the interface to "leak" it's data, potenti=
ally breaking the encapsulation, maybe not in a harmful way, I'm not su=
re.<br>
<br><br>To add to my previous comment:</div><div class=3D"gmail_extra">Basi=
cally it looks to me that until we have a way to hide the types of the priv=
ate member data, I can't see how it would be possible to avoid this kin=
d of encapsulation breakage.<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11c33b02eb4b0204ed3532f4--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 10 Dec 2013 16:11:44 -0600
Raw View
--001a11c33fd0340ad004ed35681d
Content-Type: text/plain; charset=ISO-8859-1
On 9 December 2013 21:26, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>
> I think the main resistance you will receive is from people that claim
> that this would break encapsulation.
>
Claim? Are you claiming this doesn't break encapsulation?
--
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/.
--001a11c33fd0340ad004ed35681d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 9 December 2013 21:26, Andrew Tomazos <span dir=3D"ltr"=
><<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtom=
azos@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><div><div>I think =
the main resistance you will receive is from people that claim that this wo=
uld break encapsulation. =A0</div>
</div></div></div></blockquote><div><br></div><div>Claim?=A0 Are you claimi=
ng this doesn't break encapsulation?<br></div></div>-- <br>=A0Nevin &qu=
ot;:-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" =
target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1404
</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11c33fd0340ad004ed35681d--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 10 Dec 2013 23:46:11 +0100
Raw View
This is a multi-part message in MIME format.
--------------010300000503080203030807
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 10/12/13 03:20, fmatthew5876@gmail.com a =E9crit :
> Hello everyone, I am going to submit a proposal for relaxing the=20
> restriction on requiring private non-virtual class methods and static=20
> private class methods to be declared in the class definition.
>
> The github repository with the current draft of the proposal is here:
> https://github.com/fmatthew5876/stdcxx-privext
>
> The proposal came out of the discussion from this thread:
> https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/pri=
vate/std-proposals/xukd1mgd21I/akgZSTG4NBUJ=20
> <https://groups.google.com/a/isocpp.org/forum/#%21searchin/std-proposals/=
private/std-proposals/xukd1mgd21I/akgZSTG4NBUJ>
>
>
Hi,
there is a C++ idiom that provides most of the advantages of your=20
proposal (see http://viboes.blogspot.fr/2010/04/pimpl-variant.html).
It consists in declaring a friend detail class.
|//foo.hh
class Foo {
||* struct detail;**
*||* friend*||*|*detail*|;**
*|
| public:
Foo();
void pub1();
void pub2();
private:
int _i;
int _j;
};|
//foo.cc
||
|struct Foo::|||*detail*| {
Foo& that;
|||*detail*|(Foo* f) : that(*f) {}
||| //Definition of _priv1()
void _priv1() {
/* function body */
}
|
||| //A new scoped private extension method.
static void _priv3() {
that._i =3D 3;
}
|
};
//Definition of Foo::pub1()
void Foo::pub1() {
|||*detail*|(this)._priv1();
||*detail*|||(this).|_priv3();
}|
This idiom solves most of the problem the proposal address and doesn't=20
have the drawback pointed by J=F6el, as the detail class is private and no=
=20
other can add private functions.
There are some holes on this idiom as friend is not transitive so other=20
friend classes could not access the backdoor functions neither.
I don't see any benefit to inline calls to private functions that would=20
be defined in a .cc file as your
|//Forward declaration of a private extension method
void Foo::_priv2();
//Inlined public method calls the private extension method
inline void Foo::pub2() { _priv2(); }
|
|inlining the _priv2() call would result on the same code.|
||
||
|I don't see neither the needed to declare new private functions on=20
different files. Could you explain where this could be useful.|
||
Maybe the idiom could be adapted to a language proposal that could avoid=20
the cumbersome use of the that variable. It could consists in declaring=20
a pseudo-struct declaration e.g. private Foo, that could contain only=20
functions. These functions would be accessible only by the class Foo and=20
any friend of Foo. Of course, in order to other classes to be able to=20
use these private functions, the private pseudo-struct should be=20
declared in another file.
||//foo.hh
class Foo {
public:
Foo();
void pub1();
void pub2();
private:
int _i;
int _j;
};|
//foo.cc
||||*private*|| Foo|| {
||| //Definition of _priv1()
void _priv1() {
/* function body */
}
|
||| //A new scoped private extension method.
static void _priv3() {
_i =3D 3;
}
|
};
//Definition of Foo::pub1()
void Foo::pub1() {
_priv1();
||_priv3();
}|
It is clear that all this would have less sense with modules.
Best,
Vicente
--=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/.
--------------010300000503080203030807
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Le 10/12/13 03:20,
<a class="moz-txt-link-abbreviated" href="mailto:fmatthew5876@gmail.com">fmatthew5876@gmail.com</a> a écrit :<br>
</div>
<blockquote
cite="mid:05028bfb-6f6f-4ee8-9a6e-7e6eaa3a877a@isocpp.org"
type="cite">
<div dir="ltr">
<div><span style="font-size: 13px;">Hello everyone, I am going
to submit a proposal for relaxing the restriction on
requiring private non-virtual class methods and static
private class methods to be declared in the class
definition.</span><br>
</div>
<div><br>
</div>
<div>The github repository with the current draft of the
proposal is here:</div>
<div><a moz-do-not-send="true"
href="https://github.com/fmatthew5876/stdcxx-privext">https://github.com/fmatthew5876/stdcxx-privext</a><br>
</div>
<div><br>
</div>
<div>The proposal came out of the discussion from this thread:
<div><a moz-do-not-send="true"
href="https://groups.google.com/a/isocpp.org/forum/#%21searchin/std-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4NBUJ">https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4NBUJ</a><br>
</div>
</div>
<div><br>
</div>
</div>
<br>
</blockquote>
Hi,<br>
<br>
there is a C++ idiom that provides most of the advantages of your
proposal (see <a class="moz-txt-link-freetext" href="http://viboes.blogspot.fr/2010/04/pimpl-variant.html">http://viboes.blogspot.fr/2010/04/pimpl-variant.html</a>).<br>
It consists in declaring a friend detail class.<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<pre><code>//foo.hh
class Foo {
</code><code><b> struct detail;</b><b>
</b></code><code><b> friend </b></code><code><b><code><b>detail</b></code>;</b><b>
</b></code>
<code> public:
Foo();
void pub1();
void pub2();
private:
int _i;
int _j;
};</code></pre>
//foo.cc
<br>
<pre><code></code>
<code>struct Foo::</code><code><code><b>detail</b></code> {
Foo& that;
</code><code><code><b>detail</b></code>(Foo* f) : that(*f) {}
</code><code><code> //Definition of _priv1()
void _priv1() {
/* function body */
}
</code>
</code><code><code> //A new scoped private extension method.
static void _priv3() {
that._i = 3;
}
</code>
};
//Definition of Foo::pub1()
void Foo::pub1() {
</code><code><code><b>detail</b></code>(this)._priv1();
</code><code><b>detail</b></code><code><code>(this).</code>_priv3();
}</code></pre>
This idiom solves most of the problem the proposal address and
doesn't have the drawback pointed by Jöel, as the detail class is
private and no other can add private functions.<br>
<br>
There are some holes on this idiom as friend is not transitive so
other friend classes could not access the backdoor functions
neither.<br>
<br>
I don't see any benefit to inline calls to private functions that
would be defined in a .cc file as your<br>
<pre><code>//Forward declaration of a private extension method
void Foo::_priv2();
//Inlined public method calls the private extension method
inline void Foo::pub2() { _priv2(); }
</code></pre>
<pre><big><code>inlining the _priv2() call would result on the same code.</code></big>
<code></code></pre>
<code></code><br>
<big><code>I don't see neither the needed to declare new private
functions on different files. Could you explain where this could
be useful.</code></big><br>
<code></code> <br>
Maybe the idiom could be adapted to a language proposal that could
avoid the cumbersome use of the that variable. It could consists in
declaring a pseudo-struct declaration e.g. private Foo, that could
contain only functions. These functions would be accessible only by
the class Foo and any friend of Foo. Of course, in order to other
classes to be able to use these private functions, the private
pseudo-struct should be declared in another file.<br>
<br>
<pre><code><code>//foo.hh
class Foo {
public:
Foo();
void pub1();
void pub2();
private:
int _i;
int _j;
};</code>
//foo.cc
</code><code><code><code><b>private</b></code></code> Foo</code><code> {
</code><code><code> //Definition of _priv1()
void _priv1() {
/* function body */
}
</code>
</code><code><code> //A new scoped private extension method.
static void _priv3() {
_i = 3;
}
</code>
};
//Definition of Foo::pub1()
void Foo::pub1() {
_priv1();
</code><code>_priv3();
}</code></pre>
<br>
It is clear that all this would have less sense with modules.<br>
<br>
Best,<br>
Vicente<br>
<br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------010300000503080203030807--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 10 Dec 2013 14:46:47 -0800
Raw View
On ter=E7a-feira, 10 de dezembro de 2013 22:53:34, Klaim - Jo=EBl Lamotte w=
rote:
> Could you clarify what would prevent this to be allowed? If it is allowed=
,
> then maybe clarifying if it's not a problem?
Looks like it would be allowed and it should not be considered a problem. W=
e=20
give the guns, if people point to their feet and pull the trigger, we can't=
be=20
blamed.
That can already be done if the interface designer left a loophole: a class=
=20
friend that isn't defined in this compilation unit.
class Bar;
class Foo
{
// ...
private:
int k;
friend Bar;
};
/// hack.cpp
class Bar
{
static int &get_k(Foo *d) { return d->k; }
};
int &get_foo_k(Foo *d)=20
{=20
return Bar::get_k(d);
}
To be honest, I don't know what the standard says about two different=20
declarations of the same class in the same application but not the same=20
translation unit. But the above will compile in most ABIs.
Not to mention #define private public
--=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/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 10 Dec 2013 23:59:31 +0100
Raw View
Le 10/12/13 23:46, Thiago Macieira a =E9crit :
> On ter=E7a-feira, 10 de dezembro de 2013 22:53:34, Klaim - Jo=EBl Lamotte=
wrote:
>> Could you clarify what would prevent this to be allowed? If it is allowe=
d,
>> then maybe clarifying if it's not a problem?
> Looks like it would be allowed and it should not be considered a problem.=
We
> give the guns, if people point to their feet and pull the trigger, we can=
't be
> blamed.
I disagree. The goal is not to give any gun. Just to be able to refactor=20
the implementation without showing it at the interface level.
> That can already be done if the interface designer left a loophole: a cla=
ss
> friend that isn't defined in this compilation unit.
>
> class Bar;
> class Foo
> {
> // ...
> private:
> int k;
> friend Bar;
> };
>
>
> /// hack.cpp
> class Bar
> {
> static int &get_k(Foo *d) { return d->k; }
> };
>
>
> To be honest, I don't know what the standard says about two different
> declarations of the same class in the same application but not the same
> translation unit. But the above will compile in most ABIs.
This violated the ODR.
> Not to mention #define private public
Note that the original idea is to don't show the private functions, not=20
making all private function public.
Vicente
--=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/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 10 Dec 2013 17:15:34 -0600
Raw View
--f46d04389213867b4a04ed364c0f
Content-Type: text/plain; charset=ISO-8859-1
On 10 December 2013 16:46, Thiago Macieira <thiago@macieira.org> wrote:
>
> give the guns, if people point to their feet and pull the trigger, we
> can't be
> blamed.
>
> That can already be done if the interface designer left a loophole: a class
> friend that isn't defined in this compilation unit.
>
> class Bar;
> class Foo
> {
> // ...
> private:
> int k;
> friend Bar;
> };
>
It isn't a loophole. Foo has *explicitly* given permission for Bar to
access the innards of Foo. That just isn't true for the proposal.
Even though there are some encapsulation loopholes in the language (member
templates come to mind), as Herb Sutter puts it in <
http://www.gotw.ca/gotw/076.htm>: "The issue here is of protecting against
Murphy vs. protecting against Machiavelli... that is, protecting against
accidental misuse (which the language does very well) vs. protecting
against deliberate abuse (which is effectively impossible)."
I am strongly against making it this trivial to ignore encapsulation.
--
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/.
--f46d04389213867b4a04ed364c0f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 10 December 2013 16:46, Thiago Macieira <span dir=3D"lt=
r"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@maci=
eira.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br>
give the guns, if people point to their feet and pull the trigger, we can&#=
39;t be<br>
blamed.<br>
<br>
That can already be done if the interface designer left a loophole: a class=
<br>
friend that isn't defined in this compilation unit.<br>
<br>
class Bar;<br>
<div class=3D"im">class Foo<br>
{<br>
=A0 =A0 // ...<br>
private:<br>
=A0 =A0 int k;<br>
</div>=A0 =A0 friend Bar;<br>
};<br></blockquote><div><br></div><div>It isn't a loophole.=A0 Foo has =
<i>explicitly</i> given permission for Bar to access the innards of Foo.=A0=
That just isn't true for the proposal.<br><br></div><div>Even though t=
here are some encapsulation loopholes in the language (member templates com=
e to mind), as Herb Sutter puts it in <<a href=3D"http://www.gotw.ca/got=
w/076.htm">http://www.gotw.ca/gotw/076.htm</a>>: "<font face=3D"Ari=
al, Arial, Helvetica">The issue here is of protecting=20
against Murphy vs. protecting against Machiavelli... that is, protecting
against accidental misuse (which the language does very well) vs.=20
protecting against deliberate abuse (which is effectively impossible)."=
;<br><br></font></div><div><font face=3D"Arial, Arial, Helvetica">I am stro=
ngly against making it this trivial to ignore encapsulation.<br></font></di=
v>
<div><font face=3D"Arial, Arial, Helvetica"></font></div></div>-- <br>=A0Ne=
vin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlor=
d.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1404
</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--f46d04389213867b4a04ed364c0f--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 11 Dec 2013 00:27:49 +0100
Raw View
--089e015388f6f5169b04ed3675dd
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Dec 10, 2013 at 11:46 PM, Thiago Macieira <thiago@macieira.org>wrote:
> That can already be done if the interface designer left a loophole: a class
> friend that isn't defined in this compilation unit.
>
Yes, but the most common case I've seen in real use was more exploiting the
visibility rules of private inner classes:
// header
class Foo
{
// ...
private:
int k;
class Bar; // inner class, private so even if you have Bar interface,
you can't use it from outside Foo's implementation
};
// cpp
class Foo::Bar
{
// takes a Foo instance and access it's private members.
};
// user cpp
class Foo::Bar // ODR violation, maybe hidden in case of dynamic libraries?
{
// do whatever with Foo
// can't use it's interface as Foo::Bar name is not accessible anyway, so
only Foo members
// can use this type
// If it's a dynamic library, this implementation will never be used by
non-inline Foo member functions.
};
Here Foo::Bar is both acting like a friend of Foo and can't be used by
external code as
even if you define Foo::Bar, the name "Foo::Bar" can't be used outside
member functions of Foo.
Assuming you define Foo::Bar with an interface that match Foo's members use
of Foo::Bar, but only
the ones defined in the header (and potentially inlined), you'd have a
hard time making this work
correctly in conjonction with the original Foo::Bar.
Basically, it's not really easy to get into Foo through Foo::Bar.
However, it is really easy to get any private data exposed in the class
definition using extends methods,
without having to change the class definition at all (which is worse than
friend which at least force the user
to change the library code, which have huge impact on maintenance, which is
a big pressure not to do so
if it's not for a bugfix but for abuse).
I'm not sure if it would be possible to modify your proposal so that it
gives similar garantees to inner classes,
but with easier syntax? At the moment I can't think of a good way.
Side comment: It looks like the issue the proposal is trying to partially
fix is really hard to improve without changing at least a bit
the compilation model itself.
--
---
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/.
--089e015388f6f5169b04ed3675dd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Dec 10, 2013 at 11:46 PM, Thiago Macieira <span dir=3D"ltr"><<a =
href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</=
a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div id=3D":1tn" style=3D"overflow:hidden">That can alread=
y be done if the interface designer left a loophole: a class<br>
friend that isn't defined in this compilation unit.<br></div></blockquo=
te></div><br>Yes, but the most common case I've seen in real use was mo=
re exploiting the visibility rules of private inner classes:</div><div clas=
s=3D"gmail_extra">
<br></div><div class=3D"gmail_extra"><div class=3D"gmail_extra">// header</=
div><div class=3D"gmail_extra">class Foo</div><div class=3D"gmail_extra">{<=
/div><div class=3D"gmail_extra">=A0 =A0 // ...</div><div class=3D"gmail_ext=
ra">private:</div>
<div class=3D"gmail_extra">=A0 =A0 int k;</div><div class=3D"gmail_extra">=
=A0 =A0 class Bar; // inner class, private so even if you have Bar interfac=
e, you can't use it from outside Foo's implementation</div><div cla=
ss=3D"gmail_extra">
};</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">// =
cpp</div><div class=3D"gmail_extra">class Foo::Bar</div><div class=3D"gmail=
_extra">{</div><div class=3D"gmail_extra">=A0 =A0// takes a Foo instance an=
d access it's private members.</div>
<div class=3D"gmail_extra">};</div><div class=3D"gmail_extra"><br></div><di=
v class=3D"gmail_extra">// user cpp</div><div class=3D"gmail_extra"><br></d=
iv><div class=3D"gmail_extra">class Foo::Bar // ODR violation, maybe hidden=
in case of dynamic libraries?</div>
<div class=3D"gmail_extra">{</div><div class=3D"gmail_extra">=A0// do whate=
ver with Foo</div><div class=3D"gmail_extra">=A0// can't use it's i=
nterface as Foo::Bar name is not accessible anyway, so only Foo members</di=
v><div class=3D"gmail_extra">
=A0 // can use this type</div><div class=3D"gmail_extra">=A0// If it's =
a dynamic library, this implementation will never be used by non-inline Foo=
member functions.</div><div class=3D"gmail_extra">};<br></div><div class=
=3D"gmail_extra">
<br></div><div class=3D"gmail_extra">Here Foo::Bar is both acting like a fr=
iend of Foo and can't be used by external code as</div><div class=3D"gm=
ail_extra">even if you define Foo::Bar, the name "Foo::Bar" can&#=
39;t be used outside member functions of Foo.</div>
<div class=3D"gmail_extra">Assuming you define Foo::Bar with an interface t=
hat match Foo's members use of Foo::Bar, but only</div><div class=3D"gm=
ail_extra">the ones defined in the =A0header (and potentially inlined), you=
'd have a hard time making this work<br>
correctly in conjonction with the original Foo::Bar.<br>Basically, it's=
not really easy to get into Foo through Foo::Bar.</div><div class=3D"gmail=
_extra"><br></div><div class=3D"gmail_extra">However, it is really easy to =
get any private data exposed in the class definition using extends methods,=
</div>
<div class=3D"gmail_extra">without having to change the class definition at=
all (which is worse than friend which at least force the user</div><div cl=
ass=3D"gmail_extra">to change the library code, which have huge impact on m=
aintenance, which is a big pressure not to do so</div>
<div class=3D"gmail_extra">if it's not for a bugfix but for abuse).</di=
v><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I'm n=
ot sure if it would be possible to modify your proposal so that it gives si=
milar garantees to inner classes,=A0</div>
<div class=3D"gmail_extra">but with easier syntax? At the moment I can'=
t think of a good way.</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">Side comment: It looks like the issue the proposal is tryi=
ng to partially fix is really hard to improve without changing at least a b=
it=A0<br>
the compilation model itself.</div><div class=3D"gmail_extra"><br></div></d=
iv></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--089e015388f6f5169b04ed3675dd--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 11 Dec 2013 00:38:36 +0100
Raw View
--001a11c2fcb88814de04ed369c41
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Let me clarify my example a bit:
On Wed, Dec 11, 2013 at 12:27 AM, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com=
>wrote:
> // header
> class Foo
> {
> // ...
>
void action();
> private:
> int k;
> class Bar; // inner class, private so even if you have Bar interface,
> you can't use it from outside Foo's implementation
> };
>
> // cpp
> class Foo::Bar
> {
> // takes a Foo instance and access it's private members.
>
Foo& m_foo;
Bar( Foo& foo ) : m_foo( foo ) {}
Bar& inc_counter() { ++m_foo.k; return this; }
>
>
};
>
void Foo::action() { Bar(*this).inc_counter(); } // here we use
Foo::Bar into Foo, so no compilation error
>
> // user cpp
>
> class Foo::Bar // ODR violation, maybe hidden in case of dynamic librarie=
s?
> {
> // do whatever with Foo
> // can't use it's interface as Foo::Bar name is not accessible anyway, s=
o
> only Foo members
> // can use this type
> // If it's a dynamic library, this implementation will never be used by
> non-inline Foo member functions.
> };
>
If nobody seen any problem with this way of doing, maybe a syntax to
simplify this would help.
Something that would look like:
// header
class Foo
{
// ...
void action();
private:
int k;
extension Bar; // like an inner class, private so even if you have Bar
interface, you can't use it from outside Foo's implementation
// extension can't be used in non-private section.
};
// cpp
extension Foo::Bar
// like an inner class BUT:
// - can only contain private members functions and private static
functions for Foo
// - don't allow visibility scope (as everything is private)
// - can't be inherited? etc.
// - members of Foo::Bar are implicitely usable from Foo members defined
AFTER this definition
// - this is Foo's instance calling the private member or static
function (see the usage)
{
// No need for the following: Bar code is implicitely usable from
// Foo& m_foo;
// Bar( Foo& foo ) : m_foo( foo ) {}
Bar& inc_counter() { ++m_foo.k; return this; }
};
void Foo::action() { inc_counter(); } // here we use Foo::Bar, but in
an implicit way
// user cpp
extension Foo::Bar // ODR violation, maybe hidden in case of dynamic
libraries?
{
// do whatever with Foo
// can't use it's interface as Foo::Bar name is not accessible anyway, so
only Foo members
// can use this type
// If it's a dynamic library, this implementation will never be used by
non-inline Foo member functions.
};
It's just a shortcut of using inner class, so not sure it's worth (it does
help to have implicit this to the outter class instance though...)
So it's basically a shortcut of an idiom I've seen and used, but I didn't
explore the potential problems (other than adding a keyword).
What do you think?
--=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/.
--001a11c2fcb88814de04ed369c41
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br></div><div class=3D"gmail_e=
xtra">Let me clarify my example a bit:</div><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On Wed, Dec 11, 2013 at 12:27 AM, Klaim - Jo=EBl=
Lamotte <span dir=3D"ltr"><<a href=3D"mailto:mjklaim@gmail.com" target=
=3D"_blank">mjklaim@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"gmail_extra">// header</div><div class=3D"im=
"><div class=3D"gmail_extra">
class Foo</div><div class=3D"gmail_extra">{</div><div class=3D"gmail_extra"=
>=A0 =A0 // ...</div></div></blockquote><div>=A0 =A0 =A0 =A0 void action();=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex">
<div class=3D"im"><div class=3D"gmail_extra">private:</div>
<div class=3D"gmail_extra">=A0 =A0 int k;</div></div><div class=3D"gmail_ex=
tra">=A0 =A0 class Bar; // inner class, private so even if you have Bar int=
erface, you can't use it from outside Foo's implementation</div><di=
v class=3D"gmail_extra">
};</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">// =
cpp</div><div class=3D"gmail_extra">class Foo::Bar</div><div class=3D"gmail=
_extra">{</div><div class=3D"gmail_extra">=A0 =A0// takes a Foo instance an=
d access it's private members.</div>
</blockquote><div>=A0 =A0 =A0 =A0Foo& m_foo;=A0</div><div>=A0 =A0 =A0 =
=A0Bar( Foo& foo ) : m_foo( foo ) {}=A0</div><div>=A0 =A0 =A0 =A0Bar&am=
p; inc_counter() { ++m_foo.k; return this; }</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=3D"gmail_extra"> =A0 =A0</div></blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=3D"gmail_extra">};</div></blockquote><div>=A0 =A0=A0</div><div>=
=A0 =A0 void Foo::action() { Bar(*this).inc_counter(); } // here we use Foo=
::Bar into Foo, so no compilation error</div><div>=A0 =A0 =A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex">
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">// user cpp=
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">class=
Foo::Bar // ODR violation, maybe hidden in case of dynamic libraries?</div=
>
<div class=3D"gmail_extra">{</div><div class=3D"gmail_extra">=A0// do whate=
ver with Foo</div><div class=3D"gmail_extra">=A0// can't use it's i=
nterface as Foo::Bar name is not accessible anyway, so only Foo members</di=
v><div class=3D"gmail_extra">
=A0 // can use this type</div><div class=3D"gmail_extra">=A0// If it's =
a dynamic library, this implementation will never be used by non-inline Foo=
member functions.</div><div class=3D"gmail_extra">};<br></div><div class=
=3D"gmail_extra">
</div></blockquote></div><br>If nobody seen any problem with this way of do=
ing, maybe a syntax to simplify this would help.<br>Something that would lo=
ok like:</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extr=
a">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
</blockquote></blockquote>// header<br><blockquote class=3D"gmail_quote " s=
tyle=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;border-right-width:1px;border-right-color:rg=
b(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex"=
>
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>class Foo<br><blockquote class=3D"gmail_quote " s=
tyle=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;border-right-width:1px;border-right-color:rg=
b(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex"=
>
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>{<br><blockquote class=3D"gmail_quote " style=3D"=
margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;border-right-width:1px;border-right-color:rgb(204,20=
4,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0 =A0 // ...<br><blockquote class=3D"gmail_quot=
e " style=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;border-right-width:1px;border-right-col=
or:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right=
:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0 =A0 =A0 =A0 void action();=A0<br><blockquote =
class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-width:1px;bord=
er-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1=
px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-lef=
t:1ex;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>private:<br><blockquote class=3D"gmail_quote " st=
yle=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb=
(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0 =A0 int k;<br><blockquote class=3D"gmail_quot=
e " style=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;border-right-width:1px;border-right-col=
or:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right=
:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0 =A0 extension Bar; // like an inner class, pr=
ivate so even if you have Bar interface, you can't use it from outside =
Foo's implementation</div><div class=3D"gmail_extra">=A0 =A0 // extensi=
on can't be used in non-private section.</div>
<div class=3D"gmail_extra"><blockquote class=3D"gmail_quote " style=3D"marg=
in:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,20=
4);border-right-style:solid;padding-left:1ex;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>};</div><div class=3D"gmail_extra"><br><blockquot=
e class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;border-right-width=
:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-l=
eft:1ex;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>// cpp<br><blockquote class=3D"gmail_quote " styl=
e=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;border-right-width:1px;border-right-color:rgb(2=
04,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>extension Foo::Bar</div><div class=3D"gmail_extra=
">=A0 =A0// like an inner class BUT:</div><div class=3D"gmail_extra">=A0 =
=A0// - can only contain private members functions and private static funct=
ions for Foo</div>
<div class=3D"gmail_extra">=A0 =A0// - don't allow visibility scope (as=
everything is private)</div><div class=3D"gmail_extra">=A0 =A0// - can'=
;t be inherited? etc.</div><div class=3D"gmail_extra">=A0 =A0// - members o=
f Foo::Bar are implicitely usable from Foo members defined AFTER this defin=
ition</div>
<div class=3D"gmail_extra">=A0 =A0// - this is Foo's instance calling t=
he private member or static function (see the usage)<br><blockquote class=
=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;bo=
rder-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex=
;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>{<br><blockquote class=3D"gmail_quote " style=3D"=
margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;border-right-width:1px;border-right-color:rgb(204,20=
4,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0 =A0 =A0=A0</div><div class=3D"gmail_extra">=
=A0 =A0 =A0 =A0// No need for the following: Bar code is implicitely usable=
from<br><blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-st=
yle:solid;padding-left:1ex;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0 =A0 =A0 =A0// Foo& m_foo;=A0<br><blockquo=
te class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;border-right-widt=
h:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-=
left:1ex;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0 =A0 =A0 =A0// Bar( Foo& foo ) : m_foo( fo=
o ) {} =A0=A0</div><div class=3D"gmail_extra"><br><blockquote class=3D"gmai=
l_quote " style=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color=
:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-rig=
ht-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding=
-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0 =A0 =A0 =A0Bar& inc_counter() { ++m_foo.k=
; return this; }<br><blockquote class=3D"gmail_quote " style=3D"margin:0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);bord=
er-right-style:solid;padding-left:1ex;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0 =A0<br><blockquote class=3D"gmail_quote " sty=
le=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(=
204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>};<br><blockquote class=3D"gmail_quote " style=3D=
"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,2=
04,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0 =A0=A0<br><blockquote class=3D"gmail_quote " =
style=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;border-right-width:1px;border-right-color:r=
gb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex=
">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0 =A0 void Foo::action() { inc_counter(); } // =
here we use Foo::Bar, but in an implicit way<br><blockquote class=3D"gmail_=
quote " style=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;border-right-width:1px;border-right=
-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-r=
ight:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0 =A0 =A0<br><blockquote class=3D"gmail_quote "=
style=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,=
204,204);border-left-style:solid;border-right-width:1px;border-right-color:=
rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1e=
x">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>// user cpp<br><blockquote class=3D"gmail_quote "=
style=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,=
204,204);border-left-style:solid;border-right-width:1px;border-right-color:=
rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1e=
x">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>extension Foo::Bar // ODR violation, maybe hidden=
in case of dynamic libraries?<br><blockquote class=3D"gmail_quote " style=
=3D"margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;border-right-width:1px;border-right-color:rgb(20=
4,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>{<br><blockquote class=3D"gmail_quote " style=3D"=
margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;border-right-width:1px;border-right-color:rgb(204,20=
4,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0// do whatever with Foo<br><blockquote class=
=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;bo=
rder-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex=
;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0// can't use it's interface as Foo::Ba=
r name is not accessible anyway, so only Foo members<br><blockquote class=
=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;bo=
rder-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex=
;padding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0 // can use this type<br><blockquote class=3D"=
gmail_quote " style=3D"margin:0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border=
-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;pad=
ding-right:1ex">
<blockquote class=3D"gmail_quote " style=3D"margin:0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-r=
ight-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid=
;padding-left:1ex;padding-right:1ex">
</blockquote></blockquote>=A0// If it's a dynamic library, this impleme=
ntation will never be used by non-inline Foo member functions.<br>};</div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><d=
iv class=3D"gmail_extra">
<br></div><div class=3D"gmail_extra">It's just a shortcut of using inne=
r class, so not sure it's worth (it does help to have implicit this to =
the outter class instance though...)</div><div class=3D"gmail_extra">So it&=
#39;s basically a shortcut of an idiom I've seen and used, but I didn&#=
39;t explore the potential problems (other than adding a keyword).</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">What do you=
think?</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11c2fcb88814de04ed369c41--
.
Author: inkwizytoryankes@gmail.com
Date: Tue, 10 Dec 2013 15:47:36 -0800 (PST)
Raw View
------=_Part_750_13770271.1386719257126
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
isnt private extension still private? I every one can create private=20
function but only private function can call it you can only create dead=20
code.
To even call any new private extension you need have at least one normal=20
member function to call it.
On Tuesday, December 10, 2013 10:53:34 PM UTC+1, Klaim - Jo=EBl Lamotte wro=
te:
>
> This proposal is interesting.
>
> Minor side comment: I'm not sure if the word "method" is used correctly=
=20
> here. I see what you mean but my understanding is that depending on the=
=20
> language, method can mean virtual member function.
> I remember C++ people saying that in C++ we should use member function to=
=20
> clarify that it have nothing to do with dynamic dispatch.
>
> More importantly:
> I would like to see a paragraph exploring if it feature could or not allo=
w=20
> of the interface "leak", potentially breaking the encapsulation, maybe no=
t=20
> in a harmful way, I'm not sure.
> I mean: at first read of this proposal, it looks like it's not possible t=
o=20
> call an extended private member function without it being called by anoth=
er=20
> member function that ultimately
> would be in the class interface.
> However, it seems possible to break the encapsulation this way:
>
> ///////////////////////////////////////////////////////////////////
> // Header "mylib.hpp" from an library "MyLib"
>
> namespace mylib
> {
>
> class Foo
> {
> // ...
> private:
> int k; // never exposed in the public interface
> };
> }
>
> ///////////////////////////////////////////////////////////////////////
> // header "mycode.hpp" in the user code
>
> #include <mylib.hpp>
>
> namespace mylib
> {
> int* Foo::get_k() { return &this->k; } // private extension
> }
>
> ///////////////////////////////////////////////////////////////////
> // cpp in the user code
> #include <mycode.hpp>
>
>
> void break_in( mylib::Foo& foo )
> {
> auto private_k_ptr =3D foo.get_k(); // accessing private member=
s=20
> "legally"
> }
>
> ////////////////////////////////////////////////////////////////////////
>
> Could you clarify what would prevent this to be allowed? If it is allowed=
,=20
> then maybe clarifying if it's not a problem?
> And if it is a problem, then I think the proposal is problematic.
> However I'm not expert so I certainly missed something?
>
>
--=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_750_13770271.1386719257126
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">isnt private extension still private? I every one can crea=
te private function but only private function can call it you can only crea=
te dead code.<br>To even call any new private extension you need have at le=
ast one normal member function to call it.<br><br>On Tuesday, December 10, =
2013 10:53:34 PM UTC+1, Klaim - Jo=EBl Lamotte wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div>This proposal is interesting.<=
/div><div><br></div><div>Minor side comment: I'm not sure if the word "meth=
od" is used correctly here. I see what you mean but my understanding is tha=
t depending on the language, method can mean virtual member function.<br>
I remember C++ people saying that in C++ we should use member function to c=
larify that it have nothing to do with dynamic dispatch.</div><div><br></di=
v><div>More importantly:</div><div>
I would like to see a paragraph exploring if it feature could or not allow =
of the interface "leak", potentially breaking the encapsulation, maybe not =
in a harmful way, I'm not sure.</div><div>
I mean: at first read of this proposal, it looks like it's not possible to =
call an extended private member function without it being called by another=
member function that ultimately<br>would be in the class interface.</div>
<div>However, it seems possible to break the encapsulation this way:</div><=
div><br></div><div>//////////////////////////////<wbr>/////////////////////=
/////////<wbr>///////<br>
</div><div>// Header "mylib.hpp" from an library "MyLib"</div><div><br></di=
v><div>namespace mylib</div><div>{</div><div>
<br></div><div> class Foo</div><div> {</div><div>&n=
bsp; // ...</div><div> private:</div><div>&=
nbsp; int k; // never exposed in the public interface<=
/div>
<div> };</div><div>}</div><div><br></div><div>/////////////////=
/////////////<wbr>//////////////////////////////<wbr>///////////</div><div>
// header "mycode.hpp" in the user code</div><div><br></div><div>#include &=
lt;mylib.hpp></div><div><br></div><div><div>
namespace mylib</div><div>{</div><div> int* Foo::get_k() { ret=
urn &this->k; } // private extension</div><div>}</div><div><br></div=
>
<div><div>//////////////////////////////<wbr>//////////////////////////////=
<wbr>///////<br></div></div></div><div>// cpp in the user code</div><div>#i=
nclude <mycode.hpp></div>
<div><br></div><div><br></div><div><div> void break_in( mylib::=
Foo& foo )</div><div> {</div><div>
auto private_k_ptr =3D foo.get_k();  =
;// accessing private members "legally"</div><div> }</div><div>=
<br></div></div><div>//////////////////////////////<wbr>///////////////////=
///////////<wbr>////////////</div>
<div><br></div><div>Could you clarify what would prevent this to be allowed=
? If it is allowed, then maybe clarifying if it's not a problem?<br>And if =
it is a problem, then I think the proposal is problematic.<br>
However I'm not expert so I certainly missed something?</div><div><br></div=
></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_750_13770271.1386719257126--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 11 Dec 2013 00:57:06 +0100
Raw View
--001a11c1e8b8abae4d04ed36dea3
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Dec 11, 2013 at 12:47 AM, <inkwizytoryankes@gmail.com> wrote:
> isnt private extension still private? I every one can create private
> function but only private function can call it you can only create dead
> code.
> To even call any new private extension you need have at least one normal
> member function to call it.
>
I think you are correct, my first example would have an error on the
foo.get_k() call.
So basically it works in the similar way than my last examples with inner
classes (without the verbosity).
I initially thought that using member function pointer could be used to
hack an access to the private data,
but I'm not sure.
I should just sleep more.
--
---
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/.
--001a11c1e8b8abae4d04ed36dea3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Dec 11, 2013 at 12:47 AM, <span dir=3D"ltr"><<a href=3D"mailto:=
inkwizytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a=
>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">isnt private extension still private? I e=
very one can create private function but only private function can call it =
you can only create dead code.<br>
To even call any new private extension you need have at least one normal me=
mber function to call it.</div></blockquote></div><br>I think you are corre=
ct, my first example would have an error on the foo.get_k() call.</div>
<div class=3D"gmail_extra">So basically it works in the similar way than my=
last examples with inner classes (without the verbosity).</div><div class=
=3D"gmail_extra">I initially thought that using member function pointer cou=
ld be used to hack an access to the private data,=A0</div>
<div class=3D"gmail_extra">but I'm not sure.</div><div class=3D"gmail_e=
xtra">I should just sleep more.<br></div><div class=3D"gmail_extra"><br></d=
iv><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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11c1e8b8abae4d04ed36dea3--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 11 Dec 2013 02:20:23 +0200
Raw View
On 11 December 2013 00:59, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Le 10/12/13 23:46, Thiago Macieira a =E9crit :
>> class Bar;
>> class Foo
>> {
>> // ...
>> private:
>> int k;
>> friend Bar;
>> };
>>
>>
>> /// hack.cpp
>> class Bar
>> {
>> static int &get_k(Foo *d) { return d->k; }
>> };
>>
>>
>> To be honest, I don't know what the standard says about two different
>> declarations of the same class in the same application but not the same
>> translation unit. But the above will compile in most ABIs.
>
> This violated the ODR.
Which bit of it does that, exactly?
--=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/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 10 Dec 2013 16:33:31 -0800
Raw View
--089e0160c2dcec073804ed376012
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tue, Dec 10, 2013 at 3:47 PM, <inkwizytoryankes@gmail.com> wrote:
> isnt private extension still private? I every one can create private
> function but only private function can call it you can only create dead
> code.
> To even call any new private extension you need have at least one normal
> member function to call it.
>
This isn't true; you can use this extension to violate encapsulation (as I
demonstrated on the previous discussion thread on this topic). That said,
it's difficult, and it's *very* unlikely that you'd do it by accident.
Here's one way to violate encapsulation with this extension:
class A {
int n;
public:
A() : n(42) {}
};
template<typename T> struct X {
static decltype(T()()) t;
};
template<typename T> decltype(T()()) X<T>::t =3D T()();
int A::*p;
private int A::expose_private_member() { // note, not called anywhere
struct DoIt {
int operator()() {
p =3D &A::n;
return 0;
}
};
return X<DoIt>::t; // odr-use of X<DoIt>::t triggers instantiation
}
int main() {
A a;
return a.*p; // read private member
}
> On Tuesday, December 10, 2013 10:53:34 PM UTC+1, Klaim - Jo=EBl Lamotte
> wrote:
>>
>> This proposal is interesting.
>>
>> Minor side comment: I'm not sure if the word "method" is used correctly
>> here. I see what you mean but my understanding is that depending on the
>> language, method can mean virtual member function.
>> I remember C++ people saying that in C++ we should use member function t=
o
>> clarify that it have nothing to do with dynamic dispatch.
>>
>> More importantly:
>> I would like to see a paragraph exploring if it feature could or not
>> allow of the interface "leak", potentially breaking the encapsulation,
>> maybe not in a harmful way, I'm not sure.
>> I mean: at first read of this proposal, it looks like it's not possible
>> to call an extended private member function without it being called by
>> another member function that ultimately
>> would be in the class interface.
>> However, it seems possible to break the encapsulation this way:
>>
>> ///////////////////////////////////////////////////////////////////
>> // Header "mylib.hpp" from an library "MyLib"
>>
>> namespace mylib
>> {
>>
>> class Foo
>> {
>> // ...
>> private:
>> int k; // never exposed in the public interface
>> };
>> }
>>
>> ///////////////////////////////////////////////////////////////////////
>> // header "mycode.hpp" in the user code
>>
>> #include <mylib.hpp>
>>
>> namespace mylib
>> {
>> int* Foo::get_k() { return &this->k; } // private extension
>> }
>>
>> ///////////////////////////////////////////////////////////////////
>> // cpp in the user code
>> #include <mycode.hpp>
>>
>>
>> void break_in( mylib::Foo& foo )
>> {
>> auto private_k_ptr =3D foo.get_k(); // accessing private membe=
rs
>> "legally"
>> }
>>
>> ////////////////////////////////////////////////////////////////////////
>>
>> Could you clarify what would prevent this to be allowed? If it is
>> allowed, then maybe clarifying if it's not a problem?
>> And if it is a problem, then I think the proposal is problematic.
>> However I'm not expert so I certainly missed something?
>>
>> --
>
> ---
> 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/.
--089e0160c2dcec073804ed376012
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Dec 10, 2013 at 3:47 PM, <span dir=3D"ltr"><<a href=3D"mailto:inkwi=
zytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>>=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">isnt private extension still private? I e=
very one can create private function but only private function can call it =
you can only create dead code.<br>
To even call any new private extension you need have at least one normal me=
mber function to call it.</div></blockquote><div><br></div><div><div>This i=
sn't true; you can use this extension to violate encapsulation (as I de=
monstrated on the previous discussion thread on this topic). That said, it&=
#39;s difficult, and it's *very* unlikely that you'd do it by accid=
ent.</div>
<div><br></div><div>Here's one way to violate encapsulation with this e=
xtension:</div><div><br></div><div>class A {</div><div>=A0 int n;</div><div=
>public:</div><div>=A0 A() : n(42) {}</div><div>};</div><div><br></div><div=
>
template<typename T> struct X {<br></div><div>=A0 static decltype(T()=
()) t;</div><div>};</div><div>template<typename T> decltype(T()()) X&=
lt;T>::t =3D T()();</div><div><div><br></div><div>int A::*p;</div></div>
<div>private int A::expose_private_member() { // note, not called anywhere<=
br></div><div>=A0 struct DoIt {</div><div>=A0 =A0 int operator()() {</div><=
div>=A0 =A0 =A0 p =3D &A::n;</div><div>=A0 =A0 =A0 return 0;</div><div>=
=A0 =A0 }</div><div>
=A0 };</div><div>=A0 return X<DoIt>::t; // odr-use of X<DoIt>::=
t triggers instantiation</div><div>}</div><div><br></div><div>int main() {<=
/div><div>=A0 A a;</div><div>=A0 return a.*p; // read private member</div><=
div>
}</div></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div clas=
s=3D"h5">
On Tuesday, December 10, 2013 10:53:34 PM UTC+1, Klaim - Jo=EBl Lamotte wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex">
<div dir=3D"ltr"><div>This proposal is interesting.</div><div><br></div><di=
v>Minor side comment: I'm not sure if the word "method" is us=
ed correctly here. I see what you mean but my understanding is that dependi=
ng on the language, method can mean virtual member function.<br>
I remember C++ people saying that in C++ we should use member function to c=
larify that it have nothing to do with dynamic dispatch.</div><div><br></di=
v><div>More importantly:</div><div>
I would like to see a paragraph exploring if it feature could or not allow =
of the interface "leak", potentially breaking the encapsulation, =
maybe not in a harmful way, I'm not sure.</div><div>
I mean: at first read of this proposal, it looks like it's not possible=
to call an extended private member function without it being called by ano=
ther member function that ultimately<br>would be in the class interface.</d=
iv>
<div>However, it seems possible to break the encapsulation this way:</div><=
div><br></div><div>//////////////////////////////<u></u>///////////////////=
///////////<u></u>///////<br>
</div><div>// Header "mylib.hpp" from an library "MyLib"=
;</div><div><br></div><div>namespace mylib</div><div>{</div><div>
<br></div><div>=A0 =A0class Foo</div><div>=A0 =A0{</div><div>=A0 =A0 =A0 =
=A0// ...</div><div>=A0 =A0private:</div><div>=A0 =A0 =A0 =A0 int k; // nev=
er exposed in the public interface</div>
<div>=A0 =A0};</div><div>}</div><div><br></div><div>///////////////////////=
///////<u></u>//////////////////////////////<u></u>///////////</div><div>
// header "mycode.hpp" in the user code</div><div><br></div><div>=
#include <mylib.hpp></div><div><br></div><div><div>
namespace mylib</div><div>{</div><div>=A0 =A0 int* Foo::get_k() { return &a=
mp;this->k; } // private extension</div><div>}</div><div><br></div>
<div><div>//////////////////////////////<u></u>////////////////////////////=
//<u></u>///////<br></div></div></div><div>// cpp in the user code</div><di=
v>#include <mycode.hpp></div>
<div><br></div><div><br></div><div><div>=A0 =A0void break_in( mylib::Foo&am=
p; foo )</div><div>=A0 =A0{</div><div>
=A0 =A0 =A0 =A0 auto private_k_ptr =3D =A0foo.get_k(); =A0// accessing priv=
ate members "legally"</div><div>=A0 =A0}</div><div><br></div></di=
v><div>//////////////////////////////<u></u>//////////////////////////////<=
u></u>////////////</div>
<div><br></div><div>Could you clarify what would prevent this to be allowed=
? If it is allowed, then maybe clarifying if it's not a problem?<br>And=
if it is a problem, then I think the proposal is problematic.<br>
However I'm not expert so I certainly missed something?</div><div><br><=
/div></div>
</blockquote></div></div></div><div class=3D""><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <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%2Bunsubscribe@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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--089e0160c2dcec073804ed376012--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 11 Dec 2013 08:34:33 +0800
Raw View
On 12/11/13 8:20 AM, Ville Voutilainen wrote:
> On 11 December 2013 00:59, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr> wrote:
>> Le 10/12/13 23:46, Thiago Macieira a =E9crit :
>>> class Bar;
>>> class Foo
>>> {
>>> // ...
>>> private:
>>> int k;
>>> friend Bar;
>>> };
>>>
>>>
>>> /// hack.cpp
>>> class Bar
>>> {
>>> static int &get_k(Foo *d) { return d->k; }
>>> };
>>>
>>>
>>> To be honest, I don't know what the standard says about two different
>>> declarations of the same class in the same application but not the same
>>> translation unit. But the above will compile in most ABIs.
>> This violated the ODR.
>
>
> Which bit of it does that, exactly?
>
The example is unclear, but it seems to imply Bar must also be defined=20
somewhere besides the hack. A class (named) with external linkage shall=20
have an identical definition in every TU. (3.2/6)
A better way to violate privileges without violating the ODR would be to=20
explicitly specialize a member of Bar which cannot be named by another=20
TU. There are other tricks based on specialization.
What if a derived class meeting some strict requirements could be=20
defined as alias-compatible with the base, such that an object of a base=20
class could be used as the interface, and suitably casted used as the=20
implementation?
Extension methods are nice to have and closely related to modules.=20
Perhaps someone can draft a modules-compatible, self-contained extension=20
providing private implementation semantics, and get a head start on ABI=20
work related to consequences in the type system.
--=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/.
.
Author: fmatthew5876@gmail.com
Date: Tue, 10 Dec 2013 18:55:11 -0800 (PST)
Raw View
------=_Part_477_12966560.1386730511760
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Wow lots of comments.=20
Before I answer the comments, I'd like to emphasize this article which=20
someone else has already mentioned. http://www.gotw.ca/gotw/076.htm
Here, Herb Sutter talks about ways in current C++ that you can break=20
encapsulation. I don't believe my feature adds any new ways to get at=20
private data that don't already exist.
What we want to avoid is allowing an easy to use "break encapsulation here"=
=20
feature. If someone can break encapsulation by doing the horrible things=20
mentioned in that article, that's ok. Access control in C++ is not a=20
security feature, its a productivity and organization feature. It helps you=
=20
write good code, its not designed to save lives.
With that, lets get started..
On Tuesday, December 10, 2013 10:17:29 AM UTC-5, corn...@google.com wrote:
>
>
> Hi,
>
> I love this proposal and wanted to do pretty much the same thing for some=
=20
> time.
>
> Good to know someone is annoyed by this restriction as I am.
=20
> In "Alternate Syntax", you say: "One downside of the current approach is=
=20
> that previously if the user wrote a typo when writing a member function=
=20
> name in the definition they would get a helpful compilation error."
>
> In my opinion, this is a deal breaker.=20
>
I don't think its a huge deal breaker, since the error will be caught at=20
link time. But I'm not too concerned with the syntax, as long as this=20
feature makes it in.
=20
> I think it's absolutely necessary to use a keyword for this, and I=20
> strongly recommend using 'private'.=20
>
Actually using a keyword nicely solves the static dilemna:
private Foo::f1() //private extension method
private static Foo::f2() //static private method
static private Foo::f3() //private extension method with internal linkage
static private static Foo::f4() //static private extension method with=20
internal linkage
Going to think about it more, maybe using the private keyword makes sense.
=20
> On a side note, if you want some evidence for the value of this proposal,=
=20
> you should check out the Sema implementation of Clang. There's lots of=20
> static helper functions in the implementation files, they all get passed=
=20
> the Sema object, and quite a few of them should have been private members=
,=20
> because they force Sema members to be public that shouldn't have been.
>
Interesting, I'll take a look at this. A real world example would add a lot=
=20
of support to the proposal. Thank you for bringing it to my attention.
On Tuesday, December 10, 2013 4:53:34 PM UTC-5, Klaim - Jo=EBl Lamotte wro=
te:
> This proposal is interesting.
>
> Minor side comment: I'm not sure if the word "method" is used correctly=
=20
> here. I see what you mean but my understanding is that depending on the=
=20
> language, method can mean virtual member function.
> I remember C++ people saying that in C++ we should use member function to=
=20
> clarify that it have nothing to do with dynamic dispatch.
>
I haven't heard that before but you might be right. I'll double check and=
=20
fix the wording. Thanks.
=20
>
> More importantly:
> I would like to see a paragraph exploring if it feature could or not allo=
w=20
> of the interface "leak", potentially breaking the encapsulation, maybe no=
t=20
> in a harmful way, I'm not sure.
> I mean: at first read of this proposal, it looks like it's not possible t=
o=20
> call an extended private member function without it being called by anoth=
er=20
> member function that ultimately
> would be in the class interface.
>
The extension methods are private and thus can only be access by members of=
=20
the class. I don't see how encapsulation could be broken by being able to=
=20
add more private methods. I'd love it if someone could come up with a=20
counter example. I haven't been able to find any.
=20
> However, it seems possible to break the encapsulation this way:
>
> ///////////////////////////////////////////////////////////////////
> // Header "mylib.hpp" from an library "MyLib"
>
> namespace mylib
> {
>
> class Foo
> {
> // ...
> private:
> int k; // never exposed in the public interface
> };
> }
>
> ///////////////////////////////////////////////////////////////////////
> // header "mycode.hpp" in the user code
>
> #include <mylib.hpp>
>
> namespace mylib
> {
> int* Foo::get_k() { return &this->k; } // private extension
> }
>
> ///////////////////////////////////////////////////////////////////
> // cpp in the user code
> #include <mycode.hpp>
>
>
> void break_in( mylib::Foo& foo )
> {
> auto private_k_ptr =3D foo.get_k(); // accessing private member=
s=20
> "legally"
> }
>
> ////////////////////////////////////////////////////////////////////////
>
> Could you clarify what would prevent this to be allowed? If it is allowed=
,=20
> then maybe clarifying if it's not a problem?
> And if it is a problem, then I think the proposal is problematic.
> However I'm not expert so I certainly missed something?
>
This will not compile. In break_in() you're calling a Foo::get_k() which is=
=20
private. The fact that it is defined outside of the class doesn't change=20
anything.
=20
On Tuesday, December 10, 2013 4:57:30 PM UTC-5, Klaim - Jo=EBl Lamotte wrot=
e:
>
>
> To add to my previous comment:
> Basically it looks to me that until we have a way to hide the types of th=
e=20
> private member data, I can't see how it would be possible to avoid this=
=20
> kind of encapsulation breakage.
>
If you want to hide the types of private data you have to use PIMPL. This=
=20
is already supported.
On Tuesday, December 10, 2013 5:11:44 PM UTC-5, Nevin ":-)" Liber wrote:
>
> On 9 December 2013 21:26, Andrew Tomazos <andrew...@gmail.com> wrote:
>
>>
>> I think the main resistance you will receive is from people that claim=
=20
>> that this would break encapsulation. =20
>>
>
> Claim? Are you claiming this doesn't break encapsulation?
>
I am claiming with all seriousness that this doesn't break encapsulation.=
=20
The number of private methods and their signatures are implementation=20
details because they are not accessible by direct users or child classes=20
who inherit. In addition, non-virtual private methods are not required to=
=20
be in the class definition by the compiler in the same way that the private=
=20
data members are. Implementation details do not belong in the interface.=20
For that reason, *my proposal actually provides better encapsulation* than=
=20
the current C++ class model.
=20
On Tuesday, December 10, 2013 5:46:11 PM UTC-5, Vicente J. Botet Escriba=20
wrote:
>
> Hi,
>
> there is a C++ idiom that provides most of the advantages of your proposa=
l=20
> (see http://viboes.blogspot.fr/2010/04/pimpl-variant.html).
> It consists in declaring a friend detail class.
>
> //foo.hh
> class Foo {* struct detail;** friend **detail;* public:
> Foo();
> void pub1();
> void pub2();
> private:
>
> int _i;
> int _j;
> };
>
> //foo.cc=20
>
> struct Foo::*detail* {
>
> Foo& that;
>
> *detail*(Foo* f) : that(*f) {}
> //Definition of _priv1()
> void _priv1() {
> /* function body */
> } //A new scoped private extension method.
> static void _priv3() {
> that._i =3D 3;
> }
> };
>
>
> //Definition of Foo::pub1()
> void Foo::pub1() {
> *detail*(this)._priv1();
> *detail*(this)._priv3();
> }
>
> This idiom solves most of the problem the proposal address and doesn't=20
> have the drawback pointed by J=F6el, as the detail class is private and n=
o=20
> other can add private functions.
>
> There are some holes on this idiom as friend is not transitive so other=
=20
> friend classes could not access the backdoor functions neither.
>
I've seen these kinds of idioms before. They go most of the way but there=
=20
are still some drawbacks:
* The syntax is not natural. Instead of direct access to the data members=
=20
you have to indirect through your 'that' pointer.
* You still have to declare the friend class in your class definition. Thus=
=20
there is still an implementation dependency required in the interface. If=
=20
you want to make any changes, it changes the interface and forces a=20
recompile to the users.
* The set of extensions are now fixed within your friend class definition=
=20
and as you mentioned before, friends are not transitive so you cannot make=
=20
another friend to extend further. Private extension methods give you the=20
ultimate freedom in implementation without breaking encapsulation. They=20
don't depend on hacks like friends and nested classes.
That being said, I should probably list some of these examples and explain=
=20
why my proposal is better.
> I don't see any benefit to inline calls to private functions that would b=
e=20
> defined in a .cc file as your
>
> //Forward declaration of a private extension method
> void Foo::_priv2();
>
> //Inlined public method calls the private extension method
> inline void Foo::pub2() { _priv2(); }
>
>
> inlining the _priv2() call would result on the same code.
>
>
> I don't see neither the needed to declare new private functions on=20
> different files. Could you explain where this could be useful.
>
I've had plenty of situations where a class is implemented in multiple cc=
=20
files in order to better separate concerns. I find myself doing this more=
=20
for classes that implement "Application Logic." Usually singular concepts=
=20
such as data structures are implemented in one cc file, if not entirely in=
=20
the header due to templates.
In this situation, you would have your public header with the class=20
definition, a private header with some extension method declarations, and=
=20
finally multiple cc files with the definitions and possibly more file=20
scoped extension methods as needed.
Declaring an extension method in the same header as the class definition=20
has little if no value. That's merely a stylistic choice. I included it=20
just to show the possibilities.
=20
>
>
> Maybe the idiom could be adapted to a language proposal that could avoid=
=20
> the cumbersome use of the that variable. It could consists in declaring a=
=20
> pseudo-struct declaration e.g. private Foo, that could contain only=20
> functions. These functions would be accessible only by the class Foo and=
=20
> any friend of Foo. Of course, in order to other classes to be able to use=
=20
> these private functions, the private pseudo-struct should be declared in=
=20
> another file.
>
> //foo.hh
> class Foo {
> public:
> Foo();
> void pub1();
> void pub2();
> private:
>
> int _i;
> int _j;
> };
>
> //foo.cc
> *private* Foo {
> //Definition of _priv1()
> void _priv1() {
> /* function body */
> } //A new scoped private extension method.
> static void _priv3() {
> _i =3D 3;
> }
> };
>
> =20
This is an interesting idea. Essentially reopening the scope to add more=20
private stuff. Not only could you add new private methods but also private=
=20
typedefs and nested classes as well. In the old thread (see github for the=
=20
link), someone was essentially proposing this idea. He wanted to use a=20
concept of class namespaces, but I like your syntax better.
>
> //Definition of Foo::pub1()
> void Foo::pub1() {
> _priv1();
> _priv3();
> }
>
>
> It is clear that all this would have less sense with modules.
>
Modules. Who knows what they are or when we will have them. I want=20
something to solve my problems now. Also this can be a step towards modules=
..
=20
On Tuesday, December 10, 2013 6:15:34 PM UTC-5, Nevin ":-)" Liber wrote:
>
>
> I am strongly against making it this trivial to ignore encapsulation.
>
>
Please provide an example where a private extension method can be used to=
=20
easily ignore encapsulation, outside of the already existing exploits=20
mentioned in Herb's article.
On Tuesday, December 10, 2013 6:27:49 PM UTC-5, Klaim - Jo=EBl Lamotte wrot=
e:
>
> However, it is really easy to get any private data exposed in the class=
=20
> definition using extends methods,
> without having to change the class definition at all (which is worse than=
=20
> friend which at least force the user
> to change the library code, which have huge impact on maintenance, which=
=20
> is a big pressure not to do so
> if it's not for a bugfix but for abuse).
>
Again, do you have an example using my proposal that makes it easy to=20
violate access control? I would like to see an example that doesn't involve=
=20
violating the ODR rule, defining private to public, or using template=20
specialization as in Herbs Article.
=20
>
> I'm not sure if it would be possible to modify your proposal so that it=
=20
> gives similar garantees to inner classes,=20
> but with easier syntax? At the moment I can't think of a good way.
>
I don't think inner classes are affected by this proposal.
=20
>
> Side comment: It looks like the issue the proposal is trying to partially=
=20
> fix is really hard to improve without changing at least a bit=20
> the compilation model itself.
>
Not sure what you mean, can you clarify?
On Tuesday, December 10, 2013 7:20:23 PM UTC-5, Ville Voutilainen wrote:
> On 11 December 2013 00:59, Vicente J. Botet Escriba=20
> <vicent...@wanadoo.fr> wrote:=20
> > Le 10/12/13 23:46, Thiago Macieira a =E9crit :=20
> >> class Bar;=20
> >> class Foo=20
> >> {=20
> >> // ...=20
> >> private:=20
> >> int k;=20
> >> friend Bar;=20
> >> };=20
> >>=20
> >>=20
> >> /// hack.cpp=20
> >> class Bar=20
> >> {=20
> >> static int &get_k(Foo *d) { return d->k; }=20
> >> };=20
> >>=20
> >>=20
> >> To be honest, I don't know what the standard says about two different=
=20
> >> declarations of the same class in the same application but not the sam=
e=20
> >> translation unit. But the above will compile in most ABIs.=20
> >=20
> > This violated the ODR.=20
>
>
>
> Which bit of it does that, exactly?=20
>
If Foo declares Bar as a friend. Its likely that Bar is also going to be=20
defined in the same library or application. You're redefining Bar in the=20
hack.cc file and thus you violated the ODR.=20
On Tuesday, December 10, 2013 7:33:31 PM UTC-5, Richard Smith wrote:
>
>
> Here's one way to violate encapsulation with this extension:
>
> class A {
> int n;
> public:
> A() : n(42) {}
> };
>
> template<typename T> struct X {
> static decltype(T()()) t;
> };
> template<typename T> decltype(T()()) X<T>::t =3D T()();
>
> int A::*p;
> private int A::expose_private_member() { // note, not called anywhere
> struct DoIt {
> int operator()() {
> p =3D &A::n;
> return 0;
> }
> };
> return X<DoIt>::t; // odr-use of X<DoIt>::t triggers instantiation
> }
>
> int main() {
> A a;
> return a.*p; // read private member
> }
> =20
>
There is our example. I tested it and it does work (you can test it by just=
=20
declaring expose_private_member() in the class definition). Still this is=
=20
so complex that I think it belongs as the 4th example Herb's article.
I will include this example in the proposal.
On Tuesday, December 10, 2013 7:34:33 PM UTC-5, David Krauss wrote:
>
>
> A better way to violate privileges without violating the ODR would be to=
=20
> explicitly specialize a member of Bar which cannot be named by another=20
> TU. There are other tricks based on specialization.=20
>
This is also mentioned in Herb's article. Nothing new from my proposal.
=20
>
> What if a derived class meeting some strict requirements could be=20
> defined as alias-compatible with the base, such that an object of a base=
=20
> class could be used as the interface, and suitably casted used as the=20
> implementation?=20
>
You can do that now if you change your private members to protected and=20
then inherit. This exposes your private members to legatimate child classes=
=20
though and is a huge break in encapsulation.
=20
>
> Extension methods are nice to have and closely related to modules.=20
> Perhaps someone can draft a modules-compatible, self-contained extension=
=20
> providing private implementation semantics, and get a head start on ABI=
=20
> work related to consequences in the type system.=20
>
I'm going ahead with this proposal. I don't think it gets in the way of=20
modules.
Thank you everyone for your feedback some great ideas here. I will try to=
=20
incorporate all of the feedback into the next draft.=20
=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_477_12966560.1386730511760
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Wow lots of comments. <div><br></div><div>Before I an=
swer the comments, I'd like to emphasize this article which someone else ha=
s already mentioned. <a href=3D"http://www.gotw.ca/gotw/076.htm">http:=
//www.gotw.ca/gotw/076.htm</a></div><div><br></div><div>Here, Herb Sutter t=
alks about ways in current C++ that you can break encapsulation. I don't be=
lieve my feature adds any new ways to get at private data that don't alread=
y exist.</div><div><br></div><div>What we want to avoid is allowing an easy=
to use "break encapsulation here" feature. If someone can break encapsulat=
ion by doing the horrible things mentioned in that article, that's ok. Acce=
ss control in C++ is not a security feature, its a productivity and organiz=
ation feature. It helps you write good code, its not designed to save lives=
..</div><div><br></div><div>With that, lets get started..<br><div><br></div>=
<div>On Tuesday, December 10, 2013 10:17:29 AM UTC-5, corn...@google.com wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; b=
order-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-s=
tyle: solid; padding-left: 1ex;"><div dir=3D"ltr"><br><div>Hi,</div><div><b=
r></div><div>I love this proposal and wanted to do pretty much the same thi=
ng for some time.</div><div><br></div></div></blockquote><div>Good to know =
someone is annoyed by this restriction as I am.</div><div> </div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: sol=
id; padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>In "Alternate Synt=
ax", you say: "<span style=3D"color: rgb(0, 0, 0); font-family: 'Times New =
Roman'; font-size: medium;">One downside of the current approach is that pr=
eviously if the user wrote a typo when writing a member function name in th=
e definition they would get a helpful compilation error."</span></div><div>=
<br></div><div>In my opinion, this is a deal breaker. </div></div></blockqu=
ote><div><br></div><div>I don't think its a huge deal breaker, since the er=
ror will be caught at link time. But I'm not too concerned with the syntax,=
as long as this feature makes it in.</div><div> </div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1=
px; border-left-color: rgb(204, 204, 204); border-left-style: solid; paddin=
g-left: 1ex;"><div dir=3D"ltr"><div>I think it's absolutely necessary to us=
e a keyword for this, and I strongly recommend using 'private'. </div></div=
></blockquote><div><br></div><div>Actually using a keyword nicely solves th=
e static dilemna:</div><div><br></div><div>private Foo::f1() //private exte=
nsion method</div><div>private static Foo::f2() //static private method</di=
v><div>static private Foo::f3() //private extension method with internal li=
nkage</div><div>static private static Foo::f4() //static private extension =
method with internal linkage</div><div><br></div><div>Going to think about =
it more, maybe using the private keyword makes sense.</div><div> </div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-styl=
e: solid; padding-left: 1ex;"><div dir=3D"ltr"><div>On a side note, if you =
want some evidence for the value of this proposal, you should check out the=
Sema implementation of Clang. There's lots of static helper functions in t=
he implementation files, they all get passed the Sema object, and quite a f=
ew of them should have been private members, because they force Sema member=
s to be public that shouldn't have been.</div></div></blockquote><div><br><=
/div><div>Interesting, I'll take a look at this. A real world example would=
add a lot of support to the proposal. Thank you for bringing it to my atte=
ntion.</div><div><br></div><div> <span style=3D"font-size: 13px;">On T=
uesday, December 10, 2013 4:53:34 PM UTC-5, Klaim - Jo=EBl Lamotte wrote:</=
span></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border=
-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr"><div>This proposal=
is interesting.</div><div><br></div><div>Minor side comment: I'm not sure =
if the word "method" is used correctly here. I see what you mean but my und=
erstanding is that depending on the language, method can mean virtual membe=
r function.<br>I remember C++ people saying that in C++ we should use membe=
r function to clarify that it have nothing to do with dynamic dispatch.</di=
v></div></blockquote><div><br></div><div>I haven't heard that before but yo=
u might be right. I'll double check and fix the wording. Thanks.</div><div>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); borde=
r-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><d=
iv>More importantly:</div><div>I would like to see a paragraph exploring if=
it feature could or not allow of the interface "leak", potentially breakin=
g the encapsulation, maybe not in a harmful way, I'm not sure.</div><div>I =
mean: at first read of this proposal, it looks like it's not possible to ca=
ll an extended private member function without it being called by another m=
ember function that ultimately<br>would be in the class interface.</div></d=
iv></blockquote><div><br></div><div>The extension methods are private and t=
hus can only be access by members of the class. I don't see how encapsulati=
on could be broken by being able to add more private methods. I'd love it i=
f someone could come up with a counter example. I haven't been able to find=
any.</div><div> </div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, =
204, 204); border-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr"><=
div>However, it seems possible to break the encapsulation this way:</div><d=
iv><br></div><div>//////////////////////////////<wbr>//////////////////////=
////////<wbr>///////<br></div><div>// Header "mylib.hpp" from an library "M=
yLib"</div><div><br></div><div>namespace mylib</div><div>{</div><div><br></=
div><div> class Foo</div><div> {</div><div> &=
nbsp; // ...</div><div> private:</div><div> =
int k; // never exposed in the public interface</div><=
div> };</div><div>}</div><div><br></div><div>//////////////////=
////////////<wbr>//////////////////////////////<wbr>///////////</div><div>/=
/ header "mycode.hpp" in the user code</div><div><br></div><div>#include &l=
t;mylib.hpp></div><div><br></div><div><div>namespace mylib</div><div>{</=
div><div> int* Foo::get_k() { return &this->k; } // pri=
vate extension</div><div>}</div><div><br></div><div>///////////////////////=
///////<wbr>//////////////////////////////<wbr>///////<br></div></div><div>=
// cpp in the user code</div><div>#include <mycode.hpp></div><div><br=
></div><div><br></div><div><div> void break_in( mylib::Foo&=
foo )</div><div> {</div><div> auto =
private_k_ptr =3D foo.get_k(); // accessing private members "le=
gally"</div><div> }</div><div><br></div></div><div>////////////=
//////////////////<wbr>//////////////////////////////<wbr>////////////</div=
><div><br></div><div>Could you clarify what would prevent this to be allowe=
d? If it is allowed, then maybe clarifying if it's not a problem?<br>And if=
it is a problem, then I think the proposal is problematic.<br>However I'm =
not expert so I certainly missed something?</div></div></blockquote><div><b=
r></div><div>This will not compile. In break_in() you're calling a Foo::get=
_k() which is private. The fact that it is defined outside of the class doe=
sn't change anything.</div><div> </div></div></div><div><br>On Tuesday=
, December 10, 2013 4:57:30 PM UTC-5, Klaim - Jo=EBl Lamotte wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-w=
idth: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>To add to my prev=
ious comment:</div><div>Basically it looks to me that until we have a way t=
o hide the types of the private member data, I can't see how it would be po=
ssible to avoid this kind of encapsulation breakage.</div></div></blockquot=
e><div><br></div><div>If you want to hide the types of private data you hav=
e to use PIMPL. This is already supported.</div></div><div><br></div><div>O=
n Tuesday, December 10, 2013 5:11:44 PM UTC-5, Nevin ":-)" Liber wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-le=
ft-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: so=
lid; padding-left: 1ex;"><div dir=3D"ltr">On 9 December 2013 21:26, Andrew =
Tomazos <span dir=3D"ltr"><<a target=3D"_blank" gdf-obfuscated-mail=
to=3D"j_LGmWwSragJ" style=3D"color: rgb(102, 17, 204);">andrew...@gmail.com=
</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width=
: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; pad=
ding-left: 1ex;"><div dir=3D"ltr"><br><div>I think the main resistance you =
will receive is from people that claim that this would break encapsulation.=
</div></div></blockquote><div><br></div><div>Claim? Are you cl=
aiming this doesn't break encapsulation?</div></div></div></div></blockquot=
e><div><br></div><div>I am claiming with all seriousness that this doesn't =
break encapsulation. The number of private methods and their signatures are=
implementation details because they are not accessible by direct users or =
child classes who inherit. In addition, non-virtual private methods are not=
required to be in the class definition by the compiler in the same way tha=
t the private data members are. Implementation details do not belong in the=
interface. For that reason, <b>my proposal actually provides better encaps=
ulation</b> than the current C++ class model.</div><div> </div></div><=
div><br><br>On Tuesday, December 10, 2013 5:46:11 PM UTC-5, Vicente J. Bote=
t Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); b=
order-left-style: solid; padding-left: 1ex;"><div text=3D"#000000" bgcolor=
=3D"#FFFFFF">Hi,<br><br>there is a C++ idiom that provides most of the adva=
ntages of your proposal (see <a href=3D"http://viboes.blogspot.fr/2010=
/04/pimpl-variant.html" target=3D"_blank">http://viboes.blogspot.fr/<wbr>20=
10/04/pimpl-variant.html</a>).<br>It consists in declaring a friend detail =
class.<br><br><pre><code>//foo.hh
class Foo {
</code><code><b> struct detail;</b><b>
</b></code><code><b> friend </b></code><code><b><code><b>detail</b></code>=
;</b><b>
</b></code>
<code> public:
Foo();
void pub1();
void pub2();
private:
int _i;
int _j;
};</code></pre>//foo.cc <br><pre><code></code>
<code>struct Foo::</code><code><code><b>detail</b></code> {
Foo& that;
</code><code><code><b>detail</b></code>(Foo* f) : that(*f) {}
</code><code><code> //Definition of _priv1()
void _priv1() {
/* function body */
}
</code>
</code><code><code> //A new scoped private extension method.
static void _priv3() {
that._i =3D 3;
}
</code>
};
//Definition of Foo::pub1()
void Foo::pub1() {
</code><code><code><b>detail</b></code>(this)._priv1();
</code><code><b>detail</b></code><code><code>(this).</code>_priv3();
}</code></pre>This idiom solves most of the problem the proposal address an=
d doesn't have the drawback pointed by J=F6el, as the detail class is priva=
te and no other can add private functions.</div></blockquote><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: =
1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; paddi=
ng-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF"><br>There are some=
holes on this idiom as friend is not transitive so other friend classes co=
uld not access the backdoor functions neither.<br></div></blockquote><div><=
br></div><div>I've seen these kinds of idioms before. They go most of the w=
ay but there are still some drawbacks:</div><div>* The syntax is not natura=
l. Instead of direct access to the data members you have to indirect throug=
h your 'that' pointer.</div><div>* You still have to declare the friend cla=
ss in your class definition. Thus there is still an implementation dependen=
cy required in the interface. If you want to make any changes, it changes t=
he interface and forces a recompile to the users.</div><div><span style=3D"=
font-size: 13px;">* The set of extensions are now fixed within your friend<=
/span> class definition and as you mentioned before, friends are not t=
ransitive so you cannot make another friend to extend further. Private exte=
nsion methods give you the ultimate freedom in implementation without break=
ing encapsulation. They don't depend on hacks like friends and nested class=
es.</div><div><br></div><div>That being said, I should probably list some o=
f these examples and explain why my proposal is better.</div><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-styl=
e: solid; padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF"><br=
>I don't see any benefit to inline calls to private functions that would be=
defined in a .cc file as your<br><pre><code>//Forward declaration of a pri=
vate extension method
void Foo::_priv2();
//Inlined public method calls the private extension method
inline void Foo::pub2() { _priv2(); }
</code></pre><pre><big><code>inlining the _priv2() call would result on the=
same code.</code></big>
<code></code></pre><code></code><br><big><code>I don't see neither the need=
ed to declare new private functions on different files. Could you explain w=
here this could be useful.</code></big></div></blockquote><div><br></div><d=
iv>I've had plenty of situations where a class is implemented in multiple c=
c files in order to better separate concerns. I find myself doing this more=
for classes that implement "Application Logic." Usually singular concepts =
such as data structures are implemented in one cc file, if not entirely in =
the header due to templates.</div><div><br></div><div>In this situation, yo=
u would have your public header with the class definition, a private header=
with some extension method declarations, and finally multiple cc files wit=
h the definitions and possibly more file scoped extension methods as needed=
..</div><div><br></div><div>Declaring an extension method in the same header=
as the class definition has little if no value. That's merely a stylistic =
choice. I included it just to show the possibilities.</div><div> </div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-styl=
e: solid; padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF"><br=
><code></code><br>Maybe the idiom could be adapted to a language proposal t=
hat could avoid the cumbersome use of the that variable. It could consists =
in declaring a pseudo-struct declaration e.g. private Foo, that could conta=
in only functions. These functions would be accessible only by the class Fo=
o and any friend of Foo. Of course, in order to other classes to be able to=
use these private functions, the private pseudo-struct should be declared =
in another file.<br><br><pre><code><code>//foo.hh
class Foo {
public:
Foo();
void pub1();
void pub2();
private:
int _i;
int _j;
};</code>
//foo.cc
</code><code><code><code><b>private</b></code></code> Foo</code><code> {
</code><code><code> //Definition of _priv1()
void _priv1() {
/* function body */
}
</code>
</code><code><code> //A new scoped private extension method.
static void _priv3() {
_i =3D 3;
}
</code>
};
</code></pre></div></blockquote><div> </div><div>This is an interestin=
g idea. Essentially reopening the scope to add more private stuff. Not only=
could you add new private methods but also private typedefs and nested cla=
sses as well. In the old thread (see github for the link), someone was esse=
ntially proposing this idea. He wanted to use a concept of class namespaces=
, but I like your syntax better.</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; bor=
der-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left:=
1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF"><pre><code>
//Definition of Foo::pub1()
void Foo::pub1() {
_priv1();
</code><code>_priv3();
}</code></pre><br>It is clear that all this would have less sense with modu=
les.<br></div></blockquote><div><br></div><div>Modules. Who knows what they=
are or when we will have them. I want something to solve my problems now. =
Also this can be a step towards modules.</div><div> </div></div><div><=
br></div><div>On Tuesday, December 10, 2013 6:15:34 PM UTC-5, Nevin ":-)" L=
iber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border=
-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmai=
l_quote"><div><font face=3D"Arial, Arial, Helvetica"><br></font></div><div>=
<font face=3D"Arial, Arial, Helvetica">I am strongly against making it this=
trivial to ignore encapsulation.<br></font></div><div><font face=3D"Arial,=
Arial, Helvetica"></font></div></div><br></div></blockquote><div><br></div=
><div>Please provide an example where a private extension method can be use=
d to easily ignore encapsulation, outside of the already existing exploits =
mentioned in Herb's article.</div></div><div><br></div><div>On Tuesday, Dec=
ember 10, 2013 6:27:49 PM UTC-5, Klaim - Jo=EBl Lamotte wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-wi=
dth: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; =
padding-left: 1ex;"><div dir=3D"ltr"><div><div><br></div><div>However, it i=
s really easy to get any private data exposed in the class definition using=
extends methods,</div><div>without having to change the class definition a=
t all (which is worse than friend which at least force the user</div><div>t=
o change the library code, which have huge impact on maintenance, which is =
a big pressure not to do so</div><div>if it's not for a bugfix but for abus=
e).</div></div></div></blockquote><div><br></div><div>Again, do you have an=
example using my proposal that makes it easy to violate access control? I =
would like to see an example that doesn't involve violating the ODR rule, d=
efining private to public, or using template specialization as in Herbs Art=
icle.</div><div> </div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, =
204, 204); border-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr"><=
div><div><br></div><div>I'm not sure if it would be possible to modify your=
proposal so that it gives similar garantees to inner classes, </div><=
div>but with easier syntax? At the moment I can't think of a good way.</div=
></div></div></blockquote><div><br></div><div>I don't think inner classes a=
re affected by this proposal.</div><div> </div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; bord=
er-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: =
1ex;"><div dir=3D"ltr"><div><div><br></div><div>Side comment: It looks like=
the issue the proposal is trying to partially fix is really hard to improv=
e without changing at least a bit <br>the compilation model itself.</d=
iv></div></div></blockquote><div><br></div><div>Not sure what you mean, can=
you clarify?</div><div><br></div><div> <span style=3D"font-size: 13px=
;">On Tuesday, December 10, 2013 7:20:23 PM UTC-5, Ville Voutilainen wrote:=
</span></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); bord=
er-left-style: solid; padding-left: 1ex;">On 11 December 2013 00:59, Vicent=
e J. Botet Escriba <br><<a target=3D"_blank" gdf-obfuscated-mailto=
=3D"oiq0Osgys0sJ" style=3D"color: rgb(102, 17, 204);">vicent...@wanadoo.fr<=
/a>> wrote: <br>> Le 10/12/13 23:46, Thiago Macieira a =E9crit :=
<br>>> class Bar; <br>>> class Foo <br>>>=
{ <br>>> // ... <br>>> private:&=
nbsp;<br>>> int k; <br>>>  =
; friend Bar; <br>>> }; <br>>> <br>>>=
; <br>>> /// hack.cpp <br>>> class Bar <br>>&=
gt; { <br>>> static int &get_k(Foo *d) {=
return d->k; } <br>>> }; <br>>> <br>>>=
<br>>> To be honest, I don't know what the standard says about =
two different <br>>> declarations of the same class in the same =
application but not the same <br>>> translation unit. But the ab=
ove will compile in most ABIs. <br>> <br>> This violated th=
e ODR. <br><br><br><br>Which bit of it does that, exactly? <br></=
blockquote><div><br></div><div>If Foo declares Bar as a friend. Its likely =
that Bar is also going to be defined in the same library or application. Yo=
u're redefining Bar in the hack.cc file and thus you violated the ODR. =
;</div></div><div><br></div><div>On Tuesday, December 10, 2013 7:33:31 PM U=
TC-5, Richard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 20=
4, 204); border-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr"><di=
v class=3D"gmail_quote"><div><div><br></div><div>Here's one way to violate =
encapsulation with this extension:</div><div><br></div><div>class A {</div>=
<div> int n;</div><div>public:</div><div> A() : n(42) {}</div><=
div>};</div><div><br></div><div>template<typename T> struct X {<br></=
div><div> static decltype(T()()) t;</div><div>};</div><div>template&l=
t;typename T> decltype(T()()) X<T>::t =3D T()();</div></div></div>=
</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204)=
; border-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr"><div class=
=3D"gmail_quote"><div><div><div><br></div><div>int A::*p;</div></div><div>p=
rivate int A::expose_private_member() { // note, not called anywhere<br></d=
iv><div> struct DoIt {</div><div> int operator()() {</di=
v><div> p =3D &A::n;</div><div> =
return 0;</div><div> }</div><div> };</div><div> r=
eturn X<DoIt>::t; // odr-use of X<DoIt>::t triggers instantiati=
on</div><div>}</div><div><br></div><div>int main() {</div><div> A a;<=
/div><div> return a.*p; // read private member</div><div>}</div></div=
><div> </div></div></div></blockquote><div><br></div><div>There is our=
example. I tested it and it does work (you can test it by just declaring e=
xpose_private_member() in the class definition). Still this is so complex t=
hat I think it belongs as the 4th example Herb's article.</div><div><br>I w=
ill include this example in the proposal.</div><div><br></div><div><br></di=
v><div><br>On Tuesday, December 10, 2013 7:34:33 PM UTC-5, David Krauss wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bo=
rder-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-st=
yle: solid; padding-left: 1ex;"><br>A better way to violate privileges with=
out violating the ODR would be to <br>explicitly specialize a member o=
f Bar which cannot be named by another <br>TU. There are other tricks =
based on specialization. <br></blockquote><div><br></div><div>This is =
also mentioned in Herb's article. Nothing new from my proposal.</div><div>&=
nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border=
-left-style: solid; padding-left: 1ex;"><br>What if a derived class meeting=
some strict requirements could be <br>defined as alias-compatible wit=
h the base, such that an object of a base <br>class could be used as t=
he interface, and suitably casted used as the <br>implementation? =
;<br></blockquote><div><br></div><div>You can do that now if you change you=
r private members to protected and then inherit. This exposes your private =
members to legatimate child classes though and is a huge break in encapsula=
tion.</div><div> </div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, =
204, 204); border-left-style: solid; padding-left: 1ex;"><br>Extension meth=
ods are nice to have and closely related to modules. <br>Perhaps someo=
ne can draft a modules-compatible, self-contained extension <br>provid=
ing private implementation semantics, and get a head start on ABI <br>=
work related to consequences in the type system. <br></blockquote><div=
><br></div><div>I'm going ahead with this proposal. I don't think it gets i=
n the way of modules.</div><div><br></div><div>Thank you everyone for your =
feedback some great ideas here. I will try to incorporate all of the feedba=
ck into the next draft. </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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_477_12966560.1386730511760--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 11 Dec 2013 06:52:32 +0100
Raw View
Le 11/12/13 01:20, Ville Voutilainen a =E9crit :
> On 11 December 2013 00:59, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr> wrote:
>> Le 10/12/13 23:46, Thiago Macieira a =E9crit :
>>> class Bar;
>>> class Foo
>>> {
>>> // ...
>>> private:
>>> int k;
>>> friend Bar;
>>> };
>>>
>>>
>>> /// hack.cpp
>>> class Bar
>>> {
>>> static int &get_k(Foo *d) { return d->k; }
>>> };
>>>
>>>
>>> To be honest, I don't know what the standard says about two different
>>> declarations of the same class in the same application but not the same
>>> translation unit. But the above will compile in most ABIs.
>> This violated the ODR.
>
>
> Which bit of it does that, exactly?
>
I expect that the class Bar will be defined somewhere else and that it=20
is not only here to hack, but maybe I miss something.
Vicente
--=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/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 11 Dec 2013 07:19:14 +0100
Raw View
This is a multi-part message in MIME format.
--------------090704040105000503010704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/12/13 03:55, fmatthew5876@gmail.com a =E9crit :
> Wow lots of comments.
>
>
>
> I don't see any benefit to inline calls to private functions that
> would be defined in a .cc file as your
>
> |//Forward declaration of a private extension method
> void Foo::_priv2();
>
> //Inlined public method calls the private extension method
> inline void Foo::pub2() { _priv2(); }
>
> |
>
> |inlining the _priv2() call would result on the same code.|
> ||
>
> ||
> |I don't see neither the needed to declare new private functions
> on different files. Could you explain where this could be useful.|
>
>
> I've had plenty of situations where a class is implemented in multiple=20
> cc files in order to better separate concerns. I find myself doing=20
> this more for classes that implement "Application Logic." Usually=20
> singular concepts such as data structures are implemented in one cc=20
> file, if not entirely in the header due to templates.
>
> In this situation, you would have your public header with the class=20
> definition, a private header with some extension method declarations,=20
> and finally multiple cc files with the definitions and possibly more=20
> file scoped extension methods as needed.
I understand your use case. Reducing compilation dependencies between=20
implementation of different classes seems to me the problem to address.=20
While taking care of the case where multiple files implements a specific=20
class would be nice, it is for me a corner case.
>
> Declaring an extension method in the same header as the class=20
> definition has little if no value. That's merely a stylistic choice. I=20
> included it just to show the possibilities.
So we agree this is not a must have.
>
>
> ||
> Maybe the idiom could be adapted to a language proposal that could
> avoid the cumbersome use of the that variable. It could consists
> in declaring a pseudo-struct declaration e.g. private Foo, that
> could contain only functions. These functions would be accessible
> only by the class Foo and any friend of Foo. Of course, in order
> to other classes to be able to use these private functions, the
> private pseudo-struct should be declared in another file.
>
> ||//foo.hh
> class Foo {
> public:
> Foo();
> void pub1();
> void pub2();
> private:
>
> int _i;
> int _j;
> };|
>
> //foo.cc
>
> ||||*private*|| Foo|| {
>
> ||| //Definition of _priv1()
> void _priv1() {
> /* function body */
> }
> |
> ||| //A new scoped private extension method.
> static void _priv3() {
> _i =3D 3;
> }
> |
> };
> |
>
> This is an interesting idea. Essentially reopening the scope to add=20
> more private stuff. Not only could you add new private methods but=20
> also private typedefs and nested classes as well. In the old thread=20
> (see github for the link), someone was essentially proposing this=20
> idea. He wanted to use a concept of class namespaces, but I like your=20
> syntax better.
Note that for me the scope could be reopened only once. In order to=20
avoid that the user can do it on any class it would be better to=20
restrict it to class that have declared it. E.g. we could declare the=20
class friend of itself.
||//foo.hh
class Foo {
*friend* Foo;
||
};
>
> |
>
> //Definition of Foo::pub1()
> void Foo::pub1() {
> _priv1();
> ||_priv3();
> }|
>
>
> It is clear that all this would have less sense with modules.
>
>
> Modules. Who knows what they are or when we will have them. I want=20
> something to solve my problems now. Also this can be a step towards=20
> modules.
You are right, but you will not have a new feature before 2017 as minor=20
as it can be.
Vicente
--=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/.
--------------090704040105000503010704
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Le 11/12/13 03:55,
<a class="moz-txt-link-abbreviated" href="mailto:fmatthew5876@gmail.com">fmatthew5876@gmail.com</a> a écrit :<br>
</div>
<blockquote
cite="mid:566b4320-4f64-4d14-ac61-6eb94c536967@isocpp.org"
type="cite">
<div dir="ltr">Wow lots of comments.
<div><br>
</div>
<div><br>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left-width: 1px; border-left-color: rgb(204,
204, 204); border-left-style: solid; padding-left: 1ex;">
<div text="#000000" bgcolor="#FFFFFF"><br>
I don't see any benefit to inline calls to private
functions that would be defined in a .cc file as your<br>
<pre><code>//Forward declaration of a private extension method
void Foo::_priv2();
//Inlined public method calls the private extension method
inline void Foo::pub2() { _priv2(); }
</code></pre>
<pre><big><code>inlining the _priv2() call would result on the same code.</code></big>
<code></code></pre>
<code></code><br>
<big><code>I don't see neither the needed to declare new
private functions on different files. Could you
explain where this could be useful.</code></big></div>
</blockquote>
<div><br>
</div>
<div>I've had plenty of situations where a class is
implemented in multiple cc files in order to better separate
concerns. I find myself doing this more for classes that
implement "Application Logic." Usually singular concepts
such as data structures are implemented in one cc file, if
not entirely in the header due to templates.</div>
<div><br>
</div>
<div>In this situation, you would have your public header with
the class definition, a private header with some extension
method declarations, and finally multiple cc files with the
definitions and possibly more file scoped extension methods
as needed.</div>
</div>
</div>
</blockquote>
I understand your use case. Reducing compilation dependencies
between implementation of different classes seems to me the problem
to address. While taking care of the case where multiple files
implements a specific class would be nice, it is for me a corner
case. <br>
<blockquote
cite="mid:566b4320-4f64-4d14-ac61-6eb94c536967@isocpp.org"
type="cite">
<div dir="ltr">
<div>
<div><br>
</div>
<div>Declaring an extension method in the same header as the
class definition has little if no value. That's merely a
stylistic choice. I included it just to show the
possibilities.</div>
</div>
</div>
</blockquote>
So we agree this is not a must have.<br>
<blockquote
cite="mid:566b4320-4f64-4d14-ac61-6eb94c536967@isocpp.org"
type="cite">
<div dir="ltr">
<div>
<div> </div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left-width: 1px; border-left-color: rgb(204,
204, 204); border-left-style: solid; padding-left: 1ex;">
<div text="#000000" bgcolor="#FFFFFF"><br>
<code></code><br>
Maybe the idiom could be adapted to a language proposal
that could avoid the cumbersome use of the that variable.
It could consists in declaring a pseudo-struct declaration
e.g. private Foo, that could contain only functions. These
functions would be accessible only by the class Foo and
any friend of Foo. Of course, in order to other classes to
be able to use these private functions, the private
pseudo-struct should be declared in another file.<br>
<br>
<pre><code><code>//foo.hh
class Foo {
public:
Foo();
void pub1();
void pub2();
private:
int _i;
int _j;
};</code>
//foo.cc
</code><code><code><code><b>private</b></code></code> Foo</code><code> {
</code><code><code> //Definition of _priv1()
void _priv1() {
/* function body */
}
</code>
</code><code><code> //A new scoped private extension method.
static void _priv3() {
_i = 3;
}
</code>
};
</code></pre>
</div>
</blockquote>
<div> </div>
<div>This is an interesting idea. Essentially reopening the
scope to add more private stuff. Not only could you add new
private methods but also private typedefs and nested classes
as well. In the old thread (see github for the link),
someone was essentially proposing this idea. He wanted to
use a concept of class namespaces, but I like your syntax
better.</div>
</div>
</div>
</blockquote>
Note that for me the scope could be reopened only once. In order to
avoid that the user can do it on any class it would be better to
restrict it to class that have declared it. E.g. we could declare
the class friend of itself.<br>
<br>
<pre><code><code>//foo.hh
class Foo {
<b>friend</b> Foo;
</code></code></pre>
};<br>
<br>
<br>
<blockquote
cite="mid:566b4320-4f64-4d14-ac61-6eb94c536967@isocpp.org"
type="cite">
<div dir="ltr">
<div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left-width: 1px; border-left-color: rgb(204,
204, 204); border-left-style: solid; padding-left: 1ex;">
<div text="#000000" bgcolor="#FFFFFF">
<pre><code>
//Definition of Foo::pub1()
void Foo::pub1() {
_priv1();
</code><code>_priv3();
}</code></pre>
<br>
It is clear that all this would have less sense with
modules.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Modules. Who knows what they are or when we will have
them. I want something to solve my problems now. Also this
can be a step towards modules.</div>
</div>
</div>
</blockquote>
You are right, but you will not have a new feature before 2017 as
minor as it can be.<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------090704040105000503010704--
.
Author: fmatthew5876@gmail.com
Date: Tue, 10 Dec 2013 22:38:20 -0800 (PST)
Raw View
------=_Part_4365_21716991.1386743900243
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wednesday, December 11, 2013 1:19:14 AM UTC-5, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 11/12/13 03:55, fmatth...@gmail.com <javascript:> a =E9crit :
> =20
> Wow lots of comments. =20
>
> =20
> =20
>> I don't see any benefit to inline calls to private functions that would=
=20
>> be defined in a .cc file as your
>>
>> //Forward declaration of a private extension method
>> void Foo::_priv2();
>>
>> //Inlined public method calls the private extension method
>> inline void Foo::pub2() { _priv2(); }
>>
>>
>> inlining the _priv2() call would result on the same code.
>>
>>
>> I don't see neither the needed to declare new private functions on=20
>> different files. Could you explain where this could be useful.
>>
>
> I've had plenty of situations where a class is implemented in multiple=
=20
> cc files in order to better separate concerns. I find myself doing this=
=20
> more for classes that implement "Application Logic." Usually singular=20
> concepts such as data structures are implemented in one cc file, if not=
=20
> entirely in the header due to templates.
>
> In this situation, you would have your public header with the class=20
> definition, a private header with some extension method declarations, and=
=20
> finally multiple cc files with the definitions and possibly more file=20
> scoped extension methods as needed.
> =20
> I understand your use case. Reducing compilation dependencies between=20
> implementation of different classes seems to me the problem to address.=
=20
> While taking care of the case where multiple files implements a specific=
=20
> class would be nice, it is for me a corner case. =20
>
Reducing dependencies by minimizing the interface is the name of the game=
=20
here. I agree that multiple source files is a corner case, but I'd like to=
=20
support it as it is useful sometimes.=20
> =20
> Declaring an extension method in the same header as the class definition=
=20
> has little if no value. That's merely a stylistic choice. I included it=
=20
> just to show the possibilities.
> =20
> So we agree this is not a must have.
>
Yes, but if you can declare a private extension method just like a regular=
=20
free function, there's no reason shouldn't be able to do it in the class=20
header. I suppose one corner use case is conditional compilation. One=20
version may want to call an inline PEM, while another does not (PEM is=20
#ifdefed out).
> =20
>
>>
>>
>> Maybe the idiom could be adapted to a language proposal that could avoid=
=20
>> the cumbersome use of the that variable. It could consists in declaring =
a=20
>> pseudo-struct declaration e.g. private Foo, that could contain only=20
>> functions. These functions would be accessible only by the class Foo and=
=20
>> any friend of Foo. Of course, in order to other classes to be able to us=
e=20
>> these private functions, the private pseudo-struct should be declared in=
=20
>> another file.
>>
>> //foo.hh
>> class Foo {
>> public:
>> Foo();
>> void pub1();
>> void pub2();
>> private:
>>
>> int _i;
>> int _j;
>> };
>>
>> //foo.cc
>> *private* Foo {
>> //Definition of _priv1()
>> void _priv1() {
>> /* function body */
>> } //A new scoped private extension method.
>> static void _priv3() {
>> _i =3D 3;
>> }
>> };
>>
>> =20
> This is an interesting idea. Essentially reopening the scope to add more=
=20
> private stuff. Not only could you add new private methods but also privat=
e=20
> typedefs and nested classes as well. In the old thread (see github for th=
e=20
> link), someone was essentially proposing this idea. He wanted to use a=20
> concept of class namespaces, but I like your syntax better.
> =20
> Note that for me the scope could be reopened only once. In order to avoid=
=20
> that the user can do it on any class it would be better to restrict it to=
=20
> class that have declared it. E.g. we could declare the class friend of=20
> itself.
>
Why the restrictions? Can you demonstrate a case where allowing this=20
feature everywhere would cause a problem? How is this better than using a=
=20
nested class (see workarounds in my new draft on github for an example).=20
>
> //foo.hh
> class Foo {
> *friend* Foo;
>
> };
>
This again is putting an implementation detail (the fact that we will=20
reopen the class to implement it) in the interface. It seems unnecessary to=
=20
me.=20
>
>
> =20
> =20
>>
>> //Definition of Foo::pub1()
>> void Foo::pub1() {
>> _priv1();
>> _priv3();
>> }
>>
>>
>> It is clear that all this would have less sense with modules.
>> =20
>
> Modules. Who knows what they are or when we will have them. I want=20
> something to solve my problems now. Also this can be a step towards modul=
es.
> =20
> You are right, but you will not have a new feature before 2017 as minor a=
s=20
> it can be.
>
=20
Will we even have modules in 2017? There is no guarantee of that.=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_4365_21716991.1386743900243
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, December 11, 2013 1:19:14 AM UTC-5, =
Vicente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Le 11/12/13 03:55,
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"TX=
2JPAgpBrwJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">fmatth...@gmail.com</a> a =E9cr=
it :<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">Wow lots of comments.
<div><br>
</div>
<div><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><br>
I don't see any benefit to inline calls to private
functions that would be defined in a .cc file as your<br>
<pre><code>//Forward declaration of a private extension metho=
d
void Foo::_priv2();
//Inlined public method calls the private extension method
inline void Foo::pub2() { _priv2(); }
</code></pre>
<pre><big><code>inlining the _priv2() call would result on th=
e same code.</code></big>
<code></code></pre>
<code></code><br>
<big><code>I don't see neither the needed to declare new
private functions on different files. Could you
explain where this could be useful.</code></big></div>
</blockquote>
<div><br>
</div>
<div>I've had plenty of situations where a class is
implemented in multiple cc files in order to better separate
concerns. I find myself doing this more for classes that
implement "Application Logic." Usually singular concepts
such as data structures are implemented in one cc file, if
not entirely in the header due to templates.</div>
<div><br>
</div>
<div>In this situation, you would have your public header with
the class definition, a private header with some extension
method declarations, and finally multiple cc files with the
definitions and possibly more file scoped extension methods
as needed.</div>
</div>
</div>
</blockquote>
I understand your use case. Reducing compilation dependencies
between implementation of different classes seems to me the problem
to address. While taking care of the case where multiple files
implements a specific class would be nice, it is for me a corner
case. <br></div></blockquote><div><br></div><div>Reducing depende=
ncies by minimizing the interface is the name of the game here. I agree tha=
t multiple source files is a corner case, but I'd like to support it as it =
is useful sometimes. </div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div><br>
</div>
<div>Declaring an extension method in the same header as the
class definition has little if no value. That's merely a
stylistic choice. I included it just to show the
possibilities.</div>
</div>
</div>
</blockquote>
So we agree this is not a must have.<br></div></blockquote><div><br></d=
iv><div>Yes, but if you can declare a private extension method just like a =
regular free function, there's no reason shouldn't be able to do it in the =
class header. I suppose one corner use case is conditional compilation. One=
version may want to call an inline PEM, while another does not (PEM is #if=
defed out).</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div text=3D"=
#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div> </div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><br>
<code></code><br>
Maybe the idiom could be adapted to a language proposal
that could avoid the cumbersome use of the that variable.
It could consists in declaring a pseudo-struct declaration
e.g. private Foo, that could contain only functions. These
functions would be accessible only by the class Foo and
any friend of Foo. Of course, in order to other classes to
be able to use these private functions, the private
pseudo-struct should be declared in another file.<br>
<br>
<pre><code><code>//foo.hh
class Foo {
public:
Foo();
void pub1();
void pub2();
private:
int _i;
int _j;
};</code>
//foo.cc
</code><code><code><code><b>private</b></code></code> Foo</code><code> {
</code><code><code> //Definition of _priv1()
void _priv1() {
/* function body */
}
</code>
</code><code><code> //A new scoped private extension method.
static void _priv3() {
_i =3D 3;
}
</code>
};
</code></pre>
</div>
</blockquote>
<div> </div>
<div>This is an interesting idea. Essentially reopening the
scope to add more private stuff. Not only could you add new
private methods but also private typedefs and nested classes
as well. In the old thread (see github for the link),
someone was essentially proposing this idea. He wanted to
use a concept of class namespaces, but I like your syntax
better.</div>
</div>
</div>
</blockquote>
Note that for me the scope could be reopened only once. In order to
avoid that the user can do it on any class it would be better to
restrict it to class that have declared it. E.g. we could declare
the class friend of itself.<br></div></blockquote><div><br></div><div>W=
hy the restrictions? Can you demonstrate a case where allowing this feature=
everywhere would cause a problem? How is this better than using a nested c=
lass (see workarounds in my new draft on github for an example). </div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=
=3D"#FFFFFF">
<br>
<pre><code><code>//foo.hh
class Foo {
<b>friend</b> Foo;
</code></code></pre>
};<br></div></blockquote><div>This again is putting an implementation d=
etail (the fact that we will reopen the class to implement it) in the inter=
face. It seems unnecessary to me. </div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
<br>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<pre><code>
//Definition of Foo::pub1()
void Foo::pub1() {
_priv1();
</code><code>_priv3();
}</code></pre>
<br>
It is clear that all this would have less sense with
modules.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Modules. Who knows what they are or when we will have
them. I want something to solve my problems now. Also this
can be a step towards modules.</div>
</div>
</div>
</blockquote>
You are right, but you will not have a new feature before 2017 as
minor as it can be.<br></div></blockquote><div><span style=3D"font-size=
: 13px;"> </span><br></div><div>Will we even have modules in 2017? The=
re is no guarantee of that. </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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_4365_21716991.1386743900243--
.
Author: fmatthew5876@gmail.com
Date: Tue, 10 Dec 2013 22:40:36 -0800 (PST)
Raw View
------=_Part_4390_11583035.1386744036317
Content-Type: text/plain; charset=ISO-8859-1
Everyone, I have written a new draft after taking in all of the feedback.
It is available on github.
With regards to method vs member function. It looks like some people use
them interchangably while others prefer "method" for virtual functions. I
am going to continue using the work method as its already in the name of
the proposal.
On Monday, December 9, 2013 9:20:46 PM UTC-5, fmatth...@gmail.com wrote:
>
> Hello everyone, I am going to submit a proposal for relaxing the
> restriction on requiring private non-virtual class methods and static
> private class methods to be declared in the class definition.
>
> The github repository with the current draft of the proposal is here:
> https://github.com/fmatthew5876/stdcxx-privext
>
> The proposal came out of the discussion from this thread:
>
> https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4NBUJ
>
>
--
---
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_4390_11583035.1386744036317
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Everyone, I have written a new draft after taking in all o=
f the feedback. It is available on github.<div><br></div><div>With regards =
to method vs member function. It looks like some people use them interchang=
ably while others prefer "method" for virtual functions. I am going to cont=
inue using the work method as its already in the name of the proposal.<br><=
br>On Monday, December 9, 2013 9:20:46 PM UTC-5, fmatth...@gmail.com wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><span st=
yle=3D"font-size:13px">Hello everyone, I am going to submit a proposal for =
relaxing the restriction on requiring private non-virtual class methods and=
static private class methods to be declared in the class definition.</span=
><br></div><div><br></div><div>The github repository with the current draft=
of the proposal is here:</div><div><a href=3D"https://github.com/fmatthew5=
876/stdcxx-privext" target=3D"_blank" onmousedown=3D"this.href=3D'https://w=
ww.google.com/url?q\75https%3A%2F%2Fgithub.com%2Ffmatthew5876%2Fstdcxx-priv=
ext\46sa\75D\46sntz\0751\46usg\75AFQjCNHUdaGAiICCLmRPFXPiWoor3W2hjA';return=
true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%=
2Fgithub.com%2Ffmatthew5876%2Fstdcxx-privext\46sa\75D\46sntz\0751\46usg\75A=
FQjCNHUdaGAiICCLmRPFXPiWoor3W2hjA';return true;">https://github.com/<wbr>fm=
atthew5876/stdcxx-privext</a><br></div><div><br></div><div>The proposal cam=
e out of the discussion from this thread:<div><a href=3D"https://groups.goo=
gle.com/a/isocpp.org/forum/#!searchin/std-proposals/private/std-proposals/x=
ukd1mgd21I/akgZSTG4NBUJ" target=3D"_blank" onmousedown=3D"this.href=3D'http=
s://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/private/s=
td-proposals/xukd1mgd21I/akgZSTG4NBUJ';return true;" onclick=3D"this.href=
=3D'https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/p=
rivate/std-proposals/xukd1mgd21I/akgZSTG4NBUJ';return true;">https://groups=
..google.com/a/<wbr>isocpp.org/forum/#!searchin/<wbr>std-proposals/private/s=
td-<wbr>proposals/xukd1mgd21I/<wbr>akgZSTG4NBUJ</a><br></div></div><div><br=
></div></div></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_4390_11583035.1386744036317--
.
Author: mitchnull@gmail.com
Date: Wed, 11 Dec 2013 01:23:00 -0800 (PST)
Raw View
------=_Part_1160_22385915.1386753780961
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, December 11, 2013 3:55:11 AM UTC+1, fmatth...@gmail.com wrote:
[SNIP]
> Actually using a keyword nicely solves the static dilemna:
>
> private Foo::f1() //private extension method
> private static Foo::f2() //static private method
> static private Foo::f3() //private extension method with internal linkage
> static private static Foo::f4() //static private extension method with
> internal linkage
>
> Going to think about it more, maybe using the private keyword makes sense.
>
I think using the private keyword like this is good, but I would prefer to
make all PEMs internal linkage by default and use extern or some other
keyword in the few cases where you want them to be reachable from other TUs
and still not declare them in the class.
Also, making "private static" and "static private" different things is
just too confusing / ugly in my opinion (but that's minor compared to my
strong preference towards making PEMs internal linkage by default, thus
avoiding this use of the static keyword 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/.
------=_Part_1160_22385915.1386753780961
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, December 11, 2013 3:55:11 AM UTC+1, =
fmatth...@gmail.com wrote:<div><br></div><div><div><span style=3D"font-size=
: 13px;">[SNIP]</span></div><div> </div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div><span style=3D"font-size: 13px;">Actua=
lly using a keyword nicely solves the static dilemna:</span><br></div><div>=
<div><br></div><div>private Foo::f1() //private extension method</div><div>=
private static Foo::f2() //static private method</div><div>static private F=
oo::f3() //private extension method with internal linkage</div><div>static =
private static Foo::f4() //static private extension method with internal li=
nkage</div><div><br></div><div>Going to think about it more, maybe using th=
e private keyword makes sense.</div></div></div></blockquote><div><br></div=
><div>I think using the private keyword like this is good, but I would pref=
er to make all PEMs internal linkage by default and use extern or some othe=
r keyword in the few cases where you want them to be reachable from other T=
Us and still not declare them in the class.</div><div>Also, making "p=
rivate static" and "static private" different things is just too confusing =
/ ugly in my opinion (but that's minor compared to my strong preference tow=
ards making PEMs internal linkage by default, thus avoiding this use of the=
static keyword here).</div></div><div><br></div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1160_22385915.1386753780961--
.
Author: inkwizytoryankes@gmail.com
Date: Wed, 11 Dec 2013 08:55:46 -0800 (PST)
Raw View
------=_Part_178_3097056.1386780946935
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
You are right, I dont except side effects like calling arbitrary function=
=20
in function definition.
On Wednesday, December 11, 2013 1:33:31 AM UTC+1, Richard Smith wrote:
>
> On Tue, Dec 10, 2013 at 3:47 PM, <inkwizyt...@gmail.com <javascript:>>wro=
te:
>
>> isnt private extension still private? I every one can create private=20
>> function but only private function can call it you can only create dead=
=20
>> code.
>> To even call any new private extension you need have at least one normal=
=20
>> member function to call it.
>>
>
> This isn't true; you can use this extension to violate encapsulation (as =
I=20
> demonstrated on the previous discussion thread on this topic). That said,=
=20
> it's difficult, and it's *very* unlikely that you'd do it by accident.
>
> Here's one way to violate encapsulation with this extension:
>
> class A {
> int n;
> public:
> A() : n(42) {}
> };
>
> template<typename T> struct X {
> static decltype(T()()) t;
> };
> template<typename T> decltype(T()()) X<T>::t =3D T()();
>
> int A::*p;
> private int A::expose_private_member() { // note, not called anywhere
> struct DoIt {
> int operator()() {
> p =3D &A::n;
> return 0;
> }
> };
> return X<DoIt>::t; // odr-use of X<DoIt>::t triggers instantiation
> }
>
> int main() {
> A a;
> return a.*p; // read private member
> }
> =20
>
>> On Tuesday, December 10, 2013 10:53:34 PM UTC+1, Klaim - Jo=EBl Lamotte=
=20
>> wrote:
>>>
>>> This proposal is interesting.
>>>
>>> Minor side comment: I'm not sure if the word "method" is used correctly=
=20
>>> here. I see what you mean but my understanding is that depending on the=
=20
>>> language, method can mean virtual member function.
>>> I remember C++ people saying that in C++ we should use member function=
=20
>>> to clarify that it have nothing to do with dynamic dispatch.
>>>
>>> More importantly:
>>> I would like to see a paragraph exploring if it feature could or not=20
>>> allow of the interface "leak", potentially breaking the encapsulation,=
=20
>>> maybe not in a harmful way, I'm not sure.
>>> I mean: at first read of this proposal, it looks like it's not possible=
=20
>>> to call an extended private member function without it being called by=
=20
>>> another member function that ultimately
>>> would be in the class interface.
>>> However, it seems possible to break the encapsulation this way:
>>>
>>> ///////////////////////////////////////////////////////////////////
>>> // Header "mylib.hpp" from an library "MyLib"
>>>
>>> namespace mylib
>>> {
>>>
>>> class Foo
>>> {
>>> // ...
>>> private:
>>> int k; // never exposed in the public interface
>>> };
>>> }
>>>
>>> ///////////////////////////////////////////////////////////////////////
>>> // header "mycode.hpp" in the user code
>>>
>>> #include <mylib.hpp>
>>>
>>> namespace mylib
>>> {
>>> int* Foo::get_k() { return &this->k; } // private extension
>>> }
>>>
>>> ///////////////////////////////////////////////////////////////////
>>> // cpp in the user code
>>> #include <mycode.hpp>
>>>
>>>
>>> void break_in( mylib::Foo& foo )
>>> {
>>> auto private_k_ptr =3D foo.get_k(); // accessing private memb=
ers=20
>>> "legally"
>>> }
>>>
>>> ///////////////////////////////////////////////////////////////////////=
/
>>>
>>> Could you clarify what would prevent this to be allowed? If it is=20
>>> allowed, then maybe clarifying if it's not a problem?
>>> And if it is a problem, then I think the proposal is problematic.
>>> However I'm not expert so I certainly missed something?
>>>
>>> --=20
>> =20
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> 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/.
------=_Part_178_3097056.1386780946935
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You are right, I dont except side effects like calling arb=
itrary function in function definition.<br><br>On Wednesday, December 11, 2=
013 1:33:31 AM UTC+1, Richard Smith wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Tue, Dec 10=
, 2013 at 3:47 PM, <span dir=3D"ltr"><<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"t3-AZPL6RQgJ" onmousedown=3D"this.href=3D=
'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;">inkwizyt...@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">isnt private extension still private? I e=
very one can create private function but only private function can call it =
you can only create dead code.<br>
To even call any new private extension you need have at least one normal me=
mber function to call it.</div></blockquote><div><br></div><div><div>This i=
sn't true; you can use this extension to violate encapsulation (as I demons=
trated on the previous discussion thread on this topic). That said, it's di=
fficult, and it's *very* unlikely that you'd do it by accident.</div>
<div><br></div><div>Here's one way to violate encapsulation with this exten=
sion:</div><div><br></div><div>class A {</div><div> int n;</div><div>=
public:</div><div> A() : n(42) {}</div><div>};</div><div><br></div><d=
iv>
template<typename T> struct X {<br></div><div> static decltype(=
T()()) t;</div><div>};</div><div>template<typename T> decltype(T()())=
X<T>::t =3D T()();</div><div><div><br></div><div>int A::*p;</div></d=
iv>
<div>private int A::expose_private_member() { // note, not called anywhere<=
br></div><div> struct DoIt {</div><div> int operator()()=
{</div><div> p =3D &A::n;</div><div> =
return 0;</div><div> }</div><div>
};</div><div> return X<DoIt>::t; // odr-use of X<DoIt=
>::t triggers instantiation</div><div>}</div><div><br></div><div>int mai=
n() {</div><div> A a;</div><div> return a.*p; // read private m=
ember</div><div>
}</div></div><div> </div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div>
On Tuesday, December 10, 2013 10:53:34 PM UTC+1, Klaim - Jo=EBl Lamotte wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex">
<div dir=3D"ltr"><div>This proposal is interesting.</div><div><br></div><di=
v>Minor side comment: I'm not sure if the word "method" is used correctly h=
ere. I see what you mean but my understanding is that depending on the lang=
uage, method can mean virtual member function.<br>
I remember C++ people saying that in C++ we should use member function to c=
larify that it have nothing to do with dynamic dispatch.</div><div><br></di=
v><div>More importantly:</div><div>
I would like to see a paragraph exploring if it feature could or not allow =
of the interface "leak", potentially breaking the encapsulation, maybe not =
in a harmful way, I'm not sure.</div><div>
I mean: at first read of this proposal, it looks like it's not possible to =
call an extended private member function without it being called by another=
member function that ultimately<br>would be in the class interface.</div>
<div>However, it seems possible to break the encapsulation this way:</div><=
div><br></div><div>//////////////////////////////<u></u><wbr>//////////////=
////////////////<u></u><wbr>///////<br>
</div><div>// Header "mylib.hpp" from an library "MyLib"</div><div><br></di=
v><div>namespace mylib</div><div>{</div><div>
<br></div><div> class Foo</div><div> {</div><div>&n=
bsp; // ...</div><div> private:</div><div>&=
nbsp; int k; // never exposed in the public interface<=
/div>
<div> };</div><div>}</div><div><br></div><div>/////////////////=
/////////////<u></u><wbr>//////////////////////////////<u></u><wbr>////////=
///</div><div>
// header "mycode.hpp" in the user code</div><div><br></div><div>#include &=
lt;mylib.hpp></div><div><br></div><div><div>
namespace mylib</div><div>{</div><div> int* Foo::get_k() { ret=
urn &this->k; } // private extension</div><div>}</div><div><br></div=
>
<div><div>//////////////////////////////<u></u><wbr>///////////////////////=
///////<u></u><wbr>///////<br></div></div></div><div>// cpp in the user cod=
e</div><div>#include <mycode.hpp></div>
<div><br></div><div><br></div><div><div> void break_in( mylib::=
Foo& foo )</div><div> {</div><div>
auto private_k_ptr =3D foo.get_k();  =
;// accessing private members "legally"</div><div> }</div><div>=
<br></div></div><div>//////////////////////////////<u></u><wbr>////////////=
//////////////////<u></u><wbr>////////////</div>
<div><br></div><div>Could you clarify what would prevent this to be allowed=
? If it is allowed, then maybe clarifying if it's not a problem?<br>And if =
it is a problem, then I think the proposal is problematic.<br>
However I'm not expert so I certainly missed something?</div><div><br></div=
></div>
</blockquote></div></div></div><div><div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
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"=
t3-AZPL6RQgJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"t3-AZPL6RQgJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</div></div></blockquote></div><br></div></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_178_3097056.1386780946935--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 11 Dec 2013 22:49:06 +0100
Raw View
--001a11c33b02c0c2b804ed4932f0
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Dec 11, 2013 at 7:40 AM, <fmatthew5876@gmail.com> wrote:
> Everyone, I have written a new draft after taking in all of the feedback.
> It is available on github.
>
>
I only read new parts but it looks far more complete, well done.
Pure curiosity question: did you thought about the potential impact this
proposal could have on some other related proposal, beyond modules?
I'm thinking about the proposal I'm not remembering the name that was
allowing calling member functions as non-member functions and vice-versa
(like it's allowed in the D language).
I suspect there might be no impact at all, just wondering if some of the
proposed syntaxes would close doors to other proposals.
> With regards to method vs member function. It looks like some people use
> them interchangably while others prefer "method" for virtual functions. I
> am going to continue using the work method as its already in the name of
> the proposal.
>
Good to know that it's not important for proposal papers.
--
---
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/.
--001a11c33b02c0c2b804ed4932f0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Dec 11, 2013 at 7:40 AM, <span dir=3D"ltr"><<a href=3D"mailto:f=
matthew5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.com</a>></sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Everyone, I have written a =
new draft after taking in all of the feedback. It is available on github.<d=
iv>
<br></div></div></blockquote><div><br></div><div>I only read new parts but =
it looks far more complete, well done.</div><div><br></div><div>Pure curios=
ity question: did you thought about the potential impact this proposal coul=
d have on some other related proposal, beyond modules?<br>
I'm thinking about the proposal I'm not remembering the name that w=
as allowing calling member functions as non-member functions and vice-versa=
(like it's allowed in the D language).<br>I suspect there might be no =
impact at all, just wondering if some of the proposed syntaxes would close =
doors to other proposals.</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div></div><div>With regards to method vs member function. It looks like =
some people use them interchangably while others prefer "method" =
for virtual functions. I am going to continue using the work method as its =
already in the name of the proposal.</div>
</div></blockquote></div><br>Good to know that it's not important for p=
roposal papers.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11c33b02c0c2b804ed4932f0--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 28 Jan 2014 17:26:37 -0800
Raw View
--bcaec548a0410b62d104f111d536
Content-Type: text/plain; charset=ISO-8859-1
Sorry this comment is too late for the mailing, but...
Rather than have 'static private static' mean something different from
'static private', have you considered giving private extension methods
interrnal linkage by default? (And require 'extern' in the presumably-rare
case that they're actually meant to be declared and used in multiple
translation units.)
On Tue, Dec 10, 2013 at 10:40 PM, <fmatthew5876@gmail.com> wrote:
> Everyone, I have written a new draft after taking in all of the feedback.
> It is available on github.
>
> With regards to method vs member function. It looks like some people use
> them interchangably while others prefer "method" for virtual functions. I
> am going to continue using the work method as its already in the name of
> the proposal.
>
>
> On Monday, December 9, 2013 9:20:46 PM UTC-5, fmatth...@gmail.com wrote:
>>
>> Hello everyone, I am going to submit a proposal for relaxing the
>> restriction on requiring private non-virtual class methods and static
>> private class methods to be declared in the class definition.
>>
>> The github repository with the current draft of the proposal is here:
>> https://github.com/fmatthew5876/stdcxx-privext
>>
>> The proposal came out of the discussion from this thread:
>> https://groups.google.com/a/isocpp.org/forum/#!searchin/
>> std-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4NBUJ
>>
>> --
>
> ---
> 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/.
--bcaec548a0410b62d104f111d536
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Sorry this comment is too late for the mailing, but...<br>=
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Rather than=
have 'static private static' mean something different from 'st=
atic private', have you considered giving private extension methods int=
errnal linkage by default? (And require 'extern' in the presumably-=
rare case that they're actually meant to be declared and used in multip=
le translation units.)</div>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Dec 10, 2=
013 at 10:40 PM, <span dir=3D"ltr"><<a href=3D"mailto:fmatthew5876@gmai=
l.com" target=3D"_blank">fmatthew5876@gmail.com</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<div dir=3D"ltr">Everyone, I have written a new draft after taking in all o=
f the feedback. It is available on github.<div><br></div><div>With regards =
to method vs member function. It looks like some people use them interchang=
ably while others prefer "method" for virtual functions. I am goi=
ng to continue using the work method as its already in the name of the prop=
osal.<div>
<div class=3D"h5"><br><br>On Monday, December 9, 2013 9:20:46 PM UTC-5, <a =
href=3D"mailto:fmatth...@gmail.com" target=3D"_blank">fmatth...@gmail.com</=
a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><span style=3D"font-size:13px">Hello everyone, I am g=
oing to submit a proposal for relaxing the restriction on requiring private=
non-virtual class methods and static private class methods to be declared =
in the class definition.</span><br>
</div><div><br></div><div>The github repository with the current draft of t=
he proposal is here:</div><div><a href=3D"https://github.com/fmatthew5876/s=
tdcxx-privext" target=3D"_blank">https://github.com/<u></u>fmatthew5876/std=
cxx-privext</a><br>
</div><div><br></div><div>The proposal came out of the discussion from this=
thread:<div><a href=3D"https://groups.google.com/a/isocpp.org/forum/#!sear=
chin/std-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4NBUJ" target=
=3D"_blank">https://groups.google.com/a/<u></u>isocpp.org/forum/#!searchin/=
<u></u>std-proposals/private/std-<u></u>proposals/xukd1mgd21I/<u></u>akgZST=
G4NBUJ</a><br>
</div></div><div><br></div></div></blockquote></div></div></div></div><div =
class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <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%2Bunsubscribe@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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--bcaec548a0410b62d104f111d536--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 29 Jan 2014 02:36:31 +0100
Raw View
--f46d044280c06da52604f111f8f8
Content-Type: text/plain; charset=UTF-8
On Wed, Jan 29, 2014 at 2:26 AM, Richard Smith <richard@metafoo.co.uk>wrote:
> Rather than have 'static private static' mean something different from
> 'static private', have you considered giving private extension methods
> interrnal linkage by default? (And require 'extern' in the presumably-rare
> case that they're actually meant to be declared and used in multiple
> translation units.)
In the published paper N3863 [1] you can find a section describing
alternatives, one of them being giving internal linkage by default (search
for "Internal Linkage by Default" or go to the end of the paper).
[1] http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3863.html
--
---
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/.
--f46d044280c06da52604f111f8f8
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 Wed, Jan 29, 2014 at 2:26 AM, Richard Smith <span dir=3D"ltr"><<a hre=
f=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk<=
/a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Rather than have 'static private static' mean some=
thing different from 'static private', have you considered giving p=
rivate extension methods interrnal linkage by default? (And require 'ex=
tern' in the presumably-rare case that they're actually meant to be=
declared and used in multiple translation units.)</blockquote>
</div><br>In the published paper N3863 [1] you can find a section describin=
g alternatives, one of them being giving internal linkage by default (searc=
h for "Internal Linkage by Default" or go to the end of the paper=
).</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">[1]=C2=A0<a=
href=3D"http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3863.html">ht=
tp://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3863.html</a></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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--f46d044280c06da52604f111f8f8--
.
Author: Matt Fioravante <fmatthew5876@gmail.com>
Date: Tue, 28 Jan 2014 19:04:49 -0800 (PST)
Raw View
------=_Part_4922_30847492.1390964689723
Content-Type: text/plain; charset=UTF-8
On Tuesday, January 28, 2014 8:26:37 PM UTC-5, Richard Smith wrote:
>
> Sorry this comment is too late for the mailing, but...
>
Never too late. The paper will undoubtedly go through many revisions so
please by all means discuss your suggestions. Even suggesting an
alternative already mentioned in the paper is useful because it shows more
people are interested in doing something a certain way.
I'm not opposed to the idea of internal linkage by default for PEMs. That's
99% of the use cases I would them for already anyway.
--
---
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_4922_30847492.1390964689723
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, January 28, 2014 8:26:37 PM UTC-5, Richard=
Smith 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">=
Sorry this comment is too late for the mailing, but...</div></blockquote><d=
iv><br></div><div>Never too late. The paper will undoubtedly go through man=
y revisions so please by all means discuss your suggestions. Even suggestin=
g an alternative already mentioned in the paper is useful because it shows =
more people are interested in doing something a certain way.</div><div><br>=
</div><div>I'm not opposed to the idea of internal linkage by default for P=
EMs. That's 99% of the use cases I would them for already anyway.</div></di=
v>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_4922_30847492.1390964689723--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 28 Jan 2014 23:41:58 -0500
Raw View
--001a1136dfc6a1da2e04f1148f13
Content-Type: text/plain; charset=ISO-8859-1
http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3863.html
- I agree with the purpose of the proposal. I write APIs for a living. I'd
prefer to keep out anything that doesn't need to be seen.
- a bug in the paper (?):
//Declare a PEM in the class header file.
//In this case, the effect is the same as declaring it within the class
//definition. Using an extension method here instead of declaring in the
//class definition is merely a stylistic choice.
Foo::_priv2();
//pub2() is inlined and calls _priv1() and _priv2(), so we need to see
//both of them at this point. This can be accomplished by including them
//within the class definition or declaring an extension method as shown
//by the examples of _priv1() and _priv2().
inline int pub2() { return _priv1() + _priv2(); }
That _priv2 needs be to (I think/hope):
private Foo::_priv2();
and the pub2() needs to be declared in the class, and qualified with Foo::
outside the class.
And/Or I don't understand what this part is trying to say.
- In general, I prefer the "reopen Foo" syntax. I don't like private
functions scattered around. You could still reopen Foo multiple times (and
thus have it scattered around) but at least you could recommend against
that in a style guideline. As an example:
void Foo::function()
{
int x = bar();
}
is bar() a member function of Foo? We can no longer just look in the class
definition to determine that. Now bar() could be declared "anywhere"
(actually anywhere above the current code, including #includes, but
practically anywhere). With reopening Foo, there will at least be a
_tendency_ for it to only be reopened at the top of the file and/or a
foo_impl.hh file.
Also reopening appears to allow private typedefs, nested classes, static
variables, etc. Which all looks good to me.
Also, a normal function can be declared within any scope. Can a PEM:
void func()
{
extern int f();
int x = f();
private int Foo::blah();
int y = someFoo.blah(); // of course func() would need to be a friend
here
}
or
void Foo::function()
{
private int blah(); // Foo:: not needed???
int x = blah();
}
- you might entertain using the 'continue' keyword to continue Foo:
class continue Foo
{
int asdf(); // PEM
};
although using 'private' does help remind us that only private stuff is
allowed.
- Internal Linkage by default: Definitely.
Tony
On Tue, Jan 28, 2014 at 10:04 PM, Matt Fioravante <fmatthew5876@gmail.com>wrote:
>
> On Tuesday, January 28, 2014 8:26:37 PM UTC-5, Richard Smith wrote:
>>
>> Sorry this comment is too late for the mailing, but...
>>
>
> Never too late. The paper will undoubtedly go through many revisions so
> please by all means discuss your suggestions. Even suggesting an
> alternative already mentioned in the paper is useful because it shows more
> people are interested in doing something a certain way.
>
> I'm not opposed to the idea of internal linkage by default for PEMs.
> That's 99% of the use cases I would them for already anyway.
>
> --
>
> ---
> 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/.
--001a1136dfc6a1da2e04f1148f13
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div><a href=3D"http://open-std.org/jtc1/sc22/wg21/doc=
s/papers/2014/n3863.html">http://open-std.org/jtc1/sc22/wg21/docs/papers/20=
14/n3863.html</a></div><div><br></div><div>- I agree with the purpose of th=
e proposal. I write APIs for a living. =A0I'd prefer to keep out anythi=
ng that doesn't need to be seen.</div>
<div><br></div><div>- a bug in the paper (?):</div><div><br></div><div>//De=
clare a PEM in the class header file.<br>//In this case, the effect is the =
same as declaring it within the class<br>//definition. Using an extension m=
ethod here instead of declaring in the<br>
//class definition is merely a stylistic choice.<br>Foo::_priv2();<br><br>/=
/pub2() is inlined and calls _priv1() and _priv2(), so we need to see<br>//=
both of them at this point. This can be accomplished by including them<br>
//within the class definition or declaring an extension method as shown<br>=
//by the examples of _priv1() and _priv2().<br>inline int pub2() { return _=
priv1() + _priv2(); }</div><div><br></div><div><br></div><div>That _priv2 n=
eeds be to (I think/hope):</div>
<div><br></div><div>private Foo::_priv2();</div><div><br></div><div>and the=
pub2() needs to be declared in the class, and qualified with Foo:: outside=
the class.</div><div><br></div><div>And/Or I don't understand what thi=
s part is trying to say.</div>
<div><br></div><div><br></div><div>- In general, I prefer the "reopen =
Foo" syntax. =A0I don't like private functions scattered around. =
=A0You could still reopen Foo multiple times (and thus have it scattered ar=
ound) but at least you could recommend against that in a style guideline. =
=A0As an example:</div>
<div><br></div><div><br></div><div>void Foo::function()</div><div>{</div><d=
iv>=A0 =A0int x =3D bar();</div><div>}</div><div><br></div><div>is bar() a =
member function of Foo? =A0We can no longer just look in the class definiti=
on to determine that. =A0Now bar() could be declared "anywhere" (=
actually anywhere above the current code, including #includes, but practica=
lly anywhere). =A0With reopening Foo, there will at least be a _tendency_ f=
or it to only be reopened at the top of the file and/or a foo_impl.hh file.=
</div>
<div><br></div><div>Also reopening appears to allow private typedefs, neste=
d classes, static variables, etc. =A0Which all looks good to me.</div><div>=
<br></div><div>Also, a normal function can be declared within any scope. Ca=
n a PEM:</div>
<div><br></div><div>void func()</div><div>{</div><div>=A0 =A0 extern int f(=
);</div><div>=A0 =A0 int x =3D f();</div><div><br></div><div>=A0 =A0 privat=
e int Foo::blah();</div><div><br></div><div>=A0 =A0 int y =3D someFoo.blah(=
); // of course func() would need to be a friend here</div>
<div>}</div><div><br></div><div>or</div><div><br></div><div>void Foo::funct=
ion()</div><div>{</div><div>=A0 =A0 private int blah(); =A0// Foo:: not nee=
ded???</div><div>=A0</div><div>=A0 =A0 int x =3D blah();</div><div>}</div><=
div><br></div>
<div><br></div><div>- you might entertain using the 'continue' keyw=
ord to continue Foo:</div><div><br></div><div>class continue Foo</div><div>=
{</div><div>=A0 =A0int asdf(); // PEM</div><div>};</div><div><br></div><div=
>
although using 'private' does help remind us that only private stuf=
f is allowed.</div><div><br></div><div><br></div><div>- Internal Linkage by=
default: =A0Definitely.</div><div><br></div><div>Tony</div><div><br></div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue,=
Jan 28, 2014 at 10:04 PM, Matt Fioravante <span dir=3D"ltr"><<a href=3D=
"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.com</a=
>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><br>On Tu=
esday, January 28, 2014 8:26:37 PM UTC-5, Richard Smith wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr">Sorry this comment is too late for the mailing, but...</di=
v></blockquote><div><br></div></div><div>Never too late. The paper will und=
oubtedly go through many revisions so please by all means discuss your sugg=
estions. Even suggesting an alternative already mentioned in the paper is u=
seful because it shows more people are interested in doing something a cert=
ain way.</div>
<div><br></div><div>I'm not opposed to the idea of internal linkage by =
default for PEMs. That's 99% of the use cases I would them for already =
anyway.</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <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%2Bunsubscribe@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>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a1136dfc6a1da2e04f1148f13--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 28 Jan 2014 23:43:38 -0500
Raw View
--089e01227c0cd3b50504f114958c
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Jan 28, 2014 at 11:41 PM, Tony V E <tvaneerd@gmail.com> wrote:
>
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3863.html
>
> - I agree with the purpose of the proposal. I write APIs for a living.
> I'd prefer to keep out anything that doesn't need to be seen.
>
> - a bug in the paper (?):
>
> //Declare a PEM in the class header file.
> //In this case, the effect is the same as declaring it within the class
> //definition. Using an extension method here instead of declaring in the
> //class definition is merely a stylistic choice.
> Foo::_priv2();
>
> //pub2() is inlined and calls _priv1() and _priv2(), so we need to see
> //both of them at this point. This can be accomplished by including them
> //within the class definition or declaring an extension method as shown
> //by the examples of _priv1() and _priv2().
> inline int pub2() { return _priv1() + _priv2(); }
>
>
> That _priv2 needs be to (I think/hope):
>
> private Foo::_priv2();
>
>
private int Foo::_priv2();
(missed the return type as well)
--
---
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/.
--089e01227c0cd3b50504f114958c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Jan 28, 2014 at 11:41 PM, Tony V E <span dir=3D"ltr"><<a=
href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a=
>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><a href=3D"http://=
open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3863.html" target=3D"_blank">=
http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3863.html</a></div>
<div><br></div><div>- I agree with the purpose of the proposal. I write API=
s for a living. =A0I'd prefer to keep out anything that doesn't nee=
d to be seen.</div>
<div><br></div><div>- a bug in the paper (?):</div><div><br></div><div>//De=
clare a PEM in the class header file.<br>//In this case, the effect is the =
same as declaring it within the class<br>//definition. Using an extension m=
ethod here instead of declaring in the<br>
//class definition is merely a stylistic choice.<br>Foo::_priv2();<br><br>/=
/pub2() is inlined and calls _priv1() and _priv2(), so we need to see<br>//=
both of them at this point. This can be accomplished by including them<br>
//within the class definition or declaring an extension method as shown<br>=
//by the examples of _priv1() and _priv2().<br>inline int pub2() { return _=
priv1() + _priv2(); }</div><div><br></div><div><br></div><div>That _priv2 n=
eeds be to (I think/hope):</div>
<div><br></div><div>private Foo::_priv2();</div><div><br></div></div></bloc=
kquote><div><br></div><div>private int Foo::_priv2();</div><div><br></div><=
div>(missed the return type as well)</div><div><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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--089e01227c0cd3b50504f114958c--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 29 Jan 2014 07:46:42 -0800 (PST)
Raw View
------=_Part_32_19936031.1391010402161
Content-Type: text/plain; charset=UTF-8
I would favor internal linkage by default. The cases when you split one
class into multiple TUs is very low. How about using the now abandoned
export keyword instead of extern for the case that you really want to work
with multiple TUs for one class. Or I would favor to make it impossible to
use private extension methods over TU borders.
The paper seems to have a bug in the nested class workaround example:
X:doWork must send *this rather than x to worker methods!
The table at the top of the paper does not list static data members. It
would be possible to add private static data PEM-style. However the value
is very limited as it is only a naming difference. However I think it
should be in the table and be explained why it is not needed.
Den tisdagen den 28:e januari 2014 kl. 20:43:38 UTC-8 skrev Tony V E:
>
>
>
>
> On Tue, Jan 28, 2014 at 11:41 PM, Tony V E <tvan...@gmail.com<javascript:>
> > wrote:
>
>>
>> http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3863.html
>>
>> - I agree with the purpose of the proposal. I write APIs for a living.
>> I'd prefer to keep out anything that doesn't need to be seen.
>>
>> - a bug in the paper (?):
>>
>> //Declare a PEM in the class header file.
>> //In this case, the effect is the same as declaring it within the class
>> //definition. Using an extension method here instead of declaring in the
>> //class definition is merely a stylistic choice.
>> Foo::_priv2();
>>
>> //pub2() is inlined and calls _priv1() and _priv2(), so we need to see
>> //both of them at this point. This can be accomplished by including them
>> //within the class definition or declaring an extension method as shown
>> //by the examples of _priv1() and _priv2().
>> inline int pub2() { return _priv1() + _priv2(); }
>>
>>
>> That _priv2 needs be to (I think/hope):
>>
>> private Foo::_priv2();
>>
>>
> private int Foo::_priv2();
>
> (missed the return type as well)
>
>
--
---
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_32_19936031.1391010402161
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I would favor internal linkage by default. The cases when =
you split one class into multiple TUs is very low. How about using the now =
abandoned export keyword instead of extern for the case that you really wan=
t to work with multiple TUs for one class. Or I would favor to make it impo=
ssible to use private extension methods over TU borders.<div><br></div><div=
><br></div><div>The paper seems to have a bug in the nested class workaroun=
d example:</div><div><br></div><div>X:doWork must send *this rather than x =
to worker methods!</div><div><br></div><div><br></div><div>The table at the=
top of the paper does not list static data members. It would be possible t=
o add private static data PEM-style. However the value is very limited as i=
t is only a naming difference. However I think it should be in the table an=
d be explained why it is not needed.<br><div><br></div><div><br></div><div>=
<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>=
<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>=
<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>=
<br></div><div><br></div><div><br></div><div><br></div><div><br><br>Den tis=
dagen den 28:e januari 2014 kl. 20:43:38 UTC-8 skrev Tony V E:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><br><br><div clas=
s=3D"gmail_quote">On Tue, Jan 28, 2014 at 11:41 PM, Tony V E <span dir=3D"l=
tr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Y40Go9UrIUUJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">tvan...@gmail.com</a>></spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><a href=3D"http://=
open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3863.html" target=3D"_blank" =
onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fopen=
-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn3863.html\46sa\75D\=
46sntz\0751\46usg\75AFQjCNEW4fC0dnxjcMuBqwogmoRsEKgZWg';return true;" oncli=
ck=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%=
2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn3863.html\46sa\75D\46sntz\07=
51\46usg\75AFQjCNEW4fC0dnxjcMuBqwogmoRsEKgZWg';return true;">http://open-st=
d.org/jtc1/sc22/<wbr>wg21/docs/papers/2014/n3863.<wbr>html</a></div>
<div><br></div><div>- I agree with the purpose of the proposal. I write API=
s for a living. I'd prefer to keep out anything that doesn't need to =
be seen.</div>
<div><br></div><div>- a bug in the paper (?):</div><div><br></div><div>//De=
clare a PEM in the class header file.<br>//In this case, the effect is the =
same as declaring it within the class<br>//definition. Using an extension m=
ethod here instead of declaring in the<br>
//class definition is merely a stylistic choice.<br>Foo::_priv2();<br><br>/=
/pub2() is inlined and calls _priv1() and _priv2(), so we need to see<br>//=
both of them at this point. This can be accomplished by including them<br>
//within the class definition or declaring an extension method as shown<br>=
//by the examples of _priv1() and _priv2().<br>inline int pub2() { return _=
priv1() + _priv2(); }</div><div><br></div><div><br></div><div>That _priv2 n=
eeds be to (I think/hope):</div>
<div><br></div><div>private Foo::_priv2();</div><div><br></div></div></bloc=
kquote><div><br></div><div>private int Foo::_priv2();</div><div><br></div><=
div>(missed the return type as well)</div><div><br></div></div></div></div>
</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_32_19936031.1391010402161--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Wed, 29 Jan 2014 17:53:48 -0800 (PST)
Raw View
------=_Part_179_11725474.1391046828804
Content-Type: text/plain; charset=UTF-8
On Tuesday, January 28, 2014 11:41:58 PM UTC-5, Tony V E wrote:
>
> That _priv2 needs be to (I think/hope):
>
> private Foo::_priv2();
>
Thanks, fixed in the latest draft.
>
> and the pub2() needs to be declared in the class, and qualified with Foo::
> outside the class.
>
>
Wow, I'm pretty bad. This is what happens when you rely on inline
compilation too much ;)
> And/Or I don't understand what this part is trying to say.
>
>
> - In general, I prefer the "reopen Foo" syntax. I don't like private
> functions scattered around. You could still reopen Foo multiple times (and
> thus have it scattered around) but at least you could recommend against
> that in a style guideline. As an example:
>
>
> void Foo::function()
> {
> int x = bar();
> }
>
> is bar() a member function of Foo? We can no longer just look in the
> class definition to determine that. Now bar() could be declared "anywhere"
> (actually anywhere above the current code, including #includes, but
> practically anywhere). With reopening Foo, there will at least be a
> _tendency_ for it to only be reopened at the top of the file and/or a
> foo_impl.hh file.
>
Internal linkage by default also sort of solves this problem. All of the
PEMs should be found within the same file as the call site.
>
> Also reopening appears to allow private typedefs, nested classes, static
> variables, etc. Which all looks good to me.
>
>
I'm not sure how useful these things would be in practice when you can just
create these objects with internal linkage. I'm not against it though,
especially if someone can come up with a compelling use case.
> Also, a normal function can be declared within any scope. Can a PEM:
>
> void func()
> {
> extern int f();
> int x = f();
>
> private int Foo::blah();
>
> int y = someFoo.blah(); // of course func() would need to be a friend
> here
> }
>
Sure why not
> or
>
> void Foo::function()
> {
> private int blah(); // Foo:: not needed???
>
> int x = blah();
> }
>
>
Would need to think if removing the Foo:: could cause any conflicts or
ambiguities. I don't think it matters much either way.
> - you might entertain using the 'continue' keyword to continue Foo:
>
> class continue Foo
> {
> int asdf(); // PEM
> };
>
> although using 'private' does help remind us that only private stuff is
> allowed.
>
> I like private better, reusing random keywords is confusing. continue has
to do with loops, private is for access control in classes.
>
> - Internal Linkage by default: Definitely.
>
Looks like this is getting more votes. I might have to shift the next
version of the paper in this direction.
On Wednesday, January 29, 2014 10:46:42 AM UTC-5, Bengt Gustafsson wrote:
>
> I would favor internal linkage by default.
>
And there is another.
> The cases when you split one class into multiple TUs is very low. How
> about using the now abandoned export keyword instead of extern for the case
> that you really want to work with multiple TUs for one class. Or I would
> favor to make it impossible to use private extension methods over TU
> borders.
>
Definitely prefer extern over export because thats what the extern keyword
already does. You use extern to give thinks external linkage, why use
something else in the case of a PEM?
>
> The paper seems to have a bug in the nested class workaround example:
>
> X:doWork must send *this rather than x to worker methods!
>
> Thank you for catching that. Fixed in latest draft.
>
> The table at the top of the paper does not list static data members. It
> would be possible to add private static data PEM-style. However the value
> is very limited as it is only a naming difference. However I think it
> should be in the table and be explained why it is not needed.
>
> I also didn't mention typedefs, enums, and nested classes. I'll consider
these additions on the next revision.
--
---
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_179_11725474.1391046828804
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, January 28, 2014 11:41:58 PM UTC-5, Tony V E w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-=
style: solid; padding-left: 1ex;"><div dir=3D"ltr"><div>That _priv2 needs b=
e to (I think/hope):</div><div><br></div><div>private Foo::_priv2();</div><=
/div></blockquote><div><br>Thanks, fixed in the latest draft.</div><div><br=
></div><div> </div><blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204,=
204); border-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr"><div>=
<br></div><div>and the pub2() needs to be declared in the class, and qualif=
ied with Foo:: outside the class.</div><div><br></div></div></blockquote><d=
iv><br></div><div>Wow, I'm pretty bad. <span style=3D"font-size: 13px;=
">This is what happens when you rely on inline compilation too much ;)</spa=
n></div><div> </div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204=
, 204); border-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr"><div=
></div><div>And/Or I don't understand what this part is trying to say.</div=
><div><br></div><div><br></div><div>- In general, I prefer the "reopen Foo"=
syntax. I don't like private functions scattered around. You c=
ould still reopen Foo multiple times (and thus have it scattered around) bu=
t at least you could recommend against that in a style guideline. As =
an example:</div><div><br></div><div><br></div><div>void Foo::function()</d=
iv><div>{</div><div> int x =3D bar();</div><div>}</div><div><br=
></div><div>is bar() a member function of Foo? We can no longer just =
look in the class definition to determine that. Now bar() could be de=
clared "anywhere" (actually anywhere above the current code, including #inc=
ludes, but practically anywhere). With reopening Foo, there will at l=
east be a _tendency_ for it to only be reopened at the top of the file and/=
or a foo_impl.hh file.</div></div></blockquote><div><br></div><div>Internal=
linkage by default also sort of solves this problem. All of the PEMs shoul=
d be found within the same file as the call site.</div><div> </div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-l=
eft-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: s=
olid; padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>Also reopeni=
ng appears to allow private typedefs, nested classes, static variables, etc=
.. Which all looks good to me.</div><div><br></div></div></blockquote>=
<div><br></div><div>I'm not sure how useful these things would be in practi=
ce when you can just create these objects with internal linkage. I'm not ag=
ainst it though, especially if someone can come up with a compelling use ca=
se.</div><div><br></div><div> </div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-col=
or: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div =
dir=3D"ltr"><div></div><div>Also, a normal function can be declared within =
any scope. Can a PEM:</div><div><br></div><div>void func()</div><div>{</div=
><div> extern int f();</div><div> int x =3D f();<=
/div><div><br></div><div> private int Foo::blah();</div><div><=
br></div><div> int y =3D someFoo.blah(); // of course func() w=
ould need to be a friend here</div><div>}</div></div></blockquote><div><br>=
</div><div>Sure why not </div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border=
-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1e=
x;"><div dir=3D"ltr"><div><br></div><div>or</div><div><br></div><div>void F=
oo::function()</div><div>{</div><div> private int blah(); &nbs=
p;// Foo:: not needed???</div><div> </div><div> int x =3D=
blah();</div><div>}</div><div><br></div></div></blockquote><div><br></div>=
<div>Would need to think if removing the Foo:: could cause any conflicts or=
ambiguities. I don't think it matters much either way.</div><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-styl=
e: solid; padding-left: 1ex;"><div dir=3D"ltr"><div></div><div><br></div><d=
iv>- you might entertain using the 'continue' keyword to continue Foo:</div=
><div><br></div><div>class continue Foo</div><div>{</div><div> =
int asdf(); // PEM</div><div>};</div><div><br></div><div>although using 'pr=
ivate' does help remind us that only private stuff is allowed.</div><div><b=
r></div></div></blockquote><div>I like private better, reusing random keywo=
rds is confusing. continue has to do with loops, private is for access cont=
rol in classes.</div><div><span style=3D"font-size: 13px;"> </span><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex=
; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-lef=
t-style: solid; padding-left: 1ex;"><div dir=3D"ltr"><div></div><div><br></=
div><div>- Internal Linkage by default: Definitely.</div></div></bloc=
kquote><div><br></div><div>Looks like this is getting more votes. I might h=
ave to shift the next version of the paper in this direction.</div><div><br=
></div><div><br></div><br>On Wednesday, January 29, 2014 10:46:42 AM UTC-5,=
Bengt Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">I would favor internal linkage by default. </div></blockquote><d=
iv><br></div><div>And there is another.</div><div> </div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr">The cases when you split o=
ne class into multiple TUs is very low. How about using the now abandoned e=
xport keyword instead of extern for the case that you really want to work w=
ith multiple TUs for one class. Or I would favor to make it impossible to u=
se private extension methods over TU borders.</div></blockquote><div><br></=
div><div>Definitely prefer extern over export because thats what the extern=
keyword already does. You use extern to give thinks external linkage, why =
use something else in the case of a PEM?</div><div> </div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>The p=
aper seems to have a bug in the nested class workaround example:</div><div>=
<br></div><div>X:doWork must send *this rather than x to worker methods!</d=
iv><div><br></div></div></blockquote><div>Thank you for catching that. Fixe=
d in latest draft.</div><div> </div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div></div><div><br></div><div>The table at the=
top of the paper does not list static data members. It would be possible t=
o add private static data PEM-style. However the value is very limited as i=
t is only a naming difference. However I think it should be in the table an=
d be explained why it is not needed.<br><div><br></div></div></div></blockq=
uote><div>I also didn't mention typedefs, enums, and nested classes. I'll c=
onsider these additions on the next revision.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_179_11725474.1391046828804--
.
Author: cornedbee@google.com
Date: Wed, 12 Feb 2014 06:00:28 -0800 (PST)
Raw View
------=_Part_3795_22852856.1392213629131
Content-Type: text/plain; charset=UTF-8
On Thursday, January 30, 2014 2:53:48 AM UTC+1, Matthew Fioravante wrote:
>
> On Tuesday, January 28, 2014 11:41:58 PM UTC-5, Tony V E wrote:
>>
>>
>>
>
>> Also reopening appears to allow private typedefs, nested classes, static
>> variables, etc. Which all looks good to me.
>>
>>
> I'm not sure how useful these things would be in practice when you can
> just create these objects with internal linkage. I'm not against it though,
> especially if someone can come up with a compelling use case.
>
>
Richard Smith has already shown how inner classes plus static members can
break encapsulation:
// intrusion.hpp
struct intruder {
virtual void intrude(fortress& f) = 0;
};
extern intruder* backdoor;
// intrusion.cpp
intruder* backdoor;
private struct fortress::spy : intruder {
spy() { backdoor = this; }
virtual void intrude() {fortress& f) {
f.secret();
}
};
private static fortress::spy fortress::insertion{};
It seems to me that the rules necessary to prevent this would get quite
complicated.
--
---
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_3795_22852856.1392213629131
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, January 30, 2014 2:53:48 AM UTC+1, Ma=
tthew Fioravante 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">On Tuesday, January 28, 2014 11:41:58 PM UTC-5, Tony V E wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div> <br></div></div></blockquote><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><br></div><div>Also reopening appears t=
o allow private typedefs, nested classes, static variables, etc. Whic=
h all looks good to me.</div><div><br></div></div></blockquote><div><br></d=
iv><div>I'm not sure how useful these things would be in practice when you =
can just create these objects with internal linkage. I'm not against it tho=
ugh, especially if someone can come up with a compelling use case.</div><di=
v><br></div></div></blockquote><div><br></div><div>Richard Smith has alread=
y shown how inner classes plus static members can break encapsulation:</div=
><div><br></div><div>// intrusion.hpp</div><div>struct intruder {</div><div=
> virtual void intrude(fortress& f) =3D 0;</div><div>};</div><div=
>extern intruder* backdoor;<br></div><div><br></div><div>// intrusion.cpp</=
div><div>intruder* backdoor;</div><div><br></div><div>private struct fortre=
ss::spy : intruder {</div><div> spy() { backdoor =3D this; }</div><di=
v> virtual void intrude() {fortress& f) {</div><div> =
f.secret();</div><div> }</div><div>};</div><div>private static fortr=
ess::spy fortress::insertion{};</div><div><br></div><div><br></div><div>It =
seems to me that the rules necessary to prevent this would get quite compli=
cated.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_3795_22852856.1392213629131--
.
Author: mikael.s.persson@gmail.com
Date: Mon, 10 Nov 2014 00:34:53 -0800 (PST)
Raw View
------=_Part_2686_1172396236.1415608493024
Content-Type: text/plain; charset=UTF-8
Hi all,
I generally love this idea of being able to extend the private parts of
classes privately ;)
Here are my opinions:
I would generally prefer to have internal linkage by default. But that
could depend on how well it meshes with the syntax. For the currently
proposed syntax (private void Foo::func()), I think that it makes more
sense to have internal linkage by default, and use "extern" to change that.
I prefer the "private class" style that was suggested a few times in this
thread, because I find the syntax nicer and more intuitive, and I see a lot
of potential in being able to define additional private nested types /
typedefs, static members (data or functions), and such. I would say that
this would be especially beneficial to class templates because I often find
that the private parts of class templates can get very cluttered with
nested types, typedefs and static members, and I often which I could just
separate it away (more on that later below).
Here is an idiom that I have used on a few specific situations for this
very same purpose (hiding private functions, and giving them internal
linkage). I like to call it the "Cheshire Kitten" idiom, because it's kind
of an overhead-free "reduced" Cheshire Cat. It goes something like this:
// in header:
class Foo {
protected: // "protected" instead of "private", even though I really
want private here
int value;
public:
void bar();
};
// in cpp file:
namespace {
class FooImpl : public Foo {
friend Foo;
void bar_priv() { /* .. some code .. */ };
//...
};
}
void Foo::bar() {
static_cast<FooImpl*>(this)->bar_priv();
}
This is obviously not a particularly nice solution (and it's theoretically
undefined behaviour because "this" does not actually point to a FooImpl
object, but in practice it's safe as long as FooImpl has no data members
and there isn't any funny business in the inheritance... so, use with
caution). That solution is really about breaking encapsulation (private ->
protected) just so that I can hack into the class' internals later on from
an anonymous namespace (with FooImpl in it).
The reason for posting this idiom here is also to point out two important
things.
The first point is very obvious: this is all about transferability of the
private access. In my little idiom, I'm forced to turn private parts into
protected parts so that FooImpl can access them (but note that I could do
it in other ways too, like a nested accessor class), and then, I have to
make Foo a friend of FooImpl (or give public members to FooImpl). A
variation of this idiom, with external linkage, involves forward-declaring
FooImpl, making it a friend of Foo, and then the rest is the same (define
FooImpl to inherit from Foo, and make an "unsafe" static-cast down to it).
So, really, the core of this proposal, to me, is really about providing a
private-only bridge across those entities (main class definition, private
implementation, and the main class' function bodies). And as long as that
bridge is neatly sealed, I see no problems of breaking encapsulation, in
fact, quite the opposite, it promotes encapsulation by providing a safe
conduit for the access-rights between those entities without having to
resort to one hack or another (like my little hacky idiom).
The second point is related to why my idiom is UB. I think this is related
to why some people on this thread have pointed out that you might need to
make changes to the layout guarantees. My idiom is UB because even though
the derived class does not contain any additional data members or any other
base class, there is no guarantee that the static-cast is safe. This is
because the standard does not really directly specify what comes into the
memory layout of a class (except by way of the definition of a
"standard-layout" class). Common sense dictates that no compiler on Earth
would actually add anything to a class' memory layout for additional
non-virtual member functions or for static members. But,
technically-speaking, compilers are only required to have this behaviour
for standard-layout classes.
So, the interesting thing here is that one way or another, if you open the
door to having additional non-virtual member functions that are not present
in the class definition, then it implies a requirement that non-virtual
member functions do not have any impact on the memory layout of the class.
I'm not sure if the C++ standard would absolutely need to make that
requirement explicit for your proposal to work, but it's a necessary
implication (that you might want to point out in the proposal, in case any
compiler-vendor has an issue with that).
So, the reason I like the "private class" version that was discussed here
is because this really boils down to being able to create a kind of "ghost
class" that is layout-compatible with the main class (like an "overlay")
and that has some mechanism for safely transferring access-rights. So, we
could have something like this:
class Foo {
public:
void bar();
};
private FooImpl : Foo {
void bar_priv();
//...
};
void FooImpl::bar_priv() {
/* .. some code that has access to Foo's private parts .. */
}
void Foo::bar() {
this->bar_priv();
}
where FooImpl has a number of restrictions (which will have to be specified
in the standard) to ensure that it does not attempt to add anything that
would change the class' layout (data members, virtual functions, etc.). And
it would both gain access to the private parts of Foo, and be only
accessible to Foo (e.g., function bodies of Foo's members). I think that
this syntax is nice and intuitive. It can behave as a normal class in terms
of linkage (i.e., it has external linkage by default but can be put into an
anonymous namespace), and in terms of templates (e.g., FooImpl could be a
template, could have specializations, etc..). And finally, you can define
multiple such classes, like FooImpl2, FooImpl3..., which might be useful to
some (as suggested in reference to the clang::Sema class, which is, btw, a
class that belongs in the museum of horrific C++ designs).
Interestingly, when providing an explicit set of restrictions to what can
be added to a class without affecting its layout, one could actually do
something like this:
public FooExtended : Foo {
public:
void another_bar();
//... additional functions to enhance Foo.
};
which is in no way related to the proposal, but could also be a cool thing.
Basically, FooExtended would have the same access-rights as a normal
derived class (public and protected parts). And it would be publicly
accessible to all as a kind of enhanced interface to Foo, that can be used
on any Foo object (i.e., does not need to be created as a FooExtended
object). I'm not sure if this feature is really desirable, but it comes
essentially for free, because if you put in place all that you need to make
the private version work (basic syntax rules, layout-compatibility
restrictions, name lookup, access-rights on classes, etc.), the public
version is trivial to put in place.
Overall, I also like the "private class" version because it simplifies a
lot of the syntax rules, because it eliminates the whole mess with "static
private static void Foo::bar_priv();". The "private class" version allows
you to just reuse the rules for class definition syntax and the syntax for
defining its member functions (outside the class definition) in a way that
remains intuitive and harmonious with the creation of normal C++ classes
(and class templates). This solution should also make things easier for the
compiler implementers.
Another bonus with the "private class" version is that you could specialize
parts of a class template, which I know people will absolutely love! What I
mean is that you could have something like this:
template <typename T>
struct Foo {
void bar();
};
template <typename T>
private FooImpl : Foo<T> {
void bar_priv();
};
template <>
private FooImpl<char> : Foo<char> {
void bar_priv();
};
template <typename T>
void Foo<T>::bar() {
this->bar_priv();
}
I think that the ramifications of the above feature might be more than I
can currently imagine. But there is no doubt that this kind of a mechanism
would be extremely useful and very popular. Currently, specializing parts
of a class template is very awkward, if possible at all, and generally
involves several awkward layers of helper templates.
And as a final note, I would say that name lookup is probably going to be
the most contentious point with compiler vendors. C++ name lookup is
already very nasty and consumes a lot of the compilation efforts, and is
also a defining structure element for the C++ compilers. I would imagine
that amending those rules is not going to be easy, and don't underestimate
how much of that will be needed for this proposal. I think that this has to
be looked into a lot more.
This was pretty much all I wanted to say.
BTW, unlike others, I am not concerned with your proposal opening the doors
for some hackish ways to break encapsulation. For one thing, C++ already
has plenty of loopholes to break encapsulation (some of which are laid out
in that gotw post). And then, I sincerely believe that this
private-to-private bridge (as I've described it earlier) is fundamentally
sound and should provide a fairly safe way to do this. And finally, the
alternatives that currently exist (such as my little hacky idiom) often
force the programmer to hack their way around the access-rights and
therefore leaving some doors open to violations of encapsulation anyways.
So, this is a net positive, it provides a safer alternative to hacking the
access-rights.
Cheers,
Mikael.
--
---
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_2686_1172396236.1415608493024
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi all,</div><div><br></div><div>I generally love thi=
s idea of being able to extend the private parts of classes privately ;)</d=
iv><div><br></div><div>Here are my opinions:</div><div><br></div><div>I wou=
ld generally prefer to have internal linkage by default. But that could dep=
end on how well it meshes with the syntax. For the currently proposed synta=
x (private void Foo::func()), I think that it makes more sense to have inte=
rnal linkage by default, and use "extern" to change that.</div><div><br></d=
iv><div>I prefer the "private class" style that was suggested a few times i=
n this thread, because I find the syntax nicer and more intuitive, and I se=
e a lot of potential in being able to define additional private nested type=
s / typedefs, static members (data or functions), and such. I would say tha=
t this would be especially beneficial to class templates because I often fi=
nd that the private parts of class templates can get very cluttered with ne=
sted types, typedefs and static members, and I often which I could just sep=
arate it away (more on that later below).</div><div><br></div><div>Here is =
an idiom that I have used on a few specific situations for this very same p=
urpose (hiding private functions, and giving them internal linkage). I like=
to call it the "Cheshire Kitten" idiom, because it's kind of an overhead-f=
ree "reduced" Cheshire Cat. It goes something like this:</div><div><br></di=
v><div>// in header:</div><div><br></div><div>class Foo {</div><div> =
protected: // "protected" instead of "private", even though I =
really want private here</div><div> int value;</div><div> =
; </div><div> public:</div><div> void bar();</div><=
div>};</div><div><br></div><div>// in cpp file:</div><div><br></div><div>na=
mespace {</div><div><br></div><div>class FooImpl : public Foo {</div><div>&=
nbsp; friend Foo;</div><div> </div><div> void bar_priv() {=
/* .. some code .. */ };</div><div> //...</div><div>};</div><div><br=
></div><div>}</div><div><br></div><div>void Foo::bar() {</div><div> s=
tatic_cast<FooImpl*>(this)->bar_priv();</div><div>}</div><div><br>=
</div><div>This is obviously not a particularly nice solution (and it's the=
oretically undefined behaviour because "this" does not actually point to a =
FooImpl object, but in practice it's safe as long as FooImpl has no data me=
mbers and there isn't any funny business in the inheritance... so, use with=
caution). That solution is really about breaking encapsulation (private -&=
gt; protected) just so that I can hack into the class' internals later on f=
rom an anonymous namespace (with FooImpl in it).</div><div><br></div><div>T=
he reason for posting this idiom here is also to point out two important th=
ings.</div><div><br></div><div>The first point is very obvious: this is all=
about transferability of the private access. In my little idiom, I'm force=
d to turn private parts into protected parts so that FooImpl can access the=
m (but note that I could do it in other ways too, like a nested accessor cl=
ass), and then, I have to make Foo a friend of FooImpl (or give public memb=
ers to FooImpl). A variation of this idiom, with external linkage, involves=
forward-declaring FooImpl, making it a friend of Foo, and then the rest is=
the same (define FooImpl to inherit from Foo, and make an "unsafe" static-=
cast down to it).</div><div><br></div><div>So, really, the core of this pro=
posal, to me, is really about providing a private-only bridge across those =
entities (main class definition, private implementation, and the main class=
' function bodies). And as long as that bridge is neatly sealed, I see no p=
roblems of breaking encapsulation, in fact, quite the opposite, it promotes=
encapsulation by providing a safe conduit for the access-rights between th=
ose entities without having to resort to one hack or another (like my littl=
e hacky idiom).</div><div><br></div><div>The second point is related to why=
my idiom is UB. I think this is related to why some people on this thread =
have pointed out that you might need to make changes to the layout guarante=
es. My idiom is UB because even though the derived class does not contain a=
ny additional data members or any other base class, there is no guarantee t=
hat the static-cast is safe. This is because the standard does not really d=
irectly specify what comes into the memory layout of a class (except by way=
of the definition of a "standard-layout" class). Common sense dictate=
s that no compiler on Earth would actually add anything to a class' memory =
layout for additional non-virtual member functions or for static members. B=
ut, technically-speaking, compilers are only required to have this behaviou=
r for standard-layout classes.</div><div><br></div><div>So, the interesting=
thing here is that one way or another, if you open the door to having addi=
tional non-virtual member functions that are not present in the class defin=
ition, then it implies a requirement that non-virtual member functions do n=
ot have any impact on the memory layout of the class. I'm not sure if the C=
++ standard would absolutely need to make that requirement explicit for you=
r proposal to work, but it's a necessary implication (that you might want t=
o point out in the proposal, in case any compiler-vendor has an issue with =
that).</div><div><br></div><div>So, the reason I like the "private class" v=
ersion that was discussed here is because this really boils down to being a=
ble to create a kind of "ghost class" that is layout-compatible with the ma=
in class (like an "overlay") and that has some mechanism for safely transfe=
rring access-rights. So, we could have something like this:</div><div><div>=
<br></div><div>class Foo {</div><div> public:</div><div> =
void bar();</div><div>};</div></div><div><br></div><div>private FooImpl : =
Foo {</div><div> void bar_priv();</div><div> //...</div><div>};=
</div><div><br></div><div>void FooImpl::bar_priv() { </div><div> =
/* .. some code that has access to Foo's private parts .. */</div><div>}</=
div><div><br></div><div><div>void Foo::bar() {</div><div> this->ba=
r_priv();</div><div>}</div></div><div><br></div><div>where FooImpl has a nu=
mber of restrictions (which will have to be specified in the standard) to e=
nsure that it does not attempt to add anything that would change the class'=
layout (data members, virtual functions, etc.). And it would both gain acc=
ess to the private parts of Foo, and be only accessible to Foo (e.g., funct=
ion bodies of Foo's members). I think that this syntax is nice and intuitiv=
e. It can behave as a normal class in terms of linkage (i.e., it has extern=
al linkage by default but can be put into an anonymous namespace), and in t=
erms of templates (e.g., FooImpl could be a template, could have specializa=
tions, etc..). And finally, you can define multiple such classes, like FooI=
mpl2, FooImpl3..., which might be useful to some (as suggested in reference=
to the clang::Sema class, which is, btw, a class that belongs in the museu=
m of horrific C++ designs).</div><div><br></div><div>Interestingl=
y, when providing an explicit set of restrictions to what can be added to a=
class without affecting its layout, one could actually do something like t=
his:</div><div><br></div><div>public FooExtended : Foo {</div><div> p=
ublic:</div><div> void another_bar();</div><div> =
//... additional functions to enhance Foo.</div><div>};</div><div><br></div=
><div>which is in no way related to the proposal, but could also be a cool =
thing. Basically, FooExtended would have the same access-rights as a normal=
derived class (public and protected parts). And it would be publicly acces=
sible to all as a kind of enhanced interface to Foo, that can be used on an=
y Foo object (i.e., does not need to be created as a FooExtended object). I=
'm not sure if this feature is really desirable, but it comes essentially f=
or free, because if you put in place all that you need to make the private =
version work (basic syntax rules, layout-compatibility restrictions, name l=
ookup, access-rights on classes, etc.), the public version is trivial to pu=
t in place.</div><div><br></div><div>Overall, I also like the "private clas=
s" version because it simplifies a lot of the syntax rules, because it elim=
inates the whole mess with "static private static void Foo::bar_priv();". T=
he "private class" version allows you to just reuse the rules for class def=
inition syntax and the syntax for defining its member functions (outside th=
e class definition) in a way that remains intuitive and harmonious with the=
creation of normal C++ classes (and class templates). This solution should=
also make things easier for the compiler implementers.</div><div><br></div=
><div>Another bonus with the "private class" version is that you could spec=
ialize parts of a class template, which I know people will absolutely love!=
What I mean is that you could have something like this:</div><div><br></di=
v><div>template <typename T></div><div>struct Foo {</div><div> =
void bar();</div><div>};</div><div><br></div><div>template <typename T&g=
t;</div><div>private FooImpl : Foo<T> {</div><div> void bar_pri=
v();</div><div>};</div><div><br></div><div>template <></div><div>priv=
ate FooImpl<char> : Foo<char> {</div><div> void bar_priv(=
);</div><div>};</div><div><br></div><div><div>template <typename T></=
div><div>void Foo<T>::bar() {</div><div> this->bar_priv();</=
div><div>}</div></div><div><br></div><div>I think that the ramifications of=
the above feature might be more than I can currently imagine. But there is=
no doubt that this kind of a mechanism would be extremely useful and very =
popular. Currently, specializing parts of a class template is very awkward,=
if possible at all, and generally involves several awkward layer=
s of helper templates.</div><div><br></div><div>And as a final note, I woul=
d say that name lookup is probably going to be the most contentious point w=
ith compiler vendors. C++ name lookup is already very nasty and consumes a =
lot of the compilation efforts, and is also a defining structure element fo=
r the C++ compilers. I would imagine that amending those rules is not going=
to be easy, and don't underestimate how much of that will be needed for th=
is proposal. I think that this has to be looked into a lot more. </div=
><div><br></div><div>This was pretty much all I wanted to say.</div><div><b=
r></div><div>BTW, unlike others, I am not concerned with your proposal open=
ing the doors for some hackish ways to break encapsulation. For one thing, =
C++ already has plenty of loopholes to break encapsulation (some of which a=
re laid out in that gotw post). And then, I sincerely believe that this pri=
vate-to-private bridge (as I've described it earlier) is fundamentally soun=
d and should provide a fairly safe way to do this. And finally, the alterna=
tives that currently exist (such as my little hacky idiom) often force the =
programmer to hack their way around the access-rights and therefore leaving=
some doors open to violations of encapsulation anyways. So, this is a net =
positive, it provides a safer alternative to hacking the access-rights.</di=
v><div><br></div><div>Cheers,</div><div>Mikael.</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_2686_1172396236.1415608493024--
.
Author: johannes.gerd.becker@gmail.com
Date: Wed, 23 Dec 2015 10:36:45 -0800 (PST)
Raw View
------=_Part_803_306770502.1450895805981
Content-Type: multipart/alternative;
boundary="----=_Part_804_1324469234.1450895805982"
------=_Part_804_1324469234.1450895805982
Content-Type: text/plain; charset=UTF-8
Wouldn't the "it's possible to access private members in a
standard-conforming way" holes disappear if private extension functions are
internally considered as being templates and thus get the same
instantiation rules.
I.e. if
private int MyClass::Extension (int a) { ... }
would be treated as if it were something like
template <class T>
std::enable_if_t<std::is_same<T, MyClass>, int> Extension (T * this, int a)
{ ... }
with myClass->Extension (2) effectively being translated into Extension
(myClass, 2), with Extension being a self-made friend?
As any such call must eventually stem from a non-extension function,
private extension functions not anchored in a non-extension function are
simply ignored???
Best regards,
Johannes
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_804_1324469234.1450895805982
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Wouldn't the "it's possible to access private=
members in a standard-conforming way" holes disappear if private exte=
nsion functions are internally considered as being templates and thus get t=
he same instantiation rules.<br><br>I.e. if<br><br>private int MyClass::Ext=
ension (int a) { ... }<br><br>would be treated as if it were something like=
<br><br>template <class T><br>std::enable_if_t<std::is_same<T, =
MyClass>, int> Extension (T * this, int a) { ... }<br><br>with myClas=
s->Extension (2) effectively being translated into Extension (myClass, 2=
), with Extension being a self-made friend?<br><br>As any such call must ev=
entually stem from a non-extension function, private extension functions no=
t anchored in a non-extension function are simply ignored???<br><br>Best re=
gards,<br>Johannes<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" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_804_1324469234.1450895805982--
------=_Part_803_306770502.1450895805981--
.