Sorry, I don't know what any of these does. When I went to school it was common convention that system level is the OS kernel, drivers and anything else that talks to the hardware.
Right. Now show me some widely used OS kernel written in C++. No, not some research thing. Becaue I hear all the time C++ is a system level language, yet it is most widely used to write games and desktop apps, not systems.
Console games are just applications like any other PC game. They access hardware by communicating with OS services. The only difference is in consoles you exactly know your hardware and you can make better use of it and OS provides less than a full blown PC OS. But this is not related to Java vs C++ debate. Java is capable of accessing hardware directly. There is even some hardware that directly runs Java or some low-end embedded systems running Java.
As of XNU, it is mostly pure C. There are a few C++ files there but they are very far from what we call "modern C++". No templates, no use of standard library, no exceptions, const char* everywhere. Just C with classes.
It appears you are either trolling or simply don't know what are you talking about. Either way there is nothing to be gained from this discussion for either of us.
"many developers tend to forget that what makes C and C++ usable for systems programming are actually language extensions that are not part of the standard."
Excuse me but what??? Please give an example. Except for maybe setting up an isr vector table and the odd coprocessor command in assembler, all other peripheral functionality is usually memory mapped and perfectly accessible in C and C++.
All the hardware interface is through shared/mapped memory nowadays (there are CPUs with a dedicated I/O bus or fancy coprocessor interfaces too but even there the bulk of work is creating control structures in memory and then kicking them through a port or a coprocessor instruction). C/C++ are perfect for the memory manipulation even in their purest standard form. I imagine your concern is about deriving the addresses for register apertures or emitting specific opcodes?
For the concrete addresses you just link with the symbols defined outside of your C code. Special ops cannot be done in pure standard, but this is not an issue in practice as there are no pure standard compilers. Even for app development you want intrinsics just for the vector, cache and bit instructions.
No, the point being that without language extensions, a C++ AOT compiler is in the same ballpark as a Java AOT native compiler.
You need an external Assembler or OS APIs to provide the required functionality. The same way that a Java runtime library can provide bindings to Assembly or OS APIs.
There are commercial AOT native compilers for Java targeting systems programming, like the ones from Atego.
I guess it depends on the size of the ballpark. 99.99% of code I write is pure C++ as all I do is, essentially, moving data around memory. My wild guess is that using Java I had to put these 99.99% into some external library as Java does not support memory manipulation. Either way, we went quite far from the original point of managed memory being a good thing (almost always).
I was just playing devil's advocate a bit, because many developers tend to forget that what makes C and C++ usable for systems programming are actually language extensions that are not part of the standard.
Many mainstream languages, with AOT native compilers would be as usable.
Most developers never read the standard in the first place. I don't see how is this important though. We did not have a standard till 1998, yet somehow managed to use C++. Same as with C, which had been used very successfully standard-less for almost two decades.
> Most developers never read the standard in the first place. I don't see how is this important though.
Do you write portable code in C and C++ across disparate systems and OSs, using multiple compilers?
I used to do that between 1994 and 2001. Don't miss those days of hit-and-miss about compiler support.
> We did not have a standard till 1998, yet somehow managed to use C++.
Yes we did. It was called the Annotated Reference Manual, used as basis for the standard, coupled with articles from The C++ Report, The C Users Journal (latter The C/C++ Users Journal).
> Same as with C, which had been used very successfully standard-less for almost two decades.
It works if you only care about one specific compiler. On those days the standard was the AT&T UNIX compiler.
Obviously, you cannot write portable system code. You can do conditional compilation to target multiple platforms though. And when you do that you realize two things:
1. No compiler is fully compliant with any standard.
2. Every compiler has bugs so even the compliant parts can be unusable.
And then you realize it's not a big deal. Changes between platforms are greater than changes between compilers. When your targets have different endianness or, even better, mixed endianness between different PUs - the standard compliance of your code is the least of your worries.
>It works if you only care about one specific compiler.
Also works if you care about a finite number of specific compilers and architectures.
>On those days the standard was the AT&T UNIX compiler.
There were, probably, hundreds of compilers and C flavors even before the ANSI C. What one thought was "the standard" was very subjective.
