"C++ is a better C" but...

Why G-WAN, Global-WAN and SLIMalloc do not rely on 'more modern' C++

We will focus on tangible issues such as (1) code clarity, freedom to innovate, (2) performance, and (3) security.

• .NET    (since 2002) 1995 CVE records (90.6 security holes per year, "memory-safe" language)
• Java    (since 1995) 2538 CVE records (87.5 security holes per year, "memory-safe" language)
• GLibC (since 1987)     174 CVE records ( 4.7 security holes per year, "memory-UNsafe" language)

If, at this stage, you think that my posture is an exaggeration, you should read what ACM and Turing award winners say about C++ (all the more modern languages are a caricature of the defects introduced by C++) before continuing to read my prose.

C++ Imposes an Artificially Bloated Cryptic Syntax

Let's say that you are a student, or a parent – not a seasoned programmer. Your first reaction when facing modern C++ source-code will be: "it's very complex"... to the point that you may start doubting that C.S. (Computer Science) is for you, or for your kids. 45 years ago, I have learned programming with the assembly language (which I have enjoyed) but I am not sure that my enthusiasm would have survived C++.

A seasoned programmer in asm or C will say: "C++ is pointlessly unreadable". Why "pointlessly"? Because in C the same functionality is written in less characters – even for the most trivial things like an automatic cast and a standard-library call:

 C   |  FILE *outStream = writeStdout ? stdout : pStream;
 C++ |  std::ostream * outStream = writeStdout ? &std::cout : dynamic_cast(pStream);

Both examples are taken from a real-life recent Academic C++ "high-performance" library.

 C   |  int time_now_sec = time(0);
 C++ |  std::chrono::system_clock::time_point time_now_sec = std::chrono::system_clock::from_time_t(time_t_now);

C++ is horribly unreadable – to the point where you will spend hours looking for what std:: library function you need, and then, after you have picked one, you cannot even be sure of what will happen when you run the generated executable (that's why Google wrote its humongous 'Abseil' C++ library). Yet, universities and policy-makers insist to skip C or present it as an inferior, obsolete vestige of the past, most probably to eradicate C as a free tool for all – and to impose instead the reign of patented, constantly mutating arbitrary nonsense.

C++ (Agnonizingly Slowly) Generates unsafe machine-code Bloat

OK, we have seen that there's a C++ syntax overhead, but what about the C++ machine code overhead in a real-life high-performance system libraries, written by the "top of the line" market players that happen to be OS vendors?

SLIMalloc's core secure memory allocator uses less than 2,000 lines of C code. The rest of its code (almost 8,000 lines of code) is for the many SLIMalloc features that other allocators don't offer at all... yet SLIMalloc is by far the smallest of the available high-performance memory allocators:

Allocator            Language     blank-lines      comment-lines       code-lines
------------------   ----------   -----------   --------------------   ----------
Facebook  JEmalloc   C, C++          9,954      11,383 (18% of code)     62,708
Google    TCmalloc   asm, C, C++     8,917      12,417 (23% of code)     54,068
Microsoft MIMalloc   C               2,359       3,421 (27% of code)     12,461
TWD       SLIMalloc  C               1,482       7,638 (76% of code)      9,995

This table only includes each company's source code used by its memory allocator (without any security features for JEmalloc and TCmalloc). This lines of code count does not include system libraries or third-party libraries (like libunwind, used by TCmalloc and, as an option, by Jemalloc – SLIMalloc having no third-party dependencies).

Google TCmalloc, the only one to use asm, also relies on the Google Abseil C++ library (an additional 159,540 lines of code – without blanks and comments) to which it may add the "probabilistic" Google GWP-Asan library (slowing-down TCmalloc by a factor 2, in an attempt to secure it).

How does this gargantuan amount of C++ code, written by the GAFAM – the best-financed and most-widely praised experts available, translate into performance?

Not very well, to say the least.

Especially if you consider the fact that SLIMalloc is the only one here to deliver "memory-safety" to C and C++... in real-time, faster than those who are unsafe and inject their by-design vulnerabilities in all the system, libraries, applications and... the so-called "memory-safe" runtimes of Java and .Net where "memory corruption" is exploited for decades.

Think that memory-safety is a virtual and benign threat?

"A threat actor could exploit the flaw to obtain elevated permissions via specially crafted inputs to [network] applications that employ these [syslog] logging functions."

Think that memory allocation issues are rare? The GAFAM claim that "memory-safety issues" account for:

"70% to 90% of the root causes of all vulnerabilities" that APPLE, MICROSOFT and GOOGLE report as "unfixable" [1] [2] [3].

C++, like MICROSOFT, has a passion for unavoidable by-design bloat and security holes*... and it hides its sins by working very hard to transform the source code your write into what its authors want to promote... (they have a sponsor to please):

(*) "How do you protect what you want to exploit?"
      –Scott Charney, VP "Trustworthy Computing", MICROSOFT

Like I want my car to obey to my command when I drive, I want my compiler to execute the code I write. I don't want my car or my compiler to become creative on my behalf – especially if that's always to do much worse than me! A lot of what makes me enjoying driving or programming is predictability and the choice of action at all times. Remove this and both activities, driving and programming, become nightmares.

Be afraid of the people that make your life more complicated than necessary... while they pretend to simplify your life.

Be very afraid.

The Flawed C++ Goals

As time goes, C++ becomes bigger and bigger. It's like if gazillions of headless chickens are allowed to add every single library they have heard about – just for the sake of "completeness" (incompatibilities, obsolescence and redundancy are celebrated as... "achievements").

A programming language SHOULD NOT TRY TO BE the most complete collection of libraries. It should be the most effective way (simplest, most efficient) to write all the possible types of applications and libraries.

The focus of "standard libraries" should be limited to accessing the OS services (clocks, network, storage, display, keyboard/mouse, printer, etc.) and the language primitives (arithmetic, strings, timers, events, errors, etc.) – while leaving room for improvement (the ability to ignore the language "standard" string/network/math library to use your own).

So, C++ is a State-sponsored abomination (killing initiatives and skills to impose arbitrary "compliance" – an ever-moving target) while C is the undisputed reference (the freedom to do as well as possible, and to accumulate strategic skills).

Chose your poison: waste your life as the slave of a cruel an unjust master forcing you to stay a weak, rampant mollusk all your life, or work hard to become your own master (strong enough to shame those in power).

The Hidden C++ (and new languages) Pursued Agenda

An old saying attributed to the NSA claims that "a haystack is required to hide a needle":

• C allows you to do anything you wish, including mistakes, but it does not encourage them.
• C++ prevents you from doing most of the good things, and it silently enforces the worse – without you being able to escape it (generating hidden memory allocations, locks, side-effects, mixing data and code(!), redefining the language grammar, etc.).

I believe that the initial motivation behind C++ is the existential need for some Academics to pretend that they have made progress:

(then, MICROSOFT has funded C++ for the sake of artificially slowing-down software in order to sell more OS licenses)
(then, the GAFAM pretended to hate C/C++ while still using it, so that they could enforce their patented backdoors)

• Academics, those in charge of teaching to our kids, are notoriously in-love with abstractions (they routinely build cathedrals based on hazardous assumptions that have no relation with reality, like Big-O ignoring the cost of each CPU instruction, Encryption ignoring the underlying number theoretical assumptions, or Quantum-Physics based on postulates – the "NewScience" religiously enforcing dogmas). So, despite ever-failing to make things work as expected, they argue that 'correctness' requires these extra details in the name of "safety" (another abstraction that they have never made tangible).


• Engineers, those in charge of making planes fly rather than fall, are notoriously in-love with efficiency and reliability. So they argue that life is too short to waste it with a pointlessly obscure syntax: compiler warnings tell you (if you wish so because they can be disabled) if you have made a mistake... and an engineer has delivered automated safety for C/C++ with SLIMalloc in 2020.

The need to deliver on time and budget is pushing engineers to be less relaxed about hazardous genetic experiments (patiently feeded with radio-active waste and toxic emissions to discover new, eye-opening, "unexpected outcomes" like global massive sterility and death rates increases) than some Academics, who enjoy their capacity to afford (always at the expenses of the taxpayer) a passion for recurring eye-wateringly-expensive failures (this documentary is a perl, you will enjoy watching it).

• Academics leave school as students to re-enter it as teacher/researcher. They cannot be fired and enjoy a guaranteed retirement.
• Engineers leave school to become responsible doers, with their revenue, freedom and retirement not guaranteed by anyone.

Chose your poison: be a man – with the risk to fail, or enjoy being a State-protected parasite – always willing to please for a grant. Academics are not all parasites, but ALL the most capable Academics I know have been facing the hostility of a majority of their honorable colleagues all their life (another sacrifice to take into account).

The By-Design C++ Dirty Secrets

C++'s father Bjarne Stroustrup claims that "C++ code is not larger than C" and that "C++ is a better C" (hence, probably, the '++').

Yet, the C99 standard specification takes 224 pages while C++ requires 1376 pages... with the C++ committee using a much smaller font and more lines per page (in a vain attempt to deny a cruel reality?).
Bjarne may have meant that "C++ code is not larger than C"... if you don't take into account the humongous C++ runtime – many versions of which are not even compatible (even the C++ ABI has changed!) – which is even more shameful for anything calling itself a "better language".

Bjarne also said that the "C++ Boost library is well-engineered" while this code is clearly inefficient, that is, if design, size, speed, readability and portability are points worth considering.

Would C have made "Boost" better-engineered? While C does not let a+b; weight 10 MB without (macro) agonizing pains, C++ is a perpetual invitation to do the wrong choice. Either you carefully avoid C++ features because you known and understand their implementation, or your blindness makes you fall in the trap.

Abstraction is achieved at the expense of how computers work (hence the fat and wonderful bugs it drags). And the heavy '++' is dangerous for the unsuspecting masses because it hides its sins:

• C++ objects invoke hidden memory allocations (even before main() is started) replicated in 'inline static' functions – in both cases, this cost can easily be avoided in C but is imposed by C++;



• C++ classes mix code and data (violating a major taboo in computer-science) facilitating "memory-unsafety" exploitation by, for example, overwriting function pointers with an OOB (Out of Bounds) memory access on a dereferenced class member (a critical by-design security flaw that almost all the more recent languages have happily inherited from C++);
  
  Dynamically-loaded shared libraries enforce such function pointers: after decades of denial (by the OS vendors), this critical data has been stored by the system executable loader in a read-only memory segment... but I have never seen applications doing that when their code uses the dlfcn.h dynamic linking loader system interface to manually get and store function pointers.
  
  Library callbacks (another example of by-design function pointer nonsense), are totally useless, and should be ditched: since all library functions have reserved names, it is trivial to reserve such a name for a USER-DEFINED function (implemented by the application, and called by the library). The first function parameter will be the library instance's context so that many instances will be able to operate concurrently without name-space pollution.
  
  Since these callbacks are technically useless, the only reason why we are taught to use callbacks is to make sure applications will have function pointers stored at known locations (function parameter, struct/class field/member)... easily patched by OOB memory access violations – leading to arbitrary remote code execution.
  
  All function pointers uses can be avoided with features being listed in a simple enum passed to a switch(). This is much simpler, faster and safer. Yet, I have never seen any open-source programs doing that.
  
  All of these programming errors are left as an exercise in C, and enforced by the design of the "more modern" programming languages – hence today's cyber chaos.
  
  As usual, follow the money to find who deserves the blame.



• C++ virtual inheritance and virtual functions double the machine code size – as well as the execution time;


• C++ templates are encapsulating encapsulated layers – why not write code targeting clarity, speed or both?


• C++ has long lost contact with the reality, with ever-increasing compilation times and increasingly obscure error messages;


• C++ standard libraries, mostly redundant, have grown without any discipline or insight – and have increased the C++ surface of vulnerability while decreasing the ability for C++ developers to write their own functions;


• C++ defeats the purpose of programming – which is all about making choices at every possible step (design and implementation) to write the best code your need – something that C celebrates like no other portable programming language (by just providing access to base programming and OS features).
  
  
  I started programming in 1979 at age 11 in assembly-language because there was nothing else available but the BASIC language (the 'B' is for 'Beginner' – and if you felt the need to push its very frustrating limits then asm was the only option at the time). When I have been able to find a C compiler I enjoyed the same level of freedom offered by asm – without the pain of learning every (ever-increasing) CPU vendor's instruction set. Bad programmers make bad asm programs. Good programmers get the most of any programming language, that is, when it's not a straight-jacket.
  
  C++ users are developers, not programmers: they blindly use C++ features without even understanding how these features work, and as a result, by learned helplessness (maliciously induced ignorance) rather than vice, these people are unable to merely question the fact that they need to redesign the ready-to-use black-boxes instead of relying on the junk-food they are served.
  
  When, after decades of denial, they realize the tax they have paid because of scale of their ignorance and misplaced trust in sub-standard design, code and documentation quality, it's too late.

In a world populated by multi-core CPUs, a runtime's inefficiency hurts performance and scalability, even before your coding skills. This has a bit more costly consequences than the mere "philosophical choices" that C++ would like you to embrace.

Conclusion: C++ is almost* as efficient as C only if you do not use the '++'. What a progress, really.
[*]: this is no longer the case because C++ is no longer C with more features: the gargantuan C++ runtime trashes your disks and CPU caches, and successfully compiling perfectly legitimate clean C code with a C++ compiler has become an agonizing pain.

What the Most Recognized Experts Say About C++

Others – including recognized academic experts (and several ACM/Turing award winners) – have been more sanguine:

How can such a thing – widely considered as an abomination by the best experts (for computer-science, ACM awards are the equivalent of a Nobel prize) – can be funded by the taxpayer during decades, and enforced in universities by nefarious private corporations, tells a lot about the artificially-created root causes of our society's problems.