------=_Part_5397_887362319.1444727418947
Content-Type: multipart/alternative;
 boundary="----=_Part_5398_688881257.1444727418948"

------=_Part_5398_688881257.1444727418948
Content-Type: text/plain; charset=UTF-8

This is an early stage 'float the idea' submission as suggested here:
https://isocpp.org/std/submit-a-proposal

When working with threads, I frequently found myself writing, or finding
code such as the following:

std::this_thread::sleep_for (1s);

It's simple, elegant, and it gets the job done. Let's not debate the pros
and cons of sleeping a thread, because the real story is how code as simple
as this can (and frequently does) evolve in the wild. Like most programming
stories, this one takes a turn for the worse when we introduce the user,
and in this instance for practical purposes we're going to make the
argument to sleep_for user-configurable. For the sake of argument, let's
say the value comes from some configuration file as a trivially parseable
string. To allow the user to configure the duration, I hard-code the
duration type into the function, and pass the parsed parameter into
sleep_for with a temporary of std::chrono::seconds:

void sleep_for (size_t s) {
    std::this_thread::sleep_for (std::chrono::seconds (s));
}

It's not looking too bad, admittedly it's slightly less elegant now I'm
hard-coding the duration type, but it's not exactly *Bad Code*. Now the
user comes back to me, having changed his mind. He has decided that he
would actually prefer *millisecond *granularity. So I update my function
and now it looks like this:

void sleep_for (size_t ms) {
    std::this_thread::sleep_for (std::chrono::milliseconds (ms));
}

Great. It's a good job I can easily change the type like that, and the code
is still readable. Development continues, more threads are added, and
configuration options are added for more threads. Things are going so well
I even re-use the same code for parsing durations. Now, for one thread in
particular, which needs to wake up quite frequently, the user has decided
he would prefer *microsecond *granularity. So I update the function as
before:

void sleep_for (size_t us) {
    std::this_thread::sleep_for (std::chrono::microseconds (us));
}

Oops, I've just introduced a bug. When parsing the user specified
parameter, I lost type information, so now my threads that were sleeping
for *milliseconds *previously are now all sleeping for *microseconds*, and
not only that I also noticed performance has taken a plunge! I rethink my
approach for a while, and I realise there is a simple solution:

std::chrono::microseconds to_microseconds(size_t t, bool is_milliseconds) {
    return (is_milliseconds) ?
std::chrono::duration_cast<std::chrono::microseconds>
(std::chrono::milliseconds (t)) : std::chrono::microseconds (t);
}

Perfect, and solved with a one-liner! The user can specify whether the
value t is in milliseconds, and if so then we use a duration_cast to
convert to microseconds, otherwise we just treat the value as microseconds.
duration_cast allows me to treat the duration as one homogeneous type, so
my function to sleep the thread only needs to work with microseconds. This
works reasonably well, though it's starting to look a little bit hairy, I
choose not to worry about it too much and carry on with the work and push
the changes upstream.

Now the user comes to me with a new problem. He claims it's not intuitive
enough only being able to use milliseconds and microseconds in his
configuration. Actually he wants to be able to specify time durations using
whatever units he deems appropriate. I find it ironic that the user wants
to be able to express time in a way that is convenient for him, at the
expense of my own time. Nevertheless, I rethink my approach once again.

Introducing to_duration:
https://github.com/bigdatadev/chrono-utilities/blob/master/src/chrono/utility/to_duration.hpp

The user now specifies the units along with the value in the string, such
as *"1s"*, or *"1000ms"*. However, the user is also able to mix units in
the same string, eg *"1s500ms"*, and use any combination of hours (h),
minutes (m), seconds (s), milliseconds (ms), microseconds (us) or
nanoseconds (ns).

In code, we can easily parse the string provided by the user (for
demonstration the string is hard-coded), and catch errors:

try {
    auto us = to_duration<std::chrono::microseconds> ("1s500ms"); //
returned type is std::chrono::microseconds
} catch (std::invalid_argument &e) {
    // handle the error here
}

And now when we wish to use the duration, we do so in a way which is
intuitive:

std::this_thread::sleep_for (us);

This is my first submission, so I welcome all comments and feedback (though
I especially welcome the constructive kind), and thank you for your time.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_5398_688881257.1444727418948
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>This is an early stage &#39;float the idea&#39; submi=
ssion as suggested here:=C2=A0<a href=3D"https://isocpp.org/std/submit-a-pr=
oposal">https://isocpp.org/std/submit-a-proposal</a></div><div><br></div>Wh=
en working with threads, I frequently found myself writing, or finding code=
 such as the following:<div><br></div><div><font face=3D"courier new, monos=
