Herb Sutter's Blog

Movin' Out

2004-10-04T15:44:00Z

(With apologies to Billy Joel.)

This is it: Hopefully the last time I move this blog for a while. I've moved over to a planned-to-be long-term blog home over at PluralSight. Thanks to Don for prodding, Fritz for hosting, and retroactive thanks to all the folks at MSDN and GDN for hosting my initial blog home here.

I'll probably move my existing blog articles there. No ETA on when, though. Things are crazy, and I'm just about done the indexing on the C++ Coding Standards book. When that's done, and the C++ standards meeting a couple of weeks from now is over, and some upcoming talks including this one at OOPSLA are behind me, there'll be more time. Probably. (I always think there'll be more time someday. I guess it's good to be optimistic.)

See you on PluralSight.

Simulating try/finally in plain C++ (without the C++/CLI extensions)

2004-09-06T16:12:00Z

Dan wrote:

I think this is close enough to try/finally in C++:

Resource* pRes = new Resource;
try
{
// use the allocated resource somehow
}
catch (...)
{
delete pRes;
throw;
}

First, note that this code as written doesn't do "finally," because the idea behind a finally block is that it gets executed whether an exception is thrown or not. But it's close: You can indeed get a similar effect if you add a throw statement (e.g., throw 1;) at the end of your try block, so that it always exits via an exception, and then catch(...).

Even after applying the quick fix to make this do what was intended, this (ab)use of the try/catch mechanism inferior to having finally (or better still, in most cases, a destructor) because it interacts poorly with other exceptions. For example, what if other parts of the body could throw specific exceptions we want to catch? It would be repetitive and fragile to duplicate the delete statement in every catch block. Also, it's going to be more expensive in runtime cost because an exception will always be thrown, and actually throwing an exception has nonzero cost on every implementation I've heard of; having finally just has the compiler ensure the given code runs in all cases without having to throw an extra exception if none was otherwise being thrown.

Downloading the Express beta compiler

2004-09-05T01:19:00Z

Mark wrote:

I have downloaded the Visual C++ Express and have been trying out simple programs. I have to say C++/CLI is amazingly simple and elegant compared to MC++. You guys rock!!!

That reminds me to announce (belatedly): Try out the free Express compiler and play around with the new syntax. Make sure you also get the tool refresh so that you get all the latest parts of the syntax now implemented (e.g., putting .NET Framework types on the stack and having them automatically Disposed for you).

Cool stuff. Check it out.

C++/CLI timeline and one-line description

2004-09-03T22:10:00Z

Ioannis Vranos wrote:

There is an upcoming C++/CLI standard (currently draft, official document expected in December 2004)

Just a note, we now expect to complete work on the C++/CLI standard in March and have it approved by Ecma in June. We wanted the extra time to complete and polish the C++/CLI spec, but another reason for the slip was that the CLI standard (undergoing its second round of work in parallel with the first round of C++/CLI) also slipped.

In case you're wondering "why 6 months," the answer is that Ecma's schedule, you get two shots a year to submit a document for approval (June and December), so any slip is 6 months (or a multiple thereof).

C++/CLI is more powerful than C#/CLI (including the upcoming C#/CLI one).

The design ideals of C++/CLI are the following:

1) Bring C++ abilities to CLI.
2) Bring CLI additional features to C++.
3) Leave no room for a lower level language in CLI (*including IL*).

BTW, another way of saying this that people seem to find useful is that, as of our Whidbey (VC++ 2005) release, C++ is the systems programming language for .NET.

finally + destructors = best of both worlds

2004-09-03T22:03:00Z

On comp.lang.c++.moderated, "Howard" <alicebt@hotmail.com> wrote:

You know how we use try { } catch() {} in C++? Well, both Delphi and C# (which was developed with the aid of one of Delphi's main original developers) have another construct, which is "try {} finally {}". The idea is that no matter what else takes place, no matter whether it's a return statement or an exception or simply dropping on out of the try block normally, the finally clause will ALWAYS be executed. (Short of an abnormal program termination, I would suspect.) It might be used like this, for example (if it were available in C++):

Resource* pRes = new Resource;
try
{
// use the allocated resource somehow
}
finally
{
delete pRes;
}

