On Sun, 31 Mar 2013 06:00:53 -0400, Lars T. Kyllingstad
wrote:
On Saturday, 30 March 2013 at 02:46:27 UTC, Steven Schveighoffer wrote:
On Fri, 29 Mar 2013 18:08:28 -0400, Jonathan M Davis
wrote:
std.conv.to is the standard way to convert one type to another. I see
no
reason to introdu
On Saturday, March 30, 2013 22:39:49 Steven Schveighoffer wrote:
> What C stuff am I interacting with? Unix Time <=> SysTime conversions are
> purely D code.
If you're using pure D code, then why are you using unix time at all? I would
expect the need for unix time in pure D code to be extremely
On Sunday, 31 March 2013 at 02:39:48 UTC, Steven Schveighoffer
wrote:
It won't be very long until Unix will have to tackle this
(hopefully they don't wait until 2037).
It looks like time_t is 64-bit on 64-bit system
http://svnweb.freebsd.org/base/head/sys/x86/include/_types.h?view=markup
So the
On Sunday, 31 March 2013 at 02:39:48 UTC, Steven Schveighoffer
wrote:
And
if future-proofing is the issue, then you'll need a 64-bit
system anyway,
otherwise the C stuff that you're interacting with wouldn't
work correctly with
the larger time_t values.
What C stuff am I interacting with? U
On Saturday, 30 March 2013 at 02:46:27 UTC, Steven Schveighoffer
wrote:
On Fri, 29 Mar 2013 18:08:28 -0400, Jonathan M Davis
wrote:
std.conv.to is the standard way to convert one type to
another. I see no
reason to introduce stuff specific to core.time or
std.datetime to do
conversions. It s
On Sat, 30 Mar 2013 17:27:37 -0400, Jonathan M Davis
wrote:
On Saturday, March 30, 2013 09:53:49 Artur Skawina wrote:
You can't tell if there is an opCast w/o looking at S. So it's either
a perfectly fine conversion, no-op, a potentially dangerous operation,
or
an error. The compiler woul
On Sat, 30 Mar 2013 02:06:14 -0400, Jonathan M Davis
wrote:
On Friday, March 29, 2013 22:50:16 Steven Schveighoffer wrote:
On Fri, 29 Mar 2013 19:35:35 -0400, Jonathan M Davis
wrote:
> On Friday, March 29, 2013 10:03:31 Steven Schveighoffer wrote:
>> 1. unixTimeToStdTime should take ulon
On Saturday, March 30, 2013 09:53:49 Artur Skawina wrote:
> You can't tell if there is an opCast w/o looking at S. So it's either
> a perfectly fine conversion, no-op, a potentially dangerous operation, or
> an error. The compiler would have been able to catch the error, but by
> overloading 'cast'
unix time will need a wrapper for strong typing
struct UnixTime { int value; }
SysTime toSysTime(UnixTime fromValue, TimeZone zone=Utc)
{ return SysTime(unixTimeToStdTime(fromValue.value), zone); }
so conversion is
return UnixTime(d.when.time).toTime!DateTime;
may be it can be reduced to
retu
On Friday, 29 March 2013 at 14:03:34 UTC, Steven Schveighoffer
wrote:
Another example, I once had to convert a long type which
represented
Unix time into DateTime. Here's the code to do it:
return
cast(DateTime)SysTime(unixTimeToStdTime(cast(int)d.when.time));
I have three comments here:
1.
On 03/30/13 09:22, Jonathan M Davis wrote:
> On Saturday, March 30, 2013 09:15:24 Artur Skawina wrote:
>> On 03/30/13 07:12, Jonathan M Davis wrote:
>>> On Friday, March 29, 2013 22:46:27 Steven Schveighoffer wrote:
The issue is when you think you are invoking the opCast operator, but you
On Saturday, March 30, 2013 09:15:24 Artur Skawina wrote:
> On 03/30/13 07:12, Jonathan M Davis wrote:
> > On Friday, March 29, 2013 22:46:27 Steven Schveighoffer wrote:
> >> The issue is when you think you are invoking the opCast operator, but you
> >> inadvertently end up casting using the compil
On 03/30/13 07:12, Jonathan M Davis wrote:
> On Friday, March 29, 2013 22:46:27 Steven Schveighoffer wrote:
>> The issue is when you think you are invoking the opCast operator, but you
>> inadvertently end up casting using the compiler's type-bypassing version.
>> I agree the opCast call is safe, i
On Saturday, March 30, 2013 08:18:08 Andrej Mitrovic wrote:
> On 3/30/13, Jonathan M Davis wrote:
> > If opCast is defined, it's perfectly
> > safe regardless of what would happen if you tried to cast without opCast
> > being defined.
>
> Casting is generally unsafe when working with reference ty
On 3/30/13, Jonathan M Davis wrote:
> If opCast is defined, it's perfectly
> safe regardless of what would happen if you tried to cast without opCast
> being defined.
Casting is generally unsafe when working with reference types like
classes. For example:
import std.stdio;
final class A
{
B
On 3/29/13, Steven Schveighoffer wrote:
> Thread.sleep(1.seconds + 200.msecs + 800.usecs);
Heh, sweet UFCS! Funny thing about this is my editor thinks "seconds"
is a fractional part and is syntax-highlighting it as a floating-point
number. Oops! :p
> 3. I HATE "safe" cast conversions. If you wa
On Friday, March 29, 2013 22:46:27 Steven Schveighoffer wrote:
> The issue is when you think you are invoking the opCast operator, but you
> inadvertently end up casting using the compiler's type-bypassing version.
> I agree the opCast call is safe, it's that its name coincides with the
> "throw al
On Friday, March 29, 2013 22:50:16 Steven Schveighoffer wrote:
> On Fri, 29 Mar 2013 19:35:35 -0400, Jonathan M Davis
>
> wrote:
> > On Friday, March 29, 2013 10:03:31 Steven Schveighoffer wrote:
> >> 1. unixTimeToStdTime should take ulong.
> >
> > Why? You're converting a time_t, so unixToStdTi
On Fri, 29 Mar 2013 19:35:35 -0400, Jonathan M Davis
wrote:
On Friday, March 29, 2013 10:03:31 Steven Schveighoffer wrote:
1. unixTimeToStdTime should take ulong.
Why? You're converting a time_t, so unixToStdTime explicitly uses
time_t. Its
size is system-dependent.
Because if your un
On Fri, 29 Mar 2013 18:08:28 -0400, Jonathan M Davis
wrote:
std.conv.to is the standard way to convert one type to another. I see no
reason to introduce stuff specific to core.time or std.datetime to do
conversions. It should just hook into the standard stuff for that. If
everything uses std.
On Fri, 29 Mar 2013 18:07:38 -0400, Jesse Phillips
wrote:
On Friday, 29 March 2013 at 21:36:37 UTC, Steven Schveighoffer wrote:
(and yes, casts are dangerous and should be avoided).
I think you are applying "common knowledge" to something where it
doesn't apply.
auto foo = cast(TickDur
On Friday, March 29, 2013 10:03:31 Steven Schveighoffer wrote:
> 1. unixTimeToStdTime should take ulong.
Why? You're converting a time_t, so unixToStdTime explicitly uses time_t. Its
size is system-dependent.
- Jonathan M Davis
On Friday, 29 March 2013 at 21:36:37 UTC, Steven Schveighoffer
wrote:
(and yes, casts are dangerous and should be avoided).
I think you are applying "common knowledge" to something where it
doesn't apply.
auto foo = cast(TickDuration) bar;
This is not unsafe, unless you claim that opCast is
On Friday, March 29, 2013 17:36:37 Steven Schveighoffer wrote:
> On Fri, 29 Mar 2013 17:17:58 -0400, Jonathan M Davis
>
> wrote:
> > But std.conv.to is the standard way to convert things, and I don't see
> > how
> > changing how std.conv.to determines how to do the conversion would help
> > us
>
On Fri, 29 Mar 2013 17:17:58 -0400, Jonathan M Davis
wrote:
But std.conv.to is the standard way to convert things, and I don't see
how
changing how std.conv.to determines how to do the conversion would help
us
any. Whether there was a to function on the type or opCast really makes
no
dif
On Friday, March 29, 2013 15:33:35 Steven Schveighoffer wrote:
> On Fri, 29 Mar 2013 15:22:19 -0400, Jonathan M Davis
>
> wrote:
> > On Friday, March 29, 2013 10:03:31 Steven Schveighoffer wrote:
> >> 3. I HATE "safe" cast conversions. If you want to make a conversion,
> >> use
> >> a method/prop
On Fri, 29 Mar 2013 15:22:19 -0400, Jonathan M Davis
wrote:
On Friday, March 29, 2013 10:03:31 Steven Schveighoffer wrote:
3. I HATE "safe" cast conversions. If you want to make a conversion,
use
a method/property. I don't even know why D allows overloading casting.
Casts are way too b
On Friday, March 29, 2013 10:03:31 Steven Schveighoffer wrote:
> On Fri, 29 Mar 2013 01:42:41 -0400, Andrej Mitrovic
> > sw.stop();
> >
> > TickDuration time = sw.peek();
> >
> > long secs = time.seconds;
> > long msecs = time.msecs - (1000 * secs);
> > long usecs = ti
On Fri, 29 Mar 2013 10:22:43 -0400, Timon Gehr wrote:
On 03/29/2013 03:20 PM, Timon Gehr wrote:
On 03/29/2013 03:03 PM, Steven Schveighoffer wrote:
...
3. I HATE "safe" cast conversions. If you want to make a conversion,
use a method/property. I don't even know why D allows overloading
cas
On 03/29/2013 03:20 PM, Timon Gehr wrote:
On 03/29/2013 03:03 PM, Steven Schveighoffer wrote:
...
3. I HATE "safe" cast conversions. If you want to make a conversion,
use a method/property. I don't even know why D allows overloading
casting. Casts are way too blunt for this.
...
The only c
On 03/29/2013 03:03 PM, Steven Schveighoffer wrote:
...
3. I HATE "safe" cast conversions. If you want to make a conversion,
use a method/property. I don't even know why D allows overloading
casting. Casts are way too blunt for this.
...
The only conceivable reason is opCast!bool, eg. for u
On Fri, 29 Mar 2013 01:42:41 -0400, Andrej Mitrovic
wrote:
import core.thread;
import core.time;
import std.datetime;
import std.stdio;
void main()
{
StopWatch sw;
sw.start();
Thread.sleep(dur!"seconds"(1));
Thread.sleep(dur!"msecs"(200));
Thread.sleep(dur!"usecs"(800));
On Friday, March 29, 2013 06:42:41 Andrej Mitrovic wrote:
> Why was this inconsistency introduced?
The main problem with TickDuration is that it was written by SHOO rather than
by me and was adjusted to fit into core.time rather than being part of the
original design. I've made some improvements
There are many many time formats. Do you want them all readily
supported?
import core.thread;
import core.time;
import std.datetime;
import std.stdio;
void main()
{
StopWatch sw;
sw.start();
Thread.sleep(dur!"seconds"(1));
Thread.sleep(dur!"msecs"(200));
Thread.sleep(dur!"usecs"(800));
sw.stop();
TickDuration time = sw.peek();
long secs
35 matches
Mail list logo
