On Sun, Dec 30, 2018 at 6:07 PM Branko Čibej <brane_at_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
>
Received on 2018-12-31 04:57:46 CET