Re: Any chance to avoid monitor field in my class?
On Thursday, 15 May 2014 at 11:51:38 UTC, Daniel Murphy wrote: This version seems to compile - the new manger can't handle extern(C++) functions with D arrays as arguments or return types. Ok, i can understand that, but what about this one: http://dpaste.dzfl.pl/6a9961e32e6d It doesn't use d arrays in function interfaces. Should it work?
Re: Any chance to avoid monitor field in my class?
On Wednesday, 14 May 2014 at 08:47:38 UTC, Daniel Murphy wrote: I'm not getting any errors with the development head. What os/compiler version? Hm, now that's strange. Building with latest public version seems to work. However, development head is doing the following: $ ./test.d Error: ICE: Unsupported type string Assertion failed: (0), function visit, file cppmangle.c, line 440. I'm using MacOS 10.9.2. The test.d is: http://dpaste.dzfl.pl/2aa4ca932be1
Re: Any chance to avoid monitor field in my class?
On Wednesday, 14 May 2014 at 10:21:00 UTC, Dejan Lekic wrote: that should not compile at all. Perhaps you thought extern(C++) interface MyClass(T) ? Ok, how about this one? http://dpaste.dzfl.pl/04655ff6ddfd It doesn't compile either.
Re: Any chance to avoid monitor field in my class?
Ali, i think that paragraph is talking about another case, which is not my case. I'm not trying to use C++ templates, nor to export a D template to C++. Besides, i guess that D template, implementing a C++ interface is perfectly valid, regardless it's template arguments, since it is instantiated on the D side anyway. Also i guess that such types as D arrays should not support mangling when used as function arguments/rettype, they are not compatible with C++ anyway, but when they become part of a class template, they should mangle somehow. IMHO. On Wednesday, 14 May 2014 at 14:08:52 UTC, Ali Çehreli wrote: Yeah, that is a documented limitation when using C++ code. C++ templates cannot be used in D. C++ Templates here: http://dlang.org/cpp_interface.html Ali
Re: Any chance to avoid monitor field in my class?
On Tuesday, 13 May 2014 at 17:09:01 UTC, Daniel Murphy wrote:
What exactly is the mangling problem with extern(C++) classes?
Can't use D arrays (and strings) as function argument types.
Can't use D array types as template arguments.
extern (C++) MyClass(T)
{
}
MyClass!string a; // Mangling error
Re: Any chance to avoid monitor field in my class?
Imho, offtop, also i'm a C++/Obj-C guy and that might partially explain my preferences, but here are some more reasons: 1. I like the concept of CT-reflection and CTFE a lot. This makes metaprogramming extremely powerful without any RT overheads. It brings a lot more control to what goes to RT. I guess D still needs to shrink it's runtime a bit more, and __monitors is just another example of that. 2. It's extremely easy for C++/C#/Java/Objc-C developers to switch to D without loosing any bit of their productivity, but gaining lots of possibilities, that can be used in future. And C++/C#/Java/Obj-C is the majority of the world now. Even PHP developers should think of D one day =). 3. That's the most arguable, but D's syntax and semantics looks much cleaner and uniform to me than Rust's.
Re: Any chance to avoid monitor field in my class?
flamencofantasy, thanx for that! Where do we vote here? =)
Re: Any chance to avoid monitor field in my class?
On Thursday, 8 May 2014 at 14:57:37 UTC, Steven Schveighoffer wrote: The de-facto minimum size of a class is 16 bytes, due to the minimum block size of the heap. 8 bytes vtbl pointer on 64-bit systems would still allocate into 16-byte blocks. -Steve Yes, but still the question remains open for non-empty classes (e.g. want to use a 64bit useful payload), and for _emplacing_ any classes anywhere (e.g. on stack). Afaiu, there's no solution except for declaring extern(C++) (yes, i know, it's a hack), and it will not work, if a class is templated on something which can not be cpp-mangled. So the question is: is there any reason why this is not possible? I mean, maybe this question was closed long before. Also, do shared classes actually require monitors?
Re: Any chance to avoid monitor field in my class?
On Thursday, 8 May 2014 at 17:49:01 UTC, Steven Schveighoffer
wrote:
To what end? What are you trying to save?
I'm trying to reimplement std.variant in a nice OOP way, that
supports CTFE, zero-size and a minimal amount of void*-casts. For
that i'm using my VariantPayload(T) class, which i want to be as
small as possible, as this is supposed to be an utility class
which you never know how will be used.
It would not be derived from Object, which has the field. In
other words, this would crash:
synchronized(cast(Object)obj) { ... }
Wouldn't cast(Object) return null here, so that synchronized will
throw or assert or smth? I see no reason for a crash.
Perhaps you meant unshared classes? No, they don't, but a
monitor is only allocated on demand, so you don't have to worry
about it.
Errm.. I'm not sure i understand the subject correctly, but
according to Alexandrescu's book, a class declared as shared does
not require synchronized() over it. I mean, it manages it's
synchronization inside itself, and it's user just has to trust
it. And if so, why ever synchronizing() on it?
Re: Any chance to avoid monitor field in my class?
But my question more was about where do you plan to put so many
of these objects that you will save a significant amount of
bytes, aside from the heap (which already uses 16-byte blocks).
Hm.. Stack/emplace, arrays, n-dimensional arrays? :) Besides, if
we're talking of D as a system language to replace C++ and to
scratch everything out of a silicon wafer (also think of embedded
platforms here), it's crucial for me to be able to control such
things. From my experience, in a 5000-class project you would
have about 20 classes that need to be synchronized on. Moreover,
mutex synchronization is not in fashion nowadays, as we tend to
use transitional synchronization. And so my 4980 classes will
contain an extra field i don't use. What?? =)
It would not be derived from Object, which has the field. In
other words, this would crash:
Those are your words.
Then what is this object? All D objects derive from Object.
Those are your words also =)
The meaning of shared is not well defined. Even TDPL is
outdated on this.
The idea in the book is that shared types would use memory
barriers to ensure correct ordering of access, and correct data
access. But it does not prevent races for multiple threads, you
still need synchronized.
Yes, i understand that. By implementing a shared class, you're on
your own with syncing, but also you tell the user, that your
class doesn't need to be synchronized on. Right?
Unshared objects, on the other hand, should not ever need
synchronization tools, since only one thread has access!
Here's two use-cases.
class A {}
shared class B {}
// Somewhere in code
{
shared A sharedA; // This would need synchronized() on access.
A unsharedA; // This would not. But since, the class is
defined as unshared, we still will have __monitor in it, and that
is good, since we can cast between unshared A and shared A.
B b;
shared B sharedB; // Here in both cases we know, that we will
never need to sync on b or sharedB, as both of those are thread
safe (it's not our business, how they do it, but they kinda
are). So do we need this __monitor, which will never be used
actually?
}
Re: Any chance to avoid monitor field in my class?
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?
Re: Any chance to avoid monitor field in my class?
Also take a look at the Rust language, that avoids some of your problems :-) Done already =). Rust is great, but I like D, and i strongly believe it's the next big language. If only it could allow a bit more tweaks ;)
Re: Any chance to avoid monitor field in my class?
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 want to provide it, but before i do, i want to know if there were any decisions made earlier, that would render my work useless. I mean, i have to know all possible cons for not having __monitor in an instance. What i suggest is the following: - Object does not have any __monitor field by default. - One can add a __monitor object to his class. - Offset to monitor is stored in TypeInfo. -1 if doesn't exist. - synchronized() inspects typeInfo. If an object has monitor, then it is used. Otherwise, the monitor is allocated/looked up in a global hash-table from object pointer to monitor. This way we could achieve performance in terms of both speed and memory. Also old code would not break. Some additional optimizations might always include a __monitor field to a class, if compiler can prove, that this class is being synchronized on.
static if (__ctfe)
Hello, is there any way to static if(__ctfe)? I want to declare class members which are only available in ctfe. Thanx.
Re: static if (__ctfe)
On Wednesday, 7 May 2014 at 09:51:01 UTC, John Colvin wrote: On Wednesday, 7 May 2014 at 09:47:20 UTC, Yuriy wrote: Hello, is there any way to static if(__ctfe)? I want to declare class members which are only available in ctfe. Thanx. Sadly not as far as I know. What's the use-case? There may be a nice solution none-the-less. Well, i'm currently playing with std.variant so it can be ctfe-friendly. And it works pretty much, however i need to use T.stringof.ptr/length instead of typeid (typeid is ctfeable), and i'm not sure if it's good for performance in runtime. So for type comparison i'd like to compare TypeInfos in rt, and T.stringof in ct. Using both with rt if will likely generate more code.
Any chance to avoid monitor field in my class?
Hello, is there a way of reducing size of an empty class to just vtbl? I tried to declare it as extern(C++) which works, but has a nasty side effect of limited mangling.
