>  It doesn't mention anything about moving C++ into C#.
> Even with IL2CPP, C# has fundamental design trade offs that make it slower than C++(GC is just one of them), so it wouldn't make much sense to port engine code to C# unless they wanted it to run slower.

What are these fundamental design trade offs?

On Tuesday, 30 September 2014 at 13:59:01 UTC, po wrote:
>
>> This will most likely change when they get their IL2CPP production ready and start moving code from C++ to C#.
>>
>> Or when Microsoft finishes the ongoing work on .NET Native.
>>
>> --
>> Paulo
>
>  I'd not seen IL2CPP before, but from this link:
>
> http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/
>
> It appears to act as a replacement for the mono VM, allowing for AoT compilation of .Net IL into C++, so that they can benefit from existing C++ compiler tech.
>
>  It doesn't mention anything about moving C++ into C#.

No, but it is a possibility.

> Even with IL2CPP, C# has fundamental design trade offs that make it slower than C++(GC is just one of them), so it wouldn't make much sense to port engine code to C# unless they wanted it to run slower.

C has fundamental design trade offs that make it slower than Assembly
(function prologs is just of them), so it wouldn't make much sense to port engine code to C unless they wanted it to run slower.

I have been through this discussion cycle a few times since the Z80.

--
Paulo

On Tuesday, 30 September 2014 at 14:19:51 UTC, Araq wrote:
>> It doesn't mention anything about moving C++ into C#.
>> Even with IL2CPP, C# has fundamental design trade offs that make it slower than C++(GC is just one of them), so it wouldn't make much sense to port engine code to C# unless they wanted it to run slower.
>
> What are these fundamental design trade offs?

Guys I beg you, is there any chance I will get my answers? ;)

On Tuesday, 30 September 2014 at 14:28:49 UTC, Szymon Gatner wrote:
> On Tuesday, 30 September 2014 at 14:19:51 UTC, Araq wrote:
>>> It doesn't mention anything about moving C++ into C#.
>>> Even with IL2CPP, C# has fundamental design trade offs that make it slower than C++(GC is just one of them), so it wouldn't make much sense to port engine code to C# unless they wanted it to run slower.
>>
>> What are these fundamental design trade offs?

http://en.wikipedia.org/wiki/List_of_CIL_instructions

> Guys I beg you, is there any chance I will get my answers? ;)

Nope :)

I don't think anyone know what extended C++ actually will look like.

Some people say  D is going to have std::* support, but that would require someone to keep track of changes in all the c++ compilers D is supposed to support: Clang, G++, and VC++…

Some people say they want full support for C++ exceptions, some say it is too difficult…

However, you don't need std::* or C++ exceptions for a game? Some aspects of "extended C++ support" is going to be either wishful thinking or non-portable, so you probably should try to avoid depending on it.  What are you missing?

On Tuesday, 30 September 2014 at 14:19:51 UTC, Araq wrote:
>> It doesn't mention anything about moving C++ into C#.
>> Even with IL2CPP, C# has fundamental design trade offs that make it slower than C++(GC is just one of them), so it wouldn't make much sense to port engine code to C# unless they wanted it to run slower.
>
> What are these fundamental design trade offs?

-GC
-no meta programming vs meta programming
-defaults to ref semantics C# vs value semantics C++
-C++ supports unique types, C# does not
-C# lambda automatic/GC, C++ lambda fully customized via capture list

>Guys I beg you, is there any chance I will get my answers? ;)

 Sorry no clue what C++ features will be supported! Just glad that a language is acknowledging how important it is to inter-op with C++ for once.

>C has fundamental design trade offs that make it slower than Assembly
>(function prologs is just of them), so it wouldn't make much sense to port engine code to C unless they wanted it to run slower.

 I don't really think this is the same situations. I don't think C# is any higher level than C++. Having a GC does not make it automatically a higher level language, nor does it make it more "productive".

 That said, I think it is much easier to be productive in C# if you are starting from scratch, but with the proper setup & in depth knowledge of C++, it is every bit as productive(especially in games, where things like GC end up as more of a burden).

On 09/30/2014 05:32 PM, po wrote:
> On Tuesday, 30 September 2014 at 14:19:51 UTC, Araq wrote:
>>> It doesn't mention anything about moving C++ into C#.
>>> Even with IL2CPP, C# has fundamental design trade offs that make it
>>> slower than C++(GC is just one of them), so it wouldn't make much
>>> sense to port engine code to C# unless they wanted it to run slower.
>>
>> What are these fundamental design trade offs?
> 
> -GC
> -no meta programming vs meta programming
(...)

C# has wonderful meta-programming facilities: Generics! (/me run and hides)

On Tuesday, 30 September 2014 at 14:34:49 UTC, Ola Fosheim Grøstad wrote:
>
>> Guys I beg you, is there any chance I will get my answers? ;)
>
> Nope :)

I suspected so :P

>
> I don't think anyone know what extended C++ actually will look like.

Great.

>
> Some people say  D is going to have std::* support, but that would require someone to keep track of changes in all the c++ compilers D is supposed to support: Clang, G++, and VC++…

My thoughts too. Seems like maintenance hell.

>
> Some people say they want full support for C++ exceptions, some say it is too difficult…
>
> However, you don't need std::* or C++ exceptions for a game? Some aspects of "extended C++ support" is going to be either wishful thinking or non-portable, so you probably should try to avoid depending on it.  What are you missing?

