<div dir="auto"><div style="font-family:sans-serif" dir="auto">IMO, it is a mistake to be attempting to provide a c++11 standard library without the c++11 language, and we'd be better off *removing* those types that cannot be implemented in c++03 (and are thus currently implemented incompatibly or incorrectly) from libcxx's c++03 mode, rather than fixing them.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 10, 2019, 9:27 PM JF Bastien via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org">libcxx-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Jun 10, 2019, at 6:10 PM, Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank" rel="noreferrer">eric@efcs.ca</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Yes, fixing these ABI bugs would require an ABI change. I don't know of ABI bugs in standard C++03 components,<div><br></div><div>I'm not sure how many users actually depend on our C++11 extensions in C++03. Or how many of those people mix</div><div>different C++ dialects in the same binary.</div><div><br></div><div>My sense is that having a different ABI between C++11 and C++03 is worse than breaking ABI compatibility once to fix that.</div><div><br></div><div><div>In the case of  `std::function::operator()(...)`, the  C++03 implementation passes rvalues across the type-erasure boundary</div><div>by value, C++11 passes by rvalue reference. If both versions of the vtable appear in your program than you've got problems. </div><div><br></div><div><div>It's less clear if  deleting <__nullptr> emulation is as palatable for all parties. I could imagine a user writing a declaration</div></div></div><div>that contains `std::nullptr_t` in the mangling.</div></div></div></blockquote><div><br></div><div><br></div><div>Ok thanks, that answers one of my questions: the C++03 extensions would break ABI. Would your suggested change affect compliant C++03 ABI?</div><div><br></div><div>Breaking extensions seems less bad... but it’s reminiscent of the std::experimental discussion: what expectations have we given developers when using extensions? If we break ABI on just extensions, can we diagnose the breakage? Or just drop the extension (maybe keep it behind a flag, deprecate, etc)?</div><div><br></div><div>Sorry for asking so many questions! In general I agree that shedding burden is useful, but I want to understand the caveats (if any). Maybe that can inform future extensions too :)</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>/Eric</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 10, 2019 at 6:03 PM JF Bastien <<a href="mailto:jfbastien@apple.com" target="_blank" rel="noreferrer">jfbastien@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div><br><blockquote type="cite"><div>On Jun 10, 2019, at 1:37 PM, Eric Fiselier via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank" rel="noreferrer">libcxx-dev@lists.llvm.org</a>> wrote:</div><br class="m_6498239295485774710gmail-m_-1720169299865068893Apple-interchange-newline"><div><div dir="ltr"><div class="m_6498239295485774710gmail-m_-1720169299865068893gmail-gs" style="margin:0px;padding:0px 0px 20px;width:1264px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:inherit"><div class="m_6498239295485774710gmail-m_-1720169299865068893gmail-"><div id="m_6498239295485774710gmail-m_-1720169299865068893gmail-:178" class="m_6498239295485774710gmail-m_-1720169299865068893gmail-gt m_6498239295485774710gmail-m_-1720169299865068893gmail-ii" style="font-size:12.8px;direction:ltr;margin:8px 0px 0px;padding:0px"><div id="m_6498239295485774710gmail-m_-1720169299865068893gmail-:177" class="m_6498239295485774710gmail-m_-1720169299865068893gmail-a3s m_6498239295485774710gmail-m_-1720169299865068893gmail-aXjCH" style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif"><div dir="ltr"><div class="m_6498239295485774710gmail-m_-1720169299865068893gmail-gs" style="margin:0px;padding:0px 0px 20px;width:1272px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:12px"><div class="m_6498239295485774710gmail-m_-1720169299865068893gmail-"><div id="m_6498239295485774710gmail-m_-1720169299865068893gmail-:11u" class="m_6498239295485774710gmail-m_-1720169299865068893gmail-gt m_6498239295485774710gmail-m_-1720169299865068893gmail-ii" style="font-size:12.8px;direction:ltr;margin:8px 0px 0px;padding:0px"><div id="m_6498239295485774710gmail-m_-1720169299865068893gmail-:11v" class="m_6498239295485774710gmail-m_-1720169299865068893gmail-a3s m_6498239295485774710gmail-m_-1720169299865068893gmail-aXjCH" style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif"><div dir="ltr"><div><span style="font-family:"Lucida Grande","Lucida Sans Unicode",Arial,Verdana,Helvetica,sans-serif">Hello,</span></div><div><span style="font-family:"Lucida Grande","Lucida Sans Unicode",Arial,Verdana,Helvetica,sans-serif"><br></span></div><div><span style="font-family:"Lucida Grande","Lucida Sans Unicode",Arial,Verdana,Helvetica,sans-serif">libc++ claims to support GCC with C++03 ("G++03"), and this is a problem for our users.</span></div><div><br></div><div><font face="Lucida Grande, Lucida Sans Unicode, Arial, Verdana, Helvetica, sans-serif">Our C++03 users are all using Clang. They must be.</font><span style="font-family:"Lucida Grande","Lucida Sans Unicode",Arial,Verdana,Helvetica,sans-serif">  Less than 9% of the C++03 tests pass with GCC [1][2]. No non-trivial C++ program could work.</span><br></div><div><br></div><div><span style="font-family:"Lucida Grande","Lucida Sans Unicode",Arial,Verdana,Helvetica,sans-serif">Attempting to support G++03 impacts our QoI considerably. Unlike Clang, G++03 offers almost no C++11 extensions. If we could remove all the fallbacks for G++03, it would mean libc++ could::</span></div><div><span style="font-family:"Lucida Grande","Lucida Sans Unicode",Arial,Verdana,Helvetica,sans-serif"><br></span></div><div><div>* Improve Correctness:</div></div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>Every `#ifdef _LIBCPP_HAS_NO_<C++11-feature>` is a bug manifest. It exists to admit for deviant semantics.</div></div><div><br></div></blockquote><div><div>* Achieve ABI stability between C++03 and C++11</div></div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>Differences between our C++03 and C++Rest branches contain ABI bugs. For example `std::nullptr_t` and `std::function::operator()(...)` are currently incompatible between C++11 and C++03, but could be fixed.</div></div></blockquote></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div><br></div><div>Would we break ABI of C++03 using clang as a compiler? Would we only do so for STL features which aren’t actually part of C++03 anyways?</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="m_6498239295485774710gmail-m_-1720169299865068893gmail-gs" style="margin:0px;padding:0px 0px 20px;width:1264px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:inherit"><div class="m_6498239295485774710gmail-m_-1720169299865068893gmail-"><div id="m_6498239295485774710gmail-m_-1720169299865068893gmail-:178" class="m_6498239295485774710gmail-m_-1720169299865068893gmail-gt m_6498239295485774710gmail-m_-1720169299865068893gmail-ii" style="font-size:12.8px;direction:ltr;margin:8px 0px 0px;padding:0px"><div id="m_6498239295485774710gmail-m_-1720169299865068893gmail-:177" class="m_6498239295485774710gmail-m_-1720169299865068893gmail-a3s m_6498239295485774710gmail-m_-1720169299865068893gmail-aXjCH" style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif"><div dir="ltr"><div class="m_6498239295485774710gmail-m_-1720169299865068893gmail-gs" style="margin:0px;padding:0px 0px 20px;width:1272px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:12px"><div class="m_6498239295485774710gmail-m_-1720169299865068893gmail-"><div id="m_6498239295485774710gmail-m_-1720169299865068893gmail-:11u" class="m_6498239295485774710gmail-m_-1720169299865068893gmail-gt m_6498239295485774710gmail-m_-1720169299865068893gmail-ii" style="font-size:12.8px;direction:ltr;margin:8px 0px 0px;padding:0px"><div id="m_6498239295485774710gmail-m_-1720169299865068893gmail-:11v" class="m_6498239295485774710gmail-m_-1720169299865068893gmail-a3s m_6498239295485774710gmail-m_-1720169299865068893gmail-aXjCH" style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif"><div dir="ltr">* Decrease Compile Times and Memory Usage:<div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><br></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">Writing efficient SFINAE requires C++11. Using alias templates, libc++ could reduce the number of instantiations it produces substantially.<br><br></blockquote>* Decrease Binary Size</div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><br></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Similar to the last point, G++03 forces metaprogramming techniques that emit more debug information [3] [4]. Compared to libstdc++, debug information size increases of +10% are not uncommon.</div></blockquote><br></div><div>I would like the communities blessing to officially unsupport GCC in C++03 in the 9.0 release.</div><div><br></div><div>/Eric</div><div><div><div><div><br></div><div>[1] <a href="https://gist.github.com/EricWF/83b352471c999655859f75f60c9061a8" target="_blank" rel="noreferrer">https://gist.github.com/EricWF/83b352471c999655859f75f60c9061a8</a></div></div></div></div><div>[2] Clang and GCC are our only "supported" C++03 compilers. MSVC and XLC don't support C++03, we don't support ILC.</div><div>[3] G++03 disallows default template parameters, so SFINAE must be written as default function parameters. Function parameters create live variables, live variables force debug info emission for their type, which emits debug information for the SFINAE construct.</div><div>[4] Unlike C++03 metafunctions written with normal class templates, C++11 alias templates aren't instantiated at every use.</div></div><div class="m_6498239295485774710gmail-m_-1720169299865068893gmail-yj6qo"></div><div class="m_6498239295485774710gmail-m_-1720169299865068893gmail-adL"></div></div></div><div class="m_6498239295485774710gmail-m_-1720169299865068893gmail-hi" style="border-bottom-left-radius:1px;border-bottom-right-radius:1px;padding:0px;width:auto;background:rgb(242,242,242);margin:0px"></div></div></div><br><br class="m_6498239295485774710gmail-m_-1720169299865068893gmail-Apple-interchange-newline"></div></div></div></div></div></div>
_______________________________________________<br>libcxx-dev mailing list<br><a href="mailto:libcxx-dev@lists.llvm.org" target="_blank" rel="noreferrer">libcxx-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev" target="_blank" rel="noreferrer">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a><br></div></blockquote></div><br></div></blockquote></div>
</div></blockquote></div>_______________________________________________<br>
libcxx-dev mailing list<br>
<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank" rel="noreferrer">libcxx-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a><br>
</blockquote></div>