Topic: Proposed new Class Access Modifier "restricted


Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Fri, 9 May 2014 20:14:56 +0200
Raw View
2014-05-09 20:03 GMT+02:00  <lwb.ztexas@gmail.com>:
>
> I Propose a new Class Access Modifier "restricted" to be used like public,
> protected, private, etc.
>
> Sometimes it would be nice to have a 4th Class Access Modifier, I'll call it
> "restricted", which would be  similar to "private", but which would provide
> restricted access to members, methods, etc.,
> ONLY within the File where the Class was defined (generally the .h file).

The standard does not require that source code is stored in files, the
notion of /source file/ in C++ does only exist conceptually, so in
which sense do you suggest to define the "file"?

- Daniel

--

---
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: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 9 May 2014 20:15:46 +0200
Raw View
--001a11347bf229522d04f8fb9646
Content-Type: text/plain; charset=UTF-8

Hi Lance,

Thanks for your proposal.

Is the following well-formed under your proposal:

file a:

    class X
    {
    restricted: int x;

file b:

    include "a"

    int f() { return x; }

    };

Regards,
Andrew.





On Fri, May 9, 2014 at 8:03 PM, <lwb.ztexas@gmail.com> wrote:

>
> I Propose a new Class Access Modifier "*restricted*" to be used like
> public, protected, private, etc.
>
> Sometimes it would be nice to have a 4th Class Access Modifier, I'll call
> it "*restricted*", which would be  similar to "*private*", but which
> would provide restricted access to members, methods, etc.,
> *ONLY *within the *File *where the *Class *was defined (generally the *.h*file).  The reasoning behind this would be to make the Compiler to provide
> an additional restriction for access by *NOT *allowing
> the member/method to be access in the corresponding *.cpp* file.  This
> would effectively *force *(or remind) the programmer to access the
> (generally) member variable through defined methods and
> *not allow access directly*.
>
> It is not uncommon to have a member variable which you would prefer were
> accessed *only *through some sort of function or method, hidden from the
> overall class code.  For example (in *.h* file):
>
> class fooClass
> {
>     ...
>
>     protected:
>
>         inline void setFooVar(int val) { fooVar = val; }
>         inline int getFooVar(void) { return fooVar; }
>
>     private:
>
>         int fooVar;
> }
>
> In the above code, the methods *setFooVar *and *getFooVar *are used to
> manipulate the private variable *fooVar*.  The programmer desires that
> all access to *fooVar *be
> *restricted to these two functions onl*y.  However, there is nothing to
> prevent a subsequent programmer to accessing *fooVar *directly in a
> corresponding *.cpp* file method, *e.g. fooVar = 10;* .
>
> In my proposal, you would write the class code this way (*note the
> restricted Access Modifier in the .h file*):
>
> class fooClass
> {
>     ...
>
>     protected:
>
>         inline void setFooVar(int val) { fooVar = val; }
>         inline int getFooVar(void) { return fooVar; }
>
>     restricted:
>
>         int fooVar;
> }
>
> With this new *restricted *Access Modifier, the programmer can now insure
> that any subsequent access of the *fooVar *member variable will *NOT *be
> allowed within the code in the .*cpp *file,
> therefore insuring that *all access* there (in the* .cpp* file) *MUST *be
> achieved by using the methods *setFooVar *and *getFooVar*.  Of course the
> use of *restricted *would be optional,
> *in thesame way which the use of const is generally optional, but forces a
> more specific restriction on what types of data may be, for example, passed
> as a parameter to a function*.
>
> Currently, this sort of data hiding *can *be accomplished via the use of
> a somewhat messy *parent class*, where the purpose of the *parent class*is *ONLY
> *to hide data and force access
> through specific member functions.  For example:
>
> class hideFooClass
> {
>     ...
>
>     protected:
>
>         inline void setFooVar(int val) { fooVar = val; }
>         inline int getFooVar(void) { return fooVar; }
>
>     private:
>
>         int fooVar;
> }
>
> class fooClass : public hideFooClass
> {
>     // No access to *fooVar *here...
> }
>
> In the above example, I may use the methods *setFooVar *and *getFooVar*as I please, but I *do
> not* have access to *fooVar*. The private member variable *fooVar *is *hidden
> *from *fooClass*.
> However, by using what I propose here, I believe would be much cleaner
> than having to *obfuscate *the code with the addition of an additional
> class meant *only to hide access* to *fooVar*.
> In my opinion, the use of an additional Access Modifier *restricted*,
> would be a much more elegant solution to this somewhat common problem.
>
> I welcome any thoughts or ideas you may have relating to this...
>
> Thank you,
>
> *Lance Bledsoe*
>
> *Austin, TexasMay 2014*
>
>
>
>
>
>
>
>  --
>
> ---
> 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/.

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

<div dir=3D"ltr">Hi Lance,<div><br></div><div>Thanks for your proposal.</di=
v><div><br></div><div>Is the following well-formed under your proposal:</di=
v><div><br></div><div>file a:</div><div><br></div><div>=C2=A0 =C2=A0 class =
X</div><div>
=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 restricted: int x;</div><div><br></=
div><div>file b:</div><div><br></div><div>=C2=A0 =C2=A0 include &quot;a&quo=
t;</div><div><br></div><div>=C2=A0 =C2=A0 int f() { return x; }</div><div><=
br></div><div>=C2=A0 =C2=A0 };</div><div><br></div>
<div>Regards,</div><div>Andrew.</div><div><br></div><div><br></div><div><br=
></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">=
On Fri, May 9, 2014 at 8:03 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:lw=
b.ztexas@gmail.com" target=3D"_blank">lwb.ztexas@gmail.com</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>I Propose a new Class A=
ccess Modifier &quot;<b><i>restricted</i></b>&quot; to be used like public,=
 protected, private, etc.<br>
<br>Sometimes it would be nice to have a 4th Class Access Modifier, I&#39;l=
l call it &quot;<b>restricted</b>&quot;, which would be=C2=A0 similar to &q=
uot;<b>private</b>&quot;, but which would provide restricted access to memb=
ers, methods, etc., <br>
<b>ONLY </b>within the <b>File </b>where the <b>Class </b>was defined (gene=
rally the <b>.h</b> file).=C2=A0 The reasoning behind this would be to make=
 the Compiler to provide an additional restriction for access by <b>NOT </b=
>allowing<br>
the member/method to be access in the corresponding <b>.cpp</b> file.=C2=A0=
 This would effectively <b>force </b>(or remind) the programmer to access t=
he (generally) member variable through defined methods and<br><b>not allow =
access directly</b>.<br>
<br>It is not uncommon to have a member variable which you would prefer wer=
e accessed <b>only </b>through some sort of function or method, hidden from=
 the overall class code.=C2=A0 For example (in <b>.h</b> file):<br><br><div=
 style=3D"margin-left:40px">
