I Love that New Syntax Smell : articles

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.

C++ DF Discussion on hold

arich — Tue, 18 Jan 2005 00:30:00 GMT

Astute readers may note two things: 1) It has been a while since I posted what should have been a followup to the previous posts, wherein I complete my discussion of the C++ DF model, and finally get this DF monkey off my back. And 2) that a previous post (DF Part 2, where I actually explain how the C++ DF model works) has been temporarily removed.

Many reasonable scenarios exist to explain these phenomena. Suprisingly, the truth has very little to do with the Bermuda Triangle. I believe the C++ DF model may be undergoing some revision - and it would be a Bad Thing to leave up a post on what could be an outdated (and incorrect) description of the model.

When the language design team (a team I must stress I am an observer of) has Finalize()d their design, I will recreate post #2 anew, and the final post on DF will also see the light of day. I can't say much about it yet (not until I've had a chance to play around with it), but from what I've seen, I'm very pleased with the new design.

So, I'm on board with the new design, if for no other reason than the fact that my final post (how the C++ DF model and the CLR Dispose pattern) was nearly impossible for me to write under the previous design. Not because I'm a poor writer :), but because the previous design left the developer with some very tough problems to handle elegantly. This new design is far more elegant, to my eyes.

While we wait on that post, I may take some time later this week to mull over some general issues that have been bothering me recently. In the meantime, here's a juicy article by Herb (who is a member of the language design team) on a subject very close to our current lines of discussion.

Deterministic Finalization IV - Benefits, part II

arich — Fri, 05 Nov 2004 18:52:00 GMT

Long ago, I wrote a post on the first part of DF benefits. Now, I'm finally getting back to it. My apologies about the laxness in posting. Blame it on my Cards losing to the Sox. And on being really busy with testpasses and bug bounces for a while. We're finally settling down a little bit, so that gives me time to pull out the keyboard and do some more blogging.

Last time, we discussed ref types on the stack, and the benefits they provide. But, if you can put ref types on the stack, where else can you put them? Try this one on for size:

using namespace System;

ref struct A{ ~A(){ Console::WriteLine("~A()"); } };
ref struct B{
A a1;
A a2;
};

int main(){
B b;
}

Compile and run that, and you'll see ~A() output twice. Now, you can have ref types as class members, and we call the destructors for you automatically. Dig this, they can even be static! The same rules as native C++ apply all over the place. If I want to call a constructor with arguments, I can do it inside the ctor initializer list. And object unwinding works as well.

Okay, so maybe I didn't need to split this into a separate posting. I could have bundled it, and divluged this little nugget of coolness weeks ago. In any case, next time, I'll wrap up this whole DF business with a discussion on how our DF model works with the CLR Dispose pattern. (See part 1, or some CLR persons' blog for more on the CLR Dispose pattern.) After that, I'll probably get into copy ctors on ref types, or maybe my new favorite subject: hidebysig.

Deterministic Finalization III - Benefits, part 1

arich — Mon, 18 Oct 2004 21:34:00 GMT

I'm pretty angry at blogs.msdn.com right now (or maybe I'm just angry at myself), as it completely nuked a post I had composed, because my session had timed out on it. I went to post, and it asked me to log in, and in the process destroyed a lot of work.

I'll try to put my frustrations out of mind, and continue with my increasingly tardy discussion of C++ DF. I've already discussed the CLR Dispose pattern, and the C++ destructor syntax. Originally, I'd planned for this third part to be about interaction between those two models, but I think I'll save that for later, and instead start talking about the benefits of C++ DF, by way of discussing a comment on my previous blog post.

A bit of discussion about Dispose brought up an interesting point - in C++, now, we've disabled the ability to call the Dispose function directly. Instead, you call it thusly:

ref class MyClass{
public:
~MyClass(){} //overrides IDisposable::Dispose()
};

