Topic: const public:" and "const private:" to avoid to
Author: r.s.salkin@gmail.com
Date: Thu, 20 Nov 2014 12:22:04 -0800 (PST)
Raw View
------=_Part_7200_525277009.1416514924260
Content-Type: multipart/alternative;
boundary="----=_Part_7201_25417446.1416514924260"
------=_Part_7201_25417446.1416514924260
Content-Type: text/plain; charset=UTF-8
In order to protect member variables from improper use, normally
get-functions are used. If the variable in question is constant, the
variable can also be declared const and be accessed directly by putting it
into the "public:"-section.
The disadvantage of the first approch is rather lengthy code for a simple
task: read-only access outside the class, read/write-access inside. The
second approach is not as general as the first since it can be only used
only for constant variables.
Why not introducing a keyword showing that a member variable can be altered
within the class but not outside, still having read-access from outside?
Proposal 1)
Add "const public:" and "const protected:" to the existing "public:",
"protected:", and "private:" keywords. Examples below. It is unclear what
happens with functions after those new keywords. They could be forbidden
(compiler error).
Examples:
Instead of:
class A
{
public:
int GetX() const
{
return m_iX;
};
private:
int m_iX;
};
write
class A
{
const public:
int m_iX;
};
This means m_iX is visible and readable from outside the class, but not
writable. From within it is writable.
Instead of
class B
{
public:
int GetX() const
{
return m_iX;
};
protected:
int m_iX;
};
write
class B
{
const protected:
int m_iX;
};
Here m_iX cannot be read outside the class, but it can be read by a derived
class (but not written). Within A it can be read or written.
class C : public B
{
void Function()
{
int iY=m_iX*3; // allowed
m_iX=4; // forbidden
}
};
Proposal 2)
Use a keyword like "readonly" preceding the member variable type.
Example:
class A
{
public:
const int m_iW; // readonly access inside and outside
class
readonly int m_iX; // readonly access outside,
read/write-access inside class
int m_iY; // read/write access inside and
outside (as usual)
protected:
readonly int m_iZ; // read but not write access from derived
class
private:
readonly int m_iL; // not really meaningful, should be not
allowed
};
--
---
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_7201_25417446.1416514924260
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">In order to protect member variables from improper use, no=
rmally get-functions are used. If the variable in question is constant, the=
variable can also be declared const and be accessed directly by putting it=
into the "public:"-section.<br>The disadvantage of the first approch is ra=
ther lengthy code for a simple task: read-only access outside the class, re=
ad/write-access inside. The second approach is not as general as the first =
since it can be only used only for constant variables.<br><br>Why not intro=
ducing a keyword showing that a member variable can be altered within the c=
lass but not outside, still having read-access from outside?<br><br>Proposa=
l 1) <br>Add "const public:" and "const protected:" to the existing "=
public:", "protected:", and "private:" keywords. Examples below. It is uncl=
ear what happens with functions after those new keywords. They could be for=
bidden (compiler error).<br><br>Examples:<br><br>Instead of:<br><span style=
=3D"color: rgb(0, 0, 255);"><br>class A<br>{<br>public:<br> &nbs=
p; int GetX() const<br> {<br> &nbs=
p; return m_iX;<br> };<br>private:<br> &=
nbsp; int m_iX;<br>};</span><br><br>write<br><br><span style=3D"color=
: rgb(0, 0, 255);">class A<br>{<br>const public:<br> <br> &=
nbsp; int m_iX;<br>};<br></span><br>This means m_iX is visible and readable=
from outside the class, but not writable. From within it is writable. <br>=
<br>Instead of<br><br><span style=3D"color: rgb(0, 0, 255);">class B<br>{<b=
r>public:<br> int GetX() const<br> {<br=
> return m_iX;<br> &nb=
sp; };<br>protected:<br> int m_iX;<br>};</span><br><br>wr=
ite<br><br><span style=3D"color: rgb(0, 0, 255);">class B<br>{<br>const pro=
tected:<br> <br> int m_iX;<br>};</span><br><br>Here =
m_iX cannot be read outside the class, but it can be read by a derived clas=
s (but not written). Within A it can be read or written.<br><br><span style=
=3D"color: rgb(0, 0, 255);">class C : public B<br>{<br> v=
oid Function()<br> {<br> &nb=
sp; int iY=3Dm_iX*3; // allowed<br> &nbs=
p; m_iX=3D4; &nb=
sp; // forbidden<br> }<br>};</span><br><br><br>Prop=
osal 2) <br>Use a keyword like "readonly" preceding the member variable typ=
e.<br>Example:<br><br><span style=3D"color: rgb(0, 0, 255);">class A<br>{<b=
r>public:<br> const int m_iW; &nbs=
p; // readonly access=
inside and outside class<br> readonly int m_iX; &nb=
sp; // readonly acces=
s outside, read/write-access inside class<br> int m_iY;&n=
bsp;  =
; // read=
/write access inside and outside (as usual)<br><br>protected:<br> &nbs=
p; readonly int m_iZ; =
// read but not write access from derived class<br><br>p=
rivate:<br> readonly int m_iL; &nb=
sp; // not really meaningful, should be not a=
llowed<br>};</span><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_7201_25417446.1416514924260--
------=_Part_7200_525277009.1416514924260--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 20 Nov 2014 16:12:32 -0500
Raw View
On 2014-11-20 15:22, r.s.salkin@gmail.com wrote:
> In order to protect member variables from improper use, normally
> get-functions are used. If the variable in question is constant, the
> variable can also be declared const and be accessed directly by putting it
> into the "public:"-section.
> The disadvantage of the first approch is rather lengthy code for a simple
> task: read-only access outside the class, read/write-access inside. The
> second approach is not as general as the first since it can be only used
> only for constant variables.
>
> Why not introducing a keyword showing that a member variable can be altered
> within the class but not outside, still having read-access from outside?
>
> Proposal 1)
> Add "const public:" and "const protected:" to the existing "public:",
> "protected:", and "private:" keywords. Examples below. It is unclear what
> happens with functions after those new keywords. They could be forbidden
> (compiler error).
I automatically dislike this because it precludes a member which has
public const access but mutable protected access.
> Proposal 2)
> Use a keyword like "readonly" preceding the member variable type.
Same comment.
Proposal 3)
Allow 'using const <member>'. Example:
class Foo
{
public:
using const m_x; // m_x is public but const
protected:
int m_x;
};
This could also be permitted if m_x is a member of a base class.
I'm not going to go digging about for it, but I brought this exact issue
up some time ago.
I currently have a class (i.e. this is in real, "production" code) that
does something like:
class Foo
{
protected:
T m_x;
public:
T const& m_mx = m_x;
};
....which "works" but is ugly.
--
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: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 20 Nov 2014 23:22:38 +0200
Raw View
On 20 November 2014 22:22, <r.s.salkin@gmail.com> wrote:
> In order to protect member variables from improper use, normally
> get-functions are used. If the variable in question is constant, the
> variable can also be declared const and be accessed directly by putting it
> into the "public:"-section.
> The disadvantage of the first approch is rather lengthy code for a simple
> task: read-only access outside the class, read/write-access inside. The
> second approach is not as general as the first since it can be only used
> only for constant variables.
Lengthy code?
class X
{
int private_x;
public:
const int& public_x = private_x;
};
--
---
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: corentin.schreiber@cea.fr
Date: Thu, 20 Nov 2014 13:26:53 -0800 (PST)
Raw View
------=_Part_837_898508596.1416518813845
Content-Type: multipart/alternative;
boundary="----=_Part_838_192743526.1416518813845"
------=_Part_838_192743526.1416518813845
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le jeudi 20 novembre 2014 21:22:04 UTC+1, r.s.s...@gmail.com a =C3=A9crit :
>
> In order to protect member variables from improper use, normally=20
> get-functions are used. If the variable in question is constant, the=20
> variable can also be declared const and be accessed directly by putting i=
t=20
> into the "public:"-section.
> The disadvantage of the first approch is rather lengthy code for a simple=
=20
> task: read-only access outside the class, read/write-access inside. The=
=20
> second approach is not as general as the first since it can be only used=
=20
> only for constant variables.
>
> Why not introducing a keyword showing that a member variable can be=20
> altered within the class but not outside, still having read-access from=
=20
> outside?
>
> Proposal 1) =20
> Add "const public:" and "const protected:" to the existing "public:",=20
> "protected:", and "private:" keywords. Examples below. It is unclear what=
=20
> happens with functions after those new keywords. They could be forbidden=
=20
> (compiler error).
>
> Examples:
>
> Instead of:
>
> class A
> {
> public:
> int GetX() const
> {
> return m_iX;
> };
> private:
> int m_iX;
> };
>
> write
>
> class A
> {
> const public:
> =20
> int m_iX;
> };
>
> This means m_iX is visible and readable from outside the class, but not=
=20
> writable. From within it is writable.=20
>
> Instead of
>
> class B
> {
> public:
> int GetX() const
> {
> return m_iX;
> };
> protected:
> int m_iX;
> };
>
> write
>
> class B
> {
> const protected:
> =20
> int m_iX;
> };
>
> Here m_iX cannot be read outside the class, but it can be read by a=20
> derived class (but not written). Within A it can be read or written.
>
> class C : public B
> {
> void Function()
> {
> int iY=3Dm_iX*3; // allowed
> m_iX=3D4; // forbidden
> }
> };
>
>
> Proposal 2)=20
> Use a keyword like "readonly" preceding the member variable type.
> Example:
>
> class A
> {
> public:
> const int m_iW; // readonly access inside and outside=
=20
> class
> readonly int m_iX; // readonly access outside,=20
> read/write-access inside class
> int m_iY; // read/write access inside and=20
> outside (as usual)
>
> protected:
> readonly int m_iZ; // read but not write access from=20
> derived class
>
> private:
> readonly int m_iL; // not really meaningful, should be not=
=20
> allowed
> };
>
The concept of a public member variable being mutable only by its owner is=
=20
something I have often wanted.
Writing an accessor is the only way to get a 100% equivalent construct in=
=20
terms of features and performance (that is, if the compiler inlines the=20
call correctly). One can argue that member variables should never be=20
exposed, and the use of the accessor should be preferred for the sake of=20
maintainability (should you, some day, decide to add a check, some=20
computation, or a mutex, before allowing external use of the variable). The=
=20
drawback of the accessor is that it requires boilerplate code, both for the=
=20
class writer (write the accessor function body) and the class user (a pair=
=20
of parenthesis).=20
Regarding the choice of syntax, I do not think the "const public:" will=20
work, for several reasons. First, the reason you quote yourself, i.e. that=
=20
it makes no sense for functions to be declared in this scope. Making this=
=20
ill-formed is a solution, but it is not very elegant. Second, some people=
=20
have been proposing already to extend the "public:" syntax in similar ways=
=20
(e.g. writing "const:", all the following member variables and functions=20
are automatically declared "const"). This was discussed here:
https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/scope=
/std-proposals/oACgySPOFzo/KvjlYsn9rIkJ
The idea has received mixed comments, mostly criticizing the lack of real=
=20
interest. This is something to keep in mind, as it is directly conflicting=
=20
your proposal. Finally, third, my personal feeling is that "const public:"=
=20
can be misleading, because you would rather interpret it like in the=20
proposal I linked just above, that is "all following member variables and=
=20
functions are public and declared const". With this syntax, it is not clear=
=20
that the variable is actually mutable inside the class.
Like "const" and "mutable", I really think this should be tied to=20
individual variables only. However, I am pretty certain that "readonly" is=
=20
not going to work either, as this is a commonly used identifier today. My=
=20
opinion is that it is also misleading, as the variable is *not* read only=
=20
inside the class. You can consider instead using a combination of existing=
=20
keywords. For example "this mutable", to be read: mutable by this class=20
only. But this can be confusing as it has nothing to do with the semantic=
=20
of the plain "mutable" keyword. Alternatively, "export const", to be read:=
=20
exported as a constant, does not suffer from this problem (if you remove=20
the "export" keyword, the variable is just "const" to everyone, which is=20
nice and predictable).
I also like Matthew's idea about "using const ...;". It's a bit more=20
verbose, but probably clearer and more versatile (good point about the=20
"const public" but "mutable protected" case).
On a side note, the issue with your production code (and Vile's suggestion)=
=20
is that you have to store this reference inside the class, therefore=20
wasting memory. That's probably not a big deal, but still.
Last point, on the declaration of a "readonly" member variable in private=
=20
scope. Although this is not useful, it should not be ill-formed. It does=20
not do any harm, and it will make things simpler if you decide, for some=20
reason, to change the access scope from "protected" to "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/.
------=_Part_838_192743526.1416518813845
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le jeudi 20 novembre 2014 21:22:04 UTC+1, r.s.s...@gmail.c=
om a =C3=A9crit :<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">In order to protect member variables from improper use, normally g=
et-functions are used. If the variable in question is constant, the variabl=
e can also be declared const and be accessed directly by putting it into th=
e "public:"-section.<br>The disadvantage of the first approch is rather len=
gthy code for a simple task: read-only access outside the class, read/write=
-access inside. The second approach is not as general as the first since it=
can be only used only for constant variables.<br><br>Why not introducing a=
keyword showing that a member variable can be altered within the class but=
not outside, still having read-access from outside?<br><br>Proposal 1)&nbs=
p; <br>Add "const public:" and "const protected:" to the existing "public:"=
, "protected:", and "private:" keywords. Examples below. It is unclear what=
happens with functions after those new keywords. They could be forbidden (=
compiler error).<br><br>Examples:<br><br>Instead of:<br><span style=3D"colo=
r:rgb(0,0,255)"><br>class A<br>{<br>public:<br> int GetX(=
) const<br> {<br> &nbs=
p; return m_iX;<br> };<br>private:<br> =
int m_iX;<br>};</span><br><br>write<br><br><span style=3D"color:rgb(0,0,255=
)">class A<br>{<br>const public:<br> <br> int m_iX;<=
br>};<br></span><br>This means m_iX is visible and readable from outside th=
e class, but not writable. From within it is writable. <br><br>Instead of<b=
r><br><span style=3D"color:rgb(0,0,255)">class B<br>{<br>public:<br> &=
nbsp; int GetX() const<br> {<br> &=
nbsp; return m_iX;<br> };<br>protected:=
<br> int m_iX;<br>};</span><br><br>write<br><br><span sty=
le=3D"color:rgb(0,0,255)">class B<br>{<br>const protected:<br> <br>&nb=
sp; int m_iX;<br>};</span><br><br>Here m_iX cannot be read outs=
ide the class, but it can be read by a derived class (but not written). Wit=
hin A it can be read or written.<br><br><span style=3D"color:rgb(0,0,255)">=
class C : public B<br>{<br> void Function()<br> &nbs=
p; {<br> int iY=3Dm_iX*3;&n=
bsp; // allowed<br> m_iX=3D4;&nbs=
p; // forbidden<br>&n=
bsp; }<br>};</span><br><br><br>Proposal 2) <br>Use a keyword li=
ke "readonly" preceding the member variable type.<br>Example:<br><br><span =
style=3D"color:rgb(0,0,255)">class A<br>{<br>public:<br> =
const int m_iW; =
// readonly access inside and outside class<br>&nb=
sp; readonly int m_iX;  =
; // readonly access outside, read/write-access ins=
ide class<br> int m_iY; &nbs=
p; &=
nbsp; // read/write access inside and outside=
(as usual)<br><br>protected:<br> readonly int m_iZ;  =
; // read but n=
ot write access from derived class<br><br>private:<br> readonly=
int m_iL;  =
; // not really meaningful, should be not allowed<br>};</span><br></div></b=
lockquote><div><br>The concept of a public member variable being mutable on=
ly by its owner is something I have often wanted.<br>Writing an accessor is=
the only way to get a 100% equivalent construct in terms of features and =
performance (that is, if the compiler inlines the call correctly). One can =
argue that member variables should never be exposed, and the use of the acc=
essor should be preferred for the sake of maintainability (should you, some=
day, decide to add a check, some computation, or a mutex, before allowing =
external use of the variable). The drawback of the accessor is that it requ=
ires boilerplate code, both for the class writer (write the accessor functi=
on body) and the class user (a pair of parenthesis). <br><br>Regarding the =
choice of syntax, I do not think the "const public:" will work, for several=
reasons. First, the reason you quote yourself, i.e. that it makes no sense=
for functions to be declared in this scope. Making this ill-formed is a so=
lution, but it is not very elegant. Second, some people have been proposing=
already to extend the "public:" syntax in similar ways (e.g. writing "cons=
t:", all the following member variables and functions are automatically dec=
lared "const"). This was discussed here:<br>https://groups.google.com/a/iso=
cpp.org/forum/#!searchin/std-proposals/scope/std-proposals/oACgySPOFzo/Kvjl=
Ysn9rIkJ<br>The idea has received mixed comments, mostly criticizing the la=
ck of real interest. This is something to keep in mind, as it is directly c=
onflicting your proposal. Finally, third, my personal feeling is that "cons=
t public:" can be misleading, because you would rather interpret it like in=
the proposal I linked just above, that is "all following member variables =
and functions are public and declared const". With this syntax, it is not c=
lear that the variable is actually mutable inside the class.<br><br>Like "c=
onst" and "mutable", I really think this should be tied to individual varia=
bles only. However, I am pretty certain that "readonly" is not going to wor=
k either, as this is a commonly used identifier today. My opinion is that i=
t is also misleading, as the variable is *not* read only inside the class. =
You can consider instead using a combination of existing keywords. For exam=
ple "this mutable", to be read: mutable by this class only. But this can be=
confusing as it has nothing to do with the semantic of the plain "mutable"=
keyword. Alternatively, "export const", to be read: exported as a constant=
, does not suffer from this problem (if you remove the "export" keyword, th=
e variable is just "const" to everyone, which is nice and predictable).<br>=
<br>I also like Matthew's idea about "using const ...;". It's a bit more ve=
rbose, but probably clearer and more versatile (good point about the "const=
public" but "mutable protected" case).<br>On a side note, the issue with y=
our production code (and Vile's suggestion) is that you have to store this =
reference inside the class, therefore wasting memory. That's probably not a=
big deal, but still.<br><br>Last point, on the declaration of a "readonly"=
member variable in private scope. Although this is not useful, it should n=
ot be ill-formed. It does not do any harm, and it will make things simpler =
if you decide, for some reason, to change the access scope from "protected"=
to "private".<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_838_192743526.1416518813845--
------=_Part_837_898508596.1416518813845--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Thu, 20 Nov 2014 16:29:20 -0500
Raw View
On Thu, Nov 20, 2014 at 4:22 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
> Lengthy code?
>
> class X
> {
> int private_x;
> public:
> const int& public_x = private_x;
> };
>
sizeof(X) = 16 on my machine.
Access might be optimizable, but the size is not as a data member.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
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: r.s.salkin@gmail.com
Date: Thu, 20 Nov 2014 14:24:56 -0800 (PST)
Raw View
------=_Part_7044_1585532606.1416522296558
Content-Type: multipart/alternative;
boundary="----=_Part_7045_47481450.1416522296565"
------=_Part_7045_47481450.1416522296565
Content-Type: text/plain; charset=UTF-8
Am Donnerstag, 20. November 2014 22:22:39 UTC+1 schrieb Ville Voutilainen:
>
>
> Lengthy code?
>
> class X
> {
> int private_x;
> public:
> const int& public_x = private_x;
> };
>
I must admit that I did not have this in mind when writing the post.
Also the following code has the same number of lines (even though it is
admittedly uglier):
class X
{
int private_x;
public:
const int& GetX() const { return private_x;};
};
I don't like both workarounds much. But I agree with the others that "const
public:" or "readonly" is probably not the best wording/keyword. It was
just the first thing coming to my mind.
--
---
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_7045_47481450.1416522296565
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Am Donnerstag, 20. November 2014 22:22:39 UTC+1 schrieb Vi=
lle Voutilainen:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Lengthy co=
de?
<br>
<br>class X
<br>{
<br> int private_x;
<br>public:
<br> const int& public_x =3D private_x;
<br>};
<br></blockquote><div><br>I must admit that I did not have this in mind whe=
n writing the post.<br><br>Also the following code has the same number of l=
ines (even though it is admittedly uglier):<br><br>class X
<br>{
<br> int private_x;
<br>public:
<br> const int& GetX() const { return private_x;};<br>};<b=
r><br>I don't like both workarounds much. But I agree with the others that =
"const public:" or "readonly" is probably not the best wording/keyword. It =
was just the first thing coming to my mind.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7045_47481450.1416522296565--
------=_Part_7044_1585532606.1416522296558--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Thu, 20 Nov 2014 14:36:00 -0800
Raw View
--001a1133ffd2e30f2f050851f310
Content-Type: text/plain; charset=UTF-8
On Thu, Nov 20, 2014 at 1:29 PM, Zhihao Yuan <zy@miator.net> wrote:
> On Thu, Nov 20, 2014 at 4:22 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> >
> > Lengthy code?
> >
> > class X
> > {
> > int private_x;
> > public:
> > const int& public_x = private_x;
> > };
> >
>
> sizeof(X) = 16 on my machine.
>
> Access might be optimizable, but the size is not as a data member.
A variant of the 'inline variables and encapsulated expressions' proposal
would allow this:
class X {
int private_x;
public:
using public_x = +private_x;
};
X x;
int a = x.public_x; // ok, means the same thing as 'int a = +x.private_x;'
but access check is done inside X.
--
---
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/.
--001a1133ffd2e30f2f050851f310
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 T=
hu, Nov 20, 2014 at 1:29 PM, Zhihao Yuan <span dir=3D"ltr"><<a href=3D"m=
ailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><span class=3D"">On Thu, Nov 20, 2014 at =
4:22 PM, Ville Voutilainen<br>
<<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.=
com</a>> wrote:<br>
><br>
> Lengthy code?<br>
><br>
> class X<br>
> {<br>
>=C2=A0 =C2=A0 =C2=A0int private_x;<br>
> public:<br>
>=C2=A0 =C2=A0 =C2=A0const int& public_x =3D private_x;<br>
> };<br>
><br>
<br>
</span>sizeof(X) =3D 16 on my machine.<br>
<br>
Access might be optimizable, but the size is not as a data member.</blockqu=
ote><div><br></div><div>A variant of the 'inline variables and encapsul=
ated expressions' proposal would allow this:</div><div><br></div><div>c=
lass X {</div><div>=C2=A0 int private_x;</div><div>public:</div><div>=C2=A0=
using public_x =3D +private_x;</div><div>};</div><div>X x;</div><div>int a=
=3D x.public_x; // ok, means the same thing as 'int a =3D +x.private_x=
;' but access check is done inside X.<br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
--001a1133ffd2e30f2f050851f310--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 20 Nov 2014 17:55:51 -0500
Raw View
On 2014-11-20 17:36, Richard Smith wrote:
> A variant of the 'inline variables and encapsulated expressions' proposal
> would allow this:
>
> class X {
> int private_x;
> public:
> using public_x = +private_x;
> };
> X x;
> int a = x.public_x; // ok, means the same thing as 'int a = +x.private_x;'
> but access check is done inside X.
How would you achieve this for a member of, say, a container type? (In
my specific case, I have something like std::vector<Bar>...)
--
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: corentin.schreiber@cea.fr
Date: Thu, 20 Nov 2014 15:15:54 -0800 (PST)
Raw View
------=_Part_7016_825991797.1416525354766
Content-Type: multipart/alternative;
boundary="----=_Part_7017_1109837971.1416525354766"
------=_Part_7017_1109837971.1416525354766
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le jeudi 20 novembre 2014 23:56:12 UTC+1, Matthew Woehlke a =C3=A9crit :
>
> On 2014-11-20 17:36, Richard Smith wrote:=20
> > A variant of the 'inline variables and encapsulated expressions'=20
> proposal=20
> > would allow this:=20
> >=20
> > class X {=20
> > int private_x;=20
> > public:=20
> > using public_x =3D +private_x;=20
> > };=20
> > X x;=20
> > int a =3D x.public_x; // ok, means the same thing as 'int a =3D=20
> +x.private_x;'=20
> > but access check is done inside X.=20
>
> How would you achieve this for a member of, say, a container type? (In=20
> my specific case, I have something like std::vector<Bar>...)=20
>
> --=20
> Matthew=20
>
>
using public_x =3D static_cast<const decltype(x)&>(private_x); ?=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_7017_1109837971.1416525354766
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le jeudi 20 novembre 2014 23:56:12 UTC+1, Matthew Woehlke =
a =C3=A9crit :<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-11-=
20 17:36, Richard Smith wrote:
<br>> A variant of the 'inline variables and encapsulated expressions' p=
roposal
<br>> would allow this:
<br>>=20
<br>> class X {
<br>> int private_x;
<br>> public:
<br>> using public_x =3D +private_x;
<br>> };
<br>> X x;
<br>> int a =3D x.public_x; // ok, means the same thing as 'int a =3D +x=
..private_x;'
<br>> but access check is done inside X.
<br>
<br>How would you achieve this for a member of, say, a container type? (In
<br>my specific case, I have something like std::vector<Bar>...)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div><br>using public_x =3D static_cast<const decltype(=
x)&>(private_x); ? <br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7017_1109837971.1416525354766--
------=_Part_7016_825991797.1416525354766--
.
Author: corentin.schreiber@cea.fr
Date: Thu, 20 Nov 2014 15:17:40 -0800 (PST)
Raw View
------=_Part_6905_1201651892.1416525460885
Content-Type: multipart/alternative;
boundary="----=_Part_6906_2129725851.1416525460891"
------=_Part_6906_2129725851.1416525460891
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le vendredi 21 novembre 2014 00:15:54 UTC+1, corentin....@cea.fr a =C3=A9cr=
it :
>
> Le jeudi 20 novembre 2014 23:56:12 UTC+1, Matthew Woehlke a =C3=A9crit :
>>
>> On 2014-11-20 17:36, Richard Smith wrote:=20
>> > A variant of the 'inline variables and encapsulated expressions'=20
>> proposal=20
>> > would allow this:=20
>> >=20
>> > class X {=20
>> > int private_x;=20
>> > public:=20
>> > using public_x =3D +private_x;=20
>> > };=20
>> > X x;=20
>> > int a =3D x.public_x; // ok, means the same thing as 'int a =3D=20
>> +x.private_x;'=20
>> > but access check is done inside X.=20
>>
>> How would you achieve this for a member of, say, a container type? (In=
=20
>> my specific case, I have something like std::vector<Bar>...)=20
>>
>> --=20
>> Matthew=20
>>
>>
> using public_x =3D static_cast<const decltype(x)&>(private_x); ?=20
>
Sorry, typing too fast:
using public_x =3D const_cast<const decltype(private_x)&>(private_x); ? =20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_6906_2129725851.1416525460891
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le vendredi 21 novembre 2014 00:15:54 UTC+1, corentin....@=
cea.fr a =C3=A9crit :<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">Le jeudi 20 novembre 2014 23:56:12 UTC+1, Matthew Woehlke a =
=C3=A9crit :<blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 2014-11-20 17:3=
6, Richard Smith wrote:
<br>> A variant of the 'inline variables and encapsulated expressions' p=
roposal
<br>> would allow this:
<br>>=20
<br>> class X {
<br>> int private_x;
<br>> public:
<br>> using public_x =3D +private_x;
<br>> };
<br>> X x;
<br>> int a =3D x.public_x; // ok, means the same thing as 'int a =3D +x=
..private_x;'
<br>> but access check is done inside X.
<br>
<br>How would you achieve this for a member of, say, a container type? (In
<br>my specific case, I have something like std::vector<Bar>...)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div><br>using public_x =3D static_cast<const decltype(=
x)&>(private_x); ? <br></div></div></blockquote><div><br>Sorry, typi=
ng too fast:<br>using public_x =3D const_cast<const decltype(private_x)&=
amp;>(private_x); ? <br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_6906_2129725851.1416525460891--
------=_Part_6905_1201651892.1416525460885--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 23 Nov 2014 12:54:51 +0800
Raw View
--Apple-Mail=_ACE1E484-A28E-493F-B317-29E2901156CB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On 2014=E2=80=9311=E2=80=9321, at 6:36 AM, Richard Smith <richard@metafoo.c=
o.uk> wrote:
> A variant of the 'inline variables and encapsulated expressions' proposal=
would allow this:
>=20
> class X {
> int private_x;
> public:
> using public_x =3D +private_x;
> };
=E2=80=A6
> using public_y =3D add_const(private_y);
Well, the original proposal would already, and without falling back on the =
arcane unary + operator or helper templates:
inline auto public_x =3D private_x;
inline auto const & public_y =3D private_y;
There were complaints about looking too much like (and being called) a vari=
able. But, nobody complained about declaring the type of the alias.
On 2014=E2=80=9311=E2=80=9323, at 1:51 AM, Ville Voutilainen <ville.voutila=
inen@gmail.com> wrote:
> That certainly looks interesting. As far as I understood it, David
> Krauss's inline-variable
> proposal met feedback according to which the inline-variable part was
> desirable, the
> expression-alias-like part less so.
Well, there didn=E2=80=99t seem to be a strong consensus about anything exc=
ept that it=E2=80=99s not a fruitful direction to pursue :P .
> Now, I must admit I don't give a rat's ass about inline variables as
> such. To me, the
> requirement of explicitly stating where the storage, if any, of a
> static/global variable
> (even if constexpr) lands is reasonable and teachable.
Well, the reason I attacked the problem for constexpr in particular is that=
it=E2=80=99s a matter of capability, not convenience or teachability. You =
cannot share an object with compile-time value between TUs, and that=E2=80=
=99s a major shortcoming. (Unless it=E2=80=99s a static class member or a v=
ariable template, which is crazy arcane.) However, this problem is potentia=
lly solved if you have any kind of alias for a constant expression. It=E2=
=80=99s a side-effect of having expression aliases supporting reference con=
stant expressions bound to temporaries, not a subcomponent of the proposal.
For things besides constant expressions, that doesn=E2=80=99t hold true.
> Being able to
> write expression
> aliases seems like a facility via which I can express abstractions I
> can't express today, without
> incurring overhead. So, Richard, are there any plans to proceed with such=
ideas?
To be clear, there=E2=80=99s no overhead if you can accept the function-cal=
l operator syntax. The alternatives involving references or implicit conver=
sions, which a library author may be forced into by legacy client code lack=
ing that operator, may involve runtime overhead.
On 2014=E2=80=9311=E2=80=9323, at 4:03 AM, Richard Smith <richard@metafoo.c=
o.uk> wrote:
> I think both features are valuable, and I'd be happy to write proposals f=
or both of them, if David isn't interested in doing so.
I don=E2=80=99t have plans to follow up by myself. However, my input contin=
ues to be that a syntactic slot for a declared type is essential in declari=
ng class interfaces.
Perhaps, I could persuade you to add that as an alternative syntax, between=
using and the declared name? This would essentially absorb my proposal. (G=
ive or take cryptic parenthesized declarators.)
using int public_x =3D private_x;
using Thing const & public_y =3D private_y;
using public_z =3D access_z();
--=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=_ACE1E484-A28E-493F-B317-29E2901156CB
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=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014=
=E2=80=9311=E2=80=9321, at 6:36 AM, Richard Smith <<a href=3D"mailto:ric=
hard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite"><div style=3D"font-fam=
ily: 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-spac=
e: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;=
"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><d=
iv>A variant of the 'inline variables and encapsulated expressions' proposa=
l would allow this:</div><div><br></div><div>class X {</div><div> int=
private_x;</div><div>public:</div><div> using public_x =3D +private_=
x;</div><div>};</div></div></div></div></div></blockquote><div>=E2=80=A6</d=
iv><div><blockquote type=3D"cite"> using public_y =3D add_const(priva=
te_y);</blockquote></div><div><br></div><div>Well, the original proposal wo=
uld already, and without falling back on the arcane unary + operator or hel=
per templates:</div><div><br></div><div><font face=3D"Courier">inline auto =
public_x =3D private_x;</font></div><div><font face=3D"Courier">inline auto=
const & public_y =3D private_y;</font></div><div><br></div><div>There =
were complaints about looking too much like (and being called) a variable. =
But, nobody complained about declaring the type of the alias.</div><div><br=
></div><div><br></div><div><div>On 2014=E2=80=9311=E2=80=9323, at 1:51 AM, =
Ville Voutilainen <<a href=3D"mailto:ville.voutilainen@gmail.com">ville.=
voutilainen@gmail.com</a>> wrote:</div><br class=3D"Apple-interchange-ne=
wline"><blockquote type=3D"cite">That certainly looks interesting. As far a=
s I understood it, David<br>Krauss's inline-variable<br>proposal met feedba=
ck according to which the inline-variable part was<br>desirable, the<br>exp=
ression-alias-like part less so.<br></blockquote><div><br></div><div>Well, =
there didn=E2=80=99t seem to be a strong consensus about anything except th=
at it=E2=80=99s not a fruitful direction to pursue :P .</div><div><br></div=
><div><blockquote type=3D"cite">Now, I must admit I don't give a rat's ass =
about inline variables as<br>such. To me, the<br>requirement of explicitly =
stating where the storage, if any, of a<br>static/global variable<br>(even =
if constexpr) lands is reasonable and teachable.</blockquote><div><br></div=
><div>Well, the reason I attacked the problem for constexpr in particular i=
s that it=E2=80=99s a matter of capability, not convenience or teachability=
.. You cannot share an object with compile-time value between TUs, and that=
=E2=80=99s a major shortcoming. (Unless it=E2=80=99s a static class member =
or a variable template, which is crazy arcane.) However, this problem is po=
tentially solved if you have any kind of alias for a constant expression. I=
t=E2=80=99s a side-effect of having expression aliases supporting reference=
constant expressions bound to temporaries, not a subcomponent of the propo=
sal.</div><div><br></div><div>For things besides constant expressions, that=
doesn=E2=80=99t hold true.</div><br><blockquote type=3D"cite">Being able t=
o<br>write expression<br>aliases seems like a facility via which I can expr=
ess abstractions I<br>can't express today, without<br>incurring overhead. S=
o, Richard, are there any plans to proceed with such ideas?</blockquote></d=
iv><div><br></div><div>To be clear, there=E2=80=99s no overhead if you can =
accept the function-call operator syntax. The alternatives involving refere=
nces or implicit conversions, which a library author may be forced into by =
legacy client code lacking that operator, may involve runtime overhead.</di=
v><div><br></div><div><br></div><div><div>On 2014=E2=80=9311=E2=80=9323, at=
4:03 AM, Richard Smith <<a href=3D"mailto:richard@metafoo.co.uk">richar=
d@metafoo.co.uk</a>> wrote:</div><br class=3D"Apple-interchange-newline"=
><blockquote type=3D"cite">I think both features are valuable, and I'd be h=
appy to write proposals for both of them, if David isn't interested in doin=
g so.</blockquote></div><div><br></div><div>I don=E2=80=99t have plans to f=
ollow up by myself. However, my input continues to be that a syntactic slot=
for a declared type is essential in declaring class interfaces.</div><div>=
<br></div><div>Perhaps, I could persuade you to add that as an alternative =
syntax, between <font face=3D"Courier">using</font> and the declared name? =
This would essentially absorb my proposal. (Give or take cryptic parenthesi=
zed declarators.)</div><div><br></div><div><div><font face=3D"Courier">usin=
g int public_x =3D private_x;</font></div><div><font face=3D"Courier">using=
Thing const & public_y =3D private_y;</font></div></div><div><font fac=
e=3D"Courier">using public_z =3D access_z();</font></div><div><br></div></d=
iv></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=_ACE1E484-A28E-493F-B317-29E2901156CB--
.
Author: sergeikrivonos@gmail.com
Date: Sun, 24 Dec 2017 23:23:41 -0800 (PST)
Raw View
------=_Part_14916_1726790615.1514186621128
Content-Type: multipart/alternative;
boundary="----=_Part_14917_910533774.1514186621128"
------=_Part_14917_910533774.1514186621128
Content-Type: text/plain; charset="UTF-8"
I am very agree with const modifiers for visibility and inheritance
specifiers.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a2005e3e-4e99-4fba-abfc-55401f7784ff%40isocpp.org.
------=_Part_14917_910533774.1514186621128
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I am very agree with const modifiers for visibility and in=
heritance specifiers.</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a2005e3e-4e99-4fba-abfc-55401f7784ff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a2005e3e-4e99-4fba-abfc-55401f7784ff=
%40isocpp.org</a>.<br />
------=_Part_14917_910533774.1514186621128--
------=_Part_14916_1726790615.1514186621128--
.
Author: olafvdspek@gmail.com
Date: Wed, 3 Jan 2018 02:38:05 -0800 (PST)
Raw View
------=_Part_41097_1015758264.1514975886010
Content-Type: multipart/alternative;
boundary="----=_Part_41098_2076070552.1514975886010"
------=_Part_41098_2076070552.1514975886010
Content-Type: text/plain; charset="UTF-8"
Op donderdag 20 november 2014 21:22:04 UTC+1 schreef r.s.s...@gmail.com:
>
> Why not introducing a keyword showing that a member variable can be
> altered within the class but not outside, still having read-access from
> outside?
>
This is, again, related to properties isn't it? ;)
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/65171bd9-4694-4baf-b460-9e30dcd9727e%40isocpp.org.
------=_Part_41098_2076070552.1514975886010
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Op donderdag 20 november 2014 21:22:04 UTC+1 schreef r.s.s=
....@gmail.com:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>Why not introducing a keyword showing that a member variable can be altere=
d within the class but not outside, still having read-access from outside?<=
br></div></blockquote><div><br></div><div>This is, again, related to proper=
ties isn't it? ;)</div><div><br></div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/65171bd9-4694-4baf-b460-9e30dcd9727e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/65171bd9-4694-4baf-b460-9e30dcd9727e=
%40isocpp.org</a>.<br />
------=_Part_41098_2076070552.1514975886010--
------=_Part_41097_1015758264.1514975886010--
.