RSS 2.0

Personal Info:

Joe Send mail to the author(s) leads the architecture of an experimental OS's developer platform, where he is also chief architect of its programming language. His current mission is to enable writing large-scale software that is reliable, secure, and scalable by-construction. Before this, Joe founded the Parallel Extensions to .NET project. He has been granted 19 patents, with 49 pending. When not working, Joe enjoys travelling with his wife, writing books, writing music, studying music theory & mathematics, and doing anything involving food & wine.

My books

My music

Disclaimer:
The content of this site are my own personal opinions and do not represent my employer's view in anyway.

© 2012, Joe Duffy

 
 Saturday, July 02, 2005

Those guys on the VC++ team have been busy workers. In the Whidbey release of C++/CLI (was Managed C++), they've added a whole big batch of new features. The best part? Some of these are things you simply can't do in C#. Put another way, C++/CLI exposes a larger set of the underlying features that the CTS/CLI has to offer.

For example, want to create a ref type on the stack? Fine.

MyType mt("Foo");

On the GC heap? Alright.

MyType^ mt = gcnew MyType("Foo");

(Note if you're wondering "how'd they do that?" The answer is that the first case only has stack semantics. It still lives on the GC heap. In other words, it acts very similar to 'using' in C#, but it maps nicely to the C++ programmer's existing understanding of stack versus heap semantics.)

Similarly, did you want to maintain a typed reference to a boxed value type? Ok.

int^ i = gcnew int(5);

This compiles to IL which uses modopts to store typing and boxing information so that the runtime/JIT know how to treat it, and for the verifier so that it knows it's being used in a type-sound manner. Did you need a Nullable<int>? Nonsense! Just set your reference to null and you've got it:

int^ i = nullptr; // now it's null
i = gcnew int(5); // now it's not

Furthermore, with stack semantics for ref types, deterministic finalization is simple. Just write a destructor for your type (it gets compiled down to a Dispose method), and it gets invoked for you when leaving the scope. Just like the old C++ days. This means you can say:

{
    StreamReader sr(...);
    // do some stuff with stream
}

And sr gets disposed just prior to leaving the block scope. You can also create your own standard resource mgmt wrappers like that come with TR1 (e.g. tr1::shared_ptr<>). Using the terms that Rico Mariani came up with in a meeting a while back, you've got "the bang" and "the twiddle"...

!MyType() {} // the bang: a finalizer
~MyType() {} // the twiddle: a Dispose method

They've also implemented STL with full interoperability with Whidbey's generics.

They've also implemented OpenMP, a fairly ubiquitous shared memory parallelism library that I've been using a lot for research recently. Now they just need MPI and the world would be complete.

I'm using C++ for many things lately (mostly due to my Rotor work), and I have to say: as I use it more and more, I am starting to miss it. But admittedly I do sometimes prefer the cozy confines of managed code. C++/CLI enables me to nicely sit in between the two worlds, getting the best of both (and leaving behind the worst). There's a hell of a lot more to it than this post surfaces. Check it out.

Happy hacking!

7/2/2005 10:48:50 AM (Pacific Daylight Time, UTC-07:00)  #   
Tracked by:
"Interesting Finds this holiday weekend" (Jason Haley) [Trackback]

 

Recent Entries:

Search:

Browse by Date:
<February 2012>
SunMonTueWedThuFriSat
2930311234
567891011
12131415161718
19202122232425
26272829123
45678910

Browse by Category:

Notables: