C++ – C++ Runtime and Runtime-Linking

cruntime

I was installing boost and I came across an option named "runtime-link". After searching a bit, I came across yet another complex topic: "runtime system"

that according to Wikipedia:

The runtime system is the gateway by which a running program interacts with the runtime environment, which contains state values that are accessible during program execution, as well as active entities that can be interacted with during program execution. For example, environment variables are features of many operating systems, and are part of the runtime environment; a running program can access them via the runtime system. Likewise, hardware devices such as a DVD drive are active entities that a program can interact with via a runtime system.

yet another topic " Runtime enviroment " comes up

the runtime system of the C language is a particular set of instructions inserted into the executable image by the compiler. Among other things, these instructions manage the processor stack, create space for local variables, and copy function-call parameters onto the top of the stack

Based on above statement, is it safe to say that "C++ runtime is basically an API to system-calls for cross platform implementation of C++ keywords and statements" and that "runtime environment is basically OS kernel" (please note that I'm only talking about c++)?

And still I have no clue about runtime-linking and why it can be static or shared? Is it related to static and dynamic libraries? (I'm completely familiar with those, so you don't have to explain that, only relation if there is any) and most of all i am confused due to "runtime hierarchy".

Best Answer

You seem to be confused because “runtime” is both a noun and an adjective. Your question asks about the three distinct concepts of the “run-time environment”, the “language runtime”, and “run-time linking”:

As a noun, the “run-time environment” of a program, or phrased differently: the “environment of a process”, refers to the (changing) state of the outside world. This state is most obviously accessible and modifiable by doing I/O, such as reading or writing {from,to} {terminals,files,block devices,network sockets}. The environment can also include concepts such as the “current working directory” or “environment variables”.

As a noun, a runtime of a programming language refers to the part of a language implementation that provides run-time semantics. This is most visible in interpreted implementations, where the interpreter is the runtime. But standard library functions can also be part of the runtime, such as malloc in C.

Some parts of the runtime might be compiled into the program rather than being accessible via a library. The way how destructors are invoked in C++ would be an example of this – the compiler inserts instructions to destroy stack objects when their scope is left, and instructions to destroy member variables when a class instance is destroyed. Another example of runtime-supplied code is the program entry point, which is not int main(). How the entry point is determined depends on the executable format. But at that real entry point, the compiler will have emitted code that e.g. takes care of initializing static members. This code will then invoke the programmer-supplied main(), but that may be non-trivial in itself. E.g. in C++ this implies dealing with uncaught exceptions, whereas Java has to also spawn the main thread. After main() returns, the runtime has to perform various cleanup, and then communicate the exit code to the OS and terminate the process. Note that complex systems such as languages or frameworks implemented on top of C add more layers to finding the real, user-perceived program entry point.

It is not generally useful to view the OS as part of a language runtime, but that view changes when writing assembly. Some assemblers include runtime-like code generation features, but doing anything interesting usually involves syscalls to the OS kernel. In user space, the point of the C language runtime and its extensions such as POSIX is to abstract over these syscalls and other system-specific details, so that the interface provided by the OS is totaly subsumed by the language runtime interface.

As an adjective, “runtime” in “run-time linking” is used to differentiate dynamic linking from static linking. In nearly all computer-science contexts, the word “dynamic” can be substituted for “run-time” to get the intended meaning. Misusing Ancient Greek words is way cooler than using boring olde English, so we keep on talking about “dynamic typing” or “dynamic linking” or “dynamic dispatch” (in its original sense, “dynamic” means “powerful” or “involving energy”, but via the meaning “changing” it seems to have arrived at its current computer science-specific meaning).