On Mon, Mar 02, 2015 at 10:11:33AM -0800, Thiago Macieira wrote: > On Monday 02 March 2015 11:21:10 Oswald Buddenhagen wrote: > > > I am actively against it while it's a huge burden on us for little > > > perceived benefit. You have to convince me of the benefit against the > > > cost. > > > > i still don't see that huge burden. i see introducing a few (inline) > > functions in two alternative #ifdef branches, and a global search & > > replace operation. > > You need to replace all the "new" too for this to be effective. > this aims at the reliably failing builds without exception support, so the non-throwing new's return value would have to be checked to complement the malloc wrapper.
while this would be reasonably simple (just replace new with qNew or something like that), it would be a) kinda ugly and b) would expand to lots of code. the other case is a build with exceptions where new throws as normal and qMalloc (used from c++ code) throws as well. malloc calls from c code would obviously need to handle and propagate malloc failures up to a point where we can see them and throw, which isn't much effort for our own code. however, there is a serious problem: stack unwinding resulting from an exception being thrown (even if it just aborts in the end because nobody catches it) requires all objects on the stack to keep their internal state consistent enough so that invoked d'tors won't crash - even when a c'tor throws before initialization finishes. this is clearly at least partially the exception safety which we have deemed out of scope so far because of an unreasonable cost/benefit ratio. i presume we're not going to change our opinion on that point. regarding 3rd party libraries: some would need to be excluded from the support entirely (because they are uncooperative), while others may need fixes inside or around the libs. generally, whether they return null or throw (while being exception-safe) doesn't matter, as the mechanisms can be translated into each other. i don't think the effort for that would be prohibitive if we had a serious interest in it, but it certainly wouldn't come for free. so to summarize ... color me convinced. replacing malloc it is. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development