Implements "in the middle" insertions of child items.
The template argument class must export a static inline bool firstGreaterOrEqual( Item *, Item * ) function which must return true when the first parameter item is considered to be greater or equal to the second parameter item and false otherwise.
The insertion function IS our very bottleneck on flat views (when there are items with a lot of children). This is somewhat pathological... beside the binary search based insertion sort we actually can only do "statement level" optimization. I've found no better algorithms so far. If someone has a clever idea, please write to pragma at kvirc dot net :)
GCC_DONT_INLINE_THIS is a macro defined above to attribute((noinline)) if the current compiler is gcc. Without this attribute gcc attempts to inline THIS function inside the callers. The problem is that while inlining this function it doesn't inline the INNER comparison functions (which we WANT to be inlined) because they would make the caller function too big.
This is what gcc reports with -Winline:
/home/pragma/kmail-soc/kmail/messagelistview/item.h:352: warning: inlining failed in call to 'static bool MessageList::ItemSubjectComparator::firstGreaterOrEqual(MessageList::Item*, MessageList::Item*)': –param large-function-growth limit reached while inlining the caller /home/pragma/kmail-soc/kmail/messagelistview/model.cpp:239: warning: called from here
The comparison functions then appear in the symbol table:
etherea kmail # nm /usr/kde/4.0/lib/libkmailprivate.so | grep Comparator 00000000005d2c10 W ZN5KMail15MessageList18ItemDateComparator19firstGreaterOrEqualEPNS0_4ItemES3 00000000005d2cb0 W ZN5KMail15MessageList20ItemSenderComparator19firstGreaterOrEqualEPNS0_4ItemES3 00000000005d2c50 W ZN5KMail15MessageList21ItemSubjectComparator19firstGreaterOrEqualEPNS0_4ItemES3 ...
With this attribute, instead, gcc doesn't complain at all and the inner comparisons seem to be inlined correctly (there is no sign of them in the symbol table).
Definition at line 92 of file item_p.h.