4 ms·

> C++ made the choice that linkers should be able to coalesce duplicates Yeah and shared libraries are where it gets ugly. For example, libstdc++ has an empty

> C++ made the choice that linkers should be able to coalesce duplicates Yeah and shared libraries are where it gets ugly. For example, libstdc++ has an empty string singleton `_S_empty_rep_storage`. Its headers compare a std::string's storage against this, by address, so the dynamic linker is on the hook to coalesce the empty string symbols. It doesn't always work, and then things break mysteriously when you have two copies of the same variable. > There's nothing wrong with taking the address of an inline function, though. It behaves just like a normal function. I think you're proposing that inline functions should have a single definition? This breaks header-only libraries, and also gets sticky with shared libs; whose symbol wins? If everything is one big static link then it's probably fine. If your compiler is deciding to emit code now, or link to future code, dependent on optimization level...it's painful!

klodolph 5y ago
> I think you're proposing that inline functions should have a single definition? This breaks header-only libraries, and also gets sticky with shared libs; whose symbol wins? You can have the definition in as many translation units as you like, it's just that only one of the definitions can have extern linkage. This works right now, today, both with header-only libraries and across shared library boundaries. If you take the address of an inline function defined this way, you just get the address of the extern linkage definition. The C compiler will do the right thing, as long as you keep in mind the limitations: - Anything static will get duplicated in each translation unit. (Regardless of whether something is inline--the "inline" keyword isn't relevant here.) - No two translation units have an extern definition for the same symbol. (Again, regardless of whether the symbol is an inline function.) All "inline" lets you do is two things: - You can define a function without creating an extern linkage symbol. - Static inline functions do not cause warnings if not used. So, with your shared library, you have to pick one translation unit in one library which gets the extern definition. This is the same restriction you have with non-inline functions--if you are linking a static library into two different shared libraries, and then combining these shared libraries, you will run into problems regardless of "inline". Or put another way... none of these issues are related to the "inline" keyword in C. The "inline" keyword does not create any new problems.

klodolph 5y ago

> I think you're proposing that inline functions should have a single definition? This breaks header-only libraries, and also gets sticky with shared libs; whose symbol wins? You can have the definition in as many translation units as you like, it's just that only one of the definitions can have extern linkage. This works right now, today, both with header-only libraries and across shared library boundaries. If you take the address of an inline function defined this way, you just get the address of the extern linkage definition. The C compiler will do the right thing, as long as you keep in mind the limitations: - Anything static will get duplicated in each translation unit. (Regardless of whether something is inline--the "inline" keyword isn't relevant here.) - No two translation units have an extern definition for the same symbol. (Again, regardless of whether the symbol is an inline function.) All "inline" lets you do is two things: - You can define a function without creating an extern linkage symbol. - Static inline functions do not cause warnings if not used. So, with your shared library, you have to pick one translation unit in one library which gets the extern definition. This is the same restriction you have with non-inline functions--if you are linking a static library into two different shared libraries, and then combining these shared libraries, you will run into problems regardless of "inline". Or put another way... none of these issues are related to the "inline" keyword in C. The "inline" keyword does not create any new problems.