Topic: New type of access modifier which allows access
Author: zumbagina29@gmail.com
Date: Mon, 8 Jun 2015 09:45:47 -0700 (PDT)
Raw View
------=_Part_852_510881316.1433781947704
Content-Type: multipart/alternative;
boundary="----=_Part_853_742657306.1433781947704"
------=_Part_853_742657306.1433781947704
Content-Type: text/plain; charset=UTF-8
This access modifier, "namespace", would be more restrictive than public,
yet less restrictive than protected and private.
I have a case in which the existing access modifiers aren't appropriate,
yet I have to use "public" because an instance function needs to be
accessible outside of my class. The problem is that I don't want my
clients to use my method.
For example, consider an implementation of Dependency Injection:
class MyClass : public MyInterface
{
public:
//Constructor, destructor, MyInterface methods
void SetDependency(aDependency* depends) { theDependency = depends; }
private:
aDependency* theDependency;
};
In this case, I need to make my 'SetDependency' function visible outside of
my class, so 'private' access obviously won't work. 'protected' access
doesn't make sense, as coupling my creator of the aDependency object to
MyClass isn't appropriate. 'public' access is my only option, however that
pollutes my interface and is confusing. In this example, the
'SetDependency' function would only be called by an object internal to my
library, most likely at start-up.
There is something similar in Java. IIRC. 'default' access means that
everything within a package has visibility.
Thank you,
Gina Stephens
--
---
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_853_742657306.1433781947704
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>This access modifier, "namespace", would be more restr=
ictive than public, yet less restrictive than protected and private. =
<br><br>I have a case in which the existing access modifiers aren't appropr=
iate, yet I have to use "public" because an instance function needs to be a=
ccessible outside of my class. The problem is that I don't want my cl=
ients to use my method. <br><br>For example, consider an implementation of =
Dependency Injection:<br><br>class MyClass : public MyInterface<br>{<br>&nb=
sp; public:<br> //Constructor, destruct=
or, MyInterface methods<br><br> void SetDependency(aDependency*=
depends) { theDependency =3D depends; }<br> private:<br> =
aDependency* theDependency;<br>};<br><br>In this c=
ase, I need to make my 'SetDependency' function visible outside of my class=
, so 'private' access obviously won't work. 'protected' access doesn'=
t make sense, as coupling my creator of the aDependency object to MyClass i=
sn't appropriate. 'public' access is my only option, however that pol=
lutes my interface and is confusing. In this example, the 'SetDepende=
ncy' function would only be called by an object internal to my library, mos=
t likely at start-up.<br><br>There is something similar in Java. IIRC=
.. 'default' access means that everything within a package has visibil=
ity.<br><br>Thank you,<br><br>Gina Stephens<br><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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_853_742657306.1433781947704--
------=_Part_852_510881316.1433781947704--
.
Author: =?UTF-8?Q?Germ=C3=A1n_Diago?= <germandiago@gmail.com>
Date: Mon, 8 Jun 2015 23:57:35 +0700
Raw View
--001a11428cb6e460b705180489c0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Use a friend class that can access that. MyClassFriendAccess. That can
access. Hide it in a namespace detail. Your users will not go for that.
El 08/06/2015 23:45, <zumbagina29@gmail.com> escribi=C3=B3:
>
> This access modifier, "namespace", would be more restrictive than public,
> yet less restrictive than protected and private.
>
> I have a case in which the existing access modifiers aren't appropriate,
> yet I have to use "public" because an instance function needs to be
> accessible outside of my class. The problem is that I don't want my
> clients to use my method.
>
> For example, consider an implementation of Dependency Injection:
>
> class MyClass : public MyInterface
> {
> public:
> //Constructor, destructor, MyInterface methods
>
> void SetDependency(aDependency* depends) { theDependency =3D depends; =
}
> private:
> aDependency* theDependency;
> };
>
> In this case, I need to make my 'SetDependency' function visible outside
> of my class, so 'private' access obviously won't work. 'protected' acces=
s
> doesn't make sense, as coupling my creator of the aDependency object to
> MyClass isn't appropriate. 'public' access is my only option, however th=
at
> pollutes my interface and is confusing. In this example, the
> 'SetDependency' function would only be called by an object internal to my
> library, most likely at start-up.
>
> There is something similar in Java. IIRC. 'default' access means that
> everything within a package has visibility.
>
> Thank you,
>
> Gina Stephens
>
> --
>
> ---
> 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/.
--001a11428cb6e460b705180489c0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Use a friend class that can access that. MyClassFriendAccess=
.. That can access. Hide it in a namespace detail. Your users will not go fo=
r that.</p>
<div class=3D"gmail_quote">El 08/06/2015 23:45, <<a href=3D"mailto:zumb=
agina29@gmail.com">zumbagina29@gmail.com</a>> escribi=C3=B3:<br type=3D"=
attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>This acces=
s modifier, "namespace", would be more restrictive than public, y=
et less restrictive than protected and private.=C2=A0 <br><br>I have a case=
in which the existing access modifiers aren't appropriate, yet I have =
to use "public" because an instance function needs to be accessib=
le outside of my class.=C2=A0 The problem is that I don't want my clien=
ts to use my method. <br><br>For example, consider an implementation of Dep=
endency Injection:<br><br>class MyClass : public MyInterface<br>{<br>=C2=A0=
=C2=A0 public:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 //Constructor, destructor,=
MyInterface methods<br><br>=C2=A0=C2=A0 void SetDependency(aDependency* de=
pends) { theDependency =3D depends; }<br>=C2=A0=C2=A0 private:<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 aDependency* theDependency;<br>};<br><br>In this case=
, I need to make my 'SetDependency' function visible outside of my =
class, so 'private' access obviously won't work.=C2=A0 'pro=
tected' access doesn't make sense, as coupling my creator of the aD=
ependency object to MyClass isn't appropriate.=C2=A0 'public' a=
ccess is my only option, however that pollutes my interface and is confusin=
g.=C2=A0 In this example, the 'SetDependency' function would only b=
e called by an object internal to my library, most likely at start-up.<br><=
br>There is something similar in Java.=C2=A0 IIRC.=C2=A0 'default' =
access means that everything within a package has visibility.<br><br>Thank =
you,<br><br>Gina Stephens<br><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" 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>
</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 <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 />
--001a11428cb6e460b705180489c0--
.
Author: Gina Stephens <zumbagina29@gmail.com>
Date: Mon, 8 Jun 2015 22:07:46 -0500
Raw View
--001a113e97de0e880e05180d1086
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Thank you, German, for the alternative.
The problem with using a friend class is that I don't know the type of the
creator of the aDependency object until run-time. This means that I would
have to declare every possible concrete type as a friend. That solution is
just not good design.
Thank you,
Gina
On Mon, Jun 8, 2015 at 11:57 AM, Germ=C3=A1n Diago <germandiago@gmail.com> =
wrote:
> Use a friend class that can access that. MyClassFriendAccess. That can
> access. Hide it in a namespace detail. Your users will not go for that.
> El 08/06/2015 23:45, <zumbagina29@gmail.com> escribi=C3=B3:
>
>>
>> This access modifier, "namespace", would be more restrictive than public=
,
>> yet less restrictive than protected and private.
>>
>> I have a case in which the existing access modifiers aren't appropriate,
>> yet I have to use "public" because an instance function needs to be
>> accessible outside of my class. The problem is that I don't want my
>> clients to use my method.
>>
>> For example, consider an implementation of Dependency Injection:
>>
>> class MyClass : public MyInterface
>> {
>> public:
>> //Constructor, destructor, MyInterface methods
>>
>> void SetDependency(aDependency* depends) { theDependency =3D depends;=
}
>> private:
>> aDependency* theDependency;
>> };
>>
>> In this case, I need to make my 'SetDependency' function visible outside
>> of my class, so 'private' access obviously won't work. 'protected' acce=
ss
>> doesn't make sense, as coupling my creator of the aDependency object to
>> MyClass isn't appropriate. 'public' access is my only option, however t=
hat
>> pollutes my interface and is confusing. In this example, the
>> 'SetDependency' function would only be called by an object internal to m=
y
>> library, most likely at start-up.
>>
>> There is something similar in Java. IIRC. 'default' access means that
>> everything within a package has visibility.
>>
>> Thank you,
>>
>> Gina Stephens
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
> --
>
> ---
> 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
Gina Stephens, MSCS
--=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/.
--001a113e97de0e880e05180d1086
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thank you, German, for the alternative.<div><br></div><div=
>The problem with using a friend class is that I don't know the type of=
the creator of the aDependency object until run-time.=C2=A0 This means tha=
t I would have to declare every possible concrete type as a friend.=C2=A0 T=
hat solution is just not good design.</div><div><br></div><div>Thank you,</=
div><div><br></div><div>Gina</div><div><br></div></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Mon, Jun 8, 2015 at 11:57 AM, Germ=
=C3=A1n Diago <span dir=3D"ltr"><<a href=3D"mailto:germandiago@gmail.com=
" target=3D"_blank">germandiago@gmail.com</a>></span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><p dir=3D"ltr">Use a friend class that can access th=
at. MyClassFriendAccess. That can access. Hide it in a namespace detail. Yo=
ur users will not go for that.</p>
<div class=3D"gmail_quote"><span class=3D"">El 08/06/2015 23:45, <<a hr=
ef=3D"mailto:zumbagina29@gmail.com" target=3D"_blank">zumbagina29@gmail.com=
</a>> escribi=C3=B3:<br type=3D"attribution"></span><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><span class=3D""><div dir=3D"ltr"><br>This access modifier, &quo=
t;namespace", would be more restrictive than public, yet less restrict=
ive than protected and private.=C2=A0 <br><br>I have a case in which the ex=
isting access modifiers aren't appropriate, yet I have to use "pub=
lic" because an instance function needs to be accessible outside of my=
class.=C2=A0 The problem is that I don't want my clients to use my met=
hod. <br><br>For example, consider an implementation of Dependency Injectio=
n:<br><br>class MyClass : public MyInterface<br>{<br>=C2=A0=C2=A0 public:<b=
r>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 //Constructor, destructor, MyInterface met=
hods<br><br>=C2=A0=C2=A0 void SetDependency(aDependency* depends) { theDepe=
ndency =3D depends; }<br>=C2=A0=C2=A0 private:<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 aDependency* theDependency;<br>};<br><br>In this case, I need to mak=
e my 'SetDependency' function visible outside of my class, so '=
private' access obviously won't work.=C2=A0 'protected' acc=
ess doesn't make sense, as coupling my creator of the aDependency objec=
t to MyClass isn't appropriate.=C2=A0 'public' access is my onl=
y option, however that pollutes my interface and is confusing.=C2=A0 In thi=
s example, the 'SetDependency' function would only be called by an =
object internal to my library, most likely at start-up.<br><br>There is som=
ething similar in Java.=C2=A0 IIRC.=C2=A0 'default' access means th=
at everything within a package has visibility.<br><br>Thank you,<br><br>Gin=
a Stephens<br><br></div>
<p></p>
-- <br>
<br>
--- <br></span>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<span class=3D""><br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</span></blockquote></div><span class=3D"HOEnZb"><font color=3D"#888888">
<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.</font></span><div class=3D=
"HOEnZb"><div class=3D"h5"><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><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"ltr">Gina Stephens, MSCS<br></di=
v></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 />
--001a113e97de0e880e05180d1086--
.
Author: David Krauss <potswa@mac.com>
Date: Tue, 09 Jun 2015 12:36:36 +0800
Raw View
--Apple-Mail=_690186B9-05E5-4DB7-945C-D60500D8C398
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9309, at 11:07 AM, Gina Stephens <zumbagina29@gm=
ail.com> wrote:
>=20
> Thank you, German, for the alternative.
>=20
> The problem with using a friend class is that I don't know the type of th=
e creator of the aDependency object until run-time. This means that I woul=
d have to declare every possible concrete type as a friend. That solution =
is just not good design.
Create a base type to serve as the friend. The concrete types derive from i=
t. The base class is inside a detail namespace and does not pollute the der=
ived interface because it provides its accessor as protected and/or always =
gets inherited as private.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_690186B9-05E5-4DB7-945C-D60500D8C398
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9309, at 11:07 AM, Gina Stephens <<a href=3D"mailto:zumbagina29@g=
mail.com" class=3D"">zumbagina29@gmail.com</a>> wrote:</div><br class=3D=
"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">Tha=
nk you, German, for the alternative.<div class=3D""><br class=3D""></div><d=
iv class=3D"">The problem with using a friend class is that I don't know th=
e type of the creator of the aDependency object until run-time. This =
means that I would have to declare every possible concrete type as a friend=
.. That solution is just not good design.</div></div></div></blockquot=
e><div><br class=3D""></div>Create a base type to serve as the friend. The =
concrete types derive from it. The base class is inside a detail namespace =
and does not pollute the derived interface because it provides its accessor=
as <font face=3D"Courier" class=3D"">protected</font> and/or always gets i=
nherited as <font face=3D"Courier" class=3D"">private</font>.</div></body><=
/html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_690186B9-05E5-4DB7-945C-D60500D8C398--
.
Author: Gina Stephens <zumbagina29@gmail.com>
Date: Tue, 9 Jun 2015 08:07:35 -0500
Raw View
--bcaec51824a630a67a051815711b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Are you saying all children that inherit from the friend class also inherit
the friend relationship? I don't believe this is true, so I tried it just
to be sure. As expected, I receive compilation errors stating that my
derived classes do not have access. Do I misunderstand you?
I understand that there are many alternatives to achieve the behavior that
I want. Heck, I could eliminate the 'Set' function altogether and just
instantiate an instance of my 'creator' class with external linkage.
However, I want a solution that follows good design practices and makes my
intent very clear. In my experience, the use of friend classes is a band
aid for poor design.
By using an access modifier that limits accessibility within a namespace,
this helps convey design intent and usage.
Thank you,
Gina
On Mon, Jun 8, 2015 at 11:36 PM, David Krauss <potswa@mac.com> wrote:
>
> On 2015=E2=80=9306=E2=80=9309, at 11:07 AM, Gina Stephens <zumbagina29@gm=
ail.com> wrote:
>
> Thank you, German, for the alternative.
>
> The problem with using a friend class is that I don't know the type of th=
e
> creator of the aDependency object until run-time. This means that I woul=
d
> have to declare every possible concrete type as a friend. That solution =
is
> just not good design.
>
>
> Create a base type to serve as the friend. The concrete types derive from
> it. The base class is inside a detail namespace and does not pollute the
> derived interface because it provides its accessor as protected and/or
> always gets inherited as private.
>
> --
>
> ---
> 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
Gina Stephens, MSCS
--=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/.
--bcaec51824a630a67a051815711b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Are you saying all children that inherit from the friend c=
lass also inherit the friend relationship?=C2=A0 I don't believe this i=
s true, so I tried it just to be sure.=C2=A0 As expected, I receive compila=
tion errors stating that my derived classes do not have access.=C2=A0 Do I =
misunderstand you?<div><br></div><div>I understand that there are many alte=
rnatives to achieve the behavior that I want.=C2=A0 Heck, I could eliminate=
the 'Set' function altogether and just instantiate an instance of =
my 'creator' class with external linkage.=C2=A0 However, I want a s=
olution that follows good design practices and makes my intent very clear.=
=C2=A0 In my experience, the use of friend classes is a band aid for poor d=
esign.</div><div><br></div><div>By using an access modifier that limits acc=
essibility within a namespace, this helps convey design intent and usage.</=
div><div><br></div><div>Thank you,</div><div><br></div><div>Gina</div><div>=
<br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n Mon, Jun 8, 2015 at 11:36 PM, David Krauss <span dir=3D"ltr"><<a href=
=3D"mailto:potswa@mac.com" target=3D"_blank">potswa@mac.com</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word=
"><br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9306=E2=80=9309, at=
11:07 AM, Gina Stephens <<a href=3D"mailto:zumbagina29@gmail.com" targe=
t=3D"_blank">zumbagina29@gmail.com</a>> wrote:</div><br><div><div dir=3D=
"ltr">Thank you, German, for the alternative.<div><br></div><div>The proble=
m with using a friend class is that I don't know the type of the creato=
r of the aDependency object until run-time.=C2=A0 This means that I would h=
ave to declare every possible concrete type as a friend.=C2=A0 That solutio=
n is just not good design.</div></div></div></blockquote><div><br></div>Cre=
ate a base type to serve as the friend. The concrete types derive from it. =
The base class is inside a detail namespace and does not pollute the derive=
d interface because it provides its accessor as <font face=3D"Courier">prot=
ected</font> and/or always gets inherited as <font face=3D"Courier">private=
</font>.</div></div><span class=3D"HOEnZb"><font color=3D"#888888">
<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" 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>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div class=3D"gmail_signature"><div dir=3D"ltr">Gina Stephens, MSCS<br></=
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 <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 />
--bcaec51824a630a67a051815711b--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Tue, 9 Jun 2015 15:23:30 +0200
Raw View
--Apple-Mail=_8731A26B-D647-4394-9401-E0AE73746A68
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
This is how it can be implemented with inheritance:
class Private;
namespace detail
{
class PrivateFriend {
protected:
PrivateFriend(Private& target) : _target(target) { }
void setX(int x) { _target.setX(x); }
int x() { return_target.x(); }
private:
Private& _target;
};
}
class Private {
void setX(int x);
int x();
=E2=80=A6
friend detail::PrivateFriend;
};
class Client : private detail::PrivateFriend {
public:
Client(Private& target) : PrivateFriend(target) { }
int foo() {
setX(5);
return x();
}
};
Instead of making setX() and x() protected in PrivateFriend you can make th=
em public to get rid of the inheritance requirement:
namespace detail
{
class PrivateFriend {
public:
PrivateFriend(Private& target) : _target(target) { }
void setX(int x) { _target.setX(x); }
int x() { return_target.x(); }
private:
Private& _target;
};
}
class Client {
public:
Client(Private& target) : _target(target) { }
int foo() {
auto accessor =3D detail::PrivateFriend{_target};
accessor.setX(5);
return accessor.x();
}
private:
Private& _target;
};
Since both Private and PrivateFriend are under your control you decide what=
private parts PrivateFriend can access. By hiding it in some non-public na=
mespace you effectively hide it from normal users and make it an implementa=
tion detail. Normal users of your class are not supposed to use PrivateFrie=
nd. You can make different friend classes for finer-grained access control,=
for example PrivateXFriend, PrivateYFriend, PrivatePositionFriend etc.
After the compiler is done with inlining there should be no indication left=
PrivateFriend ever existed.
> On 09 Jun 2015, at 15:07 , Gina Stephens <zumbagina29@gmail.com> wrote:
>=20
> Are you saying all children that inherit from the friend class also inher=
it the friend relationship? I don't believe this is true, so I tried it ju=
st to be sure. As expected, I receive compilation errors stating that my d=
erived classes do not have access. Do I misunderstand you?
>=20
> I understand that there are many alternatives to achieve the behavior tha=
t I want. Heck, I could eliminate the 'Set' function altogether and just i=
nstantiate an instance of my 'creator' class with external linkage. Howeve=
r, I want a solution that follows good design practices and makes my intent=
very clear. In my experience, the use of friend classes is a band aid for=
poor design.
>=20
> By using an access modifier that limits accessibility within a namespace,=
this helps convey design intent and usage.
>=20
> Thank you,
>=20
> Gina
>=20
>=20
> On Mon, Jun 8, 2015 at 11:36 PM, David Krauss <potswa@mac.com <mailto:pot=
swa@mac.com>> wrote:
>=20
>> On 2015=E2=80=9306=E2=80=9309, at 11:07 AM, Gina Stephens <zumbagina29@g=
mail.com <mailto:zumbagina29@gmail.com>> wrote:
>>=20
>> Thank you, German, for the alternative.
>>=20
>> The problem with using a friend class is that I don't know the type of t=
he creator of the aDependency object until run-time. This means that I wou=
ld have to declare every possible concrete type as a friend. That solution=
is just not good design.
>=20
> Create a base type to serve as the friend. The concrete types derive from=
it. The base class is inside a detail namespace and does not pollute the d=
erived interface because it provides its accessor as protected and/or alway=
s gets inherited as private.
>=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=
email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/ <http://groups.google.com/a/isocpp.org/group/std-proposals/>.
>=20
>=20
>=20
> --=20
> Gina Stephens, MSCS
>=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=
email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/ <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/.
--Apple-Mail=_8731A26B-D647-4394-9401-E0AE73746A68
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D"">Th=
is is how it can be implemented with inheritance:</div><div class=3D""><br =
class=3D""></div><div class=3D"">class Private;</div><div class=3D""><br cl=
ass=3D""></div><div class=3D"">namespace detail</div><div class=3D"">{</div=
><div class=3D""> class PrivateFriend {</div><div class=3D""> p=
rotected:</div><div class=3D""> PrivateFriend(Private& tar=
get) : _target(target) { }</div><div class=3D""> void setX(int=
x) { _target.setX(x); }</div><div class=3D""> int x() { retur=
n_target.x(); }</div><div class=3D""><br class=3D""></div><div class=3D"">&=
nbsp; private:</div><div class=3D""> Private& _target;</di=
v><div class=3D""> };</div><div class=3D"">}</div><div class=3D""><br=
class=3D""></div>class Private {<div class=3D""> void setX(int x);</=
div><div class=3D""> int x();</div><div class=3D""> =E2=80=A6</=
div><div class=3D""> friend detail::PrivateFriend;<br class=3D""><div=
class=3D"">};</div><div class=3D""><br class=3D""></div><div class=3D"">cl=
ass Client : private detail::PrivateFriend {</div><div class=3D"">public:</=
div><div class=3D""> Client(Private& target) : PrivateFriend(targ=
et) { }</div><div class=3D""><br class=3D""></div><div class=3D""> in=
t foo() {</div><div class=3D""> setX(5);</div><div class=3D"">=
return x();</div><div class=3D""> }</div><div class=3D"=
">};</div><div class=3D""><br class=3D""></div><div class=3D"">Instead of m=
aking setX() and x() protected in PrivateFriend you can make them public to=
get rid of the inheritance requirement:</div><div class=3D""><br class=3D"=
"></div><div class=3D""><div class=3D"">namespace detail</div><div class=3D=
"">{</div><div class=3D""> class PrivateFriend {</div><div class=3D""=
> public:</div><div class=3D""> PrivateFriend(Private&am=
p; target) : _target(target) { }</div><div class=3D""> void se=
tX(int x) { _target.setX(x); }</div><div class=3D""> int x() {=
return_target.x(); }</div><div class=3D""><br class=3D""></div><div class=
=3D""> private:</div><div class=3D""> Private& _targ=
et;</div><div class=3D""> };</div><div class=3D"">}</div></div><div c=
lass=3D""><br class=3D""></div><div class=3D""><div class=3D"">class Client=
{</div><div class=3D"">public:</div><div class=3D""> Client(Private&=
amp; target) : _target(target) { }</div><div class=3D""><br class=3D""></di=
v><div class=3D""> int foo() {</div><div class=3D""> aut=
o accessor =3D detail::PrivateFriend{_target};</div><div class=3D""> =
accessor.setX(5);</div><div class=3D""> return accessor=
..x();</div><div class=3D""> }</div><div class=3D""><br class=3D""></d=
iv><div class=3D"">private:</div><div class=3D""> Private& _targe=
t;</div><div class=3D"">};</div><div class=3D""><br class=3D""></div><div c=
lass=3D"">Since both Private and PrivateFriend are under your control you d=
ecide what private parts PrivateFriend can access. By hiding it in some non=
-public namespace you effectively hide it from normal users and make it an =
implementation detail. Normal users of your class are not supposed to use P=
rivateFriend. You can make different friend classes for finer-grained acces=
s control, for example PrivateXFriend, PrivateYFriend, PrivatePositionFrien=
d etc.</div><div class=3D""><br class=3D""></div><div class=3D"">After the =
compiler is done with inlining there should be no indication left PrivateFr=
iend ever existed.</div><div class=3D""><br class=3D""></div><div><blockquo=
te type=3D"cite" class=3D""><div class=3D"">On 09 Jun 2015, at 15:07 , Gina=
Stephens <<a href=3D"mailto:zumbagina29@gmail.com" class=3D"">zumbagina=
29@gmail.com</a>> wrote:</div><br class=3D"Apple-interchange-newline"><d=
iv class=3D""><div dir=3D"ltr" class=3D"">Are you saying all children that =
inherit from the friend class also inherit the friend relationship? I=
don't believe this is true, so I tried it just to be sure. As expect=
ed, I receive compilation errors stating that my derived classes do not hav=
e access. Do I misunderstand you?<div class=3D""><br class=3D""></div=
><div class=3D"">I understand that there are many alternatives to achieve t=
he behavior that I want. Heck, I could eliminate the 'Set' function a=
ltogether and just instantiate an instance of my 'creator' class with exter=
nal linkage. However, I want a solution that follows good design prac=
tices and makes my intent very clear. In my experience, the use of fr=
iend classes is a band aid for poor design.</div><div class=3D""><br class=
=3D""></div><div class=3D"">By using an access modifier that limits accessi=
bility within a namespace, this helps convey design intent and usage.</div>=
<div class=3D""><br class=3D""></div><div class=3D"">Thank you,</div><div c=
lass=3D""><br class=3D""></div><div class=3D"">Gina</div><div class=3D""><b=
r class=3D""></div></div><div class=3D"gmail_extra"><br class=3D""><div cla=
ss=3D"gmail_quote">On Mon, Jun 8, 2015 at 11:36 PM, David Krauss <span dir=
=3D"ltr" class=3D""><<a href=3D"mailto:potswa@mac.com" target=3D"_blank"=
class=3D"">potswa@mac.com</a>></span> wrote:<br class=3D""><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div style=3D"word-wrap:break-word" class=3D""><br class=
=3D""><div class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">=
On 2015=E2=80=9306=E2=80=9309, at 11:07 AM, Gina Stephens <<a href=3D"ma=
ilto:zumbagina29@gmail.com" target=3D"_blank" class=3D"">zumbagina29@gmail.=
com</a>> wrote:</div><br class=3D""><div class=3D""><div dir=3D"ltr" cla=
ss=3D"">Thank you, German, for the alternative.<div class=3D""><br class=3D=
""></div><div class=3D"">The problem with using a friend class is that I do=
n't know the type of the creator of the aDependency object until run-time.&=
nbsp; This means that I would have to declare every possible concrete type =
as a friend. That solution is just not good design.</div></div></div>=
</blockquote><div class=3D""><br class=3D""></div>Create a base type to ser=
ve as the friend. The concrete types derive from it. The base class is insi=
de a detail namespace and does not pollute the derived interface because it=
provides its accessor as <font face=3D"Courier" class=3D"">protected</font=
> and/or always gets inherited as <font face=3D"Courier" class=3D"">private=
</font>.</div></div><span class=3D"HOEnZb"><font color=3D"#888888" class=3D=
""><div class=3D""><br class=3D"webkit-block-placeholder"></div>
-- <br class=3D"">
<br class=3D"">
--- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" class=3D"">std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" class=3D"">std-proposals@isocpp.org</a>.<br class=
=3D"">
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" class=3D"">http://groups.google.com/a/iso=
cpp.org/group/std-proposals/</a>.<br class=3D"">
</font></span></blockquote></div><br class=3D""><br clear=3D"all" class=3D"=
"><div class=3D""><br class=3D""></div>-- <br class=3D""><div class=3D"gmai=
l_signature"><div dir=3D"ltr" class=3D"">Gina Stephens, MSCS<br class=3D"">=
</div></div>
</div><div class=3D""><br class=3D"webkit-block-placeholder"></div>
-- <br class=3D"">
<br class=3D"">
--- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
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" class=3D"">=
std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" class=3D"">http://groups.google.com/a/isocpp.org/group/std-=
proposals/</a>.<br class=3D"">
</div></blockquote></div><br class=3D""></div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_8731A26B-D647-4394-9401-E0AE73746A68--
.
Author: Gina Stephens <zumbagina29@gmail.com>
Date: Tue, 9 Jun 2015 08:36:05 -0500
Raw View
--90e6ba6e86421156d8051815d7bc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
OK, thank you for the example. Yes, I have no doubt that there are
multiple ways to achieve the desired behavior.
I believe that we are getting off topic, though. Are you suggesting an
alternative because you do not believe that my proposal has merit? If so,
could you state why my proposal has no merit?
On Tue, Jun 9, 2015 at 8:23 AM, Miro Knejp <miro.knejp@gmail.com> wrote:
> This is how it can be implemented with inheritance:
>
> class Private;
>
> namespace detail
> {
> class PrivateFriend {
> protected:
> PrivateFriend(Private& target) : _target(target) { }
> void setX(int x) { _target.setX(x); }
> int x() { return_target.x(); }
>
> private:
> Private& _target;
> };
> }
>
> class Private {
> void setX(int x);
> int x();
> =E2=80=A6
> friend detail::PrivateFriend;
> };
>
> class Client : private detail::PrivateFriend {
> public:
> Client(Private& target) : PrivateFriend(target) { }
>
> int foo() {
> setX(5);
> return x();
> }
> };
>
> Instead of making setX() and x() protected in PrivateFriend you can make
> them public to get rid of the inheritance requirement:
>
> namespace detail
> {
> class PrivateFriend {
> public:
> PrivateFriend(Private& target) : _target(target) { }
> void setX(int x) { _target.setX(x); }
> int x() { return_target.x(); }
>
> private:
> Private& _target;
> };
> }
>
> class Client {
> public:
> Client(Private& target) : _target(target) { }
>
> int foo() {
> auto accessor =3D detail::PrivateFriend{_target};
> accessor.setX(5);
> return accessor.x();
> }
>
> private:
> Private& _target;
> };
>
> Since both Private and PrivateFriend are under your control you decide
> what private parts PrivateFriend can access. By hiding it in some
> non-public namespace you effectively hide it from normal users and make i=
t
> an implementation detail. Normal users of your class are not supposed to
> use PrivateFriend. You can make different friend classes for finer-graine=
d
> access control, for example PrivateXFriend, PrivateYFriend,
> PrivatePositionFriend etc.
>
> After the compiler is done with inlining there should be no indication
> left PrivateFriend ever existed.
>
> On 09 Jun 2015, at 15:07 , Gina Stephens <zumbagina29@gmail.com> wrote:
>
> Are you saying all children that inherit from the friend class also
> inherit the friend relationship? I don't believe this is true, so I trie=
d
> it just to be sure. As expected, I receive compilation errors stating th=
at
> my derived classes do not have access. Do I misunderstand you?
>
> I understand that there are many alternatives to achieve the behavior tha=
t
> I want. Heck, I could eliminate the 'Set' function altogether and just
> instantiate an instance of my 'creator' class with external linkage.
> However, I want a solution that follows good design practices and makes m=
y
> intent very clear. In my experience, the use of friend classes is a band
> aid for poor design.
>
> By using an access modifier that limits accessibility within a namespace,
> this helps convey design intent and usage.
>
> Thank you,
>
> Gina
>
>
> On Mon, Jun 8, 2015 at 11:36 PM, David Krauss <potswa@mac.com> wrote:
>
>>
>> On 2015=E2=80=9306=E2=80=9309, at 11:07 AM, Gina Stephens <zumbagina29@g=
mail.com> wrote:
>>
>> Thank you, German, for the alternative.
>>
>> The problem with using a friend class is that I don't know the type of
>> the creator of the aDependency object until run-time. This means that I
>> would have to declare every possible concrete type as a friend. That
>> solution is just not good design.
>>
>>
>> Create a base type to serve as the friend. The concrete types derive fro=
m
>> it. The base class is inside a detail namespace and does not pollute the
>> derived interface because it provides its accessor as protected and/or
>> always gets inherited as private.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
>
> --
> Gina Stephens, MSCS
>
> --
>
> ---
> 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/.
>
--=20
Gina Stephens, MSCS
--=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/.
--90e6ba6e86421156d8051815d7bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">OK, thank you for the example.=C2=A0 Yes, I have no doubt =
that there are multiple ways to achieve the desired behavior.<div><br></div=
><div>I believe that we are getting off topic, though.=C2=A0 Are you sugges=
ting an alternative because you do not believe that my proposal has merit?=
=C2=A0 If so, could you state why my proposal has no merit?</div><div><br><=
/div><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Tue, Jun 9, 2015 at 8:23 AM, Miro Knejp <span dir=3D"ltr"><<=
a href=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"wo=
rd-wrap:break-word"><div>This is how it can be implemented with inheritance=
:</div><div><br></div><div>class Private;</div><div><br></div><div>namespac=
e detail</div><div>{</div><div>=C2=A0 class PrivateFriend {</div><div>=C2=
=A0 protected:</div><div>=C2=A0 =C2=A0 PrivateFriend(Private& target) :=
_target(target) { }</div><div>=C2=A0 =C2=A0 void setX(int x) { _target.set=
X(x); }</div><div>=C2=A0 =C2=A0 int x() { return_target.x(); }</div><div><b=
r></div><div>=C2=A0 private:</div><div>=C2=A0 =C2=A0 Private& _target;<=
/div><div>=C2=A0 };</div><div>}</div><div><br></div>class Private {<div>=C2=
=A0 void setX(int x);</div><div>=C2=A0 int x();</div><div>=C2=A0 =E2=80=A6<=
/div><div>=C2=A0 friend detail::PrivateFriend;<br><div>};</div><div><br></d=
iv><div>class Client : private detail::PrivateFriend {</div><div>public:</d=
iv><div>=C2=A0 Client(Private& target) : PrivateFriend(target) { }</div=
><div><br></div><div>=C2=A0 int foo() {</div><div>=C2=A0 =C2=A0 setX(5);</d=
iv><div>=C2=A0 =C2=A0 return x();</div><div>=C2=A0 }</div><div>};</div><div=
><br></div><div>Instead of making setX() and x() protected in PrivateFriend=
you can make them public to get rid of the inheritance requirement:</div><=
div><br></div><div><div>namespace detail</div><div>{</div><div>=C2=A0 class=
PrivateFriend {</div><div>=C2=A0 public:</div><div>=C2=A0 =C2=A0 PrivateFr=
iend(Private& target) : _target(target) { }</div><div>=C2=A0 =C2=A0 voi=
d setX(int x) { _target.setX(x); }</div><div>=C2=A0 =C2=A0 int x() { return=
_target.x(); }</div><div><br></div><div>=C2=A0 private:</div><div>=C2=A0 =
=C2=A0 Private& _target;</div><div>=C2=A0 };</div><div>}</div></div><di=
v><br></div><div><div>class Client {</div><div>public:</div><div>=C2=A0 Cli=
ent(Private& target) : _target(target) { }</div><div><br></div><div>=C2=
=A0 int foo() {</div><div>=C2=A0 =C2=A0 auto accessor =3D detail::PrivateFr=
iend{_target};</div><div>=C2=A0 =C2=A0 accessor.setX(5);</div><div>=C2=A0 =
=C2=A0 return accessor.x();</div><div>=C2=A0 }</div><div><br></div><div>pri=
vate:</div><div>=C2=A0 Private& _target;</div><div>};</div><div><br></d=
iv><div>Since both Private and PrivateFriend are under your control you dec=
ide what private parts PrivateFriend can access. By hiding it in some non-p=
ublic namespace you effectively hide it from normal users and make it an im=
plementation detail. Normal users of your class are not supposed to use Pri=
vateFriend. You can make different friend classes for finer-grained access =
control, for example PrivateXFriend, PrivateYFriend, PrivatePositionFriend =
etc.</div><div><br></div><div>After the compiler is done with inlining ther=
e should be no indication left PrivateFriend ever existed.</div><div><div c=
lass=3D"h5"><div><br></div><div><blockquote type=3D"cite"><div>On 09 Jun 20=
15, at 15:07 , Gina Stephens <<a href=3D"mailto:zumbagina29@gmail.com" t=
arget=3D"_blank">zumbagina29@gmail.com</a>> wrote:</div><br><div><div di=
r=3D"ltr">Are you saying all children that inherit from the friend class al=
so inherit the friend relationship?=C2=A0 I don't believe this is true,=
so I tried it just to be sure.=C2=A0 As expected, I receive compilation er=
rors stating that my derived classes do not have access.=C2=A0 Do I misunde=
rstand you?<div><br></div><div>I understand that there are many alternative=
s to achieve the behavior that I want.=C2=A0 Heck, I could eliminate the &#=
39;Set' function altogether and just instantiate an instance of my '=
;creator' class with external linkage.=C2=A0 However, I want a solution=
that follows good design practices and makes my intent very clear.=C2=A0 I=
n my experience, the use of friend classes is a band aid for poor design.</=
div><div><br></div><div>By using an access modifier that limits accessibili=
ty within a namespace, this helps convey design intent and usage.</div><div=
><br></div><div>Thank you,</div><div><br></div><div>Gina</div><div><br></di=
v></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, J=
un 8, 2015 at 11:36 PM, David Krauss <span dir=3D"ltr"><<a href=3D"mailt=
o:potswa@mac.com" target=3D"_blank">potswa@mac.com</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><di=
v><blockquote type=3D"cite"><div>On 2015=E2=80=9306=E2=80=9309, at 11:07 AM=
, Gina Stephens <<a href=3D"mailto:zumbagina29@gmail.com" target=3D"_bla=
nk">zumbagina29@gmail.com</a>> wrote:</div><br><div><div dir=3D"ltr">Tha=
nk you, German, for the alternative.<div><br></div><div>The problem with us=
ing a friend class is that I don't know the type of the creator of the =
aDependency object until run-time.=C2=A0 This means that I would have to de=
clare every possible concrete type as a friend.=C2=A0 That solution is just=
not good design.</div></div></div></blockquote><div><br></div>Create a bas=
e type to serve as the friend. The concrete types derive from it. The base =
class is inside a detail namespace and does not pollute the derived interfa=
ce because it provides its accessor as <font face=3D"Courier">protected</fo=
nt> and/or always gets inherited as <font face=3D"Courier">private</font>.<=
/div></div><span><font color=3D"#888888"><div><br></div>
-- <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" 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>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div><div dir=3D"ltr">Gina Stephens, MSCS<br></div></div>
</div><div><br></div>
-- <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" 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></blockquote></div><br></div></div></div></div></div><div class=3D"HO=
EnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"ltr">Gina Stephens, MSCS<br></di=
v></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 />
--90e6ba6e86421156d8051815d7bc--
.
Author: Max Truxa <me@maxtruxa.com>
Date: Tue, 9 Jun 2015 08:11:55 -0700 (PDT)
Raw View
------=_Part_3113_765590068.1433862715601
Content-Type: multipart/alternative;
boundary="----=_Part_3114_1697743699.1433862715601"
------=_Part_3114_1697743699.1433862715601
Content-Type: text/plain; charset=UTF-8
What you are suggesting sounds much like .NET's "internal" access modifier,
which is not feasible ATM because there are no
"packages"/"modules"/whatever (yet).
Something like this could make sense in the future though depending on the
outcome of SG2 (Modules).
--
---
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_3114_1697743699.1433862715601
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>What you are suggesting sounds much like .NET's "inte=
rnal" access modifier, which is not feasible ATM because there are no "pack=
ages"/"modules"/whatever (yet).</div><div>Something like this could make se=
nse in the future though depending on the outcome of SG2 (Modules).</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_3114_1697743699.1433862715601--
------=_Part_3113_765590068.1433862715601--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Tue, 09 Jun 2015 19:58:52 +0200
Raw View
This is a multi-part message in MIME format.
--------------040404030307050404030606
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
It is only off-topic if you don't consider these solutions viable=20
altenatives to your proposal. It is on you to convince the committee=20
that your proposed solution is significantly superior to what can be=20
accomplished with the existing tools and warrant a core language change.=20
I am not on the committee and don't have any strong oppinion on this, I=20
was merely trying to explain Germ=C3=A1n's and David's solutions.
Am 09.06.2015 um 15:36 schrieb Gina Stephens:
> OK, thank you for the example. Yes, I have no doubt that there are=20
> multiple ways to achieve the desired behavior.
>
> I believe that we are getting off topic, though. Are you suggesting=20
> an alternative because you do not believe that my proposal has merit? =20
> If so, could you state why my proposal has no merit?
>
>
>
> On Tue, Jun 9, 2015 at 8:23 AM, Miro Knejp <miro.knejp@gmail.com=20
> <mailto:miro.knejp@gmail.com>> wrote:
>
> This is how it can be implemented with inheritance:
>
> class Private;
>
> namespace detail
> {
> class PrivateFriend {
> protected:
> PrivateFriend(Private& target) : _target(target) { }
> void setX(int x) { _target.setX(x); }
> int x() { return_target.x(); }
>
> private:
> Private& _target;
> };
> }
>
> class Private {
> void setX(int x);
> int x();
> =E2=80=A6
> friend detail::PrivateFriend;
> };
>
> class Client : private detail::PrivateFriend {
> public:
> Client(Private& target) : PrivateFriend(target) { }
>
> int foo() {
> setX(5);
> return x();
> }
> };
>
> Instead of making setX() and x() protected in PrivateFriend you
> can make them public to get rid of the inheritance requirement:
>
> namespace detail
> {
> class PrivateFriend {
> public:
> PrivateFriend(Private& target) : _target(target) { }
> void setX(int x) { _target.setX(x); }
> int x() { return_target.x(); }
>
> private:
> Private& _target;
> };
> }
>
> class Client {
> public:
> Client(Private& target) : _target(target) { }
>
> int foo() {
> auto accessor =3D detail::PrivateFriend{_target};
> accessor.setX(5);
> return accessor.x();
> }
>
> private:
> Private& _target;
> };
>
> Since both Private and PrivateFriend are under your control you
> decide what private parts PrivateFriend can access. By hiding it
> in some non-public namespace you effectively hide it from normal
> users and make it an implementation detail. Normal users of your
> class are not supposed to use PrivateFriend. You can make
> different friend classes for finer-grained access control, for
> example PrivateXFriend, PrivateYFriend, PrivatePositionFriend etc.
>
> After the compiler is done with inlining there should be no
> indication left PrivateFriend ever existed.
>
>> On 09 Jun 2015, at 15:07 , Gina Stephens <zumbagina29@gmail.com
>> <mailto:zumbagina29@gmail.com>> wrote:
>>
>> Are you saying all children that inherit from the friend class
>> also inherit the friend relationship? I don't believe this is
>> true, so I tried it just to be sure. As expected, I receive
>> compilation errors stating that my derived classes do not have
>> access. Do I misunderstand you?
>>
>> I understand that there are many alternatives to achieve the
>> behavior that I want. Heck, I could eliminate the 'Set' function
>> altogether and just instantiate an instance of my 'creator' class
>> with external linkage. However, I want a solution that follows
>> good design practices and makes my intent very clear. In my
>> experience, the use of friend classes is a band aid for poor design.
>>
>> By using an access modifier that limits accessibility within a
>> namespace, this helps convey design intent and usage.
>>
>> Thank you,
>>
>> Gina
>>
>>
>> On Mon, Jun 8, 2015 at 11:36 PM, David Krauss <potswa@mac.com
>> <mailto:potswa@mac.com>> wrote:
>>
>>
>>> On 2015=E2=80=9306=E2=80=9309, at 11:07 AM, Gina Stephens
>>> <zumbagina29@gmail.com <mailto:zumbagina29@gmail.com>> wrote:
>>>
>>> Thank you, German, for the alternative.
>>>
>>> The problem with using a friend class is that I don't know
>>> the type of the creator of the aDependency object until
>>> run-time. This means that I would have to declare every
>>> possible concrete type as a friend. That solution is just
>>> not good design.
>>
>> Create a base type to serve as the friend. The concrete types
>> derive from it. The base class is inside a detail namespace
>> and does not pollute the derived interface because it
>> provides its accessor as protected and/or always gets
>> inherited as private.
>>
>> --=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 email to std-proposals+unsubscribe@isocpp.org
>> <mailto:std-proposals+unsubscribe@isocpp.org>.
>> To post to this group, send email to std-proposals@isocpp.org
>> <mailto:std-proposals@isocpp.org>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>>
>>
>>
>> --=20
>> Gina Stephens, MSCS
>>
>> --=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 email to std-proposals+unsubscribe@isocpp.org
>> <mailto:std-proposals+unsubscribe@isocpp.org>.
>> To post to this group, send email to std-proposals@isocpp.org
>> <mailto:std-proposals@isocpp.org>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --=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 email to std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>
>
> --=20
> Gina Stephens, MSCS
> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> 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/.
--------------040404030307050404030606
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
It is only off-topic if you don't consider these solutions viable
altenatives to your proposal. It is on you to convince the committee
that your proposed solution is significantly superior to what can be
accomplished with the existing tools and warrant a core language
change. I am not on the committee and don't have any strong oppinion
on this, I was merely trying to explain Germ=C3=A1n's and David's
solutions.<br>
<br>
<div class=3D"moz-cite-prefix">Am 09.06.2015 um 15:36 schrieb Gina
Stephens:<br>
</div>
<blockquote
cite=3D"mid:CADPkdePaVmZWNVkNHHxc=3D5P4_dTS0dRzCV8e7_v++MgrrH1OtA@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">OK, thank you for the example.=C2=A0 Yes, I have no
doubt that there are multiple ways to achieve the desired
behavior.
<div><br>
</div>
<div>I believe that we are getting off topic, though.=C2=A0 Are you
suggesting an alternative because you do not believe that my
proposal has merit?=C2=A0 If so, could you state why my proposal
has no merit?</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Tue, Jun 9, 2015 at 8:23 AM, Miro
Knejp <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">miro.k=
nejp@gmail.com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style=3D"word-wrap:break-word">
<div>This is how it can be implemented with inheritance:</div=
>
<div><br>
</div>
<div>class Private;</div>
<div><br>
</div>
<div>namespace detail</div>
<div>{</div>
<div>=C2=A0 class PrivateFriend {</div>
<div>=C2=A0 protected:</div>
<div>=C2=A0 =C2=A0 PrivateFriend(Private& target) :
_target(target) { }</div>
<div>=C2=A0 =C2=A0 void setX(int x) { _target.setX(x); }</div=
>
<div>=C2=A0 =C2=A0 int x() { return_target.x(); }</div>
<div><br>
</div>
<div>=C2=A0 private:</div>
<div>=C2=A0 =C2=A0 Private& _target;</div>
<div>=C2=A0 };</div>
<div>}</div>
<div><br>
</div>
class Private {
<div>=C2=A0 void setX(int x);</div>
<div>=C2=A0 int x();</div>
<div>=C2=A0 =E2=80=A6</div>
<div>=C2=A0 friend detail::PrivateFriend;<br>
<div>};</div>
<div><br>
</div>
<div>class Client : private detail::PrivateFriend {</div>
<div>public:</div>
<div>=C2=A0 Client(Private& target) :
PrivateFriend(target) { }</div>
<div><br>
</div>
<div>=C2=A0 int foo() {</div>
<div>=C2=A0 =C2=A0 setX(5);</div>
<div>=C2=A0 =C2=A0 return x();</div>
<div>=C2=A0 }</div>
<div>};</div>
<div><br>
</div>
<div>Instead of making setX() and x() protected in
PrivateFriend you can make them public to get rid of
the inheritance requirement:</div>
<div><br>
</div>
<div>
<div>namespace detail</div>
<div>{</div>
<div>=C2=A0 class PrivateFriend {</div>
<div>=C2=A0 public:</div>
<div>=C2=A0 =C2=A0 PrivateFriend(Private& target) :
_target(target) { }</div>
<div>=C2=A0 =C2=A0 void setX(int x) { _target.setX(x); }<=
/div>
<div>=C2=A0 =C2=A0 int x() { return_target.x(); }</div>
<div><br>
</div>
<div>=C2=A0 private:</div>
<div>=C2=A0 =C2=A0 Private& _target;</div>
<div>=C2=A0 };</div>
<div>}</div>
</div>
<div><br>
</div>
<div>
<div>class Client {</div>
<div>public:</div>
<div>=C2=A0 Client(Private& target) : _target(target)=
{
}</div>
<div><br>
</div>
<div>=C2=A0 int foo() {</div>
<div>=C2=A0 =C2=A0 auto accessor =3D
detail::PrivateFriend{_target};</div>
<div>=C2=A0 =C2=A0 accessor.setX(5);</div>
<div>=C2=A0 =C2=A0 return accessor.x();</div>
<div>=C2=A0 }</div>
<div><br>
</div>
<div>private:</div>
<div>=C2=A0 Private& _target;</div>
<div>};</div>
<div><br>
</div>
<div>Since both Private and PrivateFriend are under
your control you decide what private parts
PrivateFriend can access. By hiding it in some
non-public namespace you effectively hide it from
normal users and make it an implementation detail.
Normal users of your class are not supposed to use
PrivateFriend. You can make different friend classes
for finer-grained access control, for example
PrivateXFriend, PrivateYFriend,
PrivatePositionFriend etc.</div>
<div><br>
</div>
<div>After the compiler is done with inlining there
should be no indication left PrivateFriend ever
existed.</div>
<div>
<div class=3D"h5">
<div><br>
</div>
<div>
<blockquote type=3D"cite">
<div>On 09 Jun 2015, at 15:07 , Gina Stephens
<<a moz-do-not-send=3D"true"
href=3D"mailto:zumbagina29@gmail.com"
target=3D"_blank">zumbagina29@gmail.com</a>&g=
t;
wrote:</div>
<br>
<div>
<div dir=3D"ltr">Are you saying all children
that inherit from the friend class also
inherit the friend relationship?=C2=A0 I don'=
t
believe this is true, so I tried it just
to be sure.=C2=A0 As expected, I receive
compilation errors stating that my derived
classes do not have access.=C2=A0 Do I
misunderstand you?
<div><br>
</div>
<div>I understand that there are many
alternatives to achieve the behavior
that I want.=C2=A0 Heck, I could eliminate
the 'Set' function altogether and just
instantiate an instance of my 'creator'
class with external linkage.=C2=A0 However,=
I
want a solution that follows good design
practices and makes my intent very
clear.=C2=A0 In my experience, the use of
friend classes is a band aid for poor
design.</div>
<div><br>
</div>
<div>By using an access modifier that
limits accessibility within a namespace,
this helps convey design intent and
usage.</div>
<div><br>
</div>
<div>Thank you,</div>
<div><br>
</div>
<div>Gina</div>
<div><br>
</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Mon, Jun 8,
2015 at 11:36 PM, David Krauss <span
dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:potswa@mac.com"
target=3D"_blank">potswa@mac.com</a>>=
;</span>
wrote:<br>
<blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div style=3D"word-wrap:break-word"><br>
<div>
<blockquote type=3D"cite">
<div>On 2015=E2=80=9306=E2=80=9309,=
at 11:07 AM,
Gina Stephens <<a
moz-do-not-send=3D"true"
href=3D"mailto:zumbagina29@gmai=
l.com"
target=3D"_blank">zumbagina29@g=
mail.com</a>>
wrote:</div>
<br>
<div>
<div dir=3D"ltr">Thank you,
German, for the alternative.
<div><br>
</div>
<div>The problem with using
a friend class is that I
don't know the type of the
creator of the aDependency
object until run-time.=C2=A0
This means that I would
have to declare every
possible concrete type as
a friend.=C2=A0 That solution
is just not good design.</div=
>
</div>
</div>
</blockquote>
<div><br>
</div>
Create a base type to serve as the
friend. The concrete types derive
from it. The base class is inside
a detail namespace and does not
pollute the derived interface
because it provides its accessor
as <font face=3D"Courier">protected</=
font>
and/or always gets inherited as <font
face=3D"Courier">private</font>.</d=
iv>
</div>
<span><font color=3D"#888888">
<div><br>
</div>
-- <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 <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubs=
cribe@isocpp.org"
target=3D"_blank">std-proposals+uns=
ubscribe@isocpp.org</a>.<br>
To post to this group, send email
to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp=
..org"
target=3D"_blank">std-proposals@iso=
cpp.org</a>.<br>
Visit this group at <a
moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/=
isocpp.org/group/std-proposals/"
target=3D"_blank">http://groups.goo=
gle.com/a/isocpp.org/group/std-proposals/</a>.<br>
</font></span></blockquote>
</div>
<br>
<br clear=3D"all">
<div><br>
</div>
-- <br>
<div>
<div dir=3D"ltr">Gina Stephens, MSCS<br>
</div>
</div>
</div>
<div><br>
</div>
-- <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 <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isoc=
pp.org"
target=3D"_blank">std-proposals+unsubscribe@i=
socpp.org</a>.<br>
To post to this group, send email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org"
target=3D"_blank">std-proposals@isocpp.org</a=
>.<br>
Visit this group at <a
moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org=
/group/std-proposals/"
target=3D"_blank">http://groups.google.com/a/=
isocpp.org/group/std-proposals/</a>.<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
<div class=3D"HOEnZb">
<div class=3D"h5">
-- <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 <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org"
target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a=
>.<br>
To post to this group, send email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank=
">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-p=
roposals/"
target=3D"_blank">http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear=3D"all">
<div><br>
</div>
-- <br>
<div class=3D"gmail_signature">
<div dir=3D"ltr">Gina Stephens, MSCS<br>
</div>
</div>
</div>
-- <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 <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------040404030307050404030606--
.
Author: Gina Stephens <zumbagina29@gmail.com>
Date: Tue, 9 Jun 2015 15:29:23 -0500
Raw View
--bcaec51824a62ad31205181b9de3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
What I mean is that my proposal was for a new language feature, not a
request for an alternative implementation. Therefore, I was hoping for
responses that were either pros or cons for such a language feature.
To Max's point - Right, very similar to the "internal" access modifier in
C# or the default access modifier in JAVA. The difference is that this
would be accessibile within the same namespace, which should be achievable
in C++. I do not know of a reason why this feature would not be possible
in C++. Do you?
Thank you,
Gina
On Tue, Jun 9, 2015 at 12:58 PM, Miro Knejp <miro.knejp@gmail.com> wrote:
> It is only off-topic if you don't consider these solutions viable
> altenatives to your proposal. It is on you to convince the committee that
> your proposed solution is significantly superior to what can be
> accomplished with the existing tools and warrant a core language change. =
I
> am not on the committee and don't have any strong oppinion on this, I was
> merely trying to explain Germ=C3=A1n's and David's solutions.
>
>
> Am 09.06.2015 um 15:36 schrieb Gina Stephens:
>
> OK, thank you for the example. Yes, I have no doubt that there are
> multiple ways to achieve the desired behavior.
>
> I believe that we are getting off topic, though. Are you suggesting an
> alternative because you do not believe that my proposal has merit? If so=
,
> could you state why my proposal has no merit?
>
>
>
> On Tue, Jun 9, 2015 at 8:23 AM, Miro Knejp <miro.knejp@gmail.com> wrote:
>
>> This is how it can be implemented with inheritance:
>>
>> class Private;
>>
>> namespace detail
>> {
>> class PrivateFriend {
>> protected:
>> PrivateFriend(Private& target) : _target(target) { }
>> void setX(int x) { _target.setX(x); }
>> int x() { return_target.x(); }
>>
>> private:
>> Private& _target;
>> };
>> }
>>
>> class Private {
>> void setX(int x);
>> int x();
>> =E2=80=A6
>> friend detail::PrivateFriend;
>> };
>>
>> class Client : private detail::PrivateFriend {
>> public:
>> Client(Private& target) : PrivateFriend(target) { }
>>
>> int foo() {
>> setX(5);
>> return x();
>> }
>> };
>>
>> Instead of making setX() and x() protected in PrivateFriend you can
>> make them public to get rid of the inheritance requirement:
>>
>> namespace detail
>> {
>> class PrivateFriend {
>> public:
>> PrivateFriend(Private& target) : _target(target) { }
>> void setX(int x) { _target.setX(x); }
>> int x() { return_target.x(); }
>>
>> private:
>> Private& _target;
>> };
>> }
>>
>> class Client {
>> public:
>> Client(Private& target) : _target(target) { }
>>
>> int foo() {
>> auto accessor =3D detail::PrivateFriend{_target};
>> accessor.setX(5);
>> return accessor.x();
>> }
>>
>> private:
>> Private& _target;
>> };
>>
>> Since both Private and PrivateFriend are under your control you decide
>> what private parts PrivateFriend can access. By hiding it in some
>> non-public namespace you effectively hide it from normal users and make =
it
>> an implementation detail. Normal users of your class are not supposed to
>> use PrivateFriend. You can make different friend classes for finer-grain=
ed
>> access control, for example PrivateXFriend, PrivateYFriend,
>> PrivatePositionFriend etc.
>>
>> After the compiler is done with inlining there should be no indication
>> left PrivateFriend ever existed.
>>
>> On 09 Jun 2015, at 15:07 , Gina Stephens <zumbagina29@gmail.com> wrote=
:
>>
>> Are you saying all children that inherit from the friend class also
>> inherit the friend relationship? I don't believe this is true, so I tri=
ed
>> it just to be sure. As expected, I receive compilation errors stating t=
hat
>> my derived classes do not have access. Do I misunderstand you?
>>
>> I understand that there are many alternatives to achieve the behavior
>> that I want. Heck, I could eliminate the 'Set' function altogether and
>> just instantiate an instance of my 'creator' class with external linkage=
..
>> However, I want a solution that follows good design practices and makes =
my
>> intent very clear. In my experience, the use of friend classes is a ban=
d
>> aid for poor design.
>>
>> By using an access modifier that limits accessibility within a
>> namespace, this helps convey design intent and usage.
>>
>> Thank you,
>>
>> Gina
>>
>>
>> On Mon, Jun 8, 2015 at 11:36 PM, David Krauss <potswa@mac.com> wrote:
>>
>>>
>>> On 2015=E2=80=9306=E2=80=9309, at 11:07 AM, Gina Stephens <zumbagina29=
@gmail.com>
>>> wrote:
>>>
>>> Thank you, German, for the alternative.
>>>
>>> The problem with using a friend class is that I don't know the type of
>>> the creator of the aDependency object until run-time. This means that =
I
>>> would have to declare every possible concrete type as a friend. That
>>> solution is just not good design.
>>>
>>>
>>> Create a base type to serve as the friend. The concrete types derive
>>> from it. The base class is inside a detail namespace and does not pollu=
te
>>> the derived interface because it provides its accessor as protected
>>> and/or always gets inherited as private.
>>>
>>> --
>>>
>>> ---
>>> 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/.
>>>
>>
>>
>>
>> --
>> Gina Stephens, MSCS
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
>
> --
> Gina Stephens, MSCS
> --
>
> ---
> 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 a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/djJjY4ksxt4/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
>
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
Gina Stephens, MSCS
--=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/.
--bcaec51824a62ad31205181b9de3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What I mean is that my proposal was for a new language fea=
ture, not a request for an alternative implementation.=C2=A0 Therefore, I w=
as hoping for responses that were either pros or cons for such a language f=
eature.<div><br></div><div>To Max's point - Right, very similar to the =
"internal" access modifier in C# or the default access modifier i=
n JAVA.=C2=A0 The difference is that this would be accessibile within the s=
ame namespace, which should be achievable in C++.=C2=A0 I do not know of a =
reason why this feature would not be possible in C++.=C2=A0 Do you?</div><d=
iv><br></div><div>Thank you,</div><div><br></div><div>Gina</div><div><br></=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue,=
Jun 9, 2015 at 12:58 PM, Miro Knejp <span dir=3D"ltr"><<a href=3D"mailt=
o:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>></spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
It is only off-topic if you don't consider these solutions viable
altenatives to your proposal. It is on you to convince the committee
that your proposed solution is significantly superior to what can be
accomplished with the existing tools and warrant a core language
change. I am not on the committee and don't have any strong oppinio=
n
on this, I was merely trying to explain Germ=C3=A1n's and David'=
;s
solutions.<div><div class=3D"h5"><br>
<br>
<div>Am 09.06.2015 um 15:36 schrieb Gina
Stephens:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">OK, thank you for the example.=C2=A0 Yes, I have no
doubt that there are multiple ways to achieve the desired
behavior.
<div><br>
</div>
<div>I believe that we are getting off topic, though.=C2=A0 Are you
suggesting an alternative because you do not believe that my
proposal has merit?=C2=A0 If so, could you state why my proposal
has no merit?</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Tue, Jun 9, 2015 at 8:23 AM, Miro
Knejp <span dir=3D"ltr"><<a href=3D"mailto:miro.knejp@gmail.co=
m" target=3D"_blank">miro.knejp@gmail.com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
<div style=3D"word-wrap:break-word">
<div>This is how it can be implemented with inheritance:</div=
>
<div><br>
</div>
<div>class Private;</div>
<div><br>
</div>
<div>namespace detail</div>
<div>{</div>
<div>=C2=A0 class PrivateFriend {</div>
<div>=C2=A0 protected:</div>
<div>=C2=A0 =C2=A0 PrivateFriend(Private& target) :
_target(target) { }</div>
<div>=C2=A0 =C2=A0 void setX(int x) { _target.setX(x); }</div=
>
<div>=C2=A0 =C2=A0 int x() { return_target.x(); }</div>
<div><br>
</div>
<div>=C2=A0 private:</div>
<div>=C2=A0 =C2=A0 Private& _target;</div>
<div>=C2=A0 };</div>
<div>}</div>
<div><br>
</div>
class Private {
<div>=C2=A0 void setX(int x);</div>
<div>=C2=A0 int x();</div>
<div>=C2=A0 =E2=80=A6</div>
<div>=C2=A0 friend detail::PrivateFriend;<br>
<div>};</div>
<div><br>
</div>
<div>class Client : private detail::PrivateFriend {</div>
<div>public:</div>
<div>=C2=A0 Client(Private& target) :
PrivateFriend(target) { }</div>
<div><br>
</div>
<div>=C2=A0 int foo() {</div>
<div>=C2=A0 =C2=A0 setX(5);</div>
<div>=C2=A0 =C2=A0 return x();</div>
<div>=C2=A0 }</div>
<div>};</div>
<div><br>
</div>
<div>Instead of making setX() and x() protected in
PrivateFriend you can make them public to get rid of
the inheritance requirement:</div>
<div><br>
</div>
<div>
<div>namespace detail</div>
<div>{</div>
<div>=C2=A0 class PrivateFriend {</div>
<div>=C2=A0 public:</div>
<div>=C2=A0 =C2=A0 PrivateFriend(Private& target) :
_target(target) { }</div>
<div>=C2=A0 =C2=A0 void setX(int x) { _target.setX(x); }<=
/div>
<div>=C2=A0 =C2=A0 int x() { return_target.x(); }</div>
<div><br>
</div>
<div>=C2=A0 private:</div>
<div>=C2=A0 =C2=A0 Private& _target;</div>
<div>=C2=A0 };</div>
<div>}</div>
</div>
<div><br>
</div>
<div>
<div>class Client {</div>
<div>public:</div>
<div>=C2=A0 Client(Private& target) : _target(target)=
{
}</div>
<div><br>
</div>
<div>=C2=A0 int foo() {</div>
<div>=C2=A0 =C2=A0 auto accessor =3D
detail::PrivateFriend{_target};</div>
<div>=C2=A0 =C2=A0 accessor.setX(5);</div>
<div>=C2=A0 =C2=A0 return accessor.x();</div>
<div>=C2=A0 }</div>
<div><br>
</div>
<div>private:</div>
<div>=C2=A0 Private& _target;</div>
<div>};</div>
<div><br>
</div>
<div>Since both Private and PrivateFriend are under
your control you decide what private parts
PrivateFriend can access. By hiding it in some
non-public namespace you effectively hide it from
normal users and make it an implementation detail.
Normal users of your class are not supposed to use
PrivateFriend. You can make different friend classes
for finer-grained access control, for example
PrivateXFriend, PrivateYFriend,
PrivatePositionFriend etc.</div>
<div><br>
</div>
<div>After the compiler is done with inlining there
should be no indication left PrivateFriend ever
existed.</div>
<div>
<div>
<div><br>
</div>
<div>
<blockquote type=3D"cite">
<div>On 09 Jun 2015, at 15:07 , Gina Stephens
<<a href=3D"mailto:zumbagina29@gmail.com" ta=
rget=3D"_blank">zumbagina29@gmail.com</a>>
wrote:</div>
<br>
<div>
<div dir=3D"ltr">Are you saying all children
that inherit from the friend class also
inherit the friend relationship?=C2=A0 I don&=
#39;t
believe this is true, so I tried it just
to be sure.=C2=A0 As expected, I receive
compilation errors stating that my derived
classes do not have access.=C2=A0 Do I
misunderstand you?
<div><br>
</div>
<div>I understand that there are many
alternatives to achieve the behavior
that I want.=C2=A0 Heck, I could eliminate
the 'Set' function altogether and j=
ust
instantiate an instance of my 'creator&=
#39;
class with external linkage.=C2=A0 However,=
I
want a solution that follows good design
practices and makes my intent very
clear.=C2=A0 In my experience, the use of
friend classes is a band aid for poor
design.</div>
<div><br>
</div>
<div>By using an access modifier that
limits accessibility within a namespace,
this helps convey design intent and
usage.</div>
<div><br>
</div>
<div>Thank you,</div>
<div><br>
</div>
<div>Gina</div>
<div><br>
</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Mon, Jun 8,
2015 at 11:36 PM, David Krauss <span dir=3D=
"ltr"><<a href=3D"mailto:potswa@mac.com" target=3D"_blank">potswa@mac.co=
m</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style=3D"word-wrap:break-word"><br>
<div>
<blockquote type=3D"cite">
<div>On 2015=E2=80=9306=E2=80=9309,=
at 11:07 AM,
Gina Stephens <<a href=3D"mail=
to:zumbagina29@gmail.com" target=3D"_blank">zumbagina29@gmail.com</a>>
wrote:</div>
<br>
<div>
<div dir=3D"ltr">Thank you,
German, for the alternative.
<div><br>
</div>
<div>The problem with using
a friend class is that I
don't know the type of th=
e
creator of the aDependency
object until run-time.=C2=A0
This means that I would
have to declare every
possible concrete type as
a friend.=C2=A0 That solution
is just not good design.</div=
>
</div>
</div>
</blockquote>
<div><br>
</div>
Create a base type to serve as the
friend. The concrete types derive
from it. The base class is inside
a detail namespace and does not
pollute the derived interface
because it provides its accessor
as <font face=3D"Courier">protected</=
font>
and/or always gets inherited as <font=
face=3D"Courier">private</font>.</div>
</div>
<span><font color=3D"#888888">
<div><br>
</div>
-- <br>
<br>
--- <br>
You received this message because
you are subscribed to the Google
Groups "ISO C++ Standard - Futur=
e
Proposals" group.<br>
To unsubscribe from this group and
stop receiving emails from it,
send an email to <a href=3D"mailto:st=
d-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-proposals+unsubsc=
ribe@isocpp.org</a>.<br>
To post to this group, send email
to <a href=3D"mailto:std-proposals@is=
ocpp.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">htt=
p://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</font></span></blockquote>
</div>
<br>
<br clear=3D"all">
<div><br>
</div>
-- <br>
<div>
<div dir=3D"ltr">Gina Stephens, MSCS<br>
</div>
</div>
</div>
<div><br>
</div>
-- <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 <a h=
ref=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-p=
roposals+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.or=
g</a>.<br>
Visit this group at <a href=3D"http://groups.go=
ogle.com/a/isocpp.org/group/std-proposals/" target=3D"_blank">http://groups=
..google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
-- <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 <a href=3D"mailto:std-proposals+u=
nsubscribe@isocpp.org" target=3D"_blank">std-proposals+unsubscribe@isocpp.o=
rg</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/i=
socpp.org/group/std-proposals/" target=3D"_blank">http://groups.google.com/=
a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear=3D"all">
<div><br>
</div>
-- <br>
<div>
<div dir=3D"ltr">Gina Stephens, MSCS<br>
</div>
</div>
</div>
-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.o=
rg" 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.o=
rg/group/std-proposals/</a>.<br>
</blockquote>
<br>
</div></div></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/djJjY4ksxt4/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/djJjY4ksxt4=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.</font></span><div class=3D"HOEnZb"><div c=
lass=3D"h5"><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><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"ltr">Gina Stephens, MSCS<br></di=
v></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 />
--bcaec51824a62ad31205181b9de3--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 9 Jun 2015 15:57:26 -0500
Raw View
--001a11c23d9cebe18005181c039d
Content-Type: text/plain; charset=UTF-8
On 9 June 2015 at 15:29, Gina Stephens <zumbagina29@gmail.com> wrote:
> What I mean is that my proposal was for a new language feature, not a
> request for an alternative implementation.
>
Right now it isn't a proposal; it's just an idea. A proposal would have to
explore the design space and explain why current implementation techniques
are insufficient.
> The difference is that this would be accessibile within the same
> namespace, which should be achievable in C++.
>
I don't see how "namespace" helps.
Except for namespace std, anyone can reopen a namespace and add things to
it.
How is that substantially different than adding a friend?
class MyClass
{
// removed the other stuff, since it is irrelevant to this feature
void SetDependency(aDependency* depends);
friend class MyClassSetDependencyAccessor;
//...
};
struct MyClassSetDependencyAccessor
{
void SetDependency(MyClass& myClass, aDependency* depends)
{ myClass.SetDependency(depends); }
};
Versus:
class MyClass
{
namespace ns:
void SetDependency(aDependency* depends);
//...
};
namespace ns {
struct MyClassSetDependencyAccessor
{
void SetDependency(MyClass& myClass, aDependency* depends)
{ myClass.SetDependency(depends); }
};
}
> I do not know of a reason why this feature would not be possible in C++.
> Do you?
>
Possible to implement is just a tiny part of a language feature proposal.
You really have to answer the question of "Why is it worth doing?"
--
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/.
--001a11c23d9cebe18005181c039d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 9=
June 2015 at 15:29, Gina Stephens <span dir=3D"ltr"><<a href=3D"mailto:=
zumbagina29@gmail.com" target=3D"_blank">zumbagina29@gmail.com</a>></spa=
n> 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;padding-left:1ex"><div dir=3D"ltr">What I mean is that my propo=
sal was for a new language feature, not a request for an alternative implem=
entation.</div></blockquote><div><br></div><div>Right now it isn't a pr=
oposal; it's just an idea.=C2=A0 A proposal would have to explore the d=
esign space and explain why current implementation techniques are insuffici=
ent.</div><div>=C2=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>The diffe=
rence is that this would be accessibile within the same namespace, which sh=
ould be achievable in C++.=C2=A0</div></div></blockquote><div><br></div><di=
v>I don't see how "namespace" helps.</div><div><br></div><div=
>Except for namespace std, anyone can reopen a namespace and add things to =
it.</div><div><br></div><div>How is that substantially different than addin=
g a friend?</div><div><br></div><div><font face=3D"monospace, monospace" si=
ze=3D"1">class MyClass<br>{</font></div><div><font face=3D"monospace, monos=
pace" size=3D"1">=C2=A0 =C2=A0 // removed the other stuff, since it is irre=
levant to this feature</font></div><div><font face=3D"monospace, monospace"=
size=3D"1">=C2=A0 =C2=A0void SetDependency(aDependency* depends);</font></=
div><div><font face=3D"monospace, monospace" size=3D"1">=C2=A0 =C2=A0friend=
class MyClassSetDependencyAccessor;</font></div><div><font face=3D"monospa=
ce, monospace" size=3D"1">=C2=A0 =C2=A0//...</font></div><div><font face=3D=
"monospace, monospace" size=3D"1">};<br></font></div><div><font face=3D"mon=
ospace, monospace" size=3D"1"><br></font></div><div><font face=3D"monospace=
, monospace" size=3D"1">struct=C2=A0MyClassSetDependencyAccessor</font></di=
v><div><font face=3D"monospace, monospace" size=3D"1">{</font></div><div><f=
ont face=3D"monospace, monospace" size=3D"1">=C2=A0 =C2=A0 void SetDependen=
cy(MyClass& myClass, aDependency* depends)</font></div><div><font face=
=3D"monospace, monospace" size=3D"1">=C2=A0 =C2=A0 { myClass.SetDependency(=
depends); }</font></div><div><font face=3D"monospace, monospace" size=3D"1"=
>};</font></div><div><span style=3D"font-size:12.8000001907349px"><br></spa=
n></div><div><span style=3D"font-size:12.8000001907349px">Versus:</span></d=
iv><div><span style=3D"font-size:12.8000001907349px"><br></span></div><div>=
<font size=3D"1" face=3D"monospace, monospace">class MyClass<br></font></di=
v><div><font size=3D"1" face=3D"monospace, monospace">{</font></div><div><f=
ont size=3D"1" face=3D"monospace, monospace">namespace ns:</font></div><div=
><font size=3D"1" face=3D"monospace, monospace">=C2=A0 =C2=A0void SetDepend=
ency(aDependency* depends);<br></font></div><div><font size=3D"1" face=3D"m=
onospace, monospace">=C2=A0 =C2=A0//...</font></div><div><font size=3D"1" f=
ace=3D"monospace, monospace">};<br></font></div><div><font size=3D"1" face=
=3D"monospace, monospace"><br></font></div><div><font size=3D"1" face=3D"mo=
nospace, monospace">namespace ns {</font></div><div><font size=3D"1" face=
=3D"monospace, monospace">struct=C2=A0MyClassSetDependencyAccessor</font></=
div><div><font size=3D"1" face=3D"monospace, monospace">{</font></div><div>=
<font size=3D"1" face=3D"monospace, monospace">=C2=A0 =C2=A0 void SetDepend=
ency(MyClass& myClass, aDependency* depends)</font></div><div><font siz=
e=3D"1" face=3D"monospace, monospace">=C2=A0 =C2=A0 { myClass.SetDependency=
(depends); }</font></div><div><font size=3D"1" face=3D"monospace, monospace=
">};</font></div><div><font size=3D"1" face=3D"monospace, monospace">}</fon=
t></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div> I do n=
ot know of a reason why this feature would not be possible in C++.=C2=A0 Do=
you?</div></div></blockquote><div><br></div><div>Possible to implement is =
just a tiny part of a language feature proposal.=C2=A0 You really have to a=
nswer the question of "Why is it worth doing?"</div></div>-- <br>=
<div class=3D"gmail_signature">=C2=A0Nevin ":-)" Liber=C2=A0 <=
mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@ev=
iloverlord.com</a>>=C2=A0 (847) 691-1404</div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a11c23d9cebe18005181c039d--
.
Author: Gina Stephens <zumbagina29@gmail.com>
Date: Tue, 9 Jun 2015 21:08:17 -0500
Raw View
--089e011604122c2d8f05182059cc
Content-Type: text/plain; charset=UTF-8
On Jun 9, 2015 3:58 PM, "Nevin Liber" <nevin@eviloverlord.com> wrote:
>
> On 9 June 2015 at 15:29, Gina Stephens <zumbagina29@gmail.com> wrote:
>>
>> What I mean is that my proposal was for a new language feature, not a
request for an alternative implementation.
>
>
> Right now it isn't a proposal; it's just an idea. A proposal would have
to explore the design space and explain why current implementation
techniques are insufficient.
GMS- Yes, right. It is a proposal for a proposal. How about that? :)
>
>>
>> The difference is that this would be accessibile within the same
namespace, which should be achievable in C++.
>
>
> I don't see how "namespace" helps.
>
> Except for namespace std, anyone can reopen a namespace and add things to
it.
>
> How is that substantially different than adding a friend?
>
> class MyClass
> {
> // removed the other stuff, since it is irrelevant to this feature
> void SetDependency(aDependency* depends);
> friend class MyClassSetDependencyAccessor;
> //...
> };
>
> struct MyClassSetDependencyAccessor
> {
> void SetDependency(MyClass& myClass, aDependency* depends)
> { myClass.SetDependency(depends); }
> };
>
>
> };
>
GMS- The problem is that MyClass has to know about every possible
aDependency creator. What if I have multiple? Should I really have to
change MyClass to add another friend when a new one is defined? Usage of
friend creates a coupling that I don't want or need. Not only that, but do
I really want to allow open access to a friend just to call one function?
No, I don't.
By declaring a function as only accessible within a namespace, this conveys
meaning and intent, just like the existing access modifiers. Friend does
not.
>>
>> I do not know of a reason why this feature would not be possible in
C++. Do you?
>
>
> Possible to implement is just a tiny part of a language feature
proposal. You really have to answer the question of "Why is it worth
doing?"
> --
GMS- Yes, I completely agree. I believe that I can make a case, though.
--
---
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/.
--089e011604122c2d8f05182059cc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Jun 9, 2015 3:58 PM, "Nevin Liber" <<a href=3D"mailto:nevin=
@eviloverlord.com">nevin@eviloverlord.com</a>> wrote:<br>
><br>
> On 9 June 2015 at 15:29, Gina Stephens <<a href=3D"mailto:zumbagina=
29@gmail.com">zumbagina29@gmail.com</a>> wrote:<br>
>><br>
>> What I mean is that my proposal was for a new language feature, no=
t a request for an alternative implementation.<br>
><br>
><br>
> Right now it isn't a proposal; it's just an idea.=C2=A0 A prop=
osal would have to explore the design space and explain why current impleme=
ntation techniques are insufficient.</p>
<p dir=3D"ltr">GMS- Yes, right. It is a proposal for a proposal. How about =
that? :)<br></p>
<p dir=3D"ltr">> =C2=A0<br>
>><br>
>> The difference is that this would be accessibile within the same n=
amespace, which should be achievable in C++.=C2=A0<br>
><br>
><br>
> I don't see how "namespace" helps.<br>
><br>
> Except for namespace std, anyone can reopen a namespace and add things=
to it.<br>
><br>
> How is that substantially different than adding a friend?<br>
><br>
> class MyClass<br>
> {<br>
> =C2=A0 =C2=A0 // removed the other stuff, since it is irrelevant to th=
is feature<br>
> =C2=A0 =C2=A0void SetDependency(aDependency* depends);<br>
> =C2=A0 =C2=A0friend class MyClassSetDependencyAccessor;<br>
> =C2=A0 =C2=A0//...<br>
> };<br>
><br>
> struct=C2=A0MyClassSetDependencyAccessor<br>
> {<br>
> =C2=A0 =C2=A0 void SetDependency(MyClass& myClass, aDependency* de=
pends)<br>
> =C2=A0 =C2=A0 { myClass.SetDependency(depends); }<br>
> };<br>
><br>
><br>
> };<br>
></p>
<p dir=3D"ltr">GMS- The problem is that MyClass has to know about every pos=
sible aDependency creator. What if I have multiple? Should I really have to=
change MyClass to add another friend when a new one is defined? Usage of f=
riend creates a coupling that I don't want or need. Not only that, but =
do I really want to allow open access to a friend just to call one function=
? No, I don't. </p>
<p dir=3D"ltr">By declaring a function as only accessible within a namespac=
e, this conveys meaning and intent, just like the existing access modifiers=
.. Friend does not. </p>
<p dir=3D"ltr">>><br>
>> I do not know of a reason why this feature would not be possible i=
n C++.=C2=A0 Do you?<br>
><br>
><br>
> Possible to implement is just a tiny part of a language feature propos=
al.=C2=A0 You really have to answer the question of "Why is it worth d=
oing?"<br>
> -- </p>
<p dir=3D"ltr">GMS- Yes, I completely agree. I believe that I can make a ca=
se, though.<br>
</p>
<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 />
--089e011604122c2d8f05182059cc--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 9 Jun 2015 21:36:49 -0500
Raw View
--001a11c3bad8a8e4fa051820c1c8
Content-Type: text/plain; charset=UTF-8
On 9 June 2015 at 21:08, Gina Stephens <zumbagina29@gmail.com> wrote:
> > I don't see how "namespace" helps.
>
> >
> > Except for namespace std, anyone can reopen a namespace and add things
> to it.
> >
> > How is that substantially different than adding a friend?
> >
> > class MyClass
> > {
> > // removed the other stuff, since it is irrelevant to this feature
> > void SetDependency(aDependency* depends);
> > friend class MyClassSetDependencyAccessor;
> > //...
> > };
> >
> > struct MyClassSetDependencyAccessor
> > {
> > void SetDependency(MyClass& myClass, aDependency* depends)
> > { myClass.SetDependency(depends); }
> > };
> >
> >
> > };
> >
>
> GMS- The problem is that MyClass has to know about every possible
> aDependency creator.
>
Why? In either case (MyClassSetDependencyAccessor being either a friend or
in the same namespace), *anybody* can use the MyClassSetDependencyAccessor
to call MyClass::SetDependency.
> What if I have multiple?
>
Multiple what? You can add any number of forwarding functions to
MyClassSetDependencyAccessor.
> Should I really have to change MyClass to add another friend when a new
> one is defined? Usage of friend creates a coupling that I don't want or
> need. Not only that, but do I really want to allow open access to a friend
> just to call one function? No, I don't.
>
I still don't see how limiting it to a namespace doesn't allow open access,
again, because there is nothing in the language stopping anyone from adding
things to a namespace (except namespace std).
> By declaring a function as only accessible within a namespace, this
> conveys meaning and intent, just like the existing access modifiers.
>
No, the existing modifiers actually limit access; this idea does not.
Show us how this mechanism can ever stop anyone from legally calling
MyClass::SetDependency if one has an instance of MyClass. I just don't see
it.
> --
>
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/.
--001a11c3bad8a8e4fa051820c1c8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 9 June 2015 at 21:08, Gina Stephens <span dir=3D"ltr">&=
lt;<a href=3D"mailto:zumbagina29@gmail.com" target=3D"_blank">zumbagina29@g=
mail.com</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-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><span class=3D""><p dir=3D"ltr">> I don=
9;t see how "namespace" helps.<br></p></span><p dir=3D"ltr"><span=
class=3D"">
><br>
> Except for namespace std, anyone can reopen a namespace and add things=
to it.<br>
><br>
> How is that substantially different than adding a friend?<br>
><br>
> class MyClass<br>
> {<br>
> =C2=A0 =C2=A0 // removed the other stuff, since it is irrelevant to th=
is feature<br>
> =C2=A0 =C2=A0void SetDependency(aDependency* depends);<br>
> =C2=A0 =C2=A0friend class MyClassSetDependencyAccessor;<br>
> =C2=A0 =C2=A0//...<br>
> };<br>
><br>
> struct=C2=A0MyClassSetDependencyAccessor<br>
> {<br>
> =C2=A0 =C2=A0 void SetDependency(MyClass& myClass, aDependency* de=
pends)<br>
> =C2=A0 =C2=A0 { myClass.SetDependency(depends); }<br>
> };<br>
><br>
><br></span>
> };<br>
></p>
<p dir=3D"ltr">GMS- The problem is that MyClass has to know about every pos=
sible aDependency creator.</p></blockquote><div>Why?=C2=A0 In either case (=
MyClassSetDependencyAccessor being either a friend or in the same namespace=
), *anybody* can use the MyClassSetDependencyAccessor to call MyClass::SetD=
ependency.</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><p dir=3D"ltr"> What =
if I have multiple?</p></blockquote><div>Multiple what?=C2=A0 You can add a=
ny number of forwarding functions to MyClassSetDependencyAccessor.</div><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"><p dir=3D"ltr">Should I really have to change MyClass to add =
another friend when a new one is defined? Usage of friend creates a couplin=
g that I don't want or need. Not only that, but do I really want to all=
ow open access to a friend just to call one function? No, I don't.</p><=
/blockquote><div>I still don't see how limiting it to a namespace doesn=
't allow open access, again, because there is nothing in the language s=
topping anyone from adding things to a namespace (except namespace std).</d=
iv><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"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">By declaring a function as only accessible within a namespac=
e, this conveys meaning and intent, just like the existing access modifiers=
..</p></blockquote><div>No, the existing modifiers actually limit access; th=
is idea does not.</div><div><br></div><div>Show us how this mechanism can e=
ver stop anyone from legally calling MyClass::SetDependency if one has an i=
nstance of MyClass.=C2=A0 I just don't see it.</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<p dir=3D"ltr">--=C2=A0<br></p></blockquote></div><div class=3D"gmail_signa=
ture">=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:=
nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=C2=
=A0 (847) 691-1404</div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a11c3bad8a8e4fa051820c1c8--
.
Author: David Krauss <potswa@mac.com>
Date: Wed, 10 Jun 2015 11:05:57 +0800
Raw View
--Apple-Mail=_711B4260-DFE7-4836-9A8C-02834B76C183
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9310, at 10:08 AM, Gina Stephens <zumbagina29@gm=
ail.com> wrote:
> GMS- The problem is that MyClass has to know about every possible aDepend=
ency creator. What if I have multiple? Should I really have to change MyCla=
ss to add another friend when a new one is defined?
>=20
No, Germ=C3=A1n=E2=80=99s canonical solution does not have that problem. My=
Class has only one friend, ever.
> By declaring a function as only accessible within a namespace, this conve=
ys meaning and intent, just like the existing access modifiers. Friend does=
not.=20
>=20
The base class, call it DependencyInjector, could require by protected acce=
ss that any class must declare itself to =E2=80=9Cbe-a=E2=80=9D DependencyI=
njector if it wants to call SetDependency. That is more expressive than all=
owing the call to be made anywhere.
> Usage of friend creates a coupling that I don't want or need. Not only th=
at, but do I really want to allow open access to a friend just to call one =
function? No, I don't.=20
>=20
If that=E2=80=99s all the friend does, then it=E2=80=99s not really very op=
en.
Anyway, there=E2=80=99s no need to befriend a class containing one function=
.. Just befriend the function.
namespace private_implementation {
template< typename HasDependency, typename DependencyType >
void SetDependency( HasDependency & Dependent, DependencyType * Dependency =
) {
Dependent.theDependency =3D Dependency;
}
}
class MyClass : public MyInterface
{
public:
//Constructor, destructor, MyInterface methods
private:
friend void private_implementation::SetDependency<>(MyClass &, aDepen=
dency*);
aDependency* theDependency;
};
Idiomatic C++ often assumes that users will not access inner namespaces wit=
h unfriendly-sounding names. Namespaces are never closed, so a really incom=
petent/malicious user could just add something to your main namespace just =
as they could explicitly name private_implementation. Access protection isn=
=E2=80=99t a security scheme, it=E2=80=99s a deterrent.
A proposal more in line with common practices would apply some restrictions=
to accessing namespace private_implementation. That could make this exampl=
e coincide with your request.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_711B4260-DFE7-4836-9A8C-02834B76C183
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9310, at 10:08 AM, Gina Stephens <<a href=3D"mailto:zumbagina29@g=
mail.com" class=3D"">zumbagina29@gmail.com</a>> wrote:</div><div class=
=3D""><p dir=3D"ltr" style=3D"font-family: Helvetica; font-size: 12px; font=
-style: normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; text-indent:=
0px; text-transform: none; white-space: normal; widows: auto; word-spacing=
: 0px; -webkit-text-stroke-width: 0px;" class=3D"">GMS- The problem is that=
MyClass has to know about every possible aDependency creator. What if I ha=
ve multiple? Should I really have to change MyClass to add another friend w=
hen a new one is defined? </p></div></blockquote><div>No, Germ=C3=A1n=E2=80=
=99s canonical solution does not have that problem. <font face=3D"Courier" =
class=3D"">MyClass</font> has only one friend, ever.</div><blockquote type=
=3D"cite" class=3D""><div class=3D""><p dir=3D"ltr" style=3D"font-family: H=
elvetica; font-size: 12px; font-style: normal; font-variant: normal; font-w=
eight: normal; letter-spacing: normal; line-height: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: nor=
mal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" clas=
s=3D"">By declaring a function as only accessible within a namespace, this =
conveys meaning and intent, just like the existing access modifiers. Friend=
does not. </p></div></blockquote><div>The base class, call it <font f=
ace=3D"Courier" class=3D"">DependencyInjector</font>, could require by <fon=
t face=3D"Courier" class=3D"">protected</font> access that any class must d=
eclare itself to =E2=80=9Cbe-a=E2=80=9D <font face=3D"Courier" class=3D"">D=
ependencyInjector</font> if it wants to call <font face=3D"Courier" class=
=3D"">SetDependency</font>. That is more expressive than allowing the call =
to be made anywhere.</div><div><div><blockquote type=3D"cite" class=3D""><p=
dir=3D"ltr" class=3D"">Usage of friend creates a coupling that I don't wan=
t or need. Not only that, but do I really want to allow open access to a fr=
iend just to call one function? No, I don't. </p></blockquote><div>If =
that=E2=80=99s all the friend does, then it=E2=80=99s not really very open.=
</div><div><br class=3D""></div><div>Anyway, there=E2=80=99s no need to bef=
riend a class containing one function. Just befriend the function.</div><di=
v><br class=3D""></div><div><font face=3D"Courier" class=3D"">namespace pri=
vate_implementation {</font></div><div><font face=3D"Courier" class=3D""><b=
r class=3D""></font></div><div><font face=3D"Courier" class=3D"">template&l=
t; typename HasDependency, typename DependencyType ></font></div><div><f=
ont face=3D"Courier" class=3D"">void SetDependency( HasDependency & Dep=
endent, DependencyType * Dependency ) {</font></div><div><font face=3D"Cour=
ier" class=3D""> Dependent.theDependency =3D Dependency;</font=
></div><div><font face=3D"Courier" class=3D"">}</font></div><div><font face=
=3D"Courier" class=3D""><br class=3D""></font></div><div><font face=3D"Cour=
ier" class=3D"">}</font></div><div><font face=3D"Courier" class=3D""><br cl=
ass=3D""></font></div><div><font face=3D"Courier" class=3D"">class MyClass =
: public MyInterface<br class=3D"">{<br class=3D""> public:<br =
class=3D""> //Constructor, destructor, MyInte=
rface methods<br class=3D""><br class=3D""> private:<br class=
=3D""> friend void </font><span style=3D"font-fami=
ly: Courier;" class=3D"">private_implementation</span><font face=3D"Courier=
" class=3D"">::SetDependency<>(MyClass &, aDependency*);<br class=
=3D""> aDependency* theDependency;<br class=3D"">};<br =
class=3D""><br class=3D""></font></div><div><font face=3D"Courier" class=3D=
""><br class=3D""></font></div><div>Idiomatic C++ often assumes that users =
will not access inner namespaces with unfriendly-sounding names. Namespaces=
are never closed, so a really incompetent/malicious user could just add so=
mething to your main namespace just as they could explicitly name <spa=
n style=3D"font-family: Courier;" class=3D"">private_implementation</span>.=
Access protection isn=E2=80=99t a security scheme, it=E2=80=99s a deterren=
t.</div><div><br class=3D""></div><div>A proposal more in line with common =
practices would apply some restrictions to accessing <span style=3D"fo=
nt-family: Courier;" class=3D"">namespace private_implementation</span>. Th=
at could make this example coincide with your request.</div><blockquote typ=
e=3D"cite" class=3D""></blockquote></div></div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_711B4260-DFE7-4836-9A8C-02834B76C183--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Wed, 10 Jun 2015 10:36:17 +0100
Raw View
--001a11c3c8425f12530518269baf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 10, 2015 at 4:05 AM, David Krauss <potswa@mac.com> wrote:
> Idiomatic C++ often assumes that users will not access inner namespaces
> with unfriendly-sounding names. Namespaces are never closed, so a really
> incompetent/malicious user could just add something to your main namespac=
e
> just as they could explicitly name private_implementation. Access
> protection isn=E2=80=99t a security scheme, it=E2=80=99s a deterrent.
>
>
.... and so that it is even clearer: there are legal ways that allow
accessing 'private' members of a type. Either you trust developers will
make idiomatic use of your libraries or you are fighting a loosing battle.
I would either use a free function (if there is only one thing that you
want to control) or a class wrapping a set of static functions (i.e. I
would avoid the 'protected' + inheritance from empty base approaches). Use
access specifiers to help you and others not make mistakes, not to deter
intended misuses.
David
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c3c8425f12530518269baf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Jun 10, 2015 at 4:05 AM, David Krauss <span dir=3D"ltr"><<a =
href=3D"mailto:potswa@mac.com" target=3D"_blank">potswa@mac.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-=
word"><div><div><div><div>Idiomatic C++ often assumes that users will not a=
ccess inner namespaces with unfriendly-sounding names. Namespaces are never=
closed, so a really incompetent/malicious user could just add something to=
your main namespace just as they could explicitly name=C2=A0<span style=3D=
"font-family:Courier">private_implementation</span>. Access protection isn=
=E2=80=99t a security scheme, it=E2=80=99s a deterrent.</div><div><br></div=
></div></div></div></div></blockquote><div><br>... and so that it is even c=
learer: there are legal ways that allow accessing 'private' members=
of a type. Either you trust developers will make idiomatic use of your lib=
raries or you are fighting a loosing battle. <br><br>I would either use a f=
ree function (if there is only one thing that you want to control) or a cla=
ss wrapping a set of static functions (i.e. I would avoid the 'protecte=
d' + inheritance from empty base approaches). Use access specifiers to =
help you and others not make mistakes, not to deter intended misuses.<br><b=
r>=C2=A0 =C2=A0 David</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 <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 />
--001a11c3c8425f12530518269baf--
.
Author: Max Truxa <me@maxtruxa.com>
Date: Wed, 10 Jun 2015 03:36:02 -0700 (PDT)
Raw View
------=_Part_240_1438104893.1433932562570
Content-Type: multipart/alternative;
boundary="----=_Part_241_300489666.1433932562570"
------=_Part_241_300489666.1433932562570
Content-Type: text/plain; charset=UTF-8
On Tuesday, June 9, 2015 at 10:29:25 PM UTC+2, Gina Stephens wrote:
>
> To Max's point - Right, very similar to the "internal" access modifier in
> C# or the default access modifier in JAVA. The difference is that this
> would be accessibile within the same namespace, which should be achievable
> in C++. I do not know of a reason why this feature would not be possible
> in C++. Do you?
>
You are right, that would be possible. I got sidetracked by the references
to Java/.NET where existing "package internal" access modifiers enforce the
access (restriction) on the package level. What I pointed out is that a
similar feature is currently not possible in C++.
On the other hand, specifying access on the namespace level would be
possible but not very useful IMO because as others have demonstrated
already there are existing idioms that can do exactly that. Adding this new
access modifier to the language would just save around 3 lines (friend
declaration + "detail" namespace).
--
---
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_241_300489666.1433932562570
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, June 9, 2015 at 10:29:25 PM UTC+2, Gina Stephe=
ns 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=
>To Max's point - Right, very similar to the "internal" access modifier in =
C# or the default access modifier in JAVA. The difference is that thi=
s would be accessibile within the same namespace, which should be achievabl=
e in C++. I do not know of a reason why this feature would not be pos=
sible in C++. Do you?</div></div></blockquote><div><br></div><div>You=
are right, that would be possible. I got sidetracked by the references to =
Java/.NET where existing "package internal" access modifiers enforce the ac=
cess (restriction) on the package level. What I pointed out is that a simil=
ar feature is currently not possible in C++.</div><div>On the other hand, s=
pecifying access on the namespace level would be possible but not very usef=
ul IMO because as others have demonstrated already there are existing idiom=
s that can do exactly that. Adding this new access modifier to the language=
would just save around 3 lines (friend declaration + "detail" namespace).<=
/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_241_300489666.1433932562570--
------=_Part_240_1438104893.1433932562570--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 10 Jun 2015 14:06:03 -0400
Raw View
On 2015-06-09 16:57, Nevin Liber wrote:
> I don't see how "namespace" helps.
>=20
> Except for namespace std, anyone can reopen a namespace and add things to
> it.
>=20
> How is that substantially different than adding a friend?
There's quite a large difference. "friend" says "I trust this particular
class and will allow it to access ALL of my members, even private ones.
The suggested feature adds an access level between public (EWISOTT=C2=B9) a=
nd
protected (only derived classes) which, like existing access specifiers,
applies only to certain members. It's not *exactly* between, since
"stuff in the same namespace" is not a superset of "derived classes" (a
class in namespace A can inherit from something in namespace B), but it
is generally more broad than "protected" and certainly less broad than
"public".
(=C2=B9 http://tvtropes.org/pmwiki/pmwiki.php/Main/ExactlyWhatItSaysOnTheTi=
n)
On 2015-06-09 22:36, Nevin Liber wrote:
> Show us how this mechanism can ever stop anyone from legally calling=20
> MyClass::SetDependency if one has an instance of MyClass. I just
> don't see it.
There are various ways in which I can call a private member if I really
want to. That doesn't mean that access protection is useless. The point
of Gina's idea is that it serves to inform the user as to the proper use
of the class.
Mind, I'm also not convinced that the feature has sufficient value, I
just don't buy your objections :-).
--=20
Matthew
--=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: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 10 Jun 2015 16:29:18 -0400
Raw View
On 2015-06-10 14:21, Nevin Liber wrote:
> On 10 June 2015 at 13:06, Matthew Woehlke wrote:
>> It's not *exactly* between, since
>> "stuff in the same namespace" is not a superset of "derived classes" (a
>> class in namespace A can inherit from something in namespace B), but it
>> is generally more broad than "protected" and certainly less broad than
>> "public".
>
> If it is less broad than public, please show an example with this feature
> where one is restricted from calling, directly or indirectly,
> MyClass::SetDependency().
Really?
namespace A {
class Foo {
internal: void poke();
};
}
namespace B {
class Bar {
public: void prod();
}
}
void A::Foo::poke() {
poke(); // stack overflow (due to lazy example), but legal
}
void B::Bar::prod() {
A::Foo foo;
foo.poke(); // error: poke is internal
}
int main() {
A::Foo foo;
foo.poke(); // error: poke is internal
}
>> There are various ways in which I can call a private member if I really
>> want to.
>
> That are legal according to the C++ standard? I know there is an
> encapsulation hole with templated member functions, but how else can you do
> it?
I'm not sure how you define "legal". There is of course '#define private
public'. You can redefine the class, adding your own custom member (or
additional friends). There are probably other ways...
--
Matthew
--
---
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: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 10 Jun 2015 17:48:35 -0400
Raw View
On 2015-06-10 16:50, Nevin Liber wrote:
> On 10 June 2015 at 15:29, Matthew Woehlke wrote:
>> On 2015-06-10 14:21, Nevin Liber wrote:
>>> On 10 June 2015 at 13:06, Matthew Woehlke wrote:
>>>> It's not *exactly* between, since
>>>> "stuff in the same namespace" is not a superset of "derived classes" (a
>>>> class in namespace A can inherit from something in namespace B), but it
>>>> is generally more broad than "protected" and certainly less broad than
>>>> "public".
>>>
>>> If it is less broad than public, please show an example with this feature
>>> where one is restricted from calling, directly or indirectly,
>>> MyClass::SetDependency().
>>
>> [snip example]
>
> And then I just write the trivial:
>
> [snip example bypassing access protection]
>
> You've prevented *nothing*.
I've prevented you accessing it without consciously circumventing an
access protection. That's... about equally secure as protected.
> I just have to jump through one hoop, which can be just as easily
> implemented with a friend.
Well, yes. Again, I didn't say I find the feature *sufficiently* useful
(i.e. to be worth adding). I just disagree that it isn't *at all* useful.
--
Matthew
--
---
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: David Krauss <potswa@mac.com>
Date: Fri, 12 Jun 2015 07:08:49 +0800
Raw View
--Apple-Mail=_0D1EFE9A-7566-4B24-B93C-8CE019F80B0B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9306=E2=80=9312, at 6:46 AM, Richard Smith <richard@metafoo=
..co.uk> wrote:
>=20
> That's a popular bug (present in Clang and GCC, but not EDG or MSVC), not=
a hole in the access rules.
There is a hole in the access rules, anyway: name the private member in a r=
eference expression in a non-type argument in an explicit instantiation dec=
laration, [temp.explicit]/12.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_0D1EFE9A-7566-4B24-B93C-8CE019F80B0B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9306=
=E2=80=9312, at 6:46 AM, Richard Smith <<a href=3D"mailto:richard@metafo=
o.co.uk" class=3D"">richard@metafoo.co.uk</a>> wrote:</div><br class=3D"=
Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" style=3D"font-f=
amily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal=
; font-weight: normal; letter-spacing: normal; line-height: normal; orphans=
: auto; text-align: start; text-indent: 0px; text-transform: none; white-sp=
ace: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0p=
x;" class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote">That's=
a popular bug (present in Clang and GCC, but not EDG or MSVC), not a hole =
in the access rules.</div></div></div></div></blockquote><br class=3D""></d=
iv><div>There is a hole in the access rules, anyway: name the private membe=
r in a reference expression in a non-type argument in an explicit instantia=
tion declaration, [temp.explicit]/12.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_0D1EFE9A-7566-4B24-B93C-8CE019F80B0B--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Fri, 12 Jun 2015 09:18:20 +0100
Raw View
--047d7beb90863a95ce05184dc0c9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Some thoughts:
- The language is not there to police you, just to help. Legal (template
instantiation trick) or not (clone the class definition, add a friend
function or an static accessor...) there are ways to circumvent it. The
access specifiers are there as documentation that can be checked by the
compiler, not as a security measure.
- C# and Java have package level access. Well, they have packages to start
with, which C++ doesn't. They don't have 'friend' through. The 'friend'
mechanism is a scalpel where package level is a butchers' knife. Both are
sharp, one is precise.
On the original problem, if you want all implementations of an interface
(base class) to be able to call this particular function, the simple
solution that does not involve waiting a few years and fighting many people
would be to befriend the interface and extend it to provide access to the
derived types:
class Interface;
class Private {
void register(Interface &);
friend class Interface;
};
class Interface {
public:
// public interface goes here
protected:
void registerIn(Private& p) {
p.register(*this);
}
};
You can play around with making that a 'static' function meddling with the
signature and what not, but I honestly see this over an improvement over
the suggestion of allowing everyone in the same namespace to call the
function. If you want finer control, you can provide an intermediate type
that separates the rest of 'Private' so that 'Interface' cannot access the
internals, but I believe that is missing an important point: 'Private' and
'Interface' are *coupled* by definition as they are parts of the same
solution. You are not befriending any random type, you are in control of
both types and both types are part of your design. The fact that the code
is laid out in two classes is a detail.
David
On Fri, Jun 12, 2015 at 12:08 AM, David Krauss <potswa@mac.com> wrote:
>
> On 2015=E2=80=9306=E2=80=9312, at 6:46 AM, Richard Smith <richard@metafoo=
..co.uk> wrote:
>
> That's a popular bug (present in Clang and GCC, but not EDG or MSVC), not
> a hole in the access rules.
>
>
> There is a hole in the access rules, anyway: name the private member in a
> reference expression in a non-type argument in an explicit instantiation
> declaration, [temp.explicit]/12.
>
> --
>
> ---
> 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/.
--047d7beb90863a95ce05184dc0c9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Some thoughts:<br><br>- The language is not there to polic=
e you, just to help. Legal (template instantiation trick) or not (clone the=
class definition, add a friend function or an static accessor...) there ar=
e ways to circumvent it. The access specifiers are there as documentation t=
hat can be checked by the compiler, not as a security measure.<br><br>- C# =
and Java have package level access. Well, they have packages to start with,=
which C++ doesn't. They don't have 'friend' through.=C2=A0=
The 'friend' mechanism is a scalpel where package level is a butch=
ers' knife. Both are sharp, one is precise.<br><br>On the original prob=
lem, if you want all implementations of an interface (base class) to be abl=
e to call this particular function, the simple solution that does not invol=
ve waiting a few years and fighting many people would be to befriend the in=
terface and extend it to provide access to the derived types:<br><br>class =
Interface;<br>class Private {<br>=C2=A0 =C2=A0 void register(Interface &=
;);<br>=C2=A0 =C2=A0 friend class Interface;<br>};<br>class Interface {<br>=
=C2=A0 public:<div>=C2=A0 =C2=A0 // public interface goes here<br>=C2=A0 pr=
otected:</div><div>=C2=A0 =C2=A0 void registerIn(Private& p) {<br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0p.register(*this);<br>=C2=A0 =C2=A0 }<br>};<br><br>=
You can play around with making that a 'static' function meddling w=
ith the signature and what not, but I honestly see this over an improvement=
over the suggestion of allowing everyone in the same namespace to call the=
function.=C2=A0 If you want finer control, you can provide an intermediate=
type that separates the rest of 'Private' so that 'Interface&#=
39; cannot access the internals, but I believe that is missing an important=
point: 'Private' and 'Interface' are *coupled* by definiti=
on as they are parts of the same solution. You are not befriending any rand=
om type, you are in control of both types and both types are part of your d=
esign. The fact that the code is laid out in two classes is a detail.<br><b=
r>=C2=A0 =C2=A0 =C2=A0David</div></div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Fri, Jun 12, 2015 at 12:08 AM, David Krauss <span =
dir=3D"ltr"><<a href=3D"mailto:potswa@mac.com" target=3D"_blank">potswa@=
mac.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=
=3D"word-wrap:break-word"><span class=3D""><br><div><blockquote type=3D"cit=
e"><div>On 2015=E2=80=9306=E2=80=9312, at 6:46 AM, Richard Smith <<a hre=
f=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk<=
/a>> wrote:</div><br><div><div dir=3D"ltr" style=3D"font-family:Helvetic=
a;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;l=
etter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;te=
xt-transform:none;white-space:normal;word-spacing:0px"><div class=3D"gmail_=
extra"><div class=3D"gmail_quote">That's a popular bug (present in Clan=
g and GCC, but not EDG or MSVC), not a hole in the access rules.</div></div=
></div></div></blockquote><br></div></span><div>There is a hole in the acce=
ss rules, anyway: name the private member in a reference expression in a no=
n-type argument in an explicit instantiation declaration, [temp.explicit]/1=
2.</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<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 />
--047d7beb90863a95ce05184dc0c9--
.
Author: Max Truxa <me@maxtruxa.com>
Date: Fri, 12 Jun 2015 09:33:39 -0700 (PDT)
Raw View
------=_Part_402_1796897114.1434126819868
Content-Type: multipart/alternative;
boundary="----=_Part_403_387267237.1434126819868"
------=_Part_403_387267237.1434126819868
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, June 12, 2015 at 10:18:23 AM UTC+2, David Rodr=C3=ADguez Ibeas w=
rote:
>
> The 'friend' mechanism is a scalpel where package level is a butchers'=20
> knife. Both are sharp, one is precise.
>
I think this comparison is somewhat unfair since "internal" and "friend"=20
try to solve quite different problems. In C++ hiding of internal detail can=
=20
be accomplished by putting it directly in source files or "private" headers=
=20
(headers that are not shipped/required by client code). Since Java and=20
C# do not follow a header-based build model like C++ they need some other=
=20
way to mark "helpers" as internal.
Just for completeness sake: In case said detail can't be hidden because=20
public headers depend on it (e.g. because the detail is a type that is used=
=20
by a class definition) using a "detail" namespaces works well for C++.
--
Max
--=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_403_387267237.1434126819868
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 12, 2015 at 10:18:23 AM UTC+2, David Rodr=
=C3=ADguez Ibeas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">The 'friend' mechanism is a scalpel where package level is a butc=
hers' knife. Both are sharp, one is precise.<br></div></blockquote><div><br=
></div><div>I think this comparison is somewhat unfair since "internal" and=
"friend" try to solve quite different problems. In C++ hiding of internal =
detail can be accomplished by putting it directly in source files or "priva=
te" headers (headers that are not shipped/required by client code). Since J=
ava and C# do not follow a header-based build model like C++ they need=
some other way to mark "helpers" as internal.</div><div>Just for completen=
ess sake: In case said detail can't be hidden because public headers depend=
on it (e.g. because the detail is a type that is used by a class definitio=
n) using a "detail" namespaces works well for C++.</div><div><br></div><div=
>--</div><div>Max</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_403_387267237.1434126819868--
------=_Part_402_1796897114.1434126819868--
.