View mode: basic / threaded / horizontal-split · Log in · Help
July 29, 2012
D language and .NET platform
There is a couple of questions.

1. What about interoperability of D and .NET platform?
2. What is the difference between pure D and D for .NET?
3. Can I write code on pure D and then compile it to MSIL and use 
it further in .NET environment?
4. Are there many libraries for D? Can D just use C\C++ dll's 
without pain for programmer?

Thank you in advance)))
July 29, 2012
Re: D language and .NET platform
On 29-07-2012 17:30, EngineerSpock wrote:
> There is a couple of questions.
>
> 1. What about interoperability of D and .NET platform?

You should be able to write C routines in D that .NET's P/Invoke can call.

> 2. What is the difference between pure D and D for .NET?

D for .NET is dead because .NET is too limited to represent the 
language, so describing this isn't really worthwhile. :)

> 3. Can I write code on pure D and then compile it to MSIL and use it
> further in .NET environment?

No. Sorry to ruin your hope, but D on .NET is a dead end.

> 4. Are there many libraries for D? Can D just use C\C++ dll's without
> pain for programmer?
>
> Thank you in advance)))

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
July 29, 2012
Re: D language and .NET platform
Alex Rønne Petersen:

> .NET is too limited to represent the language,

Can you tell us why?

Bye,
bearophile
July 29, 2012
Re: D language and .NET platform
On 29-07-2012 17:36, bearophile wrote:
> Alex Rønne Petersen:
>
>> .NET is too limited to represent the language,
>
> Can you tell us why?
>
> Bye,
> bearophile

Array slices. The .NET type system has no way to represent them because 
it's designed for precise GC, and array slices allow interior pointers 
in the heap (as opposed to the stack when passing a field of an object 
by reference to a function, or whatever).

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
July 29, 2012
Re: D language and .NET platform
On 7/30/2012 12:30 AM, EngineerSpock wrote:
> There is a couple of questions.

> 4. Are there many libraries for D? Can D just use C\C++ dll's without
> pain for programmer?
>

There are a number of libraries covering different domains, some active 
some not. Also, D is binary compatible with C, so you can use existing C 
libraries with D (see Derelict[1] and Deimos[2] for examples).

There's also some support for binding with C++, but AFAIK it's not as 
reliable as the C interface due to incompatibilities between C++ 
compilers. There are also going to be limitations regarding certain C++ 
features. I /assume/ it will mostly work with DMC and GCC. But someone 
else will have to tell you how usable it is.

[1] https://github.com/aldacron/Derelict3
[2] https://github.com/D-Programming-Deimos
July 29, 2012
Re: D language and .NET platform
On Sun, 29 Jul 2012 18:32:08 +0200, Alex Rønne Petersen <alex@lycus.org>  
wrote:

> On 29-07-2012 17:36, bearophile wrote:
>> Alex Rønne Petersen:
>>
>>> .NET is too limited to represent the language,
>>
>> Can you tell us why?
>>
>> Bye,
>> bearophile
>
> Array slices. The .NET type system has no way to represent them because  
> it's designed for precise GC, and array slices allow interior pointers  
> in the heap (as opposed to the stack when passing a field of an object  
> by reference to a function, or whatever).

So one couldn't simply use a two-level system, with a slice referencing an
array, and holding an offset and a length?

-- 
Simen
July 29, 2012
Re: D language and .NET platform
On 07/29/2012 06:32 PM, Alex Rønne Petersen wrote:
> On 29-07-2012 17:36, bearophile wrote:
>> Alex Rønne Petersen:
>>
>>> .NET is too limited to represent the language,
>>
>> Can you tell us why?
>>
>> Bye,
>> bearophile
>
> Array slices. The .NET type system has no way to represent them because
> it's designed for precise GC, and array slices allow interior pointers
> in the heap (as opposed to the stack when passing a field of an object
> by reference to a function, or whatever).
>

I think all of CTFE-D should map to .NET without much hassle.

struct ArraySlice<T>{
    private T[] storage;
    private ulong start;
    private ulong len;

