www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why can I convert a d_time to int without error?

reply Grzegorz Adam Hankiewicz <gradhanews ya.com> writes:
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.
Dec 31 2005
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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
Dec 31 2005
next sibling parent Grzegorz Adam Hankiewicz <gradhanews ya.com> writes:
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.
Jan 01 2006
prev sibling parent reply S. Chancellor<dnewsgr mephit.kicks-ass.org> writes:
No need to be so aggravated.  It's an easy mistake to make, and after
all, this is the D.learn newsgroup.
Manfred Nowak <svv1999 hotmail.com> wrote:
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

-- Email works.
Jan 03 2006
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
S. Chancellor wrote:

 No need to be so aggravated.  It's an easy mistake to make, and
 after all, this is the D.learn newsgroup.

Same to you. Ever heard of the drama triangle? -manfred
Jan 03 2006
parent reply S. Chancellor<dnewsgr mephit.kicks-ass.org> writes:
Manfred Nowak <svv1999 hotmail.com> wrote:
S. Chancellor wrote:

 No need to be so aggravated.  It's an easy mistake to make, and
 after all, this is the D.learn newsgroup.

Same to you. Ever heard of the drama triangle? -manfred

Ever heard "If you can't say something nice, don't say anything at all?" If you don't like stupid questions, don't answer them. -- Email works.
Jan 03 2006
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
S. Chancellor wrote:

[...]
 Ever heard "If you can't say something nice, don't say anything
 at all?" 
   If you don't like stupid questions, don't answer them.

Okay. I see, that the climate of the D-NG has changed drastically. Instead of polishing up my posts you want me to say nothing. Thats the second time that someone reacts this way to my incapabilities stemming from the fact not to be a native english speaker. I leave the D-community now. Please inform Walter to nominate some other co-editor. -manfred
Jan 03 2006
parent John Reimer <terminal.node gmail.com> writes:
Manfred Nowak wrote:
 S. Chancellor wrote:
 
 [...]
 Ever heard "If you can't say something nice, don't say anything
 at all?" 
   If you don't like stupid questions, don't answer them.

Okay. I see, that the climate of the D-NG has changed drastically. Instead of polishing up my posts you want me to say nothing. Thats the second time that someone reacts this way to my incapabilities stemming from the fact not to be a native english speaker. I leave the D-community now. Please inform Walter to nominate some other co-editor. -manfred

Manfred, you can't use the English-is-a-second-language excuse anymore. Your posts are quite purposeful in your disdain for people or their posts. You seem to have enough of a handle of English to fully understand the points you are getting across. In fact, maybe you are just being a little too cocky with your handle of English. It's like taking a big knife in your hand and deftly twirling it on your fingertips... only to discover that you lack the coordination for the maneuver; in short, it's dangerous, and the way you've been "twirling" your English around is bound to hurt you and others. You could easily avoid this by writing plain and straight English and avoid all attempts at English idiom, sarcasm, or wit. You just can't do it. I've been completely perplexed at some of your posts. You have been your own worst enemy. Maybe I shouldn't have addressed you directly like this. I'm sorry if this offends you, but I believe it needed to be said. -JJR
Jan 04 2006
prev sibling parent reply Ben Phillips <Ben_member pathlink.com> writes:
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
Jan 02 2006
parent reply a.c.edwards <a.c.edwards_member pathlink.com> writes:
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
Jan 02 2006
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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
Jan 02 2006
next sibling parent reply Chris Sauls <ibisbasenji gmail.com> writes:
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
Jan 02 2006
parent Manfred Nowak <svv1999 hotmail.com> writes:
Chris Sauls cited:

[...]
 # typedef int myint;
 # int i;
 # myint m;
 # i = m;             // OK
 # m = i;             // error
 # m = cast(myint)i;  // OK

