I’m becoming more of an advocate of namespaces.

Traditionally, they’ve been defined informally by prefixing function and/or variable names with some unique mnemonic – such as ‘Q’ for Qt stuff, ‘wx’ for wxWidgets stuff, or even something as potentially ambiguous as ‘C’ for MFC stuff.

All well and fine and helpful, but you can still run into name collisions. For instance, I was browsing the mac utility headers a while ago and ran into a raft of ‘QT’ names – for QuickTime. Dangerously close to ‘Qt’.

The newer languages, such as C# and Java, enforce namespaces. In C#, you can’t write a single line of code, unless it’s wrapped in a namespace.

The usefulness was heightened for me in a recent project with C#: we were attempting to use an underlying module for statistical binning and drawing. But, we needed a highly optimized version so we could dynamically select bins and draw the results on the fly.

Some customization was in order.

Now, in an ideal world, we would go to the creators, explain what we needed, and collaborate with them to get the enhancements we needed. In the real world, though, the creators are off doing something else highly urgent, and we’re not on their ‘to-do’ list.

So, we did the undesirable: clone the module and get the modifications in, ourselves.

Of course, we didn’t want our version to collide with the older version. How to avoid? Simple: since it’s C#, there’s guaranteed to be a namespace associated with the module. Just change the namespace of our cloned module and proceed.

Voila! (I’m writing this in Paris, so I get to stick in my bit of francaise.)

Of course, things aren’t quite so simple – the binning module used several namespaces (a bit of fragmentation overkill, IMHO), and relied on other underlying modules, which had to be detected and determined if they needed cloning, namespace changes, et al. It still can get pretty ugly. But the namespace feature helped.

Another time when namespaces would have been useful was when a somewhat recalcitrant vendor provided a package with a modified libjpg. Naturally, none of our stuff that relied on libjpg worked any more after we integrated their new code…

After the initial shock and dismay, we had to come up with a solution – the vendor was in Germany and were perfectly happy with the solution, as it was, so were disinclined to make changes. In that case, I think we isolated their libjpg into a fully resolved dynamic library along with their system, and didn’t export the jpeg functions. A pain in the ass, to be sure.

Back then, namespaces weren’t widely supported in the compilers (notably, Microsoft), but had they been, it could have been a better solution. Granted, libjpg is in C, but it can be compiled as C++ and then wrapped in a namespace that would prevent it from colliding with our libjpg (assuming we could get the vendor to cooperate.)

As software grows, and applications become more of a ‘mash-up’ of different modules, namespaces can become an increasingly important construct to eliminate conflicts. For instance, if Trolltech wrapped everything in a ‘TT’ namespace, or, better yet, a ‘TT_QT’ namespace, it would disambiguate them from any other code that might just happen to start with ‘Q’. Like ‘QT’ for QuickTime.

So, in my current effort (creating an extension for Qt), I’m wrapping everything in a namespace (’KIS_QX’). It means users will have to sprinkle ‘using’ statements in their code. A bit onerous, admittedly, but I think utimately that namespace usage is a good habit to get into.

I’ve extolled the virtues of Qt extensively, and will continue to do so – it’s a great toolkit for cross-platform UI development.

Same for Open Inventor (TGS’ version, particularly), for the 3D graphics world.

But, getting those environments is costly: enough to consider having to mortgage the baby and the house, if you don’t have the backing of a major corporation.

Thus the dilemma I faced when needing to write an architectural feasibility exploration program. What to use?

We had Open Inventor, but no Qt. And I needed it longer than a month, so the trial version was not a consideration. The first attempt was to use our OIV with the straight Win32 API.

Yeah, ok, you can do that, but it’s a lot of lines of code, and it isn’t quick. Not exactly an agile environment. Need to do something better.

The Solution

Web investigations led me to wxWidgets for the UI. wxWidgets might be considered the poor sister to Qt (although devotees would argue that.)

And, for an Open Inventor solution, there is either the horse’s mouth – SGI themselves – or the COIN implementation from the Systems In Motion folks in Finland, who provide an open-source version. The SGI is open-source, too, but it doesn’t come with an SoWin implementation, so COIN looked like the better answer.

And, they’re both free – completely free in the case of wxWidgets – less free, but ok for internal/demo use in the case of COIN.

The Conclusion

They worked great! I had to hook up the SoWin directly into the wxWidgets idle loop, but that’s not onerous. Create an SoWinExaminerViewer, parent it with a win HANDLE (available from the widget), and things were spinning, soon enough.

More to discuss in this line, but they look very promising for low-budget investigations or even products that can’t sustain the full investment of their much more expensive counterparts. This is much more true in the case of wxWidgets, since it’s use is free and completely unrestricted. If you’re going to use COIN in a commercial product, you will have to pay…

More to come…

rickb