More questions, more clarifications.

Garrett asked some further questions that were also good.  Good enough, in fact, that I didn't know the answers.  So I went down the hall and asked Brandon.  I'll paraphrase what Brandon told me here.

1. What about partial types?

What are partial types?   For those of you unaware about partial types, I'll give some background.  A partial type is a single type, defined in multiple source files which are sort of “welded” together.  In the C++ lexicon, its like defining part of a class in one file, and then defining the rest in another.  Think “out-of-line-but-still-in-line definition“.  My understanding is that ASP.Net and C# will encorporate this in Whidbey (if they don't already).

Why do we need partial types?   The major usefulness for partial types in C# (and potentially C++) will be in Longhorn, where you define UI through XAML - a markup language for defining UI - and write a “code-behind” file that adds the code for the event methods, etc.  Then you put these two together, to create a single coherent type that is compiled into part of your program.  (A whole lot more on this cool feature can be found here.)  The usefulness in ASP.Net is somewhat similar to this, albeit slightly more hidden from the user.

So, will it make it into Whidbey C++?   The short answer is probably not.  We've got a lot of other great work going on, and it just doesn't seem likely right now that we'll have time for partial types in this release.  It is something that is being very strongly considered for the next release after Whidbey.  Believe me, the usefulness is apparent, it just isn't something that we can tackle right now, with everything else on our plates.  On to the second question:

2. Given the statement found on Brandon Bray's blog about "Leave no room for a lower level language on the CLR than C++." , what about inline MSIL? :)

There are actually two different reasons people want (or think they want) inline MSIL.  I'll address them seperately.

1. I want to write inline MSIL for optimization purposes, like inline ASM.   I toyed around with this misconception for a little while.  Truth is, the JIT is your optimizer.  And the JIT nets a per-machine optimization, which you may prevent by writing your own MSIL.  In short, the C++ compiler may produce less-than-optimal MSIL (prompting those Type-A's to want to squeeze that extra bit of perf out), but that's because there's another optimizer yet to come.

Furthermore, writing inline ASM isn't even a very good idea from an optimization standpoint - at best, its benefits are merely pragmatic.  At worst, it is harmful and costly. Think about inline assembler that was written five or ten years ago that's still in someone's codebase.  What type of processor was that “optimized” code written for?  Is the person who wrote that code still working for your company?  Do you update the assembler, or do you rewrite that code now (both painful and costly)?  C++ is largely platform-portable, and when compiled, produces highly optimized code for the platform compiled on.  You can't get that benefit with inline assembler.

2. I want to write inline MSIL because I can't express everything the CLR allows with C++.   This is actually the reason for Brandon's statement: “There is no language lower than C++.”  What he means by that is that we intend to represent everything feasible within the bounds of the CLR in the context of C++.  This is something that C# doesn't do - for example, sealed abstract classes.  Do they make a whole lot of sense?  Maybe not.  Does the CLR support doing it?  If it does, then we want to support it as well.  (Incidentally, it does, and we do.)  The hope is that you would never need to resort to inline MSIL to do what you want - you can just use C++ to do it.

However, C++ isn't about what we think you need to do, its about what you need to do, and there may be a justifiable reason for writing inline MSIL.  I can't really come up with one, but that doesn't mean one doesn't exist.  The design team is considering adding inline MSIL to VC++ - however, again, most likely not in Whidbey.

Great questions!

Comments

• Anonymous
  December 10, 2003
  Wow! it seems you are empowering c++ for CLR. will .net be available for non-windows platforms?
• Anonymous
  December 10, 2003
  The short answer is yes. The long answer is: check the post I just made! :)
• Anonymous
  December 10, 2003
  The comment has been removed