Thank you for that clarification. 1) The first assignment shows the case where a variable of a typedef'd type is assigned to a variable of the base type of the typedef ... ... while I was reasoning over assignments to "any other type than its base type". 2) The second assignment shows the case where a variable of the base type is assigned to a variable of a typedef'd type ... ... and according to the comment it is erroneous. This can happen only if the LHS of the assignment is _not_ converted to its base type. This again can only happen if the rules for "Usual Arithmetic Conversions" do _not_ apply. 3) The third assignment shows the case 2) again but with the addition of a `cast' to the typedef'd type with the comment, that this OK. The `cast' would be superfluous if the rules for "Usual Arithmetic Conversions" would apply ... as shown in case 2). From facts 2) and 3) follows already that the rules stated under "Usual Arithmetic Conversions" do _not_ apply to assignments. Further thinking that the examples above are special cases would lead to code: typedef int myint; myint a,b,c; a= b + c; // error, because `b + c' is converted to `int' Therefore the rules stated under "Usual Arithmetic Conversions" are incomplete. At least rule 1) must be reformulated. For example: 1. If at least one operand is typedef'd then 1. if it is the same typedef, no more conversions are done 2. any typedef on the left of an assignment remains unconverted 3. all remaining typedef's are converted to their underlying type. Note, that 1.2) may be placed wrongly in this section of the docs because in general the assignment is not an numeric or arithmetic operator. -manfred ( x-post and f'up to D.bugs)
Jan 03 2006
prev sibling next sibling parent a.c.edwards <a.c.edwards_member pathlink.com> writes:
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
Jan 02 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
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
Jan 03 2006
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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
Jan 03 2006
parent reply S. Chancellor<dnewsgr mephit.kicks-ass.org> writes:
Manfred Nowak <svv1999 hotmail.com> wrote:
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

You are the one who is sorely mistaken. and you don't need to be so angsty. If d_time is a typedef of long, and long can be converted to an int. Then there's no reason a d_time can't be converted to a long and then to an int. The point of a typedef is keeping other stuff out of your typedefs, not keeping your typedefs out of other stuff. ÀComprende? -- Email works.
Jan 03 2006
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
S. Chancellor wrote:

[...]
 The point of a typedef is keeping other stuff out of your
 typedefs, not keeping your typedefs out of other stuff.
 ÀComprende?

Me parece chino. The rules do not demand to convert my typedefs into other stuff on arithmetics? -manfred P.S.: If you want to take over censorship for my postings I will be glad to have them polished by you.
Jan 03 2006
parent reply jicman <jicman_member pathlink.com> writes:
Manfred Nowak says...
S. Chancellor wrote:

[...]
 The point of a typedef is keeping other stuff out of your
 typedefs, not keeping your typedefs out of other stuff.
 ÀComprende?

Me parece chino.

Manfred, you made a mistake on the Spanish statement above. It should had been, "me pareces chino." Just clearing things up. :-) josé PS: Sorry, I had to do it. :-)
Jan 04 2006
parent reply Carlos Santander <csantander619 gmail.com> writes:
jicman escribió:
 Manfred Nowak says...
 
S. Chancellor wrote:

[...]

The point of a typedef is keeping other stuff out of your
typedefs, not keeping your typedefs out of other stuff.
ÀComprende?

Me parece chino.

Manfred, you made a mistake on the Spanish statement above. It should had been, "me pareces chino."

Yo pensaba que se refería a lo que S. Chancellor escribió, no a él mismo. A mí me pareció correcto. For those lost in translation: Manfred wrote "it seems chinese to me". José argues that it should've been "you seem chinese to me", which I think is not what Manfred tried to say.
 
 Just clearing things up. :-)
 
 josé
 
 PS: Sorry, I had to do it. :-)
 
 

Same here :P -- Carlos Santander Bernal
Jan 04 2006
parent jicman <jicman_member pathlink.com> writes:
Carlos Santander says...
jicman escribió:
 Manfred Nowak says...
 
S. Chancellor wrote:

[...]

The point of a typedef is keeping other stuff out of your
typedefs, not keeping your typedefs out of other stuff.
ÀComprende?

Me parece chino.

Manfred, you made a mistake on the Spanish statement above. It should had been, "me pareces chino."

Yo pensaba que se refería a lo que S. Chancellor escribió, no a él mismo. A mí me pareció correcto.

Carlos, ahora que vuelvo a leerlo, entiendo lo que dices. Pense que el estaba llamando chino al otro. Ok, buena aclaracion. :-) Folks, Carlos just straightened me out. I misinterpreted the statement because of the heated battle and so I thought something that it was not. Carlos, in his good nature, cleared the statement for me. :-) Carry on... :-)
For those lost in translation: Manfred wrote "it seems chinese to me". José 
argues that it should've been "you seem chinese to me", which I think is not 
what Manfred tried to say.

 
 Just clearing things up. :-)
 
 josé
 
 PS: Sorry, I had to do it. :-)
 
 

Same here :P -- Carlos Santander Bernal

Jan 04 2006