I Love that New Syntax Smell : musings

Corrections, explanations, etc.

arich — Wed, 26 Nov 2003 00:32:00 GMT

First, I should apologize for the lack of postings lately. A combination of server downtime/outages and apathy have kept me from making postings. Now that we're back up, I think I should clarify some of what I've said.

Value types aren't as grand as I make them out to be. They're designed by the CLR to be very lightweight, stack-based, blittable items. Nothing fancy. You can't define a default constructor for them. For Whidbey, we were attempting to extend the functionality and usefulness of value types, but the design team has determined that we shouldn't (for a variety of reasons). Really, in most cases, you're going to want a ref type. The value type incurs extra cost if you want to put it on the gc heap (something I may address later, called boxing). The value type is simply the CLR exposing for users the same type that it uses internally for the fundamental types - ints, floats, etc. Users should try to hold true to this concept. So, the instances where a value type are appropriate are actually fewer than I originally stated.

My stack example isn't as nice as it ought to be. I thought it would well demonstrate what my concept of value types vs. ref types is, but, the more I look at it, the more I believe I should have made the Node a ref type. (Largely in part to a redefinition of my thinking on value types, as explained above.) But, I'll leave it up as it is for now.

Someone made a request for explanations of the sources that I'm posting. In the future, I'll make an effort to explain what I'm up to in my code. Another example should be forthcoming.

Also, if you have any suggestions for what I should try to tackle, post comments or suggestions, or shoot me an email at arich@microsoft.com.

Context-sensitive keywords

arich — Fri, 07 Nov 2003 20:29:00 GMT

If you've used Managed Extensions, you're familiar with the CLR types that __gc and __value exposed. These have now been replaced with the context-sensitive keywords ref and value.

Context-sensitive keywords? That's right. We've made huge efforts (especially with respect to IJW work) to ensure that we don't break our users' code in our haste to add new features. That's why most of the CLR features exposed by Whidbey will only be keywords in the right context. So, if you've already got an identifier named value - and who doesn't - don't worry. Compiling with /clr isn't going to break that.

You can still create classes just like you always have. With the added CLR types, most of us refer to conventional C++ classes as "native types." We expose the new CLR types as extensions of regular classes. Where you might have class A{}; before, you now have ref class A{};. Now you're dealing with a CLR type, and all the benefits that provides, all without breaking exisiting code.

This is really at the heart of what sets this new implementation apart from Managed Extensions. It has an integrated feel into the original language, without breaking existing code, and __without __all __those __ugly __double __underscores. The code looks and feels natural.

That crazy GC Heap

arich — Fri, 07 Nov 2003 04:36:00 GMT

If you're like me, the whole idea of a garbage collected heap seems, at first, contrarian to the C++ coder's mentality. As a breed, we'd prefer to handle memory (de-)allocations completely on our own. But if you're like me, and you've spent hours trying to figure out where that memory hole is coming from, then maybe the idea of a GC has looked good, from time to time.

Coding can take on a slightly different feel when you're working with a GC. You may feel a little sloppy, at first. C++ programmers have been conditioned to cover all their bases, watch their backs, and in general be as careful as they possibly can be. Coding with a GC frees you from some of these constraints, so it can feel a little "loosey-goosey" at first.

But in my opinion, having a GC is mighty nice. It's like visiting a hotel. Don't make the bed, don't scrub the toilet; that's what the cleaning staff is for. Just enjoy the nice, clean room. Having a GC do the dirty work for you frees you up to concentrate on more important details.