pace">std::this_thread::sleep_for (1s);</font></div><div><br></div><div>It&=
#39;s simple, elegant, and it gets the job done. Let&#39;s not debate the p=
ros and cons of sleeping a thread, because the real story is how code as si=
mple as this can (and frequently does) evolve in the wild. Like most progra=
mming stories, this one takes a turn for the worse when we introduce the us=
er, and in this instance for practical purposes we&#39;re going to make the=
 argument to sleep_for user-configurable. For the sake of argument, let&#39=
;s say the value comes from some configuration file as a trivially parseabl=
e string. To allow the user to configure the duration, I hard-code the dura=
tion type into the function, and pass the parsed parameter into sleep_for w=
ith a temporary of std::chrono::seconds:</div><div><br></div><div><font fac=
e=3D"courier new, monospace">void sleep_for (size_t s) {</font></div><div><=
font face=3D"courier new, monospace">=C2=A0 =C2=A0 std::this_thread::sleep_=
for (std::chrono::seconds (s));</font></div><div><font face=3D"courier new,=
 monospace">}</font></div><div><br></div><div>It&#39;s not looking too bad,=
 admittedly it&#39;s slightly less elegant now I&#39;m hard-coding the dura=
tion type, but it&#39;s not exactly <i>Bad Code</i>. Now the user comes bac=
k to me, having changed his mind. He has decided that he would actually pre=
fer <i>millisecond </i>granularity. So I update my function and now it look=
s like this:</div><div><br></div><div><div><font face=3D"courier new, monos=
pace">void sleep_for (size_t ms) {</font></div><div><font face=3D"courier n=
ew, monospace">=C2=A0 =C2=A0 std::this_thread::sleep_for (std::chrono::mill=
iseconds (ms));</font></div><div><font face=3D"courier new, monospace">}</f=
ont></div></div><div><br></div><div>Great. It&#39;s a good job I can easily=
 change the type like that, and the code is still readable. Development con=
tinues, more threads are added, and configuration options are added for mor=
e threads. Things are going so well I even re-use the same code for parsing=
 durations. Now, for one thread in particular, which needs to wake up quite=
 frequently, the user has decided he would prefer <i>microsecond </i>granul=
arity. So I update the function as before:</div><div><br></div><div><div><f=
ont face=3D"courier new, monospace">void sleep_for (size_t us) {</font></di=
v><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 std::this_thread=
::sleep_for (std::chrono::microseconds (us));</font></div><div><font face=
=3D"courier new, monospace">}</font></div></div><div><br></div><div>Oops, I=
&#39;ve just introduced a bug. When parsing the user specified parameter, I=
 lost type information, so now my threads that were sleeping for <i>millise=
conds </i>previously are now all sleeping for <i>microseconds</i>, and not =
only that I also noticed performance has taken a plunge! I rethink my appro=
ach for a while, and I realise there is a simple solution:</div><div><br></=
div><div><font face=3D"courier new, monospace">std::chrono::microseconds to=
_microseconds(size_t t, bool is_milliseconds) {</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 return=C2=A0(is_milliseconds) ? s=
td::chrono::duration_cast&lt;std::chrono::microseconds&gt; (std::chrono::mi=
lliseconds (t)) : std::chrono::microseconds (t);</font></div><div><font fac=
e=3D"courier new, monospace">}</font></div><div><br></div><div>Perfect, and=
 solved with a one-liner! The user can specify whether the value t is in mi=
lliseconds, and if so then we use a duration_cast to convert to microsecond=
s, otherwise we just treat the value as microseconds. duration_cast allows =
me to treat the duration as one homogeneous type, so my function to sleep t=
he thread only needs to work with microseconds. This works reasonably well,=
 though it&#39;s starting to look a little bit hairy, I choose not to worry=
 about it too much and carry on with the work and push the changes upstream=
..</div><div><br></div><div>Now the user comes to me with a new problem. He =
claims it&#39;s not intuitive enough only being able to use milliseconds an=
d microseconds in his configuration. Actually he wants to be able to specif=
y time durations using whatever units he deems appropriate. I find it ironi=
c that the user wants to be able to express time in a way that is convenien=
t for him, at the expense of my own time. Nevertheless, I rethink my approa=
ch once again.</div><div><br></div><div>Introducing to_duration:=C2=A0<a hr=
ef=3D"https://github.com/bigdatadev/chrono-utilities/blob/master/src/chrono=
/utility/to_duration.hpp">https://github.com/bigdatadev/chrono-utilities/bl=
ob/master/src/chrono/utility/to_duration.hpp</a></div><div><br></div><div>T=
he user now specifies the units along with the value in the string, such as=
 <i>&quot;1s&quot;</i>, or <i>&quot;1000ms&quot;</i>. However, the user is =
