I thought I might mention the book: API Design for C++ (Morgan Kaufmann, 2011) by Martin Reddy and the accompanying website [1] and blog [2], in particular the articles on API design [3]. One of those blog entries is on "Writing a C Library" by David Zeuthen [4].
The book has a short section on Flat C APIs. An entire chapter is devoted to Versioning with a section on Levels of Compatibility. I haven't read it myself yet --- I've been meaning to for months :) --- but it gets excellent reviews on amazon. As far as your question goes, I use PCRE in a few small personal projects. I wouldn't be all that bothered if you chose Option 1. OTOH, I really need to be able to do regex replace/substitute. If that isn't in the new PCRE then I'd like to see pcreCPP updated also in a timely manner. [1] http://www.apibook.com/ [2] http://www.apibook.com/blog/ [3] http://www.apibook.com/blog/archives/category/design [4] http://www.apibook.com/blog/archives/186 On Sat, Jun 8, 2013 at 4:51 PM, Thorsten Schöning <[email protected]>wrote: > Guten Tag Graycode, > am Samstag, 8. Juni 2013 um 19:42 schrieben Sie: > > > OPCRE should have > > consideration for the POSIX API wrapper as well. Perhaps the existing > > C++ wrapper is in OPCRE too. > > As POSIX and C++ alreaady are just wrappers around the old API, it > should be enough to let the old API be a wrapper around the new one. > The other wrappers should work out of the bov in this case. > > > An application may use either OPCRE or NPCRE, but not both. > > Why should one need that restriction if NPCRE already is a dependency > for OPCRE and therefore must be used in an application? Why shouldn't > one be able to use both APIs, especially with different function > names, if one is forced to build and link both libraries? > > > The header > > #define values such as PCRE_CASELESS can be very different for OPCRE > > than for NPCRE. Similarly, the header for OPCRE might: > > #define pcre_compile(a,b,c,d,e) opcre__compile(a,b,c,d,e) > > in order to avoid conflict with function names in the libraries when > > OPCRE links in the NPCRE library. > > It should be preferable to simply use new function names in the new > API, this way there won't be any naming collisions. And if the old > API is used in some kind of wrapper it's less work to leave everything > like function names structures, defines etc. as they are and map those > only if necessary to new names and structures. A new API doesn't > necessarily mean that every old define or structure need to change, > only those that behave differently. > > > The documentation should state that OPCRE is transitional. At some > > future date the OPCRE project may be abandoned, or perhaps it will > > just remain static for very long intervals. > > I don't see the benefit of an OPCRE for maintainers or users, users > who don't want or are able to upgrade at least should be in a position > to use the latest versions of "old PCRE" without changing any of their > infrastructure and this would mean that old PCRE simply stays > untouched as it is and the new API is simply that, a new library which > one can use or not. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail:[email protected] > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...........05151- 9468- 55 > Fax...............05151- 9468- 88 > Mobil..............0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > > > -- > ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev > -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
