Monday, 17 June 2019

C++ : "ignored-qualifiers" warnings are a bit wrong

It has been a while hasn't it... I'm very busy, sorry.... But here's an item, the const qualifier on return types in C++... So, I'm of the same mind as Scott Meyers that you should const everything you can whenever possible, and one place I always const is on return codes from functions where I don't want the result to be mutable, like this:

const bool OverTen(const int& p_Value)
{
return p_Value > 10;
}

I don't want the caller to this function to modify the result, that bool they get back, I want it to be constant, I want them to use that bool for that one purpose.

This compiled fine, until you compile with -Wextra, where you then get -Wignored-qualifies and the message:

warning: 'const' type qualifier on return rype has no effect

But I want it to have an effect, I want that to be immutable, it's a constant boolean.  It could be anything, a constant error code value, I don't want someone to fudge over an error by setting it to some other value!  I want it to be constant.

It not being constant allows crusty code like this:

auto test = OverTen(2);

if ( NefariousProgrammersBirthday() )
{
test = true;
}

if ( test )
{
PayoutCash();
}
else
{
ResetMachine();
}

I'm sure you can see where this is going.

but, but but, you're going to argue that I'm assigning to auto, I'm not using "const auto".  Well that's my point, I want the warning to tell the programmer that they're assigning my const return type to a non-const auto, that they should be using "const auto" and hence close this loop hole.

Instead the compiler warns you that your API, the return being const, has no effect.  It should have an effect, the return is constant and it should be hard to get rid of that constness.

For instance if one had to const_cast like so:

auto test = OverTen(2);
if ( NefariousProgrammersBirthday() )
{
test = const_cast<bool>(test);
test = true;
}

Well, that jumps out at you, as would

auto test = const_cast<bool>(OverTen(2));

or even

auto test = (bool)OverTen(2);

So, I would suggest that if a return type has const the auto becomes "const auto" immediately, attempts to change this are easy to spot.

And -Wignored-qualifiers should NOT report a warning on a const qualification of a return, because it is being used in the auto case, and then if it were being assigned to a mutable type:

bool test = OverTen(2);

Then you should truly get an ignored-qualifiers warning, because the const on the function result is being ignored.

Friday, 24 May 2019

Development Job: My Interview Log

Where have you been, and what have you been doing?... Well, in the short I've been very busy with the new job, which brings me to post, as there was a little confusion raised about my post the other night.... That post, like many of them here, was set up to go out months ago (in 2018 to be honest) I'd actually forgot it was in rotation, it wasn't for a recent job interview.

But it's about interviews I want to talk, so in my job search last year I had five interviews, count them... FIVE.... I'm not sure where on the scale of interviews that stands, to me it was a lot, to others it maybe very few, for you see the last time I was seeking a new role (in 2003 so a LONG time ago) five interviews was a lot, I had new roles very quickly for a time and interviewed for them once.

This time however I interviewed them as much as they interviewed me, indeed my current boss can vouch for the fact that after they'd made an offer I actually asked to go back and meet them some more, I wanted the right fit.  Being honest, I think I have it, it's interesting work and in a new field and includes international travel (as much as that can be a drag).

However, I wanted to talk today about the other four interviews, all of them started as phone interviews, two of them didn't go further than that, two did... One did and lead to an offer I kindly declined, lets just dissect what I can from them.

The first phone interview was for a company literally around the corner from my old house, I only decided to interview because of the proximity, a literal 10 minute commute really appealed after the 1 hour + drive I'd endured so long.  The interview was about server control, fiber channel, fat pipes, bits and bobs, but nothing development, I was after a hybrid role to allow me to stretch more with my server work but keep the development side ticking over... Simply the role didn't seem a fit so I left it there.

The second was also a phone interview and Brexit got mightily in the way here, it was for a company based in France, who wanted to move a certain subset of their products to the UK before Brexit, so they could possibly avoid import/export problems if the UK drops out of the customs union, it was all very very dodgy sounding and seemed they were willing to pay, and pay well, but you were taking all the risk.  Three times they repeated that "you will only receive one months severance pay in the first five years", very odd to say in an interview.  Then the kicker was that my boss would be in France, I would have to pay (myself) to travel back and forth, and I thought to myself my schoolboy French (GCSE grade E no less) would not suffice.  Plus it was in a very boring industry.

