New home for technical stuff

A friend of mine has started up his own blog hosting site - so I've decided to split my blogging. Technical stuff will now be over there, in the second drawer. Here will be the random thoughts that come out of the third drawer.

So go visit The Second Drawer for reading my technical stuff... and while you are there you can help my friend out by clicking on some of the google ads!

Who's guess?

I'm currently watching The Great Global Warming Swindle on the ABC. It all appears like they are just making guesses... probably in both directions. Such historical science involves so many estimates, so many guesses.

I saw it when I was working for CSIRO - my boss was a modeler, constantly analysing the historical data and feeding in parameters to try and predict crop yields so that a good model could be determined to help establish the relationship between those parameters and the outcome. From that practical steps could be performed. Published in a journal there will be a reference to me because I wrote some simulation software as work experience before I began there. I think it is good work.

BUT the software that my boss used (not the software I wrote) had hundreds, if not thousands, of parameters. You take such a complex system as our world and in particular weather systems and it is hard to make predictable models that really show what is the cause and the relationship between these parameters.

So does this mean we can sit back on our hands? No. I think like everything else it needs to be done with consideration and moderation though. There is always someone that is looking to capitalise from any opportunity, and many already are (for better or for ill). Living greener is always a benefit, however I do see the one point that was made about the developing nations being disadvantaged. Certainly there is a need here that needs to be addressed. They hold one advantage however - they can make the jump of the last 30 years of development, where we have learnt the hard way, and use the modern technologies. The cost is still prohibitive, but if it is determined that this is the way forward then subsidising the alternative power sources is a requirement.

It is interesting that the discussion of alternative energy sources has almost died out. Have we forgotten that we are using non-renewable energy now? That in itself is good reason to develop and promote the development of alternative, renewable energy sources.

I think it was an interesting show, and interesting discussion (if it could be called discussion, there was very little listening going on, and a hell of a lot of stating opinion) . It seems like there is a lot of misleading "evidence" on both sides of the fence (I remember reading some comments on Gore's doco - which I should watch at some point). I certainly site to the left side of the argument still, but as one of the commentators said, it is our position to remain skeptical.

The right question.

Warning: Technical content included.


The Internet has a whole crap load of information on it... and wading through it can be a difficult task, and is a skill that has to be acquired. Google has made it easier, and for that I respect them.

But it all comes down to asking the right question.

The issue I've been struggling with recently is to do with pure virtual destructors in C++. In my previous job I worked almost exclusively with Java and so my C++ knowledge comes only from uni days... which was pre STL to give a time frame for it. For the last year and a bit I've been working with a mixed C++ and PHP environment... with some legacy Borland Kylix thrown in to give me white hair. Recently I've been trying to work through the design and reimplementation of our backend which I've been trying to do using the best of OO. This means lots of C++ classes and good inheritance models... and trying to understand some of the basics of inheritance coming from a Java background. This means I refer to things as interfaces etc. The main thing with this, I've not really understood is how and when to use virtual destructors. From my understanding if you wanted the equivalent to a Java interface you would declare the class with a pure virtual destructor (virtual ~MyClass() = 0). If I forgot to make the virtual destructor the GNU compiler with -Wall would politely remind me that I hadn't specified a virtual destructor when I had virtual methods. Which I would then do by making the the destructor a pure virtual... which would then give me errors at run time saying that it tried to execute a pure virtual destructor. Also I've been implementing plugin systems (using dlopen) and these would not work with pure virtual destructors. Its all confusing.

So given my ignorance I finally worked out the question to ask - when to use a pure virtual destructor. A quick google came up with this link: http://www.gotw.ca/gotw/031.htm which filled in the missing detail:
If the class should be abstract (you want to prevent instantiating it) but it doesn't happen to have any other pure virtual functions, a common technique to make the destructor pure virtual ...
Of course, any derived class' destructor must call the base class' destructor, and so the destructor must still be defined (even if it's empty):

So in summary the points I learnt as a Java person moving into C++ land:

1. There is no such things as an Interface in C++ - everything is an abstract class - and that is ok because C++ allows for multiple inheritance


2. The closest thing to an Interface is a class with only pure virtuals - but you still must have implementation for the destructor!!

I love Objects

Warning: Technical content included.

I've been paid to be a software developer for almost 7 years now and the truth of the matter is that all through that time I've been following the OO design principles, knowing the benefits and only occasionally making use of some of the large advantages. But two nights ago (I've been meaning to post since then) it came to my rescue.

A bit of background - I've been developing a website for a friends printing business in my spare time (www.rooprint.com.au). I threw myself into it going through a proper design and have spent some good hours setting up a good framework for the website with PHP as the backend because of the options with his web hosting company. I normally avoid anything HTML related, because cross browser development is down-right evil... but having been playing around with it at work I got excited by the prospects of AJAX for a second or two (the site currently only partially works in any other browser than firefox - I'll probably post more about this later).

Anyway I had the site up to a stage where I needed to put it on the net for me to show my friend, and also to allow me to test all those evil browsers that don't work. So after battling through a local install of PEAR and then HTML_AJAX within the local user area I came to try and view my lovely creation and learnt the hard way that the hosting company only really has PHP support on the server so they can run PHPMyAdmin. What does this mean? That the MySQL PDO driver wasn't installed, and "couldn't" be installed.

Thankfully I had followed good OO design principles and written a wrapper class for all database queries. With a little bit of work and a lot of learning about the mysqli PHP extension I rewrote the class with use mysqli and whacked it in and all works peachy - no changes to the actually code running around it. Well I did make one change - I decided not to implement the equivalent wrapped call to pdo_statement->execute(array) which I was using in one instance rather than binding the parameters individually.

Woot OO!