Actually, that's valid C++/CLI code -- C++/CLI also supports finally with exactly that syntax. This is described in the current draft spec available via: http://www.msdn.microsoft.com/visualc/homepageheadlines/ecma/default.aspx . See section 16.4, and search for "finally" throughout (there are other spots that specify how it interacts with other language features like goto).

This is in addition to destructors -- as another responder, Mike Wahler, noted, you can also get a similar effect with destructors:

C++ already has this, via destructors. When 'throw' causes a scope to be exited, all automatic objects are destroyed, and any destructors will run. ALWAYS. So just wrap that 'new' and 'delete' in a class, create an automatic object of that type, and you have the same mechanism.

One advantage of finally is visual locality of reference -- the code is right there in the function instead of off in a different place (a destructor definition). One advantage of destructors is that RAII objects encapsulate and automatically manage ownership. In your example above, I would prefer to use a destructor (by writing auto_ptr<Resource> instead of Resource*, you don't need a finally at all). You can use either facility, of course.

To me, this is yet another case where C++ gives you the best of both worlds. Having both is better than having either alone (in languages that have only finally or only destructors). Note this is very closely related to the Dispose pattern I mentioned in a recent post, because the Dispose pattern relies on finally for things that destructors do better, so it's good to have destructors. For other things, finally is better, so it's good to have finally.

Herb

An update to the C++/CLI draft

2004-08-03T20:36:00Z

An interim updated snapshot of the C++/CLI draft standard is now available:

C++/CLI Language Specification (Working Draft 1.5, June 2004)

A new article on C++/CLI

2004-08-03T20:28:00Z

Kenny Kerr announced a cool article he wrote about C++/CLI on MSDN:

C++/CLI: The Most Powerful Language for .NET Programming

C++ RAII compared with Java Dispose pattern

2004-07-31T20:49:00Z

Earlier today I wrote that: “The C++ destructor model is exactly the same as the Dispose and using patterns, except that it is far easier to use and a direct language feature and correct by default, instead of a coding pattern that is off by default and causing correctness or performance problems when it is forgotten.“ Niclas Lindgren agreed with the post but added:

...although you use the word coding pattern to confuse something simple with something that sounds trickier.

I was referring to the Dispose coding pattern. For the benefit of those who aren't familiar with the Java Dispose pattern, let me give two examples: first a simple one with just one resource, then a more complex one with three resources. The examples use .NET Framework types.

Consider this C++/CLI code:

String^ ReadFirstLineFromFile( String^ path ) {
StreamReader r(path);
return r.ReadLine();
}

The minimal C# equivalent is the “using“ patterns which semiautomates the Java Dispose pattern (I'm showing the {} around the block to be explicit that there's a block, although since there's only one statement you don't really need them):

String ReadFirstLineFromFile( String path ) {
using ( StreamReader r = new StreamReader(path) ) {
return r.ReadLine();
}
}

The minimal Java equivalent is the Dispose pattern (this is what C#'s “using“ generates under the covers):

String ReadFirstLineFromFile( String path ) {
StreamReader r = null;
String s = null;
try {
    r = new StreamReader(path);
    s = r.ReadLine();
} finally {
    if ( r != null ) r.Dispose();
}
return s;
}

I called this Dispose pattern “a coding pattern that is off by default and causing correctness or performance problems when it is forgotten.“ That is all true. You have to remember to write it, and you have to write it correctly. In constrast, in C++ you just put stuff in scopes or delete it when you're done, whether said stuff has a nontrivial destructor or not.

But that example is still flattering to the Dispose pattern, because there's only one resource. Consider as a second example this C++ code that opens a message queue and echoes one message to two target queues (a main queue and a backup queue) -- and automatically correctly closes the queues:

void Transfer() {
MessageQueue source( "server\\sourceQueue" );
String^ qname = (String^)source.Receive().Body;
MessageQueue dest1( "server\\" + qname ), dest2( "backup\\" + qname );

Message^ message = source.Receive();
dest1.Send( message );
dest2.Send( message );
}

The minimal correct Java equivalent is:

void Transfer() {
MessageQueue source = null, dest1 = null, dest2 = null;
try {
    source = new MessageQueue( "server\\sourceQueue" );
    String qname = (String)source.Receive().Body;
    dest1 = new MessageQueue( "server\\" + qname );
    dest2 = new MessageQueue( "backup\\" + qname );

    Message message = source.Receive();
    dest1.Send( message );
    dest2.Send( message );
}
finally {
    if( dest2 != null ) { dest2.Dispose(); }
    if( dest1 != null ) { dest1.Dispose(); }
    if( source != null ) { source.Dispose(); }
}
}

In this case, the queues will be freed up eventually when the garbage collector runs (which it probably will). In the meantime, we've tied up scarce resources. Worse, we've tied up resources on other machines.

So the C++ destructor model is exactly the same as the Dispose and using patterns, except that it is far easier to use and a direct language feature and correct by default, instead of a coding pattern that is off by default and causing correctness or performance problems when it is forgotten.

More on % (managed reference)

2004-07-31T20:28:00Z

Keith Duggar asked:

Ok, I'm missing a basic point here. So, out of curiousity:

1) Is there any overhead associated with using 'T%' in place of 'T&'?

No.

2) Are there things that can be done with 'T&' that cannot be done with 'T%'

Yes: A % can only exist on the stack (a CLI limitation). Cases where a C++ program puts a & on the heap are relatively rare -- you'd have to a have a reference member of an object, which is problematic in general -- but % can't be a drop-in replacement for that use of &.

Using % and &

2004-07-31T20:05:00Z

This post brings together three related questions and answers posted recently on comp.lang.c++.moderated. They all have to do with the relationship between % (tracking reference) and & (unmanaged reference).

First, Dietmar Kuehl asked about this C++/CLI code:

template <typename T> void f(T&) {}

int main() {
int^ ptr = gcnew int(0);
f(*ptr); // error
}

The solution is to change f's parameter from T& to T% . When referring to ab object on the GC heap, just as instead of an unmanaged pointer you need a handle ^ (which tracks during GC) you also instead of an unmanaged reference need a tracking reference % (which tracks during GC).

Trying to pass a deref'd ^ (which tracks) to a & (which doesn't track) is the same kind of error as trying to pass a const object (which is const) to a non-const & (which isn't const):

template <typename T> void f(T&) {}

int main() {
const int i;
f(i); // similar category of error
}

So in general, to be able to bind also to objects on the GC heap, a function taking a & parameter only needs to change the & to % instead (the body generally won't care).

In our STL.NET project we're providing the standard algorithms with % instead of & parameter types, which doesn't affect the meaning but allows them to be used with all the types they work with already plus also managed types.

If you can't change the function and must call a function with a plain & (including if you just want to call the standard algorithms directly for some reason), you can still do it by using the RAII pin_ptr so that tracking isn't needed for the duration:

template <typename T> void f(T&) {}

int main() {
int^ ptr = gcnew int(0);
f( *pin_ptr<int>(&*ptr) );
}

Note that normally you don't need that extra &* -- here it's needed because we're dealing with a boxed value type and want to reach into the box.

Separately, Sebastian Kaliszewski asked about this code:

template <typename T> void f(T%) {}

int main() {
int* ptr = new int(0);
f(^ptr);
}

This code does work, except that you dereference a ^ with * (just like you dereference all pointerlike abstractions), so change the call to f(*ptr); and it works just fine.

Finally, Thorsten Ottosen asked whether the following couldn't be possible:

template< class T > void foo( T& );
template< class T > void bar( T% );

int main()
{
   int^ gc = gcnew int(0);
   int* ptr = new int(0);
   foo( *gc ); // 1
   foo( *ptr ); // 2
   bar( *gc ); // 3
   bar( *ptr ); // 4
}

The answer is that all of those work as written, except for #1 which only needs a pin_ptr. A pin_ptr is an RAII helper that pins an object on the GC heap for the lifetime of the pin_ptr. Pinning ensures that the GC doesn't move the object around, during which time it's safe to take a plain old unmanaged pointer to it:

foo( *pin_ptr<int>(&*gc) ); // 1 (fixed)

Or, a little more clearly:

pin_ptr<int> pp = &*gc; // take a pin
f( *pp ); // call any old function taking * or &

The % can bind to any object whether the object moves (i.e., is on the gc heap) or not -- thus % can bind to a strict superset of what a & can bind to. (The & can bind directly to any object not on the gc heap, but requires a pin to bind to one on the gc heap.)

Thorsten also asked:

What has been the rationale for the current design?

In short, to provide pointerlike and referencelike abstractions that work for the general case of garbage-collected memory, which includes compacting GCs that move objects around (so the new pointer/reference abstractions have to be able to track), as close to unmanaged pointers/references in function and syntax as possible.