[PATCH] Fallback to operator new for MSVC compatibility

Richard Smith richard at metafoo.co.uk
Tue May 28 17:04:22 PDT 2013


On Tue, May 28, 2013 at 4:50 PM, Aaron Ballman <aaron at aaronballman.com>wrote:

> On Tue, May 28, 2013 at 6:07 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > What does MSVC think about:
> >
> > void *operator new(unsigned int size, arbitrary_t);
> > void operator delete[](unsigned int size, arbitrary_t) = delete;
> > struct S { S(); };
> > S *p = new (arbitrary) S[5];
> >
> > ? Will it call the (deleted) operator delete[] even though it picked a
> > non-array operator new?
>
> MSVC doesn't support deleted functions as of right now, so it just errors
> out.
>
> > What if there is an array new but no array delete?
>
> struct arbitrary_t {} arbitrary;
> void *operator new(unsigned int size, arbitrary_t);
>
> void f() {
>   int *p = new(arbitrary) int[4];
>   int *p2 = new(arbitrary) int;
>
>   delete [] p;
>   delete p2;
> }
>
> Yields calls to:
>
> call ??3 at YAXPAX@Z ; operator delete
>
> for both p and p2, so it falls back on the global delete.


I don't think that answers my question, though. What I'd like to know is,
should we fall back from operator delete[] to operator delete exactly when
we fall back from operator new[] to operator new (as your patch does), or
should we perform the two fallbacks independently?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130528/e63edc6c/attachment.html>


More information about the cfe-commits mailing list