Thinking C++, rather than C

I'm going to be controvertial... Nothing new about that, but here is comes... Are you ready?

If you are a C++ programmer, and you are using sprintf, you are not writing C++.

There, I've said it, I can't take it back.  Obviously now, I need to qualify this statement, so lets begin.  Obviously, I am over simplifying, and C++ programs can contain calls to sprintf and still be put through the C++ compiler to receive working object code, so I'm not discounting the use of sprintf in C++ programs.

What I'm trying to tell you is that, if you are writing C++, designing C++, and sprintf is your goto method of truncating and outputting various raw data formats together as a string, then you are NOT thinking C++.

You are infact thinking C... Lets hear why this might be a bad idea...

Its about how you are thinking, you are not thinking in the skill-set you think you are.  And though I make a point about sprintf, I am talking about anything within C, if you happen to elect to use a part of the C standard which is not supported in the C++ standard you suddenly have a problem, and potentially derail your project.

And you don't need to worry about this, you don't need to get around it, program around it or turn hoops to achieve that perfect laminar flow in your code and project, instead you simply need to understand where you are crossing the boundary.

Thats easy when we talk about integrating a C++ program with Java or Python, becuase we have to bring in a whole other runtime element or library and we know we are interlinking, however, this cross-bleeding of C into C++ with no formal unification of the two is, in my opinion, more insidious.  Again Bjarne explains why, far more succincly than I can in the above video.

So, up date your way of thinking to lift your thinking into only C++ if you are writing C++, understand when you include CStdLib or CStdIO excetera you are pulling in a different language.

Therefore, even against many other programmers wishes, I will not use sprintf in C++ I will use streams to concatenate across lines of code:

#include <sstream>

#include <string>

const unsigned int c_Age(147);

const std::string c_Name("Xelous");

std::ostringstream l_oss;

l_oss << "Hello World, I am " << c_name << " and I am " << c_Age << " years old";

Rather than sprintf with "%s %i" formatting, because my solution is "more" C++, stronger C++ if you will.

Both sprintf and ostringstream usage achieve the same notional operations here, streams may even be slower, but I remove the over head of worrying about pre-allocating a buffer for the call, I remove the need to worry about deprecated calls or using "sprintf_s" for security, I drop the three decades of evolution in C and jump straight to the current C++ standard in 2017.

P.S. Some of you have asked where I've been for so long without any posts, well I've been in the deep dark depths of Wales, firstly with work, and then ironically I returned with the wife and dogs on a holiday, which was totally disconnected, no mobile, no internet, I read a few books, watched a lot of DVD's and TV, and I recharged my cognitive batteries after eighteen months of strife, but I'm back!

Development : The Cathedral & The Bazaar

Recently I had to explain to a none-developer how we had been working on a project, that is to say he and I.  I explained that our common boss worked very much in terms of the Cathedral, everything is big, grand, old, with set sources for supplies and almost dogmatic adherence to their ways of working.  Whilst he and I had been working, with extraordinary success, in a much more agile manner, in the manner of the Bazaar.

Anyone could bring items to us, he could filter some queries, I could filter some others, between us we then worked in an Agile manner to achieve a result.

I myself ran the development, and I pushed builds, lots of builds, releasing at least twice daily.  Any problem was picked up, worked on, solved and the next build had it, leaving a train of progressively better builds step by step, until we sit today with a fully functional system and we await input from multiple other sources.

The main source for things we are awaiting is the Cathedral, we have waited a long time, seven weeks of hard work by ourselves far out stripped the expectations of the Cathedral model of working, and once we superceded that model it was too heavy, too slow, too stiff to catch up with us.

The net result is somewhat of a pocket of confusion, work was demanded, it was delivered, yet now it sits unused.

The bazaar delivered, whilst the Cathedral struggles.

("The Cathedral & the Bazaar" is a famous musing upon software development from the perspective of old slow methodologies to the exploding Agile methodologies which suffuse the Linux development and open source development movements).

IT Sexism : What is Modern Development (for a Woman)?

Recently, I was challenged, almost to a fault, to enthuse myself about "modern development"... The quiz master expected me to extol about the virtues of distributed code verses centralised, to effervesce about sprints, about round tabling, about all these other buzz words and cockeyed concepts.

I simple asked the quiz master, quite what they meant by "modern development" ...

So surprised were they that they broke through a little bit of their shell and just talked to me, it was a refreshing change, moving away from methods and procedure, we talked about the system itself, avoiding even the language they were working in.

