I recently worked on an off-beat pet project where the idea is to convert a .Net app to something that can run natively on an ARM microcontroller (mainly to work around the fact that the .Net Micro Framework runs 3 to 4 orders of magnitude slower on a microcontroller than equivalent native code).

My initial approach was to create C++ code from the IL, and then use a traditional ARM C++ compiler to compile the code to an ARM executable. Initially I was just using VS to compile the C++ code to a native x86 executable for testing purposes, and it went reasonably well.

Once I actually started looking into the available C++ compilers for ARM microcontrollers, I realized it was a bad idea. The "decent" IDE's are all ridiculously expensive. For instance, Keil quoted me $2,695 for their basic, crippled version of their IDE that only allows 256K code to be generated, plus $4,895 for the dev kit. And the free or cheap IDEs were difficult to set up and ultimately it didn't seem like it was worth all the effort.

OK I know all of this sounds off-topic - hear me out...

My next approach was to create an ARM assembler/linker/emulator that allows me to compile the IL code directly to native ARM code. I'm quite far along with this project, and it is going well. Parts of the emulator consists of auto-generated C# code.

OK, so how is this related to this topic? Well, now that I've had a chance to write code that auto-generates both C++ code and C# code, I can say that C++ is a royal pain. It is so much easier to generate C# code where you don't need to worry about header files, forward declarators, worry about #ifdef guards, declaring static members multiple times (I mean - it's all there! Why can't the compiler figure it out - yes I know, it's a single-pass vs multi-pass thing), etc. Overall the C# syntax is just cleaner. All this unneeded complexity distracts from the real problem you are trying to solve.

In addition, the C++ compiler is way more finicky and often gives you compiler error messages that are completely unrelated to what the real error is. Well that last point might be more VS related than C++ related, but I believe it is because of C++'s nature that even the compiler is sometimes clueless as to what is really the problem. And then there is that whole debugging C++ code vs C# code thing. There is quite an advantage to the debugger being able to use reflection on your application...

I'm not 100% sure how writing code generation algorithms relate to actually writing the code yourself, but for me at least it has shown that C++ is pretty archaic compared to modern languages.

Bottom line, if I can help it at all, I'd like to stay away from C++ if I could. The problems we need to solve in code are getting exponentially more complex, and the last thing I need is to have to deal with an additional layer of complexity which modern languages have done away with.

EDIT: A few years ago I attended a talk by Bjarne Stroustrup in Berkeley CA about the future of C++. He is very passionate about C++ and I commend him for the great work he does. One thing that came through during his talk is that he is frustrated by the slow progress that C++ is making and the difficulty in advancing it. He made comparisons to C# and said something along the lines of "C++ doesn't have a sugar daddy that can push new development as fast" (yes, I believe he actually used the term "sugar daddy").