November 28, 2014
Hot Topics:

C++ Language Changes for Visual Studio 2005

  • June 11, 2004
  • By Kate Gregory
  • Send Email »
  • More Articles »

The next version of Visual Studio (formerly Whidbey, now Visual Studio 2005) is rich in improvements to the libraries and the usual sort of "behind the scenes" cleanups and speedups that don't get a lot of press. It has plenty of companion tools and new functionalities that will make the lives of developers simpler and happier. But to me, all of that pales in comparison to what Visual Studio 2005 has done with C++. In this column, I highlight some of the C++ language changes awaiting you in the next Visual Studio version.

Bye, Bye Underscore

Visual Studio .NET 2002 introduced managed extensions for C++. The extensions were keywords that started with two underscores, such as __gc or __property. I've written a tremendous amount of code featuring double underscores in the years since the release, and I have to confess that I never really liked it. I understand the reasoning entirely: The double underscores flag the keywords as vendor-specific extensions, and they don't mess with the standards compliance of the compiler. In theory, you could take something full of managed extensions and compile it in some other compiler, which would ignore all the __ keywords.

That was the solution: Microsoft found a way to change the language without changing the language. But that compromise has some consequences:

  • Developers found the syntax unnatural and ugly.
  • Adoption was not all it could be.

Take, for example, the way properties are defined in managed C++:

public __gc class Foo
{
   // hundreds of lines of code
    __property String* get_Text();
   // hundreds of lines of code
   __property void set_Text(String*);
   // hundreds of lines of code
};

Sure, well-behaved programmers put the get and the set right next to each other, and put whatever underlying variables are involved nearby as well. But, the language doesn't ask that of you. It offers no surrounding brace-delimited structure that lets you say "here's a property, as a unit." So while it works, it's not natural and it's unlike the other .NET languages.

But what are you going to do about it? The only way to achieve a more natural integration of C++ into the CLR and vice versa is to really change C++. And, if you're going to do that, you gain some tremendous freedoms to make a natural and elegant language that gives you the best of both worlds. And, you can ditch most of the double underscore keywords while you're at it!

Lifetime and Scope

I just love deterministic destruction. Actually, I love garbage collection, too. Maybe I should get out more. Really, though, they both have their places and I want them both. If I'm creating objects that have only memory in them, I love not having to clean up after myself. Memory management is such a pain! But, when my objects hold a non-managed resource such as a database connection, an open file, or the like, I want to take control. I want to know it will go away as soon as possible. The Dispose pattern tries to handle this, but it's not exactly intuitive. The simplicity of a closing brace is really a much nicer approach.

Here's how things look if you have to do them yourself, working in ordinary unmanaged C++:

//this is a code fragment
{
   try
   {
      Foo* f=new Foo(/* params */);
      //all kinds of code, some of which might throw exceptions
     delete f;
   }
   catch (/* something */)
   {
      delete f;
      //whatever else, or rethrow;
   }

}

Life is so much easier if you create the object on the stack:

//this is a code fragment
{
   Foo f;
   //all kinds of code, some of which might throw exceptions
}

When f goes out of scope, whether because of an exception or not, it's cleaned up. That's natural and pleasant.

When the object is on the managed heap, you don't need to delete it. It will get cleaned up by the garbage collector. But, if it holds a managed resource, you may want to clean it up, perhaps by calling its Dispose() method. C# provides the using construct for this, but it's still not as simple as our stack example.

In the new version of the language (formally called C++/CLI), where you create something does not depend on what kind of object it is. You can create a managed object on the stack, and it can have deterministic destruction, being cleaned up when it goes out of scope. If you prefer, you can create it on the managed heap. It's your choice.

This change carries other consequences, though. One of the most far-reaching is that you can easily put any kind of object into a "templated" collection or as a member variable of another class. You can get the full C++ strength for lifetime management, rather than only "allocate on the heap and wait until the garbage collector takes care of it."





Page 1 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel