Thread overview | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
September 10, 2017 -betterC and extern(C++) classes | ||||
---|---|---|---|---|
| ||||
I was experimenting with -betterC and found out that C++ classes doesn't work. Because the resulting object file needs a symbol "_D14TypeInfo_Class6__vtblZ" which is in druntime. I suppose this is to support T.classinfo? Could we remove T.classinfo and make classes work under -betterC? Or is there some other reason preventing this from happening? Thanks. |
September 10, 2017 Re: -betterC and extern(C++) classes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Yuxuan Shui | On 10/09/2017 9:40 AM, Yuxuan Shui wrote: > I was experimenting with -betterC and found out that C++ classes doesn't work. Because the resulting object file needs a symbol "_D14TypeInfo_Class6__vtblZ" which is in druntime. I suppose this is to support T.classinfo? Nope. > Could we remove T.classinfo and make classes work under -betterC? Or is there some other reason preventing this from happening? > > Thanks. Definitely not. Classes require vtable's to work. Vtables are generated as part of TypeInfo. No TypeInfo, no classes, simple to understand. Same reason why you can't use classes and cross the dll boundary on Windows. But if you prefer not having any methods to call, then I'm sure we can remove the requirement on the vtable ;) (Not a solution) |
September 10, 2017 Re: -betterC and extern(C++) classes | ||||
---|---|---|---|---|
| ||||
Posted in reply to rikki cattermole | On Sunday, 10 September 2017 at 08:56:11 UTC, rikki cattermole wrote:
> On 10/09/2017 9:40 AM, Yuxuan Shui wrote:
>> I was experimenting with -betterC and found out that C++ classes doesn't work. Because the resulting object file needs a symbol "_D14TypeInfo_Class6__vtblZ" which is in druntime. I suppose this is to support T.classinfo?
>
> Nope.
>
>> Could we remove T.classinfo and make classes work under -betterC? Or is there some other reason preventing this from happening?
>>
>> Thanks.
>
> Definitely not.
>
> Classes require vtable's to work. Vtables are generated as part of TypeInfo. No TypeInfo, no classes, simple to understand.
>
No. vtables can be generated without RTTI and we can have both D and C++ classes in betterC mode. It may not be ready now, but it is definitely possible and should be supported.
Best reagards,
Ilya
|
September 10, 2017 Re: -betterC and extern(C++) classes | ||||
---|---|---|---|---|
| ||||
Posted in reply to 9il | On 10/09/2017 10:03 AM, 9il wrote:
> On Sunday, 10 September 2017 at 08:56:11 UTC, rikki cattermole wrote:
>> On 10/09/2017 9:40 AM, Yuxuan Shui wrote:
>>> I was experimenting with -betterC and found out that C++ classes doesn't work. Because the resulting object file needs a symbol "_D14TypeInfo_Class6__vtblZ" which is in druntime. I suppose this is to support T.classinfo?
>>
>> Nope.
>>
>>> Could we remove T.classinfo and make classes work under -betterC? Or is there some other reason preventing this from happening?
>>>
>>> Thanks.
>>
>> Definitely not.
>>
>> Classes require vtable's to work. Vtables are generated as part of TypeInfo. No TypeInfo, no classes, simple to understand.
>>
>
> No. vtables can be generated without RTTI and we can have both D and C++ classes in betterC mode. It may not be ready now, but it is definitely possible and should be supported.
>
> Best reagards,
> Ilya
Agreed, but that is a bigger change and would require a bit more of a rethink than just a simple 'remove reference to symbol'.
|
September 10, 2017 Re: -betterC and extern(C++) classes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Yuxuan Shui | On 9/10/2017 1:40 AM, Yuxuan Shui wrote:
> I was experimenting with -betterC and found out that C++ classes doesn't work. Because the resulting object file needs a symbol "_D14TypeInfo_Class6__vtblZ" which is in druntime. I suppose this is to support T.classinfo?
>
> Could we remove T.classinfo and make classes work under -betterC? Or is there some other reason preventing this from happening?
Yes, we do want to move towards "Better C++" working in an analogous manner, and that means removing the typeinfo dependency.
|
September 10, 2017 Re: -betterC and extern(C++) classes | ||||
---|---|---|---|---|
| ||||
Posted in reply to rikki cattermole | On Sunday, 10 September 2017 at 08:56:11 UTC, rikki cattermole wrote:
> On 10/09/2017 9:40 AM, Yuxuan Shui wrote:
>> I was experimenting with -betterC and found out that C++ classes doesn't work. Because the resulting object file needs a symbol "_D14TypeInfo_Class6__vtblZ" which is in druntime. I suppose this is to support T.classinfo?
>
> Nope.
>
>> Could we remove T.classinfo and make classes work under -betterC? Or is there some other reason preventing this from happening?
>>
>> Thanks.
>
> Definitely not.
>
> Classes require vtable's to work. Vtables are generated as part of TypeInfo. No TypeInfo, no classes, simple to understand.
>
> Same reason why you can't use classes and cross the dll boundary on Windows.
>
> ....
You sure can do that in C++, since Windows 3.x days.
The constraint is that C++ compiler needs to be the same on both sides.
Then there is COM as language neutral vtable.
|
September 10, 2017 Re: -betterC and extern(C++) classes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Sunday, 10 September 2017 at 09:31:55 UTC, Walter Bright wrote:
> Yes, we do want to move towards "Better C++" working in an analogous manner, and that means removing the typeinfo dependency.
TypeInfo is cheap and useful with classes.
You shouldn't be removing it, just stripping it to the minimum needed so the rest is opt in.
|
September 10, 2017 Re: -betterC and extern(C++) classes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Sunday, 10 September 2017 at 09:31:55 UTC, Walter Bright wrote:
> On 9/10/2017 1:40 AM, Yuxuan Shui wrote:
>> I was experimenting with -betterC and found out that C++ classes doesn't work. Because the resulting object file needs a symbol "_D14TypeInfo_Class6__vtblZ" which is in druntime. I suppose this is to support T.classinfo?
>>
>> Could we remove T.classinfo and make classes work under -betterC? Or is there some other reason preventing this from happening?
>
> Yes, we do want to move towards "Better C++" working in an analogous manner, and that means removing the typeinfo dependency.
If TypeInfo for extern(C++) classes is removed, couldn't final extern(C++) classes without base class and which don't implement any interfaces omit the vtable so that the following assert holds:
---
final extern(C++) class Foo {}
static assert (__traits(classInstanceSize, Foo) == 0LU);
---
The reason I ask is that fairly often I have an abstraction that's better suited as a reference type than a value type, but doesn't need any runtime polymorphy (or the monitor standard classes have). Structs + pointers are the only way I know of to avoid the (in this special case) unneeded vtable overhead, but it always ends up looking worse to read.
|
September 10, 2017 Re: -betterC and extern(C++) classes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Sunday, 10 September 2017 at 09:31:55 UTC, Walter Bright wrote:
> On 9/10/2017 1:40 AM, Yuxuan Shui wrote:
>> I was experimenting with -betterC and found out that C++ classes doesn't work. Because the resulting object file needs a symbol "_D14TypeInfo_Class6__vtblZ" which is in druntime. I suppose this is to support T.classinfo?
>>
>> Could we remove T.classinfo and make classes work under -betterC? Or is there some other reason preventing this from happening?
>
> Yes, we do want to move towards "Better C++" working in an analogous manner, and that means removing the typeinfo dependency.
Is there a plan? Are there any simple tasks I can take/help?
|
September 10, 2017 Re: -betterC and extern(C++) classes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Moritz Maxeiner | On 10/09/2017 2:19 PM, Moritz Maxeiner wrote:
> If TypeInfo for extern(C++) classes is removed, couldn't final extern(C++) classes without base class and which don't implement any interfaces omit the vtable so that the following assert holds:
>
> ---
> final extern(C++) class Foo {}
> static assert (__traits(classInstanceSize, Foo) == 0LU);
> ---
>
> The reason I ask is that fairly often I have an abstraction that's better suited as a reference type than a value type, but doesn't need any runtime polymorphy (or the monitor standard classes have). Structs + pointers are the only way I know of to avoid the (in this special case) unneeded vtable overhead, but it always ends up looking worse to read.
We can do it for any class if its final. The problem isn't generating the vtable's. But the information required for casting.
|
Copyright © 1999-2021 by the D Language Foundation