If we are serious about having a serious update to APR, I would recommend that we use more up-to-date data structures, patterns and algorithms than those in apr1. For example, Greg's pocore mini lib is an example of the types of improvements we should consider.
> On Nov 20, 2015, at 1:31 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > I'm wondering how the group would react to refactoring some of APR 2.0 > to either offer inline code for many of our heavily consumed functions, > or offering inline + fn implementations alongside one another? > > Would it still be necessary in this day and age to support C compilers > that do not support inline at all, e.g. hide the inline declarations based > on some macro switch leaving only the function stub? > > We can obviously debate the merits of which functions are most > prime for optimization, including how mature each is (due to the > fact that the user will be 'stuck' with the implementation until they > recompile their own code against a new release of apr in the event > of a bug or security fix). > > Thoughts? > > Bill
