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

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?

>> 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.

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.

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