-
Notifications
You must be signed in to change notification settings - Fork 139
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* added compound assignment operators: +=, -=, *=, /=. Closes #44. * print undefined unit types in SI base units. Closes #38. Update constants to NIST 2014 CODATA recommendations. * Reduce metaprogramming boilerplate * workaround for vs2013 internal compiler error * added data and data transfer units. Closes #46. * update doxyfile.in to v2.2.0 * add constexpr std::array test * add julian and gregorian year definitions. Closes #29. * added `value()` and `value_type` trait. Closes #56. * fixes constexpr relational operator bug. Closes #63. * improve compile time. * removed some debug code. * measure compile time * Friend the linear scale units. Reduces compile time. * add inline to pow() and abs() for being able to use units.h in different compilation units * Revert "Friend the linear scale units. Reduces compile time." This reverts commit e26fcd7. * Revert "add inline to pow() and abs() for being able to use units.h in different compilation units" This reverts commit d42020e. * add inline to pow() and abs() for being able to use units.h in different compilation units * Test with Visual Studio 2017 * Another attempt at using Visual Studio 2017 in appveyor * Build with VS2017 * add MSVC2017 badge * started min/max * fixes #65, fixes #71, fixes #76, fixes #79, fixes #80. Adds documentation. * fix for vs2013, gcc * updated docs * fix for vs2013 * remove gcc warnings, add prefined unit defines * min/max shouldn't be constexpr * fix cmake * more cmake fixes * numeric_limits namespace * fixes #77. * fixes #75 & documentation * fixed merge issues * for Morwenn * Make the project work with both ninja and msvc generators on windows * Fixes #106. Locale aware `to_string` conversions. * Fixes #105. Unary operators. Also removes VS 2013 testing (and support) * Fixes #87. Don't include `to_string()` when iostream is disabled. * fix a mistake in the unary +/- * Add constexpr name/abbreviation member functions which don't require iostream. * Fixes for linux build
- Loading branch information
Showing
8 changed files
with
267 additions
and
37 deletions.
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
{ | ||
// See https://go.microsoft.com//fwlink//?linkid=834763 for more information about this file. | ||
"configurations": [ | ||
{ | ||
"name": "Debug", | ||
"generator": "Ninja", | ||
"configurationType": "Debug", | ||
"inheritEnvironments": [ "msvc_x64_x64" ], | ||
"buildRoot": "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\build\\${name}", | ||
"installRoot": "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\install\\${name}", | ||
"cmakeCommandArgs": "", | ||
"buildCommandArgs": "-v", | ||
"ctestCommandArgs": "" | ||
}, | ||
{ | ||
"name": "Release", | ||
"generator": "Ninja", | ||
"configurationType": "RelWithDebInfo", | ||
"inheritEnvironments": [ "msvc_x64_x64" ], | ||
"buildRoot": "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\build\\${name}", | ||
"installRoot": "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\install\\${name}", | ||
"cmakeCommandArgs": "", | ||
"buildCommandArgs": "-v", | ||
"ctestCommandArgs": "" | ||
} | ||
] | ||
} |
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
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.
3252189
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.
std::numeric_limits
is for arithmetic types or types emulating those. Evenstd::chrono
provides no specializations for it. It also fails to meet its requirements. It might be useful for somebody someday, so maybe you'll want to keep it for dimensionlessunit
s.3252189
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.
In my mind, units are arithmetic types. Agree that they don't meed the definition for that, but they are in a spirit-of-the-law way. I think
numeric_limits
for units should meet the requirements (will fix for v3), and if I were amending the ISO std to talk about units I'd say something to the effect of... only much better worded.
3252189
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.
Maybe I'm being too pedantic. Following from your amend, the correct implementation would simply derive from
std::numeric_limits<T>
.3252189
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.
yeah, that sounds good