Sunday, 12 May 2019

Development Job : Interview Questions?

I was asked a question a few hours ago, "how would you kill a named process"... This annoyed me on two levels, firstly, as I was put on the spot, but secondly I had already blogged about this exact problem just a few weeks ago...

The quiz master knew this, or rather they should have, given all the information they had about me, including this blog... So to ask tells me more about them, than my answering would tell them about me.

It tells me that they're working to a bare minimum investigative level, they're looking perhaps too much to their goal (which it to get answers they like) rather than checking anything produced before.

This would be a little like asking Sir John Geilgud, whilst interviewing for a country play.... "Have you done any acting?"

It frustrates me.

Sunday, 21 April 2019

C++: When to Cast Away Const

There's a rule, a very good rule, a brilliant rule, almost a law to not cast away const in C++.  There are legitimate reasons for this, and greater minds than myself have invented and enforced said coding standard.

Unfortunately, this doesn't mean there are not cases where you can use this technique, lets take a look.

So, modern C++ casts should always be used.  These are static_cast, reinterpret_cast, the dreaded dynamic_cast and as we're going to look at const_cast.  Where would I use this?  Well, in concert with good parameter conventions, we always want to communicate to the outside world what we'll use a parameter for...

class Foo
{
private:
    int* memory;


public:
    Foo(int* ourMemory)
        :
        memory(ourMemory)
    {
    }

};

We're assigning our memory to the class, but this constructor is communicating something back to the caller, it intimates that the pointer could perhaps, maybe, be changed as we pass it without the constant prefix.  A caller could then assume they must check whether the pointer has changed, become nullptr or whatever else.  That's assuming our API users are good people, which we all knows they are!

But, we don't change the pointer, we just take it into our member variable pointer.

We therefore have a dichotomy, the class may change the pointer along the way, but the actual constructor does not, this is a design decision, so assuming we communicate this back, I just want to make it clear the constructor does not change the pointer.

class Foo
{
private:
    int* memory;


public:
    Foo(const int* ourMemory)
        :
        memory(ourMemory)
    {
    }

};

Unfortunately you now get a compile error that "int*" can't be cast to "const int*".  So we need to cast-away the const in our constructor, like this:

class Foo
{
private:
    int* memory;


public:
    Foo(const int* ourMemory)
        :
        memory(const_cast<int*>(ourMemory))
    {
    }

};

This is, pretty much, the only use case I can find in my own coding standards for casting away const.

Monday, 25 March 2019

C++ Variadic Template Compiler Optimizations

In my prior post we briefly talked about how the compiler unrolls a variadic template and we needed to provide the end-point function to stop that iteration, lets take a closer look at how the compiler does this unrolling.

The impact this has on your debug build is critical, and I demonstrate that you can see the unrolling of numeric functions (such as summation) but then in release the compiler is smart enough to optimize that all away and use a constant.  Understanding when this is happening is a crucial lesson, as we then see the action of a repetitive string output.


If you found these two little videos of any use, please life & subscribe on YouTube to let me know!

And as always the comments below are available.

Sunday, 24 March 2019

C++ Variadic Template Parameter Packing Example

Today in the brief few mintues I hate, I wanted to welcome all the new readers the blog is getting, there are nearly 5000 of you folks passing through these pages each month!


And now the code video....

Today we go over a usage example for variadic templates, demonstrating the new C++17 parameter packing, how to call functions with the parameter pack, how to mix parameter types with the template and control the compilers iterative unrolling of your code.

Find the source code here:

Find Fedor Pikus's new book here:


Please Note: Filmed in one take, during the single half-hour I have spare, so don't complain about the low production values, cus the code does at least work!

Friday, 22 March 2019

P4

I don't like P4


Its not the best blog post after a fortnights silence, but it's all I have to say really.

Thursday, 7 March 2019

Mistakes Were Made

