> On 2002-10-11 at 19:44:10 [+0200], you wrote: > > > We should be very careful with inlining functions. Unless the > > functions's tasks are trival (as BString::Length()/String() are for > > example), the function call overhead to function execution ratio > > should > > be insignificantly small. And inlining may introduce serious binary > > compatibility traps. > > Yes, but inlining some class private methods won't introduce any > binary > compatibility problems, and could help improving performance, even if > some > of these functions are, IMHO, too big to be inlined. The _Init() > method > could be inlined, but I wouldn't inline the _OpenAtBy() or the > _GrowBy(). Yep, I guess, you can even keep the inlined private functions out of the header file. > > Regarding the performance loss: BString is a high-performance > > class. It > > trades space (the length field in _privateData) for performance. I > > would say, however you implement it now, the final code should take > > advantage of this length field. > > Yeah, of course. > It's already taking advantage of it. > > BTW, I brought a bad example. A better example would be the two > CharacterEscape function. If you take a look on them, you will > understand > what I want to say (and if you don't have time, I will explain more > the > next time) :) Right, the first CharacterEscape() version can and should use the second one. BTW, I see some potential for more optimization. The function could scan the string first to determine the new string length and then iterate from back to front to insert the escape character. This will save a lot of realloc()s and will make the algorithm O(m*n) (m := number of characters in setOfCharsToEscape, n := string length) instead of O(m*n + n^2), which is obviously bad for long strings. Anyway, this can definitely be postponed. CU, Ingo