Writing A Decent Library

When you are writing a shared library (DLL) you have to put a lot of thought into the public interface which your customer (another programmer) will be using.

What you have to work out is whether it is closed or open source, whether the binaries are supplied, and how you keep the user from having broken interfaces on different versions. All of this is from the point of view from a C++ programmer.

I think it is best to start with how not to write a closed-source library:
* Do not use templates.
* Do not have implementation half in the binary and half in the headers.
* Do not expose the innards of your program.

When creating a closed-source library you have to firewall the innards (which are probably commercially sensitive) from the interface. This would mean some use of the Pimpl Idiom.

You need to use solidly defined types like if you were binding to another language like Python. This means that the implementation can live in the binary and the interface is defined in your headers.

One of the problems it is easy to encounter is when STL is exposed in the library. The problem occurs when people use different implementations of the standard library which means you either need to maintain versions for that particular setup.

By making those two decisions you can massively simplify the maintenance and the headaches of people trying to implement it. You have to think carefully about the simplest interface for the developers who have to work out how to integrate it.

By not exposing the innards of the library you can also protect yourself from problems when the library loads/unloads because you can't have conflicting CRTs/libraries.

I suppose what I am suggesting is to have the most simple public interface and make sure that all implementation is hidden away. Almost only using a C interface for a library means you don't encounter the problems where you have to think about supplying a version for each version of the compiler your users have.

SPA Cambridge Talk - Windows Presentation Foundation (WPF)

The latest SPA Cambridge talk is coming on the 14th November, follow the link here to sign up. Here are the details:

Windows Presentation Foundation

Ian Griffiths Interact Software Limited

Synopsis

Windows Presentation Foundation (WPF) is a platform for building Windows desktop applications that can take full advantage of the graphical capabilities of modern PCs. Whereas many UI frameworks in the past have merely added yet another layer of abstraction on what was there before, WPF is radically different from its predecessors. This talk will discuss what possessed Microsoft to abandon the strategy of incremental tinkering that has served them well for over 20 years of Windows application development. WPF shifts away from many of the fundamental mechanisms that had been in place since the first version of Windows, and we will explore the new possibilities this creates.

Speaker Biography

Ian Griffiths is an independent WPF consultant, developer, speaker and Pluralsight instructor and a widely recognized expert on the subject. He lives in London but can often be found on various developer mailing lists and newsgroups, where a popular sport is to see who can get him to write the longest email in reply to the shortest possible question. Ian maintains a popular blog and is co-author of "Windows Forms in a Nutshell" and of "Mastering Visual Studio .NET".

ACCU Cambridge Talk - Agile Development

Thursday 1st November is the next ACCU Cambridge talk. This month's one is about Agile Development:

So you want to do Agile software development? How, or where do you start?

In this talk Allan looks at the problem of changing your organization over to Agile software development. He gives some advice on how to go about introducing the ideas and which practice(s) to focus on first.

You can sign up through the ACCU website on this page. Once3 again it is hosted at DisplayLink on the top floor of Mount Pleasant House.

Another Cambridge Talk - Joel Spolsky

As part of the FogBugz World Tour Joel Spolsky of Joel On Software will be doing a talk in Cambridge.

The main basis for it is to drum up interest for FogBugz v6.0 but it will involve some discussion of the software development process. You can sign up for the talk here.

Static Code Analysis - PREFast

At work we use Gimpel PC-Lint to analyse our source code for defects that the compiler does not pick up. We use it on quite a strict level even after bolting it on to a legacy code-base. There are some tools to make your life a little easier when using it from Riverblade Software. Gimpel Lint is not a perfect tool for an IDE as it is commandline based and these types of checks should honestly be part of a good quality compiler as additional warning levels.

What I have found out though is that in Visual Studio Team System there is a static code analysis tool that isn't even available in the Professional version. It's internally called PREFast at Microsoft and apparently they use it to ensure code quality. Apparently in the Windows Driver Development Kit (WDK) it is available so it is possible to use that to do some code analysis. Check out this blog post for instructions. There are plenty of blog posts about it on the rest of Steve Dispensa's blog.

There is a small Microsoft Research Article available here about PREFast.

I've downloaded VS Team System to give it a go and to see how good it is. Or maybe I will try out the PSDK hack...

