I Love that New Syntax Smell : post responses

Properties Part 2 - defining default properties

arich — Thu, 11 Aug 2005 03:10:00 GMT

Disclaimer. This is an ancient post. By the looks of it, I originally intended to write this almost a year ago, as a follow up to my scalar properties writeup. That was back when I was testing properties (and more exactly, default properties) and some of the design was still in flux. Now it's pretty nailed down (there's very little time to change it for Whidbey, anyhow), and it dawned on me that I hadn't posted this material. So, I'll do it now, with a bit of fixup.

The Way C# Does It. Reader Rob Walker asked over a year ago:

Why do I have to specify the type of the property 3 times in the definition? It makes this new syntax more verbose than the old. Why not just adopt the C# style?

Let me start by mentioning that I'm not a member of the design team. I've been included on various discussions that take place regarding the syntax, but I haven't been the one making the decisions. I can only make guesses as to their reasonings (or ask them). Either way, the reasoning is my own.

I believe there are two reasons why we wouldn't adopt the C# style. First, there's an existing property syntax that users are familiar with. The changes between the two syntaxes are somewhat minor. Second, the C# property syntax doesn't fit well with C++ paradigms. Though simple, I imagine the syntax could wreak havok on parsers, and could introduce a number of ambiguities in the language. One of the goals of adding CLI to C++ was to not break existing paradigms, where possible. Finally, the designers wanted to do what felt natural to C++ users. C++ users aren't familiar with functions that have no parameter lists, that's unusual.

Speaking of how C# does it, here it is:

public class ArrayWrap {
public ArrayWrap(){ arr = new int[10]; }

public int this[int idx] {
get{ return arr[idx]; }
set{ arr[idx] = value; }
}

private int[] arr;
}

And here's code to produce the equivalent class in C++:

public ref class ArrayWrap {
public:
ArrayWrap(){ arr = gcnew array<int>(10); }

property int default[int] {
int get(int idx){ return arr[idx]; }
void set(int idx, int value){ arr[idx] = value; }
}

private:
array<int>^ arr;
};

We stole the default keyword and co-opted it for use in indexed properties. Note that you still make use of the property keyword. When this comes out in IL, it looks almost exactly like the C# indexer - with the default property being named "Item" and the getters and setters also thusly named. You can change the name of the default property by using the attribute System::Reflection::DefaultMember on the class. The compiler sees this attribute and interprets it to mean that the default member you created in the class should be named whatever you pass in the attribute ctor.

A weird IL trick leads to another way you can generate a class with a default indexer using that attribute. In IL, a property is a default indexer if it meets two requirements: 1) it is an indexed property, and 2) its name matches the name in the DefaultMember attribute. So, you can actually generate a default member in C++ using code like this:

[System::Reflection::DefaultMember("Foo")]
public ref class ArrayWrap {
public:
property int Foo [int] { ... }

However, I do not recommend this approach, except as a possible way to workaround bugs, or to obfuscate for fun, as the C++ compiler will not recognize Foo as a default property when compiling, only when importing. Also, although it is legal in IL, I do not recommend using this trick to make default scalar properties. That's just unpleasant.

In a future posting, I'll go over the various ways you can access properties, which may come in handy as workarounds.

Another good customer bug

arich — Mon, 13 Sep 2004 17:28:00 GMT

Reader Andy Neilson writes in with another bug:

The current compiler implementation has some problems. If the variable is a field of this, then the compiler will die. For example:

class MyClass {
public:
int i;

void Foo() {
   array<int>^ x = {1, 2, 3};

for each (i in x) {
    if (i == 2) break;
    }
}
};

This is also a bug. I'll file it in our bug tracking database. I'm not sure what the design decision will be; it feels like we should disallow the construct you show - but I'm not certain. I found a "sort-of" workaround; you can use a tracking reference to an integer to do it, such as:

void Foo() {
array<int>^ x = {1, 2, 3};
int% a = i;
for each (a in x) {
...
}
}

Thanks for the bug report!

I love when customers find bugs!

arich — Thu, 09 Sep 2004 20:12:00 GMT

Reader Rob Walker asks:

Is there a neat way of handling dictionaries? I have a Dictionary<Guid, Object^> and want to iterate over the values.

Currently I have to use the syntax:

for each(KeyValuePair<Guid, Object^> v in dict)
{
v.Value ...
}

I can't find an invocation that would allow

for each (Object^ v in dict->Values)

(This is using the Whidbey beta 1 compiler refresh).

I imagine, Rob, that you're getting what I'm getting from the compiler, which is:

error C3285: for each statement cannot operate on variables of type 'overloaded-function'

That just doesn't seem right to me. In fact, I made an incredibly simple case, and tried it with a very recent compiler:

using namespace System;

ref struct R{
property array<int>^ p;
};

int main(){
R^ r = gcnew R;
for each( int i in r->p ){}
}

And this also gives me that same error. I talked with the guy responsible for testing for each, and he confirmed my suspicion - that's a bug. Good catch! I've filed it in our bug tracking database, and shot it over to the proper developer. (With a note that this bug came from a customer - which always raises bug priority.)

In the meantime, there's a pretty simple workaround. You should be able to get around this problem by calling the property accessor method directly. In my case, that'd be r->p::get(), and in your case, it'd be dict->Values::get(). That should allow you to use for each on that collection.

By the way, I'm sort-of touching on bits of the property syntax which I haven't discussed yet in this blog. I'll try to get back to that subject after DF.

.NET, 7.0, 2003, what's it all mean?

arich — Fri, 09 Jul 2004 16:53:00 GMT

A reader asked the question:

Is .NET, in fact, the SAME THING as Visual Studio 7.0? Could it be possible that a developer with .NET would be able to simply open the project file and recompile without rewriting code?

.NET itself is a runtime. Unfortunately, the word ".NET" has started creeping into a lot of our product names, including our latest Server OS, and a few versions of Visual Studio. Visual Studio .NET is, indeed, version 7.0. The latest public offering, Visual Studio .NET 2003 (codename Everett), is version 7.1. The next product we're going to offer, codename Whidbey (and named externally as Visual Studio 2005), is version 8.0.

(I have a little more on this subject here: http://blogs.msdn.com/arich/archive/2003/12/17/44187.aspx)

You'd have to talk to marketing as to why we can't use release names that make sense. Believe me, they make no sense inside the company, either. (At least the next version won't have ".NET" in the product name. That was starting to bug me.)

Furthermore, you should be able to open a VS7.0 project file in VS7.1 (.NET 2003). Upon opening it, the IDE will ask if you want to convert the project to 7.1. Be warned, however, that this conversion is *not* reversible.

As to your question about being able to take 7.0 code into other versions, and compile immediately, the answer is most usually no. Improvements, bug fixes, and conformance all tend to hurt a compiler's backwards compatibility, and occasionally, we find it necessary to “break“ our upgrading customers in the name of progress. We try to do this as infrequently as possible. For help on converting from 7.0 to 7.1, I suggest you check out the breaking changes article on MSDN.

Pointer to String chars - Everett style

arich — Mon, 22 Dec 2003 22:51:00 GMT

Garrett asked:

If the source text is in a CLR String, and we want to pass(even read-only) to unmanaged code, it appears that there is no way to get a pointer to the String's buffer directly. We have to use the marshalling stuff to get it there, which in itself makes a copy.

Given that one of managed C++ and CLI/C++ 's goals (imnsho) is to facilitate leveraging existing native c++ code, has any thought been given to this?

Can I get a native pointer to the data in a CLR String? The short answer is yes, so long as you don't mind a wchar_t* - which is native analog of the actual backing store type for a CLR String (the CLR type System::Char). Even in Everett, we supported doing this. You have to use a special function in order to get at it, located in the header file , which shipped with Everett. This header file includes a function, PtrToStringChars, which takes a String* and returns a wchar_t __gc*. You can use the returned pointer - called an “interior pointer” - to munge with the string data in a fairly intuitive “native” way, as in this example code:

#using <mscorlib.dll>
#include <vcclr.h>
using namespace System;

int main(){
String *s = S"abcdefg";
wchar_t __gc* pc = PtrToStringChars(s);
for(int i=0; iLength; i++){
*(pc+i)+=1; //increment each character in the string
}
Console::WriteLine(pc); //writes "bcdefgh"
}

Yeah, but I wanted to use a native function. I'm getting there. Now, you can't convert from a __gc* to a __nogc* (“native pointer“), but you can convert from a __gc* to another type - __pin* - which has a conversion to a __nogc*:

#using <mscorlib.dll>
#include <vcclr.h>
using namespace System;

int unmanagedStrLenFunction(wchar_t *c){ //counts the length of c
int count=0;
while(*c){
count++;
c++; //heh
}
return count;
}

int main(){
String *s = S"abcdefg";
wchar_t __gc* pc = PtrToStringChars(s);
wchar_t __pin* ppc = pc;
int x = unmanagedStrLenFunction(ppc);
Console::WriteLine(__box(x)); //writes "7"
}

I could have turned the result of PtrToStringChars directly into a wchar_t __pin* directly, but I wanted to make it absolutely clear.

Wow! Pin pointers are cool! I'm going to use them everywhere! Whoa there, trigger. There are a few things to keep in mind about pin pointers:

They can be extremely costly. The pin pointer works by literally pinning the enclosing type down, so the GC collector can't move it around when its doing collections. Do this too often, or keep the pin pointer around for a relatively long time, and you're seriously hurting the performance of the garbage collector - not a good idea.

They can't be used everywhere. By design, because of the costliness and lifetime problems involved with pin pointers, they can't be: members of a type, function return types, function parameters, or temporary variables.

Pin pointers only pin objects for their lifetime. This leaves open the possibility of GC holes. That is, you can get a native pointer to the GC, release the pin pointer, and then leave yourself a huge GC hole. For example:

__gc class A{
public:
int i;
};

int* gchole(A* a){
int __pin* p = &(a->i);
return p;
}

What's so wrong with that code? On the surface, it looks pretty benign. But remember that the object passed in (a) is only pinned for the lifetime of the pin pointer p. So, when the function returns, you have a native pointer into the GC heap, which would be safe, except p has been destroyed. So, instead, you have a GC hole. The pointer returned from the function gchole is only going to be valid until the next garbage collection - and who knows when that will happen. In short, don't do this, if you want to avoid unexplainable, untraceable, unreproduceable application crashes.

Back to the original question, what about regular char*'s? No chance, not without incurring a copy cost (either by using API functions that turn wchar_t*'s into char*'s, or by marshalling).

In a future article, I'll describe the new syntax versions of the pinning and interior pointer, and some of the (mostly minor) differences.

The native heap/managed heap barrier

arich — Mon, 22 Dec 2003 19:15:00 GMT

Garrett asks:

You mentioned:

class A{}; array^ arr = gcnew array(10);.

Are you saying that whidbey will support this? What is it doing to the native pointer? Boxing?

Managed array of native pointers to native objects? This didn't work in Everett, but it will in Whidbey. It probably wasn't a hard fix. Let's look a the simple case, having a native pointer inside of a managed object on the GC heap. Take the following example:

class N{}; //some native class
ref struct R{
N* pn; //native (__nogc) pointer to native class
R(){ pn = new N; }
};

But can't the GC heap move objects around at will? Yes, it can. This was puzzling to me for a while, also. Look closely at the constructor for R. We are calling new on the native object. Not gcnew, just regular new. So, the native object is going on the native heap. The pointer to that object might be inside R, on the managed heap, but the location the pointer is referencing won't move. Imagine it like a rubber band, one end tacked down in the native heap, the other in the GC heap. The native side holds still, doesn't move. The managed side might be relocated, but the pointer still points to the same position in the native heap.

Clarifications on the array template, and some about the CLR namespaces

arich — Fri, 19 Dec 2003 19:18:00 GMT

Garrett returns with some observations:

Damn Cool. My only reservation is that it doens't *resemble* a native array, but that's ok too :) In some ways that is far better than the alternative. I was never quite thrilled about the cryptic nature of managed arrays before.

Yeah, us either. That's why we did it. :)

Is then the syntax for a managed array of managed objects:
array<Object^>^ array = gcnew array<Object^>(10); ?

Otherwise, I would assume that if you didn't need the ^ inside the <> you wouldn't be prepared for native garbage collected types in a post Whidby release.

Yup, you hit the nail on the head. I only showed value types, for simplicity's sake, but ref types you'll also want to be able to put in a managed array. And yes, the syntax you've provided is correct. If you want a size 10 array of managed strings, you do array<String^>^ strarr = gcnew array<String^>(10);.

And your reasoning seems valid, too. It is worth pointing out that you can also do managed arrays of native pointers to native types: class A{}; array<A*>^ arr = gcnew array<A*>(10);. I'll let you fill in the blanks as to where we can take that post-Whidbey.

Garrett also asks:

I notice that the namespace using went from
   #using <mscorlib.dll>
   using namespace System;
to
   using namespace stdcli::language;
Is there a new "mapping" of namespaces going on here? Is the "System" namespace replaced with "stdcli::language" ?

No, and its totally my fault for not explaining what was going on. This is why you should never rush blog posts, people! :)

First, why the #using <mscorlib.dll> disappeared. In Managed Extensions, you compile with /clr, and then are required to put the #using at the start of every file. When doing Whidbey C++, we realized that if we're requiring it at the start of every file, we could just put it in for you, so we did.

Second, about the namespaces. The System namespace still exists, and is quite vital. A lot of stuff is under that namespace. But in my example, I didn't use anything from that namespace (except for the one System::Console::WriteLine, which you'll notice was fully qualified). Its the array type that is in the stdcli::language namespace, along with a few other types (pin_ptr and interior_ptr, which I'll talk about at a later date).

The justification for putting the array type in that namespace is pretty straightforward: people have array as an identifier all over the place. We simply couldn't make it a general keyword and break them. So, we put it inside a namespace. That way, you could have array as an identifier, and then fully qualify the stdcli::language::array type when you wanted to use it. Or, if you were writing a new program, or knew you had no instances of an identifier named array, you could just do a using on the namespace safely.

If you ever wonder about why the language design team made a choice they made, you can almost always be certain the reason is because they didn't want to break existing users. They make every effort not to.

Why you ought not pre-jit, and why it sometimes makes sense.

arich — Fri, 19 Dec 2003 18:51:00 GMT

So, Raj asks:

Thanks for the explanation but what is the deal with the IL and JIT. Why not just prejit the code?

Why not pre-jit the code? Class, you didn't do the required reading. :) Actually, there are a couple of optimization reasons why you don't pre-jit code. Most of it deals with this basic tenet: the JIT is around when the compiler isn't. It can know things about the runtime environment the compiler has no way of figuring out, and perform other optimizations.

The JIT only generates the code it needs to. It doesn't need to generate the code for a method that the program isn't going to use on a particular execution, so you don't incur the cost of jitting your entire program every time. Only what needs to be is jitted, and the rest is jitted as necessary.

Agressive Inlining. No, this doesn't mean buying a step-up kit for your rollerblades so you can go grinding. Basically, it allows methods that are called often to gain a speed advantage over methods that are called less often. The native C++ backend has something similar, called POGO (Profile-Guided Optimization). But even that can't optimize as specifically as a JIT can - the JIT can optimize each time the program is executed.

But, what if I still want to pre-jit? Well, you still can. We provide a tool with the framework called ngen.exe, which allows you to take the cost of jitting the code once, say, at installation time. You gain the advantage of faster start-up time, but you lose the advantages listed above (among others that are more technical than I can explain well). The author of the article I linked to mentions two places where you might want to pre-jit:

The first situation is where you call an enormous number of methods early on in your program. You'll have to JIT a lot of methods up front, resulting in an unacceptable load time. This is not going to be the case for most people, but pre-JITing might make sense if it affects you. Precompiling also makes sense in the case of large shared libraries, since you pay the cost of loading these much more often. Microsoft precompiles the Frameworks for the CLR, since most applications will use them.

So, there's a time and a place for everything. In fact, we're still fully supporting native C++ compliation in Visual C++ Whidbey, because sometimes a native program makes more sense than a managed one. (For example, device drivers.) But by and large, you want to write managed code, because its easier and more portable, and you want to use the JIT, because in most situations it is to your advantage to do so.

Dave strikes again, a basic description of how .NET works.

arich — Fri, 19 Dec 2003 03:30:00 GMT

Dave asks:

i have tried some UI examples in the book, but it was quite slow. when I execute the program, it takes 1.5-2seconds to see the window on the screen, on the other hand plain win32 api creates window before 1st second. doesn't .net generate native win32 binary code? what does it load/do delaying application so long?

What exactly IS .NET? First, .NET is a cross-language application framework - the same types and methods that you access in C++ are accessed in different (sometimes the same) way in C#, VB.NET, ASP.NET, and so on. (This is why, when I talk about a managed C++ feature, I usually say it is exposed in Whidbey C++.) Since the Common Language Specification (CLS) is an ECMA standard, and freely available, expect to see more (including non-Microsoft) language implementations targeting the .NET framework in the near future. (.NET perl, anyone?)

In order for multiple languages to apply to a single framework, an assembler-type language is used, called Microsoft Intermediate Language, or MSIL. All .NET-targeted languages compile their code to MSIL (in C++'s case, a mixture of native code and MSIL). The MSIL is then compiled to native machine code on-the-fly by a JIT (Just-In-Time) compiler. The JIT is basically a VM, similar in concept to the Java VM.

So, why is my sample slow? The performance hit you see (why the program takes a few seconds to load as opposed to miliseconds) is the JIT compiling your code. However, we take this tradeoff for a number of performance benefits the JIT provides. These performance benefits are nearly invisible in small programs - such as examples - and hugely beneficial in large applications. I'm not going to go into them here, because other people have done it better. Stay tuned for a really great link on the perf benefits of the CLR.

i am really into it, but i have a question && suggestion; why you are providing a garbage collector? instead of that, it would be better to track memory leaks with visual studio .net ide, like BoundsChecker was doing with vs6. because garbage collector is using system resources, may be it causes cache misses, too. of course, i have no idea about its implementation, you engineers probably considered such cases.

Do we really want/need a Garbage Collector? This isn't the first time I've heard this - and almost always from C++ users, too. We're such a type-A breed, always wanting to do things ourselves (mostly out of speed considerations). But the short-term losses you might perceive in the overhead of a GC are far outweighed by the benefits you reap. Again, I'm going to provide a link, I promise.

(To be totally clear, it isn't C++'s Garbage Collector. It is the .NET GC, and we're simply leveraging it. All .NET targetted languages are, by default, garbage collected.)

What about low-overhead solutions like BoundsChecker? Well, on the surface, these seem to be good solutions, but they aren't always. First, consider that the GC performs optimizations that non-GC environments (native C++) can't take advantage of. For example, choosing when to destruct/collect an object. In native you have to do it when the stack is being unwound (even if the CPU is at 99% usage) - in the GC world, you could choose to wait for processor lull. Second, solutions that look for memory holes only find the holes you create - you still have to patch them up. With the GC, you can't create memory holes, that worry simply never crosses your mind. (And besides, not to slam the IDE team, but do you really want the IDE - which you pointed out can't seem to manage its own memory leaks - trying to manage yours?)

So, where's that link? There's a great article on MSDN that has an explanation/justification of all the benefits provided by the .NET framework - and the theory behind why managed code isn't slower than native, and why it has the ability to be faster. It has sections on the GC, the JIT, Thread Pooling, Appdomains, and so on and so forth. It even has an Overview of the .NET framework, if my crappy one-paragraph explaination above wasn't sufficient for you.

Anyhow, if you want to know more, I strongly encourage you to check out this article.

VC++ .NET Examples, a tiny Visual Studio timeline, how to participate in the Whidbey Beta

arich — Wed, 17 Dec 2003 19:36:00 GMT

Reader Dave commented:

back to lack of visual c++ .net examples. I saw that there are lots of c# examples, this is good because C# is a new language and if i am correct, it is built for .net. there are vb.net examples, too, but there is not a visual c++ .net example displaying a window on the screen (or i didnt see any). so i am playing with console and sockets, and it is getting boring.

I did a little digging, and came up with some samples for Visual C++ .NET that you might not have seen. I believe these examples were made for VC++ 7.0, and not for 7.1. The samples cover a wide variety, including some dealing with Windows Forms, which should get your feet wet with the .NET UI APIs. (If you're looking for some VC++ 7.1 / Codename Everett examples, you might be interested in looking here.)

i see whidbey samples everywhere, in your blog for instance, but not much examples for vs2002. it seems i need to upgrade vs2003 as soon as possible.

There are plenty of good reasons to upgrade from .NET 2002 to .NET 2003 (and don't just take our word for it.)

But, there may be some confusion on the generations of Visual Studio (and of our compiler), so I'm going to try and clear it up. Since Visual Studio 6, there have been two releases. Visual Studio 7.0 (”Visual Studio .NET”) and Visual Studio 7.1 (”Visual Studio .NET 2003”). I don't know about the other products, so I won't try and outline the changes for anything but Visual C++ between these releases.

VC++ 7.0, also known as Visual C++ .NET 2002, was the first product to contain Managed Extensions.

VC++ 7.1, also known as Visual C++ .NET 2003, also known as Codename Everett, is a great compiler, and Microsoft's latest public offering. It has a whole lot of standards and conformance work, and other increases in perf, stability, etc.

Codename Whidbey, the compiler we're working on currently, is the only compiler to feature the new managed syntax I'm always blathering on about in my blog. It isn't in public release yet (there's an Alpha program currently), but we'll have a Beta hopefully in the next six months.

If you're interested in participating in the Beta, you can sign up here. Enter your Passport information, use 'BetaReq' (case sensitive) as your guest login, and fill out the survey. If you're lucky, you'll be part of the Whidbey Beta program.

A little Q&A

arich — Tue, 16 Dec 2003 19:23:00 GMT

Reader Dave asks:

I am using Visual Studio 7.0 (2002?). I turn on my computer in the morning, and run it until midnight and my visual studio is always open. however, it consumes 60-150MB Virtual memory, specifically when i use VisualPerl (I usually use Visual C++). sometimes i need to run two instances of visual studio, but virtual memory usage keeps growing in both processes. do you know any fixes, or suggestions?

I talked to some of the people who are involved in providing support for previous versions (something at Microsoft that is typically dubbed “sustained engineering“). They tell me that, unfortunately, memory leaks in the IDE (such as the one you are experiencing) are typically low-priority, and not as likely to be fixed as language design flaws or serious limitations in compiler functionality. The fact that the problem is most noticable in a third party add-in suggests it might not even be a problem primarily with the VS product. My only suggestions in this area are to contact ActiveState, to see if they are working on a fix for your problem, or to install any relevant VS .NET 2002 updates. (Though, it doesn't appear there are any addressing this specific problem.)

as i have posted in my prior posts, i have never used .net. i will say one more thing, but i dont know if it is correct, so it contains a question as well; we dont need windows forms or anything else dealing with user-interface to run a service at the server, right?

That's correct, you don't need windows forms to write a service. Windows forms are just a way to describe user interface - typically, services (especially FreeBSD/Linux/etc. ones) handle user interface through config files, command-line options, or some kind of limited console interaction. All of which should be supported by Rotor through the various CLI namespaces (System::Console, System::IO, etc.).

Mono, more on cross-platform

arich — Thu, 11 Dec 2003 19:39:00 GMT

Mono (very different from mono), is, at its core, an implementation of the Common Language Specification - which we purposefully made public domain through ECMA. Mono is pretty cool, too, and I'm personally glad to see it. They even praise the standard Microsoft helped develop:

The Common Language Infrastructure platform is similar to the goals we had in GNOME of giving language independence to programmers. It is more mature, documented, larger in scope, and has a consistent design.

What makes the Common Language Infrastructure development platform interesting is that it is a good mix of technologies that have been nicely integrated.

Which is a welcome change from what we usually hear from the open-source community. Garrett mentioned:

Without System::Windows::Forms , having the CLR on Mac OS X and FreeBSD is kinda like a mule with spinning wheel : no-one knows how he got it, and be damned if he knows how to use it :)

Well, Lyle... I mean Garrett, remember that the SSCLI is in its first version - not everything is there yet. And GTK# looks like a fairly good idea. But the truth is that Windows::Forms is a COM-interop wrapper for the native Win32 GDI, which hasn't been ported to other platforms, and likely won't be - except by those great people over at WINE :). What you ought to be wondering about is WinFX. And I don't know the answer to that question...

C++ feature "lag," native types on the GC Heap, a plug for some software I like

arich — Thu, 11 Dec 2003 18:48:00 GMT

Garrett points out:

I *am* a tad sad that C++ tends to lag a generation behind C# on features in .NET.

I realize that's likely due to the larger effort required, with less resources than C#, and it seems that C++ is less ...sexy... than C#, but it's still sad . :(

Yes, it is true that C# is ahead of the game when it comes to new features - but you have to realize that we were at a disadvantage from the start. The goals of our language redesign are very different from the goals of the C# team. I tend to think they have it easy: their language is already made to target the CLR. That's it, nothing more, nothing less. We're trying to give our users the best of both worlds: native and managed. All at once. It's a difficult task, to say the least. Having said that, it is unfortunate that C# is half a step ahead of us. But they had a head-start - and we've closed the gap considerably. I can only imagine that we'll be on-par (maybe a little ahead) by our next release. (Psst... codename Orcas.)

How far off is that intent to put native types into the GC Heap?

I can see this as being a VERY handy feature, basically adding Garbage collection to native code. This will very quickly help cure some memory leaks and crappy code :)

I'm not certain I'm allowed to speak on this issue in specifics without violating some sort of NDA. I can say, what you are looking almost certainly isn't coming in Whidbey. But it is on the horizon. For sure. We want it just as badly as you do. I'd watch Herb Sutter's blog for more on that, he's come close to talking about it a couple of times. In fact, he's already said the following:

In my previous blog entry, I listed two reasons not to conflate the type category with where objects of that type can be allocated, namely to let us in the future support allocating native types on the GC heap, and CLI types on the native heap. The decision to garbage-collect or not should not be per-type (as it was in MC++), but per-object.

By the way, if you're trying to keep track of multiple blogs, I highly suggest Newsgator. It aggregates blogs (using their RSS feeds) and dumps it into Outlook for you. Convenient!

Will .NET be available for non-Windows platforms?

arich — Wed, 10 Dec 2003 23:53:00 GMT

I thought this deserved a post, and not be buried in a comment. Dave asks:

Wow! it seems you are empowering c++ for CLR. will .net be available for non-windows platforms?

IT ALREADY IS! Being Microsoft, you'd think .NET would be a Windows-only innovation. But, happily, it isn't. My buddy Joel is PM of the Rotor team, which is working to bring the CLI (Common Language Infrastructure - the core of the .NET Framework) and the C# compiler to other platforms. Check out the SSCLI 1.0 release - which already builds on WindowsXP, FreeBSD, and Mac OS X 10.2, released under Microsoft's Shared Source Initiative. As Joel says, boot your FreeBSD box, download, untar, build, have a cup of coffee, and start playing with the CLR today!

(Ripped from the download page for SSCLI 1.0):

The Shared Source CLI archive contains the following technologies in source code form:

An implementation of the runtime for the Common Language Infrastructure (ECMA-335) that builds and runs on Windows XP, the FreeBSD operating system, and Mac OS X 10.2.
Compilers that work with the Shared Source CLI for C# (ECMA-334) and JScript.
Development tools for working with the Shared Source CLI such as assembler/disassemblers (ilasm, ildasm), a debugger (cordbg), metadata introspection (metainfo), and other utilities.
The Platform Adaptation Layer (PAL) used to port the Shared Source CLI from Windows XP to FreeBSD and Mac OS X.
Build environment tools (nmake, build, and others).
Documentation for the implementation.
Test suites used to verify the implementation.
A rich set of sample code and tools for working with the Shared Source CLI.

What about the C++/CLI binding on non-Windows platforms? Well, Microsoft isn't typically in the business of making compilers for non-Windows platforms. But Herb Sutter, with lots of collaboration with other groups (Plum Hall, EDG, and Dinkumware), are hard at work standardizing the C++/CLI binding with the ECMA Standards Group. Then, there will be a standard that can be used by other groups and companies to develop C++ compilers those non-Windows platforms that can target the CLI, which will be available on those platforms through Rotor. We're even working with the C and C++ standards groups to try and bring some of our innovations to the language into those standards!

Thanks for the question, Dave! And you're right about the empowerment - but it isn't C++ we're empowering for CLR - it's our USERS!