I only know about the two C++ alternatives already mentioned.

If this had been a "normal" target, there would have been other alternatives allowing C++ to be preprocessed into C and then compiled with a C compiler.

But the 8051 needs a number language additions because of memory regions, bit addressing and interrupts, that means a C++ preprocessor would most probably need to understand the additions of the C compiler to be usable.

The stack and the machine instructions for indirection are the big hurdle for C++.

C++ is a better C than C even if not using virtual methods etc. It adds a number of small features that improves type safety and ability to modularize code that does not affect the runtime requirements. So C++ would be excellent for an 8051 even without use of virtual methods, exceptions, templates, ...

But all (?) books about C++ will teach the full language, or at least a major part of the language. So anyone who try to use C++ on a 8051 will be frustrated when they do what it says in the book, and then get into troubles. The Keil linker wants to be able to figure out the call chains of the program to see how local parameters can be upgraded into nameless, but reused, global variables. Virtual methods on the other hand are there just to _not_ let the compiler know when/if a function is called. They are basically a variant of runtime linking. But over all - anyone using C++ on a 8051 would need to know and understand exactly how all the language features are actually implemented - and exactly what the underlying C compiler/linker will do with different constructs.

So the reason I don't think C++ is a good choice for 8051 isn't because it generates bloated code or is too complex or too much of a burned for a 8051. It can match byte-for-byte the code of a C compiler. But it adds a big burden on the developer to understand which C++ features that are great to use, and which C++ features that may blow up in the face. I personally think that this burned is way bigger than the advantages the user gets from "a better C", i.e. the help with type checking, namespaces etc.

Switching to a microcontroller with a larger stack and a reasonable set of indexing instructions (not just 32-bit processors, but much 16 and 8-bit architectures too), you don't get a huge punishment from using virtual methods etc. The only punishment that bigger processors may take from C++ is templates (which performs a form of copy-paste of code reducing # of source lines for similar code but different data types, but producing larger binaries) or switching from the C I/O library to the C++ stream-based library which is much larger. In the end, for most other processors, a "wrong" choice can only increase the binary a bit - and many target architectures have enough flash that it is well worth this cost just to save on development time.

But the main issue with C++ on a 8051 is that it probably complicates the life of the developer more than it helps. Unless you really are very skilled, and already do understand exactly what makes C++ tick and what your compiler will actually do for any C++ construct. In short - a beginner will not get helped by C++ on a 8051. And someone with 10 years experience writing C programs on the 8051 should be able to continue just fine with C.