View mode: basic / threaded / horizontal-split · Log in · Help
February 19, 2013
Re: Java binaries
Am 19.02.2013 22:59, schrieb rumbu:
> On Tuesday, 19 February 2013 at 21:30:53 UTC, Paulo Pinto wrote:
>> Am 17.02.2013 21:47, schrieb Walter Bright:
>>> On 2/17/2013 1:46 AM, Russel Winder wrote:
>>>> The world is split into native code, PVM, JVM, JavaScript/ECMAScript. D
>>>> only really has a play in one of these, and needs to get real traction
>>>> there first before looking for new lands to conquer. Else it risks
>>>> being
>>>> seen as a solution looking for a problem to solve.
>>>
>>> I agree. There was at one time a D implementation on .net, but it
>>> suffered from .net's lack of support for pointers, which meant that
>>> slices performed poorly.
>>>
>>
>> So how are C++ and C# pointers done in IL ?
>
> There are two kind of pointers in C#: managed and unmanaged. Wrapped in
> a fixed statement (just to tell the garbage collector to keep fixed
> references), C# pointers will behave like any native language pointer.
> This is not the first topic where I read that misconception that slices
> are a problem for IL. From .net 2.0 (9 years ago) there is the
> ArraySegment<T> type doing exactly what D slices do. Also, in C# arrays
> are implicitely convertible to pointers.
> ...

I know .NET since the early pre-Beta days as my employer at the time, 
had the privilege to be one of the few Microsoft Partners in Portugal 
with access to the technology.

In those days I did some C# <=> C++ integration work by means of Managed 
C++, later superseded by C++/CLI. Hence my question. :)

--
Paulo
February 19, 2013
Re: Java binaries
On 02/19/2013 10:59 PM, rumbu wrote:
> ...
>
> Anyway, I don't see any use for a D IL compiler, since probably the
> language syntax will look 90% like C#.

Even if that was true, so what?
February 20, 2013
Re: Java binaries
>> So how are C++ and C# pointers done in IL ?
>
> There are two kind of pointers in C#: managed and unmanaged. 
> Wrapped in a fixed statement (just to tell the garbage 
> collector to keep fixed references), C# pointers will behave 
> like any native language pointer. This is not the first topic 
> where I read that misconception that slices are a problem for 
> IL. From .net 2.0 (9 years ago) there is the ArraySegment<T> 
> type doing exactly what D slices do. Also, in C# arrays are 
> implicitely convertible to pointers.

IIRC, the biggest incompatibility between D and .NET is that D 
pointers can point to the stack, to unmanaged (non-GC) memory or 
to managed (GC) memory, while simultaneously having unlimited 
lifetime. In .NET, arguments that are passed by reference can 
point to GC or non-GC memory, but pointers inside objects 
(classes or boxed structs) can only point to (1) non-GC non-stack 
memory OR (2) the beginning of a GC object. The key problem: a 
single pointer cannot be used for both purposes!

D pointers and ranges can point to stack, GC or non-GC memory, 
regardless of the location of the pointer or range itself. Also, 
D pointers can point to the interior of an object and not just 
the beginning, while .NET pointers, in general, cannot.

This doesn't make a D implementation for .NET impossible, but if 
you want to run arbitrary D code on .NET, I think it would have 
to run inefficiently because it would constantly have to work 
around limitations of .NET. I think doing D in .NET efficiently 
would require a specialized version of D, or something.

Note that plain old C++ can be used in .NET because C++ pointers 
can't point to GC memory without special .NET-specific types. 
Thus, old-fashioned C++ avoids problems related to the .NET 
garbage collector.

> Anyway, I don't see any use for a D IL compiler, since probably 
> the language syntax will look 90% like C#.

How is "looking" like C# relevant? D looks 90% like C++ too, and 
D is still better. Certainly D is more powerful than C# on the 
whole.
February 20, 2013
Re: Java binaries
On Wednesday, 20 February 2013 at 00:15:00 UTC, David Piepgrass 
wrote:

> How is "looking" like C# relevant? D looks 90% like C++ too, 
> and D is still better. Certainly D is more powerful than C# on 
> the whole.

This is not a debate C# vs D. D is clearly more powerful than C# 
with the current language semantics. But, once D will be adapted 
to generate IL code, most of advantages will be lost. You cannot 
have assembler code (may be IL code, but this can be achieved 
using Emit in C# also), compile time reflection will become 
redundant because of the intrinsic runtime reflection, most of 
the templates will be constrained to generic types. In a 
pottential D#, Phobos will not be used since you have the .net 
framework. Also because of lack of some D features (like 
readonly, mutiple interface implementation of the same method, 
namespaces), more keywords will be needed to describe the code 
and that will make it similar to C# more than expected.

The irony is the fact that digging in the forum history, you will 
find how D has evolved to be more and more C# like. Just look at 
the recent changes, "alias" has evolved to the exact syntax of 
"using" from C#.

If the initial audience of D was the C++ programmer, I think it's 
time to make a step forward and look also to lure the C# 
programmer since the syntax is very similar. The most important 
argument for the C# programmer to use D is the fact that D 
compiles to native code. Offering something like D# to the C# 
programmer is out of his interest, imho.
February 20, 2013
Re: Java binaries
On Wednesday, 20 February 2013 at 08:38:00 UTC, rumbu wrote:
> On Wednesday, 20 February 2013 at 00:15:00 UTC, David Piepgrass 
> wrote:
>
>> How is "looking" like C# relevant? D looks 90% like C++ too, 
>> and D is still better. Certainly D is more powerful than C# on 
>> the whole.
>
> This is not a debate C# vs D. D is clearly more powerful than 
> C# with the current language semantics. But, once D will be 
> adapted to generate IL code, most of advantages will be lost. 
> You cannot have assembler code (may be IL code, but this can be 
> achieved using Emit in C# also), compile time reflection will 
> become redundant because of the intrinsic runtime reflection, 
> most of the templates will be constrained to generic types. In 
> a pottential D#, Phobos will not be used since you have the 
> .net framework. Also because of lack of some D features (like 
> readonly, mutiple interface implementation of the same method, 
> namespaces), more keywords will be needed to describe the code 
> and that will make it similar to C# more than expected.
>
> The irony is the fact that digging in the forum history, you 
> will find how D has evolved to be more and more C# like. Just 
> look at the recent changes, "alias" has evolved to the exact 
> syntax of "using" from C#.
>
> If the initial audience of D was the C++ programmer, I think 
> it's time to make a step forward and look also to lure the C# 
> programmer since the syntax is very similar. The most important 
> argument for the C# programmer to use D is the fact that D 
> compiles to native code. Offering something like D# to the C# 
> programmer is out of his interest, imho.

A problem here is that Microsoft is probably in the process of 
also offering standalone compilation for .NET languages as well.

Windows Phone 8 .NET applications get compiled to native code, 
they are not JITted.

They might as well decide to use the same solution instead of 
NGEN on the desktop.

--
Paulo
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home