class fooClass<br>{<br>=C2=A0=C2=A0=C2=A0 ...<br><br>=C2=A0=C2=A0=C2=A0 pro=
tected:<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inline void setFo=
oVar(int val) { fooVar =3D val; }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 inline int getFooVar(void) { return fooVar; }<br><br>=C2=A0=C2=A0=C2=
=A0 private:<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int fooVar;<=
br>
}<br></div><br>In the above code, the methods <b>setFooVar </b>and <b>getFo=
oVar </b>are used to manipulate the private variable <b>fooVar</b>.=C2=A0 T=
he programmer desires that all access to <b>fooVar </b>be <b>restricted to =
<br>
these two functions onl</b>y.=C2=A0 However, there is nothing to prevent a =
subsequent programmer to accessing <b>fooVar </b>directly in a correspondin=
g <b>.cpp</b> file method, <b><i>e.g. fooVar =3D 10;</i></b> .<br><br>In my=
 proposal, you would write the class code this way (<i>note the <b>restrict=
ed </b>Access Modifier in the<b> .h</b> file</i>):<br>
<br><div style=3D"margin-left:40px">class fooClass<br>{<br>=C2=A0=C2=A0=C2=
=A0 ...<br><br>=C2=A0=C2=A0=C2=A0 protected:<br><br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 inline void setFooVar(int val) { fooVar =3D val; }<br=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inline int getFooVar(void) { re=
turn fooVar; }<br><br>=C2=A0=C2=A0=C2=A0 restricted:<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int fooVar;<br>}<br><br></di=
v>With this new <b>restricted </b>Access Modifier, the programmer can now i=
nsure that any subsequent access of the <b>fooVar </b>member variable will =
<b>NOT </b>be allowed within the code in the .<b>cpp </b>file,<br>
therefore insuring that <b>all access</b> there (in the<b> .cpp</b> file) <=
b>MUST </b>be achieved by using the methods  <b>setFooVar </b>and <b>getFoo=
Var</b>.=C2=A0 Of course the use of <i><b>restricted </b></i>would be optio=
nal, <i>in the<br>
same way which the use of <b>const </b>is generally optional, but forces a =
more specific restriction on what types of data may be, for example, passed=
 as a parameter to a function</i>.<br><br>Currently, this sort of data hidi=
ng <u><b>can </b></u>be accomplished via the use of a somewhat messy <i><b>=
parent class</b></i>, where the purpose of the <i><b>parent class</b></i> i=
s <b>ONLY </b>to hide data and force access<br>
through specific member functions.=C2=A0 For example:<br><br><div style=3D"=
margin-left:40px">class hideFooClass<br>{<br>=C2=A0=C2=A0=C2=A0 ...<br><br>=
=C2=A0=C2=A0=C2=A0 protected:<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 inline void setFooVar(int val) { fooVar =3D val; }<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inline int getFooVar(void) { return fooVar; =
}<br>
<br>=C2=A0=C2=A0=C2=A0 private:<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 int fooVar;<br>}<br></div><br><div style=3D"margin-left:40px">class =
fooClass : public hideFooClass<br>{<br>=C2=A0=C2=A0=C2=A0 // No access to <=
b>fooVar </b>here...<br>}<br><br></div>In the above example, I may use the =
methods  <b>setFooVar </b>and <b>getFooVar</b> as I please, but I <u><b>do =
not</b></u> have access to <b>fooVar</b>. The private member variable <b>fo=
oVar </b>is <i><b>hidden </b></i>from <b>fooClass</b>.<br>
However, by using what I propose here, I believe would be much cleaner than=
 having to <i>obfuscate </i>the code with the addition of an additional cla=
ss meant <i><b>only to hide access</b></i> to <b>fooVar</b>.=C2=A0 <br>In m=
y opinion, the use of an additional Access Modifier <i><b>restricted</b></i=
>, would be a much more elegant solution to this somewhat common problem.<b=
r>
<br>I welcome any thoughts or ideas you may have relating to this...<br><br=
>Thank you,<br><br><b>Lance Bledsoe</b><br><i>Austin, Texas<br>May 2014</i>=
<span class=3D"HOEnZb"><font color=3D"#888888"><br><br><br><br><br><br><br>
<br></font></span></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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11347bf229522d04f8fb9646--

.


Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 9 May 2014 20:19:12 +0200
Raw View
--089e0122aaee6aa4fe04f8fba2d1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, May 9, 2014 at 8:14 PM, Daniel Kr=C3=BCgler <daniel.kruegler@gmail.=
com>wrote:

> 2014-05-09 20:03 GMT+02:00  <lwb.ztexas@gmail.com>:
> >
> > I Propose a new Class Access Modifier "restricted" to be used like
> public,
> > protected, private, etc.
> >
> > Sometimes it would be nice to have a 4th Class Access Modifier, I'll
> call it
> > "restricted", which would be  similar to "private", but which would
> provide
> > restricted access to members, methods, etc.,
> > ONLY within the File where the Class was defined (generally the .h file=
).
>
> The standard does not require that source code is stored in files, the
> notion of /source file/ in C++ does only exist conceptually, so in
> which sense do you suggest to define the "file"?


While I am pretty sure I'm against the proposal, your statement is
incorrect:

[lex.separate]/1:

    The text of the program is kept in units called *source =EF=AC=81les* i=
n this
International Standard

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 9, 2014 at 8:14 PM, Daniel Kr=C3=BCgler <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler@g=
mail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">2014-05-09 20:03 GMT+02:00 =C2=A0&lt;<a href=3D"mailto:lwb=
..ztexas@gmail.com">lwb.ztexas@gmail.com</a>&gt;:<br>

<div class=3D"">&gt;<br>
&gt; I Propose a new Class Access Modifier &quot;restricted&quot; to be use=
d like public,<br>
&gt; protected, private, etc.<br>
&gt;<br>
&gt; Sometimes it would be nice to have a 4th Class Access Modifier, I&#39;=
ll call it<br>
&gt; &quot;restricted&quot;, which would be =C2=A0similar to &quot;private&=
quot;, but which would provide<br>
&gt; restricted access to members, methods, etc.,<br>
&gt; ONLY within the File where the Class was defined (generally the .h fil=
e).<br>
<br>
</div>The standard does not require that source code is stored in files, th=
e<br>
notion of /source file/ in C++ does only exist conceptually, so in<br>
which sense do you suggest to define the &quot;file&quot;?</blockquote></di=
v><br></div><div class=3D"gmail_extra">While I am pretty sure I&#39;m again=
st the proposal, your statement is incorrect:</div><div class=3D"gmail_extr=
a">
<br></div><div class=3D"gmail_extra">[lex.separate]/1:</div><div class=3D"g=
mail_extra"><br></div><div class=3D"gmail_extra">=C2=A0 =C2=A0 The text of =
the program is kept in units called <i>source =EF=AC=81les</i> in this Inte=
rnational Standard<br>
</div><div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0122aaee6aa4fe04f8fba2d1--

.


Author: Brian Bi <bbi5291@gmail.com>
Date: Fri, 9 May 2014 14:21:52 -0400
Raw View
--001a11349920fa93df04f8fbab8b
Content-Type: text/plain; charset=UTF-8

Could you suggest how this could be useful? It sounds like you're saying
the implementation of a class (in the .cpp file) should be forced to use
the class's public interface (in the .h file) but that doesn't seem like
good object-oriented design to me.

--
*Brian Bi*


On Fri, May 9, 2014 at 2:03 PM, <lwb.ztexas@gmail.com> wrote:

