-
-
Notifications
You must be signed in to change notification settings - Fork 401
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
Implement Constexpr Strong Typedef #861
Merged
jwellbelove
merged 7 commits into
ETLCPP:pull-request/#861-Implement-Constexpr-Strong-Typedef
from
drewr95:feature/838-strong-typedef-constexpr
Mar 13, 2024
Merged
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
adb50a6
feat: make type_def constexpr
drewr95 0617696
test: macro constexpr
drewr95 089c122
test: implicit constexpr
drewr95 f1d4ef9
test: get constexpr
drewr95 35d2226
refactor: remove constexpr from assignment
drewr95 014dc5d
test: comparisons constexpr
drewr95 11c92d5
fix: cpp11 support for constexpr get method
drewr95 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
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.
@jwellbelove I believe I may have mistaken this part. I think for C++11 users this will make the TValue reference be const? In C++14 they loosened the restrictions on what constexpr meant, so methods didn't have to be necessarily constexpr to have the keyword for it. I can change this quickly if you suspect this is the case.
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, it is normal to not have
constexpr
on both the const and non-const functions.I'm pretty sure you don't need the
#if ETL_USING_CPP14
, unless I'm missing something.I'm also sure that the
operators
can also be constexpr.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.
What would you like? I thought for CPP11 constexpr was strict? I can leave the constexpr off the get methods. As far as operators, I left the assignment operators (*=, +=, -=, ++, --, etc) not constexpr because there wasn't a way for me to test them. In C++14 it would have been okay to make them constexpr because of the more lax rules. But I'm pretty sure that would have failed the C++11 actions. I think i'll just leave the gets as non-constexpr and open a new 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.
I found I get a compile error if I've set both const and non-const versions of a member function
constexpr
.The operators can be tested by making a unit test that is only enabled for C++14 and above.
The CI that I run locally, and on Github Actions, test with C++11, C++14, C++17 & C++20
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 will update the tests for C++14 and above, 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.
I'm not quite sure how they can be constexpr without specifying
#if ETL_USING_CPP14
, can you clarify? It's not making sense how the C++11 builds would pass since all the operator *= += -= tests will be non-constexpr. As you pointed out, I would have to create separate tests for C++14 and above - which is "ETL_USING_CPP14" if I'm not mistaken. Why would the tests need differentiated but not the implementation?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.
Part of me thinks the assignment operators shouldn't be marked constexpr regardless because you can't manipulate a constexpr variable. So I almost feel like the PR should stay the way it is (I removed the constexpr keywords from the get and assignment operators).
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.
You can able to use
constexpr
operators inside aconstexpr
function that returns aconstexpr
object.Example
https://godbolt.org/z/rPqW17xPx
There is more than one
constexpr
macro.ETL_CONSTEXPR
orETL_CONSTEXPR11
Defined asconstexpr
for C++11 and aboveETL_CONSTEXPR14
Defined asconstexpr
for C++14 and aboveETL_CONSTEXPR17
Defined asconstexpr
for C++17 and aboveETL_CONSTEXPR20
Defined asconstexpr
for C++20 and aboveYou use the one that is appropriate for the code.
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, much appreciated! I will get right on that
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'm still getting build errors. I'm kind of stumped. The lambdas were nice to keep the typedefs local to the test functions. If I move the lambdas out to constexpr free functions like your godbolt-linked example, then the typedef will need to exist at a scope outside of the tests (which will conflict with the tests). Unless you're okay with that or have another suggestion