4 ms·

C and C++ say that a function has the same address in all translation units Until perhaps very recently, the ISO C and C++ standards didn't actually support dy

C and C++ say that a function has the same address in all translation units Until perhaps very recently, the ISO C and C++ standards didn't actually support dynamic linking. (They didn't officially support multithread concurrency either but flexibility is one of those languages' strengths). if your final binary is over 2GB the linker could fail to put the symbol within range of the offset and fail I have had to code around this limitation too but it didn't turn out to be that hard in practice. How about we optimize for the case where the final binary is 2GB or smaller? :-)

brigade 15y ago
> Until perhaps very recently, the ISO C and C++ standards didn't actually support dynamic linking. (They didn't officially support multithread concurrency either but flexibility is one of those languages' strengths). How so? They certainly didn't mention it but they shouldn't have to - describing the final linked behaviour is enough and means that whether it was statically or dynamically linked doesn't matter if it produces the same run-time behaviour. Which resulted in a huge mess in the linker for C++. > How about we optimize for the case where the final binary is 2GB or smaller? :-) I agree, but compilers should be standards-compliant by default and any such optimizations should be under non-default flags (e.g. -fvisibility-inlines-hidden). But -mcmodel=small is already the default...
- marshray 15y ago
  I'd seen references to possible standards issues with dynamic linking, but hadn't really thought about it until you pointed it out: taking the address of a function or data object with linkage is no longer naturally returns the same address in different translation units. Believe it or not, in C++ a pointer to an object or function is valid as a non-type template parameter. Heck, I bet you can even partially specialize on it.
Rexxar 15y ago
I'm very curious to know how you manage to need 2GB final binary ? - Huge use of template metaprogramming ? - Generated code ? - May be it's only for the debug build with all symbols ?
- marshray 15y ago
  One can include arbitrary amounts of data in binaries. I don't see this for ELF systems, but consider all the Windows installers that package entire applications into a single .exe.

brigade 15y ago

> Until perhaps very recently, the ISO C and C++ standards didn't actually support dynamic linking. (They didn't officially support multithread concurrency either but flexibility is one of those languages' strengths). How so? They certainly didn't mention it but they shouldn't have to - describing the final linked behaviour is enough and means that whether it was statically or dynamically linked doesn't matter if it produces the same run-time behaviour. Which resulted in a huge mess in the linker for C++. > How about we optimize for the case where the final binary is 2GB or smaller? :-) I agree, but compilers should be standards-compliant by default and any such optimizations should be under non-default flags (e.g. -fvisibility-inlines-hidden). But -mcmodel=small is already the default...

marshray 15y ago
I'd seen references to possible standards issues with dynamic linking, but hadn't really thought about it until you pointed it out: taking the address of a function or data object with linkage is no longer naturally returns the same address in different translation units. Believe it or not, in C++ a pointer to an object or function is valid as a non-type template parameter. Heck, I bet you can even partially specialize on it.

Rexxar 15y ago

I'm very curious to know how you manage to need 2GB final binary ? - Huge use of template metaprogramming ? - Generated code ? - May be it's only for the debug build with all symbols ?

marshray 15y ago
One can include arbitrary amounts of data in binaries. I don't see this for ELF systems, but consider all the Windows installers that package entire applications into a single .exe.