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

[Hal Finkel]

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

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