Saturday, 9 December 2017

Start C++?

I've been writing C++11 or better code, well since 2010, as I started doing so with the TR1 as was.  We're nearing eight years since then, and it starts to show.

So, where would I recommend starting to learn modern C++?  Well, if you've never programmed before, don't start by learning C or C++, go learn Pascal, or Python, or something else which is more friendly.  I started out in Pascal, for a good three years, before I started to work in C and later moved into C++ (in 1998) so if 20 years of C++ teach me anything, it's don't try to learn if as your first language.

Once you have a concept of how to program, then start to learn C++, and I would recommend finding someone - hopefully like me - and asking them.  An hours chat with them, to help swap what you know with what they know, is a good start.

Saving any such friends, YouTube, watch CPPCon, BoostCon, watch talks about programming C++ but most importantly get a development environment and cut some code, if you must go for a community edition of Visual Studio 2017, but otherwise get a Linux machine up and running and have a play.

If you work in an office where there's a C++ guru, ask them, if they're worth their salt they'll be more than happy to take you through a few things.

And failing that, I include a set of programs below, one through three, these are the most simplistic C++ programs I would recommend you start off working with, and if you want to know more comment below.

So, open an editor, and write this C++ code, then save the file as "main.cpp":

#include <iostream>

int main ()
   std::cout << "Hello World";


If you are in Visual Studio, you run that file, if you're in linux close the editor after saving and lets use the gnu g++ compiler (install it in Ubuntu say with "sudo apt install g++"), and you compile this into a program like so:

g++ main.cpp -o example1

Your program output will be called "example1", and you can run that program, and it'll say "Hello World".

The code itself I want to only explain the first line... the include, this tells the compiler to include some code for you to use, and "iostream" is the input/output streaming functions for you.

int main is the first function the program starts to run from, int is the return type, meaning integer, but in C++ we don't need to return a value here - if anyone argues with you about this, they're wrong.  The name "main" is the a special name and the compiler makes sure your program starts with this function entry point.  The empty brackets show we're not passing anything into the function, there are no parameters.

The braces mark out the body of code for the main function, so it starts with an open brace, contains lines of code and then ends with a close brace, and yes I call them "braces" not "curly brackets" :)

The one and only line of code we've got left is the output call, this is streaming the value on the right of the "<<" chevrons to the standard character output stream... "std::cout"... I'll reiterate 'standard character output stream".   And the value we're streaming is a string (note the quotes in the code) "Hello World".

This is the only line of code with the all important semicolon ending, this is used to tell the compiler that we're done with out line of code.

Go, try this...

The next most basic program for C++ noobies to learn, is to maybe output some more kinds of data.... After say, asking the user something...We've seen cout, how about "standard character input"?...

#include <iostream>
#include <string>

int main ()
    std::cout << "What is your name? ";
    std::string name;
    std::cin >> name;
    std::cout << "\r\n";
    std::cout << "Oh Hi " << name;

We're introducing a new header, the "string" header helps us store strings of characters in the type "standard string"... "std::string"... Did you spot that?... This is our first variable, and it has the name "name" so we can refer to it later.

As ask the user a question by sending characters out "<<" to the output stream, and then we read them back in ">>" from the character input stream, and we read them into the "name" variable we just created.

Next we output a carriage return "\r" to move our carat back to the left of our screen, and we move to the next line "\n".

And finally we output a piece of text AND our input variable!

You can play with this code with other variable types, other than string... Try "int" to read in a whole number, of "float" to read in a floating point number.

But our third program, will involve some actual processing.... Lets average the age of a set of people we ask the user to input...

#include <iostream>

int main ()
    int TotalAge (0);

    int age;
    std::cout << "Enter the name of person 1: ";

    std::cout >> age;
    TotalAge = TotalAge + age;
    std::cout << "\r\n";

    std::cout << "Enter the name of person 2: ";
    std::cout >> age;
    TotalAge = TotalAge + age;
    std::cout << "\r\n";
    std::cout << "Enter the name of person 3: ";
    std::cout >> age;
    TotalAge = TotalAge + age;
    std::cout << "\r\n";

    float Result = TotalAge / 3;

    std::cout << "The average Age is: " << Result

Here we have much more code, we ask for each persons age, adding it to the total, then we calculate the resulting average age and print it out.  Take a moment to look at this....

What do you see?  If the first thing you see is that there are three sets of the same code in there, then you have the seed of a programming within.  If however you just see a mess, then maybe C++ isn't for you.

Monday, 4 December 2017

Great Rack Mount Mistakes #5

It has been a while since I've brought to you the tales of woe from my past... But this one isn't a tale of woe for myself, it was some other poor bugger who had to suffer, though I was involved.

