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

[Chandler Carruth]

On Sat, Oct 5, 2013 at 9:19 PM, Howard Hinnant <howard.hinnant at gmail.com>wrote:

> I must admit to not completely understanding how your path forward is any
> different from the status-quo.
>

An explicit call to operator new (array or single object) cannot be merged
with others according to N3664 (note that the wording has been tweaked in
core since that paper, but not in relevant ways). If we implement the
standard allocator's allocate function with a raw call to operator new, we
don't get the optimizations.

I'm proposing a Clang builtin which allows us to call operator new
*without* writing a new-expression, but *with* the optimization freedoms
provided by a new-expression.

This allows us to call the right operator new (ie, not the array version)
when doing a raw allocation while permitting the various optimizations.



>  And in that sense, I have absolutely no objection to it.
>

It isn't the status-quo, I'm just explaining it poorly. =] I'll keep trying.


> I do maintain that unless there is a committee change, we need to beware
> of:
>

> #include <vector>
>
> int
> main()
> {
>    std::vector<int> v;
>    v.push_back(1);
>    return v[0];
> }
>
> #include <stdio.h>
> #include <stdlib.h>
>
> void* operator new[](size_t sz)
> {
>    printf("I don't like new-array!\n");
>    abort();
>    return nullptr;
> }
>

Yes. This means that we cannot implement a raw allocation with "new
char[...]" because it calls the wrong overload. My plan is for us to
implement raw allocation with "__builtin_allocate(...)" which calls the
non-array operator new, but in a way that permits the optimizations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131005/bbc74a58/attachment.html>