On Tuesday 24 February 2015 12:58:12 Jon A. Cruz wrote: > This seems to me that a separation between C and C++ parts of the core > might be warranted. For the single-threaded case that would mean not > building the C++ lib. > > The current proposal of a single library would presumably address this > by merely selectively disabling inclusion of the C++ code by build > configuration wizardry. > > Making the C and C++ parts into two libraries would simply build > configuration and maintenance. However our codebase is probably small > enough not to require this complexity yet. Then later we could split > into two libs and perhaps a compatibility lib that keeps the original > name but references both of the new ones.
Another advantage is to ensure we don't have any leakage of C++ code into the C SDK, if we do the split. A disadvantage of the split is the overhead caused by having mutliple libraries. There's at a minimum 4k overhead of non-sharable data and the symbol resolution is O(n) on the number of libraries. I did mention this to Pat and he, as the maintainer of this particular codebase, said he prefers a single, merged library. Pat, do you want to change your mind? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
