I want to gauge if there is interest in the following.

The value returned by chrono::duration<Rep,Period>::count() is the
tick count in units of Period. If we want this count in another unit,
we must use chrono::duration_cast.

We could add a convenience function to return the tick count in another
unit directly. For example:

   chrono::seconds s{2};
   auto ms = chrono::count<chrono::milliseconds>(s);
   assert(ms == 2000);

Another overload can be added for chrono::time_point

   auto now = chrono::steady_clock::now();
   auto ms = chrono::count<chrono::milliseconds>(now);

Example implementations are:

   template <typename ToDuration, typename Rep, typename Period>
   typename ToDuration::rep count(const chrono::duration<Rep, Period>& d)
   {
     return chrono::duration_cast<ToDuration, Rep, Period>(d).count();
   }

   template <typename ToDuration, typename Clock, typename Duration>
   typename ToDuration::rep count(const chrono::time_point<Clock,
Duration>& t)
   {
     return chrono::duration_cast<T, typename Duration::rep, typename
Duration::period>(t.time_since_epoch()).count();
   }

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1b10bb5f-9861-b3b8-eb3c-bd246715b7c4%40mail1.stofanet.dk.

.

--Apple-Mail=_ECC9130B-8CC9-4038-8FF7-17DB12669FDB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

On Mar 14, 2017, at 4:52 PM, Bjorn Reese <breese@mail1.stofanet.dk> wrote:
>=20
> I want to gauge if there is interest in the following.
>=20
> The value returned by chrono::duration<Rep,Period>::count() is the
> tick count in units of Period. If we want this count in another unit,
> we must use chrono::duration_cast.
>=20
> We could add a convenience function to return the tick count in another
> unit directly. For example:
>=20
>  chrono::seconds s{2};
>  auto ms =3D chrono::count<chrono::milliseconds>(s);
>  assert(ms =3D=3D 2000);
>=20
> Another overload can be added for chrono::time_point
>=20
>  auto now =3D chrono::steady_clock::now();
>  auto ms =3D chrono::count<chrono::milliseconds>(now);
>=20
> Example implementations are:
>=20
>  template <typename ToDuration, typename Rep, typename Period>
>  typename ToDuration::rep count(const chrono::duration<Rep, Period>& d)
>  {
>    return chrono::duration_cast<ToDuration, Rep, Period>(d).count();
>  }
>=20
>  template <typename ToDuration, typename Clock, typename Duration>
>  typename ToDuration::rep count(const chrono::time_point<Clock, Duration>=
& t)
>  {
>    return chrono::duration_cast<T, typename Duration::rep, typename Durat=
ion::period>(t.time_since_epoch()).count();
>  }

Personally I=E2=80=99d vote against it.  I regularly help people who are le=
arning <chrono> and one of the most common mistakes I see is overuse of the=
 .count() (and .time_since_epoch()) function.  These should be considered =
=E2=80=9Cescape hatches=E2=80=9D out of the type-safe chrono library, mainl=
y for use in interfacing with code not aware of chrono.  The .count() is no=
thing but a cast from a time duration to an arithmetic type.

Something that encourages this cast, or adds more complication under the ho=
od, is something I don=E2=80=99t think we want to do.  Instead we want to e=
ncourage C++ programmers to stay _in_ the type-safe chrono system.  If prog=
rammers do so, they are more likely to have their time-related logic errors=
 be caught at compile time by the type system.

 chrono::seconds s{2};
 chrono::milliseconds ms =3D s;
 assert(ms =3D=3D 2000ms);
 assert(ms =3D=3D 2s);

Howard

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5F669DFA-D552-4960-81DA-5906A4FB92AE%40gmail.com=
..

--Apple-Mail=_ECC9130B-8CC9-4038-8FF7-17DB12669FDB
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename=signature.asc
Content-Type: application/pgp-signature;
 name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYyFpQAAoJEGbcHCxKqhWCenMP/AzvZbkYmVDBiYnOcfIcE/D9
