Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

QuLogic
Copy link
Member

@QuLogic QuLogic commented Jun 24, 2025

PR summary

By replacing double pointers by std::array and returned tuples. AFAICT, this doesn't have any effect on code size, but ensures that several places are checked at compile time. And for now, we already know these to be correct, but this would prevent any future problems if some sizes change.

PR checklist

@QuLogic QuLogic added the CI: Run cibuildwheel Run wheel building tests on a PR label Jun 24, 2025
double last_x = 0.0;
double last_y = 0.0;

unsigned code;

while ((code = path.vertex(&x[0], &y[0])) != agg::path_cmd_stop) {
while ((code = path.vertex(&std::get<0>(x), &std::get<0>(y))) != agg::path_cmd_stop) {
Copy link
Contributor

@anntzer anntzer Jun 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can still do &x[0] no? (or x.at(0) if you really want bounds checking here; this still reads better than std::get I'd say)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

std::get is compile-time checked for constants; neither x[0] nor x.at(0) are unfortunately.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ugh, indeed, that's a bit annoying...

if (code == CLOSEPOLY) {
buffer += codes[4];
buffer += std::get<4>(codes);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

} else if (code < 5) {
size_t size = NUM_VERTICES[code];

for (size_t i = 1; i < size; ++i) {
unsigned subcode = path.vertex(&x[i], &y[i]);
unsigned subcode = path.vertex(&x.at(i), &y.at(i));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the compiler can safely elide the bounds check here, because it'll have trouble proving that size is small enough (I guess the "modern C++" way of ensuring that is to make NUM_VERTICES an int templated on code etc.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, x.at is the bounds-checked version, and x[i] isn't, but somehow the compiled code remains the same size either way. (Perhaps this is because the Fedora compiler has hardening enabled somewhere?)

@github-actions github-actions bot removed the CI: Run cibuildwheel Run wheel building tests on a PR label Jun 24, 2025
@tacaswell tacaswell modified the milestone: v3.11.0 Jun 26, 2025
... by replacing double pointers by fixed-size `std::array`, or a return
`tuple`. With gcc (and optimization enabled?), this has no effect on
code size, but gives compile-time (and better runtime) checks that there
are no out-of-bounds access.
... by avoiding double pointers.
It is `bool` for the Python wrapper, while internally `int`, but can be
`bool` consistently.

Also mark it as `inline` since it's used in a template and the compiler
warns about a possible ODR violation (which isn't a problem since it's
only used in one file.)
By using the existing `XY` type to replace x/y pairs, and taking
advantage of struct methods.
Use `XY` type to shorten internals, and `agg::rect_d::normalize` to
shorten initialization.
@QuLogic
Copy link
Member Author

QuLogic commented Sep 11, 2025

Instead of the tuple, I thought it better to use the XY type we already have here. Also tacked on changing to that for the extent limits struct as well.

@QuLogic
Copy link
Member Author

QuLogic commented Sep 12, 2025

Instead of the tuple, I thought it better to use the XY type we already have here.

A secondary reason is it makes extension to 3D a bit simpler, as we can eventually template on XY and (to be PR'd) XYZ somewhat straightforwardly.

@QuLogic QuLogic mentioned this pull request Sep 12, 2025
5 tasks
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.

4 participants