C++/CX – keeping C++/CLI syntactically alive

As most of you already know by now, the C++ Component Extensions (or just C++/CX) introduced in Visual C++ 11 will basically use the C++/CLI syntax with minor differences. Someone asked me on Code Project what I thought of that and I replied to him, (paraphrasing here) – “Years of using an unpopular syntax to code in C++ is finally going to pay off”. I also believe that the very reason we are getting intellisense for C++/CLI now is that they had to do that for C++/CX anyway, so they (as in the VC++ team) may well have thought they’d do it for C++/CLI as well. Obviously while there are syntactic similarities, they do target entirely different data/code/memory models – so that has to be kept in mind. One of them is for garbage collected .NET while the other is for ref-counted native code/COM (WinRT). I will be blogging more on C++/CX here in the next few weeks/months. So if anyone’s interested in that stuff, stay tuned.


The future of C++/CLI

With all the unverified but reasonably believable rumors about the new Windows 8 API (Jupiter) and how it supports managed and native APIs, questions can be raised as to the need or use of C++/CLI as a Windows programming language. Well here are a few reasons why I think C++/CLI won’t go away and will continue to remain a minimally used but very important citizen in the Windows programming language world.

  • Windows 7 and Vista, and possibly XP are not going away anytime soon. Apps that run on those OSes can continue to benefit from the mixed mode capabilities of C++/CLI.
  • Even on Windows 8, assuming the core API offers managed and native versions with full functional parity, there is still the fact that 3rd party code and customer legacy code bases will continue to exist as a nice mix of managed and native libraries. So interop will still be a key requirement in any significant software attempt, and thus C++/CLI as well.
  • The next version of Visual Studio brings back support for intellisense with C++/CLI. I am pretty sure they won’t go that far without solid enough reasons to back the fact that C++/CLI will continue to have a role to play.
  • Large corporate apps may have multiple teams working together, some with managed coding skills, others with C++ skills. C++/CLI can still play a useful role to unify the different code bases for common use.

That said, I do not see C++/CLI being used as a first class managed language. Its solitary purpose would be as an interop bridge.

And does this mean I’ll write an update for my C++/CLI book? Unlikely! Even if there’s new stuff to write about, it won’t be significant enough to bring out a 2nd edition. I’d rather write an article and publish that directly. Faster, simpler, and so much more straightforward.

Mixed-mode scenario with tracking handles to value types

This question was recently asked in the MSDN forums and answered by myself, and I am blogging it here so I have a page to link to if something similar gets asked again in that or some other forum. The OP had a C# caller that called a mixed-mode DLL’s method that took 3 arguments of type int%. This mixed-mode method then called a native function that took 3 arguments of type int* and modified all three of them. The OP was confused as to how to pass the int% values passed from C# to the native method. The central issue was that although int is a value type, int% is a tracking reference and needs to be pinned first. Once you do that, you just pass it to the native method. Example code snippet:

void nativefunc(int *p1, int *p2, int *p3)
  // . . .

void managedfunc([Out]int% mp1, [Out]int% mp2, [Out]int% mp3)
  pin_ptr<int> p1 = &mp1;
  pin_ptr<int> p2 = &mp2;
  pin_ptr<int> p3 = &mp3;

  nativefunc(p1, p2, p3);

Splitting a C++/CLI property’s definition and implementation into separate cpp/header files

I got asked this in one of my article forums, and thought I’d blog about it here so I can just direct people to a single URL if the question comes up again. Here’s how you’d do it (I used the example property the OP used):

//The header file

ref class Test
  property Byte default[int]
    Byte get(int index);
    void set(int index, Byte value);


//The cpp file

Byte Test::default::get(int index)
  return 0;

void Test::default::set(int index, Byte value)


VC++ 2010 : C++/CLI does not support variant delegates/interfaces

I just reported this bug on Connect :

.NET 4.0 supports covariance and contravariance in delegates and interfaces. Unfortunately, C++/CLI does not support this as of VC++ 2010 RTM. Considering that the most popular use for C++/CLI today is as an interop language, the compiler not supporting a feature that’s going to be heavily used in the BCL and in new C# libraries is a very serious problem. It will impose limits on how effective C++/CLI will be as an interop-language.

If you think this is a serious enough problem, please vote the bug up so it gets more attention. Thank you.

Visual Assist X gives VC++ 2010 intellisense for C++/CLI

The lack of intellisense has been the biggest show-stopper for using VC++ 2010 for any managed or mixed mode programming. Many people could not make the upgrade from VC++ 2008 for this very reason. Fortunately, the latest version of Visual Assist X from Whole Tomato Software provides fully functional intellisense for C++/CLI code! VA has always been a truly impressive add-in for VC++ users for a decade or so now, and with this update they make it obvious why they are still one of the most popular and most useful add-ins for Visual C++.

For anyone doing C++/CLI in VS 2010 and totally frustrated with the Notepad like editing experience, or for anyone holding off on upgrading to VS 2010, I strongly recommend Visual Assist X. I’ve been using it for a couple of weeks now and I have not noticed any performance issues with VS 2010 although I am on a very fast machine with heaps of memory. That said, there are several other improvements and refactoring features that Visual Assist X provides but I was primarily evaluating it for the C++/CLI intellisense.