Any chance to avoid monitor field in my class?

[Yuriy via Digitalmars-d-learn]

> How many of these? In order to justify saving 8 bytes per 
> instance, you have have a lot. I don't see emplacing thousands 
> or tens of thousands of objects on the stack.
Ok, i guess i have to agree with you. But. Why are you protecting 
__monitors so eagerly? :)

> Arrays of objects are stored as arrays of object references, 
> with each one pointing at a separate block on the heap.
Or again you can emplace them in the heap, so that they occupy a 
continuous chunk.

> In D, class is not used for such things, struct is.
But classes have vtbls which is an ultimate feature for me, and 
moreover, it works in ctfe, while "reinventing" vtbls for ctfe 
might be a challenging task.

> I'm assuming you want D classes, but without the monitor 
> object. D classes derive from Object.
> "Any chance to avoid monitor field in my class?" Those are your 
> words. What is it that you want?
Thats right. I was saying that extern(C++) almost suits me except 
for it's mangling. And you said that extern(C++) classes are not 
derived from Object? But still such objects would have RTTI which 
will forbid casting to Object, wouldn't they?

> shared != thread safe. You still need to synchronize
Ok. So shared class is not a reason to omit __monitor field, as 
it still can be used, am i right here?