int main(){
MyClass^ mc = gcnew MyClass();
//do stuff
mc->Dispose(); //error!
mc->~MyClass(); //legal, calls Dispose()
delete mc; //also legal, also calls Dispose()
}

The options left open to the user are, I think, a little more familiar. However, there's a large caveat included in this discussion. Imagine, in that innocuous comment titled "do stuff," that I throw an exception. I haven't handled it in my code snippet, so I'm likely to run into issues. The most obvious way to handle this would be to wrap our instantiation in a try/finally:

int main(){
MyClass^ mc = gcnew MyClass();
try {
    //do stuff, maybe even throw an exception
  } finally {
    delete mc; //dispose, regardless of execution path
}
}

That works, but it's likely to get nasty very quickly when you have multiple disposable objects, as you should be nesting try/finallys (to guard against exceptions in an object Disposer, for example). C# has a nifty piece of syntax set up to handle this, the using statement (not to be confused with the using directive). You can scope out the code example in that article for more information on it. In C++, however, we've developed our own bit of syntactic sugar to handle disposable objects cleanly: ref types on the stack. With a nod to the example above, here's a quick look at ref types on the stack:

#using <System.Drawing.dll>
using namespace System::Drawing;

int main(){
Font f1("Arial", 10.0f);
Font f2("Courier New", 8.0f);
//do stuff with these fonts
} //Dispose called automatically, even with exceptions

This is a syntax that should be intimately familiar to C++ users - what's more, if you look at the IL, it actually behaves the way they will expect. That is, your disposer gets called even if an exception is thrown during the "do stuff" phase. Ref types on the stack aren't really anything special, they're still a ^ underneath, it's just a lightweight "shim," with a few added bonuses. However, this syntax does represent a slight problem - there are no BCL methods that take a font-on-the-stack, because this whole "on the stack" thing is a C++ convention.

To handle this, (pun intended) we introduced the % (Anders-of) operator. This basically gets you the handle underneath our implementation. So, you can have a ref type on the stack, and still pass it to functions that expect a handle to that type. It's used exactly like the & (address-of) operator, which is pleasantly analogous, in light of the & reference type and the % tracking reference type.

#using <System.Drawing.dll>
using namespace System;
using namespace System::Drawing;

void foo(Font^ f);

int main(){
Font f1("Arial", 10.0f);
Console::WriteLine(f1.FontFamily);
foo(%f1); //foo requires a Font^
}

Why not use something similar to the boxing conversion? (Is it some kind of coincidence that my post on boxing was also apparently nuked at some point?) Anyhow, there's a very good reason for not using a boxing-style conversion, and it's something new we've implemented for Whidbey C++: deep copy semantics. (That is, copy constructors for ref types.)

We're starting to stray outside the bounds of this conversation, however. We'll save copy ctors for another day. Next time, I'll get into more benefits of DF. Also still to come: how C++ DF interacts with the CLR Dispose pattern.

Deterministic Finalization I - a primer for CLR Dispose

arich — Fri, 24 Sep 2004 01:49:00 GMT

A large subject like DF needs a few posts. My generalized plan to lay it out will start by describing the CLR's Dispose pattern, how our DF pattern works, and finally how the two patterns fit together.

The CLR's Dispose patterns can be quite confusing. It took me a while to get my mind around Dispose() and Dispose(bool), and I'm still not sure I fully understand it. But, I'm going to take a crack at it. Most of what I know about Dispose/Finalize patterns comes from two sources; talks with Brandon, and this excellent whitepaper on the subject. It's wordy, but it will do a far better job explaining Dispose than I can, and it will talk about more Dispose patterns than I plan to. In fact, it might be a good idea to read that whitepaper, and then return here, to see how my take on it differs from your own. I'll take this opportunity to remind you that this is my opinion of the way things are, not the way they really are.

The usefulness of Disposing is primarily for freeing unmanaged resources. In a nutshell, the Garbage Collector really only gets invoked when there's memory pressure. But the GC can't "feel" pressure from unmanaged resources. If you have a bunch of objects hanging around that have gobs of natively allocated memory (C++ new, or Marshal.AllocHGlobal), the GC won't know about this memory pressure, and won't begin freeing up these objects. (It may notice the free memory being reduced, but it has no sense of which objects are holding the memory.) The aforementioned whitepaper also talks about database handles, file handles, and message queue handles as other forms of unmanaged resource.

When creating .NET Disposable types, you usually want to create a Finalize (C# destructor syntax), Dispose(), Dispose(bool), and inherit from System.IDisposable. Almost all of your actual object cleanup will occur inside Dispose(bool). That's the pattern they came up with, and it's a good way to keep all your cleanup in one place. We'll get to cases in a second, but first, here's a hunk of C# code plaigarized from the whitepaper:

public class BothType: IDisposable{
public void Dispose(){
    Dispose(true);
    GC.SupressFinalize(this);
}

~BothType(){ //finalizer
    Dispose(false);
}

protected virtual void Dispose(bool disposing){
    if(disposing){
      //'Disposable' managed resource cleanup code
    }
    //Unmanaged resource cleanup code
    base.Dispose(disposing);
}
}

When Disposing, the first call is always to Dispose(). Biggest take-away from one of my talks with Brandon. All disposing starts with that call. The CLR way of doing "chaining" destructors is the manual Dispose(bool) pattern. Basically, the user calls Dispose(), and inside that function, Dispose(true) is called. This does a callvirt on Dispose(bool), which will thunk down to the lowest child instance. Then, you have the manual base.Dispose(disposing) calls that will walk up the chain. I had to step up to my whiteboard for a while to prove to myself that this pattern works - but it does.

The Finalizer is a backup system in this paradigm, only there to ensure that your unmanaged resources get cleaned up. That is, if a Disposable object is being Finalized, it's probably a mistake - the user forgot to Dispose(). So a call to Finalize() yields a call to Dispose(false), which takes care of only those unmanaged resources it holds, those that the GC is unable to clean up.

Note: a call to Dispose(false) should only clean up the unmanaged resources. If we're finalizing, we have no discrete order for finalization. If I try and Dispose objects the GC is aware of within a finalizer, I could be in for a world of pain, because those objects might already be collected. Finalization is not deterministic. There was an MSDN TV episode where Brad Abrams tells an antecdote about a bug where they were calling Console.WriteLine() in their Finalizer and getting a NullReferenceException, because the Console object had already been finalized. Talk about hard to track down...

You clean up your managed resources inside the if(disposing) scope. Note that in that scope, you should only clean up your Disposable member objects. Don't bother with objects that don't have a Disposer, those objects will be cleaned up just fine by the GC. It's a trade-off you make between those objects you need to get rid of, to free up scarce resources, and not having to clean it all up right away. Like at home; I might do the dishes on a weeknight (especially if I've run out of ramen bowls), but I don't go vaccuuming the floor every time I walk on it.

The call to GC.SuppressFinalize() shouldn't be overlooked - it ensures the Garbage Collector won't Finalize an object that's already been Disposed. In general, you're either going to Dispose an object, or the GC will Finalize it, not both.

Though this is the most flexible cleanup model, it isn't the only cleanup model for objects in the CLR. The whitepaper goes over most of them. The simplest case is where your object has no Disposable members, or unmanaged references. ("Simple" objects.) No Disposers or Finalizers needed there, the CLR will clean everything up for you. Or, your object might only have non-scarce resources and the aforementioned Simple objects, in which case you might have a Finalizer, but not a Disposer. But, if you've got only unmanaged resources, or both unmanaged and managed resources, you probably want both a Disposer and a Finalizer, where the Finalizer is more a safety net than intended use. The whitepaper also talks about the case where you might want only a Disposer. While this case does exist, I think it should be used with caution. If you or your user forgets to Dispose() such an object, your unmanged resources could be hanging around for a very long time.

