Skip to content

[doc] Fix \tparam names that do not match the declaration - #1486

Open
karpovantonme wants to merge 2 commits into
boostorg:developfrom
karpovantonme:doc/tparam-names-match-declaration
Open

[doc] Fix \tparam names that do not match the declaration#1486
karpovantonme wants to merge 2 commits into
boostorg:developfrom
karpovantonme:doc/tparam-names-match-declaration

Conversation

@karpovantonme

Copy link
Copy Markdown

Four Doxygen blocks name a template parameter the declaration below them does not have.

File Documented Declared
algorithms/detail/overlay/clip_linestring.hpp:43 B, P Box, Point
algorithms/simplify.hpp:82 the Point
strategies/azimuth.hpp:27 CalculationType only CSTag exists
strategies/transform.hpp:41 CoordinateSystemTag, CoordinateSystem, D, Point the eight numbered ones

Two of these are interesting beyond a rename.

simplify.hpp reads \tparam the enclosed point type, with the name left out, so Doxygen takes the as the parameter name and the description becomes "enclosed point type" attached to a parameter that does not exist.

transform.hpp documents pairs in one line each:

\tparam CoordinateSystemTag 1,2 coordinate system tags
\tparam CoordinateSystem 1,2 coordinate system
\tparam D 1, 2 dimension
\tparam Point 1, 2 point type

The intent is clear to a human and invisible to Doxygen, which reads four names none of which exist, and leaves all eight real parameters undocumented. Split into eight lines.

Which one is source and which is target is not a guess: transform(Geometry1 const& geometry1, Geometry2& geometry2) takes the first by const reference and the second mutable, and select_strategy passes Geometry1's traits into the odd positions.

azimuth.hpp simply lists one parameter too many, so that line is gone.

Not included

The same sweep flags twelve more, and they are a different kind: the block documents parameters that belong to a member function rather than to the class, e.g. detail/not.hpp documents Geometry1/Geometry2 from apply on a class templated only on Policy, and the pythagoras distance strategies do the same with Point1/Point2. Fixing those means deciding where the documentation should live, which is yours to make rather than mine. Point at any of them and I will send a follow-up.

Checks

Comments only, no declaration touched. The check reported 24 before and 16 after, and the sixteen left are exactly the group described above.

Found with a small tool that pulls every \param and \tparam name out of a Doxygen block and compares it against the declaration that follows, then re-run afterwards to confirm the count moved by exactly the number of edits.

Every projection class in srs/projections/proj is
`template <typename T, typename Parameters>`, but the Doxygen block above
each one still documents `Geographic` and `Cartesian`, the parameters
these classes took before ddce41f (Apr 2017) moved the internal
representations. `T` has been undocumented since.

All 152 blocks in 99 headers were byte-identical and every one is
followed by `template <typename T, typename Parameters>`, so this is a
straight replacement. The wording for `T` is taken from
srs/projections/impl/base_dynamic.hpp, which already documents the same
type as "calculation type".

Comments only.
- clip_linestring.hpp: the Liang-Barsky strategy documents \tparam B and
  \tparam P, the template takes Box and Point.
- simplify.hpp: douglas_peucker_point writes '\tparam the enclosed point
  type', so Doxygen reads 'the' as the parameter name. It is Point.
- azimuth.hpp: default_strategy documents CalculationType, the template
  has only CSTag.
- transform.hpp: the four lines read '\tparam CoordinateSystemTag 1,2
  coordinate system tags', meaning both at once, so Doxygen sees a name
  that does not exist. Split into the eight real parameters. Source and
  target follow from transform(Geometry1 const&, Geometry2&), where the
  second one is the mutable output.

Comments only.
@barendgehrels

Copy link
Copy Markdown
Collaborator

Thanks! I think this include the other PR #1485
So we only need to review this one? If so, can you close the other one?

@karpovantonme

Copy link
Copy Markdown
Author

Yes, this one includes 1485 -- I diffed them, all 251 added lines of 1485 are in here, plus 11 more \tparam lines in clip_linestring.hpp and simplify.hpp that turned up in a second pass

Closing 1485 now, so this is the only one to review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants