On 04.01.2019 15:35, Daniel Shahaf wrote:
> Branko Čibej wrote on Fri, 04 Jan 2019 15:31 +0100:
>> On 04.01.2019 15:20, Daniel Shahaf wrote:
>>> brane_at_apache.org wrote on Fri, 04 Jan 2019 10:38 +0000:
>>>> Move (some of the) standalone types into separate implementation headers
>>>> so that SVN++ can use them directly without exposing APR or other dependencies.
>>>> +++ subversion/trunk/subversion/include/svn_opt_impl.h Fri Jan 4
>>>> 10:38:53 2019
>>>> @@ -0,0 +1,83 @@
>>>> + * @file svn_opt.h
>>>> + * @brief Option and argument parsing for Subversion command lines
>>>> + * (common implementation)
>>>> + */
>>>> +
>>>> +/* NOTE:
>>>> + * This file *must not* include or depend on any other header except
>>>> + * the C standard library headers.
>>>> + */
>>> Could the comment also explain the rationale for the restriction it imposes?
>> No, not in every "impl" header we happen to create. But it is documented
>> in subversion/bindings/cxx/README, as one of the SVN++ design goals.
> Shouldn't this be documented in the C API's documentation too, at least
> by reference? Someone working on the C headers in a year or three might
> not think to look in the C++ bindings for design choices of the C API.
If you have an idea how to do that without boring repetition, please go
ahead.
I just don't see it as all that relevant apart from the "don't do that"
header in the files. Every existing type that was moved to the new
headers already has a reference to its C++ counterpart[1]. When we
invent new types, trivial cases will be caught when (if?) their C++
wrappers are written.
-- Brane
[1] ... except svn_node_kind_t, which doesn't have a C++ counterpart yet.
Received on 2019-01-04 15:42:30 CET