Tools To Make A Developers Life Easier - Trac

Trac by Edgewall Software is at its most simplistic level an issue tracker that provides source control integration (mainly for Subversion). But it is much more than that, it also has a built-in wiki, source browser, and project management through the ticketing system.

It's a really decent tool for make developer's lives much easier and it looks nice too. As you start doing more with it you can really see the power in there. You can work out a roadmap/timeline from your tickets and also generate changelogs.

But all this isn'y new to the world out there, what I discovered today was Trac Hacks which is a repository of Trac add-ins and enhancements. There is a code review plug-in, a blog plug-in, and simply too many others to list.

So combine Subversion with Trac for a good experience, then add plug-ins to fill the holes in the development process.

GUI Toolkits - Ultimate++

Ultimate++ is a GUI toolkit with its own IDE, GUI designer, build system, collections, and more. In the recent past it has improved its integration into the operating system with its Chameleon technology for native look and feel.

Unfortunately at the moment it is not 100% geared to be used as a library and you have to use the supplied IDE and development tools to use Ultimate++. Someone has been working on it though and maybe there will be a full released solution soon. If this does come to fruition it will be seriously interesting.

I had a quick read through the Ultimate++ forums recently and came across some interesting things that would make it a more desirable GUI toolkit to use.

First up you have an Office 2007 look skin. This won't be the full ribbon-based UI or anything but it should be interesting to see how it looks and maybe be extended.

Secondly there is the docking toolkit. This looks like a fairly comprehensive docking kit written very quickly. Some of teh examples even had the HUD style docking of Visual Studio. Also, if this does come to fruition this is a very important feature for people evaluating the system.

This toolkit will certainly be moving very fast in teh near future and if these features are suitably polished then it may look like a competitive toolkit to use.

Build Systems

I was setting up the Visual Studio build system to target not only multiple build types but multiple platforms. This is the point I discovered hand editing the solution files is the only way to maintain consistency and accuracy of the builds. This is because the ue interface provided is antiquated, a struggle, and worst of all, unpredictable.

Build systems are really separated into two camps, text file based, or IDE based. The text file based ones give you the most control and flexibility, but in this day and age it is a real shame that they are the most useful. Also you may need an unknown macro language and will probably need to know every compiler setting that you want to set. The IDE based ones tend to require manual intervention in some undocumented or badly documented file format. This immediately negates any advantage you previously had.

I am amazed these parts of the IDE have been so neglected since without it you will not get predictable results. You want easy ways to compare different configurations or projects to see if they are out of step. There is also no way of batching changes to a set of projects (you can get some sort of batch changes with configurations although you are not really sure of what you are doing).

Maybe there is a better way? I don't know what else there is out there apart from premake systems (eg, CMake, Premake), script based build systems (eg, make, Boost.Build), and IDE based systems (Visual Studio et al). You almost want the equivalent of the Apple stye reimagining for debugging/profiling like XRay in the upcoming OS X Leopard.

One of the things I am dead proud of recently is the one touch build release kit from within the Visual Studio IDE. This means you just need to hit build and at the end you get an installer exe with no need for any jumping through hoops. It would be nice if you didn't need really work hard to get to that stage.

C++ and 64-bits

When pursuing the development of a 64-bit native program you realise that everything is not what you thought it was. Somehow I had convinced myself of the wrong sizes for the built in types. This wasn't due to ignorance but due to the plethora of 64-bit implementations.

I'd somehow convinced myself the data model I was programming to was ILP64, but for Windows as it turns out uses LLP64. Normally you don't discover it until you get to the point your program collapses in a heap under heavy load.

Here are some relevant articles here, here, here, and here. The good thing is if you statically check your code with something like Lint pretty strictly a lot of the problems you would normally encounter don't exist.

For the data models have a look at this article. For some reason the table won't display correctly in my blog.

Complete Insanity In The World Of Computing

And now for something completely different...

I thought I would share some of the more insane things I have heard in the world of computing.

No Source Control

It's amazing to think that a company can get away without source control, let alone a company supplying closed-source library functionality. This meant that regressions happened at an alarming rate and a bugfix could result in previous bugfixes being undone. The "repository" was a copy of the source code on a server and developers would copy the files to their computer, edit them, and then copy the changed files back to the server.

