How is that different from linking a custom implementation of operator new/operator delete and malloc/free into Qt?
These are embedded use-cases anyway, so you wouldn’t be using a stock Qt binary. Implementing the above is well-documented, and in fact both C++11 and C++14 have improved the ways in which the new/delete can be overridden. Just put your implementation in a static lib and pass it to the configure script as an additional library. --Louai Maybe a bit off-topic: can we introduce our own (probably customizable) memory allocation API, something like Apple's CFAllocator [1], and move Qt internals to use it instead of malloc/realloc/free (and maybe instead of some new/delete-s, based on some policies)? Then we could let the user to decide if he needs a OOM safety, i.e. with QAllocator::setDefaultAllocator(..) Such a "centralized" memory allocation routines also could be very useful in debugging or memory consumption monitoring. Regards, Konstantin [1] https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFAllocatorRef/ 2015-02-26 0:29 GMT+04:00 Marc Mutz <marc.m...@kdab.com<mailto:marc.m...@kdab.com>>: On Wednesday 25 February 2015 16:30:56 Giuseppe D'Angelo wrote: > And on the other hand, this assumption of having infinite memory has > held for a while Only in the niche that Qt exists in. Now, the question is whether Qt does not play a role in systems that handle oom gracefully because Qt doesn't handle them gacefully or whether it doesn't play a role in those systems because there are no such systems. But I'm sure there are embedded systems that fall in between the desktop model of inifinite VM space and hard-realtime systems that allow no dynamic memory allocations after program initialisation. For such systems, recovering from oom is actually a plausible alternative. Relying on the oom killer in a soft realtime application is asking for trouble. It can literally take an hour for the system to recover. I just experienced a 50min thrashing when I dared to start up a 4GB VM without waiting for qtcreator to fully quit. The oom killer killed qt-creator, but it _did_ take 50mins. As Ossi said, overcommitting is likely turned off in those systems. BTW, IIRC, you also get nullptr mallocs (without thrashing swap first when you run into user-defined ulimits. If Qt wants to be(come) relevant to that part of the embedded space (or that part of server space that still uses ulimit), we better stop acting like there's only infinite memory. > -- why should now people have a slower library because > of all those checks? Q_CHECK_PTR does not necessarily make the library slower. It only needs to be applied to malloc/calloc and nothrow operator new, because ordinary new already throws. We can port such code to normal operator new instead. Thanks, Marc -- Marc Mutz <marc.m...@kdab.com<mailto:marc.m...@kdab.com>> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com<http://www.kdab.com> || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions _______________________________________________ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development