bloggo ergo sum

Charles Murray put it perfectly:

“A meaningful friendship does not consist of sharing backyard barbecues; a satisfying marriage does not consist of two people living together; a vibrant community is not created by yard sales. All of these relationships are given weight and consequence by the elemental events of life — birth, death, raising children, paying the rent, comforting the sad, joining together to do things that need getting done and (crucial point here) having responsibility for getting those things done. The welfare state says of too many important functions in life, “We’ll take care of that.” The natural human response is to say, “Okay, you do it.” And in this transfer of responsibility the welfare state has drained too much of the life from life.”

I am trying to get some experience building graphical UIs using C++ after hours at work (and also to build a tool that would be useful there as well). I started looking into the various frameworks, and the truth is that there isn’t any magical silver bullet for C++. There is no Swing++, so to speak.

Anyway, I really like the idea of using the Glade tool to build the UI graphically and have it specified in an XML file which would then be read at runtime to construct the actual UI. I did a few toy examples in C to see how it’s done, and I was thoroughly impressed, especially with the signal autoconnect facility in libglade. Connecting callback functions is one of the many tedious things that really make it a chore to build a UI.

After doing that for a while, I thought I’d try the libglademm (and gtkmm/glibmm) libraries so I could benefit from the consistent API and proper object orientation and hierarchy for the various widgets. All very nice. If you want to create a custom widget, you don’t have to bend over backwards to do it; you just inherit from a stock widget and change as necessary, using the base class’ implementation where possible. Here’s what Debian’s Roger Leigh had to say about it:

The C++ code using Gtkmm is slightly more complex than the code using
Glade. However, the benefits of type and signal safety, encapsulation
of complexity and the ability to re-use code through the derivation of new
widgets make Gtkmm and libglademm an even better choice. Although it
is possible to write perfectly good code in C, Gtkmm gives the programmer
security through compiler type checking that plain GTK+ cannot offer. In
addition, improved code organisation is possible, because inheritance allows
encapsulation.

Then, after libglademm kindly constructs your widget objects for you, you just connect your signals. How hard can it be, right? After all, in libglade, all you have to do is this:

#include
#include

/* load the interface */
xml = glade_xml_new("filename-for-interface", NULL);
/* connect the signals in the interface */
glade_xml_signal_autoconnect(xml);
/* start the event loop */
gtk_main();
return 0;
}

This is just a stock example from the libglade reference documentation, of course, but it illustrates nicely how much ugly crapwork you don’t have to do because glade does it for you. That ‘glade_xml_signal_autoconnect’ function is pure gold, buddy, let me tell you.

Anyway, I looked for something similar in libglademm, but there isn’t. There isn’t a Gnome::Glade::Xml::signal_autoconnect because, according to Leigh,

You need to do the connection “by hand” in your constructor, for
example. It’s not possible to connect to C++ object methods
automatically like you can with C functions.

It’s certainly not impossible. It’s especially challenging if you’re going for the most abstract form of portability, but who needs to do that? At any rate, that has no bearing on the fact that gtkmm expects you to derive every widget you use, if you want to use signals at all (and which widgets don’t fall into that category? GtkLabel maybe? Even then you sometimes want something to happen when you click a label). I am completely dismayed by this. Every object has a default signal handler…but it’s protected. What for? I just want to hook up whatever the default signal handlers are. If the defaults don’t do anything, then why aren’t they pure virtual? If they do something, then why can’t they just be exposed so I can avoid creating a new class for every widget I want to hook signals to?

The interface I’m working on has a top-level window with a number of nested widgets down to a pretty deep level (7 or 8 or so). Each level contains multiple widgets. If I want to hook signals to every one of them, everything I’ve read about it to date suggests that I’m going to have to derive tens of new classes, just so I can call their default signal handlers. How poor is that? The code and image size bloat are astonishing, and with all the big virtual tables that have to be constructed, the performance hit is surely unnecessarily monstrous.

*sigh*

Maybe someone who knows gtkmm on a much deeper level than me will comment here and set me straight. I’ll keep posting about this though, because despite its shortcomings, I don’t know that there is anything better for C++ out there right now. Nothing as portable as GTK+, anyway.

