Thread overview | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
December 31, 2005 Why can I convert a d_time to int without error? | ||||
---|---|---|---|---|
| ||||
Hi, I'm testing this code: [0:gradha@noir:0] [~/test]$ cat hello.d import std.stdio; import std.date; int main() { int bad_date = getUTCtime(); d_time good_date = getUTCtime(); writefln("This is bad: %s", toDateString(bad_date)); writefln("This is good: %s", toDateString(good_date)); return 0; } [0:gradha@noir:0] [~/test]$ ./hello This is bad: Sun Dec 07 1969 This is good: Sat Dec 31 2005 Obviously d_time types should not be converted to ints. From str.date documentation I didn't see any warnings about this. In fact, I thought a d_time type would be just like C's simple time data type (t_time) and there would be no problems doing this. The example shows otherwise. Shouldn't the compiler give an error about the conversion? I didn't find any warning switches on dmd's command line help to turn on verbosity about such obvious conversion mistakes. Is this maybe a bug in dmd allowing to convert silently a d_time value to int? I'm using dmd 0.141. |
December 31, 2005 Re: Why can I convert a d_time to int without error? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Grzegorz Adam Hankiewicz | Grzegorz Adam Hankiewicz wrote: [...] > I didn't find any warning switches > on dmd's command line help to turn on verbosity about such > obvious conversion mistakes. [...] Maybe you were too embarressed to see the "-w" warning switch on the command line help. Maybe you have not read http://www.digitalmars.com/d/warnings.html. But if you have a C background as your comparison with t_time suggests you should know the implicit conversion rules obeyed by C and that therefore assigning to a variable may cause loss of data, if the type of the variable is not known exactly to you. It depends on your habits of handlinmg risks what to do in case of unsureness. You decided to take a risk, lost and now critisizes D. You could have stated your prerequisite by inserting code like assert( typeof(getUTCtime()).sizeof<= int.sizeof); and would have been on the warned side forever. -manfred |
January 01, 2006 Re: Why can I convert a d_time to int without error? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manfred Nowak | El Sat, 31 Dec 2005 19:34:53 +0000, Manfred Nowak escribió:
> Maybe you were too embarressed to see the "-w" warning switch on the command line help.
Embarressed? No, if I was embarrassed by every mistake I do I would never ever get out of my mother's basement (oh, wait).
I apologise for not having read correctly the output of dmd on the command line and causing so much trouble.
|
January 02, 2006 Re: Why can I convert a d_time to int without error? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Grzegorz Adam Hankiewicz | In article <pan.2005.12.31.11.29.06.445640@ya.com>, Grzegorz Adam Hankiewicz says... > >Hi, I'm testing this code: > > [0:gradha@noir:0] [~/test]$ cat hello.d > import std.stdio; > import std.date; > > int main() > { > int bad_date = getUTCtime(); > d_time good_date = getUTCtime(); > writefln("This is bad: %s", toDateString(bad_date)); > writefln("This is good: %s", toDateString(good_date)); > return 0; > } > [0:gradha@noir:0] [~/test]$ ./hello > This is bad: Sun Dec 07 1969 > This is good: Sat Dec 31 2005 > >Obviously d_time types should not be converted to ints. From str.date documentation I didn't see any warnings about this. In fact, I thought a d_time type would be just like C's simple time data type (t_time) and there would be no problems doing this. > >The example shows otherwise. Shouldn't the compiler give an error >about the conversion? I didn't find any warning switches on dmd's >command line help to turn on verbosity about such obvious conversion >mistakes. Is this maybe a bug in dmd allowing to convert silently >a d_time value to int? I'm using dmd 0.141. > d_time is an alias rather than a typedef meaning that it is not actually a new type Currently in data.d, d_time is declared as "alias long d_time;" Perhaps this should be changed "typedef long d_time;"? I think it should |
January 02, 2006 Re: Why can I convert a d_time to int without error? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Phillips | In article <dpbd1t$31bq$1@digitaldaemon.com>, Ben Phillips says... > >In article <pan.2005.12.31.11.29.06.445640@ya.com>, Grzegorz Adam Hankiewicz says... >> >>Hi, I'm testing this code: >> >> [0:gradha@noir:0] [~/test]$ cat hello.d >> import std.stdio; >> import std.date; >> >> int main() >> { >> int bad_date = getUTCtime(); >> d_time good_date = getUTCtime(); >> writefln("This is bad: %s", toDateString(bad_date)); >> writefln("This is good: %s", toDateString(good_date)); >> return 0; >> } >> [0:gradha@noir:0] [~/test]$ ./hello >> This is bad: Sun Dec 07 1969 >> This is good: Sat Dec 31 2005 >> >>Obviously d_time types should not be converted to ints. From str.date documentation I didn't see any warnings about this. In fact, I thought a d_time type would be just like C's simple time data type (t_time) and there would be no problems doing this. >> >>The example shows otherwise. Shouldn't the compiler give an error >>about the conversion? I didn't find any warning switches on dmd's >>command line help to turn on verbosity about such obvious conversion >>mistakes. Is this maybe a bug in dmd allowing to convert silently >>a d_time value to int? I'm using dmd 0.141. >> > >d_time is an alias rather than a typedef meaning that it is not actually a new type > >Currently in data.d, d_time is declared as "alias long d_time;" Perhaps this should be changed "typedef long d_time;"? I think it should > It does not matter whether d_time is a typedef or an alias. The fact remains that if you assign a long (i.e., d_time) to an int, implicit conversion will occur. # typedef long d_time; # d_time dtime; # int time; # # dtime = cast(d_time)1000000000000000000; # time = dtime; # writefln(time); output: C:\d>dtime -1486618624 The documentation clearly states that a typedef will be implicitly converted to it's base type during assignment. See: http://www.digitalmars.com/d/type.html Rule number 1 under "Usual Arithmetic Conversions" Regards, Andrew |
January 02, 2006 Re: Why can I convert a d_time to int without error? | ||||
---|---|---|---|---|
| ||||
Posted in reply to a.c.edwards | a.c.edwards wrote:
[...]
> The documentation clearly states that a typedef will be implicitly converted to it's base type during assignment.
[...]
Sorry, there is no such clear statement in the docs.
Assignment is not an _arithmetic_ operator.
According to the specs the result of an assignment of a typedef'd type to any other type than its base type is not defined.
-manfred
|
January 03, 2006 Re: Why can I convert a d_time to int without error? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manfred Nowak | Manfred Nowak wrote: > a.c.edwards wrote: > > [...] > >>The documentation clearly states that a typedef will be >>implicitly converted to it's base type during assignment. > > [...] > > Sorry, there is no such clear statement in the docs. > > Assignment is not an _arithmetic_ operator. > > According to the specs the result of an assignment of a typedef'd type to any other type than its base type is not defined. > > -manfred Quoted directly from http://digitalmars.com/d/type.html ######################### D has a lot of types, both built in and derived. It would be tedious to require casts for every type conversion, so implicit conversions step in to handle the obvious ones automatically. A typedef can be implicitly converted to its underlying type, but going the other way requires an explicit conversion. For example: # typedef int myint; # int i; # myint m; # i = m; // OK # m = i; // error # m = cast(myint)i; // OK ######################### -- Chris Sauls |
January 03, 2006 Re: Why can I convert a d_time to int without error? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manfred Nowak | In article <Xns973FEC134871Asvv1999hotmailcom@63.105.9.61>, Manfred Nowak says... > >a.c.edwards wrote: > >[...] >> The documentation clearly states that a typedef will be implicitly converted to it's base type during assignment. >[...] > >Sorry, there is no such clear statement in the docs. > >Assignment is not an _arithmetic_ operator. > >According to the specs the result of an assignment of a typedef'd type to any other type than its base type is not defined. > >-manfred > > Maybe you and I are reading two completely different specs. The one I read (i.e. the link I provided) was extremely clear to me. Or maybe it's just that my inexperience as a programmer does not grant me the necessary required knowlege to discern what is clear from what is not. But I would go as far as to suggest that if is clear to neophyte, then it is pretty damn clear to just about anyone else except those who chose not to read it. Andrew |
January 03, 2006 Re: Why can I convert a d_time to int without error? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manfred Nowak | On Tue, 03 Jan 2006 09:12:27 +1100, Manfred Nowak <svv1999@hotmail.com> wrote: > a.c.edwards wrote: > > [...] >> The documentation clearly states that a typedef will be >> implicitly converted to it's base type during assignment. > [...] > > Sorry, there is no such clear statement in the docs. > > Assignment is not an _arithmetic_ operator. > > According to the specs the result of an assignment of a typedef'd > type to any other type than its base type is not defined. I suggest that the 'mistake' in that part of the documentation (Usual Arithmetic Conversions) is that it uses the word "arithmetic" when it really just means "numeric". -- Derek Parnell Melbourne, Australia |
January 03, 2006 Re: Why can I convert a d_time to int without error? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | Derek Parnell wrote:
[...]
> uses the word "arithmetic" when it really just means "numeric".
Changing the wording would not help much. Please see my answer to "Chris Sauls" posting.
-manfred
|
Copyright © 1999-2021 by the D Language Foundation