1. What both you and Jose (A. Pascoa) tend to constantly call C++ programming is effectively not C++ at all! This is rather plain old procedural ANSI C built in a completely different paradigm of another language which is a derivative of ANSI C but which is all about Object Oriented Programming with all the implicit overhead of multiply nested proxy calls to the "object" building blocks' various properties and methods. The requirement to ensure backward compatibility with ANSI C in modern C++ environments like VS or GCC is set forth in the corresponding IEEE and C standards because without such compatibility C++ would've been just as ridiculously slow as C# is.

2. Unlike modern C++ environments like VS and GCC which are automatic optimizing compilers, modern assemblers like MASM or HJWASM or PB/Lasarus/Delphi/Free Pascal ASM inliners are all non-optimizing (for various reasons but mainly due to the lack of continuous financial sponsorship/motivation of their respective developers). Non-optimizing assembler code is typically 3 times slower than optimized (but massively unmaintainable!) C compiler machine code output, even when the former is written by a programmer fairly proficient in assembly.

That said, here are two obvious consequences:

1. Had the benchmark code been written in genuine C++ (class instantiation, interfaces, properties, methods, namespaces and other modular "object" proxy stuff in the OOP worst tradition) rather than plain old procedural ANSI C, assemblers would've been definitively faster than C++ even if unoptimized automatically and thus relying only on the programmer's skills (or susceptible to the lack thereof).

2. Should sufficient monies be invested in assemblers to equip them with automatic optimization facilities competitive with what modern C/C++ compilers can offer, assembly would remain unbeatable, speed-wise, by higher-level languages to the end of time of our civilization.