RxtyWjq6nMitBMYh1T4uUpwvSW6bLYsvntIqglXQxDUyRDxnGaiCG9q8bsDRJfk+
XUBdwOX7Guj6JOAITL/OsL0w9bhXNPqXtZTEEDOxV0ZIvxxc2RRudqkTjztQzkpZ
xnf3tl95us0BbIZNbVyNlchv2dgwv548gEbkRYoQsrYXMW48mMaxRf57mwWvxSSq
8jG9GuuUJgz5L5v+ehDDPMPNP7jaXTuVQuUGdX9Xc9vf0tBp2/5G5Pd6uZPKtzkr
RvatQkce5UfM7194sqbbkpsaagB3dHQ5D4mVklcxRCtlcodyqJKIM353RCsu6ov/
aXnkIClxUp3MaFj19AscRrBfUFxAMZ2o9fnkh6Vz8oMoG1dkIzpzLfmHiRwur3Fi
7L5GKQJko23Sd50Wf9morTmKoJ4YAJAO/6cjyKslEmZqn+Ae0TPJnVI2L8nPqMkp
LGhAfEgmz0XuYnGNi54xy8cq4Vkg5/QoRc4gBzz6GEw30P9g8YvNhjXrDU0mGhzC
enC0K0RSnQrv0rII0ruDkK928IoBHBI8t7bQJXCI4JqHnCnj/ele5fveS40OCEey
hMcYO/Zc67nZfMyLrplzjRzShck4zDEMxPjiDOa9hTtrFqsddcbmLXWEkxF1nGMr
JTrGN/v6b4mVBhAQmU7h
=I5eh
-----END PGP SIGNATURE-----

--Apple-Mail=_ECC9130B-8CC9-4038-8FF7-17DB12669FDB--

.

On 03/14/2017 10:02 PM, Howard Hinnant wrote:

> Personally I=E2=80=99d vote against it.  I regularly help people who are =
learning <chrono> and one of the most common mistakes I see is overuse of t=
he .count() (and .time_since_epoch()) function.  These should be considered=
 =E2=80=9Cescape hatches=E2=80=9D out of the type-safe chrono library, main=
ly for use in interfacing with code not aware of chrono.  The .count() is n=
othing but a cast from a time duration to an arithmetic type.

While I tend to agree with the "escape hatch" comment, we do
unfortunately have to use this escape hatch quite often, not out of
joy, but out of necessity.

One use-case is to get the current time and then manipulate it -- e.g.
with drift calculations -- before turning it back into a time_point.

Another use-case is to use durations as input to statistical methods
that have no knowledge of chrono. Some of these calculations will later
result in a duration (e.g. the mean of all durations.)

We use the count() function that I suggested, and it removed a whole
category of errors. I would like to urge you to reconsider your
position.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9cafd666-d0fe-5bf2-6ac0-63236c5c9243%40mail1.sto=
fanet.dk.

.

--Apple-Mail=_F9356CBC-94DD-4217-B945-6591F7EE9C6B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

On Mar 14, 2017, at 5:44 PM, Bjorn Reese <breese@mail1.stofanet.dk> wrote:
>=20
> On 03/14/2017 10:02 PM, Howard Hinnant wrote:
>=20
>> Personally I=E2=80=99d vote against it.  I regularly help people who are=
 learning <chrono> and one of the most common mistakes I see is overuse of =
the .count() (and .time_since_epoch()) function.  These should be considere=
d =E2=80=9Cescape hatches=E2=80=9D out of the type-safe chrono library, mai=
nly for use in interfacing with code not aware of chrono.  The .count() is =
nothing but a cast from a time duration to an arithmetic type.
>=20
> While I tend to agree with the "escape hatch" comment, we do
> unfortunately have to use this escape hatch quite often, not out of
> joy, but out of necessity.
>=20
> One use-case is to get the current time and then manipulate it -- e.g.
> with drift calculations -- before turning it back into a time_point.
>=20
> Another use-case is to use durations as input to statistical methods
> that have no knowledge of chrono. Some of these calculations will later
> result in a duration (e.g. the mean of all durations.)
>=20
> We use the count() function that I suggested, and it removed a whole
> category of errors. I would like to urge you to reconsider your
> position.

I will definitely reconsider my position.  I would like to hear more about =
the errors you encountered.  I also find myself wondering why this simpler =
syntax did not suffice:

    chrono::seconds s{2};
    auto ms =3D chrono::milliseconds{s}.count();
    assert(ms =3D=3D 2000);

