Is it Time to Give C++ to the Garbage Collector?
C++, like its forefather, ‘C’, is a low-level language. Like C, its main design goal is to act as a kind of 'portable assembler', i.e. C and C++ can be used - with very few limitations - to write efficient 'systems-level code': and that code can be moved from platform to platform with very little effort.
The reason C/C++ are able to do this is that C-type operations, constructs and operators are primitive, mapping, very closely, to most CPU’s instruction sets: thus these languages are low-level and, from source to binary; there is very little execution-abstraction provided by either C or C++.
Indeed, these languages became extremely popular because of this and their low-level nature - as all one needed, to port a program from one machine to the next, was a C compiler – to map C’s primitives (in some program) to that other machine, via a compilation process (even C++ used to be compiled to C). Yes, albeit that ‘run’ meant ‘compile first’ in the case of C/C++ - C and C++ more-or-less started the ‘write once, run anywhere’ mantra now adopted as the war cry of many Java developers.
Because C/C++ can be used to create any program – remember, one is basically writing in assembler – it often is misapplied today, i.e. it is used to do everything – the adage “using a sledge hammer to crack a nut” springs to mind.
Ok, in the distant past, when programs ran standalone and, clock-cycles and memory were limited, the efficiency and flexibility of C and C++ was very welcome indeed. However most modern programs are no longer 'standalone', i.e. they use system-extensions in vast quantities. For example, modern Windows’ programs spend around just 7% of their total-execution-time in the code the developer actually writes! The rest of time being spent elsewhere ‘in the system’ (system DLLs and runtimes etc). To put this another way – today, a developer only writes about 7% of the actual code that gets executed by the CPU – for a given application.
So, why write such an insignificant proportion in such dangerous languages?
Why ‘dangerous’? Because in using such languages one is first and foremost faced with dealing with the machine’s memory - allocation, clean-up and ‘addresses’: primitive operations – as expected. One of the things that even experienced C/C++ developers say is that “pointers require concentration” (pointers are memory addresses in ‘C speak’) – indeed, it’s one of the most feared parts of learning C or C++ – that one will have to deal with pointers and, thus, memory. Yet, to write in C/C++, one typically must know how to use them expertly. Yes, C++ has improved upon C, giving developers proper ‘references’ and templated smart-pointer capability but, and here’s the point, ‘why bother’ – when, even if you could make your code run infinitely fast, you’d only speed up your application by around 7%?
Of course, it should also ring alarm bells - if skilled practitioners require language-constructs (these ‘smart-pointers’) to protect them from the language itself! And, they are but one example – the language is so dangerous that C++ experts extend it, so as to protect themselves from it – hmmm, well, I don’t know about you but I’d want a highly skilled person working with such a beast!
So, should C/C++ never be used? Not at all - both are excellent languages, it’s just that they should be applied judiciously – they should be the exception rather than the rule: Say that you want to fix a picture to the wall ... would you use a Colt 45, turned butt-up as a hammer given this scenario, or would you use, um, a hammer (not a sledge hammer mind, but the 'right' hammer for this job!) Sure, the Colt 45 will work a lot of the time, but occasionally, it'll blow your foot off. Use the right tool for the job - don't treat C++ as a kinda Swiss Army knife. We're living in a world where mixed-language programming is a delight, and where we need reliable systems - learn more languages, supplement a near empty toolbox with more tools, and get out of the mindset that it's 'smart' to program everything in C++ (as someone in the know once said: if you think it's smart to program in C++, you shouldn't use it)!