Windows with C++: C++ and the Windows API

A few readers have left comments on my Windows with C++ column for July 2011. I was hoping to respond but there is a problem with the commenting infrastructure that prevents me from leaving a comment. If you missed it, you can read it online now.

Windows with C++: C++ and the Windows API

In this issue, I introduce the unique_handle class template. Here are a few questions I received along with my answers.

Juan Carlos Trimiño asks about the empty throw exception specification as it relates to Boost and Visual C++.

Boost is designed to work with a large variety of C++ compilers. The Windows with C++ column is about Windows and Visual C++. You can of course use the techniques I illustrate with other compilers but you may need to optimize certain practices for your compiler of choice. The Visual C++ compiler will in all likelihood inline all of the functions in the unique_handle class template in which case the throw specification would have no effect. I prefer not to base too many coding decisions on whether or not a function will be inlined. I do not want to take any chances as the performance impact on large code bases can be significant. In the future we will be able to use “noexcept” from C++0x as a more portable and semantically correct way of expressing the same thing.

DavidTM asks about the relevance of the Windows API in today’s world of MFC, .NET and C#.

Libraries like MFC and to a lesser degree ATL are very old. I first learned how to use MFC when I was in my teens. It was designed around an early version of C++ that is not representative of modern C++ style. You can of course still use MFC but I do not recommend it as modern C++ can do a better job of supporting the Windows developer. As for .NET, that is a choice you need to make weighing up your experience, the level of productivity and assistance you expect, and your performance requirements. See my interview for more on this.

Juan Carlos Trimiño asks another question about auto_ptr.

C++0x introduces the unique_ptr class template that completely replaces the older auto_ptr class template. You should never again use auto_ptr for anything. If you need an STL container of pointers then use unique_ptr.

7 thoughts on “Windows with C++: C++ and the Windows API

  1. Philip

    I also had a question about nothrow().
    handle_traits::close() has been annotated with nothrow(), but how do we know that the call to CloseHandle() won’t throw? Are the Win32 API functions guaranteed to never throw C++ exceptions, and only throw structured exceptions?

    1. Jeremy

      The Windows API makes no assumptions about what programming language you are using. As such it will never throw a C++ exception (after all you could be using C, Pascal, C# or some other language).

      In general you can assume they won’t throw anything (unless documented otherwise) except possibly a SEH if you do something that is a programming error on your part (like call an API with the stack full enough that it blows inside the API)

      1. Kenny Kerr Post author

        More specifically, you can assume a particular function will not throw an exception if used correctly. All bets are off if used incorrectly. By exception I mean any type of exception, whether a C++, SEH, or some hardware exception. Even if some Windows API happens to throw a C++ exception, it would not be documented as such since C++ exceptions are not binary compatible and there is no guarantee that the producer and consumer would be using the same compiler.

  2. Kenny Kerr Post author

    The unique_handle class template calls the close function from the traits class only if it has a valid handle. CloseHandle in turn will not throw an exception unless you call it with an invalid handle. The particular type of exception that CloseHandle may throw is not defined. Many of the “CloseXxx” functions I use in subsequent articles in the series behave in a similar way. As you write your own unique_handle traits classes you must ensure that its members do not throw exceptions when presented with valid arguments.

  3. matt

    Kenny, great article! Good to see more C++ content in MSDN magazine. When using the functions listed in your article ie: check_bool, check_hr and friends. How would one determine what specific exception has occured eg: how would once determine that it was a com error and not a win32 api GetLastError. The same check_failed struct was used in both examples.

    1. Kenny Kerr Post author

      Thanks Matt. As I alluded to in my article, I do not in general use exceptions for recoverable errors. There is then no need to distinguish between different exceptions at run time. If you would like to catch these exceptions and be able to distinguish between them then simply define separate types such as check_hr_failed, check_bool_failed, etc. Everything else would stay the same.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s