<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 25, 2013 at 3:47 PM, Howard Hinnant <span dir="ltr"><<a href="mailto:howard.hinnant@gmail.com" target="_blank" class="cremed">howard.hinnant@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":a02" style="overflow:hidden">Doesn't new char[n] have to call ::operator new[](n) instead of ::operator new(n)?  These two operators are separately overloadable by the client.<br>

<br>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2158.html" target="_blank" class="cremed">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2158.html</a><br>
<br>
If we switch, I think the wrong operator new gets called, and the user can detect that.</div></blockquote></div><br>This is... extremely frustrating then.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
We're unable to use the language-blessed mechanism for permitting an optimization to take advantage of a library-blessed permission for an optimization, and thus will likely have to resort to language extensions.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I think the correct fix will then become more complex and require introducing compiler builtins which call the global operator new but provide the semantic constraints of a new expression.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I also know that regardless of the solution, Marshall has thoughts on the best way to factor this within the library, but those are orthogonal.</div></div>