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.









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:









-- Chris Sauls
Jan 02 2006
parent Manfred Nowak <svv1999 hotmail.com> writes:
Chris Sauls cited:

[...]









[...]

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