Topic: Why doesn't C++ have const inheritance?
Author: Oleksandr Pikozh <o.pikozh@gmail.com>
Date: Fri, 19 Jan 2018 01:38:31 +0200
Raw View
Like this:
=C2=A0=C2=A0=C2=A0 struct A {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int original_member;
=C2=A0=C2=A0=C2=A0 };
=C2=A0=C2=A0=C2=A0 struct B: const A {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int added_member;
=C2=A0=C2=A0=C2=A0 };
This should mean that `B &` isn't type-cast-able to `A &`, but is=20
type-cast-able to `const A &`. This differs from declaring `B` with=20
having an instance of `A` declared just as a field (but not as ancestor)=20
and additionally having a type-case operator like `operator const A &()=20
const {return _a /*the field name*/;}`in the following aspects:
1. Instances of `B` allow access to (some of, see below) members of `A`=20
through `.` operator (e.g. `B b; std::cout << b.original_member`; and of=20
course instances of `B *` allow access to (some of, see below) members=20
of `A` through `->` operator).
2. Within `B` declaration, (some of, see below) virtual methods of `A`=20
can be overridden.
In general the rules are expected to be the following:
1. All non-static fields from `A` are inherited with usual visibility,=20
but making them effectively const.
2. All non-static const methods from `A` are inherited with usual=20
visibility.
3. All non-static non-const methods from `A` aren't allowed be called=20
from `B` (as `A` is effectively const-ed). They also aren't allowed to=20
be overridden within `B` with the `override` directive. Declaring within=20
`B` a virtual method with a signature similar to a such method in `A`=20
without `override` causes a new entry in VMT.
4. All static members are inherited with usual visibility.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5375ec95-89a6-0d4a-91ab-f06602089d97%40gmail.com=
..
.
Author: Todd Fleming <tbfleming@gmail.com>
Date: Thu, 18 Jan 2018 17:19:57 -0800 (PST)
Raw View
------=_Part_4331_1285234077.1516324797976
Content-Type: multipart/alternative;
boundary="----=_Part_4332_1100969854.1516324797976"
------=_Part_4332_1100969854.1516324797976
Content-Type: text/plain; charset="UTF-8"
On Thursday, January 18, 2018 at 6:40:19 PM UTC-5, Oleksandr Pikozh wrote:
>
> Like this:
>
> struct A {
> int original_member;
> };
> struct B: const A {
> int added_member;
> };
>
> This should mean that `B &` isn't type-cast-able to `A &`, but is
> type-cast-able to `const A &`. This differs from declaring `B` with
> having an instance of `A` declared just as a field (but not as ancestor)
> and additionally having a type-case operator like `operator const A &()
> const {return _a /*the field name*/;}`in the following aspects:
> 1. Instances of `B` allow access to (some of, see below) members of `A`
> through `.` operator (e.g. `B b; std::cout << b.original_member`; and of
> course instances of `B *` allow access to (some of, see below) members
> of `A` through `->` operator).
> 2. Within `B` declaration, (some of, see below) virtual methods of `A`
> can be overridden.
>
> In general the rules are expected to be the following:
> 1. All non-static fields from `A` are inherited with usual visibility,
> but making them effectively const.
> 2. All non-static const methods from `A` are inherited with usual
> visibility.
> 3. All non-static non-const methods from `A` aren't allowed be called
> from `B` (as `A` is effectively const-ed). They also aren't allowed to
> be overridden within `B` with the `override` directive. Declaring within
> `B` a virtual method with a signature similar to a such method in `A`
> without `override` causes a new entry in VMT.
> 4. All static members are inherited with usual visibility.
>
A common response to "Why Not?" in this forum is "Why?". Is there a lot of
code out there that this would simplify? Lambda functions, Modules,
Coroutines, the Spaceship Operator, and other features had to pass that
test.
Todd
--
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/1b22eaaf-1441-4bd2-8f1d-a54c58964b05%40isocpp.org.
------=_Part_4332_1100969854.1516324797976
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, January 18, 2018 at 6:40:19 PM UTC-5, Oleksan=
dr Pikozh wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Like this:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0 struct A {
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int original_member;
<br>=C2=A0=C2=A0=C2=A0=C2=A0 };
<br>=C2=A0=C2=A0=C2=A0=C2=A0 struct B: const A {
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int added_member;
<br>=C2=A0=C2=A0=C2=A0=C2=A0 };
<br>
<br>This should mean that `B &` isn't type-cast-able to `A &`, =
but is=20
<br>type-cast-able to `const A &`. This differs from declaring `B` with=
=20
<br>having an instance of `A` declared just as a field (but not as ancestor=
)=20
<br>and additionally having a type-case operator like `operator const A &am=
p;()=20
<br>const {return _a /*the field name*/;}`in the following aspects:
<br>1. Instances of `B` allow access to (some of, see below) members of `A`=
=20
<br>through `.` operator (e.g. `B b; std::cout << b.original_member`;=
and of=20
<br>course instances of `B *` allow access to (some of, see below) members=
=20
<br>of `A` through `->` operator).
<br>2. Within `B` declaration, (some of, see below) virtual methods of `A`=
=20
<br>can be overridden.
<br>
<br>In general the rules are expected to be the following:
<br>1. All non-static fields from `A` are inherited with usual visibility,=
=20
<br>but making them effectively const.
<br>2. All non-static const methods from `A` are inherited with usual=20
<br>visibility.
<br>3. All non-static non-const methods from `A` aren't allowed be call=
ed=20
<br>from `B` (as `A` is effectively const-ed). They also aren't allowed=
to=20
<br>be overridden within `B` with the `override` directive. Declaring withi=
n=20
<br>`B` a virtual method with a signature similar to a such method in `A`=
=20
<br>without `override` causes a new entry in VMT.
<br>4. All static members are inherited with usual visibility.
<br></blockquote><div><br></div><div>A common response to "Why Not?&qu=
ot; in this forum is "Why?". Is there a lot of code out there tha=
t this would simplify? Lambda functions, Modules, Coroutines, the Spaceship=
Operator, and other features had to pass that test.</div><div><br></div><d=
iv>Todd</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/1b22eaaf-1441-4bd2-8f1d-a54c58964b05%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1b22eaaf-1441-4bd2-8f1d-a54c58964b05=
%40isocpp.org</a>.<br />
------=_Part_4332_1100969854.1516324797976--
------=_Part_4331_1285234077.1516324797976--
.
Author: Oleksandr Pikozh <o.pikozh@gmail.com>
Date: Fri, 19 Jan 2018 10:03:34 +0200
Raw View
This is a multi-part message in MIME format.
--------------BFB9BC75A4B5B31E5ABF5448
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 19.01.18 03:19, Todd Fleming wrote:
> On Thursday, January 18, 2018 at 6:40:19 PM UTC-5, Oleksandr Pikozh=20
> wrote:
>
> Like this:
>
> =C2=A0=C2=A0=C2=A0=C2=A0 struct A {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int original_member;
> =C2=A0=C2=A0=C2=A0=C2=A0 };
> =C2=A0=C2=A0=C2=A0=C2=A0 struct B: const A {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int added_member;
> =C2=A0=C2=A0=C2=A0=C2=A0 };
>
> This should mean that `B &` isn't type-cast-able to `A &`, but is
> type-cast-able to `const A &`. This differs from declaring `B` with
> having an instance of `A` declared just as a field (but not as
> ancestor)
> and additionally having a type-case operator like `operator const
> A &()
> const {return _a /*the field name*/;}`in the following aspects:
> 1. Instances of `B` allow access to (some of, see below) members
> of `A`
> through `.` operator (e.g. `B b; std::cout << b.original_member`;
> and of
> course instances of `B *` allow access to (some of, see below)
> members
> of `A` through `->` operator).
> 2. Within `B` declaration, (some of, see below) virtual methods of
> `A`
> can be overridden.
>
> In general the rules are expected to be the following:
> 1. All non-static fields from `A` are inherited with usual
> visibility,
> but making them effectively const.
> 2. All non-static const methods from `A` are inherited with usual
> visibility.
> 3. All non-static non-const methods from `A` aren't allowed be called
> from `B` (as `A` is effectively const-ed). They also aren't
> allowed to
> be overridden within `B` with the `override` directive. Declaring
> within
> `B` a virtual method with a signature similar to a such method in `A`
> without `override` causes a new entry in VMT.
> 4. All static members are inherited with usual visibility.
>
>
> A common response to "Why Not?" in this forum is "Why?". Is there a=20
> lot of code out there that this would simplify? Lambda functions,=20
> Modules, Coroutines, the Spaceship Operator, and other features had to=20
> pass that test.
>
> Todd
Yep, you're right, this doesn't simplify a lot. It's more about making a=20
feature stack more complete and intuitive (i.e. if we have non typical=20
for other languages features (which partially eraseborder between=20
aggregation and inheritance) like protected and private inheritance,=20
then why not to go further (with erasing this border) with const=20
inheritance, why actually not to make every type (e.g. int) to be able=20
to act as ancestor), but it would be quite rarely used. So even I myself=20
don't consider this feature to be somehow near the beginning of the list=20
of missing C++ features (I personally wait for the "lambda structs"=20
(i.e. structs that=C2=A0 grab local context of the place of declaration and=
=20
can use it in their methods, extension of the `[&](=E2=80=A6){}` feature) f=
or=20
the most now).
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/bfb2b93c-480a-788e-4383-9d04ce59689c%40gmail.com=
..
--------------BFB9BC75A4B5B31E5ABF5448
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
On 19.01.18 03:19, Todd Fleming wrote:<br>
<blockquote type=3D"cite"
cite=3D"mid:1b22eaaf-1441-4bd2-8f1d-a54c58964b05@isocpp.org">
<div dir=3D"ltr">On Thursday, January 18, 2018 at 6:40:19 PM UTC-5,
Oleksandr Pikozh wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Like
this:
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 struct A {
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int original_mem=
ber;
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 };
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 struct B: const A {
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int added_member=
;
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 };
<br>
<br>
This should mean that `B &` isn't type-cast-able to `A
&`, but is <br>
type-cast-able to `const A &`. This differs from declaring
`B` with <br>
having an instance of `A` declared just as a field (but not as
ancestor) <br>
and additionally having a type-case operator like `operator
const A &() <br>
const {return _a /*the field name*/;}`in the following
aspects:
<br>
1. Instances of `B` allow access to (some of, see below)
members of `A` <br>
through `.` operator (e.g. `B b; std::cout <<
b.original_member`; and of <br>
course instances of `B *` allow access to (some of, see below)
members <br>
of `A` through `->` operator).
<br>
2. Within `B` declaration, (some of, see below) virtual
methods of `A` <br>
can be overridden.
<br>
<br>
In general the rules are expected to be the following:
<br>
1. All non-static fields from `A` are inherited with usual
visibility, <br>
but making them effectively const.
<br>
2. All non-static const methods from `A` are inherited with
usual <br>
visibility.
<br>
3. All non-static non-const methods from `A` aren't allowed be
called <br>
from `B` (as `A` is effectively const-ed). They also aren't
allowed to <br>
be overridden within `B` with the `override` directive.
Declaring within <br>
`B` a virtual method with a signature similar to a such method
in `A` <br>
without `override` causes a new entry in VMT.
<br>
4. All static members are inherited with usual visibility.
<br>
</blockquote>
<div><br>
</div>
<div>A common response to "Why Not?" in this forum is "Why?". Is
there a lot of code out there that this would simplify? Lambda
functions, Modules, Coroutines, the Spaceship Operator, and
other features had to pass that test.</div>
<div><br>
</div>
<div>Todd</div>
</div>
</blockquote>
<br>
Yep, you're right, this doesn't simplify a lot. It's more about
making a feature stack more complete and intuitive (i.e. if we have
non typical for other languages features (which partially erase<span
id=3D"result_box" class=3D"short_text" lang=3D"en"><span class=3D"">
border</span></span> between aggregation and inheritance) like
protected and private inheritance, then why not to go further (with
erasing this <span id=3D"result_box" class=3D"short_text" lang=3D"en"><=
span
class=3D"">border</span></span>) with const inheritance, why
actually not to make every type (e.g. int) to be able to act as
ancestor), but it would be quite rarely used. So even I myself don't
consider this feature to be somehow near the beginning of the list
of missing C++ features (I personally wait for the "lambda structs"
(i.e. structs that=C2=A0 grab local context of the place of declaration
and can use it in their methods, extension of the `[&](=E2=80=A6){}=
`
feature) for the most now).<br>
</body>
</html>
<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/bfb2b93c-480a-788e-4383-9d04ce59689c%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bfb2b93c-480a-788e-4383-9d04ce59689c%=
40gmail.com</a>.<br />
--------------BFB9BC75A4B5B31E5ABF5448--
.
Author: Cleiton Santoia <cleitonsantoia@gmail.com>
Date: Sun, 21 Jan 2018 17:44:30 -0800 (PST)
Raw View
------=_Part_3436_406776290.1516585470685
Content-Type: multipart/alternative;
boundary="----=_Part_3437_281531527.1516585470686"
------=_Part_3437_281531527.1516585470686
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Consider
struct A {
int x;
int y;
A(int x_) : x(x_) {} // constructor does not initialize y
};
struct B: const A { // how initialize A::y ?
=20
};
How would you construct the "const" part of A ?
Em sexta-feira, 19 de janeiro de 2018 06:04:10 UTC-2, Oleksandr Pikozh=20
escreveu:
>
> On 19.01.18 03:19, Todd Fleming wrote:
>
> On Thursday, January 18, 2018 at 6:40:19 PM UTC-5, Oleksandr Pikozh wrote=
:=20
>>
>> Like this:=20
>>
>> struct A {=20
>> int original_member;=20
>> };=20
>> struct B: const A {=20
>> int added_member;=20
>> };=20
>>
>> This should mean that `B &` isn't type-cast-able to `A &`, but is=20
>> type-cast-able to `const A &`. This differs from declaring `B` with=20
>> having an instance of `A` declared just as a field (but not as ancestor)=
=20
>> and additionally having a type-case operator like `operator const A &()=
=20
>> const {return _a /*the field name*/;}`in the following aspects:=20
>> 1. Instances of `B` allow access to (some of, see below) members of `A`=
=20
>> through `.` operator (e.g. `B b; std::cout << b.original_member`; and of=
=20
>> course instances of `B *` allow access to (some of, see below) members=
=20
>> of `A` through `->` operator).=20
>> 2. Within `B` declaration, (some of, see below) virtual methods of `A`=
=20
>> can be overridden.=20
>>
>> In general the rules are expected to be the following:=20
>> 1. All non-static fields from `A` are inherited with usual visibility,=
=20
>> but making them effectively const.=20
>> 2. All non-static const methods from `A` are inherited with usual=20
>> visibility.=20
>> 3. All non-static non-const methods from `A` aren't allowed be called=20
>> from `B` (as `A` is effectively const-ed). They also aren't allowed to=
=20
>> be overridden within `B` with the `override` directive. Declaring within=
=20
>> `B` a virtual method with a signature similar to a such method in `A`=20
>> without `override` causes a new entry in VMT.=20
>> 4. All static members are inherited with usual visibility.=20
>>
>
> A common response to "Why Not?" in this forum is "Why?". Is there a lot o=
f=20
> code out there that this would simplify? Lambda functions, Modules,=20
> Coroutines, the Spaceship Operator, and other features had to pass that=
=20
> test.
>
> Todd
>
>
> Yep, you're right, this doesn't simplify a lot. It's more about making a=
=20
> feature stack more complete and intuitive (i.e. if we have non typical fo=
r=20
> other languages features (which partially erase border between=20
> aggregation and inheritance) like protected and private inheritance, then=
=20
> why not to go further (with erasing this border) with const inheritance,=
=20
> why actually not to make every type (e.g. int) to be able to act as=20
> ancestor), but it would be quite rarely used. So even I myself don't=20
> consider this feature to be somehow near the beginning of the list of=20
> missing C++ features (I personally wait for the "lambda structs" (i.e.=20
> structs that grab local context of the place of declaration and can use =
it=20
> in their methods, extension of the `[&](=E2=80=A6){}` feature) for the mo=
st now).
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/de685e29-1144-4991-bde8-f1a3d837b26f%40isocpp.or=
g.
------=_Part_3437_281531527.1516585470686
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Consider<br></div><div><br></div><div><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><font colo=
r=3D"#660066"><span style=3D"color: #008;" class=3D"styled-by-prettify">str=
uct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> A </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> y</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>=C2=A0 A</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x_</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">x_</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{}</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">// constructor does not in=
itialize y</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> B</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> A </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> =C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-prett=
ify">// how initialize A::y ?</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 <br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">};</span></font></div></code></div><br>How would yo=
u construct the "const" part of A ?<br></div><br>Em sexta-feira, =
19 de janeiro de 2018 06:04:10 UTC-2, Oleksandr Pikozh escreveu:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
On 19.01.18 03:19, Todd Fleming wrote:<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Thursday, January 18, 2018 at 6:40:19 PM UTC-5,
Oleksandr Pikozh wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">Like
this:
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 struct A {
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int original_mem=
ber;
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 };
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 struct B: const A {
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int added_member=
;
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 };
<br>
<br>
This should mean that `B &` isn't type-cast-able to `A
&`, but is <br>
type-cast-able to `const A &`. This differs from declaring
`B` with <br>
having an instance of `A` declared just as a field (but not as
ancestor) <br>
and additionally having a type-case operator like `operator
const A &() <br>
const {return _a /*the field name*/;}`in the following
aspects:
<br>
1. Instances of `B` allow access to (some of, see below)
members of `A` <br>
through `.` operator (e.g. `B b; std::cout <<
b.original_member`; and of <br>
course instances of `B *` allow access to (some of, see below)
members <br>
of `A` through `->` operator).
<br>
2. Within `B` declaration, (some of, see below) virtual
methods of `A` <br>
can be overridden.
<br>
<br>
In general the rules are expected to be the following:
<br>
1. All non-static fields from `A` are inherited with usual
visibility, <br>
but making them effectively const.
<br>
2. All non-static const methods from `A` are inherited with
usual <br>
visibility.
<br>
3. All non-static non-const methods from `A` aren't allowed b=
e
called <br>
from `B` (as `A` is effectively const-ed). They also aren't
allowed to <br>
be overridden within `B` with the `override` directive.
Declaring within <br>
`B` a virtual method with a signature similar to a such method
in `A` <br>
without `override` causes a new entry in VMT.
<br>
4. All static members are inherited with usual visibility.
<br>
</blockquote>
<div><br>
</div>
<div>A common response to "Why Not?" in this forum is &qu=
ot;Why?". Is
there a lot of code out there that this would simplify? Lambda
functions, Modules, Coroutines, the Spaceship Operator, and
other features had to pass that test.</div>
<div><br>
</div>
<div>Todd</div>
</div>
</blockquote>
<br>
Yep, you're right, this doesn't simplify a lot. It's more a=
bout
making a feature stack more complete and intuitive (i.e. if we have
non typical for other languages features (which partially erase<span la=
ng=3D"en"><span>
border</span></span> between aggregation and inheritance) like
protected and private inheritance, then why not to go further (with
erasing this <span lang=3D"en"><span>border</span></span>) with const i=
nheritance, why
actually not to make every type (e.g. int) to be able to act as
ancestor), but it would be quite rarely used. So even I myself don'=
t
consider this feature to be somehow near the beginning of the list
of missing C++ features (I personally wait for the "lambda structs=
"
(i.e. structs that=C2=A0 grab local context of the place of declaration
and can use it in their methods, extension of the `[&](=E2=80=A6){}=
`
feature) for the most now).<br>
</div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/de685e29-1144-4991-bde8-f1a3d837b26f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/de685e29-1144-4991-bde8-f1a3d837b26f=
%40isocpp.org</a>.<br />
------=_Part_3437_281531527.1516585470686--
------=_Part_3436_406776290.1516585470685--
.
Author: Brian Bi <bbi5291@gmail.com>
Date: Sun, 21 Jan 2018 17:46:13 -0800
Raw View
--001a11352e126779370563539853
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
You would have the same issue with a `const A` non-static member, and yet
that's allowed.
On Sun, Jan 21, 2018 at 5:44 PM, Cleiton Santoia <cleitonsantoia@gmail.com>
wrote:
> Consider
>
> struct A {
> int x;
> int y;
> A(int x_) : x(x_) {} // constructor does not initialize y
> };
>
> struct B: const A { // how initialize A::y ?
>
> };
>
> How would you construct the "const" part of A ?
>
> Em sexta-feira, 19 de janeiro de 2018 06:04:10 UTC-2, Oleksandr Pikozh
> escreveu:
>>
>> On 19.01.18 03:19, Todd Fleming wrote:
>>
>> On Thursday, January 18, 2018 at 6:40:19 PM UTC-5, Oleksandr Pikozh
>> wrote:
>>>
>>> Like this:
>>>
>>> struct A {
>>> int original_member;
>>> };
>>> struct B: const A {
>>> int added_member;
>>> };
>>>
>>> This should mean that `B &` isn't type-cast-able to `A &`, but is
>>> type-cast-able to `const A &`. This differs from declaring `B` with
>>> having an instance of `A` declared just as a field (but not as ancestor=
)
>>> and additionally having a type-case operator like `operator const A &()
>>> const {return _a /*the field name*/;}`in the following aspects:
>>> 1. Instances of `B` allow access to (some of, see below) members of `A`
>>> through `.` operator (e.g. `B b; std::cout << b.original_member`; and o=
f
>>> course instances of `B *` allow access to (some of, see below) members
>>> of `A` through `->` operator).
>>> 2. Within `B` declaration, (some of, see below) virtual methods of `A`
>>> can be overridden.
>>>
>>> In general the rules are expected to be the following:
>>> 1. All non-static fields from `A` are inherited with usual visibility,
>>> but making them effectively const.
>>> 2. All non-static const methods from `A` are inherited with usual
>>> visibility.
>>> 3. All non-static non-const methods from `A` aren't allowed be called
>>> from `B` (as `A` is effectively const-ed). They also aren't allowed to
>>> be overridden within `B` with the `override` directive. Declaring withi=
n
>>> `B` a virtual method with a signature similar to a such method in `A`
>>> without `override` causes a new entry in VMT.
>>> 4. All static members are inherited with usual visibility.
>>>
>>
>> A common response to "Why Not?" in this forum is "Why?". Is there a lot
>> of code out there that this would simplify? Lambda functions, Modules,
>> Coroutines, the Spaceship Operator, and other features had to pass that
>> test.
>>
>> Todd
>>
>>
>> Yep, you're right, this doesn't simplify a lot. It's more about making a
>> feature stack more complete and intuitive (i.e. if we have non typical f=
or
>> other languages features (which partially erase border between
>> aggregation and inheritance) like protected and private inheritance, the=
n
>> why not to go further (with erasing this border) with const inheritance,
>> why actually not to make every type (e.g. int) to be able to act as
>> ancestor), but it would be quite rarely used. So even I myself don't
>> consider this feature to be somehow near the beginning of the list of
>> missing C++ features (I personally wait for the "lambda structs" (i.e.
>> structs that grab local context of the place of declaration and can use=
it
>> in their methods, extension of the `[&](=E2=80=A6){}` feature) for the m=
ost now).
>>
> --
> 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/de685e29-1144-4991-
> bde8-f1a3d837b26f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/de685e29-11=
44-4991-bde8-f1a3d837b26f%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
*Brian Bi*
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAMmfjbOZ%2BsXzN0wv0AP7zUywtrDhL7Hyo8i2E0JAZoQ%2=
BmqwQAA%40mail.gmail.com.
--001a11352e126779370563539853
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You would have the same issue with a `const A` non-static =
member, and yet that's allowed.<br><div><div><div><div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Sun, Jan 21, 2018 at 5:44 PM, =
Cleiton Santoia <span dir=3D"ltr"><<a href=3D"mailto:cleitonsantoia@gmai=
l.com" target=3D"_blank">cleitonsantoia@gmail.com</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Consider<br></div><div=
><br></div><div><div class=3D"m_3759043583166119104prettyprint" style=3D"ba=
ckground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:=
solid;border-width:1px;word-wrap:break-word"><code class=3D"m_3759043583166=
119104prettyprint"><div class=3D"m_3759043583166119104subprettyprint"><font=
color=3D"#660066"><span style=3D"color:#008" class=3D"m_375904358316611910=
4styled-by-prettify">struct</span><span style=3D"color:#000" class=3D"m_375=
9043583166119104styled-by-prettify"> A </span><span style=3D"color:#660" cl=
ass=3D"m_3759043583166119104styled-by-prettify">{</span><span style=3D"colo=
r:#000" class=3D"m_3759043583166119104styled-by-prettify"><br>=C2=A0 </span=
><span style=3D"color:#008" class=3D"m_3759043583166119104styled-by-prettif=
y">int</span><span style=3D"color:#000" class=3D"m_3759043583166119104style=
d-by-prettify"> x</span><span style=3D"color:#660" class=3D"m_3759043583166=
119104styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_375=
9043583166119104styled-by-prettify"><br>=C2=A0 </span><span style=3D"color:=
#008" class=3D"m_3759043583166119104styled-by-prettify">int</span><span sty=
le=3D"color:#000" class=3D"m_3759043583166119104styled-by-prettify"> y</spa=
n><span style=3D"color:#660" class=3D"m_3759043583166119104styled-by-pretti=
fy">;</span><span style=3D"color:#000" class=3D"m_3759043583166119104styled=
-by-prettify"><br>=C2=A0 A</span><span style=3D"color:#660" class=3D"m_3759=
043583166119104styled-by-prettify">(</span><span style=3D"color:#008" class=
=3D"m_3759043583166119104styled-by-prettify">int</span><span style=3D"color=
:#000" class=3D"m_3759043583166119104styled-by-prettify"> x_</span><span st=
yle=3D"color:#660" class=3D"m_3759043583166119104styled-by-prettify">)</spa=
n><span style=3D"color:#000" class=3D"m_3759043583166119104styled-by-pretti=
fy"> </span><span style=3D"color:#660" class=3D"m_3759043583166119104styled=
-by-prettify">:</span><span style=3D"color:#000" class=3D"m_375904358316611=
9104styled-by-prettify"> x</span><span style=3D"color:#660" class=3D"m_3759=
043583166119104styled-by-prettify">(</span><span style=3D"color:#000" class=
=3D"m_3759043583166119104styled-by-prettify">x_</span><span style=3D"color:=
#660" class=3D"m_3759043583166119104styled-by-prettify">)</span><span style=
=3D"color:#000" class=3D"m_3759043583166119104styled-by-prettify"> </span><=
span style=3D"color:#660" class=3D"m_3759043583166119104styled-by-prettify"=
>{}</span><span style=3D"color:#000" class=3D"m_3759043583166119104styled-b=
y-prettify"> </span><span style=3D"color:#800" class=3D"m_37590435831661191=
04styled-by-prettify">// constructor does not initialize y</span><span styl=
e=3D"color:#000" class=3D"m_3759043583166119104styled-by-prettify"><br></sp=
an><span style=3D"color:#660" class=3D"m_3759043583166119104styled-by-prett=
ify">};</span><span style=3D"color:#000" class=3D"m_3759043583166119104styl=
ed-by-prettify"><br><br></span><span style=3D"color:#008" class=3D"m_375904=
3583166119104styled-by-prettify">struct</span><span style=3D"color:#000" cl=
ass=3D"m_3759043583166119104styled-by-prettify"> B</span><span style=3D"col=
or:#660" class=3D"m_3759043583166119104styled-by-prettify">:</span><span st=
yle=3D"color:#000" class=3D"m_3759043583166119104styled-by-prettify"> </spa=
n><span style=3D"color:#008" class=3D"m_3759043583166119104styled-by-pretti=
fy">const</span><span style=3D"color:#000" class=3D"m_3759043583166119104st=
yled-by-prettify"> A </span><span style=3D"color:#660" class=3D"m_375904358=
3166119104styled-by-prettify">{</span><span style=3D"color:#000" class=3D"m=
_3759043583166119104styled-by-prettify"> =C2=A0</span><span style=3D"color:=
#800" class=3D"m_3759043583166119104styled-by-prettify">// how initialize A=
::y ?</span><span style=3D"color:#000" class=3D"m_3759043583166119104styled=
-by-prettify"><br>=C2=A0 <br></span><span style=3D"color:#660" class=3D"m_3=
759043583166119104styled-by-prettify">};</span></font></div></code></div><b=
r>How would you construct the "const" part of A ?<br></div><div><=
div class=3D"h5"><br>Em sexta-feira, 19 de janeiro de 2018 06:04:10 UTC-2, =
Oleksandr Pikozh escreveu:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
On 19.01.18 03:19, Todd Fleming wrote:<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Thursday, January 18, 2018 at 6:40:19 PM UTC-5,
Oleksandr Pikozh wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">Like
this:
<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 struct A {
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int original_mem=
ber;
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 };
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 struct B: const A {
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int added_member=
;
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 };
<br>
<br>
This should mean that `B &` isn't type-cast-able to `A
&`, but is <br>
type-cast-able to `const A &`. This differs from declaring
`B` with <br>
having an instance of `A` declared just as a field (but not as
ancestor) <br>
and additionally having a type-case operator like `operator
const A &() <br>
const {return _a /*the field name*/;}`in the following
aspects:
<br>
1. Instances of `B` allow access to (some of, see below)
members of `A` <br>
through `.` operator (e.g. `B b; std::cout <<
b.original_member`; and of <br>
course instances of `B *` allow access to (some of, see below)
members <br>
of `A` through `->` operator).
<br>
2. Within `B` declaration, (some of, see below) virtual
methods of `A` <br>
can be overridden.
<br>
<br>
In general the rules are expected to be the following:
<br>
1. All non-static fields from `A` are inherited with usual
visibility, <br>
but making them effectively const.
<br>
2. All non-static const methods from `A` are inherited with
usual <br>
visibility.
<br>
3. All non-static non-const methods from `A` aren't allowed b=
e
called <br>
from `B` (as `A` is effectively const-ed). They also aren't
allowed to <br>
be overridden within `B` with the `override` directive.
Declaring within <br>
`B` a virtual method with a signature similar to a such method
in `A` <br>
without `override` causes a new entry in VMT.
<br>
4. All static members are inherited with usual visibility.
<br>
</blockquote>
<div><br>
</div>
<div>A common response to "Why Not?" in this forum is &qu=
ot;Why?". Is
there a lot of code out there that this would simplify? Lambda
functions, Modules, Coroutines, the Spaceship Operator, and
other features had to pass that test.</div>
<div><br>
</div>
<div>Todd</div>
</div>
</blockquote>
<br>
Yep, you're right, this doesn't simplify a lot. It's more a=
bout
making a feature stack more complete and intuitive (i.e. if we have
non typical for other languages features (which partially erase<span la=
ng=3D"en"><span>
border</span></span> between aggregation and inheritance) like
protected and private inheritance, then why not to go further (with
erasing this <span lang=3D"en"><span>border</span></span>) with const i=
nheritance, why
actually not to make every type (e.g. int) to be able to act as
ancestor), but it would be quite rarely used. So even I myself don'=
t
consider this feature to be somehow near the beginning of the list
of missing C++ features (I personally wait for the "lambda structs=
"
(i.e. structs that=C2=A0 grab local context of the place of declaration
and can use it in their methods, extension of the `[&](=E2=80=A6){}=
`
feature) for the most now).<br>
</div>
</blockquote></div></div></div><div><div class=3D"h5">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/de685e29-1144-4991-bde8-f1a3d837b26f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/de68=
5e29-1144-4991-<wbr>bde8-f1a3d837b26f%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=
=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i></font><br><div></div><div>=
</div><div></div></div></div></div></div>
</div></div></div></div></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/CAMmfjbOZ%2BsXzN0wv0AP7zUywtrDhL7Hyo8=
i2E0JAZoQ%2BmqwQAA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbOZ%2Bs=
XzN0wv0AP7zUywtrDhL7Hyo8i2E0JAZoQ%2BmqwQAA%40mail.gmail.com</a>.<br />
--001a11352e126779370563539853--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Sun, 21 Jan 2018 22:48:30 -0300
Raw View
--94eb2c062d509fde27056353a05b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1465.pdf
(See the date :) )
Bjarne asked: "is there a large set of problems for what this is a
solution?" In that moment, my answer was "not that big", but with the years
I found myself needing this issue.
El ene. 18, 2018 22:20, "Todd Fleming" <tbfleming@gmail.com> escribi=C3=B3:
> On Thursday, January 18, 2018 at 6:40:19 PM UTC-5, Oleksandr Pikozh wrote=
:
>>
>> Like this:
>>
>> struct A {
>> int original_member;
>> };
>> struct B: const A {
>> int added_member;
>> };
>>
>> This should mean that `B &` isn't type-cast-able to `A &`, but is
>> type-cast-able to `const A &`. This differs from declaring `B` with
>> having an instance of `A` declared just as a field (but not as ancestor)
>> and additionally having a type-case operator like `operator const A &()
>> const {return _a /*the field name*/;}`in the following aspects:
>> 1. Instances of `B` allow access to (some of, see below) members of `A`
>> through `.` operator (e.g. `B b; std::cout << b.original_member`; and of
>> course instances of `B *` allow access to (some of, see below) members
>> of `A` through `->` operator).
>> 2. Within `B` declaration, (some of, see below) virtual methods of `A`
>> can be overridden.
>>
>> In general the rules are expected to be the following:
>> 1. All non-static fields from `A` are inherited with usual visibility,
>> but making them effectively const.
>> 2. All non-static const methods from `A` are inherited with usual
>> visibility.
>> 3. All non-static non-const methods from `A` aren't allowed be called
>> from `B` (as `A` is effectively const-ed). They also aren't allowed to
>> be overridden within `B` with the `override` directive. Declaring within
>> `B` a virtual method with a signature similar to a such method in `A`
>> without `override` causes a new entry in VMT.
>> 4. All static members are inherited with usual visibility.
>>
>
> A common response to "Why Not?" in this forum is "Why?". Is there a lot o=
f
> code out there that this would simplify? Lambda functions, Modules,
> Coroutines, the Spaceship Operator, and other features had to pass that
> test.
>
> Todd
>
> --
> 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/1b22eaaf-1441-4bd2-
> 8f1d-a54c58964b05%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1b22eaaf-14=
41-4bd2-8f1d-a54c58964b05%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-2P9bJbiPJa4FPajJ96HSs4F0zfAWNHj5mfobgQ6fC=
BTw%40mail.gmail.com.
--94eb2c062d509fde27056353a05b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pa=
pers/2003/n1465.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/200=
3/n1465.pdf</a><div dir=3D"auto"><br></div><div dir=3D"auto">(See the date =
:) )</div><div dir=3D"auto"><br></div><div dir=3D"auto">Bjarne asked: "=
;is there a large set of problems for what this is a solution?" In tha=
t moment, my answer was "not that big", but with the years I foun=
d myself needing this issue.</div></div><div class=3D"gmail_extra"><br><div=
class=3D"gmail_quote">El ene. 18, 2018 22:20, "Todd Fleming" <=
;<a href=3D"mailto:tbfleming@gmail.com">tbfleming@gmail.com</a>> escribi=
=C3=B3:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr">On Thursday, January 18, 2018 at 6:40:19 PM UTC-5, Oleksandr Pikozh wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">Like this:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0 struct A {
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int original_member;
<br>=C2=A0=C2=A0=C2=A0=C2=A0 };
<br>=C2=A0=C2=A0=C2=A0=C2=A0 struct B: const A {
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int added_member;
<br>=C2=A0=C2=A0=C2=A0=C2=A0 };
<br>
<br>This should mean that `B &` isn't type-cast-able to `A &`, =
but is=20
<br>type-cast-able to `const A &`. This differs from declaring `B` with=
=20
<br>having an instance of `A` declared just as a field (but not as ancestor=
)=20
<br>and additionally having a type-case operator like `operator const A &am=
p;()=20
<br>const {return _a /*the field name*/;}`in the following aspects:
<br>1. Instances of `B` allow access to (some of, see below) members of `A`=
=20
<br>through `.` operator (e.g. `B b; std::cout << b.original_member`;=
and of=20
<br>course instances of `B *` allow access to (some of, see below) members=
=20
<br>of `A` through `->` operator).
<br>2. Within `B` declaration, (some of, see below) virtual methods of `A`=
=20
<br>can be overridden.
<br>
<br>In general the rules are expected to be the following:
<br>1. All non-static fields from `A` are inherited with usual visibility,=
=20
<br>but making them effectively const.
<br>2. All non-static const methods from `A` are inherited with usual=20
<br>visibility.
<br>3. All non-static non-const methods from `A` aren't allowed be call=
ed=20
<br>from `B` (as `A` is effectively const-ed). They also aren't allowed=
to=20
<br>be overridden within `B` with the `override` directive. Declaring withi=
n=20
<br>`B` a virtual method with a signature similar to a such method in `A`=
=20
<br>without `override` causes a new entry in VMT.
<br>4. All static members are inherited with usual visibility.
<br></blockquote><div><br></div><div>A common response to "Why Not?&qu=
ot; in this forum is "Why?". Is there a lot of code out there tha=
t this would simplify? Lambda functions, Modules, Coroutines, the Spaceship=
Operator, and other features had to pass that test.</div><div><br></div><d=
iv>Todd</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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1b22eaaf-1441-4bd2-8f1d-a54c58964b05%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/1b22=
eaaf-1441-4bd2-<wbr>8f1d-a54c58964b05%40isocpp.org</a><wbr>.<br>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2P9bJbiPJa4FPajJ96HSs4F0zfAWNH=
j5mfobgQ6fCBTw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2P9bJbiPJa=
4FPajJ96HSs4F0zfAWNHj5mfobgQ6fCBTw%40mail.gmail.com</a>.<br />
--94eb2c062d509fde27056353a05b--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 22 Jan 2018 04:24:35 +0200
Raw View
On 22 January 2018 at 03:48, dgutson . <danielgutson@gmail.com> wrote:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1465.pdf
>
> (See the date :) )
>
> Bjarne asked: "is there a large set of problems for what this is a
> solution?" In that moment, my answer was "not that big", but with the years
> I found myself needing this issue.
There's a more recent attempt at
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0277r1.pdf
but EWG didn't have any support for it. There was a suggestion that
the motivation
needs to be better, which doesn't mean more motivation, it means
better motivation.
--
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/CAFk2RUaYr8eZ6Mm%2BnVeqH7wPqBzX0iEny_tOzZErgRCtvvz8iw%40mail.gmail.com.
.
Author: brian.gloyer@gmail.com
Date: Sat, 17 Feb 2018 13:55:17 -0800 (PST)
Raw View
------=_Part_7312_484832167.1518904517770
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
This could solve some of the Square - Rectangle type problems.
class Square: public const Rectangle {
public:
Square(double size);
void doubleArea();
};
Clients would be prevened from modifying the Square through the Rectangle i=
nterface (Which could make it not square). However Square itself should be=
allowed to modify Rectangle. A client could call doubleArea() which would=
increase both dimensions equally. A Square is-a const Rectangle.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b1cd3941-e3b3-45d8-b6f0-fbc4241d8fd8%40isocpp.or=
g.
------=_Part_7312_484832167.1518904517770--
.
Author: brian.gloyer@gmail.com
Date: Sun, 18 Feb 2018 14:38:50 -0800 (PST)
Raw View
------=_Part_10227_1476843916.1518993530481
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Yes, that is what I want but I'd like it all in one step. Actually steps 1=
and 3 are fine now but step 2 is a maintenance problem because there is no=
easy way to do the `using`. It could be called "public const interface in=
heritance with private non-const implementation inheritance" which would ne=
ed to be shortened. I don't agree that const inheritance should require th=
e base to be treated like a const member but based on the other comments in=
this thread I may be alone with this thinking. I see it as the derived ha=
s a full non-const base but only exposes the base's const interface.
My main point was to give an example of "why" const inheritance would be us=
eful. It could be a tool for the classic Square-Rectangle problem which do=
esnt have a clean C++ (or Java, C#, etc) solution.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7d751be7-0501-4d2c-928e-8d7182d1bce9%40isocpp.or=
g.
------=_Part_10227_1476843916.1518993530481--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Sun, 18 Feb 2018 23:08:12 +0000
Raw View
--001a114127d6d89a4a056584a6dd
Content-Type: text/plain; charset="UTF-8"
On 18 Feb 2018 22:38, <brian.gloyer@gmail.com> wrote:
It could be a tool for the classic Square-Rectangle problem which doesnt
have a clean C++ (or Java, C#, etc) solution.
It doesn't have a solution because it is not a problem in code, it is a
problem in coders. They misunderstand the verb "to be". A square is a
rectangle in the mathematical subset sense, NOT the behaviour sense (you
can elongate a rectangle, not a square, therefore the square doesn't quack
like a rectangle). If you want to describe the subset sense, OOP is the
wrong tool for the job because of the reasons I outlined.
--
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/CAC%2B0CCPjH-kHWmo0VBbT_tKoz7H4y8XRkYY8hsxC%3DRC0esbOBg%40mail.gmail.com.
--001a114127d6d89a4a056584a6dd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 18 Feb 2018 22:38, <<a href=3D"mailto:brian.gloyer@gmail.c=
om">brian.gloyer@gmail.com</a>> wrote:<br type=3D"attribution"><blockquo=
te class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">It could be a tool for the classic Square-Rectangle problem=
which doesnt have a clean C++ (or Java, C#, etc) solution.<br></blockquote=
></div></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">It doesn&#=
39;t have a solution because it is not a problem in code, it is a problem i=
n coders. They misunderstand the verb "to be". A square is a rect=
angle in the mathematical subset sense, NOT the behaviour sense (you can el=
ongate a rectangle, not a square, therefore the square doesn't quack li=
ke a rectangle). If you want to describe the subset sense, OOP is the wrong=
tool for the job because of the reasons I outlined.</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/CAC%2B0CCPjH-kHWmo0VBbT_tKoz7H4y8XRkY=
Y8hsxC%3DRC0esbOBg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPjH-=
kHWmo0VBbT_tKoz7H4y8XRkYY8hsxC%3DRC0esbOBg%40mail.gmail.com</a>.<br />
--001a114127d6d89a4a056584a6dd--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 18 Feb 2018 15:26:15 -0800 (PST)
Raw View
------=_Part_10271_1342941411.1518996375355
Content-Type: multipart/alternative;
boundary="----=_Part_10272_701587992.1518996375355"
------=_Part_10272_701587992.1518996375355
Content-Type: text/plain; charset="UTF-8"
On Sunday, February 18, 2018 at 5:38:50 PM UTC-5, brian....@gmail.com wrote:
>
> Yes, that is what I want but I'd like it all in one step. Actually steps
> 1 and 3 are fine now but step 2 is a maintenance problem because there is
> no easy way to do the `using`.
That's what metaclasses are for.
--
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/fd6c8668-51c0-43b2-9520-13f04f1b600f%40isocpp.org.
------=_Part_10272_701587992.1518996375355
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, February 18, 2018 at 5:38:50 PM UTC-5, brian...=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Yes, that is=
what I want but I'd like it all in one step. =C2=A0Actually steps 1 an=
d 3 are fine now but step 2 is a maintenance problem because there is no ea=
sy way to do the `using`.</blockquote><div><br>That's what metaclasses =
are for. <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/fd6c8668-51c0-43b2-9520-13f04f1b600f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fd6c8668-51c0-43b2-9520-13f04f1b600f=
%40isocpp.org</a>.<br />
------=_Part_10272_701587992.1518996375355--
------=_Part_10271_1342941411.1518996375355--
.