[cfe-dev] _LIBCPP_INLINE_VISIBILITY and std::string::length

[Howard Hinnant]

On Mar 8, 2013, at 4:05 PM, John McCall <rjmccall at apple.com> wrote:

> On Mar 8, 2013, at 12:18 PM, Howard Hinnant <hhinnant at apple.com> wrote:
>> On Mar 8, 2013, at 2:09 PM, Alexey Kudinkin <alexey.kudinkin at gmail.com> wrote:
>>> Hello!
>>> 
>>> I'm just curious about what are the reasons to forcing inlining of that sort of functions like std::string::length? Precluding them to be included into libc++ binary breaks linkage of the following snippet of code 
>>> 
>>>> int main(int ARGC, char *ARGV[])() {
>>>> 
>>>> std::vector<std::string>  pray = { "I", "will", "not", "aim", "for", "the", "head" };
>>>> std::vector<size_t>       lengths;
>>>> 
>>>> std::transform(pray.begin(), pray.end(), std::back_inserter(lengths), std::mem_fn(&std::string::size));
> 
> For what it's worth, IIRC this code is not required to work, because you are not generally allowed to take the address of functions from the standard library.

Actually I think this was more true in C++03 than in C++11.  The specification says the vendor can add default arguments and/or overloads to a non-virtual member function.  So you can't assume the member function's precise signature.  Now with variadic templates it is a lot easier to take the address without assuming the precise signature of the member function.

> 
>> The rationale for the use of always_inline in libc++ is to control the ABI of libc++.  In the past I have watched compilers use different heuristics from release to release on making the inline/outline decision.  This can cause code to be silently added to and removed from a dylib.  With the use of always_inline, I am telling the compiler to never add that code to the libc++.dylib binary.
> 
> This is an incredibly brute-force way of accomplishing this goal, and it causes major problems downstream, e.g. with debugging programs that use libc++.
> 
> Have you considered only explicitly instantiating the functions you actually want to show up in the library instead of explicitly instantiating the entire class?

No, I hadn't considered that.  I'll give that some thought.  It sounds tedious but it may be worth it.

Thanks,
Howard