[libcxx] Patch/RFC: Avoid using ::operator new in the default allocator

[Chandler Carruth]

On Wed, Sep 25, 2013 at 3:47 PM, Howard Hinnant <howard.hinnant at gmail.com>wrote:

> 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.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2158.html
>
> If we switch, I think the wrong operator new gets called, and the user can
> detect that.
>

This is... extremely frustrating then.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130925/e19101c4/attachment.html>