int64.org

Qt 4.5 is out, along with Qt Creator.  It’s still using GCC 3.4.5, from a January 2006 codebase.  Sigh.

I’ve been doing so much C# and XAML coding for work lately, I felt compelled to get back to the place I thrive — real C++.

I’ve always been weary of cross-platform C++ GUI coding.  The options just never seemed very good to me: GTK, which doesn’t act anything close to native in Windows.  Qt, which seemed good but was under GPL.  wxWidgets, which feels like a thin wrapper around Win32 (and was therefor quite easy for me to learn) but has lots of little issues like the inability to scale with DPI.  Given the announcement of Qt going LGPL, I figured it’s a good time to start learning Qt.

If you’re like me you might be thinking – “Qt, but that’s not real C++!  What happened to using the standard library, templates, and not paying for what you don’t use!?”.  Do I wish there was a more modern Boost-quality library?  Absolutely.  But that doesn’t exist.  Perhaps because GUI work is rather boring, and coders who could make a better quality library would rather spend their time on more interesting things.  Qt is still the most modern GUI lib I’ve seen for C++ yet.  But I digress.

Hunting around the Qt website, first thing I find out: it’s going to be a pain in the ass to compile my Qt-based project with VC++.  I’m sure it’s possible with a little elbow grease, but I wanted to get started quickly so I downloaded Qt Creator instead.  Creator has a bundle that includes MinGW, Qt, and the Creator IDE.  Perfect for a quick start!

Creator turns out to be a pretty good IDE.  It is very close to knocking VC++ out of my favorite position.  With a few bugs and usability issues fixed, it’s possible I’ll be using it even for pure Win32 apps.

I create a GUI project, hop into the designer and lay out a simple window.  I haven’t even read any documentation or tutorials for using Qt at this point, so I get a little stuck.  There are no Creator tutorials out there yet, so I skimmed through some other Qt stuff and quickly found my way to the layout model – exactly what I was looking for.  The best thing I’ve found in WPF is the ability to have a window layed out automatically based on the size of controls in it, and I’m very pleased to see Qt has something similar.  Tie in some events, and I have a simple app created.

Compile the project and oops, some errors pop up.  After a little hair pulling, I found out the Creator bundle comes with MinGW GCC 3.4 — very old!  It was not compiling some of my standard C++ correctly.  I’ll see about integrating TDM’s GCC 4.x builds soon, but fear it will mean recompiling Qt.  For now I’ve begrudgingly dumbed down my C++ to the subset that GCC 3.4 works with.

In one day I’ve learned how to create a functioning GUI program with Qt.  I’ve also backed away from the designer and learned how to do things manually – I’ll definitely use the designer for a serious project, but learning how things work behind the scenes is important too.

All-in-all I’m impressed with Qt.  It feels native on Windows, and has a relatively clean API.  It is more powerful and productive than straight Win32, but doesn’t seem nearly as powerful as WPF.  Then again, it took me several months to wrap my head around WPF enough to build anything of substance.

This is fantastic news for anyone developing GPL-incompatible software.  Nokia will be releasing Qt under the LGPL.

You might often hear about exceptions being slow. For this reason they are usually shunned in the embedded space, and sometimes even for regular desktop/server programming. What makes them slow? When one is thrown it needs to search through the call stack for exception handlers.

I guess I don’t understand this line of thinking. For one, exceptions are meant for exceptional situations: things you don’t expect to happen under normal operation. Code that uses exceptions will run just as fast (or maybe even faster) as code without, until you throw one. These exceptional situations are truely rare, so I usually don’t care if they do happen to run slower.

A compiler can actually use exceptions to optimize your code. Consider this inefficient (but typical) pseudo-C:

int dosomething(void) {
   /* do something A */
   if(err) return -1;

   /* do something B */
   if(err) {
      /* cleanup previous work A */
      return -1;
   }

   /* do something C */
   if(err) {
      /* cleanup previous work B */
      /* cleanup previous work A */
      return -1;
   }

   return 0;
}

Or even this more efficient (yes boys and girls, goto actually has a good use case in C, get over it) pseudo-C:

int dosomething(void) {
   /* do something A */
   if(err) return -1;

   /* do something B */
   if(err) goto err1;

   /* do something C */
   if(err) goto err2;

   return 0;

   err2:
   /* cleanup previous work B */

   err1:
   /* cleanup previous work A */

   return -1;
}

Why are these bad? Cache locality. In the first example, you have error handling code inline with your regular code. In the second you have it slightly better and off to the end of the function. Ideally the code you run will all be compacted in as few cache lines as possible, and erroring handling this way will waste significant space on cleanup code that in the large majority of cases won’t be run.

But with exceptions, the compiler is free to take all the cleanup code in your entire app, and shove it into a single separate area of code. All your normal code that you expect to run can be compact and closer together. Of course, this will make exceptions run slower. If your code is heavy on throwing exceptions (which would probably be an abuse) it will probably cause a significant overall slowdown. But if they are used correctly–for exceptional situations–then the common case will be improved cache usage and therefor faster code.

Channel 9 has an interview with Stephan T. Lavavej of the Visual C++ team showing off some of the new features in TR1, the new draft standard library additions for C++0x.  While the interview will probably have nothing new for competent C++ developers, Stephan does go into good detail explaining the unique strengths of C++ that newbies may not immediately see.

If you’ve thought of C++ but have been scared by its complexity, or have been tempted by newer garbage collected languages like C#, this will probably be a good eye opener.

Being in IRC, every so often you will find someone heralding the use of strncpy for writing secure code. A lot of the time they are just going off what others have said, and can’t even tell you what strncpy really does. strncpy is a problem for two reasons:

1. It silently truncates data. When, in all of your experience coding, has silent truncation been acceptable behavior? Replacing one bug (a buffer overflow) with silent truncation is not a fix, it’s just hiding the problem.
2. strncpy does not do what you think it does. It is not made for security–in fact, if the buffer runs out of room it will copy into the last character, not adding a null terminator! So once again, you replace a buffer overflow with another bug.

Bugs happen. Sometimes we build sanity checks into programs to combat unknown ones before they become a problem. But strncpy is not a sanity check or security feature–using it instead of resizing a buffer to accommodate the data, or just outright rejecting the data if it gets too big is a bug.

It’s here!  A beta of the promised TR1 library update has been put up for download.

Included in the pack is an update to MFC that adds a number of Office-style controls.  Wish they’d put these out as plain Win32 controls, because I’ve got no intention of using MFC!