On Wednesday, 21 de December de 2011 17.01.13, Holger Hans Peter Freyther wrote: > On 12/21/2011 07:26 AM, Robin Burchell wrote: > > Hi, > > > > ways to accomplish this as the commit message notes, and it's rather > > unfair to impose an additional function call on all uses of these for > > something which isn't used in the majority of cases. > > Hi, > > my two cents here. If code is calling out to malloc/new you are already on > the slow path and the time will be dominated by the real malloc anyway. I > have not seen a performance problem that went away/got better by patching > out qMalloc/qFree. In case it would become one, on ELF one can probably use > aliases declarations or the recent 'ifunc' to have it resolved to the real > malloc implementation. I don't think qMalloc/qFree is a burden.
Agreed. The point Robin was trying to make was that these functions are
unnecessary these days. Either way, we should mark qMalloc with
__attribute__((alloc_size(1))) and qRealloc suitably.
I also want most uses of qMalloc or malloc gone from the headers: the
container classes should call suitable allocation functions, such as all
containers but QVarLengthArray already do.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
