Re:Go memory ballast: How I learnt to stop worrying and love...
by saagarjha on Monday December 02, 2019 @05:41AM
(#21681342)
If you don’t have static initalizers you should just be able to set your entrypoint to be main, no?
Re:Go memory ballast: How I learnt to stop worrying and love...
by jchw on Monday December 02, 2019 @01:22PM
(#21685141)
Not really, because the entrypoint of executables is OS dependent and may not resemble the “main” function signature. I actually don’t know what Linux dumps on the stack/registers before calling your entrypoint, though, to be honest.
Re:Go memory ballast: How I learnt to stop worrying and love...
by saagarjha on Monday December 02, 2019 @01:42PM
(#21685367)
On a freestanding environment, the signature of main doesn't have to be the standard "int main(int argc, char argv)". Oh, and on Linux the the arguments to main are put on the stack, which you can see is handled by _start: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86...
However, even if you go to the extreme of not using any features that require runtime support, if you are using hosted C++, in practice you still have one bit of runtime: the entrypoint. Technically, an operating system could implement the bits that call main, but to the best of my knowledge none of them ever have. So every compiled binary from every hosted C++ implementation begins at the runtime library. (Admittedly, normally the C runtime library, since C++ doesn’t differ here, but that is just another layer deep of pedantics. In practice, everyone has a runtime.)
Nitpick: As far as I am aware OpenMP is not part of the language itself but an extension. But yeah, you could argue that is runtime scheduling in C++, I think.