Conversation
| bool isPentagon = isBaseCellPentagonArr[baseCellNumber]; | ||
|
|
||
| for (int r = 1; r <= res; r++) { | ||
| int d = digits[r - 1]; |
There was a problem hiding this comment.
Practically speaking, the user can pass in an array of length res - 1. Is this intended behavior and part of the function contract, or must a user always pass an array of length 15?
There was a problem hiding this comment.
The user doesn't need to pass in an array of length 15 unless they're making a res 15 cell.
The function just takes in a pointer, which we assume points to an array of length res:
H3Error constructCell(int res, int baseCellNumber, int *digits, H3Index *out);
There was a problem hiding this comment.
We will need to document that for the C API, as users will make shorter arrays and the function must never attempt to index beyond the end of the array. I would include that in the docstring for this, when describing what the int *digits parameter means.
There was a problem hiding this comment.
Added docs in h3Index.c, which is what we typically do.
Thought: Wouldn't it make more sense to document function params and other things relevant to the API in h3api.h.in? I forget if we have a historical reason for why we tend to keep the documentation fairly light in the header file, but more detailed in the implementation. It makes sense to keep algorithm descriptions and internal details there, but I'd think we'd want the API spec in the header, right? cc: @isaacbrodsky @dfellis @nrabinowitz
But I might be forgetting why we do it this way. And this is definitely a discussion we can continue elsewhere.
Co-authored-by: Isaac Brodsky <[email protected]>
Co-authored-by: Isaac Brodsky <[email protected]>
Co-authored-by: Isaac Brodsky <[email protected]>
Taking over from #1037.
constructCellconstructs a valid h3 cell from components (resolution, base cell, digits).E_BASE_CELL_DOMAIN,E_DIGIT_DOMAIN,E_DELETED_DIGITsubtasks:
justfile