C# Developers Must Be Expensive

To make it easier to maintain a product when it is written in C# but you have lots of Visual Basic developers, convert the product to VB... This was apparently done by taking the semi-colons off of the end of the lines then compiling to see where the errors are.

It seems to me that the process is completely insane and devoid of any merit. First you do not understand the code, this will adversely effect bugfixing. I am sure that the fallout from that kind of development will be felt for years.

Visual Sourcesafe Is Fine

It's easiest to witness the insanity of using Visual Sourcesafe from the sane world of proper revision control systems. Sourcesafe does not give any data integrity, can lose stuff, is impossible to script in any meaningful fashion, has a terrible architecture, and more...

I am talking about v6.0 and older here (I have no idea about the package that has inherited the name).

I see things like source control as integral to the development experience and productivity of your team.

The Phantom Build System

A developer on their own work computer has the only scripts that run the build kit. Once that person leaves noone can do it and there is nothing to reverse engineer from. It then takes perseverance and a small amount of brilliance to get to a working release installation kit.

EVERYTHING to build your program should be well documented and under source control as much as possible. It should be able to be run from any computer following the written instructions.

SPA Cambridge Talk - Test Driven Development

After an extended summer break the SPA Cambridge talks are back. A change of venue to Anglia Ruskin University has now happened which is much better due to close vicinity to many pubs which was a problem with the Microsoft Research venue. Thee events are organised by Mark Dalgarno and you can read his blog here.

This month's talk was about Test Driven Development by Ivan Moore. It was an interactive session requiring a laptop and Eclipse. Unfortunately I discovered I must have the only copy of Eclipse in existence not set up for Java development (I have used it for Python and C/C++) a bit too late to rectify that.

The exercise was to solve a blocks world problem with test driven development. We used Java and JMock for this. I also got to show my Java ineptitude since I haven't used it for 7 years properly, so I was learning on the fly. To be honest now I go back to Java it is a lot more inelegant than I remember. At least after all that I managed to get the tests to pass...

The interactive sessions are a bit more fun when you are sharing a computer, especially when all three of us huddled around it have very little practical Java experience.

The next talk will be from Ian Griffiths about WPF (Windows Presentation Foundation) on the 14th November.

ACCU Cambridge Talk - Closing The Case For Groovy

Two weeks ago I attended the latest ACCU Cambridge meeting called Closing The Case For Groovy presented by Russel Winder. It was very kindly hosted by Displaylink again.

This talk was about dynamic languages concentrating mainly on Groovy. It is a dynamic language which is compiled into JVM bytecode meaning it can interact very nicely with Java. What was particularly refreshing about his talk was Russel not talking about language wars but how they can cooperate together. Overall the talk was entertaining and informative especially from the point of Closures which I really needed to learn about.

Obviously the pub visit afterwards was essential.

The next talk will be on Thursday 1st November by Allan Kelly. If you like technology and development and live in or around Cambridge then these talks are essential.

Virtualisation - An Understanding

It's amazing how many mistakes it is possible to make when attempting to understand a concept. Up until a couple of weeks ago I had some misconceptions about virtualisation. I've used it through VMWare and have viewed it as a way to have a virtual layer on top of your processor.

Then some concepts coalesced from various articles I was reading.

Virtualisation is the abstraction of resources away from their use. At the moment the most common use of virtualisation would be memory. You get a virtual address space from your operating system - this can be mad up of RAM, ROM, cache, hard drive, flash memory, and probably more. You don't know what you are accessing but the virtualisation of those resources and their access makes it easy to use.

One of the catalysts for my understanding was iD Software new iD Tech 5. There was mention of Megtexture which was texture virtualisation allowing the use of massive amounts of textures for the rendering. This would no doubt be a way of not needing to know about the basic building blocks of the textures, but to use them through a virtualised interface.

Then this comes to the processor virtualisation. My misconception was because of the examples I had seen from Parallels and VMWare. It allows you to run multiple computers on a single processor. But what processor virtualisation should do is abstract away the processor resources allowing the program to run. This would mean that you would not care about multiple cores or even computers, you could in their run one virtual machine which has a backend of a massive cluster of computers. I don't know if this is the case yet as when you do parallel processing you still nee to know too much about the parallelism in order to develop a solution but I imagine some solutions must be able to do it.