I had a lovely post for this evening, until a coworker pointed out it was utterly wrong... DOH.

Tuesday, 5 March 2019

C++ Factory Create Shared Pointer - Private Constructors

Back in 2016, I posted this little ditty about hiding the constructors but still enabling the use of "make_shared", this worked through a friendship between your class and the ref counter, but was sadly windows only.


At the time I promised the follow up for the same code for GNU, well I forgot, so here's the secret sauce, make your class as per that post, but friend it thus:

friend class __gnu_cxx::new_allocator<Foo>;

This only came up as I showed a colleague today and realized, I never got around to posting the other item!

Sunday, 3 March 2019

Home Network Upgrade - Part 1

This is going to have to be a multi-part series, firstly as it's a complex task we've got on, but also time constraints from both my side and also from suppliers delivering me kit means it's already spread itself over three weeks... and I can only imagine it's going to take a lot longer yet.

What am I up to?  Well, we're all settled in the new house and it's time to sort out the networking... Now I only have wireless at the moment, you may have seen my prior posts about the lost router?  Well, I found it... And I was wrong, it wasn't lost at the in-laws, it was lost here.... After searching the garage again, with the wife for that fourth time she finally believed me that it was lost (not just that I was being a stupid man) and she helped look elsewhere... We still didn't find it, however the next day at work my phone rang and on the other end was a joyous voice "I found it, the router, I found it"...

Yes, it was in a box in the garden!

Not open to the elements, but not fabulous either, anyway, router found I stuck it in place.  The problem now, I had two wireless networks the router provided one and the BT Homehub one... Easy, turn the BT Wifi off.... Which I did.

Except, that doesn't turn off the BT Wifi with Fon thing, the free access point for any BT customer to use.  And, I saw folks using my Wifi*

So, I hit the old interwebs and looked up a decent ADSL/VDSL modem replacement, the one which came up, from a video by Cameron Grey actually.  I ordered a Netgear DM200.


It looks quite nice, this is just an ADSL jack in and RJ45 jack out, it is NOT a wifi router.  But, this is an utter and total pig to set up folks, really a total and utter pain in the bum.... I tried three weekends in a row in six different sessions each of over an hour before it finally sorted itself out.

For those interested, flash the firmware to v1.61.  Give it power but no network connections plugged in and hold the factory reset button on the back for 30 seconds, then kill the power to it... Plug in the ADSL feed and connect it with a single ethernet cable directly to your laptop or PC.... Give it power and wait... and wait... and wait... until all three lights go green... If they don't after like fifteen minutes (seriously wait that long), only then remove the connections, but leave the power on factory reset again and power off, connect and power on etc until you get three green lights.

Then on your PC browser open to "http://routerlogin.net" and get in there, and just run the Genie wizard, if ANY thing else comes up, factory reset!  Let it detect BT, enter the username as bthomehub@btbroadband.com no password, nothing else and wait literally tens of minutes, it will get somewhere.  And when it's asking you to register on the netgear site pacify it with the "next" button until it is totally and utterly and completely done.  Only then open another tab and try a website.

When I finally got a website I then removed this hunk of trash.

Finally, no BT Wifi with FON sucking on my juices.  I set the DM200 into modem only mode, wired it to my Router and set up PPPoE with the username and password for BT again... Anyone wondering bthomehub@btbroadband.com and BT, with VLAN set to 101.

And voila, I was back to where I was with my virgin router at the old address, I now have my nice router working nicely with a nice modem on this BT line... And it's about 5mbps quicker on my speed tests, the DNS resolutions (set to Google and CloudFire are around 30ms quicker too).  And I have more control over everything, I am so much happier.

But I'm not altogether happy, because the next phase of my work has been massively massively delayed, by like a year... Like this was planned for the old house... Fiber Optic.

Yeah, remember this box?



Hang on, lets be clear... THIS BOX...


