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 <tschoening@???>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:Thorsten.Schoening@???
> 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
>
