Hi, on Wednesday 08 December 2010 03:06:08 Aaron J. Seigo wrote:
> On Monday, December 6, 2010, Thomas Baumgart wrote: > > The plan is to move libalkimia to extragear/office/alkimia once approved > > some hopefully useful feedback: > > binary compat: there is not dptr, making keeping binary compatibility > impossible if changes are desired. for shared libraries it is highly > recommended (and required, if binary compatibility will be provided) to > have a dptr and to move all data members into it. > > inline methods: aside from the note about inline methods that Albert > already noted, it's an even worse idea to do this with constructors and > destructors as it severely limits what you can do with the class in > future. is this class needed to be extremely-high-performance? if so, have > you measured the benefits of the inlined methods versus non-inlined to > ensure the lack of flexibility is warranted by the performance gains in > those use cases? Thanks for the comments. Some more in-depth analysis showed that the gain was not as much as expected, so I moved the inline methods to the cpp file. Also added a dptr interface while thinking that the overhead involved is not significant. Changes checked-in. > enumeration: RndDown, etc. why not RoundDown? makes it clear "rnd" doesn't > mean "random" :) Yep, that Rnd came a long way ... Anyway, changed to 'Round' in all cases. Thanks also to Albert for his explanation. -- Regards Thomas Baumgart GPG-FP: E55E D592 F45F 116B 8429 4F99 9C59 DB40 B75D D3BA ------------------------------------------------------------- "Hey! I could use Tex!" and I've only gotten to use it a little so far but it's so far superiour to MS Words "be everywhere do everything"-ness it's not even funny... (lordSauron) -------------------------------------------------------------
signature.asc
Description: This is a digitally signed message part.