>
> I Propose a new Class Access Modifier "*restricted*" to be used like
> public, protected, private, etc.
>
> Sometimes it would be nice to have a 4th Class Access Modifier, I'll call
> it "*restricted*", which would be  similar to "*private*", but which
> would provide restricted access to members, methods, etc.,
> *ONLY *within the *File *where the *Class *was defined (generally the *.h*file).  The reasoning behind this would be to make the Compiler to provide
> an additional restriction for access by *NOT *allowing
> the member/method to be access in the corresponding *.cpp* file.  This
> would effectively *force *(or remind) the programmer to access the
> (generally) member variable through defined methods and
> *not allow access directly*.
>
> It is not uncommon to have a member variable which you would prefer were
> accessed *only *through some sort of function or method, hidden from the
> overall class code.  For example (in *.h* file):
>
> class fooClass
> {
>     ...
>
>     protected:
>
>         inline void setFooVar(int val) { fooVar = val; }
>         inline int getFooVar(void) { return fooVar; }
>
>     private:
>
>         int fooVar;
> }
>
> In the above code, the methods *setFooVar *and *getFooVar *are used to
> manipulate the private variable *fooVar*.  The programmer desires that
> all access to *fooVar *be
> *restricted to these two functions onl*y.  However, there is nothing to
> prevent a subsequent programmer to accessing *fooVar *directly in a
> corresponding *.cpp* file method, *e.g. fooVar = 10;* .
>
> In my proposal, you would write the class code this way (*note the
> restricted Access Modifier in the .h file*):
>
> class fooClass
> {
>     ...
>
>     protected:
>
>         inline void setFooVar(int val) { fooVar = val; }
>         inline int getFooVar(void) { return fooVar; }
>
>     restricted:
>
>         int fooVar;
> }
>
> With this new *restricted *Access Modifier, the programmer can now insure
> that any subsequent access of the *fooVar *member variable will *NOT *be
> allowed within the code in the .*cpp *file,
> therefore insuring that *all access* there (in the* .cpp* file) *MUST *be
> achieved by using the methods *setFooVar *and *getFooVar*.  Of course the
> use of *restricted *would be optional,
> *in thesame way which the use of const is generally optional, but forces a
> more specific restriction on what types of data may be, for example, passed
> as a parameter to a function*.
>
> Currently, this sort of data hiding *can *be accomplished via the use of
> a somewhat messy *parent class*, where the purpose of the *parent class*is *ONLY
> *to hide data and force access
> through specific member functions.  For example:
>
> class hideFooClass
> {
>     ...
>
>     protected:
>
>         inline void setFooVar(int val) { fooVar = val; }
>         inline int getFooVar(void) { return fooVar; }
>
>     private:
>
>         int fooVar;
> }
>
> class fooClass : public hideFooClass
> {
>     // No access to *fooVar *here...
> }
>
> In the above example, I may use the methods *setFooVar *and *getFooVar*as I please, but I *do
> not* have access to *fooVar*. The private member variable *fooVar *is *hidden
> *from *fooClass*.
> However, by using what I propose here, I believe would be much cleaner
> than having to *obfuscate *the code with the addition of an additional
> class meant *only to hide access* to *fooVar*.
> In my opinion, the use of an additional Access Modifier *restricted*,
> would be a much more elegant solution to this somewhat common problem.
>
> I welcome any thoughts or ideas you may have relating to this...
>
> Thank you,
>
> *Lance Bledsoe*
>
> *Austin, TexasMay 2014*
>
>
>
>
>
>
>
>  --
>
> ---
> 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/.

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

<div dir=3D"ltr">Could you suggest how this could be useful? It sounds like=
 you&#39;re saying the implementation of a class (in the .cpp file) should =
be forced to use the class&#39;s public interface (in the .h file) but that=
 doesn&#39;t seem like good object-oriented design to me.<br>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><f=
ont color=3D"#c0c0c0"><span style=3D"color:rgb(0,0,0)">--</span><i><br>Bria=
n Bi</i></font><br><div></div><div></div><div></div></div></div>
<br><br><div class=3D"gmail_quote">On Fri, May 9, 2014 at 2:03 PM,  <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:lwb.ztexas@gmail.com" target=3D"_blank">lw=
b.ztexas@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br>I Propose a new Class Access Modifier &quot;<b><i>rest=
ricted</i></b>&quot; to be used like public, protected, private, etc.<br><b=
r>Sometimes it would be nice to have a 4th Class Access Modifier, I&#39;ll =
call it &quot;<b>restricted</b>&quot;, which would be=C2=A0 similar to &quo=
t;<b>private</b>&quot;, but which would provide restricted access to member=
s, methods, etc., <br>
<b>ONLY </b>within the <b>File </b>where the <b>Class </b>was defined (gene=
rally the <b>.h</b> file).=C2=A0 The reasoning behind this would be to make=
 the Compiler to provide an additional restriction for access by <b>NOT </b=
>allowing<br>
the member/method to be access in the corresponding <b>.cpp</b> file.=C2=A0=
 This would effectively <b>force </b>(or remind) the programmer to access t=
he (generally) member variable through defined methods and<br><b>not allow =
access directly</b>.<br>
<br>It is not uncommon to have a member variable which you would prefer wer=
e accessed <b>only </b>through some sort of function or method, hidden from=
 the overall class code.=C2=A0 For example (in <b>.h</b> file):<br><br><div=
 style=3D"margin-left:40px">
class fooClass<br>{<br>=C2=A0=C2=A0=C2=A0 ...<br><br>=C2=A0=C2=A0=C2=A0 pro=
tected:<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inline void setFo=
oVar(int val) { fooVar =3D val; }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 inline int getFooVar(void) { return fooVar; }<br><br>=C2=A0=C2=A0=C2=
=A0 private:<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int fooVar;<=
br>
}<br></div><br>In the above code, the methods <b>setFooVar </b>and <b>getFo=
oVar </b>are used to manipulate the private variable <b>fooVar</b>.=C2=A0 T=
he programmer desires that all access to <b>fooVar </b>be <b>restricted to =
<br>
these two functions onl</b>y.=C2=A0 However, there is nothing to prevent a =
subsequent programmer to accessing <b>fooVar </b>directly in a correspondin=
g <b>.cpp</b> file method, <b><i>e.g. fooVar =3D 10;</i></b> .<br><br>In my=
 proposal, you would write the class code this way (<i>note the <b>restrict=
ed </b>Access Modifier in the<b> .h</b> file</i>):<br>
<br><div style=3D"margin-left:40px">class fooClass<br>{<br>=C2=A0=C2=A0=C2=
=A0 ...<br><br>=C2=A0=C2=A0=C2=A0 protected:<br><br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 inline void setFooVar(int val) { fooVar =3D val; }<br=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inline int getFooVar(void) { re=
turn fooVar; }<br><br>=C2=A0=C2=A0=C2=A0 restricted:<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int fooVar;<br>}<br><br></di=
v>With this new <b>restricted </b>Access Modifier, the programmer can now i=
nsure that any subsequent access of the <b>fooVar </b>member variable will =
<b>NOT </b>be allowed within the code in the .<b>cpp </b>file,<br>
therefore insuring that <b>all access</b> there (in the<b> .cpp</b> file) <=
b>MUST </b>be achieved by using the methods  <b>setFooVar </b>and <b>getFoo=
Var</b>.=C2=A0 Of course the use of <i><b>restricted </b></i>would be optio=
nal, <i>in the<br>
same way which the use of <b>const </b>is generally optional, but forces a =
more specific restriction on what types of data may be, for example, passed=
 as a parameter to a function</i>.<br><br>Currently, this sort of data hidi=
ng <u><b>can </b></u>be accomplished via the use of a somewhat messy <i><b>=
parent class</b></i>, where the purpose of the <i><b>parent class</b></i> i=
s <b>ONLY </b>to hide data and force access<br>
through specific member functions.=C2=A0 For example:<br><br><div style=3D"=
margin-left:40px">class hideFooClass<br>{<br>=C2=A0=C2=A0=C2=A0 ...<br><br>=
=C2=A0=C2=A0=C2=A0 protected:<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 inline void setFooVar(int val) { fooVar =3D val; }<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inline int getFooVar(void) { return fooVar; =
}<br>
<br>=C2=A0=C2=A0=C2=A0 private:<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 int fooVar;<br>}<br></div><br><div style=3D"margin-left:40px">class =
fooClass : public hideFooClass<br>{<br>=C2=A0=C2=A0=C2=A0 // No access to <=
b>fooVar </b>here...<br>}<br><br></div>In the above example, I may use the =
methods  <b>setFooVar </b>and <b>getFooVar</b> as I please, but I <u><b>do =
not</b></u> have access to <b>fooVar</b>. The private member variable <b>fo=
oVar </b>is <i><b>hidden </b></i>from <b>fooClass</b>.<br>
However, by using what I propose here, I believe would be much cleaner than=
 having to <i>obfuscate </i>the code with the addition of an additional cla=
ss meant <i><b>only to hide access</b></i> to <b>fooVar</b>.=C2=A0 <br>In m=
y opinion, the use of an additional Access Modifier <i><b>restricted</b></i=
>, would be a much more elegant solution to this somewhat common problem.<b=
r>
<br>I welcome any thoughts or ideas you may have relating to this...<br><br=
>Thank you,<br><br><b>Lance Bledsoe</b><br><i>Austin, Texas<br>May 2014</i>=
<span class=3D"HOEnZb"><font color=3D"#888888"><br><br><br><br><br><br><br>
<br></font></span></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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11349920fa93df04f8fbab8b--

