Re: Any chance to avoid monitor field in my class?

2014-05-15 Thread Yuriy via Digitalmars-d-learn
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

Re: Any chance to avoid monitor field in my class?

2014-05-14 Thread Yuriy via Digitalmars-d-learn
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:

Re: Any chance to avoid monitor field in my class?

2014-05-14 Thread Yuriy via Digitalmars-d-learn
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?

2014-05-14 Thread Yuriy via Digitalmars-d-learn
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

Re: Any chance to avoid monitor field in my class?

2014-05-13 Thread Yuriy via Digitalmars-d-learn
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

Re: Any chance to avoid monitor field in my class?

2014-05-09 Thread Yuriy via Digitalmars-d-learn
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.

Re: Any chance to avoid monitor field in my class?

2014-05-09 Thread Yuriy via Digitalmars-d-learn
flamencofantasy, thanx for that! Where do we vote here? =)

Re: Any chance to avoid monitor field in my class?

2014-05-08 Thread Yuriy via Digitalmars-d-learn
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

Re: Any chance to avoid monitor field in my class?

2014-05-08 Thread Yuriy via Digitalmars-d-learn
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

Re: Any chance to avoid monitor field in my class?

2014-05-08 Thread Yuriy via Digitalmars-d-learn
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

Re: Any chance to avoid monitor field in my class?

2014-05-08 Thread 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

Re: Any chance to avoid monitor field in my class?

2014-05-08 Thread Yuriy via Digitalmars-d-learn
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?

2014-05-08 Thread Yuriy via Digitalmars-d-learn
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

static if (__ctfe)

2014-05-07 Thread Yuriy via Digitalmars-d-learn
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)

2014-05-07 Thread Yuriy via Digitalmars-d-learn
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

Any chance to avoid monitor field in my class?

2014-05-07 Thread Yuriy via Digitalmars-d-learn
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.