Yes, they are fiber optic network cards... You might ask "Xel why have you so many?"... And I would have to blush and admit, I thought I was buying two as a test, instead I bought TWO JOB LOTS OF 10 CARDS!  So  have this huge box full of 20 fiber optic network cards.

The plan therefore is to put together a small form factor PC by the router and fit a fiber connection to it.   Carry that fiber line up into the loft and up there have a fiber optic router.  That's the ultimate aim.  But I want to do that test first, machine to machine... So, I fitted a card to my workstation and another to my my Xeon home server... All fine, drivers and everything fine, and I set about ordering a pair of short 2 meter cables...

And I wait...

And wait....

And a month later finally....

Oh yeah baby... Except, hang on...


I ordered a pair of cables didn't I... Didn't I... Yes, yes I did... How many are in that baggy?... Just one... OH NO JUST ONE!!!?!?!??!?!!  So, this is where I leave this project for now, it's been a long time coming, but I hope to get the optics test done, then we've got two runs of ether cat 5 or fiber to run from the router feed in down stairs to the loft and then to my office and to the garage.

As owning a garage, this is where I now plan to have the server rack, and running fiber to it may be my optimal solution, it may even be possible to get cat 5 into the garage easier than to the loft, so all the fiber might go in the garage, this is literally a plan in the process of being figured out as I find out the structure and layout of the house.

Stick around for more.



* I actually spoke to a neighbour about this, he said "Oh that'll be my lad, he connects to the as many BT Wifi connections for free, we don't pay for the internet that way".... Nice, thanks... 

Saturday, 23 February 2019

Its all a question of metier

I've had one of those moments, taking the wife to a new hair dressers, I had to sit and after giving up the pile of decidedly feminine magazines as a bad job I used my phone to crib up on a problem I'm having setting Code Collaborator up properly.

The problem aside, it's just one of those things, I needed to read the info.

About fifteen minutes into my reading and with many female voices cackling merrily away their 11 o'clock comes in with her husband in tow.  He takes the seat with me and we do the usual nod of the head and tut at the flapping the girls are all doing cooing and fawning over one another.  It really is all a bit beyond me, some form of communication is taking place, but I'm not certain what kind.

Alas, five minutes after our perfunctory nod and his going through the self same magazines he strikes up a conversation "you reading something good?"

I reply, good naturedly and we're washed over with a wave of cackling.

"Computers eh?" he says it like it's some mystery force in the universe, "our lads into them, doing his A-Levels".

I listen again, "Yeah he wants to go into using them, looking at his degree options and he got into Nottingham".

So, I do the dutiful thing, I ask what degree... I'm expecting computing, programming, systems or something...mathematical maybe physics at an outside edge.

"He's going to do English Literature"

I don't really think about it, I just ask what's the link to computers then?

"Wants to work with them".

And I can't help it, but we're in this rabbit hole and I ask "How does he jump from English Literature to working with computers?"

The guy fumbles a little here, I think this maybe the first moment he's thought about the tenuousness of the connection from A-Levels in Sociology, English Lit and Physical Education, a degree in English Literature and the wish to work in Computers.  But he gathers himself in a flash.

"He uses a right good laptop for his home work".

Game over, good night vienna, sensible has left the building.

Our conversation peters out some at this moment and I just leave him to this thoughts as my wife's done, but I can't help think about the metier here.  Computing is a goal, or the lad enjoys playing games, but he's studying completely unrelated topics, with no seeming extra curricular things, and he'll no doubt be out trying to get any computer related job, I don't know what, maybe sweeping out server rooms.  But he'll be cheaper than a qualified person in a computer academic bent.


Thursday, 21 February 2019

RAF Tornado Retires

I'm quite sad to see the retirement of an icon of my age, born in 1978 I saw the Tornado come into service and has a lad had a cool postcard poster of one coming into land, it was such a modern thing and to my eyes still is, the forward angle on the air intakes, the vaunted carrying capacity and the potential for this pan European jet to enter service and serve us well.