.


Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Fri, 9 May 2014 20:22:21 +0200
Raw View
2014-05-09 20:19 GMT+02:00 Andrew Tomazos <andrewtomazos@gmail.com>:
> On Fri, May 9, 2014 at 8:14 PM, Daniel Kr=C3=BCgler <daniel.kruegler@gmai=
l.com>
> wrote:
>>
>> 2014-05-09 20:03 GMT+02:00  <lwb.ztexas@gmail.com>:
>> >
>> > I Propose a new Class Access Modifier "restricted" to be used like
>> > public,
>> > protected, private, etc.
>> >
>> > Sometimes it would be nice to have a 4th Class Access Modifier, I'll
>> > call it
>> > "restricted", which would be  similar to "private", but which would
>> > provide
>> > restricted access to members, methods, etc.,
>> > ONLY within the File where the Class was defined (generally the .h
>> > file).
>>
>> The standard does not require that source code is stored in files, the
>> notion of /source file/ in C++ does only exist conceptually, so in
>> which sense do you suggest to define the "file"?
>
> While I am pretty sure I'm against the proposal, your statement is
> incorrect:
>
> [lex.separate]/1:
>
>     The text of the program is kept in units called source =EF=AC=81les i=
n this
> International Standard

The are named source files, but this exists only as a concept, but
they are not required to be files, see the explanatory note in 2.2 p7:

"Source files, translation units and translated translation units need
not necessarily be stored as files, nor need
there be any one-to-one correspondence between these entities and any
external representation. The
description is conceptual only, and does not specify any particular
implementation."

- Daniel

--=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: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 9 May 2014 20:26:57 +0200
Raw View
--089e0122aaee27ac4204f8fbbeaa
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, May 9, 2014 at 8:22 PM, Daniel Kr=C3=BCgler <daniel.kruegler@gmail.=
com>wrote:

> 2014-05-09 20:19 GMT+02:00 Andrew Tomazos <andrewtomazos@gmail.com>:
> > While I am pretty sure I'm against the proposal, your statement is
> > incorrect:
> >
> > [lex.separate]/1:
> >
> >     The text of the program is kept in units called source =EF=AC=81les=
 in this
> > International Standard
>
> The are named source files, but this exists only as a concept, but
> they are not required to be files, see the explanatory note in 2.2 p7:
>
> "Source files, translation units and translated translation units need
> not necessarily be stored as files, nor need
> there be any one-to-one correspondence between these entities and any
> external representation. The
> description is conceptual only, and does not specify any particular
> implementation."


 Sure - so I guess the way I read the proposal is that when the OP said
file, he meant a *source file* as defined in [lex.separate]/1, and wasn't
talking about how they were stored.

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 9, 2014 at 8:22 PM, Daniel Kr=C3=BCgler <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler@g=
mail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2014-05-09 20:19 GMT+02:00 Andrew Tomazos &l=
t;<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmail.com</a>&gt=
;:<br>

<div><div class=3D"h5">&gt; While I am pretty sure I&#39;m against the prop=
osal, your statement is<br>
&gt; incorrect:<br>
&gt;<br>
&gt; [lex.separate]/1:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 The text of the program is kept in units called source =
=EF=AC=81les in this<br>
&gt; International Standard<br>
<br>
</div></div>The are named source files, but this exists only as a concept, =
but<br>
they are not required to be files, see the explanatory note in 2.2 p7:<br>
<br>
&quot;Source files, translation units and translated translation units need=
<br>
not necessarily be stored as files, nor need<br>
there be any one-to-one correspondence between these entities and any<br>
external representation. The<br>
description is conceptual only, and does not specify any particular<br>
implementation.&quot;</blockquote><div><br></div><div>=C2=A0Sure - so I gue=
ss the way I read the proposal is that when the OP said file, he meant a=C2=
=A0<i>source file</i>=C2=A0as defined in [lex.separate]/1, and wasn&#39;t t=
alking about how they were stored.</div>
<div><br></div><div><br></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0122aaee27ac4204f8fbbeaa--

.


Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 9 May 2014 14:30:55 -0400
Raw View
--047d7b34315e5e279c04f8fbcc67
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

How about we drop the "source file" stuff and say it is restricted to
functions inlined inside the class definition.

I still don't think it is a good _enough_ idea, but that would at least fit
in with how the language works.

I understand the idea behind the restriction; an alternative way of doing
it might be:

class X
{
    // use atributes maybe?
    // list the functions allowed to access x directly
    int x [[friend { getX(), setX(int) }]];
....
};

Or similar syntax.

Alternatively, maybe this could be done by a code-checker outside the
compiler?  Just look to see if 'x' is used directly "too often" within
class functions?
It seems like a stylistic rule, so an external style checker might be the
way to go.

On Fri, May 9, 2014 at 2:22 PM, Daniel Kr=C3=BCgler <daniel.kruegler@gmail.=
com>wrote:

> 2014-05-09 20:19 GMT+02:00 Andrew Tomazos <andrewtomazos@gmail.com>:
> > On Fri, May 9, 2014 at 8:14 PM, Daniel Kr=C3=BCgler <
> daniel.kruegler@gmail.com>
> > wrote:
> >>
> >> 2014-05-09 20:03 GMT+02:00  <lwb.ztexas@gmail.com>:
> >> >
> >> > I Propose a new Class Access Modifier "restricted" to be used like
> >> > public,
> >> > protected, private, etc.
> >> >
> >> > Sometimes it would be nice to have a 4th Class Access Modifier, I'll
> >> > call it
> >> > "restricted", which would be  similar to "private", but which would
> >> > provide
> >> > restricted access to members, methods, etc.,
> >> > ONLY within the File where the Class was defined (generally the .h
> >> > file).
> >>
> >> The standard does not require that source code is stored in files, the
> >> notion of /source file/ in C++ does only exist conceptually, so in
> >> which sense do you suggest to define the "file"?
> >
> > While I am pretty sure I'm against the proposal, your statement is
> > incorrect:
> >
> > [lex.separate]/1:
> >
> >     The text of the program is kept in units called source =EF=AC=81les=
 in this
> > International Standard
>
> The are named source files, but this exists only as a concept, but
> they are not required to be files, see the explanatory note in 2.2 p7:
>
> "Source files, translation units and translated translation units need
> not necessarily be stored as files, nor need
> there be any one-to-one correspondence between these entities and any
> external representation. The
> description is conceptual only, and does not specify any particular
> implementation."
>
> - Daniel
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr"><div><div><div>How about we drop the &quot;source file&quo=
t; stuff and say it is restricted to functions inlined inside the class def=
inition.<br><br></div>I still don&#39;t think it is a good _enough_ idea, b=
ut that would at least fit in with how the language works.<br>
<br>I understand the idea behind the restriction; an alternative way of doi=
ng it might be:<br><br></div>class X<br>{<br></div><div>=C2=A0=C2=A0=C2=A0 =
// use atributes maybe?<br>=C2=A0=C2=A0=C2=A0 // list the functions allowed=
 to access x directly<br></div>
=C2=A0=C2=A0=C2=A0 int x [[friend { getX(), setX(int) }]];<br><div><div><di=
v><div class=3D"gmail_extra">...<br>};<br><br></div><div class=3D"gmail_ext=
ra">Or similar syntax.<br><br>Alternatively, maybe this could be done by a =
code-checker outside the compiler?=C2=A0 Just look to see if &#39;x&#39; is=
 used directly &quot;too often&quot; within class functions?<br>
It seems like a stylistic rule, so an external style checker might be the w=
ay to go.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Fri, May 9, 2014 at 2:22 PM, Daniel Kr=C3=BCgler <span dir=3D"ltr">&lt=
;<a href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.krue=
gler@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2014-05-09 20:19 GMT+02:00 Andrew Tomazos &l=
t;<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmail.com</a>&gt=
;:<br>

