Hi

Is it possible to use classes, which do not have monitor and other DRuntime stuff?

Object can be allocated/deallocated using allocators, but they are very complex for betterC mode (monitor, mutex, object.d dependency).

Can we have something more primitive?

Ilya

On Friday, 16 December 2016 at 15:17:15 UTC, Ilya Yaroshenko wrote:
> Hi
>
> Is it possible to use classes, which do not have monitor and other DRuntime stuff?
>
> Object can be allocated/deallocated using allocators, but they are very complex for betterC mode (monitor, mutex, object.d dependency).
>
> Can we have something more primitive?
>
> Ilya

extern(c++)
class

Works pretty good in my experience, at least it gets rid of the monitor, yay!

On Friday, 16 December 2016 at 16:24:18 UTC, Daniel N wrote:
> On Friday, 16 December 2016 at 15:17:15 UTC, Ilya Yaroshenko wrote:
>> Hi
>>
>> Is it possible to use classes, which do not have monitor and other DRuntime stuff?
>>
>> Object can be allocated/deallocated using allocators, but they are very complex for betterC mode (monitor, mutex, object.d dependency).
>>
>> Can we have something more primitive?
>>
>> Ilya
>
> extern(c++)
> class
>
> Works pretty good in my experience, at least it gets rid of the monitor, yay!

Thanks,
DRuntime is required anyway, but this is step forward.

ldmd2 -betterC -defaultlib= -O -inline -release -run cppclass.d

extern(C++) class Hw
{
	import core.stdc.stdio;

	this()
	{

	}

	void hw()
	{
		printf("hey\n");
	}
}

import std.traits;
extern(C)
int main()
{
	enum classSize = __traits(classInstanceSize, Hw);
	align(16)
	ubyte[classSize] payload = void;
	auto init = cast(const(ubyte)[]) typeid(Hw).initializer;
	foreach(i; 0..classSize)
		payload[i] = init[i];
	auto object = cast(Hw) payload.ptr;
	object.__ctor();
	object.hw();
	return 0;
}

-------------
Undefined symbols for architecture x86_64:
  "__D14TypeInfo_Class6__vtblZ", referenced from:
      __D8cppclass2Hw7__ClassZ in cppclass-7ed89bd.o

On Friday, 16 December 2016 at 18:29:33 UTC, Ilya Yaroshenko wrote:
> Undefined symbols for architecture x86_64:
>   "__D14TypeInfo_Class6__vtblZ", referenced from:
>       __D8cppclass2Hw7__ClassZ in cppclass-7ed89bd.o

By using typeid you request the class' TypeInfo, and it pulls quite a lot.

On Tuesday, 20 December 2016 at 13:30:54 UTC, Kagamin wrote:
> On Friday, 16 December 2016 at 18:29:33 UTC, Ilya Yaroshenko wrote:
>> Undefined symbols for architecture x86_64:
>>   "__D14TypeInfo_Class6__vtblZ", referenced from:
>>       __D8cppclass2Hw7__ClassZ in cppclass-7ed89bd.o
>
> By using typeid you request the class' TypeInfo, and it pulls quite a lot.

The failure reason is a different one - apparently each class (incl. extern(C++)) _must_ feature at least one virtual function, as a vtbl pointer as first member is expected in multiple places (frontend too, not just backend). Linking fails as the vtable is empty. Tested with DMD 2.071, and that fails too, regardless of `-betterC`.
If there's no good reason for this, it may be considered a bug, as it prevents treating simple C++ classes as reference types on the D side.

It looks more like a reference from C++ class TypeInfo to Class TypeInfo vtable, which is legit since the C++ class TypeInfo is a D class derived from Class TypeInfo. What's not good is a reference to the C++ class TypeInfo in the first place.

On Thursday, 22 December 2016 at 09:01:21 UTC, Kagamin wrote:
> It looks more like a reference from C++ class TypeInfo to Class TypeInfo vtable, which is legit since the C++ class TypeInfo is a D class derived from Class TypeInfo.

Or just an instance of Class TypeInfo, so its initializer needs Class TypeInfo vtable.