Coming in Part II, I'll discuss the C++ DF model, and how it fits with the CLR's Dispose() pattern. (Depending on how long it takes, that discussion might be split into two parts.) I'm also planning on a Part III (or IV), where I'll talk about the C# using declaration (see 2.4 of the whitepaper), and how C++ tackles the same problems.

The C++ "for each" syntax

arich — Thu, 09 Sep 2004 01:09:00 GMT

For Each? I won't go into a huge justification - suffice to say, there are some instances where it is nice to be able to iterate over a set, and perform operations on each member of that set. A good primer might be the MSDN node on C# foreach.

A basic sample. If you're familiar with C++ for statements or the C# foreach statement, the C++ for each statement should be fairly familiar. I'll steal from a C# sample, and convert to C++:

using namespace System;

int main(){
array<int>^ arr = gcnew array<int>{0,1,2,5,7,8,11};
int even=0, odd=0;

for each (int i in arr) {
  if (i%2 == 0)
  even++;
    else
      odd++;
  }

Console::WriteLine("Found {0} Odd Numbers, and {1} Even Numbers.",
    odd, even);
}

Pretty simple. There are some definite advantages to for each. Most importantly, it beats struggling with iterators and IEnumerables almost any day of the week. There are also some interesting things you can do with for each. For example, you can do fun things like for each(Char c in "abcdefg"). Go crazy with Generic Collections. And, here's a code sample that I know will make some of you out there salivate:

#include <vector>
#include <iostream>
using namespace std;

int main() {
int total = 0;

vector<int> v(6);
v[0] = 10; v[1] = 20; v[2] = 30;
v[3] = 40; v[4] = 50; v[5] = 60;

for each(int i in v) {
total += i;
}

cout << total << endl;
}

Here's the kicker: you can compile the above natively. Why throw in the CLR if you don't want to? Of course, it compiles just fine with the CLR, but for each works on any STL-compliant container in native C++. Now that's a compiler improvement I can get behind. Next time, I'll take a first look at DF. I think it's going to take me a few posts to get it sorted out.

Pinning Pointers

arich — Fri, 27 Aug 2004 20:32:00 GMT

Hot on the heels of my article on interior pointers, comes a much more insightful one by Stan Lippman on the same issue. That happens sometimes. I enjoyed the chat we had on the VC++ 2005 Beta, and I wanted to point that there are two other online chats coming up. One is on upgrading COM apps to .NET, and the other is on the library and runtime enhancements in VC++ 2005. They're lumped together with other chats that might be of interest on this page.

On to pinning pointers. Sometimes, the interior pointer simply won't suffice. Say I have a function I really need to access in a native code module. For example, I have a native function that loads an array for me, and I want to use it to load a managed array. Sounds like a complicated task, and it can be. Conventional wisdom tells us that the native function can't get access to the managed array, because it's on the GC heap, and could move around all over the place. I can't use interior pointers because this is native code. So it seems the onlyh choice left is to make another native array, call into the native function, and then loop through the native array, copying the members over from it to the managed array. Clunky, to say the least.

There's a better way? You bet. It's called the pinning pointer. In Managed Extensions, we exposed it using the keyword __pin. In the new syntax, we expose it through another smart-pointer-ish type, pin_ptr<>, located in the cli namespace (the namespace formerly known as stdcli::language). What the pinning pointer does is "pin" our managed object down on the GC heap, preventing the garbage collector from moving it around. In addition to this pinning, it gives us what we need; a conversion to a native pointer.

Though pinning pointers are cool, they are sometimes not well understood. The best way to think of them is that an object is pinned so long as a pinning pointer points to it. That's important enough a concept that you ought to read that sentence again. I'll wait. What this means is that your pin_ptr object is only pinning something on the GC help while its in scope. When it goes out of scope, it stops pointing to that object, and that object can be moved at any time. That means you can't go saving a native pointer, and expect your pin_ptr to hold it forever.