<div class=3D"">&gt; On Fri, May 9, 2014 at 8:14 PM, Daniel Kr=C3=BCgler &l=
t;<a href=3D"mailto:daniel.kruegler@gmail.com">daniel.kruegler@gmail.com</a=
>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; 2014-05-09 20:03 GMT+02:00 =C2=A0&lt;<a href=3D"mailto:lwb.ztexas@=
gmail.com">lwb.ztexas@gmail.com</a>&gt;:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I Propose a new Class Access Modifier &quot;restricted&quot; =
to be used like<br>
&gt;&gt; &gt; public,<br>
&gt;&gt; &gt; protected, private, etc.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Sometimes it would be nice to have a 4th Class Access Modifie=
r, I&#39;ll<br>
&gt;&gt; &gt; call it<br>
&gt;&gt; &gt; &quot;restricted&quot;, which would be =C2=A0similar to &quot=
;private&quot;, but which would<br>
&gt;&gt; &gt; provide<br>
&gt;&gt; &gt; restricted access to members, methods, etc.,<br>
&gt;&gt; &gt; ONLY within the File where the Class was defined (generally t=
he .h<br>
&gt;&gt; &gt; file).<br>
&gt;&gt;<br>
&gt;&gt; The standard does not require that source code is stored in files,=
 the<br>
&gt;&gt; notion of /source file/ in C++ does only exist conceptually, so in=
<br>
&gt;&gt; which sense do you suggest to define the &quot;file&quot;?<br>
&gt;<br>
&gt; While I am pretty sure I&#39;m against the proposal, your statement is=
<br>
&gt; incorrect:<br>
&gt;<br>
&gt; [lex.separate]/1:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 The text of the program is kept in units called source =
=EF=AC=81les in this<br>
&gt; International Standard<br>
<br>
</div>The are named source files, but this exists only as a concept, but<br=
>
they are not required to be files, see the explanatory note in 2.2 p7:<br>
<br>
&quot;Source files, translation units and translated translation units need=
<br>
not necessarily be stored as files, nor need<br>
there be any one-to-one correspondence between these entities and any<br>
external representation. The<br>
description is conceptual only, and does not specify any particular<br>
implementation.&quot;<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
- Daniel<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b34315e5e279c04f8fbcc67--

.


Author: Lance Bledsoe <lwb.ztexas@gmail.com>
Date: Fri, 9 May 2014 11:31:46 -0700 (PDT)
Raw View
------=_Part_3_27975406.1399660306389
Content-Type: text/plain; charset=UTF-8

In my proposal, this would generate a compile time error.

I guess what I'm saying here is that the use of *restricted *would then be
restricted to the confines of the *class *definition itself (between the
brackets { }).

When I said *file*, I should have been more specific and said *class
definition*. My apologies.  (My habit is to put the class definition in the
..h file and the implementation in the .cpp file)

Of course the following code could be in a single *file*, but would
generate an error:

class fooClass
{
    ...

    protected:

        void setFooVar(int var);
        inline int getFooVar(void) { return fooVar; }

    restricted:

        int fooVar;
}

fooClass::setFooVar(int var)
{
    fooVar = var;  // Error, not allowed, outside class definition
}

Thanks,
Lance

On Friday, May 9, 2014 1:15:46 PM UTC-5, Andrew Tomazos wrote:
>
> Hi Lance,
>
> Thanks for your proposal.
>
> Is the following well-formed under your proposal:
>
> file a:
>
>     class X
>     {
>     restricted: int x;
>
> file b:
>
>     include "a"
>
>     int f() { return x; }
>
>     };
>
> Regards,
> Andrew.
>
>
>
>
>
> On Fri, May 9, 2014 at 8:03 PM, <lwb.z...@gmail.com <javascript:>> wrote:
>
>>
>> I Propose a new Class Access Modifier "*restricted*" to be used like
>> public, protected, private, etc.
>>
>> Sometimes it would be nice to have a 4th Class Access Modifier, I'll call
>> it "*restricted*", which would be  similar to "*private*", but which
>> would provide restricted access to members, methods, etc.,
>> *ONLY *within the *File *where the *Class *was defined (generally the
>> *.h* file).  The reasoning behind this would be to make the Compiler to
>> provide an additional restriction for access by *NOT *allowing
>> the member/method to be access in the corresponding *.cpp* file.  This
>> would effectively *force *(or remind) the programmer to access the
>> (generally) member variable through defined methods and
>> *not allow access directly*.
>>
>> It is not uncommon to have a member variable which you would prefer were
>> accessed *only *through some sort of function or method, hidden from the
>> overall class code.  For example (in *.h* file):
>>
>> class fooClass
>> {
>>     ...
>>
>>     protected:
>>
>>         inline void setFooVar(int val) { fooVar = val; }
>>         inline int getFooVar(void) { return fooVar; }
>>
>>     private:
>>
>>         int fooVar;
>> }
>>
>> In the above code, the methods *setFooVar *and *getFooVar *are used to
>> manipulate the private variable *fooVar*.  The programmer desires that
>> all access to *fooVar *be
>> *restricted to these two functions onl*y.  However, there is nothing to
>> prevent a subsequent programmer to accessing *fooVar *directly in a
>> corresponding *.cpp* file method, *e.g. fooVar = 10;* .
>>
>> In my proposal, you would write the class code this way (*note the
>> restricted Access Modifier in the .h file*):
>>
>> class fooClass
>> {
>>     ...
>>
>>     protected:
>>
>>         inline void setFooVar(int val) { fooVar = val; }
>>         inline int getFooVar(void) { return fooVar; }
>>
>>     restricted:
>>
>>         int fooVar;
>> }
>>
>> With this new *restricted *Access Modifier, the programmer can now
>> insure that any subsequent access of the *fooVar *member variable will *NOT
>> *be allowed within the code in the .*cpp *file,
>> therefore insuring that *all access* there (in the* .cpp* file) *MUST *be
>> achieved by using the methods *setFooVar *and *getFooVar*.  Of course
>> the use of *restricted *would be optional,
>> *in the same way which the use of const is generally optional, but forces
>> a more specific restriction on what types of data may be, for example,
>> passed as a parameter to a function*.
>>
>> Currently, this sort of data hiding *can *be accomplished via the use of
>> a somewhat messy *parent class*, where the purpose of the *parent class*is *ONLY
>> *to hide data and force access
>> through specific member functions.  For example:
>>
>> class hideFooClass
>> {
>>     ...
>>
>>     protected:
>>
>>         inline void setFooVar(int val) { fooVar = val; }
>>         inline int getFooVar(void) { return fooVar; }
>>
>>     private:
>>
>>         int fooVar;
>> }
>>
>> class fooClass : public hideFooClass
>> {
>>     // No access to *fooVar *here...
>> }
>>
>> In the above example, I may use the methods *setFooVar *and *getFooVar*as I please, but I *do
>> not* have access to *fooVar*. The private member variable *fooVar *is *hidden
>> *from *fooClass*.
>> However, by using what I propose here, I believe would be much cleaner
>> than having to *obfuscate *the code with the addition of an additional
>> class meant *only to hide access* to *fooVar*.
>> In my opinion, the use of an additional Access Modifier *restricted*,
>> would be a much more elegant solution to this somewhat common problem.
>>
>> I welcome any thoughts or ideas you may have relating to this...
>>
>> Thank you,
>>
>> *Lance Bledsoe*
>>
>> *Austin, TexasMay 2014*
>>
>>
>>
>>
>>
>>
>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> 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/.

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

<div dir=3D"ltr">In my proposal, this would generate a compile time error.<=
br><br>I guess what I'm saying here is that the use of <i><b>restricted </b=
></i>would then be restricted to the confines of the <b>class </b>definitio=
n itself (between the brackets { }).<br><br>When I said <i><b>file</b></i>,=
 I should have been more specific and said <b><i>class definition</i></b>. =
