C++/CLI: The Most Powerful Language for .NET Framework Programming

My latest article is now live on MSDN. It should be headlined on the Visual C++ Developer Center soon.

C++/CLI: The Most Powerful Language for .NET Framework Programming
Summary: Explore the design and rationale for the new C++/CLI language introduced with Visual C++ 2005. Use this knowledge to write powerful .NET applications with the most powerful programming language for .NET programming.

This article tells a story about the new C++/CLI language design that I have wanted to share for some time now. I actually wrote this about six months ago, before any compiler was available to implement any of the new language features (don’t ask me why it took so long to publish). The language specification was very helpful in getting to know the new language design.

Many thanks to the Program Managers on the Visual C++ team for their helpful feedback on the draft of this article. Special thanks to Herb Sutter for taking the time to review the article and providing some very helpful feedback.

Visual C++ 2005 is a great product. Kudos to the entire team for delivering such an awesome compiler.

After reading my article I’m sure you will want to start playing with the compiler immediately. Keep in mind that some of the capabilities I describe in the article are not yet implemented in Beta 1.

Have fun!

© 2004 Kenny Kerr

 

7 Comments

  • Great article. I really like the new implementation of the CLR support. It "feels" right.

  • The described destructor operator ! does not work with .NET 2.0 beta1 compiler.

    Does it mean that this feature is not implemented yet or it is just excluded from the language?

  • Gabriele: Thanks! I like it too. :) It certainly does feel right.



    D.P.: As I mentioned in this post, there are a number of features that have not yet been implemented in Beta 1. Most notable is stack-semantics for CLI reference types. Fortunately we can expect everything I described to be included in the release candidate.



  • 1. In the article, 2 lines in each of 2 places (total 4 lines), should m_value be m_name?



    property String^ Name

    {

    String^ get()

    {

    return m_value; // m_name?

    }

    void set(String^ value)

    {

    m_value = value; // m_name?

    }

    }



    If not, then it seems that 18 different properties with 18 different names would all use 1 member variable named m_value.



    2. Unboxing, "int c = *hi;", makes the dereference as clear as everything in C++. Boxing doesn't. "int^ hi = 123;" is grammatically unambiguous to compilers but not to humans. It might be better if this remained as "int^ hi = __box(123);" or maybe something involving the gcnew operator.

  • In the base note, the words "language specification" are a broken link. download.microsoft.com responds to ping but Internet Explorer says the site is unusable.

  • 8/3/2004 8:18 AM Kenny Kerr:



    > Boxing is implicit as it is more often than

    > not what the programmer intended.



    Yes boxing is what the programmer intended. But that is not a reason to make the syntax confusing. The syntax LOOKS a lot like the way an integer constant (to be used as an address) could be assigned to a pointer variable. Again, there is no disagreement over what the programmer intended, only whether the syntax should resemble familiar operations that had somewhat parallel effects (my preference) or whether the syntax should resemble different familiar operations that had drastically different effects (the preference of you and your colleagues).

  • If the keyword "nullptr" were "nullhdl" or "nullhandle", that would also help avoid confusion. Everyone agrees on what its meaning is, I only propose to make the syntax match the meaning.

Comments have been disabled for this content.