On 21/09/2021 09:24, Adriano dos Santos Fernandes wrote: > On 21/09/2021 09:11, Dimitry Sibiryakov wrote: >> Adriano dos Santos Fernandes wrote 21.09.2021 13:50: >>> We may split that global default pool in two, so we'll have another >>> default pool for external (not controlled by us) libraries. All memory >>> allocated directly with "operator new" (not FB_NEW) will go to external >>> pool. >> >> Wouldn't it be simpler to make GlobalStorage do not use pool at all >> (and do not overload global new/delete operators)? >> Pools can be employed in places where it really has meaning using >> class-bound allocators. In this case the cleanup is performed on object >> destruction and doesn't interfere with external modules. >> > > It's easy and possible. >
I may have bad understood you. I answered about if you were saying just about not redefine global new/delete and make them call the standard new/delete. But it's not what you said. > Though we will lose way to monitor leaks. > And it also don't work make some operator new use an allocator and another one use another. The global delete (without extra parameters) always need to be redefined. It's what is called in most circumstances (no exception). So both memory allocated by Firebird code and external libraries will go to the same place. External pool with special characteristics works for this case. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