The next interview was a phone call, that progressed to my being invited for a face to face, and is perhaps the worst interview I've ever been in.  It began with them handing a laptop to me and asking me to write code... Except, they didn't want me to write code... They wanted me to write the Unit tests (google or NUnit - your choice)... BEFORE the code existed.  Now, this is a little alien to me, Test Driven Development (TDD) has always been a bit of a dark art, to write a test of code which doesn't exist yet seemed even more strange.

I get the principle, you write tests then write the code to conform to those tests, but this smacks of doing the work twice to me, I'm much more at home writing the code then testing it, or littering it with asserts, than TDD.  And I personally always favour a positive forward branch approach to code, so I make checks to get to the functional guts of a function then handle the error conditions in each "else", not the most popular approach but less off the wall than this chap was asking.

I went along with this test, let him show me what he wanted, then asked "the foo-bar program, it's maybe 9 lines of code, we've written fifty in tests, it's taken forty minutes to catch every case.  I can't but help think this is just to make someone none-tech-savvie happy that their code runs instead of them understanding the code themselves".

There was a distinct gust of cold air in the room at this point, and the technical interviewer left, handing me over to the WORST three hours of interview, YES, three hours.  They loved me, they talked about me, my life, told me their situations, about the company, about plans and products, stuff they really shouldn't have unless they were hiring me.... They were so happy they were promising me a job offer by the end of the week, even the end of the day. But on my mind was that test, it made me utterly not interested, that TDD session had me stone cold on the idea of not working there*.

At the end of the interview, I said this, that the technical test was a major off put, I said that I felt it smacked of their being a manager stood before a board berating everyone that their test was orange or god forbid red, rather than the code be succinct or of quality.  And that I would withdraw from the application.  They looked surprised and asked me why I didn't like the TDD approach, but I didn't want to elaborate.

As I went into the car-park, where I had parked, the sun had come around in the hours I'd been in there, so what was an opaque window I could now see into... there was a large man, with a bluetooth headset on, stood in front of a large wall mounted display, with the tests showing green or orange or red, and he would theatrically put his hand to his ear and make a person in the room look up as he spoke to them through this headset... I could not help but chuckle.

The final interview was from a friend, whom hearing I was on the job market instantly wanted to work with me again, he set up an interview with their C# web crew and told me to get my bum in their seat.  But this role was a long way away and even with the M1 it was an hour still... But on the days I went down there, massive traffic jams and I spent 3 hours in the car both ways, so it was already not going to be on the cards.  What was interesting though was this progressed to two interviews, two face-to-faces.  Because, the first two guys who interviewed me were leaving, they were hiring me as their own replacement.

My friend kept me interested and the pay was excellent, even if it was C# rather than C++ and they did their own NOC work and even though it wasn't a 100% fit it felt okay and the industry was familiar, as I'd worked within it before.  But on the second interview I was asked the BEST technical question... "if you have millions of strings, how would you optimised concatenating them together"... I asked if they were sorted, they were, so I said "from a single thread, optimise by threading the operation, concatenate the first half to the second or however many cores you have".

The guy just looked at me... "What about StringBuilder"... That was his whole reply, string builder, which is allocating it's memory half over each time and appending my memcpy under the hood was the solution he wanted, not threading, not pointer amalgamation, not memory defragmentation "StringBuilder".  This continued, rather than their thinking about solutions in code in terms of the problem, they thought of them purely in terms of C# classes, C# C# C#.  It was a little woeful.

I then asked about the roll out of the product, asked how they were working on it, remember I'm interviewing to be their boss... "because there's a bug in there"... I had done my homework, I'd spent a bit of time on their site, and found a definite bug, you do a search term and you get informed there's maybe 40 results or 200 results.  How many of these results can you see?... Just one.  The resulting search list was only showing the first result, none of the others.  If you changed the sorting order (to say by price) and did the same search, a different single result was shown, but still it said there were X others.... I pointed this out.

I literally sat there and showed them the bug.  And the chap looked at me, blinked and said (in front of his own departing managers) "There are no bugs".

I literally laughed, I thought it was a joke.  The managers just looked at me almost cringing, looked at him and we left it there, walking out to my car I asked the manager, "Is that why you're leaving?  You can't control or tell that technical bod when there's a problem?".... His answer was "Yes".

The last interview was were I've come to, about which I will say no more, but I hope you've enjoyed my little journey through strange, interesting and sometimes scary interviews in 2018.




* Interestingly a chap on the team I'm now on had worked at that company, he'd left them when the TDD mania began, funny that.

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.