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

[Howard Hinnant]

On Sep 26, 2013, at 10:16 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
>> On Sep 25, 2013, at 3:33 PM, Chandler Carruth <chandlerc at google.com>
>> wrote:
>> 
>>> 
>>> On Wed, Sep 25, 2013 at 3:29 PM, Howard Hinnant
>>> <howard.hinnant at gmail.com> wrote:
>>> 20.8.9.1 [allocator.members]/p6:
>>> 
>>>> Remark: the storage is obtained by calling ::operator
>>>> new(std::size_t) (18.6.1), but it is unspec- ified when or how
>>>> often this function is called. The use of hint is unspecified,
>>>> but intended as an aid to locality if an implementation so
>>>> desires.
>>> 
>>> The question becomes, if we make this substitution, is there a test
>>> the user can write to observe it?  Is there an LWG issue here?
>>> 
>>> I *believe* that by writing a new expression, you get *precisely*
>>> this behavior: storage is obtained by calling ::operator new, but
>>> when or how often can change via the implementation (N3664).
>> 
>> 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 not a compliance problem, right? Just a backwards-compatibility problem?

No, this is a conformance issue.  Here is a HelloWorld:

#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;
}

This program should not abort according to C++98//30/11 and the current draft.  It will abort if std::allocator starts calling new char[n].

Howard

> 
> If we need a non-standard extension to make this work, maybe the following makes sense:
> 
> void *alloc(int n) {
>        typedef char foo[n];
>        foo *p = new foo;
>        return (void *) p;
> }
> 
> This does not currently compile:
> 
> error: 'new' cannot allocate object of variably modified type 'foo' (aka 'char [n]')
> 
> but enabling this to work might be less ugly than using a new builtin (on the other hand, we probably need a new builtin for doing dynarray, if there is still interest in that).
> 
> -Hal
> 
>> 
>> Howard
>> 
>> 
>> 
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits