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!

Comments

Post a Comment

Popular posts from this blog

C++ : Ignored qualifiers (-Wignored-qualifiers)

What is an ignored qualifier?  Well, in a class, lets have a student class: #include <string> class Student {     public:         const std::string Name;     private:         bool m_Present;     public:         Student(const std::string& p_Name)             :             Name(p_Name),             m_Present         {         }                 void SetPresent() { m_Present = true; }         void SetAbsent() { m_Present = false; } }; Now, we may want to access the present flag, therefore provide a function to do so:     bool Present() const { return m_Present } This function is telling the user of our class quite a bit, it tells them that the return type is boolean and that the calling of this function makes no changes to the class  contents (const trailing the parameter list). However, for me, this isn't quite right, I believe that we want to inform any user that the boolean returned is also constant, it does not change unless you alter the internal value with the "Set
Read more

C++: The Dilemma of using Exceptions

Image
As a C++ developer I've recently been in the midst of the Exceptions debate.  Exceptions as a feature of the C++ language have long divided the community, naively I've often put this down to their coming to the language from elsewhere (C perhaps) where exceptions were not the norm. This was a mistake, for in the projects I've previously worked upon the overhead of an exception compared to the ramifications of the error resulting in a crash have often totally outweighed the overhead, making deciding to employ an exception exceptionally easy (*bum bum*).  Exceptions were the norm, still are and should be to you too (according to the C++ Core Guidelines https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Ri-except ). The difficulty, the dilemma if you will, comes not from the feature, but the cost.  If you application domain demands high performance you can not risk using exceptions, the argument carries on therefore whether in not using them to avoid
Read more

Development : Anti-Hungarian Notation

Whilst cutting code I employ a coding style, which I enforce, whereby I output the scope of the variable being used with a prefix. "l_" for Local "m_" for Member "c_" for constant "e_" for enum And so forth, for static, parameter and a couple of others.  I also allow compounds of these, so a static constant would be: "sc_" This is useful in many languages, and imperative in those which are not type strict, such as Python. Some confuse this with "Hungarian Notation", it's not.  Hungarian notation is the practice of prefixing a type notification to the variable name, for example "an integer called count" might be "iCount". I have several problems with anyone using Hungarian Notation, and argue against it thus. With modern code completion and IDE lookup tools this is really not needed, with useful and meaningful naming of your variables the type is not needed and finally there are multiple types with the s
Read more