How to replace operator new/delete and not interfere with libraries?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







6















Let's say I want to add some meta information to allocated objects to track allocations/deallocations.
I learned that it's enough to replace one version of operator new and two versions of operator delete to handle all allocations since C++11.



Here's what I've written:



#include <cstdlib>
#include <FreeImage.h>

#include <new>
#include <iostream>

void *operator new(size_t size)
{
std::cout << "allocation of size " << size << 'n';
void *allocated = malloc(size + sizeof(size_t));
*reinterpret_cast<size_t *>(allocated) = size;
return reinterpret_cast<void *>(reinterpret_cast<size_t *>(allocated) + 1);
}

void _delete(void *ptr) {
void *allocated = reinterpret_cast<void *>(reinterpret_cast<size_t *>(ptr) - 1);
size_t size = *reinterpret_cast<size_t *>(allocated);
std::cout << "deallocation of size " << size << 'n';
free(allocated);
}

void operator delete(void *ptr) noexcept
{
_delete(ptr);
}

void operator delete(void *ptr, std::align_val_t al) noexcept
{
_delete(ptr);
}

int main()
{
auto str = new char[1337];
delete str;
FreeImage_Initialise();
}

// compiled with `g++ -std=c++17 reproduce.cpp -lfreeimage`


This program works if I don't use any third-party functions, but fails if I do.



The program crash with free(): invalid pointer and gdb says it fails inside of _delete which, I guess, means that something was allocated with standard allocator, but was freed with my own.



GDB output:



(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff79a9535 in __GI_abort () at abort.c:79
#2 0x00007ffff7a10516 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7b34c00 "%sn") at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff7a173aa in malloc_printerr (str=str@entry=0x7ffff7b32d85 "free(): invalid pointer") at malloc.c:5336
#4 0x00007ffff7a191fc in _int_free (av=<optimized out>, p=<optimized out>, have_lock=<optimized out>) at malloc.c:4143
#5 0x00005555555552e8 in _delete(void*) ()
#6 0x0000555555555303 in operator delete(void*) ()
#7 0x00007ffff7d7edc2 in ?? () from /usr/lib/x86_64-linux-gnu/libfreeimage.so.3
#8 0x00007ffff79cba77 in __cxa_finalize (d=0x7ffff7fa0000) at cxa_finalize.c:83
#9 0x00007ffff7d17003 in ?? () from /usr/lib/x86_64-linux-gnu/libfreeimage.so.3
#10 0x00007fffffffdec0 in ?? ()
#11 0x00007ffff7fe3d16 in _dl_fini () at dl-fini.c:138


So the question: How to replace new/delete properly?










share|improve this question




















  • 2





    All identifiers that begin with an underscore in the global namespace are reserved and can't be used. _delete violates that. It might not be the cause of your problem but it would be best to fix it and eliminate it as a possible cause. Edit : You can find a list of restricted identifiers here.

    – François Andrieux
    Jan 4 at 18:37








  • 2





    SUGGESTION: print out the addresses returned by malloc() and passed to free(), to verify they're correct. And I agree: "_delete()" is an unwise choice of names :(

    – paulsm4
    Jan 4 at 18:40













  • objcopy the library and substitute standard names for new and delete for new ones. Provide them in your translation unit. Overwrite the defaults in another. Link. There is no other option - you need to substitute the function names in the library code.

    – Kamil Cuk
    Jan 4 at 18:42











  • Strictly speaking you should be using placement new to write the size into the extra allocated memory.

    – François Andrieux
    Jan 4 at 18:44











  • Thank you for pointing out _delete, but even if I rename it to something like my_delete it behaves the same.

    – Yegor Tyuvaev
    Jan 4 at 18:47




















6















Let's say I want to add some meta information to allocated objects to track allocations/deallocations.
I learned that it's enough to replace one version of operator new and two versions of operator delete to handle all allocations since C++11.



Here's what I've written:



#include <cstdlib>
#include <FreeImage.h>

#include <new>
#include <iostream>

void *operator new(size_t size)
{
std::cout << "allocation of size " << size << 'n';
void *allocated = malloc(size + sizeof(size_t));
*reinterpret_cast<size_t *>(allocated) = size;
return reinterpret_cast<void *>(reinterpret_cast<size_t *>(allocated) + 1);
}

void _delete(void *ptr) {
void *allocated = reinterpret_cast<void *>(reinterpret_cast<size_t *>(ptr) - 1);
size_t size = *reinterpret_cast<size_t *>(allocated);
std::cout << "deallocation of size " << size << 'n';
free(allocated);
}

void operator delete(void *ptr) noexcept
{
_delete(ptr);
}

void operator delete(void *ptr, std::align_val_t al) noexcept
{
_delete(ptr);
}

int main()
{
auto str = new char[1337];
delete str;
FreeImage_Initialise();
}

// compiled with `g++ -std=c++17 reproduce.cpp -lfreeimage`


This program works if I don't use any third-party functions, but fails if I do.



The program crash with free(): invalid pointer and gdb says it fails inside of _delete which, I guess, means that something was allocated with standard allocator, but was freed with my own.



GDB output:



(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff79a9535 in __GI_abort () at abort.c:79
#2 0x00007ffff7a10516 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7b34c00 "%sn") at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff7a173aa in malloc_printerr (str=str@entry=0x7ffff7b32d85 "free(): invalid pointer") at malloc.c:5336
#4 0x00007ffff7a191fc in _int_free (av=<optimized out>, p=<optimized out>, have_lock=<optimized out>) at malloc.c:4143
#5 0x00005555555552e8 in _delete(void*) ()
#6 0x0000555555555303 in operator delete(void*) ()
#7 0x00007ffff7d7edc2 in ?? () from /usr/lib/x86_64-linux-gnu/libfreeimage.so.3
#8 0x00007ffff79cba77 in __cxa_finalize (d=0x7ffff7fa0000) at cxa_finalize.c:83
#9 0x00007ffff7d17003 in ?? () from /usr/lib/x86_64-linux-gnu/libfreeimage.so.3
#10 0x00007fffffffdec0 in ?? ()
#11 0x00007ffff7fe3d16 in _dl_fini () at dl-fini.c:138


So the question: How to replace new/delete properly?










share|improve this question




















  • 2





    All identifiers that begin with an underscore in the global namespace are reserved and can't be used. _delete violates that. It might not be the cause of your problem but it would be best to fix it and eliminate it as a possible cause. Edit : You can find a list of restricted identifiers here.

    – François Andrieux
    Jan 4 at 18:37








  • 2





    SUGGESTION: print out the addresses returned by malloc() and passed to free(), to verify they're correct. And I agree: "_delete()" is an unwise choice of names :(

    – paulsm4
    Jan 4 at 18:40













  • objcopy the library and substitute standard names for new and delete for new ones. Provide them in your translation unit. Overwrite the defaults in another. Link. There is no other option - you need to substitute the function names in the library code.

    – Kamil Cuk
    Jan 4 at 18:42











  • Strictly speaking you should be using placement new to write the size into the extra allocated memory.

    – François Andrieux
    Jan 4 at 18:44











  • Thank you for pointing out _delete, but even if I rename it to something like my_delete it behaves the same.

    – Yegor Tyuvaev
    Jan 4 at 18:47
















6












6








6








Let's say I want to add some meta information to allocated objects to track allocations/deallocations.
I learned that it's enough to replace one version of operator new and two versions of operator delete to handle all allocations since C++11.



Here's what I've written:



#include <cstdlib>
#include <FreeImage.h>

#include <new>
#include <iostream>

void *operator new(size_t size)
{
std::cout << "allocation of size " << size << 'n';
void *allocated = malloc(size + sizeof(size_t));
*reinterpret_cast<size_t *>(allocated) = size;
return reinterpret_cast<void *>(reinterpret_cast<size_t *>(allocated) + 1);
}

void _delete(void *ptr) {
void *allocated = reinterpret_cast<void *>(reinterpret_cast<size_t *>(ptr) - 1);
size_t size = *reinterpret_cast<size_t *>(allocated);
std::cout << "deallocation of size " << size << 'n';
free(allocated);
}

void operator delete(void *ptr) noexcept
{
_delete(ptr);
}

void operator delete(void *ptr, std::align_val_t al) noexcept
{
_delete(ptr);
}

int main()
{
auto str = new char[1337];
delete str;
FreeImage_Initialise();
}

// compiled with `g++ -std=c++17 reproduce.cpp -lfreeimage`


This program works if I don't use any third-party functions, but fails if I do.



The program crash with free(): invalid pointer and gdb says it fails inside of _delete which, I guess, means that something was allocated with standard allocator, but was freed with my own.



GDB output:



(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff79a9535 in __GI_abort () at abort.c:79
#2 0x00007ffff7a10516 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7b34c00 "%sn") at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff7a173aa in malloc_printerr (str=str@entry=0x7ffff7b32d85 "free(): invalid pointer") at malloc.c:5336
#4 0x00007ffff7a191fc in _int_free (av=<optimized out>, p=<optimized out>, have_lock=<optimized out>) at malloc.c:4143
#5 0x00005555555552e8 in _delete(void*) ()
#6 0x0000555555555303 in operator delete(void*) ()
#7 0x00007ffff7d7edc2 in ?? () from /usr/lib/x86_64-linux-gnu/libfreeimage.so.3
#8 0x00007ffff79cba77 in __cxa_finalize (d=0x7ffff7fa0000) at cxa_finalize.c:83
#9 0x00007ffff7d17003 in ?? () from /usr/lib/x86_64-linux-gnu/libfreeimage.so.3
#10 0x00007fffffffdec0 in ?? ()
#11 0x00007ffff7fe3d16 in _dl_fini () at dl-fini.c:138


So the question: How to replace new/delete properly?










share|improve this question
















Let's say I want to add some meta information to allocated objects to track allocations/deallocations.
I learned that it's enough to replace one version of operator new and two versions of operator delete to handle all allocations since C++11.



Here's what I've written:



#include <cstdlib>
#include <FreeImage.h>

#include <new>
#include <iostream>

void *operator new(size_t size)
{
std::cout << "allocation of size " << size << 'n';
void *allocated = malloc(size + sizeof(size_t));
*reinterpret_cast<size_t *>(allocated) = size;
return reinterpret_cast<void *>(reinterpret_cast<size_t *>(allocated) + 1);
}

void _delete(void *ptr) {
void *allocated = reinterpret_cast<void *>(reinterpret_cast<size_t *>(ptr) - 1);
size_t size = *reinterpret_cast<size_t *>(allocated);
std::cout << "deallocation of size " << size << 'n';
free(allocated);
}

void operator delete(void *ptr) noexcept
{
_delete(ptr);
}

void operator delete(void *ptr, std::align_val_t al) noexcept
{
_delete(ptr);
}

int main()
{
auto str = new char[1337];
delete str;
FreeImage_Initialise();
}

// compiled with `g++ -std=c++17 reproduce.cpp -lfreeimage`


This program works if I don't use any third-party functions, but fails if I do.



The program crash with free(): invalid pointer and gdb says it fails inside of _delete which, I guess, means that something was allocated with standard allocator, but was freed with my own.



GDB output:



(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff79a9535 in __GI_abort () at abort.c:79
#2 0x00007ffff7a10516 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7b34c00 "%sn") at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff7a173aa in malloc_printerr (str=str@entry=0x7ffff7b32d85 "free(): invalid pointer") at malloc.c:5336
#4 0x00007ffff7a191fc in _int_free (av=<optimized out>, p=<optimized out>, have_lock=<optimized out>) at malloc.c:4143
#5 0x00005555555552e8 in _delete(void*) ()
#6 0x0000555555555303 in operator delete(void*) ()
#7 0x00007ffff7d7edc2 in ?? () from /usr/lib/x86_64-linux-gnu/libfreeimage.so.3
#8 0x00007ffff79cba77 in __cxa_finalize (d=0x7ffff7fa0000) at cxa_finalize.c:83
#9 0x00007ffff7d17003 in ?? () from /usr/lib/x86_64-linux-gnu/libfreeimage.so.3
#10 0x00007fffffffdec0 in ?? ()
#11 0x00007ffff7fe3d16 in _dl_fini () at dl-fini.c:138


So the question: How to replace new/delete properly?







c++ linux






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 4 at 18:38









John Kugelman

249k54407460




249k54407460










asked Jan 4 at 18:34









Yegor TyuvaevYegor Tyuvaev

513




513








  • 2





    All identifiers that begin with an underscore in the global namespace are reserved and can't be used. _delete violates that. It might not be the cause of your problem but it would be best to fix it and eliminate it as a possible cause. Edit : You can find a list of restricted identifiers here.

    – François Andrieux
    Jan 4 at 18:37








  • 2





    SUGGESTION: print out the addresses returned by malloc() and passed to free(), to verify they're correct. And I agree: "_delete()" is an unwise choice of names :(

    – paulsm4
    Jan 4 at 18:40













  • objcopy the library and substitute standard names for new and delete for new ones. Provide them in your translation unit. Overwrite the defaults in another. Link. There is no other option - you need to substitute the function names in the library code.

    – Kamil Cuk
    Jan 4 at 18:42











  • Strictly speaking you should be using placement new to write the size into the extra allocated memory.

    – François Andrieux
    Jan 4 at 18:44











  • Thank you for pointing out _delete, but even if I rename it to something like my_delete it behaves the same.

    – Yegor Tyuvaev
    Jan 4 at 18:47
















  • 2





    All identifiers that begin with an underscore in the global namespace are reserved and can't be used. _delete violates that. It might not be the cause of your problem but it would be best to fix it and eliminate it as a possible cause. Edit : You can find a list of restricted identifiers here.

    – François Andrieux
    Jan 4 at 18:37








  • 2





    SUGGESTION: print out the addresses returned by malloc() and passed to free(), to verify they're correct. And I agree: "_delete()" is an unwise choice of names :(

    – paulsm4
    Jan 4 at 18:40













  • objcopy the library and substitute standard names for new and delete for new ones. Provide them in your translation unit. Overwrite the defaults in another. Link. There is no other option - you need to substitute the function names in the library code.

    – Kamil Cuk
    Jan 4 at 18:42











  • Strictly speaking you should be using placement new to write the size into the extra allocated memory.

    – François Andrieux
    Jan 4 at 18:44











  • Thank you for pointing out _delete, but even if I rename it to something like my_delete it behaves the same.

    – Yegor Tyuvaev
    Jan 4 at 18:47










2




2





All identifiers that begin with an underscore in the global namespace are reserved and can't be used. _delete violates that. It might not be the cause of your problem but it would be best to fix it and eliminate it as a possible cause. Edit : You can find a list of restricted identifiers here.

– François Andrieux
Jan 4 at 18:37







All identifiers that begin with an underscore in the global namespace are reserved and can't be used. _delete violates that. It might not be the cause of your problem but it would be best to fix it and eliminate it as a possible cause. Edit : You can find a list of restricted identifiers here.

– François Andrieux
Jan 4 at 18:37






2




2





SUGGESTION: print out the addresses returned by malloc() and passed to free(), to verify they're correct. And I agree: "_delete()" is an unwise choice of names :(

– paulsm4
Jan 4 at 18:40







SUGGESTION: print out the addresses returned by malloc() and passed to free(), to verify they're correct. And I agree: "_delete()" is an unwise choice of names :(

– paulsm4
Jan 4 at 18:40















objcopy the library and substitute standard names for new and delete for new ones. Provide them in your translation unit. Overwrite the defaults in another. Link. There is no other option - you need to substitute the function names in the library code.

– Kamil Cuk
Jan 4 at 18:42





objcopy the library and substitute standard names for new and delete for new ones. Provide them in your translation unit. Overwrite the defaults in another. Link. There is no other option - you need to substitute the function names in the library code.

– Kamil Cuk
Jan 4 at 18:42













Strictly speaking you should be using placement new to write the size into the extra allocated memory.

– François Andrieux
Jan 4 at 18:44





Strictly speaking you should be using placement new to write the size into the extra allocated memory.

– François Andrieux
Jan 4 at 18:44













Thank you for pointing out _delete, but even if I rename it to something like my_delete it behaves the same.

– Yegor Tyuvaev
Jan 4 at 18:47







Thank you for pointing out _delete, but even if I rename it to something like my_delete it behaves the same.

– Yegor Tyuvaev
Jan 4 at 18:47














1 Answer
1






active

oldest

votes


















2














I found the answer for my case.



I replaced these forms to have it working:



void *operator new(size_t size);

void *operator new(size_t size, std::align_val_t al);

void *operator new(size_t size, const std::nothrow_t &tag);

void *operator new(std::size_t size, std::align_val_t al, const std::nothrow_t &);

void operator delete(void *ptr);


Though I didn't replace aligned delete operator, the program stopped crashing.
But I guess it's still a good idea to replace aligned delete as well as cppreference.com suggests.






share|improve this answer



















  • 2





    In other words, the problem was that there were some overloads you didn't anticipate, correct? Please feel free to "accept" your answer.

    – paulsm4
    Jan 4 at 20:54













  • @paulsm4 yes, I think this is the problem. I trusted too much to cppreference.com. Or maybe the problem was that this rule of thumb from that website applies only to C++17 apps and the library might be built with older C++ standard. I don't want to dig deeper though.

    – Yegor Tyuvaev
    Jan 4 at 21:02












Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54044336%2fhow-to-replace-operator-new-delete-and-not-interfere-with-libraries%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









2














I found the answer for my case.



I replaced these forms to have it working:



void *operator new(size_t size);

void *operator new(size_t size, std::align_val_t al);

void *operator new(size_t size, const std::nothrow_t &tag);

void *operator new(std::size_t size, std::align_val_t al, const std::nothrow_t &);

void operator delete(void *ptr);


Though I didn't replace aligned delete operator, the program stopped crashing.
But I guess it's still a good idea to replace aligned delete as well as cppreference.com suggests.






share|improve this answer



















  • 2





    In other words, the problem was that there were some overloads you didn't anticipate, correct? Please feel free to "accept" your answer.

    – paulsm4
    Jan 4 at 20:54













  • @paulsm4 yes, I think this is the problem. I trusted too much to cppreference.com. Or maybe the problem was that this rule of thumb from that website applies only to C++17 apps and the library might be built with older C++ standard. I don't want to dig deeper though.

    – Yegor Tyuvaev
    Jan 4 at 21:02
















2














I found the answer for my case.



I replaced these forms to have it working:



void *operator new(size_t size);

void *operator new(size_t size, std::align_val_t al);

void *operator new(size_t size, const std::nothrow_t &tag);

void *operator new(std::size_t size, std::align_val_t al, const std::nothrow_t &);

void operator delete(void *ptr);


Though I didn't replace aligned delete operator, the program stopped crashing.
But I guess it's still a good idea to replace aligned delete as well as cppreference.com suggests.






share|improve this answer



















  • 2





    In other words, the problem was that there were some overloads you didn't anticipate, correct? Please feel free to "accept" your answer.

    – paulsm4
    Jan 4 at 20:54













  • @paulsm4 yes, I think this is the problem. I trusted too much to cppreference.com. Or maybe the problem was that this rule of thumb from that website applies only to C++17 apps and the library might be built with older C++ standard. I don't want to dig deeper though.

    – Yegor Tyuvaev
    Jan 4 at 21:02














2












2








2







I found the answer for my case.



I replaced these forms to have it working:



void *operator new(size_t size);

void *operator new(size_t size, std::align_val_t al);

void *operator new(size_t size, const std::nothrow_t &tag);

void *operator new(std::size_t size, std::align_val_t al, const std::nothrow_t &);

void operator delete(void *ptr);


Though I didn't replace aligned delete operator, the program stopped crashing.
But I guess it's still a good idea to replace aligned delete as well as cppreference.com suggests.






share|improve this answer













I found the answer for my case.



I replaced these forms to have it working:



void *operator new(size_t size);

void *operator new(size_t size, std::align_val_t al);

void *operator new(size_t size, const std::nothrow_t &tag);

void *operator new(std::size_t size, std::align_val_t al, const std::nothrow_t &);

void operator delete(void *ptr);


Though I didn't replace aligned delete operator, the program stopped crashing.
But I guess it's still a good idea to replace aligned delete as well as cppreference.com suggests.







share|improve this answer












share|improve this answer



share|improve this answer










answered Jan 4 at 20:52









Yegor TyuvaevYegor Tyuvaev

513




513








  • 2





    In other words, the problem was that there were some overloads you didn't anticipate, correct? Please feel free to "accept" your answer.

    – paulsm4
    Jan 4 at 20:54













  • @paulsm4 yes, I think this is the problem. I trusted too much to cppreference.com. Or maybe the problem was that this rule of thumb from that website applies only to C++17 apps and the library might be built with older C++ standard. I don't want to dig deeper though.

    – Yegor Tyuvaev
    Jan 4 at 21:02














  • 2





    In other words, the problem was that there were some overloads you didn't anticipate, correct? Please feel free to "accept" your answer.

    – paulsm4
    Jan 4 at 20:54













  • @paulsm4 yes, I think this is the problem. I trusted too much to cppreference.com. Or maybe the problem was that this rule of thumb from that website applies only to C++17 apps and the library might be built with older C++ standard. I don't want to dig deeper though.

    – Yegor Tyuvaev
    Jan 4 at 21:02








2




2





In other words, the problem was that there were some overloads you didn't anticipate, correct? Please feel free to "accept" your answer.

– paulsm4
Jan 4 at 20:54







In other words, the problem was that there were some overloads you didn't anticipate, correct? Please feel free to "accept" your answer.

– paulsm4
Jan 4 at 20:54















@paulsm4 yes, I think this is the problem. I trusted too much to cppreference.com. Or maybe the problem was that this rule of thumb from that website applies only to C++17 apps and the library might be built with older C++ standard. I don't want to dig deeper though.

– Yegor Tyuvaev
Jan 4 at 21:02





@paulsm4 yes, I think this is the problem. I trusted too much to cppreference.com. Or maybe the problem was that this rule of thumb from that website applies only to C++17 apps and the library might be built with older C++ standard. I don't want to dig deeper though.

– Yegor Tyuvaev
Jan 4 at 21:02




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54044336%2fhow-to-replace-operator-new-delete-and-not-interfere-with-libraries%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Monofisismo

Angular Downloading a file using contenturl with Basic Authentication

Olmecas