After my first in-depth IT related job, I got into looking after some big systems, and I mean so Big they could have starred Tom Hanks... The last one of which ended, officially in early 2001, this was my looking after an IBM AS400 machine.

It had several terminals hooked into it, many suited analysts (as the non-programmers were called) regally sipped coffee and generated reports from it, there were also several ASCII Serial wireless hand-held terminals for roaming about the site with, all pretty cool.  I however was not involved in any of this, my job was to look after the PC's on the site and keep the AS400 fed with back-up tapes.

One of the PC's however took me within a solar breath of the chorona of glory that was working with the BIG IRON, and this was a little IBM PC, running OS/2 which was used actually boot the AS400, the mechanism escapes me, the details I've long forgotten, I remember it using OS/2, a terminal and a fancy script.

As I said this role ended for me in 2001, and I whisked my way off to work for a little software shop in Alcester, Warwickshhire (where I know I was a lazy pain in the arse - sorry about that lads - I grew up later, honest!).  Anyway, 23rd December 2001, I had a call at my parents home, a chap asking for me by name.  They handed out my personal mobile (Rocking the Nokia 3310 on Genie Mobile).

Well, this guy didn't let up, Christmas Eve, I'm mid-way through watching the Muppet Christmas Carol for the fifth time that day, and I finally look at the phone, and the seventeen texts to call the head-office of my prior employer.

Which I do, and awake a security guard whom had less hold of English than my dog, and the dog's Greek...

After a mixed conversation, I got through to a chap who was clearly in a server room, you could hear the noise behind him, I love that noise.

As he's talking to me however, the noise disappeared, dead silent...

"Did you just leave the server room?"

His reply.. "No, it just shuts off, it never completes its boot".

He was talking about the AS400, of which I knew nothing, they had very expensive IBM support for it on the way, but they were very worried, and wanted me to take a look, as everything had to be up for the Boxing Day sales - this was my time not in a manufacturing world, but in a retail world - the pressure was real, the target was live.

On the offer of a very nice cash sum, I jumped in my 206 and drove down to the offices, waved through security I signed in, and took a look around my old stomping ground, things had changed since I was last there, the partitioning wall to the server room had been removed, where the analysts sat was now occupied by a modern style series of server rack positions, they were in the process of moving everything to a set of Dell Power Edge 2U servers, with A/C, a hot isle and a cold, some decent kit.

Turning around there was the great big AS400, jet black, with a rectangular base rounded at one end.  And the machine perched on this raised platform.

This was the machine which would not booting... The problem?

Well, that paritioning wall, which had been removed... "How did you remove this wall?"

"Oh" he said "we had them put plastic sheets double lined from the ceiling to floor, took down the stud walling, and clean up, we never had to turn the AS400 off"

"Fabulous" I noted his pride "so the silver racks which were here, the shelving with parts and the little PC sat about here"  I intimated the corner just below waist height.

"All that was removed, with the wall, just old junk parts and pieces"

"Okay" I look around "So where did you remove it all to?"

"A skip" he shrugged "About three months ago"

"Aha" I nodded "I know your problem, the AS400 is coming up into advisory mode and awaiting the start signals from the script host, I'm going to guess you don't run AS400 elsewhere, you're winding down to the new servers?"

"Yeah" he was quite flustered "I know nothing about this hunk of junk, I just need it to work"

"Then you need to find a PC running OS/2 before morning, and restore from one of the back-ups I used to take onto tape, if you can"

He went whiter than my best linen on wash day... "OS2 PC?  Why?"

"Because the machine which sat here, was the boot master for the main shell into the Analysts layer, it sat here" indicating the wall again "whoever unplugged and threw it in a skip should really have looked a the holistic picture, it was a very important little machine, which is why we had two of them and spare parts on those shelves, and why it also got backed up to tape when it was installed or updates performed on it"

Silence filled the gap.

"I'll take that cash and get back to my Christmas pudding".

Thursday, 30 November 2017

C++ : Trust the STL

One sore lesson to teach some developers is when to trust the compiler, once you've gotten that across you have to start teaching folks to stop re-inventing the wheel.

If someone has already implemented a file handler, or a serial port abstraction, or a wrapper for some obscure feature, you need to evaluate that offering...

To evaluate whether a library is worth using, firstly see if it works, then see how many folks actually use it, the more that use it then the more likely bugs will be flushed out and the whole thing has been tested.

Leveraging this kind of mature code within your projects assists in bootstrapping the startup phase of new projects.

Boost is a note worthy example of what I'm talking about here, many software shops (at least the ones I know) resist using open-source or third party libraries, they prefer to stick to in-house developed niche implementations until the very last moment, this of course slows development and completely symies innovation.

