MarbleMice.com

Some thoughts on compilation speed have been playing on the back of my mind for some time. I have in the past given up on some home projects as the rebuild time was about 5 minutes (on a slow computer at the time).  For C++ that does not sound that bad except the project was only a few thousand lines long. I learn the lesson that some part of boost are really not suited being used on anything but a top of the range computer.

I notices that anything over about 10 seconds when compiling a file or running tests, that is it breaks my concentration. I find running Java tests in NetBeans slightly slow even when there is only a few tests. Sure there are reasons for things being slow and some C++ people would say long compile times means the computer is doing a lot of work for you and type checking a whole lot of things and I can see the argument that you are trading CPU cycles to save you from having to stuff it manually. Trouble is it breaks my concentration which is a negative. So in my C++ programming at home I swing from using some parts of boost to avoiding them because entirely on the basis of not wanting compile times to increase.

Until recently I had not really seen anyone talk much about the problem of long compile times in C++. Well people complain and do the usual tricks but generally accept that the added benefits of the libraries out weigh the extra compiling time. Two blog posts (here and here) actually tackle this issue head on and take the approach that long compile times are a really bad thing. They are avoiding both the STL and Boost to keep compile speeds really fast, they obviously feel the breaking of concentration far out weighs the benefits of these libraries.

Avoiding Boost I can understand but avoiding the STL seems a little extreme, although if I am honest for a lot of the code I write at home I could probably give most of it up as long as I had a replacement for the std::vector class – Which would be fairly trivial to hand role. Most of the other data containers I rarely use. It is not an experiment I plan to do at the moment though but it is good to see some people taking different approaches in their C++ coding

Boost has it, lots of other large bits of code have their own from which you can inherit from. Of course if you are are C++ programmer and don’t what I am talking about! tut, tut you really should. Basically it is an class that is completely empty except it makes the assignment operator and copy constructor private.

This,obviously, stops you from being able to make copies of it and ensures you always pass by reference when when passing it as a parameter. It is easy to forget an & when creating those pesky functions. The down side is it doe not play well with the STL container and so on.

So why am I thinking about this… Well recently I had a conversation about it with a programmer about when to use. By default when I create a class I put noncopyable on it. The other programmer tended to only put noncopyable on a class when the compiler (on its highest warning level) tells him it can’t create a default copy constructor or assignment operator and it really should not be copyable. That is only when it is needed.

We both agreed writing custom copy/assigment operators is generally bad and you should certainly give this sort of thing some thought. I preferred my default as the chance of forgetting a  & on the parameter can have fairly large performance issues and is hard to fine, but could see his arguments about wanting to be warned as early as possible the compiler constructed operators would not work so he could think about fixing them if needs be. The moment I need to use the said class with the STL I go though the same though process. Both being reasonable people we can see the other side of the argument we decide to hit the many books on C++ programming and see what they say. Pretty much all they say is make sure you think about these operators and you should write code that work with the compiler generated ones if they are meant to be copied.

No resolution there then. It seems to be one of those stylistic things you get in programming.  To be honest I can’t really suggest one over the other. At this very moment as I type this blog I am starting to lean towards my friends argument. The pragmatic approach is do as the books say and think about it every time you create a new class and certainly avoid writing custom ones unless you really have to.

Ever since reading the practice of programming (Kerningham and Pike)  where they briefly discuss just in time compilers I have had the urge to write some code to implement a playground Just in time (JIT) compiler. I thought it would be fun to write a JIT calculator! Completely pointly but fun bit of code. I still have not written that bit of code but I moved a step closer. Continue reading ‘Simplest Just In Time Compiler Possible’ »

If you have not read my posts about the first two version of the code you can read about version one here and version two here. Basically the idea has been to use a simple calculator program to demonstrate the boost::graph library. In the latest version and probably the last I replace our hand rolled parser/lexer with one created using the Spirit framework for parser generation.

Continue reading ‘Boost::Graph - Simple Calculate Version 3 (Spirit)’ »

As I mentioned in my original example of a simple calculator using the boost::graph library (BGL) there was a number of things in my code I would like to improve. The major one being a more OO take on the parse tree nodes with each node being represented as an individual class instead of a single class and a type variable. This then naturally leads to using the visitor design pattern for algorithms we apply to the parse tree. This post is about how I went about refactoring the old code use an OO parse tree, I assume you have read my original post.

Continue reading ‘Boost::Graph - Simple Calculator Version 2’ »