Why can\'t a compiler be written that manages what needs to be managed in C++ code (i.e. to make it \"CLR compatible\")?
Maybe with some compromise, li
I think this is because adding managed code features into C++ would made C++ slower and the compiler more complex. So much so that C++ would lose what it's designed for in the first place. One of the nice things of C++ is that it's a nice language to work with, it's low-level enough and yet somewhat portable. And probably that's what the C++ Standard Committee plans to made it stay that way. Anyway I do not think C++ can ever be fully "managed", because that would mean programs written in C++ needs a VM to execute. If that's the case, why not just use C++/CLI?
The .NET CLR requires that no reference to a managed object can ever exist anyplace the run-time doesn't know about except while the object is pinned; good performance requires that objects be pinned as little as possible. Since the .NET CLR cannot understand all of the data structures that are usable within C++, it's imperative that no references to managed objects ever be persisted in such structures. It would be possible to have "ordinary" C++ code interact with .NET code without any changes to the C++ language, but the only way the C++ code could keep any sort of "reference" to any .NET objects would be to have a some code on the .NET side assign each object a handle of some sort, and keep a static table of the objects associated with the handles. C++ code which wanted to manipulate the objects would then have to ask the .NET wrapper to perform some operation upon the object identified by a handle. Adding the new syntax makes it possible for the compiler to identify the kinds of objects the .NET framework will need to know about, and enforce the necessary restrictions upon them.
Existing correct code, i.e. code written according to the C++ standard, must not change its behaviour inadvertently.
Why can't you compile native C++ code targetting the CLR?
Yes, you guessed it right, there would be too many compromises, that would make it useless. I'd like to name just three examples...
1.) Templates: C++ supports them, the CLR doesn't (generics are different). So you couldn't use the STL, boost etc. in your code.
2.) Multiple inheritance: supported in C++, not in CLI. You couldn't even use the standard iostream class and derivatives (like stringstream, fstream), which inherit both from istream and ostream.
Almost none of the code out there would compile, you couldn't even implement the standard library.
3.) Garbage collection: Most C++ apps manage their memory manually (using smart pointers etc.), the CLR has automatic memory management. Thus the C++ style "new" and "delete" would be incompatible with "gcnew", making existing C++ code useless for this new compiler.
If you'd have to root out all the important features, even the standard library, and no existing code would compile... then what's the point?
Qt framework does almost that. I.e. it has smart pointers, that automatically set to null, when the object that they point to is destroyed. And still it's a native C++, after parsed by moc(meta object compiler).
I agree with 5hammer ! If I left Java and other managed languages that's not for nothing : that's to have FULL control over the computer, access memory manage memory myself, have control over how the computer will run my code, integrate with C libraries (such as Lua). If I loose that flexibility, then I would just leave C++ and fall back to C, and if C becomes managed too, then I would go to assembler.
Managed languages are the worst ones ever for all gaming platforms/complex programs as they are bounding you in some kine of sandbox with no direct access to the hardware, and are much slower than compiled languages.
The main purpose of C++ had always been Performence. It's one of the best language for big Games. And without this language performences a lot of games would not exist !