220 19152 article Path: news.gmane.org!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: New type of "new"/"delete" override Date: Tue, 21 Jul 2015 14:24:06 -0700 Lines: 390 Approved: news@gmane.org Message-ID: References: <2328a5fd-924c-4d02-ac18-6a225f786dec@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec52d52dd2feea4051b69467a X-Trace: ger.gmane.org 1437513868 26069 80.91.229.3 (21 Jul 2015 21:24:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Jul 2015 21:24:28 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDVNBJG4YAIBB57QXKWQKGQEY6IYUYA@isocpp.org Tue Jul 21 23:24:12 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f200.google.com ([209.85.220.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZHf1E-0004M1-LD for gclcip-std-proposals@m.gmane.org; Tue, 21 Jul 2015 23:24:08 +0200 Original-Received: by qkez4 with SMTP id z4sf295496250qke.2 for ; Tue, 21 Jul 2015 14:24:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=3x/zEk3sLVd8KwtWOmDuMYd6g/KoUCqapYEyqmlyNnI=; b=MqT0m4aVTrSHYH+NPpf3s0GEPOmBgV36IjOigib+yGVGBuLHSnI3TgOGOqcFeJDLIw WqGfRW0W07oL9Fpmy6zlcD0VxhGAR6tdKo+p+weIY5DeASpshahRUb/HZlX625O/eF0d rUenPeOFFlAxTUhBzinUL5U/C/EPFyhs/4h26FbGKGJ0gXW9r2X/qMILQDtAL5FLyQ40 eWclLuWraZ1Ck5w68N3pNsRq3BXRdmeMI6kQbRjaGHv88iSxr3MG50JQNVN1BdDbwnW5 hRD3VtJqQtR3uThHNUWFh7rvOLbEqNP7uaCojVw0CgdJWGp6d1dxOJDKAe6wmty5qgbO JsJQ== X-Gm-Message-State: ALoCoQlrdkP0LevbAWfiUUYXUKH6bSAGGmg0XAhXTInmyzHtgJTsW+f7C0wDFq3Vt1hUSVMVKRff X-Received: by 10.140.151.65 with SMTP id 62mr36660565qhx.1.1437513847876; Tue, 21 Jul 2015 14:24:07 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.92.10 with SMTP id a10ls4180367qge.94.gmail; Tue, 21 Jul 2015 14:24:06 -0700 (PDT) X-Received: by 10.52.244.40 with SMTP id xd8mr45464540vdc.2.1437513846762; Tue, 21 Jul 2015 14:24:06 -0700 (PDT) Original-Received: from mail-vn0-x236.google.com (mail-vn0-x236.google.com. [2607:f8b0:400c:c0f::236]) by mx.google.com with ESMTPS id xw1si25331894vdb.28.2015.07.21.14.24.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2015 14:24:06 -0700 (PDT) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c0f::236 as permitted sender) client-ip=2607:f8b0:400c:c0f::236; Original-Received: by vnav141 with SMTP id v141so41026169vna.0 for ; Tue, 21 Jul 2015 14:24:06 -0700 (PDT) X-Received: by 10.52.135.4 with SMTP id po4mr45355034vdb.78.1437513846613; Tue, 21 Jul 2015 14:24:06 -0700 (PDT) Original-Sender: metafoo@gmail.com Original-Received: by 10.31.75.2 with HTTP; Tue, 21 Jul 2015 14:24:06 -0700 (PDT) In-Reply-To: <2328a5fd-924c-4d02-ac18-6a225f786dec@isocpp.org> X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c0f::236 as permitted sender) smtp.mail=metafoo@gmail.com; dkim=pass header.i=@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:19152 Archived-At: --bcaec52d52dd2feea4051b69467a Content-Type: text/plain; charset=UTF-8 On Tue, Jul 21, 2015 at 12:37 PM, Myriachan wrote: > In trying to implement a custom memory allocator, there are many > annoyances that come up that make C++ difficult to work with. > Particularly, the syntax of the new and delete operators means that using > a custom memory allocator often involves macros that are semantically > different from new and delete. > Can you explain a bit more about the problem? It's really not clear to me what the motivation for this change is. Why can't you / don't you want to use a custom placement operator new for this? > When private and protected constructors and destructors get involved, > things get especially annoying, because the allocator code can't call the > constructor or destructor itself. > > I thought of an idea that would help with this issue, though it is > admittedly rather crazy. > > I would add a new type of operator new overload: > > template > Type *operator new valloc_new(const Constructor &constructor) > noexcept(noexcept(constructor(static_cast(nullptr)))) > { > static_assert(alignof(Type) <= PAGE_SIZE, "only allocations of > alignment PAGE_SIZE or less are supported") ; > > std::size_t headerSize = 0; > > // Custom implementations aren't required to use new_handlers > void *memory = VirtualAlloc(nullptr, headerSize + sizeof(Type), > MEM_COMMIT, PAGE_READWRITE); > if (!memory) > { > throw std::bad_alloc("out of memory"); > } > > try > { > return constructor(memory); > } > catch (...) > { > VirtualFree(memory, 0, MEM_RELEASE); > throw; > } > } > > template > void operator delete valloc_delete(Type *object, const Destructor & > destructor) > { > if (object == nullptr) > { > return; > } > > // Get the base address of the most-derived object > void *memory = const_cast *>(object); > if (std::is_polymorphic::value) > { > memory = dynamic_cast(const_cast > *>(object)); > } > > destructor(object); > > VirtualFree(memory, 0, MEM_RELEASE); > } > > > > Now valloc_new and valloc_delete in the proper scope will syntactically > function the same way as the new and delete keywords, in a way becoming > keywords themselves. I think that it would be worthwhile to allow these to > be scoped to namespaces or classes. > > The private constructor/destructor problem is solved, because they are > passed in as lambdas (or function pointers, at implementation discretion). > > We can redefine the basic implementation of the "new" keyword to be an > implementation-defined template function that calls ::operator new(size_t) > and does other things, like dynamic_cast if the type is > polymorphic. Overriding the global new would work by replacing this > template or its overloads. > > template > Type *operator new new(const Constructor &constructor, Args &&...args) > noexcept( > noexcept(constructor(static_cast(nullptr))) && > noexcept(::operator new(std::size_t(), std::forward(args > )...))); > > > Melissa > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > Visit this group at > http://groups.google.com/a/isocpp.org/group/std-proposals/. > -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --bcaec52d52dd2feea4051b69467a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 21, 2015 at 12:37 PM, Myriachan <myriachan@gmail.com> wrote:
In trying to = implement a custom memory allocator, there are many annoyances that come up= that make C++ difficult to work with.=C2=A0 Particularly, the syntax of th= e new and delete operators means tha= t using a custom memory allocator often involves macros that are semantical= ly different from new and delete.

Can you explain a bit more about the pr= oblem? It's really not clear to me what the motivation for this change = is. Why can't you / don't you want to use a custom placement operat= or new for this?
=C2=A0
When private and protected constructors and destructors get inv= olved, things get especially annoying, because the allocator code can't= call the constructor or destructor itself.

I thought of an idea tha= t would help with this issue, though it is admittedly rather crazy.

= I would add a new type of operator new overload:

template <= typename Type,= typename Constructor= >Type <= /span>*operato= r new valloc_new(const Constructor &constructor)
=C2=A0 =C2=A0 noexcept(noexcept(constructor(static_cast<Type *>(nullptr))))
{
=C2=A0 =C2=A0 static_assert= (aligno= f(Type<= /span>) <=3D PAGE_= SIZE, <= /span>"only allocations of alignment PAGE_S= IZE or less are supported") ;

=C2=A0 =C2=A0 std::size_t headerSize =3D 0;

=C2=A0 =C2=A0 // Custo= m implementations aren't required to use new_handlers
=C2=A0 =C2=A0 void *<= span style=3D"color:#000">memory =3D VirtualAllo= c(nullp= tr, hea= derSize + sizeof(Type= ), MEM_COMMIT, PAGE_READWRITE);
=C2=A0 =C2=A0 if (!memory<= span style=3D"color:#660">)
=C2=A0 =C2= =A0 {=C2=A0 =C2=A0 =C2=A0 =C2=A0 throw std::= bad_alloc("out of memory");
=C2=A0 =C2=A0 }

=C2= =A0 =C2=A0 try
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return constructor(memory);
=C2=A0 =C2=A0 = }
= =C2=A0 =C2=A0 catch (...)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 VirtualFree(memory, 0, MEM_RELEASE);
=C2=A0 =C2=A0= =C2=A0 =C2=A0 throw;
=C2=A0 =C2=A0 }
}

