<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-2723629833377820389m_-1287341096313284757WordSection1"><span><div><br>
</div>
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What kind of static asserts? Can you provide an example? </blockquote><p class="MsoNormal"><u></u></p>
</div>
</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">What I had in mind here was for the first line of inplace_merge (and other allocating algorithms) to be something along the lines of static_assert(!_LIBCPP_HAS_NO_<wbr>ALLOC). 
 I think you had a much better suggestion though…</span></p></div></div></blockquote><div><br></div><div>The algorithms all use std::get_temporary_buffer to allocate memory, and IIRC all of the algorithms should still work if std::get_temporary_buffer returns no additional memory. In this particular case I think it would be better to patch get_temporary_buffer and leave the algorithms as-is.</div><div><br></div><div>All other allocation cases that need static_assert should be handled by the std::allocation suggestion.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-2723629833377820389m_-1287341096313284757WordSection1"><span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u></span></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div style="border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 4.0pt">
<p class="MsoNormal">>> * I'll also need to figure out how to not drag along unwanted header dependencies.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">> I don't see how libc++ could upstream changes since it requires every header<u></u><u></u></p>
<p class="MsoNormal">> it currently includes (modulo bugs).<u></u><u></u></p>
</div>
<p class="MsoNormal">The straightforward (and labor intensive) way is with #ifdef _LIBCPP_HAS_NO_ALLOC<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">_LIBCPP_HAS_NO_ALLOC is exactly the invasive change I wanted to avoid. First <new> is currently a freestanding header,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">and I think it should stay that way. Second I want to avoid the maintenance cost of such a restrictive<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">configuration. This macro would have to guard the the vast majority of the library, unlike<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">_LIBCPP_HAS_EXCEPTIONS and _LIBCPP_NO_RTTI which have a much smaller and more manageable scope.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">If the end goal is simply to diagnose when end users use features that dynamically allocate I suspect there<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">are less invasive ways to do it. First there are two important things to note:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">(1) Libc++ has very few naked new/delete calls. Almost all dynamic allocations go through std::allocator.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">(2) std::allocator is typically used in dependent contexts (templates). <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Instead of #ifdef'ing out std::allocator and everything that uses it, we could make instantiating std::allocator::allocate<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">produce a diagnostic. This would make the changes needed within libc++ significantly smaller while still<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">producing reasonable diagnostics when users attempt to use those types.<u></u><u></u></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Putting a static assert (or some other kind of diagnostic) in std::allocator::allocate seems like an excellent idea to me.  I’d also want to hunt down the other places where
 raw new is used, but I think this approach has a lot of promise.  </span></p></div></div></blockquote><div><br></div><div>I think most usages of raw new could be made to use std::allocator instead, so they wouldn't have to be handled separately. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-2723629833377820389m_-1287341096313284757WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We can document what we officially support, but say that other things might work.  If someone instantiates code that hits std::allocator, they will get a static assert.  If they write their
 own code that calls new or delete, they will get a linker error (in the Windows Kernel at least). </span></p></div></div></blockquote><div><br></div><div>If me manage to make libc++ always use std::allocator instead of raw new then it might be feasible to mark the new/delete definitions as unavailable, since they would only have one caller internally. This would allow usages to be diagnosed at compile-time instead of link-time. It would also ensure that replacement definitions of new/delete are not found at link time.</div><div> </div></div><br></div></div>