Was it the need to convert to coarser units prior to the cast?  Overuse of =
duration_cast (when an implicit conversion would do) is another common mist=
ake I see.  Overuse of duration_cast leads to the hiding of those conversio=
ns that have truncation errors under the hood.  In case you have to track d=
own an error that you suspect is caused by truncation, it is easier if thos=
e conversions that didn=E2=80=99t require duration_cast didn=E2=80=99t use =
it.

Howard

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/EFBF15E2-E9D8-4715-8240-91ADB7C0BFC0%40gmail.com=
..

--Apple-Mail=_F9356CBC-94DD-4217-B945-6591F7EE9C6B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename=signature.asc
Content-Type: application/pgp-signature;
 name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYyGboAAoJEGbcHCxKqhWCpUsP/24fgilqmlJp5aynh1Ok15tK
bvZ2dpUVgCsKOcOpIIKnfVMfdTzo2ZBJoTa3TE7fC2uNUzRydgkz3PD+v/SazWjW
UDvRRGuiNS5GKmICNPIO/0+63npZv0Xxd8i3NnMjVnKWJTmj/h6v0LCFGAcjobgE
zhHPYnyahHGtLkFvCjz8Kg8+YgJxJmu53jo2xNwHMjunz1GKx5cvJLC1RJdQc3zM
q+naacG+t2Tg0+mxP+AIZLjo1cep9bgNGxpFnFZsz+sfwIe5u3eZIWZ2PSQaSTMd
zpzca8+GXFLkLkOOveQxvp7RvTxqX0phUo6kX96SXb+GLmNLGMzd+ETk2HyPltWz
NSK5SGU5EvFTgbYs77KvgOK1o/TnpJz0KqhO/Htd8bBe6kuRYnk6iguJtWq4UrKZ
BR47VH0Bdbew3JQffxZBPjJ4TlWilkHr/E+iO2Ct7HUnAqhPk3vn67NaCxFKEpYk
geAtv54LV9Q+tXGoriWL4iCMMSP/zBB7/xqD6xhNrFjGlKDjf9/Ze2bIG/aLIZln
eVjF87znhsIobNp0VawGRbL8CyCw/UlHIuz4QzEEt3Ko6idEY36h4I6tMF3VeHFV
cmOHKiALsuZFLkWqg0Ggi1CN5UbdSAMGyZOK9nG8CfyIzPsy8k9M5sAThMxZn2bi
2EQ8Bd2ejVLBzukc/5jj
=aT76
-----END PGP SIGNATURE-----

--Apple-Mail=_F9356CBC-94DD-4217-B945-6591F7EE9C6B--

.

On 03/14/2017 10:52 PM, Bjorn Reese wrote:
> I want to gauge if there is interest in the following.
>
> The value returned by chrono::duration<Rep,Period>::count() is the
> tick count in units of Period. If we want this count in another unit,
> we must use chrono::duration_cast.
>
> We could add a convenience function to return the tick count in another
> unit directly. For example:
>
>   chrono::seconds s{2};
>   auto ms = chrono::count<chrono::milliseconds>(s);

You can write


    auto ms = s / 1ms;

>   assert(ms == 2000);
>
> Another overload can be added for chrono::time_point
>
>   auto now = chrono::steady_clock::now();
>   auto ms = chrono::count<chrono::milliseconds>(now);

    auto ms = now.time_since_epoch() / 1ms;

>
> Example implementations are:
>
>   template <typename ToDuration, typename Rep, typename Period>
>   typename ToDuration::rep count(const chrono::duration<Rep, Period>& d)
>   {
>     return chrono::duration_cast<ToDuration, Rep, Period>(d).count();
>   }
>
>   template <typename ToDuration, typename Clock, typename Duration>
>   typename ToDuration::rep count(const chrono::time_point<Clock,
> Duration>& t)
>   {
>     return chrono::duration_cast<T, typename Duration::rep, typename
> Duration::period>(t.time_since_epoch()).count();
>   }
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5fa7d18b-3067-0eb6-0b5e-7562a59e44f7%40scylladb.com.

.

On 03/14/2017 10:55 PM, Howard Hinnant wrote:

> I will definitely reconsider my position.  I would like to hear more abou=
t the errors you encountered.

