-
Notifications
You must be signed in to change notification settings - Fork 448
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
Refactor Util::Enumerator #4513
Conversation
@fruffy This is the change that gives that p4tools testcase speedup due to removal of |
@fruffy What is |
Compilation failed due to gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90031 |
We pin it to 15.0.6 https://github.com/p4lang/p4c/blob/main/requirements.txt#L7 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I do not have many comments on the technical side, it's probably best other stakeholders look at the changes here.
: Enumerator<typename Iter::value_type>(), | ||
begin(begin), | ||
end(end), | ||
current(begin), | ||
name(name) {} | ||
|
||
public: | ||
cstring toString() const { return this->name + ":" + this->stateName(); } | ||
[[nodiscard]] std::string toString() const { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm most other toString
functions return a cstring. I am not certain whether we should refactor this spotwise or do it all at once it one single PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I'd go for small iterative changes. Otherwise this (cstring
change) would end with something of enormous size that is impossible to review / digest
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine with me. We should define some form of heuristic to decide when to use a cstring. toString
might be fairly benign for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I'm planning to do first sweep one day to get rid of most obvious cases (e.g. we do not need to cstring of format strings or jsons). Then we can discuss the proper API (cstring vs std::string
vs std::string_view
usage)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then we can discuss the proper API (cstring vs
std::string
vsstd::string_view
usage)
And document it somewhere 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks okay to me too.
: Enumerator<typename Iter::value_type>(), | ||
begin(begin), | ||
end(end), | ||
current(begin), | ||
name(name) {} | ||
|
||
public: | ||
cstring toString() const { return this->name + ":" + this->stateName(); } | ||
[[nodiscard]] std::string toString() const { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then we can discuss the proper API (cstring vs
std::string
vsstd::string_view
usage)
And document it somewhere 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall, but I have concerns about some details.
f3c91ac
to
fc45577
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice cleanups!
Though I think ideally we'd like to move away from these java enumerators to more static C++-style ones.
This is the plan. But one step at a time. We rely on this type-erased things heavily in few places... |
60058ef
to
12a8cc7
Compare
@vlstill Refactored |
12a8cc7
to
563d685
Compare
…used as a bit non-standard InputIterator
…ed to std::function indirection and type erasure
Ensure Values() could be used like "container".
53d1ef0
to
eb2cdab
Compare
@vlstill Will you please check the refined PR. Does it address your comments? Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the changes! Sorry I forgot about needing to re-review this one.
Restore parentheses that were accidentally dropped from begin call as part of recent code improvements (#4513).
* restore missing parentheses Restore parentheses that were accidentally dropped from begin call as part of recent code improvements (#4513). * add basic test for ValuesForKeys from map.h
ICastable
forAsEnumerator
std::function
type-erasure forFilterEnumerator
, make it less memory hogConcatEnumerator
sane, do not do tons of memory allocations each timeConcatEnumerator
is createdenumerate
/concat
)EnumeratorHandle
behave asForwardIterator
, so STLinsert
, etc. are working withEnumerator
Values
and other things fromlib/map.h
could be used withEnumerator
, improve here const-correctness & remove deprecatedstd::iterator
usage in favor of iterator traitslib/enumerator.h
, make itcstring
-less