From dev-return-38809-archive-asf-public=cust-asf.ponee.io@subversion.apache.org Mon Dec 31 15:19:26 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 832D6180648 for ; Mon, 31 Dec 2018 15:19:25 +0100 (CET) Received: (qmail 3077 invoked by uid 500); 31 Dec 2018 14:19:24 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 3067 invoked by uid 99); 31 Dec 2018 14:19:24 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Dec 2018 14:19:24 +0000 Received: from [172.23.17.71] (89-233-126-4.dynamic.t-2.net [89.233.126.4]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 43E034343 for ; Mon, 31 Dec 2018 14:19:23 +0000 (UTC) Subject: Re: Common header(s) for C and C++ API To: Subversion Development References: <38088a6d-9110-1447-af96-7fcda69d1474@apache.org> From: =?UTF-8?Q?Branko_=c4=8cibej?= Openpgp: preference=signencrypt Autocrypt: addr=brane@apache.org; prefer-encrypt=mutual; keydata= mQINBFG3qpMBEACi+jRQDd2TiYeAxVgrLZ3cyyuGOFSMh4nCyUOG9BwXC69cDLH48RcE0Mpu TFTGlfdokz6JgLKU3uqShPXiflrL6JIVnJX4rTEKRzFNkcS6Zq0PfNRnFnkwiD2KIzyAG8XE y0c1Bt7hqZ5dfXaC1b7Xo+1cnlqjdLAOnr1ruTrtfQ5sO81p9jYtARVa+iVmf8bs/FvC9Yn2 QtEDtuUfUUHx2bnB9vmh8tOjErfIcWtzCPt8uTUkmiszlkRMiB5/X97oqXlX/5dSQWE9m4M5 6Fc9ixIrmCwkF515RLrCNTv/YAtmpu4VaB0rxgTuSku0cVk83xSMrH2hNFx1fAeYBZpwp2GL ONlTy3D2N+BjWXjEUE9baGOoYM7QUbAdj4JMstSByppaAi4AiG9+raxknTWtWt2IT9LHW7Pu i6S3k4WL5jmTdQKqNQ9/+vRqiSVsA98yHQLa+s19IYh4F7WIfo2lzBAn06HEntpKS9TtV20o JyMBLOVqQP1dARWRfB0xIxGtbI61CfjEhCeG8H+UynCrHkUxgUoKsXXkI/JxsIMZ3TivFj3U MJVur7KVwg/isqqaEyMfUnCrXJxexZp8kuTjkzzvDKfYs0vHJezPQYhlqBLkK2w9VzktGjA7 lb+TO69bEyPOcBjVsCtrdYVc442/Z37G+1UV5+1X06m14Pt9UQARAQABtCBCcmFua28gxIxp YmVqIDxicmFuZUBhcGFjaGUub3JnPokCOgQTAQoAJAIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgAUCUbetMwIZAQAKCRAbymWGo0eUP2tOD/9KOLYfxwTcGV/Nj3lnKE4Y4gRl0r4cfnWm 1/2KyPYVsmQ8vWRUZxjuVHAvZrAkTBvlu+CVzrCWEEpCzQC/jki0xkPQchTEU2XOHQ6PzkXB 17o1NSSu/vyKynh0pXMRTHm4wZodzUw/tHn/Ism5QyRyhlYUP4mVX8v2hbN+stkJHrkdVBPm FspnFidhulUP5hr+LWz2qd+Ab8MOn3+x25jsGE8yaUiqmNdrmq/trvHPGThySa4Hz0uEkhfP K2knc6PpV5GTbeRn/J1eu17xVgXYVgko35Qwz5s/LRat+5R79tgBAL9SKFybCVBPr6/1Zp4u w9b0NcHW6t3aQHCxv8iEqxrJ7UIDhh/hXh4no0vzpPR1Cgjn6fK997WrpUyaAtlnbSH5QGad YY9rpFka3o2Gj+f+cr75hq6c7DnNJo94eGw9L0JEjfgordi8UkWErGOklnGf8N8brlVG0TdW 7KOz60m1E3UzIwd2lQd9a0zd8Mqrmn2MMPdJt4EpKQWaJsoK+FOdEBX0Ezm3StEXufe1IOG9 DihVcOnsx/G6aTS9GyKjURVt0jDB4wsVSzsRHYHmQpw7/ekvHFNKZS5yMNwSt2X/Szmk4GmV 69gaI79kf8VD87xwE31p0s0uVIVp7MTOTEYT5HUh5Rz6Rr66+vg9qgN1enMj5sh4f8krXgRR wLkCDQRRt6qTARAAnxIdGqDTC2FU9AE2ElT/m/Hs/57BwqUUb8qod3mJ6Qkp7PpHCBnvtbwm krrCsJl5rR1fliton6qoJUNCSfmcfeujcU8Be+q75rNZxIWi6AjMmyrjyMp9JIO7g/7+VYmL dm9c1wRn4QDnIKxl7qMPz9q8/OF6BGEMEW4zRL8rHvM7CCapOikHUKKq7GnZMVyYbue6KUTA Tczxjt6E9Av1QDnnW9zbW56jqUKdgpNek/bSTuef2xYEDzIzFPQREyw8E/C3xx8zZfOJ0+XV s1n39GLp3vugP5IBNE2pgqcyFtKISj1pVJgDr7zXjD92ZGS8xgqDxePTuf1LcCwd65BJNVVK IFsFicvBVhdslCZ7l8jkCuZAzYoFJZthUKuuJg1n7HYi8XLifZmun9Z3fbM5gk9/vA1rXsWt An597BACKDUkWA5tOb3Si4/MaRDiZYvzplHGc4sTn4aBIj3VFGGFNlOUPFLWjZLHdudNOBGj 3eIlz/DQZh/mwNGn5g98c3xehHnWxcXa0PsN2Xl1iRM2dec8drEVVRYaWPcOmGhKfqnlwl2z OeuST2TMcWhxKshVimR9eSt5pX1oGOD9PZ9V0gQDIr4d35UjQaW5ABCWbgTd7e3yPTlHoWx4 qyv+YoxEf6AlQ4nvE+q1s4wRBs/eNVQsROnYmhKhYPZUsDE6EocAEQEAAYkCHwQYAQoACQUC UbeqkwIbDAAKCRAbymWGo0eUPwd6D/92i5LBHSluiBdnzYH3kYlkIMjhy3lcqtxb/TWV1X/z CVpaZkEXvL9NQ44ZqfiOFB8fnaJvy+9rfIL3MwHKLVHOjsurBRP2DJ8H/EI6QuZV//Nxh66A dicXlE5SSiKQ5KcIH+eqZHa4XjVeXGeNZummrlhOv3ItKXETVhh2qeIQ/7zCjuw5rQk606+2 isg6cs4Nwtie1rXQ1KFtkTNQqWfqyM4PrEP9Bq5pWBQVkcxDsxk1Yj3A8L80IY3Hzwm8nRlq F+HkD/0IPgHICVDyiOB4XZtqVk+DHNOolCcdrFSXOcwt+qwD5zk4p0hdHKHagAPGBDXS8shm k2vaUDbKMUoVDdj579Jtp4tNOoVEEqqXspT995w7+ckbHGoQhFlSxCwtaXCr/8wwdwcCA2eO w0aLYrU04EbnH7Ryj4aTjsBGvJdmyZQT8/lTj5VARbEkNXTdTOs61pebDliyWtcF9Uz9b44p cLNniphcBO4SP/IMlEh8pBAJ1C2QlD4G90iJ1WK0MsJsUDix9Vb5s1AE6WA/Ss1iPCOdhhif eToCAwoobIipoxUZF2ik3oESskmMDolpVBiaPaFg+YPtNp/53dLap7jBNRNgyKXaGJAZaolp L+9hCU1EOWswqusDHDFSRUuYOXfuXZJxcbQUTnhQhRbvSDy3tDMRGd252Ur1sCOU5g== Organization: The Apache Software Foundation Message-ID: <82cfedcc-f95d-f234-bb16-7a02ed10bc9b@apache.org> Date: Mon, 31 Dec 2018 15:19:21 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB On 31.12.2018 04:57, Troy Curtis Jr wrote: > On Sun, Dec 30, 2018 at 6:07 PM Branko Čibej 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 >>