On Sun, Dec 30, 2018 at 6:07 PM Branko Čibej <br...@apache.org> wrote:
> Summary: I propose to create one or possibly several new public header > files that will be used by both the C and C++ public APIs. > > > I would like to completely hide the dependency on APR from the public > parts of the C++ API. In order to do that, public C++ headers must not > include the C headers directly, because most if not all of them do > expose APR. > > Up to now I've been "solving" this in an unsatisfactory and error-prone > way, redefining enumeration values in C++ to be the same as in C, > forward-declaring C structures in C++ headers, and so on. Instead, I'd > like to extract certain parts of the C public API into a new header that > is independent of APR, and use that in both APIs. This way I won't avoid > redefining enumerations, for example, but I can ensure that both the C > and C++ APIs use the same enumeration constant values. > Just a few of the thoughts that occurred to me while thinking about this. How big do you expect these implementation header to get? In your included example it seems fairly reasonable, but I worry about what kinds of strange define/inclusion gymnastics might be required in the future in order to continue to accomplish the APR hiding goal. It also seems to me that in general you'd want to use module specific implementation files, like svn_client__impl.h or similar to main the nice componentized nature of the existing header files, which seems like quite a few files that would presumably be very empty. Would the "policy" be to put everything that doesn't require external headers into these implementation headers? Or only types/definitions that are also required for the CXX interface? Does that result in significant movement from the current headers to these new impl headers? Would it be a problem if it did? It seems like a good bit of churn, but probably not a very big deal. > I'm attaching a patch that shows an example of what I have in mind. > > Please raise your objections by next year. :) > > -- Brane >
