On 11/4/2012 6:19 PM, Edward Diener wrote:
C++/CLI does not pretend to be C++. It is a dialect of C++ for .Net programming but nobody of any experience views this as the official C++ language.
Your rant against things like C++/CLI and C++/CX is ill-founded IMO. Language vendors certainly have the right to create a new language from an existing language for their own use and their customer's use. I think you are being intolerant to think otherwise. If Microsoft has said anywhere that C++/CLI or C++/CX is standard C++ I would like to see it.
Sure they have the right to do it. That doesn't make it good design, that doesn't make the way they go about it ethical, and that doesn't make it good for C++ as a whole. Regardless, as I've said, I wouldn't have nearly the vitriol toward MS if they actually implemented the language. No marketing, no "subtle" maneuvering, just implement the language. They go on and on, especially in the last year or two, about the "C++ renaissance" and their commitment to C++, but then they develop yet another set of their own extensions instead of C++.
There are probably few serious C++ expert programmers who do not agree with you that language vendors should support the C++ standard. But that is very different from mandating that language vendors should only be allowed to support a language standard and not be allowed to create another similar language for their own purposes.
I'm not advocating mandating anything. Microsoft should either say they support C++ and then actually do it by implementing the language (completely--no "won't fix"), or they should say that they don't support C++ and step aside--developing whatever C-flat that they want.
Actually C++/CLI is a very good language for .Net programming but Microsoft's support for it has been abysmal, so that it is hopeless to use it ( as opposed to C# ) for any serious largescale .Net programs or modules.
This has nothing to do with C++, but there is no such thing as a good language for .Net programming. It isn't a good runtime model. Take away the .Net Framework (which is bloatware anyway--std::string x 1000) and what do you have? You have a fairly generic ho-hum language that bubbles implementation detail (in the form of any type of non-memory resource management). Now implement the .Net Framework, bloatware and all if you like, as a C++ API, and you have everything that C# actually offers sans reflection--which is frequently overused to paper over poor design. The point is, of course, that C# strength is *not* its language, but rather its extensive library--however poorly implemented. I look at that and say, "Why isn't that easily available in C++?" The answer, IMO, is largely because libraries target *compilers* rather than C++. Regardless of what gets added to the standard library, it will *never* be enough. What's needed is for compiler vendors to approximate the language to the greatest degree possible such that the standard acts as a contract between compiler authors and compiler vendors. That is priority one for C++ to move forward. More libraries in the standard library is good, but unnecessary. There is only one thing that is really necessary. Regards, Paul Mensonides