On Mon, 31 Dec 2018, 15:43 Julian Foad <julianfoad_at_apache.org wrote:
> I guess I'm missing something. Why not just move the existing C
> declarations verbatim to an APR-free header (from svn_types.h to
> svn_types_impl.h, for instance), and in C++ use them directly like this
> (proposed lines marked '>'):
>
> /**
> * @brief Revision number type.
> */
> - enum class number : long
> + enum class number : svn__impl__revnum_t
> > enum class number : svn_revnum_t
> {
> - invalid = -1, ///< Invalid revision number.
> + invalid = SVN__IMPL__INVALID_REVNUM, ///< Invalid revision number.
> > invalid = SVN_INVALID_REVNUM, ///< Invalid revision number.
> };
>
> Then there would be no need for all the reimplementing in svn_types.h with
> lines like "A = __impl__A".
>
That won't work, the type specifier on 'enum class' doesn't declare
inheritance but the underlying integral type of the enumeration constants.
The values of the constants still have to be defined explicitly. But yes, I
can skip one step as you suggest.
> Oh... I suppose the reason is because you don't want the C++ headers to
> expose the original C declarations.
Exposing the C declarations is not an issue, as long as it doesn't expose
APR types. I do want to use C++ 'enum class' for enumerations and e.g.,
svn_revnum_t, because they define distinct types which is important for
overload resolution and argument-dependent namespace lookup.
But is that such a problem? I'm thinking of the existing SWIG Python
> bindings where we map C name svn_client_add to Python name
> "svn.client.add", primarily, but we also leave the original name hanging
> around as "svn.client.svn_client_add" or something like that, and AFAIK
> it's not much of a problem, just a little untidy.
>
> Overall, if this is what it takes for you to proceed with the good work,
> then sure, go ahead: it looks like a manageable amount of churn.
>
I'll go with your suggestion to move the "safe" C types to separate headers
and use those directly in C++.
Thanks for the review!
-- Brane, not quite sure why he's answering mail on the phone on 1st
January, but surely wishing you all a not so bad New Year.
Received on 2019-01-01 11:26:42 CET