Skip to content
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

Use a chrono::duration type as underlying time representation #49

Open
sansumbrella opened this issue Jul 27, 2016 · 1 comment
Open

Comments

@sansumbrella
Copy link
Owner

sansumbrella commented Jul 27, 2016

As demonstrated by the date library, std::chrono operations compile down to simple numeric operations without any extra type information. This means calculations with duration<double, seconds::period> are the same as calculations with double.

As a benefit, we would get explicit temporal information in our timestep.

  .rampTo(10.0f, Seconds(1.5))
  .rampTo(20.0f, Seconds(1.0) + minutes(2));

On a current project, I have a constexpr converting chrono types to double to pass through to Choreograph. Will be nice to skip that extra writing. Will, however, require explicitly defining the incoming time type.

sansumbrella pushed a commit that referenced this issue Jul 27, 2016
Placeholders converting from chrono::seconds to double
for animation. Will eventually replace all use of double with
std::chrono per gh #49.
sansumbrella pushed a commit that referenced this issue Jul 27, 2016
Placeholders converting from chrono::seconds to double
for animation. Will eventually replace all use of double with
std::chrono per gh #49.
@sansumbrella
Copy link
Owner Author

sansumbrella commented Aug 1, 2016

Alternatively, provide methods that perform the chrono conversion as needed (it might be annoying to always specify Seconds(1.5) rather than just pass in a number).

User-defined literals might alleviate, too, though their could be ambiguity with chrono literals. Consider sec and msec to disambiguate. Alternatively, defining the literal for double could cause our s suffix to take precedence.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant