Date: Wed, 25 Aug 2021 10:41:12 +0300
The virtual functions are for sure not a part of this feature, because it
involves the virtual tables that are based on potentially complex classes
hierarhy.
In my example
struct foo;
void foo::bar();
foo is only the typename.
Then when compiler gots
foo& f;
f.bar();
It translates to methid call with reference this parameter &f.
No additional information about struct foo is required to generate that
method call, therefore full foo struct definition is unnecessery
restriction of the language.
My main cocern is that in some architectures, when real foo struct is
small, ABI passes *this parameter by value. I do not have a solution for
this problem.
On Wed, Aug 25, 2021, 10:24 Lénárd Szolnoki via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> What about virtual functions? Do you want these to be declarable outside
> the class? I think those would have similar ABI issues.
>
> Personally I like the "partial type definition" idea. If we want to
> protect against different orders in different TUs then maybe we could
> mandate to give each part a name, and each part should refer to the
> previous part, if there is any. The part that completes the type shouldn't
> have a name.
>
> class C/part1 {
> int i;
> };
>
> class C/part2 extends(part1) {
> int j;
> };
>
> class C extends(part2) {
> int k;
> }; //completes the type
>
> This is just a dummy syntax.
>
> Cheers,
> Lénárd
>
>
> ------------------------------
> *From:* Valery Osheter via Std-Proposals <std-proposals_at_[hidden]>
> *Sent:* August 25, 2021 5:28:41 AM GMT+01:00
> *To:* Ville Voutilainen <ville.voutilainen_at_[hidden]>
> *Cc:* Valery Osheter <valery.o_at_[hidden]>, sotrdg sotrdg via
> Std-Proposals <std-proposals_at_[hidden]>
> *Subject:* Re: [std-proposals] Partial type definition
>
> I see that the discussion goes to the direction I did not expect.
> So maybe the caption should be changed from "partial type definition" to
> "declaration of methods outside of the class definition". This is my real
> intent. I think it does not hurt ODR, because ODR requires only one
> definition and allows several equvalent declarations. If the declarations
> are not equal, the linker fails just like in case of plain function in C++.
>
> I hope that this feature so simple and attractive, the compilers can do it
> literally tomorrow.
>
> On Tue, Aug 24, 2021, 23:08 Ville Voutilainen <ville.voutilainen_at_[hidden]>
> wrote:
>
>> On Tue, 24 Aug 2021 at 23:05, Ville Voutilainen
>> <ville.voutilainen_at_[hidden]> wrote:
>> > I doubt it's viable to allow the real definition of X to omit the
>> > things defined in the partial definition. A translation
>> > unit that sees the real definition might not see the partial
>> > definition, and then you have a serious ODR problem.
>>
>> ..which is not to say that this idea isn't riddled with different ODR
>> problems to begin with, though. :)
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
involves the virtual tables that are based on potentially complex classes
hierarhy.
In my example
struct foo;
void foo::bar();
foo is only the typename.
Then when compiler gots
foo& f;
f.bar();
It translates to methid call with reference this parameter &f.
No additional information about struct foo is required to generate that
method call, therefore full foo struct definition is unnecessery
restriction of the language.
My main cocern is that in some architectures, when real foo struct is
small, ABI passes *this parameter by value. I do not have a solution for
this problem.
On Wed, Aug 25, 2021, 10:24 Lénárd Szolnoki via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> What about virtual functions? Do you want these to be declarable outside
> the class? I think those would have similar ABI issues.
>
> Personally I like the "partial type definition" idea. If we want to
> protect against different orders in different TUs then maybe we could
> mandate to give each part a name, and each part should refer to the
> previous part, if there is any. The part that completes the type shouldn't
> have a name.
>
> class C/part1 {
> int i;
> };
>
> class C/part2 extends(part1) {
> int j;
> };
>
> class C extends(part2) {
> int k;
> }; //completes the type
>
> This is just a dummy syntax.
>
> Cheers,
> Lénárd
>
>
> ------------------------------
> *From:* Valery Osheter via Std-Proposals <std-proposals_at_[hidden]>
> *Sent:* August 25, 2021 5:28:41 AM GMT+01:00
> *To:* Ville Voutilainen <ville.voutilainen_at_[hidden]>
> *Cc:* Valery Osheter <valery.o_at_[hidden]>, sotrdg sotrdg via
> Std-Proposals <std-proposals_at_[hidden]>
> *Subject:* Re: [std-proposals] Partial type definition
>
> I see that the discussion goes to the direction I did not expect.
> So maybe the caption should be changed from "partial type definition" to
> "declaration of methods outside of the class definition". This is my real
> intent. I think it does not hurt ODR, because ODR requires only one
> definition and allows several equvalent declarations. If the declarations
> are not equal, the linker fails just like in case of plain function in C++.
>
> I hope that this feature so simple and attractive, the compilers can do it
> literally tomorrow.
>
> On Tue, Aug 24, 2021, 23:08 Ville Voutilainen <ville.voutilainen_at_[hidden]>
> wrote:
>
>> On Tue, 24 Aug 2021 at 23:05, Ville Voutilainen
>> <ville.voutilainen_at_[hidden]> wrote:
>> > I doubt it's viable to allow the real definition of X to omit the
>> > things defined in the partial definition. A translation
>> > unit that sees the real definition might not see the partial
>> > definition, and then you have a serious ODR problem.
>>
>> ..which is not to say that this idea isn't riddled with different ODR
>> problems to begin with, though. :)
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2021-08-25 02:41:25