Jump to page: 1 2
Thread overview
-betterC and extern(C++) classes
Sep 10, 2017
Yuxuan Shui
Sep 10, 2017
rikki cattermole
Sep 10, 2017
9il
Sep 10, 2017
rikki cattermole
Sep 10, 2017
Paulo Pinto
Sep 10, 2017
Walter Bright
Sep 10, 2017
Adam D. Ruppe
Sep 10, 2017
Moritz Maxeiner
Sep 10, 2017
rikki cattermole
Sep 10, 2017
Moritz Maxeiner
Sep 10, 2017
Yuxuan Shui
Sep 10, 2017
Moritz Maxeiner
Sep 10, 2017
Yuxuan Shui
Sep 10, 2017
Walter Bright
Sep 10, 2017
Yuxuan Shui
Sep 10, 2017
Moritz Maxeiner
Sep 10, 2017
Walter Bright
September 10, 2017
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
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
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
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
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
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
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
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
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
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.
« First   ‹ Prev
1 2