Reduce copying in API parameter constructors #5926
Merged
Conversation
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
When using non-default constructors for the API parameter classes, vector arguments like coordinates and hints are copied at least once (twice when passed as lvalue arguments). Enable perfect forwarding of BaseParameter arguments and pass-by-value in the constructor that uses the argument. This ensures we copy at most once (zero for rvalue arguments).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Issue
When using non-default constructors for the API parameter classes, vector arguments like
coordinatesandhintsare copied at least once (twice when passed as lvalue arguments).This PR enables perfect forwarding of
BaseParametersarguments and pass-by-value/move in the constructor that uses the argument. This ensures we copy at most once (zero for rvalue arguments).There is one case that I have omitted from forwarding -
waypointsinMatchParameters, which inherits fromRouteParametersand has a slightly different argument order that complicates things. I've left it as-is for readability.Impact
This will have no effect on requests made to
osrm-routedor via NodeJS bindings as they both use the default constructor and build parameters incrementally. It only impacts libosrm API usage of non-default*Parametersconstructors.Requirements / Relations
There is previous discussion in #2991 about enabling perfect forwarding in these constructors, suggesting this would break the libosrm API. Unless this is referring to a binary compatibility issue which I'm not aware of, I don't think this is a problem.
With this change, lvalue arguments will still be copied, and rvalue arguments will be moved from, which should meet the expectation of the caller.
Tasklist