GUI Toolkits - MFC v9 - Visual Studio 2008

This is a sad thing to get me excited but Microsoft seems to have been keeping something up its sleeve for Visual Studio 2008. Normally nothing is a surprise with Microsoft and I had assumed that we had seen all we would from VS2008 in the latest beta.

As it turns out they have a massive update for MFC dropping for Visual Studio 2008. It had been alluded to here and by Herb Sutter here. I assumed that we would have to wait for the version after VS2008 since the beta was largely the same as VS2005.

At Technet 2007 in Spain there is a talk:
Title/Code: TLA404 MFC Updates for Visual Studio 2008 and Beyond

Presenter: Ale Contenti

Abstract: This session will demonstrate the new features added to MFC in Visual Studio 2008, including support for Vista Common Dialogs, Vista Common Controls, the Microsoft Office 2007 Look and Feel (including support for an Office Ribbon style interface), Office and Visual Studio style Docking Toolbars and Tabbed Documents. We will also talk about our plans to evolve the MFC library for Visual C++ 10 and beyond. This is an in-depth session designed for experienced C++/MFC programmers. (C)


Do a search for the speaker here.

So it looks like the people using MFC will be getting some very powerful UI features as standard. I'm not so bothered about Vista standard controls but more powerful docking would be very nice and would go hand in hand with tabbed document interfaces. The most exciting part is the Office 2007 look 'n' feel along with the ribbon user interface (is it RibbonBar? I don't know...). I guess we will find out more in November but this is good news for people maintaining MFC systems.

GUI Toolkits - Some thoughts

I mentioned a couple of posts back that I was going to put some thought into GUI subjects and maybe trying out writing a simple toolkit.

I was thinking abut which way to jump with trying to write a toolkit. First of all what should it be based on? Should it just wrap Win32? Cocoa? Should it be entirely implemented on top of OpenGL from scratch? Should it be cross-platform in design? Just these questions could cause anyone to run away screaming.

Thinking about building it on top of OpenGL I encountered a couple of interesting GUI libraries GLUI and GLOW. In these projects the windows are completely rendered by OpenGL which is an interesting approach. I suppose Juce is built from similar roots as well where it implements its own toolkits.

I was thinking about writing a nice C++ wrapper for Win32 but then I started to think even Microsoft products don't use the standard widget rendering. Then you start to think about built in custom drawn widget rendering, then you think why are you using standard widgets...

The whole idea about implementing a simple GUI toolkit is an education about the design decisions and pitfalls that you can get into. You also need to decide which subset you decide to implement first. The problem is most toolkits go for the same 10% and that is normally as far as they get.

The main idea I want to try out for an experimental GUI toolkit is some DSL (domain specific language). What I mean is embedding a language in C++ in order to implement the user interface in a readable fashion. It is certainly possible using modern C++ idioms as demonstrated in Boost. I suppose the type of thing I want to do is (in some kid of C++ like pseudo code):

dialog(...) +
widget("Number", sizeX, sizeY) | widget(RESIZE_X) ||
widget("Name", sizeX, sizeY)   | widget(RESIZE_X) ||
widget("Blah", sizeX, sizeY, RESIZE_XY)
;
toolbar() +
button("image1", ...) |
button("image2", ...) |
separator() |
button("image3", ...) |
button("image4", ...)
;

Complete and utter insanity? Probably, but could be fun to try out. It would certainly be something different and would create a parallel in your source in comparison to what you would see on screen. I don't think anything quit like it has been tried before, so feel free to steal the idea - it would save me implementing it(!)

Enough rambling for today I think...

One Year Old

It's hard to believe this blog has been going for one year as of today. I can't believe I actually remembered this since I never managed to spot my 100th or 200th post.

It has been quite a year really. NC Graphics were taken over by PTC meaning I am now with a third employer working on the same codebase (in four separate stints).

Certainly the most popular items on the blog have been the TortoiseSVN and Visual Studio integration and recently the STLPort debugging in Visual Studio. Thanks to all the readers and all the comments.

I would promise something for the next year or some manifesto, but if it is as action packed as the previous year I somehow doubt I will live up to it. All I can promise is if I learn anything interesting about computers I will share it with the rest of the Internet.

Normal service will now resume.