Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify and clang tidy #460

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

rpavlik
Copy link
Contributor

@rpavlik rpavlik commented Aug 20, 2019

Take or leave any subset of these patches. They're all split by topic for easy cherry-picking.

@whitequark
Copy link
Contributor

whitequark commented Sep 10, 2019

Thanks, I've cherry-picked most of this PR. Could you please rebase it so we can discuss the rest? There are a few things I'd like to see changed.

The main of them is the clang-tidy configuration that causes it to put small functions and loops/conditionals entirely on one line (which IMO makes the code more annoying to read); ideally it'd not reformat the functions that way at all, and maybe match loops/conditionals to the existing style better, but the second part isn't as important.

The rest are something I'd like to discuss in review.

@whitequark
Copy link
Contributor

@rpavlik Also, looks like tests crash on Windows now. Could you please take a look? https://ci.appveyor.com/project/whitequark/solvespace/builds/27299022

@whitequark
Copy link
Contributor

Looks like the crash is caused by "Range-for conversions and improvements. NFC."

@rpavlik
Copy link
Contributor Author

rpavlik commented Sep 10, 2019

Yeah, I have hung my machine twice now attempting to run the tests for that commit with sanitizers from GCC enabled. (It was all fine with Clang...) I've dropped that patch from this series, will figure it out separately. (Yes, I am now testing that each commit in a branch can be built and passes tests before pushing - embarassed myself too much recently with broken commits.)

I have adjusted the clang-format file and re-formatted my changes here as well to reduce the number of one-line things that get created.

@rpavlik rpavlik mentioned this pull request Sep 10, 2019
@whitequark
Copy link
Contributor

@rpavlik This PR still fails on Windows.

src/polygon.h Outdated
void Generate(std::function<void(Vertex *start, Vertex *next, Edge *edge)> const &startFunc,
std::function<void(Vertex *next, Edge *edge)> const &nextFunc,
std::function<void(Edge *)> const &aloneFunc,
std::function<void()> const &endFunc = []() {});
Copy link
Contributor

Choose a reason for hiding this comment

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

What does this actually guarantee?

Copy link
Contributor Author

@rpavlik rpavlik Sep 12, 2019

Choose a reason for hiding this comment

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

the change to add const & there prevents copying of the functor object, which can be expensive. The requirement is that the Generate function shouldn't hold those references longer than its call (or longer than the lifetime of the thing being passed in, which is at least as long as the call).

I see I accidentally did east-const there instead of west-const. I'll take that as a TODO.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh yeah, I got confused by std::function<> const, it should really be const std::function<>. I wasn't sure if the semantics is identical.

src/polygon.cpp Outdated Show resolved Hide resolved
@whitequark
Copy link
Contributor

Merged a few more commits from here. In "Simplify returns and booleans. NFC.", most of the changes make the code less readable, and a few comments no longer explain what's happening, so you can drop that one.

@rpavlik
Copy link
Contributor Author

rpavlik commented Sep 12, 2019

ok, guess I will reboot into Windows for this :) (the bug is in the const/const-refs commit - pulled that one from this branch to a separate one)

@whitequark
Copy link
Contributor

Merged everything except FindIndex changes. Do we really have no better approach here than returning -1 if it's not found? Morally it seems like FindIndex ought to return size_t.

@nabijaczleweli
Copy link
Contributor

FWIW, the std::string::find() API just returns (size_t)-1 when the needle wasn't found, which has the added benefit of both returning the correct type and having an explicitly-named sentinel (npos, in that case), rather than an unclear < 0 check.

@whitequark
Copy link
Contributor

Yeah that'd probably be fine.

These are generic and work with List and IdList,
as well as vector<> and raw arrays.
@rpavlik
Copy link
Contributor Author

rpavlik commented Dec 9, 2019

Rebased to leave the one commit not cherry-picked yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants