generated from NOAA-OWP/owp-open-source-project-template
-
Notifications
You must be signed in to change notification settings - Fork 63
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
Geojson optimization #444
Merged
Merged
Geojson optimization #444
Changes from all commits
Commits
Show all changes
16 commits
Select commit
Hold shift + click to select a range
ef4dbed
move PropertyMap typedef with other type definitions
hellkite500 fb91f58
remove TODO
hellkite500 8d51dc5
move strings to prevent yet another copy
hellkite500 e5f3070
another minor reference/copy optimization
hellkite500 252e7fe
use initializer lists more consistently
hellkite500 5168d9f
rework lexical casting to avoid millions of excpeptions on large data
hellkite500 ccb26a8
Finish implementing variant type for all JSONProperty data
hellkite500 4e51a54
more resource stealing and management
hellkite500 d15d787
update vector visitor, use SFINAE for overload
hellkite500 2aa6855
fix List pointer intitialization
hellkite500 efd46a4
fix Object pointer initialization
hellkite500 66dc64f
fix copy constructor
hellkite500 c62c4ed
don't use List indirection if not required
hellkite500 4045e08
remove old print
hellkite500 0764fdb
fix handling of empty data in property tree
hellkite500 ae4ac20
Additional test coverage for nested list/object and edge cases like e…
hellkite500 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 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 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 think that
std::move
might end up ripping stuff off offchild
here. It's hard to tell here without having example docs in front of me, but it looks like there's a chance that thesestd::move
operations might modify the tree and bubble up the updates, harming reuse. There might need to be some comments highlighting this so it's easier to identify while skimming.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.
Once processed and recorded does the state of that node in the ptree really matter? The reference in the tree should still be valid if I understand the semantics of move correctly, but even if it isn't does it matter in this context?
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's why I'm not sure - if the
ptree
isn't used afterwards, no one cares, butstd::move
stands to "replace" values (I'm assuming arrays?) when moving. Strings, for example, stand to be converted to empty strings after movement (new location still gets the correct value, though). This specific line isn't a good example; I just picked one of the moves to put a comment about moves. I think the biggest risk is when moving stuff into vectors. I'm not the expert, so I can easily be missing 90% of what's going on. That's sort of the reason I suggested adding comments instead of actually changing code. If someone comes along further down the line (most likely a goober like me) and expects the state of the tree to remain the same they might be in for a rude awakening.std::move
was a really good idea, so I'm not disputing its use.