Dangers of pinning pointers. In fact, because of the dangers of misinterpretation, we severely restrict where and how you can use pinning pointers. They can't be involved anywhere temporaries are created, can't be the argument to or the return type from a function, can't be members of a type, and can't be involved in casts, to name a few. But this is C++, and what would C++ be without a way to shoot yourself in the foot. Long ago, I wrote an article that included some warnings about the pinning pointer. The examples are in Managed Extensions, but the concepts are pretty solid. Rather than repeat myself, I'll just link to it, and request that you read it. Especially that example of how to make a quick and easy GC hole.

Enough talk, let's see an example. Right.

using namespace System;
using namespace cli;

void myUnmanagedFunction(wchar_t* p, int size){
for(int i=0; i<size; i++)
p[i] = 'A'+i;
}

int main(){
array<Char>^ arr = gcnew array<Char>(10);
pin_ptr<Char> ppC = &arr[0]; //implicit conversion from interior to pin pointer
myUnmanagedFunction(ppC, 10);

for(int i=0; i<10; i++)
Console::Write(arr[i]);
Console::Write("\n");
}

Putting it all together can be complicated. Brandon helped me sort it out one day by drawing a helpful diagram, which I'll replicate here.

Don't quit your day job. I know, I'm not much of an artist. Think of the arrows as "can convert to." Note that for orthogonality, native pointers can convert to pin and interior pointers. Hey, it's sometimes useful, you'll be glad it's there. That's it for pin pointers. In a future article, I might look at our upcoming for each syntax.

Interior Pointers

arich — Mon, 16 Aug 2004 20:28:00 GMT

Where's the rest of the properties stuff? I was going to write about default properties in this entry (and have quite a lengthy one saved for future use), but there are a few disagreements I have with the current implementation of default properties, and I want to see those issues resolved before I discuss a feature. (I hate when I discuss something, and then it changes on me, and I have to backpedal.)

Interior Pointers. Instead, I'm going to take this opportunity to delve into interior pointers. I'd say the major difference between interior pointers in V1 and the updated C++ syntax is, in V1, you used the same __gc keyword to denote both interior pointers and handles to objects (for which we now use the carat or "hat" symbol). The confusion, for many users, is that a __gc * would actually be something different, depending on the type of object it pointed to.

#using <mscorlib.dll>
using namespace System;

__gc class A{
public:
int i;
};

int main(){
A* a = new A;
int __gc *p = &(a->i);
*p = 10;
}

Seems simple enough. The confusion, for most users, is why they can't take that p and pass it to some unmanaged function or static library and perform the same sorts of operations. The reason, though, is actually somewhat obvious, when you consider it. The type handle a is pointing to the GC heap - a managed, garbage-collected heap. At any time, the gc can fire up, and perform collections and compactions.