Most errors occurred in calculations that used both duration and
floating-point numbers. These calculations used <cmath> so they were
done with double. Sometimes they needed to use a constant (e.g.
a threshold value) that was specified as a duration. We used .count()
on those constants. If one of these constants was declared as, say,
chrono::milliseconds, and somebody later changed it to chrono::seconds
the calculations would be off by a factor of 1000.

 >  I also find myself wondering why this simpler syntax did not suffice:
>
>     chrono::seconds s{2};
>     auto ms =3D chrono::milliseconds{s}.count();

That will solve the duration case. It is less attractive for the
time_point case, but I realize that this is insufficient motivation for
a proposal.

> Was it the need to convert to coarser units prior to the cast?  Overuse o=
f duration_cast (when an implicit conversion would do) is another common mi=
stake I see.  Overuse of duration_cast leads to the hiding of those convers=
ions that have truncation errors under the hood.  In case you have to track=
 down an error that you suspect is caused by truncation, it is easier if th=
ose conversions that didn=E2=80=99t require duration_cast didn=E2=80=99t us=
e it.

I suggested duration_cast because I thought that was the way to convert
between duration types.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/22a9d0eb-16b2-1a1a-27e1-65239dc113c5%40mail1.sto=
fanet.dk.

.

--Apple-Mail=_78227210-919F-47A3-BA07-6BB6E752CB20
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

On Mar 18, 2017, at 7:50 AM, Bjorn Reese <breese@mail1.stofanet.dk> wrote:
> On 03/14/2017 10:55 PM, Howard Hinnant wrote:
>=20
>> Overuse of duration_cast (when an implicit conversion would do) is anoth=
er common mistake I see.  Overuse of duration_cast leads to the hiding of t=
hose conversions that have truncation errors under the hood.  In case you h=
ave to track down an error that you suspect is caused by truncation, it is =
easier if those conversions that didn=E2=80=99t require duration_cast didn=
=E2=80=99t use it.
>=20
> I suggested duration_cast because I thought that was the way to convert
> between duration types.

Lack of good tutorial material on <chrono> has been a problem.  Here is my =
attempt to help in that department:

https://www.youtube.com/watch?v=3DP32hvk8b13M

Howard

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/61B459C2-D1D0-4F40-B223-B90E31B49830%40gmail.com=
..

--Apple-Mail=_78227210-919F-47A3-BA07-6BB6E752CB20
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename=signature.asc
Content-Type: application/pgp-signature;
 name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYzVMMAAoJEGbcHCxKqhWCbV8QAJhF6nE6JsxSlwpSneGzrRK8
Vece/34t4MpA7rrMkHjly6fr0uoN2y7WXKhwJzdVrHyUwND6sg4XB9roIxGLStwK
Oh5mlD2vrrC6fj/aCE8k5/WQWOd+mLjRbm/3+phEAm/IccKIXT2hKpreocwk5SoT
YOuZtBvzuIhwzSBoLQwoHPxobPUF1u97FpLlm1WL/l+8AwJgnxgTceyMTmvZnNlu
cbxelzdSOKMV0+69GY3WzED6f74UYRCl4YKVsMcOkT1AwW2x7F0hgJQEJLBoCT7T
3nnX9w0Cpa8AJBwRH7rEOwLkphH+YB7c6Hu2eHg99oP4mY3FXZm84aF2EI9cR0AK
wThJJueZ+7VTekgrnocLzP6syp3NEczAV8zGB+mSgBj5G2Z69baCt0Jturhi7uum
wJm0V4PFYn8rMG2DQ4lWEKbJmyoJb2KtBpeUUHTFSLahWaT3mt0xhwaU+1ogsiR7
lrvh0uEjoTRWbvlOqGy9xlkwqCoEYVlQjfKLDWMQG4tgF9fhu0sgbpHyZ4VAaaaY
VYz6C9rGXsXgRPRzGB7yzk/j9rNgyE3HrYxW4MGycG6FOBxOiJd/FX7oraTf2HjD
wLpeZjVk0bySZSVB+D8g2m1Z4DPQQKoQo9cTChKpFUiWB2ox57tFCJm4zbF/4Nbc
Lm8QMBPC3LLgx9xK1v8Z
=q9GQ
-----END PGP SIGNATURE-----

--Apple-Mail=_78227210-919F-47A3-BA07-6BB6E752CB20--

.