Which she has, the Tornado has been a mainstay for the RAF, its replacement isn't even clear cut, as the aircraft was so versatile, we see the Eurofighter Typhoon taking on the air-superiority and potentially some of the light strike capabilities, we see the F35 coming over from the US to augment the fighter force, but they're machines at the moment, they're things.  The Tornado for me, she has a certain personality.


Friday, 15 February 2019

Coding Standards - About Scopes (again)

Consistency is good, consistency is light, consistency is really what you need think about when creating code, no matter what format, language, platform or project you're on do things the same way, and even on your first pass do them your way consistently before you apply any locally demanded view of the code....

What do I mean by view?  Well, I'm talking about coding standards, but the non-functional side of things, hence the view.  You can look at code from any angle you choose, indeed there are multiple ways to achieve the same solution within code, the difficulty is to get things out there, put them down, then sort the wheat from the chaff.

I've done this in a couple of videos, where I move pieces of code from their own coding layout to my own, I have labelled these "coding standards", but in retrospect they've just the coding view.

One of my big points is the notation for the scope of variables, I love to use scoped notation.  Having been brought into programming when Hungarian notation was not only taught to you academically as required, but demanded by all projects you worked on (basically as you had no code completion tools, so knowing the type of a named variable whenever you utilised it was really very useful) but that was twenty plus years ago, now we have code completion I strongly feel your tools should be made to work for you.

Therefore, when I complete a call or variable name, I want that to communicate something to me, and the most useful is to check the scope, the code completion tells me the type and the name, but scoping isn't really fully covered in the tooling (please post below any suggestions for Visual Studio, Atom, CodeBlocks or Visual Studio Code which perform scope notation or checking on the fly).

When I complete my typing and pause I want to see all the m_ members together, all the c_ constants all the s_ statics and so many coding standards documents define these three.  However, it's just not far enough, what happens when you have locals named 'angle', 'view' and 'Gregorian'?  They're at very different points within the code completion window which pops up, you have to remove your hands from the keyboard to begin scrolling through them; or worse still start typing letters in order to guess the name (for instance we may start to type a c to see if 'Gregorian' comes up actually as 'calendar').

My solution?  The solution I've been pushing time after time, post after post, video after video?  Scope more things.

We can add "local" as "l_", parameters as "p_", we can compound them, so a static constant maybe "sc_" and we can tailor this in whichever manner we feel fits best, but be consistent.

Let me be utterly clear, this is not Hungarian notation of old, we are not adding "i" to integers or "l" to longs, we are not defining the type within the name, we are simply defining the scope and helping the tools to help us by grouping the various scopes of variables together.

I find it incredibly hard to read documents which go half way, defining members as "m_" (or just a leading m) is extremely common, ditto for constants and even statics, it's only with parameters people get a little squeamish.  "p_" is sometimes reserved for pointer, but that's a style edging back to Hungarian you're notifying the reader of the type and use rather than the scope, therefore I push "p_" as a parameter.  But I can also see arguments for "i_" and "o_" for parameters, which tell you it's an input or output to the function.  If one wanted to be a pedant you could go so far as to stress this with "pi_" and "pi_".

This isn't to say I'm for everything, for example in returning from a function:

int foo();

I will not define an "r_" as the return scope, I'm not interested in the semantics to that extent, and I don't feel code like this:

int foo()
{
int r_result(0);

... Some code to set r_result

return r_result;
}

Is communicating anything useful, so often in my code you will find:

int foo()
{
int l_result(0);

... Some code to set l_result

return l_result;
}

As the result remains a local until returned.

Which brings me back to my second bug bear of the month, one which I've already blogged about returning early.  I'll let you remind yourselves of my opinions.




