Why all the C/C++ interest all of a sudden?

13 hours ago, TexasToast wrote

Add back memory management and you basically kill of C++.

Well, you can always do a Marshal.AllocHGlobal() and Marshal.FreeHGlobal() and put "unsafe" before all of your classes. The sad thing is that memory management is basically an implementation detail for almost all applications, and it leads to bugs that C# otherwise eliminates (memory leaks, double frees, use-after-frees and invalid-frees all vanish if you use a GC, and they're some of the hardest bugs to detect).

I dont mind having the memory management and agree its a good addition,  it is just not easily ported to other OS's.   I wonder if Rosyln could help to make a native output for C#.

http://roslyncsderivedlan.codeplex.com/  start with this and take the output to produce C code.

Why couldn't you write a C++ memory manager that implements the GC?

Mono's compiler can compile C# to machine code. I've did some relatively unscientific experiments with it in the past and found that the performance gains tend to be minor over using the JIT'er.

The Mono team did a lot more work improving native compilation over the past years so it might be more dramatic these days. There are some reflection/generics features that don't work without the JIT'er, so it's not like win/win anyway. 

2 hours ago, ScanIAm wrote

Why couldn't you write a C++ memory manager that implements the GC?

You can. The .NET GC written in C++ is just such an example. You do have to bear in mind that it only works if all of your allocations go through the GC and you give enough type information to the GC to properly understand your program, so you probably won't be able to trivially port a C++ program to one using a C++ garbage collector.

One example of something C# can do that C++ can't is reflection. I've used it so many times now that I find C++ a pain to program in (and there are many other reasons too).

For instance, I created a debugging class that, when added to any C# project, allows you to do "realtime" debugging. It creates a tree of all objects in your process much like you can do with the current Watch window in VS. But the Watch window in VS only works if your app is stopped and is broken into the debugger. A big limitation.

So, the way this debugging class works is that you for instance add a special button or secret key press somewhere in your app. Once this has been clicked or pressed, you instantiate this special debug class and pass it any object. This object would usually be your main class in the application. It then displays a window that contains a tree that you can drill down into and look at each and every object in your app. It updates every 2 seconds (configurable), so what you see is up to date and your app is running at full speed. So you can interact with your app and see the values change in realtime. This is a very useful debugging tool and I use it on every project I work on.

Try that using C++...

Aren't most of those slot machines in casinos all Windows Embedded? 90% of them seem to be video-screen driven, some even with touch capabilities. And would they all be done in C++?

1 hour ago, Harlequin wrote

Aren't most of those slot machines in casinos all Windows Embedded? 90% of them seem to be video-screen driven, some even with touch capabilities. And would they all be done in C++?

I wouldn't be surprised if a good portion of this kind of application is still done in VB6.

I remember many years ago that there was a push by MS to similarly use Windows in arcade games (the real ones that you feed coins into). I'm not sure where that ended up but I think they did have some success.

I found this website that has a pretty detailed writeup of arcade machine history, including which OSes were used in which machines. Although the author doesn't think developing for Windows is easier (than Linux, I guess). Hmm, ok...