On 03.04.2017 19:02, Liu Hao wrote: > On 2017/4/4 0:48, David Grayson wrote: >> I'm a bit confused about the different inlining keywords. From the GCC >> documentation for inlining in the C language ( >> https://gcc.gnu.org/onlinedocs/gcc/Inline.html ) it seemed like "extern >> inline" (i.e. __CRT_INLINE) would be the best thing to use, but I could not >> find any cases where __inline (which I think is a macro) is worse. >> LH_Mouse's patch does not change what kind of inlining keywords are used, >> it just changes the logic for when to use those keywords. > If you have multiple `extern inline` definitions in different > translation units (TU), a C++ compiler is smart enough to mark them as > 'link once', so the linker will only pick the first definition it finds > and discard the rest. This isn't the case in C. If you have an `extern > inline` function _defined_ in a header, the definition would end up in > every TU that refers that header, resulting in multiple definitions of > that function. > >> Anyway, I tested LH_Mouse's second patch and it works for me, so I'd say >> it's mergeable. > Thanks for testing. I am looking to Jacek's opinion.
I'm sorry to jump into discussion so late. The patch looks good to me. I took a look at how __CRT__NO_INLINE is handled in the tree and I must say I'd be tempted to limit its usages in general. Take time.h for example. It has some inline functions forwarding to 32 or 64 bit, depending on _USE_32BIT_TIME_T define. It looks fine until you look closer at this. Those inline forwarders are inside __CRT__NO_INLINE, meaning they will not be used if inlining is disabled. Linker will be used instead to whatever is default for given options, but it's not necessary the same as would be used based on the macro. That's not an effect I'd expect from changing compiler optimization level! Anyway, it's an off topic to this patch, I just wanted to explain my general dislike to __CRT__NO_INLINE usage. I think we can do better without it and provide inline functions even if true inlining is disabled. That said, patch is fine with me as it's how we currently do things, but I would like a patch removing __STRSAFE__NO_INLINE even more ;) Thanks! Jacek ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