And just a note to the world at large, if you're coding "m_" for members, but ALSO add Hungarian notations "m_iInteger" stop, stop it now... and yes that includes when you're doing pointers "int* m_pIntegerList"... argh, I want to pull my own arm off just to have something to throw at the screen when I see this one, it's a hybrid as annoying as the Alien in Alien Resurrection.


What's my solution?... Well the completely sane idea I use is "m_IntegerListPtr"... Yes, it's a pointer... I tell myself it's one, I'm not strange at all... Alright, maybe a little.


Sunday, 10 February 2019

The Lost Router

Its gone... Just gone.. Puft... Up and gone... I remember it in the box, I remember packing it... Puft, gone, where is it?... Have you seen it?....

LOST


LinkSys WRT AC1900

Responds with the SSID "XelNet"

Likes to sit on the side serving internet pages to the house and the occasional belly rub....


It's just lost.. I've come this weekend to sort out my network situation, so I've finally gotten an afer market ADSL modem to replace the BT Home Hub, I've got a powerline network adapter to carry network upstairs to the wired office (rather than running wires through ceilings just yet).

I've gotten the hub for the garage and the hub for the office sorted... And all the smaller ethernet cables all crimped to perfect length to stop wires trailing all over under my desk and behind the TV.

But, then I go to find my router and it's just missing... I remember boxing it back in it's own box on moving day, I remember doing that.... I remember it distinctly.

I think it went into my car, not the wifes... My car is now clearly empty, I emptied it... So I've been through EVERY box in the garage three times, been through the loft twice, I've been through every nook and cranny I can find...

My thoughts are that maybe, perhaps, it's at the in-laws house, I've asked them to look and they just said "no"... But I think it's there by their PC and they don't realize the box which looks like theirs is mine.

So frustrating!


--------

Update, the wife came with to go through EVERY box in the garage with me... Guess what... No, no... She didn't come up smug (I knew you'd think she would)... The thing is still LOST... GONE LOST VANEEEEEEEESHED.... Gah.

I think I have to go look at the in-laws.

Thursday, 31 January 2019

C++ Coding Standards: Don't Return Early

I've just had one of those mini-conversations which has be scratching my head, I asked a coworker about "return early" being part of the coding standard or not, as it was being discussed by other parties.

His response was an emphatic, slightly arrogant and touchily obtuse, "I have no time for anyone arguing for not returning early from a function you've discovered you should not be in".

I however don't take such a black and white view, I see the pro's and con's of both approaches, importantly not returning from a function can, and is part of, driving process flow conversations and it aids in picking out structure which can be encapsulated away.  The result being that instead of instantly exiting and potentially leaving spaghetti code you can see a flow, see where branching is occurring and deal with it...

But, that said, it must be understood "returning early" is often seen as "faster", as the chap argued "I see no point being in a function you know you should already have left", so I took to compiler explorer... In a very trivial example:

 

Here we see a decision being made and either a return or the active code, easy to read, simple, trivial... But don't dismiss it too early, is it the neatest code?

Well, we could go for less lines of code which generates near identical assembly thus:


This is certainly less lines of C++ however, inverting the test is a little messy and could easily be overlooked in our code or in review, better might therefore be expanding the test to a true opposite:


One could argue the code is a little neater to read without the inverting, critically though it has made no difference to the assembly output, it's identical.

And it is identical in all three cases.

You could argue therefore that "returning early has no bearing on the functionality of the code", but that's too simplistic, because "not returning early" also has no bearing on the functionality of the code.  The test and action and operation has been worked out by the magic of the compiler for us to be the same.

So with equivalent operation and generation we need think about what returning from the function early did affect, well it made the code on the left longer, yes this is an affectation of our coding with braces, but it was longer.  You could also see that there were two things to read and take in, the test was separate to the code and importantly for me the test and the actual functional code were on the same indentation horizontal alignment.  Being on that same alignment makes your eye not think a decision has been made.

Putting the test and the action of that test into the inner bracing communicates clearly that a decision has been made and our code has branched.