My apologies.&nbsp; (My habit is to put the class definition in the .h file=
 and the implementation in the .cpp file)<br><br>Of course the following co=
de could be in a single <i><b>file</b></i>, but would generate an error:<br=
><br><div style=3D"margin-left: 40px;">class fooClass<br>{<br>&nbsp;&nbsp;&=
nbsp; ...<br><br>&nbsp;&nbsp;&nbsp; protected:<br><br>&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; void setFooVar(int var);<br>&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; inline int getFooVar(void) { return fooVar; }<br><br>&nbs=
p;&nbsp;&nbsp; restricted:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; int fooVar;<br>}<br></div><br><div style=3D"margin-left: 40px;">fooClass:=
:setFooVar(int var)<br>{<br>&nbsp;&nbsp;&nbsp; fooVar =3D var;&nbsp; // Err=
or, not allowed, outside class definition<br>}<br></div><br>Thanks,<br>Lanc=
e<br><br>On Friday, May 9, 2014 1:15:46 PM UTC-5, Andrew Tomazos wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hi Lance,<div><br=
></div><div>Thanks for your proposal.</div><div><br></div><div>Is the follo=
wing well-formed under your proposal:</div><div><br></div><div>file a:</div=
><div><br></div><div>&nbsp; &nbsp; class X</div><div>
&nbsp; &nbsp; {</div><div>&nbsp; &nbsp; restricted: int x;</div><div><br></=
div><div>file b:</div><div><br></div><div>&nbsp; &nbsp; include "a"</div><d=
iv><br></div><div>&nbsp; &nbsp; int f() { return x; }</div><div><br></div><=
div>&nbsp; &nbsp; };</div><div><br></div>
<div>Regards,</div><div>Andrew.</div><div><br></div><div><br></div><div><br=
></div></div><div><br><br><div class=3D"gmail_quote">On Fri, May 9, 2014 at=
 8:03 PM,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"e-xd7X3ma0oJ" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">lwb.z=
....@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>I Propose a new Class A=
ccess Modifier "<b><i>restricted</i></b>" to be used like public, protected=
, private, etc.<br>
<br>Sometimes it would be nice to have a 4th Class Access Modifier, I'll ca=
ll it "<b>restricted</b>", which would be&nbsp; similar to "<b>private</b>"=
, but which would provide restricted access to members, methods, etc., <br>
<b>ONLY </b>within the <b>File </b>where the <b>Class </b>was defined (gene=
rally the <b>.h</b> file).&nbsp; The reasoning behind this would be to make=
 the Compiler to provide an additional restriction for access by <b>NOT </b=
>allowing<br>
the member/method to be access in the corresponding <b>.cpp</b> file.&nbsp;=
 This would effectively <b>force </b>(or remind) the programmer to access t=
he (generally) member variable through defined methods and<br><b>not allow =
access directly</b>.<br>
<br>It is not uncommon to have a member variable which you would prefer wer=
e accessed <b>only </b>through some sort of function or method, hidden from=
 the overall class code.&nbsp; For example (in <b>.h</b> file):<br><br><div=
 style=3D"margin-left:40px">
class fooClass<br>{<br>&nbsp;&nbsp;&nbsp; ...<br><br>&nbsp;&nbsp;&nbsp; pro=
tected:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; inline void setFo=
oVar(int val) { fooVar =3D val; }<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; inline int getFooVar(void) { return fooVar; }<br><br>&nbsp;&nbsp;&nbsp=
; private:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int fooVar;<br=
>
}<br></div><br>In the above code, the methods <b>setFooVar </b>and <b>getFo=
oVar </b>are used to manipulate the private variable <b>fooVar</b>.&nbsp; T=
he programmer desires that all access to <b>fooVar </b>be <b>restricted to =
<br>
these two functions onl</b>y.&nbsp; However, there is nothing to prevent a =
subsequent programmer to accessing <b>fooVar </b>directly in a correspondin=
g <b>.cpp</b> file method, <b><i>e.g. fooVar =3D 10;</i></b> .<br><br>In my=
 proposal, you would write the class code this way (<i>note the <b>restrict=
ed </b>Access Modifier in the<b> .h</b> file</i>):<br>
<br><div style=3D"margin-left:40px">class fooClass<br>{<br>&nbsp;&nbsp;&nbs=
p; ...<br><br>&nbsp;&nbsp;&nbsp; protected:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; inline void setFooVar(int val) { fooVar =3D val; }<br>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; inline int getFooVar(void) { retur=
n fooVar; }<br><br>&nbsp;&nbsp;&nbsp; restricted:<br>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int fooVar;<br>}<br><br></di=
v>With this new <b>restricted </b>Access Modifier, the programmer can now i=
nsure that any subsequent access of the <b>fooVar </b>member variable will =
<b>NOT </b>be allowed within the code in the .<b>cpp </b>file,<br>
therefore insuring that <b>all access</b> there (in the<b> .cpp</b> file) <=
b>MUST </b>be achieved by using the methods  <b>setFooVar </b>and <b>getFoo=
Var</b>.&nbsp; Of course the use of <i><b>restricted </b></i>would be optio=
nal, <i>in the<br>
same way which the use of <b>const </b>is generally optional, but forces a =
more specific restriction on what types of data may be, for example, passed=
 as a parameter to a function</i>.<br><br>Currently, this sort of data hidi=
ng <u><b>can </b></u>be accomplished via the use of a somewhat messy <i><b>=
parent class</b></i>, where the purpose of the <i><b>parent class</b></i> i=
s <b>ONLY </b>to hide data and force access<br>
through specific member functions.&nbsp; For example:<br><br><div style=3D"=
margin-left:40px">class hideFooClass<br>{<br>&nbsp;&nbsp;&nbsp; ...<br><br>=
&nbsp;&nbsp;&nbsp; protected:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; inline void setFooVar(int val) { fooVar =3D val; }<br>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; inline int getFooVar(void) { return fooVar; }<br=
>
<br>&nbsp;&nbsp;&nbsp; private:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; int fooVar;<br>}<br></div><br><div style=3D"margin-left:40px">class =
fooClass : public hideFooClass<br>{<br>&nbsp;&nbsp;&nbsp; // No access to <=
b>fooVar </b>here...<br>}<br><br></div>In the above example, I may use the =
methods  <b>setFooVar </b>and <b>getFooVar</b> as I please, but I <u><b>do =
not</b></u> have access to <b>fooVar</b>. The private member variable <b>fo=
oVar </b>is <i><b>hidden </b></i>from <b>fooClass</b>.<br>
However, by using what I propose here, I believe would be much cleaner than=
 having to <i>obfuscate </i>the code with the addition of an additional cla=
ss meant <i><b>only to hide access</b></i> to <b>fooVar</b>.&nbsp; <br>In m=
y opinion, the use of an additional Access Modifier <i><b>restricted</b></i=
>, would be a much more elegant solution to this somewhat common problem.<b=
r>
<br>I welcome any thoughts or ideas you may have relating to this...<br><br=
>Thank you,<br><br><b>Lance Bledsoe</b><br><i>Austin, Texas<br>May 2014</i>=
<span><font color=3D"#888888"><br><br><br><br><br><br><br>
<br></font></span></div><span><font color=3D"#888888">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
e-xd7X3ma0oJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"e-xd7X3ma0oJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</font></span></blockquote></div><br></div>
</blockquote><script charset=3D"UTF-8" src=3D"chrome://hdv/content/hdv.js" =
type=3D"application/javascript"></script><script charset=3D"UTF-8" src=3D"c=
hrome://hdv/content/hdv.js" type=3D"application/javascript"></script></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3_27975406.1399660306389--

.


Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 9 May 2014 20:38:18 +0200
Raw View
--047d7bd760c2bedc5104f8fbe625
Content-Type: text/plain; charset=UTF-8

