On 31.12.2018 04:57, Troy Curtis Jr wrote:
> 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.
I don't imagine these headers would be come very large. They can really
only contain plain data types, enunerations and forward declarations of
C structs (for p_impl, where apppropriate, so that we don't have to go
through void*).
> 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?
No, not everything; only things that can usefully be reused by the C++
API. I don't imagine there will be a lot of that. For example, I can't
imagine we'd ever expose the entire status callback structure in C++.
> 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.
My main concern is to not mess up the ABI. What I did in the example
with enumerations is safe in C, anything more complex would have to be
carefully checked and tested. The main reason for this move isn't so
much to save typing or the number of conformance tests, but to be able
to make some of the C++ stuff inline that currently isn't because it the
implementation relies on the C-API headers.
-- Brane
>> 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 15:19:30 CET