also able to mix units in the same string, eg <i>&quot;1s500ms&quot;</i>, a=
nd use any combination of hours (h), minutes (m), seconds (s), milliseconds=
 (ms), microseconds (us) or nanoseconds (ns).</div><div><br></div><div>In c=
ode, we can easily parse the string provided by the user (for demonstration=
 the string is hard-coded), and catch errors:</div><div><br></div><div><fon=
t face=3D"courier new, monospace">try {</font></div><div><font face=3D"cour=
ier new, monospace">=C2=A0 =C2=A0 auto us =3D to_duration&lt;std::chrono::m=
icroseconds&gt; (&quot;1s500ms&quot;); // returned type is std::chrono::mic=
roseconds</font></div><div><font face=3D"courier new, monospace">} catch (s=
td::invalid_argument &amp;e) {</font></div><div><font face=3D"courier new, =
monospace">=C2=A0 =C2=A0 // handle the error here</font></div><div><font fa=
ce=3D"courier new, monospace">}</font></div><div><br></div><div>And now whe=
n we wish to use the duration, we do so in a way which is intuitive:</div><=
div><br></div><div><font face=3D"courier new, monospace">std::this_thread::=
sleep_for (us);</font><br></div><div><br></div><div>This is my first submis=
sion, so I welcome all comments and feedback (though I especially welcome t=
he constructive kind), and thank you for your time.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5398_688881257.1444727418948--
------=_Part_5397_887362319.1444727418947--

.

------=_Part_46_387733279.1444739312693
Content-Type: multipart/alternative;
 boundary="----=_Part_47_646199072.1444739312693"

------=_Part_47_646199072.1444739312693
Content-Type: text/plain; charset=UTF-8

Is there some reason why 1.5s is not a better way to say "1s500ms"?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_47_646199072.1444739312693
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><div>Is there some reason why 1.5s is not a better way to say &quot;1s500ms&quot;?</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_47_646199072.1444739312693--
------=_Part_46_387733279.1444739312693--

.

------=_Part_5502_1915582008.1444741012689
Content-Type: multipart/alternative;
 boundary="----=_Part_5503_462673371.1444741012689"

------=_Part_5503_462673371.1444741012689
Content-Type: text/plain; charset=UTF-8

Thank you for your feedback. Upon reflection I agree with you, I think it
would be preferable to be able to specify values with either integer or
floating-point precision. This would be more in keeping with chrono
literals.

On Tuesday, 13 October 2015 13:28:33 UTC+1, Nicol Bolas wrote:
>
> Is there some reason why 1.5s is not a better way to say "1s500ms"?
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_5503_462673371.1444741012689
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you for your feedback. Upon reflection I agree with =
you, I think it would be preferable to be able to specify values with eithe=
r integer or floating-point precision. This would be more in keeping with c=
hrono literals.<div><div><div><br>On Tuesday, 13 October 2015 13:28:33 UTC+=
1, Nicol Bolas  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Is there some reason why 1.5s is not a better way to say &quo=
t;1s500ms&quot;?</div></div></blockquote></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5503_462673371.1444741012689--
------=_Part_5502_1915582008.1444741012689--

.

------=_Part_121_1158955906.1444745878982
Content-Type: multipart/alternative;
 boundary="----=_Part_122_757680445.1444745878982"

------=_Part_122_757680445.1444745878982
Content-Type: text/plain; charset=UTF-8

Your motivating example doesn't make much sense to me. Rather than void
sleep_for (size_t s), the idiomatic way to write that function would be void
sleep_for(std::chrono::seconds). That way if you want to provide increased
precision you can change the parameter type or add overloads (of
std::chrono::microseconds, etc.).