Ryan is disillusioned with C++.  The analogy of C++-as-a-person-whom-I’m-going-to-divorce is kinda lame, but his criticisms are typical.  I normally don’t get in blog wars like this, but for some reason, I’m feeling defensive tonight. 

1. He complains about C++ that “You can’t decide who you are”. 

   What this means is that he thinks C++ behaves inconsistently.  Firstly, so does any other language that has more than one compiler.  Java may be an exception, but there aren’t many java VMs other than Sun’s – and even then, there are probably differences.  The C++ standard is clear about expected behavior in almost all conceivable scenarios, and it spells out where the behavior isn’t well-defined.  I think his complaint here ought to be with the “compiler friends” he hangs out with.  He could also find a portable compiler that tries to comply with the standards (such as gcc/mingw or the intel compiler, if he’s on x86.  VS2005 does a respectable job of implementing the standard, but then, it’s not portable in any sense.

2. “Self-denial”? What the heck? 

   Yes, so C++ doesn’t have usable reflection capabilities.  That was an intentional design decision made to prevent the runtime overhead involved – remember, C++ was designed as a tool for creating high-performance software.  Languages and VMs that support real reflection are aren’t.  Repeat after me: C++ isn’t the tool you should use in a project that requires reflection.  Languages that support reflection aren’t the ones you should use in a project that require high performance.

3. I honestly don’t understand his complaint that C++ doesn’t “know what strings are”. 

   He says he has to use a “null-terminated blah blah blah” – which you should never have to do in C++.  And what’s so bloated about std::string?  I find it to be quite nice, actually.  Non-standard third-party implementations need not apply.  std::string works just fine.

4. C++ doesn’t know what arrays are?

   std::vector<int> anyone?  Also, if std::vector<std::vector<int> > doesn’t blow up your skirt, then typedef it.  Sheesh.

5. Templates

   Where to start?  Firstly, C++ having templates is still more than Java can say.  Generics != templates.  The syntax is a little unseemly at first, but it’s an acquired taste – like beer.

6. Dependency resolution.

   Firstly, header dependency resolution isn’t a characteristic of C++.  The pre-processor does that.  Secondly, if your code is so complicated that wrapping all your headers in
   #ifndef _BLAH_
#define _BLAH_
// definitions
#endif
   doesn’t work for you, then your design is broken.  Don’t blame C++.

7. Necessity of design patterns?

   Design patterns are just the outflow of a few decades worth of industrial experience.  People are starting to retire en masse, so they thought it might be a good idea to write some things down.  Why is that a bad idea, and what does that have anything to do with C++?  No language can obviate the benefits of having formal design patterns.  Not even our current rock-star, Ruby.

More generally, what I want say, and what many expert programmers will say until they’re blue in the face and what many other programmers simply won’t listen to is that languages are just tools.  They’re all designed for something, and that something isn’t always the same.  Actually, it usually isn’t.  Use a tool that’s appropriate for the job.  C++ happens to be designed for a very broad and general application domain.  That’s a large reason for why it’s so widely used.  I don’t know that I even know of any other languages that have such a large application domain.  Even Java, C#, and Lisp/Scheme aren’t as general-purpose as C++ is.  The point is use the tool appropriate for the job.  The fact that C++ is a combo compound mitre saw/router/nailgun doesn’t mean it should be used to paint a wall.  Likewise, you shouldn’t use a paintbrush to try and make furniture.  Ruby does not do everything Perl does with none of the downside.  Perl has its strengths, and Ruby has its.  Let it be at that.

Just to address Ryan’s specific comments: the reason certain languages are widely used and “safe” is because of their large application domain (and other reasons as well, many of which ultimately spring from this primary reason).  Businesses don’t want to invest in many niche tools when they can support good general tools for the same or less.

Also, I don’t necessarily disagree with his insistence that we shouldn’t be monolingual (picking up new programming languages should be something any good programmer can do quickly), but I also think that it’s good to be able to fall back on something as an expert. 

Powered by ScribeFire.