Yuriy wrote in message news:klosrzuxwmvilupzz...@forum.dlang.org...
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?
Similar problem, D arrays cannot be mangled correctly with C++ mangling.
Yuriy wrote in message news:rfirqtgbparjbqxwt...@forum.dlang.org...
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.
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
On Tuesday, 13 May 2014 at 17:41:42 UTC, Yuriy wrote:
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
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:
On Tuesday, 13 May 2014 at 17:41:42 UTC, Yuriy wrote:
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
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.
On 05/14/2014 04:15 AM, Yuriy wrote:
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.
extern(C++)
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
Yuriy wrote in message news:uflaemdlxvavfmvkb...@forum.dlang.org...
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.
What exactly is the mangling problem with extern(C++)
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
Yuriy:
but I like D, and i strongly believe it's the next big language.
Oh, good. Do you want to briefly explain why? :)
Bye,
bearophile
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.
One thing I hate about C# (which is what I use professionally) is
the sync block index in every single class instance. Why not have
the developer decide when he needs a Monitor and manually use
it?! I am disappointed D took the same route.
On Friday, 9 May 2014 at 14:56:21 UTC, flamencofantasy wrote:
One thing I hate about C# (which is what I use professionally)
is
the sync block index in every single class instance. Why not
have
the developer decide when he needs a Monitor and manually use
it?! I am disappointed D took the same
flamencofantasy, thanx for that! Where do we vote here? =)
On Wed, 07 May 2014 10:44:55 -0400, Yuriy yuriy.gluk...@gmail.com wrote:
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.
The de-facto minimum size of a class is 16
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
On Thu, 08 May 2014 13:21:07 -0400, Yuriy yuriy.gluk...@gmail.com wrote:
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
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
On Thu, 08 May 2014 14:17:42 -0400, Yuriy yuriy.gluk...@gmail.com wrote:
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
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
also =)
Any chance to avoid monitor field in my class? Those are your words.
What is it that you want?
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
On Wednesday, 7 May 2014 at 14:44:57 UTC, Yuriy wrote:
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.
Just a general FYI:
Classes are relatively heavyweight in D.
, 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
Yuriy:
But. Why are you protecting __monitors so eagerly? :)
Also take a look at the Rust language, that avoids some of your
problems :-)
Bye,
bearophile
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 ;)
, 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
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
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.
On Wednesday, 7 May 2014 at 14:44:57 UTC, Yuriy wrote:
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.
May I ask what your use case is? Perhaps there's another solution
31 matches
Mail list logo