And when that structure is apparent you can think about what not returning early has done, well it's literally braced around the stanza of code to run after the decision, that packet of code could be spun off into it's own function do you start to think about encapsulation.  Of course you can think about the same thing after the return, but in my opinion having the content of the braces to work within is of benefit and most certainly does not afford any speed benefits.

Lets look at a more convoluted, but no less trivial example, a function to load a file in its entirety and return it as a known sized buffer... we'll start with a few common types:

#include <memory>
#include <cstdint>
#include <string>
#include <cstdio>
#include <optional>
#include <sys/stat.h>
#include <sys/types.h>
using byte = unsigned char;
using DataBlock = std::shared_ptr<byte>;
using Buffer = std::pair<uint32_t, DataBlock>;
using LoadResult = std::optional<Buffer>;

And we'll assume there's a function to get the file size, with stat...

const uint32_t GetFileSize(const std::string& p_Path)
{
    uint32_t l_result(0);

    struct stat l_FileStat;
    if ( stat(p_Path.c_str(), &l_FileStat) == 0)
    {
        l_result = l_FileStat.st_size;
    }

    return l_result;
}

Now, this file is return path safe because I define the result as zero and always get to that return, I could have written it thus:

const uint32_t GetFileSizeOther(const std::string& p_Path)
{    
    struct stat l_FileStat;
    if ( stat(p_Path.c_str(), &l_FileStat) != 0)
    {
        return 0;
    }

    return l_FileStat.st_size;
}

But I don't see the benefit, both returns generate an lvalue which is returned, except in the latter you have two code points to define the value, if anything I would argue you loose the ability to debug "l_result" from the first version, you can debug it before, during and after operating upon it... Where as the latter, you don't know the return value until the return, which results in the allocate and return.  And again in both cases the assembly produced is identical.

So, the load function, how could it be written with returning as soon as you see a problem?... Well, how about this?

LoadResult LoadFileReturning(const std::string& p_Path)
{
    LoadResult l_result;

    if ( p_Path.empty() )
    {
        return l_result;
    }
     
    auto l_FileSize(GetFileSize(p_Path));
    if ( l_FileSize == 0 )
    {                     
        return l_result;
    }

    FILE* l_file (fopen(p_Path.c_str(), "r+"));
    if ( !l_file )
    {
        return l_result;
    }

    Buffer l_temp { l_FileSize, std::make_shared<byte>(l_FileSize) };
    if ( !l_temp.second )
    {
        fclose(l_file);
        return l_result;
    }

    auto l_ReadBytes(
        fread(
            l_temp.second.get(),
            1,
            l_FileSize,
            l_file));

    if ( l_ReadBytes != l_FileSize )
    {
        fclose(l_file);
        return l_result;
    }

    l_result.emplace(l_temp);

    fclose(l_file); 

    return l_result;
}

We have six, count them (orange highlights) different places where we return the result, as we test the parameters, check the file size and then open and read the file all before we get to the meat of the function which is to setup the return content after a successful read.  We have three points where we must remember and maintain to close the file upon a problem (red highlights).  This duplication of effort and dispersal of what could be critical operations (like remembering to close a file) throughout your code flow is a problem down the line.

I very much know I've forgotten and missed things like this, reducing the possible points of failure for your code is important and my personal preference to not return from a function early is one such methodology.

Besides the duplicated points of failure I also found the code to not be communicating well, its 44 lines of code, better communication comes from code thus:

LoadResult LoadFile(const std::string& p_Path)
{
    LoadResult l_result;

    if ( !p_Path.empty() )
    {
        auto l_FileSize(GetFileSize(p_Path));
        if ( l_FileSize > 0 )
        {                        
            FILE* l_file (fopen(p_Path.c_str(), "r+"));
            if ( l_file )
            {
                Buffer l_temp { l_FileSize, std::make_shared<byte>(l_FileSize) };
                if ( l_temp.second )
                {
                    auto l_ReadBytes(
                        fread(
                            l_temp.second.get(),
                            1,
                            l_FileSize,
                            l_file));

                    if ( l_ReadBytes == l_FileSize )
                    {
                        l_result.emplace(l_temp);
                    }
                }                

                fclose(l_file);
            }
        }
    }

    return l_result;
}