    public ArraySlice<T> slice(ulong a, ulong b){
        if(a>b||b>len) throw new BoundsError("...");
        return new ArraySlice<T>(storage, start+a, b-a);
    }

    public ulong length(){ return len; }
    public Pointer<T> ptr(){ return new Pointer<T>(storage, start); }
    // ...
}

Performance will suffer of course.
July 29, 2012
Re: D language and .NET platform
On 07/29/2012 07:00 PM, Timon Gehr wrote:
> On 07/29/2012 06:32 PM, Alex Rønne Petersen wrote:
>> On 29-07-2012 17:36, bearophile wrote:
>>> Alex Rønne Petersen:
>>>
>>>> .NET is too limited to represent the language,
>>>
>>> Can you tell us why?
>>>
>>> Bye,
>>> bearophile
>>
>> Array slices. The .NET type system has no way to represent them because
>> it's designed for precise GC, and array slices allow interior pointers
>> in the heap (as opposed to the stack when passing a field of an object
>> by reference to a function, or whatever).
>>
>
> I think all of CTFE-D should map to .NET without much hassle.
>

This could get a little hairy:

struct S{
    int x,y;
}

void main(){
    S s;
    auto p = &s.y;
    // ...
}

It would have to be translated to something like (pseudo-code)

class S{
    int x;
    int y;

    S copy(){...}
}

class SyPointer : Pointer<int> {
    private S instance;
    override int deref(){ return instance.y; }
    override void derefAssign(int y){ instance.y = y; }
}

Out of the window goes native value type support.
July 29, 2012
Re: D language and .NET platform
On 07/29/2012 01:11 PM, Timon Gehr wrote:
> On 07/29/2012 07:00 PM, Timon Gehr wrote:
>> On 07/29/2012 06:32 PM, Alex Rønne Petersen wrote:
>>> On 29-07-2012 17:36, bearophile wrote:
>>>> Alex Rønne Petersen:
>>>>
>>>>> .NET is too limited to represent the language,
>>>>
>>>> Can you tell us why?
>>>>
>>>> Bye,
>>>> bearophile
>>>
>>> Array slices. The .NET type system has no way to represent them because
>>> it's designed for precise GC, and array slices allow interior pointers
>>> in the heap (as opposed to the stack when passing a field of an object
>>> by reference to a function, or whatever).
>>>
>>
>> I think all of CTFE-D should map to .NET without much hassle.
>>
>
> This could get a little hairy:
>
> struct S{
> int x,y;
> }
>
> void main(){
> S s;
> auto p = &s.y;
> // ...
> }
>
> It would have to be translated to something like (pseudo-code)
>
> class S{
> int x;
> int y;
>
> S copy(){...}
> }
>
> class SyPointer : Pointer<int> {
> private S instance;
> override int deref(){ return instance.y; }
> override void derefAssign(int y){ instance.y = y; }
> }
>
> Out of the window goes native value type support.

I still always thought it funny that we didn't reach for it anyways.  It 
seems like the VMs can weaken performance significantly, but they should 
always be able to implement D's semantics.  It's a matter of finding 
effective hacks.
July 29, 2012
Re: D language and .NET platform
On 29-07-2012 18:51, Simen Kjaeraas wrote:
> On Sun, 29 Jul 2012 18:32:08 +0200, Alex Rønne Petersen
> <alex@lycus..org> wrote:
>
>> On 29-07-2012 17:36, bearophile wrote:
>>> Alex Rønne Petersen:
>>>
>>>> .NET is too limited to represent the language,
>>>
>>> Can you tell us why?
>>>
>>> Bye,
>>> bearophile
>>
>> Array slices. The .NET type system has no way to represent them
>> because it's designed for precise GC, and array slices allow interior
>> pointers in the heap (as opposed to the stack when passing a field of
>> an object by reference to a function, or whatever).
>
> So one couldn't simply use a two-level system, with a slice referencing an
> array, and holding an offset and a length?
>

That could work, but it wouldn't be compatible with D as it is now.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home