Boost however is one step further than the problem I'm going to tackle today... The Standard Template Library...

The STL is often commented upon negatively, this is despite it being a hugely available resource, vastly and deeply tested throughout and constantly incorporating new innovations.  Whole books have been written on the topic, and yet one can still find projects and individuals resisting using the STL.

STL nay-sayers will quote "no need for an STL requirement", "uses less memory than an STL implementation" or "faster than the STL"...

The problem with this attitude is, are such attitudes going to sufficiently tackle testing of their bespoke solution, is that bespoke solution going to be as robust or as easily maintained as something using the STL?

Probably not, and this is a hard one for die hard "purist" developers to swallow, we want to write all our own code, we want to be gods in our domain, the trouble is for the vast number of us, god has already been there and he wrote a decent enough library to do the task we need doing... So leverage this!

I came across one such niche item the other day, with an algorithm to see if a string starts with...

They hadn't used boost, or the STL, to do the searching, yet perversely had used an std::string... Their code, looked a little like this:

const bool StartsWith(
const std::string& p_Text,
const std::string& p_Pattern)
bool l_result(true);

if ( p_Text.length() >= p_Pattern.length() )
for (unsigned int i(0);
i < p_Pattern.length();
if ( p_Text[i] != p_Pattern[i] )
l_result = false;
l_result = false;

return l_result;

It is fairly logical code, they're looking at the length of the presented parameters, to avoid looping when not required, then they only loop from the start and only return a fail when the character is a miss-match, looking at this with programming eyes from 1996, I'd say this is fine.

Looking with eyes well aware of the STL, I cringe a little, and replaced this whole function like this...

const bool StartsWith(
const std::string& p_Text,
const std::string& p_Pattern)
return (p_Text.find(p_Pattern) == 0);

One line, of very much more maintainable, vastly more readable and easy to comprehend code...

The developer of the original however was not happy... "you're wasting resources, this will find any instance and tell you the input".... he's right it will, but the STL will still be faster than his code.

I demonstrated this by plugging both into CompilerExplorer... He still refused to listen.

Therefore, I've written this little helper project, to run the two functions side by side, threaded three tests, looking for the match, a long match and a negative match at the start of the string (Code on Github).

The results of this are interesting, you see the project itself favours cases where it's highly likely the string being searched for is present and therefore we don't need to worry too much about the odd test not finding a match taking longer... This is exactly the behaviour seen in the STL based find example.

The Short search time, for the same data, on the same processor went from 28358 microseconds to just 5234... That's about 81% faster.  The longer search is more stark, falling from 185966 microseconds to just 6884, just over 96% faster!

The rub is the negative case took longer, rising from 19765 in the hand-crafted search to 25695, just over 30% slower.  Some of this increase can be explained perhaps by the hand-crafted version using the lengths to quickly skip too short an input, otherwise it is simply that the STL find has to iterate over the whole string when no match is found.  A hybrid to not perform the find at all, when there is insufficient data maybe in order; however this may add to our maintenance burden and lower code clarity, swings and roundabouts.

However, clearly in the case of this project, dismissing the STL resulted in slower code, we have a system propensity for matches, they're quite short, and all target platforms have the STL built in, use it.

Never be affraid to ask questions of what you're working with, ever.

Tuesday, 28 November 2017

CMake rather than Mammoth makefile marathons

I'm having difficulty communicating with some folks about the beauty of cmake and using ccmake to leverage that beauty.

These are folks whom are either completely ignorant of what a makefile should look like, are happy to manage their own or at worst case are folks put off of makefiles by having inherited projects which have spiralled out of control with mammoth makefiles and a propensity to being so complex as to prevent any cost-effective entry grade for new developers to key into - i.e. they're too hard to learn, or obfuscated sufficiently to allow established developers to retain their positions of glory and power.

I don't subscribe to that ethos however, and believe that as a leader in development you should facilitate everyone to be being able to do everyone else's development role, be that starting a new project or continuing an old.

It perhaps comes from my being able to work alone and defining a role which others are then keyed into, I have been forced to allow entry to my work, to make the cost of someone else bootstrapping my work into their wetware (brain) as simple as possible.

Mammoth makefile marathons are not the way for me to do that, a CMakeLists.txt file, now that's a better proposition.  However, even here you have to take care, some folks are ignorant of the tools available, to leverage cmake in this way one might use this kind of command line...

This is daunting for a newbie, and even an experienced developer has to admit...


This is a much more succinct and easy to access way of getting into your CMake way of working, the cost of entry being so low as to actually make introducing new developers to Linux development, or just general CMake usage, trivial.

So where am I failing to communicate this?

Well, cmake, ccmake... The naming conventions of both are so close as to confuse people, they don't hear the second C in CCmake, or they think I'm talking about the C Programming language.  This is a lack of understanding on their part, people being people however, they don't want to admit they've no idea what you're talking about.

(As an aside, folks, if you want to be a good developer, a good person, please admit when you don't know something, it causes so much less issues in at development scrum time if you are handed work, and you simply state "I know nothing about that".  Someone else can be assigned the role, or better still, you can get training and schedule the work more effectively!)

My solution to this difficulty therefore?

Rename the programs, I've created two symbolic links in /usr/bin....

sudo ln -s /usr/local/cmake/bin/ccmake /usr/bin/makefile_prep_gui
sudo ln -s /usr/local/cmake/bin/cmake /usr/bin/makefile_prep_cmd

I've essentially bamboozled the communication factor by giving cmake the working name "makefile_prep", this means that those opposed to ceasing direct use of makefiles still feel empowered, but are subtly diverted to using an automated tool.

Immediately questions and opposite to changing the status quo has ceased, and folks are talking about using the new "makefile_prep" tools.... How clean they are, how nice the builds look, how they integrate with CLion easily, and "the output from my makefile_prep looks exactly like the build going on inside the IDE (CLion)"... Little do they realise they're both cmake!

Oiling the cogs of resistance to change, this is where I'm living at present... Its not an easy task, but sometimes it's rewarding.... Now to do the same in the day-office.

Friday, 17 November 2017

Waking Up With My Dog

Someone was cold, this is where they perched...

Ain't he the cutest....

Wednesday, 15 November 2017

Time Expectations in WoW Classic?

With the news today of EA reducing by 75% the time it will take in Star Wars Battlefront 2 to unlock a hero character, can we expect to see modern gamers head into WoW Classic and start complaining?

(c)2017 Electonic Arts

Lets just recap though, World of Warcraft, vanilla, people played a character to level 60 in about 4 days played, that's about 96 hours played.

EA's plight, and collapse into pandering, happened with a played time of around 40, that's less than half... Reducing it by 75% that now makes a hero in SW:BF2 in 10 hours.

10 hours for Vanilla WoW was not enough, and this is where my first concerns with WoW Classic come about, firstly, will Blizzard be forced to pander down to newer gamers whom most certainly want action & reaction, risk and reward.  They certainly don't deal in patience nor RNG.

My second concern comes that this is a big issue, and perhaps Blizzard will side step it, by simple nerfing the amount of time to level, or perhaps increasing the rate of XP gain, as arguably since Burning Crusade or Wrath of the Litch King, the business model for WOW has been to push players to level cap as fast as possible and explore repetitive tasks in that area.

The way of thinking Blizzard have entertained (no pun intended) since I stopped playing was daily's, and find a group, find a raid, tokens, faster reward for input, but with exponential damage, health and other stats making that power-wonder factor... Fast rewards, I said during my appearance on "Shut Up We're Talking" that this was where things would be going.

Rinse and repeat.  That is all I've seen delivered, it's certainly all I've heard explained.  Should I name drop "Garrisons"?

All this said however, we must remember, that there will be a huge influx of tourists to WoW Classic, toe dabblers, so what could the population of regulars; the hardcore; who settle there expect?  These are the things we don't know and as you can tell by this post, we can only speculate about.

Monday, 13 November 2017

Virgin media - Poor Speed Proof in Statistics

From my prior post, I have now appended the first ResultSet1.csv file - used to generate the chart in my previous post....

However, since than I have been doing some processing, and between 20:00 and 21:59 there are 191 entries in my little chart.  Remember this is what virgin refer to as "Peak time", and they state an average of 50mbits in 24 hours.  I'll be fair here, they never state what the actual speed they throttle down to or limit one as, but the chart here clearly shows 50mbits...

So, what average did I receive for 24 hours?

22.124 mbits/sec

Less than half the speed promised.

My speed during the peak time slot?  Averaged out as?

6.310 mbits/sec

Utterly pathetic...

You can download the results csv yourself, plug this into a spreadsheet and enjoy the proof positive of this dreadful situation.

To make matters that little bit worse, I have tried to call Virgin, and spent tens of minutes of my break and lunch in the queue to speak to someone, and their live chat simply performs this horrid loop:

Clearly the average upload speed of my test matches their predictions, its not particularly impressive, but is the speed as advertised.

Since I am having issues talking to Virgin, their Twitter minions keep passing me from pillar to post, asking the same dead-end and above all unrelated questions, and their actual customer services team are harder to talk to than they should be.... I think I'll be forwarding this one now to the communications ombudsman.