Improvements to C++ MakePath/MakePathD #401
Merged
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.
Thanks for pulling in PR #398, but I think it may have an error. To explain, the
static_assert
in my original PR is evaluated only at compile-time, and will cause the build to terminate on an odd number oflist
values. However, the altered version allows the compiler to emit aMakePath
with an odd numberedlist
, which when called would result in an out-of-bounds read fromlist
. This PR fixes the bug by adding back thestatic_assert
(I figure it's better to have the compiler simply prevent the bug instead of having to deal with one that appears at run-time).Also,
MakePath
/MakePathD
in PR #398 wouldn't accept a dynamically allocatedlist
argument, but in retrospect it probably should have since the versions for other languages do. So, I added vector accepting versions (which useDoError
since they have to check the length at runtime). To simplify the code I also moved the vector initialization into thedetails::MakePathGeneric
helper function.One other thing I should probably highlight is that the implementation of
details::MakePathGeneric
is structured to maximize what the compiler can evaluate at compile-time rather than run-time. There are certainly other ways to write it, but in my experience this should minimize the amount of unnecessary runtime code that gets generated.