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
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 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
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 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
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).
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
