Matthias Blume wrote:
> "Rob Thorpe" <[EMAIL PROTECTED]> writes:
> > Matthias Blume wrote:
> >> "Rob Thorpe" <[EMAIL PROTECTED]> writes:
> >>
> >> > I think we're discussing this at cross-purposes.  In a language like C
> >> > or another statically typed language there is no information passed
> >> > with values indicating their type.
> >>
> >> You seem to be confusing "does not have a type" with "no type
> >> information is passed at runtime".
> >>
> >> > Have a look in a C compiler if you don't believe me.
> >>
> >> Believe me, I have.
> >
> > In a C compiler the compiler has no idea what the values are in the
> > program.
>
> It is no different from any other compiler, really.  If the compiler
> sees the literal 1 in a context that demands type int, then it knows
> perfectly well what value that is.

Well, with a literal yes.  But with the value of some variable x at
runtime it only know the type because it knows the type of the
variable.  Similarly the type of values generated by an expression are
only known because the type the expression generates is known.

> > It knows only their type in that it knows the type of the variable they
> > are contained within.
> > Would you agree with that?

Would you?

> >> > No it doesn't. Casting reinterprets a value of one type as a value of
> >> > another type.
> >> > There is a difference.  If I cast an unsigned integer 2000000000 to a
> >> > signed integer in C on the machine I'm using then the result I will get
> >> > will not make any sense.
> >>
> >> Which result are you getting?  What does it mean to "make sense"?
> >
> > Well the right one actually, bad example.
> >
> > But, if I cast an unsigned int 2500000000 to signed I get -1794967296.
>
> So, why do you think this "does not make sense"?

Well, it makes sense in terms of the C spec certainly.
It does not make sense in that it does not emit an error.

>And, as this example
> illustrates, casting in C maps values to values.  Depending on the
> types of the source and the target, a cast might change the underlying
> representation, or it might leave it the same.  But it does produce a
> value, and the result value is usually not the same as the argument
> value, even if the representation is the same.

Yes. I'm not arguing with that.

-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to