Compaction? The collection doesn't worry us so much - it's the compactions we need to worry about. The GC is allowed to move our objects around during compaction. The runtime then updates the active type handles to continue to point to the proper place. What about types that the runtime doesn't know anything about? They're not updated, plain and simple. That's why the runtime has its own type of pointer that gets updated. Native C++ pointers know nothing about the GC, and frankly, that's the way we want it. To protect the user, we prevent the creation of native pointers to memory in the GC heap (except for pinning pointers - which I'll discuss in a later post).

What's the new syntax? The new syntax is similar to template smart-pointers (such as std::auto_ptr or shared_ptr from the boost library). The interior pointer template name is interior_ptr<T> and it's located in the namespace cli, along with array, pin_ptr, and safe_cast. The above sample would look something like:

using namespace System;
using namespace cli;

ref class A{
public:
int p;
};

int main(){
A^ a = gcnew A;
interior_ptr<int> p = &(a->p);
*p = 10;
}

What's the point of interior pointers? I was having a discussion with a coworker while preparing this post, and that question came up, and we were both dumbfounded for a split second. The answer came to me, but it took a little while: the number one use in Whidbey is probably by-ref parameters. If I want a by-ref parameter that modifies the value of an int that's passed to it, the best type to use is an interior_ptr. The main reason is that native pointers to T can convert to interior_ptr<T>, so I can pass by-ref parameters from almost anywhere into that function, and have it modify the value whether the type is on the heap or on the stack. For example:

using namespace System;
using namespace cli;

ref class A{
public:
int i;
};

void applyTen(interior_ptr<int> p){
*p=10;
}

int main(){
A^ a = gcnew A;
int i;
applyTen(&i);
applyTen(&a->i);
}

If the parameter to applyTen was an int* as opposed to an interior_ptr<int>, the types wouldn't match for the second call. In a future article, I'll delve into the pinning pointer.

Properties Part 1 - the updated property syntax

arich — Wed, 28 Jul 2004 03:38:00 GMT

What are properties?

Technically, properties are CLR "aliases." They are exposed as standard methods, and any compiler that consumes them simply transforms the user's code into the proper function calls. Similarly, any compiler that wants to author CLR properties just needs to follow the naming convention rules, and provide the necessary metadata entries.

The property appears as a red triangle in ildasm. In the shot below, note that the functions implementing the property are not hidden or obfuscated. Indeed, languages that don't support the property can still call the underlying functions.

The Managed Extensions property syntax

__gc class MyClass{
__property int get_MyProp(){ ... }
__property void set_MyProp(int value) { ... }
}

int main(){
MyClass* mc = new MyClass();
return mc->get_MyProp();
}

By using the keyword __property, and providing a getter and/or a setter (using the naming convention get_PropName), a user was able to signal to the compiler that they wanted the extra property information generated. When a user wanted to call a property, they would simply use the get_ and set_ functions directly. This fit in the C++ syntax neatly, but it wasn't exactly first-class. Whereas other languages could get the length of an array by saying MyArray.Length, we were limited to MyArray->get_Length().

The new C++ property syntax

In the Whidbey syntax, the property is defined as a block, similar to how C# handles properties. The general syntax uses the context-sensitive word property, followed by the general type of that property, followed by the name. Curly-braces then define the "scope" of the property block, and inside, you're allowed to define get and/or set functions that match the expected signature. (The C# MSDN node on properties provides more context on how C# exposes properties.)

ref class MyClass{
property int MyProp{
int get(){ ... }
void set(int v){ ... }
}
};

Calling properties is also similar to how C# handles them, with a few caveats. In general, you should be able to call a property via its alias name, as in int i = myObject->MyProp, or myObject->MyProp = 10. The compiler then transforms these calls into a getter or setter method, as appropriate. This works on all properties, not just those you create.

More to come

In future articles, I'll talk more about what you can do with properties, including:

default properties / default indexers
overloading of properties
limitations of properties in C++

VC++ Whidbey Beta1 Ships!

arich — Tue, 29 Jun 2004 21:46:00 GMT

Finally! VC++ 2005 Beta1 has dropped, and we had a little party last Friday to celebrate. It was nothing fancy, and I spent most of my time playing bridge in a corner. The full beta is only available to MSDN Subscribers now, and selected partners, but there's still a way for everyone to play around with Whidbey: the Express SKUs!

What is Express? It's a way for everyone - students, hobbyists, and nay-sayers, to give the Visual Studio product line a go. In fact, VC++ 2005 Express Beta1 is out there, just waiting for you to go download it. In fact, start the download (you'll have to cough up a valid email address), and then come back here to read more about it. I'll wait.

Welcome back. The Express lineup, in my opinion, is freakin' cool. It gives everyone an opportunity to see what's great about our product. We've got a rock-solid optimizing compiler, and a brand-spanking new C++/CLI syntax (that I know you're dying to try out). You also get the best of our IDE, including live code browsing, Intellisense, debugging, and the updated Class Viewer.

