Repository navigation
Compile-time caps are undocumented in the README #4
Description
What is missing
The library has three fixed compile-time caps because its working set is statically sized and the implementation avoids dynamic allocation.
| Constant | Value | Header |
|---|---|---|
kMaxPathKnots |
65 | include/motionkit/core/cartesian.hpp:20 |
kMaxWaypoints |
16 | include/motionkit/core/cartesian.hpp:90 |
kMaxObstacles |
32 | include/motionkit/core/collision.hpp:17 |
These limits are documented in the headers.
They are not documented in the README.
As a result, somebody evaluating the library cannot discover, for example, that a route with 20 waypoints cannot currently be represented without reading the source or hitting TooManyWaypoints.
Why it matters
A 16-waypoint cap is a real constraint on a real application.
The reason for the cap is also legitimate: fixed storage preserves the library's no-allocation behaviour.
A constraint with a deliberate engineering reason should be advertised rather than discovered at runtime.
Acceptance criteria
- Add a short README section listing all public compile-time caps.
- Include their current values.
- Explain in one sentence why the limits exist.
- Decide whether these limits are intended to be user-overridable.
- If they are overridable, expose the configuration through CMake rather than asking users to edit headers.
- Add a build/test configuration using non-default cap values.
- If they are intentionally not overridable, document that explicitly.
Activity
nightcityblade commentedon Sep 12, 2026
Hi, I'd like to work on this. I'll submit a PR shortly.
Onwcan commentedon Sep 12, 2026
Hi @nightcityblade
Thanks for picking this up and for opening #5. I've left a few review notes on the PR, so let's continue the implementation discussion there.
Also, since this repository has several
good first issueitems, please leave some of them available for other contributors as well, especially newcomers who are looking for their first contribution.