Any chance to avoid monitor field in my class?

[Steven Schveighoffer via Digitalmars-d-learn]

On Thu, 08 May 2014 17:05:56 -0400, Yuriy <yuriy.glukhov at gmail.com> wrote:

>> 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? :)

I'm not, I'm trying to help you justify the path your taking :) Because  
where it's currently leading is somewhere that D doesn't support. This  
means in order to support it, you have to maintain a parallel compiler, or  
somehow convince the compiler writers to add such support. Neither of  
these burdens is small.

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

This is not a good idea. The dtors of classes in the GC is stored per  
block, not per chunk of a block.

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

Removing the monitor could also prove quite challenging.

I don't doubt your reasons, but then again, you have what you have right  
now in D. Asking for more, you have to provide it, or convince others to.  
If it's the latter, you need to make a very very strong case.

>
>> 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?

extern(C++) objects are not considered D objects. A D object can implement  
a C++ interface, but once you get to the C++ interface, you cannot go back.

This sounds to me very different from your goal.

-Steve