Two perspectives here. One is interoperability. Bytecodes are virtual machine code so you compile to bytecode on one computer, and distribute the compiled product across several OSes (win/mac/nix) or architectures (such as x86 or ppc64) (Java's once famed "write once run anywhere"). Another is how much the runtime knows about your program while it is running. In Java or C# you can ask a class what it is. You can create a class and methods at runtime and more generally your program is "self-aware" (via 'reflection'). This flexibility still has a cost ( < performance ).
At runtime C and C++ know almost nothing about the program being run, so there is no "C++ runtime" per se.
Wow. You need a tutor : P ?
-- Anyways. Note some of these properties are hard set, others are not. You cannot run compiled C/C++ across another architecture (or only via emulation of the target processor/architecture) but you could (at least in theory) bake information about classes inside compiled code; in practice compiled languages don't often take this approach - what they do is leverage every opportunity to optimize your code for the target architecture.
Two perspectives here. One is interoperability. Bytecodes are virtual machine code so you compile to bytecode on one computer, and distribute the compiled product across several OSes (win/mac/nix) or architectures (such as x86 or ppc64) (Java's once famed "write once run anywhere"). Another is how much the runtime knows about your program while it is running. In Java or C# you can ask a class what it is. You can create a class and methods at runtime and more generally your program is "self-aware" (via 'reflection'). This flexibility still has a cost ( < performance ).
At runtime C and C++ know almost nothing about the program being run, so there is no "C++ runtime" per se.
Wow. You need a tutor : P ?
-- Anyways. Note some of these properties are hard set, others are not. You cannot run compiled C/C++ across another architecture (or only via emulation of the target processor/architecture) but you could (at least in theory) bake information about classes inside compiled code; in practice compiled languages don't often take this approach - what they do is leverage every opportunity to optimize your code for the target architecture.
Okay, the interoperability one is what I thought.
Thanks for your explanation.