Lance:  You have contradicted yourself.  If access to a restricted member
can be obtained only inline within a class definition (class specifier)
then my example should be well-formed, and your proposal has nothing to do
with source files.  Or are you saying that restricted members can only be
accessed within the same source file AND inline within a class definition?
    -Andrew


On Fri, May 9, 2014 at 8:31 PM, Lance Bledsoe <lwb.ztexas@gmail.com> wrote:

> In my proposal, this would generate a compile time error.
>
> I guess what I'm saying here is that the use of *restricted *would then
> be restricted to the confines of the *class *definition itself (between
> the brackets { }).
>
> When I said *file*, I should have been more specific and said *class
> definition*. My apologies.  (My habit is to put the class definition in
> the .h file and the implementation in the .cpp file)
>
> Of course the following code could be in a single *file*, but would
> generate an error:
>
> class fooClass
> {
>     ...
>
>     protected:
>
>         void setFooVar(int var);
>
>         inline int getFooVar(void) { return fooVar; }
>
>     restricted:
>
>         int fooVar;
> }
>
> fooClass::setFooVar(int var)
> {
>     fooVar = var;  // Error, not allowed, outside class definition
> }
>
> Thanks,
> Lance
>
>
> On Friday, May 9, 2014 1:15:46 PM UTC-5, Andrew Tomazos wrote:
>
>> Hi Lance,
>>
>> Thanks for your proposal.
>>
>> Is the following well-formed under your proposal:
>>
>> file a:
>>
>>     class X
>>     {
>>     restricted: int x;
>>
>> file b:
>>
>>     include "a"
>>
>>     int f() { return x; }
>>
>>     };
>>
>> Regards,
>> Andrew.
>>
>>
>>
>>
>>
>> On Fri, May 9, 2014 at 8:03 PM, <lwb.z...@gmail.com> wrote:
>>
>>>
>>> I Propose a new Class Access Modifier "*restricted*" to be used like
>>> public, protected, private, etc.
>>>
>>> Sometimes it would be nice to have a 4th Class Access Modifier, I'll
>>> call it "*restricted*", which would be  similar to "*private*", but
>>> which would provide restricted access to members, methods, etc.,
>>> *ONLY *within the *File *where the *Class *was defined (generally the
>>> *.h* file).  The reasoning behind this would be to make the Compiler to
>>> provide an additional restriction for access by *NOT *allowing
>>> the member/method to be access in the corresponding *.cpp* file.  This
>>> would effectively *force *(or remind) the programmer to access the
>>> (generally) member variable through defined methods and
>>> *not allow access directly*.
>>>
>>> It is not uncommon to have a member variable which you would prefer were
>>> accessed *only *through some sort of function or method, hidden from
>>> the overall class code.  For example (in *.h* file):
>>>
>>> class fooClass
>>> {
>>>     ...
>>>
>>>     protected:
>>>
>>>         inline void setFooVar(int val) { fooVar = val; }
>>>         inline int getFooVar(void) { return fooVar; }
>>>
>>>     private:
>>>
>>>         int fooVar;
>>> }
>>>
>>> In the above code, the methods *setFooVar *and *getFooVar *are used to
>>> manipulate the private variable *fooVar*.  The programmer desires that
>>> all access to *fooVar *be
>>> *restricted to these two functions onl*y.  However, there is nothing to
>>> prevent a subsequent programmer to accessing *fooVar *directly in a
>>> corresponding *.cpp* file method, *e.g. fooVar = 10;* .
>>>
>>> In my proposal, you would write the class code this way (*note the
>>> restricted Access Modifier in the .h file*):
>>>
>>> class fooClass
>>> {
>>>     ...
>>>
>>>     protected:
>>>
>>>         inline void setFooVar(int val) { fooVar = val; }
>>>         inline int getFooVar(void) { return fooVar; }
>>>
>>>     restricted:
>>>
>>>         int fooVar;
>>> }
>>>
>>> With this new *restricted *Access Modifier, the programmer can now
>>> insure that any subsequent access of the *fooVar *member variable will *NOT
>>> *be allowed within the code in the .*cpp *file,
>>> therefore insuring that *all access* there (in the* .cpp* file) *MUST *be
>>> achieved by using the methods *setFooVar *and *getFooVar*.  Of course
>>> the use of *restricted *would be optional,
>>> *in the same way which the use of const is generally optional, but
>>> forces a more specific restriction on what types of data may be, for
>>> example, passed as a parameter to a function*.
>>>
>>> Currently, this sort of data hiding *can *be accomplished via the use
>>> of a somewhat messy *parent class*, where the purpose of the *parent
>>> class* is *ONLY *to hide data and force access
>>> through specific member functions.  For example:
>>>
>>> class hideFooClass
>>> {
>>>     ...
>>>
>>>     protected:
>>>
>>>         inline void setFooVar(int val) { fooVar = val; }
>>>         inline int getFooVar(void) { return fooVar; }
>>>
>>>     private:
>>>
>>>         int fooVar;
>>> }
>>>
>>> class fooClass : public hideFooClass
>>> {
>>>     // No access to *fooVar *here...
>>> }
>>>
>>> In the above example, I may use the methods *setFooVar *and *getFooVar*as I please, but I *do
>>> not* have access to *fooVar*. The private member variable *fooVar *is *hidden
>>> *from *fooClass*.
>>> However, by using what I propose here, I believe would be much cleaner
>>> than having to *obfuscate *the code with the addition of an additional
>>> class meant *only to hide access* to *fooVar*.
>>> In my opinion, the use of an additional Access Modifier *restricted*,
>>> would be a much more elegant solution to this somewhat common problem.
>>>
>>> I welcome any thoughts or ideas you may have relating to this...
>>>
>>> Thank you,
>>>
>>> *Lance Bledsoe*
>>>
>>> *Austin, TexasMay 2014*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@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/.
>

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra">Lance: =C2=A0You have contradic=
ted yourself. =C2=A0If access to a restricted member can be obtained only i=
nline within a class definition (class specifier) then my example should be=
 well-formed, and your proposal has nothing to do with source files. =C2=A0=
Or are you saying that restricted members can only be accessed within the s=
ame source file AND inline within a class definition?</div>
<div class=3D"gmail_extra">=C2=A0 =C2=A0 -Andrew<br><br><br><div class=3D"g=
mail_quote">On Fri, May 9, 2014 at 8:31 PM, Lance Bledsoe <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:lwb.ztexas@gmail.com" target=3D"_blank">lwb.ztexas@g=
mail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">In my proposal, this would =
generate a compile time error.<br><br>I guess what I&#39;m saying here is t=
hat the use of <i><b>restricted </b></i>would then be restricted to the con=
fines of the <b>class </b>definition itself (between the brackets { }).<br>
<br>When I said <i><b>file</b></i>, I should have been more specific and sa=
id <b><i>class definition</i></b>. My apologies.=C2=A0 (My habit is to put =
the class definition in the .h file and the implementation in the .cpp file=
)<br>
<br>Of course the following code could be in a single <i><b>file</b></i>, b=
ut would generate an error:<br><br><div style=3D"margin-left:40px">class fo=
oClass<br>{<br>=C2=A0=C2=A0=C2=A0 ...<br><br>=C2=A0=C2=A0=C2=A0 protected:<=
br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 void setFooVar(int var);<=
div class=3D"">
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inline int getFooVar(void) {=
 return fooVar; }<br><br>=C2=A0=C2=A0=C2=A0 restricted:<br><br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int fooVar;<br>}<br></div></div><br><div sty=