You could win an Xbox and Halo 2. Got your attention yet? Head over to Channel 9's Summer of Express contest for all the details.

We want bugs. We want your bugs. Grab all your code, run it against our Beta, and give us all the bugs you find. We've released a new product feedback center, where you can file bugs that go right into our bug database. One click, your computer to our doorstep. You can even keep us responsible by tracking the progress of your bug, and bugs filed by other customers.

What's new? I'll probably elaborate on this more, and I might find the energy to work up a few samples. I suggest you try out the new Whidbey language, our generics support, and the new Secure CRT, to name a few of our advancements. Don't try out DF (deterministic finalization), though. Despite what the website may say, DF is not in beta1.

Visual C++ .NET 2003, Free.

arich — Mon, 19 Apr 2004 17:36:00 GMT

Go here to get a free command-line version of VC++ .NET 2003. For you misers, I'm sure you could trick the 7.0 IDE (or even the 6.0 one) into using these new binaries. This was mentioned on Slashdot on Sunday.

I'd recommend carefully reading the included EULA if you intend to use this version of VC to create commercial products. I haven't read it myself, but the download page doesn't explicitly say that this can be used for commercial products.

Having said that, this is a great thing to get for free. As far as I can tell, it isn't crippled in any serious way. Full optimizations are available, and there don't appear to be any time limits.

Status, aggregate initialization of CLI arrays

arich — Wed, 17 Mar 2004 17:41:00 GMT

This is a quickie. I have some other blog posts about interesting material on the horizon, but I'm always wary of posting information without knowing whether I'm going to violate NDA by writing about it. There should be a real flurry of activity when we finally get the Whidbey Beta 1 out our doors, but I don't expect that to happen for months, yet. We're in “heads-down“ mode in the FE team, hard at work delivering features that we think will excite and engage our users.

About aggregate initialization. How do you do it with managed arrays? I held the suspicion that you couldn't do it, that we didn't provide a way to do it in the new syntax. Stan showed me how:

using namespace System;
using namespace stdcli::language;

int main(){
array<int>^ numbers = gcnew array<int>{4, 6, 8, 10};
for ( int i=0; i<numbers->Length; i++ )
Console::WriteLine( numbers[i] );
}

That's it. Pretty straightforward, pretty simple.

The CLR team is looking for a few good people

arich — Sat, 06 Mar 2004 21:02:00 GMT

Joel just posted over on his blog that the CLR team has some open headcount - they're looking to fill a few positions. I can say that working for Microsoft has been one of the most challenging and rewarding experiences of my short life (pay no attention to the fact that I'm posting this on a Saturday), and if you're interested, and you have the skills, I'm sure they'd love to have you.

Check out the details here.

Ain't said nothin' in a while, but some old posts are now available.

arich — Mon, 12 Jan 2004 19:25:00 GMT

Where you been? Yes, it's true, I've been fairly silent. But I assure you, my reason(s) are good. Mostly, I've been skiing in Colorado, or really busy. But I'm back at work, and once I catch up on the email, there will be more tasty posts from yours truly. (And more code snippets, once I figure out where I'm going to host them.)

You can now use http://blogs.msdn.com/arich. I think this is a more meaningful URL, however cosmetic.

My old posts are now available. They were (finally) ported over from my old blog. If you never bothered to read them, here are their subjects (and permalinks):

11/06/03 - The first introduction
11/06/03 - That crazy GC Heap
11/07/03 - Context-sensitive keywords
11/10/03 - The ref type
11/11/03 - The value type (note these corrections)
11/12/03 - Simple stack code
11/17/03 - Branbray on Handles
11/17/03 - PtrToStringChars v2 remix
11/25/03 - Corrections, explanations, etc.
12/04/03 - Goodbye to my original blog

Hopefully, that will satisfy the content mongers for a little while, so I have time to get my bearings. :)

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.