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

[Howard Hinnant]

On Oct 5, 2013, at 9:25 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 
> 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.

Not positive, but I think dawn is breaking over marble-head. ;-)  I look forward to testing this.  In case it isn't apparent from my history, I live for avoiding trips to the heap. :-)

Howard