It soon became apparent we both worked from the same hymn sheet, just perhaps mine is an older copy... For you see, to me a good development job, doesn't necessarily sit with the work at hand, it sits with how you are allowed to approach that work, if you are just bombarded with red-tape and requirements and  micromanagement, then the person micromanaging you may as well just do the job on their own; and I have worked as the poor soul doing the work in just such a situation.  And it soon became clear this was the problem with the team this person was controlling.

It appeared they had gone through personality, philosophy and finally technical clashes, to the point that the four developers on the team didn't do much more than talk to one another about computers and draw their cheque each month.

The manager was doing all the work, not because she wanted to, not because she was female and they pushed it onto her, but because she had set high standards and promised delivery, but was getting no input from those below her.

In a paradoxical, and pretty toxic, situation, she was enabled to hire one more head, but not able to fire the useless four... She had ideas I might be that fifth chair, not a thought I relished as the conversation expanded into the actual problems she faced.

Now I've run into dysfunctional teams, but I know in the end the work either gets done or you all get fired, sometimes both.  But to sit and provocatively do nothing in the manner these folks did was tantamount to embezzlement, when I was introduced to them, they just sniffed and looked at me; I was egging myself onto ask them technical questions, but I was whisked into a private meeting room where this sad talk unfolds from.

After twenty minutes lamenting the problems I asked "What do you use as a way to leverage the work, what is that pedal you press to put on the pressure or get results?"...

She looked at me rather blankly, almost as though I were a magician showing a dog a card trick, as her eyes blinked she started to reel of a bunch of methods... Waterfall this and sprint that, and engagement in progress... yadda yadda yadda....

I put my hand palm up and asked again "not what procedures, what do you physically do?"

She didn't do anything, she sat in her office away from them all day and did code.  She never got out her chair and challenged them, she never spoke to then, she never pushed them in person... "Why not?"

And I was flabbergast to hear an intelligent, clearly able, mid twenty something, graduate and clearly decent programmer trying to manage a team say to me... "Because I'm a woman, they don't listen".

She was serious too!  Going on to explain that when she started she worked for a chap about my age, and they listened to him, she was one of them, but took a lot of ribbing, she moved into the supervisory role, still in the same room as them without issue, then was appointed to manage this new project when the other chap left... And that's where the problem started.

I wasn't sure whether it was green eyed envy at her progressing above them, or just because she had boobs, but whatever the reason I thought it extremely uncomfortable.  I saw her wanting, desperately to have a puppet in a more senior position to the team, to invoke her will upon them, and wanted myself (clearly 10 years older than them, and twenty something years her senior in age) just as a sort of enforcer and inquisition.

And I thought, her idea was "modern development", lots of buzz words and concepts, she had lost the "just talk to people" vibe.  Sadly because she was being intimidated, perhaps even sexually harassed... That, was the sad state, I found modern development in... Sickening and not a place I wanted to involve myself.

Software Engineering : C++14/make_shared & Factory Create Pattern

I have a C++ issue, it's not often I can pick fault, but this is one of them... For years, I've used the factory create pattern; or at least my take on that pattern.  

Whereby I make the constructor private, or the whole class "Uncopyable/Uncreatable", and then I add a new static function which returns the class wrapped into a smart pointer.

By doing this, I get the advantage that no-one can use outdated "new" calls on it, and I drastically reduce the potential for third party memory leak creation/exploitation.

I can still do this with C++14, however, for a while now authors have recommended using "std::make_shared".  Their points are valid, but they break my factory creation pattern.  Which has much more to offer me than just using "make_shared" or whatever smart pointer creation template.

Lets take a look...

So, we have the class, but we're creating and deleting it in the old style, anyone forgetting to perform that delete will leak memory.

There, we can implement creating the class instance with a smart pointer...

A big change next however, we make the constructor private, to absolutely stop other programmers creating instances of our class with "new" and so totally negating anyone creating the class and potentially forgetting to delete it.

So we offer the programmer the static create function, which returns the shared pointer wrapped class... At least, that was the idea, as we can see, it utterly fails, because the std::make_shared template class is not a friend of our "foo" class.

Finally, we have to take a step back, to use the create, and hence enforcing our whole factory create pattern, we have to return this smart pointer wrapped instance after using "new".  This is fine, it is the same as "std::make_shared", but feels like a retrograde step.