Coding, Page 3

First thoughts on Qt

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.

C#: lamer by the moment

To my disbelief, you can’t inherit from generic type parameters in C#. Something like this is currently impossible:

class Foo<T> : T
{
}

It’s sad, really, how Microsoft continues to focus on other crap but leaves out basic things like constraint-based overload resolution or simple inheritance. And still no Spec# features.

C++0x is now feature complete

Herb Sutter posts to tell us C++0x is now feature complete. There will now be about a year of bugfixing and clarification, but that’s it: all the features are now known, and their interfaces are solid barring any bugs being found. This means compilers can finally start implementing C++0x at full speed without too much worry of surprises.

The Committee Draft is not yet available, but it is about the same as the September 2008 Working Draft.

Visual Studio 2010 CTP now available

Coinciding with the 2008 PDC, the first Visual Studio 2010 CTP is now available for download. At first glance, it includes a few interesting things for C++:

I’ll be posting more as I take a closer look at these and other features.

Visual Studio incompatibilities

Hopefully someone reading this won’t have to waste a few days trying to figure this stuff out:

If you install Visual Studio 2008 Team Explorer, you’ll want to install it before VS2008 SP1 or stuff will break.

Internet Explorer 8 Beta 2 breaks the Windows Mobile 6 SDK Refresh—try to click on Platforms in the project creation wizard, and it’ll cancel the dialog. Uninstalling IE8 (Control Panel->Programs->View installed updates->Windows Internet Explorer) fixes the issue.

Converting SVG to XAML

While I understand (and even agree with some of) the reasons behind Microsoft reinventing the wheel and not using SVG for their WPF, I find myself constantly wishing they at least offered it as a supported image format. There is so much SVG out there, it’s a shame to not be able to use it.

On my search for a SVG to XAML converter I came across a few really old and out of date tools, one recent but still sub-par tool, and finally one almost perfect tool: Michael Swanson’s Adobe Illustrator to XAML Export plugin.

As the name suggests, it is a plugin for Adobe Illustrator. It works great, but It’s a bit odd to use – by default, it exports to a canvas which, for everything I’ve ever wanted to use a XAML image, is the wrong choice. Luckily it also supports exporting to a DrawingBrush if you hold down the right shift key when you click save in Illustrator.

DrawingBrush isn’t my first choice of format, but you can easily change it into a DrawingImage resource, which lets you use it just like any other ImageSource. To do so you just take what it spits out:

<Viewbox
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Rectangle>
   <Rectangle.Fill>
      <DrawingBrush>
         <DrawingBrush.Drawing>
            <DrawingGroup>
               ...
            </DrawingGroup>
         </DrawingBrush.Drawing>
      </DrawingBrush>
   </Rectangle.Fill>
</Rectangle>
</Viewbox>

And move it’s root DrawingGroup over like so:

<ResourceDictionary
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<DrawingImage x:Key="someImage">
   <DrawingImage.Drawing>
      <DrawingGroup>
         ...
      </DrawingGroup>
   </DrawingImage.Drawing>
</DrawingImage>
</ResourceDictionary>

Now you can use it just like any other resource:

<Image Source="{StaticResource someImage}"/>

All in all, it’s a fantastically useful tool. If it had some form of UI to select export options instead of asking you to use the shift key (really, wtf??), it would get an A+.

Optimizing exceptions

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.

WCF is pretty neat

I haven’t worked with .NET extensively since a little bit after 2.0 was released, so when I took on a new job developing with it, I had some catching up to do. WCF was the easy part. In fact, I’m really enjoying using it. I can tell they put a lot of thought into making it scalable.

For those that don’t know, WCF is Microsoft’s new web services framework, meant to replace the old Remoting stuff in .NET 2.0. It lets you worry about writing code—classes and methods etc., and it manages transforming it into SOAP and WSDL in the background.

The coolest thing about WCF is the support for completely async design. You start a database query, put the method call into the background, and resume it when the database query is done. This allows the server to run thousands of clients in only a couple threads, improving cache and memory usage greatly.

One funny thing I learned from this is that ASP.NET has full async support too, it just doesn’t get a lot of advertising for some reason. The one thing that annoys me about all modern web development frameworks is the lack of async support making you pay for 20 servers when you should only need one, and here it was under my nose all the time. Imagine that!

Visual C++ 2008 Feature Pack is now available

The Visual C++ 2008 Feature Pack I talked about before is finished and ready for download. This includes a bulk of the TR1 updates (sadly, still no cstdint) and some major MFC updates.

The internationalization test

When choosing a development framework there are many things to look for, but the first thing I notice is solid internationalization support.

Does that seem weird to anyone? That is exactly why. Internationalization is extremely hard to get right, and is usually the last thing on anyone’s mind. If a framework offers fully integrated internationalization, there is a good chance it will be well thought out in other areas and be worth my time to use.