-
Notifications
You must be signed in to change notification settings - Fork 1.5k
pass a char buffer to simplecpp instead of a stream #6379
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
Open
firewave
wants to merge
12
commits into
danmar:main
Choose a base branch
from
firewave:charbuf
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
7870b35
make it possible to pass char buffer to simplecpp
firewave 630e51d
pass a char buffer to simplecpp instead of a stream
firewave 7eba3a2
cppcheck.cpp: mitigated `unusedFunction` selfcheck warnings
firewave baf9fd7
removed unnecessary usage of `std::istringstream`
firewave d4845f7
removed unused stream-related functions
firewave c6902d0
testrunner: removed more `std::istringstream` usage
firewave da90a76
removed remaining stream usage from checking
firewave 7ce5e45
made some function names more descriptive
firewave 6e60bfc
democlient/democlient.cpp: fixed size of input
firewave 4b7d813
cleaned up passing of buffers
firewave f370d81
mitigated `unusedFunction` selfcheck warnings
firewave b516b96
CppCheck: small cleanup
firewave File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I dislike this interface. 1 parameter is switched to 2 parameters and it's not because we want to separate them.
isn't modern c++ guidelines advocating that span/string_view is used instead of raw-pointer+size this is a step in opposite direction.
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.
It's an rather internal interface and this removes all unnecessary wrappers and shows the actual intention.
As usual the changes made are incremental. The next step after this is to merge danmar/simplecpp#496 and get it downstream so further cleanups can be made. With the code clean and more interfaces into simplecpp available it should be clearer on how to proceed.
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.
I think what you want to have is performance, getting rid of memory allocation and data copy, right?
What I want is a function interface that does not have a pointer+size pair and I would like a type that makes it as clear as possible that it is the raw code to process.
In my humble opinion we do not have conflicting requests. How about this:
Uh oh!
There was an error while loading. Please reload this page.
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.
I would not be against that FileData would have similar interface as string_view (with only the methods that we use). We can then have the option (using #ifdef) to just use a string_view alias instead:
And I guess that could lead to improved static analysis etc.
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.
That is rather awkward and I would like to have something which can be used without adjusting the code when we ever switch. But I do not want to do this in this PR. And without a clean base that cannot be properly tested and we also need a clean baseline to profile against.
As mentioned above that will be done in follow ups.
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.
It does more than just adjust that single interface and it will be changed in the future. We need clean code to move to something else instead of some intermediate mishmash. Moving to something else intermediate will only complicate things if I want to compare the implementations - which would actually not be possible at all to compare since there will always be a mix of various interfaces if we never had it clean to begin with.
Uh oh!
There was an error while loading. Please reload this page.
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.
I would like to understand what the plan is really. I don't want to have char buffers all over the place. I suggest we remove the buffer inputs from simplecpp directly
string_view is safer than a plain old char pointer. the reason string_view was invented was to improve safety and expressiveness.
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.
and I don't understand why we should convert to char buffers everywhere first and then change to something else later. that sounds like "intermediate mishmash" to me :-(
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.
ah.. I see that there is work in progress in danmar/simplecpp#496 👍
It would feel much better if we merge 496 first and then use the safe interface..
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.
The plan is to get rid of all unnecessary (inefficient) wrappers so data can be passed through directly and the interfaces can be cleaned up.
This PR for instance gets rid of the
std::istream
input which was never necessary.And as outlined above. The next steps are getting the modern
simplecpp::TokenList
interface in so we clean up more things. And to clean up more of the tests.The production code would then be clean and only the test might still have some mishmash but the interfaces for that can then be moved there and the production code can get some thin wrappers which allows for modern stuff to drop-in. (As using Qt implicitly switches to C++17 that could already be used and tested).
Doing this all as whole would be hard-to-review, making profiling the various implementations impossible and also might make it harder to pinpoint potential issues.
In production code we do not have any actual char buffers at all. We only pass as such. The buffers are where data comes from memory (fuzzer, democlient) or string literals in tests. In the latter case we can deduce it via template and can mostly pass it on.
That is what danmar/simplecpp#496 is essentially doing.
You mainly gain bounds safety and simplified interfaces. But it is still a massive footgun because people think it is all safe but if you use it wrong it might be even harder to figure out what is wrong than before (and also lifetime dependencies). But let's stay on topic...
We no longer do that in production code after this PR. The buffer goes straight into
simplecpp::TokenList
.