This is gonna be a long critique, I'll try to keep it concise.

> C-like C++ is good start, if code doesn’t require more complexity don’t add unnecessary C++ complexities.

C is almost obsolete nowadays. Not to mention that C++ is effectively a strict superset of C (nearly 99% of the C standard is in C++) and the few features that aren't are included as compiler extensions (VLA, restrict keyword, nested functions). There are a handful of C features that aren't in C++, and for very good reason (most of them suck). When was the last time you ran into a C library that a pure C++ compiler couldn't compile? Only if someone decided to spam the new keyword all over the codebase (or something similar).

> In general case code should be readable to anyone who is familiar with C language.

Most C++ already is? Even very template heavy C++.

> Don’t do this, the end of “design rationale” in Orthodox C++ should be immedately after “Quite simple, and it is usable. EOF”.

A lot of the methods in that document are necessary to make C++ shine, especially template metaprogramming.

> Don’t use exceptions.

Optional but irrelevant.

> Don’t use RTTI.

.. Why? Reimplementing RTTI in C will give you almost the same overhead.

> Don’t use C++ runtime wrapper for C runtime includes (<cstdio>, <cmath>, etc.), use C runtime instead (<stdio.h>, <math.h>, etc.)

.. Why? Those wrappers all include the "raw C runtime" under the hood (literally they do #include <stdio.h|xx>. Near 0 compiletime overhead?

> Don’t use stream (<iostream>, <stringstream>, etc.), use printf style functions instead.

This is a design decision.

> Don’t use metaprogramming excessively for academic masturbation. Use it in moderation, only where necessary, and where it reduces code complexity.

There are many programs that are _impossible_ to write in a finite time without metaprogramming. How will you (with zero runtime overhead) dispatch a function with a variable arity of random types to a handler that requires exactly that type of function? Arbitrarily? In C++ it's possible, in C it isn't.

> When was the last time you ran into a C library that a pure C++ compiler couldn't compile? Only if someone decided to spam the new keyword all over the codebase (or something similar).

In C, you can use goto to jump over a variable declaration, and you can't in C++. I understand why this is, but it's the thing I see the most often that makes C code not compile as C++.

For me it was already obsolete in 1992, when I was given a copy of Turbo C++ 1.0 for MS-DOS.

It was the next step from Turbo Pascal in terms of safety, with added benefits from cross platform.

Nowadays all C compilers that matter are written in C++ anyway.

> nearly 99% of the C standard is in C++

But, one of the annoying habits of WG21 (the C++ committee) is sending stuff to WG14 (the C committee) to have them make it part of their language rather than accept that it's a C++ problem. Even the stupid type qualifiers are actually C++'s fault, K&R doesn't have this abomination but the pre-standard C++ did so too bad now it's in C89.

> > Don’t do this, the end of “design rationale” in Orthodox C++ should be immedately after “Quite simple, and it is usable. EOF”.

> A lot of the methods in that document are necessary to make C++ shine, especially template metaprogramming.

So? Is your goal to make C++ shine, or is it to produce useful, understandable code? My goal is good code, not being a showoff.