220 19160 article Path: news.gmane.org!not-for-mail From: Farid Mehrabi Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: New type of "new"/"delete" override Date: Wed, 22 Jul 2015 20:26:35 +0430 Lines: 481 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=001a114938b4189814051b78d32c X-Trace: ger.gmane.org 1437580639 12265 80.91.229.3 (22 Jul 2015 15:57:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jul 2015 15:57:19 +0000 (UTC) To: std-proposals Original-X-From: std-proposals+bncBC27JR6ERAOBBW72X2WQKGQEI3UDQSI@isocpp.org Wed Jul 22 17:57:18 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f69.google.com ([209.85.192.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZHwOT-0007yJ-F4 for gclcip-std-proposals@m.gmane.org; Wed, 22 Jul 2015 17:57:17 +0200 Original-Received: by qges31 with SMTP id s31sf233190151qge.3 for ; Wed, 22 Jul 2015 08:57:16 -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:in-reply-to:references:from:date :message-id:subject: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=Gigf1U7zz/FOxI6EcBzvdvS6hTEewacBdezHz6sx9Ik=; b=SPCOewlW88X5cnVrQZbyTk4Zb3CLnotkEgfBB+tYquV7bqzg6Lg+ZYDe5UjecS7XTa RmKNi6TYbaWddRRhiXirWIsUQPDGBruU7zjyUbXXxW77WlhEks8jQQmIvKenGGXeN7/F lBZ5ssU/VSNwm3nwqkVEWTLegiP6JCRwRK6evQd65wiS/3sBS3P/7UNCnDu3mKApg4ZQ rwtGzIFgD1ALAt41JBpZctGTVWjgeXPqTYmKC0wGZGPEzCXn9laKq8w1G+z5efO+VFUz BPqwUr1mTWGK1pgDjerYiqlIJLWzz/vAmhV4cxUItbmbRGkGMYxQHwYlVWnHwTe3/nWZ dFOw== X-Gm-Message-State: ALoCoQkJyO/LqaWldSbXZhi3Wv+Hm0/1GmWIw9CvAdu4N4xAIpKUwOc+yvwuPDQrAgSCPjdaZnMC X-Received: by 10.129.117.70 with SMTP id q67mr3427524ywc.57.1437580636512; Wed, 22 Jul 2015 08:57:16 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.30.200 with SMTP id d66ls457483qgd.63.gmail; Wed, 22 Jul 2015 08:57:15 -0700 (PDT) X-Received: by 10.140.20.115 with SMTP id 106mr4706168qgi.87.1437580635461; Wed, 22 Jul 2015 08:57:15 -0700 (PDT) Original-Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com. [2607:f8b0:400d:c04::22d]) by mx.google.com with ESMTPS id s32si2144771qge.75.2015.07.22.08.57.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jul 2015 08:57:15 -0700 (PDT) Received-SPF: pass (google.com: domain of farid.mehrabi@gmail.com designates 2607:f8b0:400d:c04::22d as permitted sender) client-ip=2607:f8b0:400d:c04::22d; Original-Received: by qgii95 with SMTP id i95so73652737qgi.2 for ; Wed, 22 Jul 2015 08:57:15 -0700 (PDT) X-Received: by 10.55.43.224 with SMTP id r93mr4767804qkr.24.1437580635169; Wed, 22 Jul 2015 08:57:15 -0700 (PDT) Original-Received: by 10.96.216.42 with HTTP; Wed, 22 Jul 2015 08:56:35 -0700 (PDT) In-Reply-To: <2328a5fd-924c-4d02-ac18-6a225f786dec@isocpp.org> X-Original-Sender: farid.mehrabi@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of farid.mehrabi@gmail.com designates 2607:f8b0:400d:c04::22d as permitted sender) smtp.mail=farid.mehrabi@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:19160 Archived-At: --001a114938b4189814051b78d32c Content-Type: text/plain; charset=UTF-8 none-public members can only be accesses via either a member or a subclass or a friend, so if you need to access those functions in any generic class/function you can just make the appropriate instance a friend. One good implementation can be a generic class/function forwarding to a member of its operand; thus allowing library user to control implementation throughout sub-typing(similar to new/delete): template my_ptr { template my_ptr (Args&...a): ptr{new(T::my_new()T{a...})} { ...//blah blah blah }; ~my_ptr() { ...//blah blah blah ptr->my_delete(); ptr->~T(); }; my_raw_ptr ptr; ...//blah blah blah }; No need for any new core lang feature. regards, FM. 2015-07-22 0:07 GMT+04:30 Myriachan : > 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. 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/. > -- how am I supposed to end the twisted road of your hair in such a dark night?? unless the candle of your face does shed some light upon my way!!! -- --- 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/. --001a114938b4189814051b78d32c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
none= -public members can only be accesses via either a member or a subclass or a= friend, so if you need to access those functions in any generic class/func= tion you can just make the appropriate instance a friend. One good implemen= tation can be a generic class/function forwarding to a member of its operan= d; thus allowing library user to control implementation throughout sub-typi= ng(similar to new/delete):

= template<typename T> my_ptr
{
=C2=A0 =C2=A0 =C2=A0 template<typename ...Args> my_ptr =C2=A0 (= Args&...a):
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ptr{new(T::my_new()T{a...}= )}
=C2=A0 =C2=A0= =C2=A0 {
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...//blah blah blah
=C2=A0 =C2=A0 =C2=A0 };
=
=C2=A0 =C2=A0 =C2=A0= =C2=A0
=C2=A0 = =C2=A0 =C2=A0~my_ptr()
=C2=A0 =C2=A0 =C2=A0{
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...//blah blah blah
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 ptr->my_delete();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ptr= ->~T();
=C2= =A0 =C2=A0 =C2=A0};

=C2=A0 = =C2=A0 =C2=A0my_raw_ptr<T> ptr;
=C2=A0 =C2= =A0 =C2=A0...//blah blah blah
};

No= need for any new core lang feature.

regards,
FM.

2015-07-22 0:07 GMT+04:30 Myriachan <= ;myriachan@gmail.c= om>:
In = trying to implement a custom memory allocator, there are many annoyances th= at come up that make C++ difficult to work with.=C2=A0 Particularly, the sy= ntax of the new an= d delete operators= means that using a custom memory allocator often involves macros that are = semantically different from new and delete<= /span>.=C2=A0 When private and protected constructors and destructors get i= nvolved, things get especially annoying, because the allocator code can'= ;t call the constructor or destructor itself.

I thought of an idea t= hat 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 Construct= or><= br>Type= *opera= tor new= valloc_new(const Constructor &constructor)
=C2=A0 =C2=A0 noexcept(noexcept(= constructor(static_cast<Type *>(nullptr))))
{
=C2=A0 =C2=A0 static_= assert(= alignof(Type) = <=3D= PAGE_SIZE, "only allocations of alignment = PAGE_SIZE or less are supported") ;<= span style=3D"color:#000">

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

=C2=A0 =C2=A0 // = Custom implementations aren't required to use new_handlers
=C2=A0 =C2=A0 vo= id *memory =3D= Virtua= lAlloc(= nullptr, headerSize + sizeof(Type), MEM_COMMIT, PAGE_READWRITE);
=C2=A0 =C2=A0 <= /span>if (!memory)
=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 }
<= span style=3D"color:#660">}

template <typenam= e Type<= /span>, typename Destructor&= gt;
= void op= erator = delete 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 void = *memory =3D co= nst_cast<std::remove_cv_t<Type> *>(object);
=C2=A0 =C2=A0 if<= span style=3D"color:#000"> (std::is_polymorphic<Type>::<= /span>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/.



--
how= am I supposed to end the twisted road of=C2=A0 your hair in such a dark ni= ght??
unless the candle of your face does shed some light upon my way!!!=

--

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