<div dir="ltr"><div style>Sorry, for the not so prompt response.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Mar 8, 2013, at 12:18 PM, Howard Hinnant <<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>> wrote:<br>> On Mar 8, 2013, at 2:09 PM, Alexey Kudinkin <<a href="mailto:alexey.kudinkin@gmail.com">alexey.kudinkin@gmail.com</a>> wrote:<br>
>> Hello!<br>>><br>>> 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<br>
>><br>>>> int main(int ARGC, char *ARGV[])() {<br>>>><br>>>> std::vector<std::string> pray = { "I", "will", "not", "aim", "for", "the", "head" };<br>
>>> std::vector<size_t> lengths;<br>>>><br>>>> std::transform(pray.begin(), pray.end(), std::back_inserter(lengths), std::mem_fn(&std::string::size));<br><span style="font-family:arial,sans-serif;font-size:13px">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.</span></blockquote>
<div><br></div><div style>However, i believe that since it didn't result in compilation error it is perfectly clang bug: it seems like it's easily reproducible with extern templates and __attribute__ (( __always_inline__ )) without involving STL, and hence rendering pointers/references to the members pretty useless.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 9, 2013 at 1:05 AM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mar 8, 2013, at 12:18 PM, Howard Hinnant <<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>> wrote:<br>
> On Mar 8, 2013, at 2:09 PM, Alexey Kudinkin <<a href="mailto:alexey.kudinkin@gmail.com">alexey.kudinkin@gmail.com</a>> wrote:<br>
>> Hello!<br>
>><br>
>> 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<br>
>><br>
>>> int main(int ARGC, char *ARGV[])() {<br>
>>><br>
>>> std::vector<std::string> pray = { "I", "will", "not", "aim", "for", "the", "head" };<br>
>>> std::vector<size_t> lengths;<br>
>>><br>
>>> std::transform(pray.begin(), pray.end(), std::back_inserter(lengths), std::mem_fn(&std::string::size));<br>
<br>
</div>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.<br>
<div class="im"><br>
> I believe this is due to a poor interaction in the compiler between extern templates and __attribute__ ((__always_inline__)). If std::string is not declared extern template, then the compiler will outline a size() member and you won't get this link error.<br>
<br>
</div>always_inline doesn't stop the dylib from exporting that function symbol. It's the hidden visibility that does that.<br>
<div class="im"><br>
> In my opinion, clang should not assume that extern templates have definitions for inlined members, especially those marked always_inline, and the fact that it does is a clang bug resulting in the link error you see.<br>
<br>
</div>Every member of a class template is implicitly inline. We are not going to completely break explicit instantiation declarations.<br>
<br>
We do already treat always_inline as a special case, and I'm not sure why it's not applying here. That does seem like a bug.<br>
<div class="im"><br>
> 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.<br>
<br>
</div>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++.<br>
<br>
Have you considered only explicitly instantiating the functions you actually want to show up in the library instead of explicitly instantiating the entire class?<br>
<span class="HOEnZb"><font color="#888888"><br>
John.<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><font face="georgia, serif"><font color="#999999">Best regards,</font></font><div><font face="georgia, serif"><font color="#999999">Alexey Kudinkin.</font></font></div>
</div>