This time we have 33 lines of code, we can see the stanzas of code indenting into the functionality, at each point we have the same decisions taking us back out to always return.  When we've had a successful open of the file we have one (for all following decisions) place where it's closed and ultimately we can identify the success conditions easily.

I've heard this described as forward positive code, you look for success and always cope with failure, whilst the former is only coping with failure as it appears.

I prefer the latter, ultimately it comes down to a personal choice, some folks argue indenting like this is bad, I've yet to hear why if the compiled object code is the same, you are communicating so much more fluently and have less points of possible human error in the code to deal with and maintain.

From the latter we could pick out reused code and we can target logging or performance metrics more directly on specific stanzas within their local scopes.  Instead of everything being against the left hand indent line.

Now, I will happily tell you it hasn't been a comfortable ride to my thoughts on this topic, I started programming on a tiny screen (40x20 characters - Atari ST Low Res GEM and when I moved to DOS having 80 character widths I felt spoiled.  Now we have tracts of huge screen space, arguing you need to stay on the left is moot, you don't, use your screen, make your code communicate its meaning, use the indents.

And yes, before you ask, I was doing things this way long before I started to use Python.

Sunday, 20 January 2019

C++: Undefined behaviour from realloc and the Clang Optimizer

I was wondering around in some system code and found a strange behaviour between two modes in a piece of code, where the code switches from double to triple buffer mode there's a problem, we've already got two buffers of everything we just want to allocate another but the underlying structure for sets of buffers wants to own them all... So the code went from:

SetOfBuffers
{
Buffer* one;
Buffer* two;
}

To:

SetOfBuffers
{
Buffer* one;
Buffer* two;
Buffer* three;
}

Creating the third buffer is fine:

SetOfBuffers::three = malloc(X);

But, the first two is a re-alloc, to reuse the existing buffer:

SetOfBuffers::One = realloc(OldSet::one, X);
SetOfBuffers::Two = realloc(OldSet::two, X);

The problem?  I'd start to modify the values in the new set of buffers, the third buffer being used and present.  Then the first buffer would be changed present... The second buffer changed present and the information is wrong (I over simplify massively here).

Anyway, I was remotely SSH'd into my server for this, so I went to Visual Studio, same code... Worked fine... So I go into my local VM and it's fine too, so I went back to the server and compiled manually and suddenly it's fine too.... WTF.

I literally spent an hour looking at this, the problem?  Well, it appears to be a bug in Clang, the reason the problem disappeared was my Makefile contains a $CC constant for the compiler to use and it was "clang" when I built by hand I used "g++".  Worse still, if I switched to a clang debug build the code worked fine, so this was something about my compilation process not a bug in the code per se.

So, perplexed I went in search of an answer.  And it appeared to be something about the clang optimizer, about which I found this talk from CppCon 2016.

Where there's this example:

#include <cstdlib>
#include <cstdio>
int main ()
{
int* p = (int*)malloc(4); // The original buffer above
int* q = (int*)realloc(p, 4); // The new pointer to the same old buffer
// Allocate a vlaue
*p = 1;
*p = 2;
if ( p == q )
{
printf("%d %d\n", *p, *q);
}
}

What do you expect this code to display?... Well, I expect it to print "2 2".  And it does on VC and G++ and even clang without the optimizer...





But you optimize the compile and its wrong:


Now, this is undefined behaviour and not caused by your code, it's the optimizer and very scary.  Not least as this was identified a while back (the talk along is from 2016) and g++ has solved the problem... Eeeek.