Hello CPUWizard,

You obviously are an experienced programmer. I have a big problem and maybe you can help me. We have to start a new project (windows/desktop/graphics). So far I have only used C++/MFC; I have no experience with C# or C++/CLI. I have read a few articles about C# and C++/CLI and I realize I do not know enough about these languages and yet I must quickly decide which one is suitable for this kind of application and start learn it. The application will be large (hundreds of thousand of lines) and will, probably, use large portions of a similar, but older, application written in C++/MFC.

I have the feeling C++/CLI is a more suitable language... but don’t ask me why, maybe because of the below qoute (Bjarne Stroustrup's FAQ).


Thank you.

“
What do you think of C#?

I have no comments on C# as a language. It will take a lot to persuade me that the world needs yet another proprietary language (YAPL). It will be especially hard to persuade me that it needs a language that is closely integrated with a specific proprietary operating system.
If you want to write exclusively for the .Net platform, C# isn't the worst alternative, but remember that C++ is a strongly supported - though less strongly hyped - alternative on that platform.

What do you think of C++/CLI?

C++/CLI is a set of extensions to ISO C++ that provides an extremely complete "binding" of C++ to Microsoft's CLI (Common Language Infrastructure). It has been standardized by ECMA (ECMA-372). I am happy that it makes every feature of the CLI easily accessible from C++ and happy that C++/CLI is a far better language than its predecessor "Managed C++". However, I am less happy that C++/CLI achieves its goals by essentially augmenting C++ with a separate language feature for each feature of CLI (interfaces, properties, generics, pointers, inheritance, enumerations, and much, much more). This will be a major source of confusion (whatever anyone does or says). The wealth of new language facilities in C++/CLI compared to ISO Standard C++ tempts programmers to write non-portable code that (often invisibly) become intimately tied to Microsoft Windows.
The CLI provides a set of interfaces (to system facilities) that are very different from traditional interfaces to operating system facilities and applications. In particular, these interfaces have semantics that cannot be completely or conveniently expressed in conventional programming languages. One way of describing CLI is as a (partial) "platform" or "virtual machine". It consists of a large set of language features (inheritance, methods, loop constructs, callback mechanisms, etc.), supporting a large set of foundation libraries (the BCL), plus an elaborate system of metadata. The CLI is sometimes described as "language neutral". However, a language that doesn't accept a large subset of these facilities cannot use even basic .Net facilities (or future Microsoft Windows facilities, assuming that Microsoft's plans don't change) and a language that cannot express all of these features cannot be used for the implementation of resources meant to be usable by other languages. Thus, CLI is "language neutral" only in the sense that every language must support all of the CLI features to be "first-class" on .Net.
I prefer a binding to be a few primitives, expressible as simple function calls and simple data structures in any language, possibly encapsulated in language-specific libraries. For the CLI, this can at best be done for consumers of CLI facilities only. A language used to produce CLI modules must be able to express all of the CLI facilities, including the metadata. Only a language that can do that can be considered a systems programming language on .Net. Thus, the Microsoft C++ team concluded that only build-in language facilities are acceptable to their customers. Their design reflects a view that accepts absolutely no restrictions on what part of CLI can be expressed in C++ with the C++/CLI extensions, absolutely no verbosity compared to other languages when using CLI facilities, and absolutely no overheads compared to other languages. They aim at preserving C++ as the dominant systems programming language for Windows.
As ever, I place a heavy emphasis on portability and recommend people to design applications so that access to system-specific facilities are through well-defined interfaces specified in ISO C++ (e.g., not to use C++/CLI directly). On Windows, this will sometimes be inconvenient compared with using C++/CLI facilities directly, but it's the only way to gain portability and a degree of vendor independence. Obviously, that arms-length approach to the CLI cannot be maintained if the purpose of a piece of code is to provide a CLI interface to be consumed by other code. Please note that I recognize the need for system-specific extensions and that Microsoft is not the only C++ vendor with such extensions, I just strongly prefer to deal with such extensions though a "thin interface" specified in ISO standard C++.
How to deal with system-specific extensions is inherently a difficult question. The Microsoft C++ team, especially Herb Sutter, has kept up an active dialog with (other) members of the ISO C++ standards committee so that the relationship between ISO C++ and its superset C++/CLI will eventually be worked out. We have a long record of constructive joint work in the ISO C++ committee. Also, to minimize confusion between ISO C++ and the C++/CLI extensions, Microsoft is now revising their Visual C++ documentation to try to clearly distinguish C++/CLI from ISO C++ (plain unqualified C++ means ISO C++). I hope others will follow that lead.
On the difficult and controversial question of what the CLI binding/extensions to C++ is to be called, I prefer C++/CLI as a shorthand for "The CLI extensions to ISO C++". Keeping C++ as part of the name reminds people what is the base language and will help keep C++ a proper subset of C++ with the C++/CLI extensions. The C/C++ compatibility problems demonstrate how important it is to keep that subset property.
“