I use both std/boost and exceptions when makes sense - game is not just rendering and number crunching after all.

Tbh what I -am missing- is proper run-time support for what is already suppose to work (building x64 C++/D app crashes when calling writeln() from D side). Win32 support is coming but I expect similar problems (is nobody really mixing C++ and D using VC++ atm?).

It would be great to be able to call non-virtual members of C++ classes from D but
I don't really need anything else from the language SPECS to start things going - my question is out of pure curiosity.

That being said my biggest fear is that D2 will never be finished... I am lurking on those forums for 2 years now, waiting for the signal to start the transition but I need to be sure that in few months everything I need and the code I write will work as expected (and on iOS too). I am not seeing this unfortunately, language is still being actively discussed on the most basic level (allocators, ARC, auto-decoding of utf strings...). It looks like Phobos might need to be rewritten entirely and soon. I will not give up tho, if I must skip D for one more project (which lasts year or two) then be it, hopefully I will be able to use if for the nest one :(

On Tuesday, 30 September 2014 at 17:11:48 UTC, Szymon Gatner wrote:
> I use both std/boost and exceptions when makes sense - game is not just rendering and number crunching after all.

I used some parts of boost c++0x std on ios a few years ago. I guess it is no longer maintained, but maybe it is possible to use the useful parts of a generic std library and match the memory layout on the D side?

> calling writeln() from D side). Win32 support is coming but I expect similar problems (is nobody really mixing C++ and D using VC++ atm?).

Dunno.

> That being said my biggest fear is that D2 will never be finished... I am lurking on those forums for 2 years now, waiting for the signal to start the transition but I need to be sure that in few months everything I need and the code I write will work as expected (and on iOS too). I am not seeing this

Well, I looked at D1 eight years ago with the intent of using it for game/world content on the server side. It was kind of nice, but the compiler was basic. Then I decided to drop D1 and wait for D2 when it was announced, and been tracking it ever since... So yeah, impatient. I dont think there will be a game friendly D version untill someone decides to cooperate on D--. Basically cutting features and redesign for fast precise GC that minimize cache load and that can run 60 times per sec without taking more than 10% of the cpu.

I think it is doable for a given execution and memory model. Add some constraints and performance will happen! :-)

> strings...). It looks like Phobos might need to be rewritten entirely and soon. I will not give up tho, if I must skip D for one more project (which lasts year or two) then be it, hopefully I will be able to use if for the nest one :(

If all the people who want to use it for game content ( not engine, but content ) cooperated and created c++ compatible datatypes then maybe we could have something going within 6-12 months?

On Tuesday, 30 September 2014 at 19:47:32 UTC, Ola Fosheim Grostad wrote:
> I dont think there will be a game friendly D version untill someone decides to cooperate on D--. Basically cutting features and redesign for fast precise GC that minimize cache load and that can run 60 times per sec without taking more than 10% of the cpu.
>
> I think it is doable for a given execution and memory model. Add some constraints and performance will happen! :-)

There's probably not much feature-wise that stands in the way of a fast precise GC. Implicitly shared `immutable` is one example, but other than that, I would say it's mostly unimplemented bits and pieces (missing type information) and "wrong" decisions made when designing the standard library.

Am 30.09.2014 17:32, schrieb po:
> On Tuesday, 30 September 2014 at 14:19:51 UTC, Araq wrote:
>>> It doesn't mention anything about moving C++ into C#.
>>> Even with IL2CPP, C# has fundamental design trade offs that make it
>>> slower than C++(GC is just one of them), so it wouldn't make much
>>> sense to port engine code to C# unless they wanted it to run slower.
>>
>> What are these fundamental design trade offs?
>
> -GC
> -no meta programming vs meta programming

C# has meta programming capabilities via attributes, MSIL manipulation, reflection and having the compiler available as a library.

It is not as powerful or clean as D, but it gets the job done in many cases.

> -defaults to ref semantics C# vs value semantics C++

Yes, it is a bummer, but they do exist to a certain extent. One just needs to make use of them.


> -C++ supports unique types, C# does not

Lost me there.

> -C# lambda automatic/GC, C++ lambda fully customized via capture list

Which very few people understand properly and end up capturing the whole environment anyway.

>
>...
>
>   I don't really think this is the same situations. I don't think C# is
> any higher level than C++. Having a GC does not make it automatically a
> higher level language, nor does it make it more "productive".
>
>   That said, I think it is much easier to be productive in C# if you are
> starting from scratch, but with the proper setup & in depth knowledge of
> C++, it is every bit as productive(especially in games, where things
> like GC end up as more of a burden).
>

The problem is not everyone has good knowledge of C++.

I do use C++ on and off since 1993, and always advocated it vs C when it was considered slow(!). However I very seldom met fellow developers on projects with similar C++ knowledge, except for the time I spent at CERN.

I follow at the distance the game industry, having tried a few times in the past to be part of it. I was an IGDA member for a while, did attend developer meetups at the game development university in Düsseldorf and
buy regularly the game's development magazine of German studios.

Many middle size studios in Germany are now betting in C# (Unity/MonoGame) and Flash. Mostly for tooling and indie quality games, but sometimes all the way to production.

If D had already a GC that could rival with the CLR GC, it would be a great alternative for the said studios. Regardless what the decision regarding the D's answer to memory management will be.

Specially given that it can interoperate better with C and C++ than the marshalling required by the alternatives.

--
Paulo