It certainly isn't an improvement to a type-unsafe interface to make it
even more type-unsafe by changing the parameter to a string (cf. "Stringly
typed <http://c2.com/cgi/wiki?StringlyTyped>").

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_122_757680445.1444745878982
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Your motivating example doesn&#39;t make much sense to me.=
 Rather than=C2=A0<span style=3D"font-family: &#39;courier new&#39;, monosp=
ace;">void sleep_for (size_t s)</span>, the idiomatic way to write that fun=
ction would be=C2=A0<span style=3D"font-family: &#39;courier new&#39;, mono=
space;">void sleep_for(std::chrono::seconds)</span>. That way if you want t=
o provide increased precision you can change the parameter type or add over=
loads (of <font face=3D"courier new, monospace">std::chrono::microseconds</=
font>, etc.).<div><br></div><div>It certainly isn&#39;t an improvement to a=
 type-unsafe interface to make it even more type-unsafe by changing the par=
ameter to a string (cf. &quot;<a href=3D"http://c2.com/cgi/wiki?StringlyTyp=
ed">Stringly typed</a>&quot;).<div><br></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_122_757680445.1444745878982--
------=_Part_121_1158955906.1444745878982--

.

On Oct 13, 2015, at 5:10 AM, Christopher Gilbert <christopher.john.gilbert@gmail.com> wrote:
>
> void sleep_for (size_t us) {
>     std::this_thread::sleep_for (std::chrono::microseconds (us));
> }


template <class Rep, class Period>
void
sleep_for(const std::chrono::duration<Rep, Period>& rel_time)
{
    std::this_thread::sleep_for(rel_time);
}

That being said, you have started down the path of duration I/O, and I support work in that area.  Here is mine (unfinished) from years ago:

http://howardhinnant.github.io/duration_io/chrono_io.html

I encourage anyone with the interest and time to pick it up and run with it.

Howard

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_5909_1624582036.1444746383737
Content-Type: multipart/alternative;
 boundary="----=_Part_5910_269299056.1444746383738"

------=_Part_5910_269299056.1444746383738
Content-Type: text/plain; charset=UTF-8

Thank you, I will reconsider the wording of my example to see if I can come
up with something more convincing.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_5910_269299056.1444746383738
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Thank you, I will reconsider the wording of my example to see if I can come up with something more convincing.</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_5910_269299056.1444746383738--
------=_Part_5909_1624582036.1444746383737--

.

On 2015-10-13 10:17, Edward Catmur wrote:
> Your motivating example doesn't make much sense to me. Rather than void
> sleep_for (size_t s), the idiomatic way to write that function would be void
> sleep_for(std::chrono::seconds). That way if you want to provide increased
> precision you can change the parameter type or add overloads (of
> std::chrono::microseconds, etc.).

Personally, I don't find the strength or weakness of the example of much
relevance. We have functions to convert strings to numbers. We have
functions to convert strings to dates (well... not in the standard, I
don't think, but strptime, boost, etc.). Why shouldn't we have a
function to convert a string to a time duration?

That said, I could imagine it would be better to have this in e.g. boost
first. Having it there and in use in the wild would certainly help with
getting it standardized.

(See also Howard's reply.)

> It certainly isn't an improvement to a type-unsafe interface to make it
> even more type-unsafe by changing the parameter to a string (cf. "Stringly
> typed <http://c2.com/cgi/wiki?StringlyTyped>").

This seems like just completely wrong logic to me. The parameter
ultimately comes from the user (e.g. a configuration file). That means
that *AT SOME POINT* it is a string and needs to be converted to a more
appropriate representation. I agree that 'sleep_for' is not the best
place for that conversion to happen, but that's orthogonal to the need
for it to happen *somewhere*.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11c3819229b7590521fdc6cb
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 13, 2015 at 3:43 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-10-13 10:17, Edward Catmur wrote:
> > Your motivating example doesn't make much sense to me. Rather than void
> > sleep_for (size_t s), the idiomatic way to write that function would be
> void
> > sleep_for(std::chrono::seconds). That way if you want to provide
> increased
> > precision you can change the parameter type or add overloads (of
> > std::chrono::microseconds, etc.).
>
> Personally, I don't find the strength or weakness of the example of much
> relevance. We have functions to convert strings to numbers. We have
> functions to convert strings to dates (well... not in the standard, I
> don't think, but strptime, boost, etc.). Why shouldn't we have a
> function to convert a string to a time duration?
>

We have std::get_time and std::put_time, which work with struct tm. It's a
bit of a mess, and they may not be particularly well supported by
implementations (gcc only has them as of 5.0, IIRC).


> That said, I could imagine it would be better to have this in e.g. boost
> first. Having it there and in use in the wild would certainly help with
> getting it standardized.
>

Boost.Date_Time has boost::posix_time::time_duration with to/from string
conversions and in/out stream operators (facet-controlled). Of course, to
use those you have to be using boost::posix_time::time_duration, not
std::chrono::duration.


> (See also Howard's reply.)
>
> > It certainly isn't an improvement to a type-unsafe interface to make it
> > even more type-unsafe by changing the parameter to a string (cf.
> "Stringly
> > typed <http://c2.com/cgi/wiki?StringlyTyped>").
>
> This seems like just completely wrong logic to me. The parameter
> ultimately comes from the user (e.g. a configuration file). That means
> that *AT SOME POINT* it is a string and needs to be converted to a more
> appropriate representation. I agree that 'sleep_for' is not the best
> place for that conversion to happen, but that's orthogonal to the need
> for it to happen *somewhere*.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c3819229b7590521fdc6cb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Oct 13, 2015 at 3:43 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex">On 2015-10-13 10:17, Edward =
Catmur wrote:<br>
&gt; Your motivating example doesn&#39;t make much sense to me. Rather than=
 void<br>
&gt; sleep_for (size_t s), the idiomatic way to write that function would b=
e void<br>
&gt; sleep_for(std::chrono::seconds). That way if you want to provide incre=
ased<br>
&gt; precision you can change the parameter type or add overloads (of<br>
&gt; std::chrono::microseconds, etc.).<br>
<br>
Personally, I don&#39;t find the strength or weakness of the example of muc=
h<br>
relevance. We have functions to convert strings to numbers. We have<br>
functions to convert strings to dates (well... not in the standard, I<br>
don&#39;t think, but strptime, boost, etc.). Why shouldn&#39;t we have a<br=
>
function to convert a string to a time duration?<br></blockquote><div><br><=
/div><div>We have std::get_time and std::put_time, which work with struct t=
m. It&#39;s a bit of a mess, and they may not be particularly well supporte=
d by implementations (gcc only has them as of 5.0, IIRC).</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex">
That said, I could imagine it would be better to have this in e.g. boost<br=
>
first. Having it there and in use in the wild would certainly help with<br>
getting it standardized.<br></blockquote><div><br></div><div>Boost.Date_Tim=
e has boost::posix_time::time_duration with to/from string conversions and =
in/out stream operators (facet-controlled). Of course, to use those you hav=
e to be using boost::posix_time::time_duration, not std::chrono::duration.<=
br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex">
(See also Howard&#39;s reply.)<br>
<br>
&gt; It certainly isn&#39;t an improvement to a type-unsafe interface to ma=
ke it<br>
&gt; even more type-unsafe by changing the parameter to a string (cf. &quot=
;Stringly<br>
&gt; typed &lt;<a href=3D"http://c2.com/cgi/wiki?StringlyTyped" rel=3D"nore=
ferrer" target=3D"_blank">http://c2.com/cgi/wiki?StringlyTyped</a>&gt;&quot=
;).<br>
<br>
This seems like just completely wrong logic to me. The parameter<br>
ultimately comes from the user (e.g. a configuration file). That means<br>
that *AT SOME POINT* it is a string and needs to be converted to a more<br>
appropriate representation. I agree that &#39;sleep_for&#39; is not the bes=
t<br>
place for that conversion to happen, but that&#39;s orthogonal to the need<=
br>
for it to happen *somewhere*.<span class=3D""><font color=3D"#888888"><br><=
/font></span></blockquote></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3819229b7590521fdc6cb--

.

Le 13/10/15 16:43, Matthew Woehlke a =C3=A9crit :
> On 2015-10-13 10:17, Edward Catmur wrote:
>> Your motivating example doesn't make much sense to me. Rather than void
>> sleep_for (size_t s), the idiomatic way to write that function would be =
void
>> sleep_for(std::chrono::seconds). That way if you want to provide increas=
ed
>> precision you can change the parameter type or add overloads (of
>> std::chrono::microseconds, etc.).
> Personally, I don't find the strength or weakness of the example of much
> relevance. We have functions to convert strings to numbers. We have
> functions to convert strings to dates (well... not in the standard, I
> don't think, but strptime, boost, etc.). Why shouldn't we have a
> function to convert a string to a time duration?
>
> That said, I could imagine it would be better to have this in e.g. boost
> first. Having it there and in use in the wild would certainly help with
> getting it standardized.
>
> (See also Howard's reply.)
Boost.Chrono provides an IO facility based on the Howard's work ( with=20
some variations).
* V1 is almost the same than Howard design.
* V2 includes some facets duration_get/put and time_point_get/put,=20
duration_units and time_point_units.

The main issue is how to manage with the combination of locales and the=20
duration units and clocks units :(
Vicente

V1=20
http://www.boost.org/doc/libs/1_59_0/doc/html/chrono/reference.html#chrono.=
reference.io_v1
V2=20
http://www.boost.org/doc/libs/1_59_0/doc/html/chrono/reference.html#chrono.=
reference.io

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.