This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
On 19/02/16 18:56 -0300, Daniel Gutson wrote:
On Mon, Nov 16, 2015 at 3:56 PM, Pedro Alves <palves@redhat.com> wrote:On 11/10/2015 01:10 PM, Jonathan Wakely wrote:On 06/11/15 09:59 +0000, Pedro Alves wrote:On 11/06/2015 01:56 AM, Jonathan Wakely wrote:On 5 November 2015 at 23:31, Daniel GutsonThe issue is, as I understand it, to do the actual work of operator new, i.e. allocate memory. It should force us to copy most of the code of the original code of operator new, which may change on new versions of the STL, forcing us to keep updated.It can just call malloc, and the replacement operator delete can call free. That is very unlikely to need to change (which is corroborated by the fact that the default definitions in libsupc++ change very rarely).Or perhaps libsupc++ could provide the default operator new under a __default_operator_new alias or some such, so that the user-defined replacement can fallback to calling it. Likewise for op delete.That could be useful, please file an enhancement request in bugzilla if you'd like that done.I'll leave that to Daniel/Aurelio.https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69879 Please assign it to Aurelio.
Done, I will look forward to seeing some patches for the next stage 1. Thanks!
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |