Prev: Python parsing XML file problem with SAX
Next: Linear nterpolation in 3D
From: Carl Banks on 8 Aug 2010 00:34
On Aug 7, 8:18 pm, Dennis Lee Bieber <wlfr...(a)ix.netcom.com> wrote:
> On Sat, 7 Aug 2010 13:02:56 -0700 (PDT), Carl Banks
> <pavlovevide...(a)gmail.com> declaimed the following in
> gmane.comp.python.general:
>
>
>
> > Not really.  Very few people call int(), float(), and company "type
> > casts".  They aren't type casts at all, they are constructors that
> > sometimes have the same semantics as type casts in C.
>
>         Given the different syntax, I never see them as "type casts"... They
> look like functions that take an argument (or more than one:
> int("FE", 16) ) and convert it into a value of the type named...
>
>         C, OTOH, I'm never sure if a conversion (the bit pattern of the
> result is different from the bit pattern of the source) or an
> equivalencing (the bit pattern of the result is the same as the bit
> pattern of the source, but the /interpretation/ of those bits is
> different) is taking place.

C's type casts are always a conversion. There are no exceptions I'm
aware of.


The only way to reinterpret bits in C is to take a reference, cast the
pointer, and then derefernece again. (C++ has a reinterpret_cast for
that.)

*(int*)&x


Casting an integer to a pointer retains the same bits because a
pointer's "value" is considered to be the same as the unsigned integer
with the same bit pattern.

Pointer-to-pointer casts in C++ don't always retain the same bits,
BTW.


Carl Banks
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Python parsing XML file problem with SAX
Next: Linear nterpolation in 3D