Next to the bare metal (C++)

Next to the bare metal is a term associated with C or C++. Most developers using these languages pride themselves in how close to the hardware they are working. This comes mainly because of the control developers had in the days of C(not to say C is not as powerful now). You can access memory locations and do quite some damage if you wanted.

With all that said, there have a been a lot of new programming languages coming to life, some becoming very popular more than others, most notably C# and Java. Which brings me to why I am writing this article. The progress of C++ has been a great one, and the language is still highly used and highly valued. But with the rise of other languages, people have opted to learn and use the more current languages to build their applications and this has lead to a lot of debate on which language brings the best features.

I was talking to a friend of mine the other day about all the new stuff I am learning and didn’t know existed in C++, this is basic things like recursive templates, lambda expressions and others. Some came in earlier versions of C++ and others later, the next major version is C++17 which should have a lot of toys to play with. Alright, back to the topic. It seems with all the new things added to C++ there is always some C# or Java developer screaming “We had that a while ago”, and even if this may be true, having the feature in C++ probably means more control over what it can do and how fast it is. I am no C++ evangelist or trying to defend it, but I have seen the power of it and can attest to the possibilities it possesses when it comes to data structures, I say this having used Java and a bit of C#.

This comparison of new languages and older ones servers no purpose, I believe more people should try learning some C++. It helps in understanding the underlying effects of the computer and how your code reacts to it. The universal example given is garbage collection, and pointers. But I believe this language brings much more to the plate and the speed, I won’t even talk about the speed when compared to other languages(I can sense someone ranting about optimizations that can be made in other languages), I will leave that to you to decide.

There are tons of improvements added to the C++ language in version C++11, C++14 and soon to come C++17, check out the status of these here. There are improvements and new toys that are totally confusing to use at first, but are some pretty powerful tools once you get to know them. Check out the latest stuff to come to C++17 here, and there are also links to features introduced in C++14 and C++11. Some of these concepts might be have been taken from other languages, but let us not forget where those languages took the bulk of their code-base.

Coding next to the bear metal is pretty awesome and it teaches you a lot, taking nothing away from other languages which have risen to the occasion and are powerful in their own right. South Africa needs a lot of C++ developers, take the plunge and you won’t regret it(after a few months or more).

  • Sfiso

    came across an interesting book,students use for the current cos 284,its the base to programming we must tackle it before or after learning languages,it stroke me with one fact that learning many languages doesn’t make you an expert as the languages follow sort of the same architecture ,so we must go back to the father c then grand father assembly language hey

    • lenkosi

      I fully agree. We are so caught up with learning as many languages as we can, we tend to forget that learning a new language is just a matter of learning how the syntax differs from the previous language you were using. We need to learn the underlying workings of how languages talk to the system, that is how we can master a language and be able to write optimized programs. And the best way to do that would be to use C/C++ which are languages that are higher than asembly but can talk directly to the hardware. That way, we understand what we are doing before getting used to things being done for us by the processor.

  • Proper stuff, but I have a questions. Has C++ improved on how it reports it’s segmentation faults? One could really use a stack trace when that unvisited part of the code decides to call out for attention.

    • lenkosi

      Well, what we need to understand is that segmentation faults are not a proplem in C++, they are caused by developers who do not care how they use memory and don’t try and write elegant code. The better question would be, have developers learned to write better code in order to prevent seg faults? And I would say no. So to answer your questions, no, C++ has not changed much when it comes to seg faults, it can’t really. But let’s be thankful for IDE’s and stack traces, they make our work a bit easier when debugging.