le=3D"margin-left:40px">fooClass::setFooVar(int var)<br>{<br>=C2=A0=C2=A0=
=C2=A0 fooVar =3D var;=C2=A0 // Error, not allowed, outside class definitio=
n<br>
}<br></div><br>Thanks,<br>Lance<div class=3D""><br><br>On Friday, May 9, 20=
14 1:15:46 PM UTC-5, Andrew Tomazos wrote:</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex">
<div class=3D""><div dir=3D"ltr">Hi Lance,<div><br></div><div>Thanks for yo=
ur proposal.</div><div><br></div><div>Is the following well-formed under yo=
ur proposal:</div><div><br></div><div>file a:</div><div><br></div><div>=C2=
=A0 =C2=A0 class X</div>
<div>
=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 restricted: int x;</div><div><br></=
div><div>file b:</div><div><br></div><div>=C2=A0 =C2=A0 include &quot;a&quo=
t;</div><div><br></div><div>=C2=A0 =C2=A0 int f() { return x; }</div><div><=
br></div><div>=C2=A0 =C2=A0 };</div><div><br>
</div>
<div>Regards,</div><div>Andrew.</div><div><br></div><div><br></div><div><br=
></div></div></div><div><br><br><div class=3D"gmail_quote"><div><div class=
=3D"h5">On Fri, May 9, 2014 at 8:03 PM,  <span dir=3D"ltr">&lt;<a>lwb.z...@=
gmail.com</a>&gt;</span> wrote:<br>

</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=
=3D"ltr"><br>I Propose a new Class Access Modifier &quot;<b><i>restricted</=
i></b>&quot; to be used like public, protected, private, etc.<br>

<br>Sometimes it would be nice to have a 4th Class Access Modifier, I&#39;l=
l call it &quot;<b>restricted</b>&quot;, which would be=C2=A0 similar to &q=
uot;<b>private</b>&quot;, but which would provide restricted access to memb=
ers, methods, etc., <br>

<b>ONLY </b>within the <b>File </b>where the <b>Class </b>was defined (gene=
rally the <b>.h</b> file).=C2=A0 The reasoning behind this would be to make=
 the Compiler to provide an additional restriction for access by <b>NOT </b=
>allowing<br>

the member/method to be access in the corresponding <b>.cpp</b> file.=C2=A0=
 This would effectively <b>force </b>(or remind) the programmer to access t=
he (generally) member variable through defined methods and<br><b>not allow =
access directly</b>.<br>

<br>It is not uncommon to have a member variable which you would prefer wer=
e accessed <b>only </b>through some sort of function or method, hidden from=
 the overall class code.=C2=A0 For example (in <b>.h</b> file):<br><br><div=
 style=3D"margin-left:40px">

class fooClass<br>{<br>=C2=A0=C2=A0=C2=A0 ...<br><br>=C2=A0=C2=A0=C2=A0 pro=
tected:<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inline void setFo=
oVar(int val) { fooVar =3D val; }<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 inline int getFooVar(void) { return fooVar; }<br><br>=C2=A0=C2=A0=C2=
=A0 private:<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int fooVar;<=
br>

}<br></div><br>In the above code, the methods <b>setFooVar </b>and <b>getFo=
oVar </b>are used to manipulate the private variable <b>fooVar</b>.=C2=A0 T=
he programmer desires that all access to <b>fooVar </b>be <b>restricted to =
<br>

these two functions onl</b>y.=C2=A0 However, there is nothing to prevent a =
subsequent programmer to accessing <b>fooVar </b>directly in a correspondin=
g <b>.cpp</b> file method, <b><i>e.g. fooVar =3D 10;</i></b> .<br><br>In my=
 proposal, you would write the class code this way (<i>note the <b>restrict=
ed </b>Access Modifier in the<b> .h</b> file</i>):<br>

<br><div style=3D"margin-left:40px">class fooClass<br>{<br>=C2=A0=C2=A0=C2=
=A0 ...<br><br>=C2=A0=C2=A0=C2=A0 protected:<br><br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 inline void setFooVar(int val) { fooVar =3D val; }<br=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inline int getFooVar(void) { re=
turn fooVar; }<br><br>=C2=A0=C2=A0=C2=A0 restricted:<br>

<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int fooVar;<br>}<br><br></di=
v>With this new <b>restricted </b>Access Modifier, the programmer can now i=
nsure that any subsequent access of the <b>fooVar </b>member variable will =
<b>NOT </b>be allowed within the code in the .<b>cpp </b>file,<br>

therefore insuring that <b>all access</b> there (in the<b> .cpp</b> file) <=
b>MUST </b>be achieved by using the methods  <b>setFooVar </b>and <b>getFoo=
Var</b>.=C2=A0 Of course the use of <i><b>restricted </b></i>would be optio=
nal, <i>in the<br>

same way which the use of <b>const </b>is generally optional, but forces a =
more specific restriction on what types of data may be, for example, passed=
 as a parameter to a function</i>.<br><br>Currently, this sort of data hidi=
ng <u><b>can </b></u>be accomplished via the use of a somewhat messy <i><b>=
parent class</b></i>, where the purpose of the <i><b>parent class</b></i> i=
s <b>ONLY </b>to hide data and force access<br>

through specific member functions.=C2=A0 For example:<br><br><div style=3D"=
margin-left:40px">class hideFooClass<br>{<br>=C2=A0=C2=A0=C2=A0 ...<br><br>=
=C2=A0=C2=A0=C2=A0 protected:<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 inline void setFooVar(int val) { fooVar =3D val; }<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inline int getFooVar(void) { return fooVar; =
}<br>

<br>=C2=A0=C2=A0=C2=A0 private:<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 int fooVar;<br>}<br></div><br><div style=3D"margin-left:40px">class =
fooClass : public hideFooClass<br>{<br>=C2=A0=C2=A0=C2=A0 // No access to <=
b>fooVar </b>here...<br>}<br><br></div>In the above example, I may use the =
methods  <b>setFooVar </b>and <b>getFooVar</b> as I please, but I <u><b>do =
not</b></u> have access to <b>fooVar</b>. The private member variable <b>fo=
oVar </b>is <i><b>hidden </b></i>from <b>fooClass</b>.<br>

However, by using what I propose here, I believe would be much cleaner than=
 having to <i>obfuscate </i>the code with the addition of an additional cla=
ss meant <i><b>only to hide access</b></i> to <b>fooVar</b>.=C2=A0 <br>In m=
y opinion, the use of an additional Access Modifier <i><b>restricted</b></i=
>, would be a much more elegant solution to this somewhat common problem.<b=
r>

<br>I welcome any thoughts or ideas you may have relating to this...<br><br=
>Thank you,<br><br><b>Lance Bledsoe</b><br><i>Austin, Texas<br>May 2014</i>=
<span><font color=3D"#888888"><br><br><br><br><br><br><br>
<br></font></span></div></div></div><span><font color=3D"#888888"><div><div=
 class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<div class=
=3D""><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/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></font></span></blockquote></div><br></div>
</blockquote></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bd760c2bedc5104f8fbe625--

.


Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 9 May 2014 21:51:08 +0300
Raw View
On 9 May 2014 21:31, Lance Bledsoe <lwb.ztexas@gmail.com> wrote:
> In my proposal, this would generate a compile time error.
>
> I guess what I'm saying here is that the use of restricted would then be
> restricted to the confines of the class definition itself (between the
> brackets { }).

I doubt this is common enough to mandate an access-specifier-like facility. Some
findings when thinking of work-arounds that are not bases:
- I can't have a pack of friends. I toyed with the idea of having a
variadic class template
with friends as a parameter pack. Can't expand that with something
like friend Friends...;
- I can't befriend a class member in a data member (or a base) that is
a class template, the class
is not complete when the member is declared
- I can't have lambda members, it would've been nice to be able to
befriend the type
of such a lambda member, since that would be a unique type

Lifting some of those requirements would at least allow more palatable
work-arounds
without having to add a completely new language facility. I can also
imagine some reflection
facilities that would allow defining the base with much less boiler-plate.

--

---
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: Fri, 09 May 2014 16:26:03 -0400
Raw View
On 2014-05-09 14:30, Tony V E wrote:
> class X
> {
>      // list the functions allowed to access x directly
>      int x [[friend { getX(), setX(int) }]];
> };

I'm not much in favor of the whole "restricted" idea, but I would love
to see this sort of granular friending.

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

.