Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Make path extension a bit safer#30208

Merged
anntzer merged 4 commits intomatplotlib:mainfrom
QuLogic:more-cpp17
Sep 18, 2025
Merged

Make path extension a bit safer#30208
anntzer merged 4 commits intomatplotlib:mainfrom
QuLogic:more-cpp17

Conversation

@QuLogic
Copy link
Member

PR summary

By replacing double pointers bystd::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

@QuLogicQuLogic added the CI: Run cibuildwheelRun wheel building tests on a PR labelJun 24, 2025

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 thatsize is small enough (I guess the "modern C++" way of ensuring that is to make NUM_VERTICES an int templated oncode etc.)

Copy link
MemberAuthor

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, andx[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-actionsgithub-actionsbot removed the CI: Run cibuildwheelRun wheel building tests on a PR labelJun 24, 2025
@QuLogic
Copy link
MemberAuthor

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

@QuLogic
Copy link
MemberAuthor

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

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

@QuLogicQuLogic mentioned this pull requestSep 12, 2025
5 tasks
Copy link
Contributor

@scottshambaughscottshambaugh left a comment
edited
Loading

Choose a reason for hiding this comment

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

Looks cleaner & safer to me, no changes stand out

... by replacing double pointers by fixed-size `std::array`, or a return`tuple`. With gcc (and optimization enabled?), this has no effect oncode size, but gives compile-time (and better runtime) checks that thereare no out-of-bounds access.
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 compilerwarns about a possible ODR violation (which isn't a problem since it'sonly used in one file.)
By using the existing `XY` type to replace x/y pairs, and takingadvantage of struct methods.
Use `XY` type to shorten internals, and `agg::rect_d::normalize` toshorten initialization.
@QuLogic
Copy link
MemberAuthor

I just noticed that6d5dd9a was empty, so I'll rebase that out.


void update(double x, double y)
{
start.x = std::min(start.x, x);
Copy link
Contributor

@anntzeranntzerSep 17, 2025
edited
Loading

Choose a reason for hiding this comment

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

Is the new form equivalent to the old one if either start.x or x is nan? (Ditto for all other similar changes.)
(It's also possible that the answer is "we never have nans here and it doesn't matter", I haven't checked.)

Copy link
MemberAuthor

@QuLogicQuLogicSep 18, 2025
edited
Loading

Choose a reason for hiding this comment

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

get_path_collection_extents always starts with areset so it should start with max/min infinity. And thenupdate_path_extents calls.update after aPathNanRemover. So we should never have NaN in either.

anntzer reacted with thumbs up emoji
Copy link
Contributor

@anntzeranntzer left a comment

Choose a reason for hiding this comment

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

Approval modulo one question re: interactions with nans.

@anntzeranntzer merged commit74beb8d intomatplotlib:mainSep 18, 2025
39 of 42 checks passed
@QuLogicQuLogic deleted the more-cpp17 branchSeptember 18, 2025 07:11
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@jkseppanjkseppanjkseppan approved these changes

@anntzeranntzeranntzer approved these changes

@scottshambaughscottshambaughscottshambaugh approved these changes

Assignees

No one assigned

Projects

None yet

Milestone

v3.11.0

Development

Successfully merging this pull request may close these issues.

5 participants

@QuLogic@jkseppan@anntzer@scottshambaugh@tacaswell

[8]ページ先頭

©2009-2026 Movatter.jp