template = <typename Type, typename = Destructor>=
voi= d opera= tor del= ete valloc_delete(Type *object, const Destructor &destructor)
{
=C2=A0 =C2=A0 if (object =3D=3D nullptr)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return;
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 // Get the base address of the most-derived object
=C2=A0 =C2=A0 v= oid *memory = =3D con= st_cast<std::remove_cv_t<Type> *>(object);
=C2=A0 =C2=A0 if (std::is_polymorphic<Type>::value)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = memory =3D dynamic_cast<void *>(const_cast<std::remove_cv_t<Type> *>(object));=
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 destructor(object);

= =C2=A0 =C2=A0 VirtualFree(memory, 0, MEM_RELEASE);
}
=



Now val= loc_new and valloc= _delete in the proper scope will syntactically function the same way= as the new and delete keywords, in = a way becoming keywords themselves.=C2=A0 I think that it would be worthwhi= le to allow these to be scoped to namespaces or classes.

The private= constructor/destructor problem is solved, because they are passed in as la= mbdas (or function pointers, at implementation discretion).

We can r= edefine the basic implementation of the "new" keyword to be an im= plementation-defined template function that calls ::operator new(size_t) and does other thing= s, like dynamic_cast<v= oid *> if the type is polymorphic.=C2=A0 Overriding the global ne= w would work by replacing this template or its overloads.

template <typename Type, typename Constructor, typename... Args>
Type *operator new new(const Constructor &constructor, Args &&...args<= /span>)
=C2= =A0 =C2=A0 noexcept(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 noexcept(constructor(static_cast<Type *>(nullptr)))<= span style=3D"color:#000"> &&
=C2=A0 =C2=A0 =C2=A0 =C2=A0 noexcept(::operator<= /span> new(std= ::size_t(), std::forward<Args>(args<= /span>)...)));


= Melissa

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/gro= up/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--bcaec52d52dd2feea4051b69467a-- .