Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #138944 > unrolled thread

A final word on casting.

Back to article view | Back to comp.lang.c

Contents

  A final word on casting. chanrasjid@gmail.com - 2018-12-23 03:02 -0800
    Re: A final word on casting. Bart <bc@freeuk.com> - 2018-12-23 12:11 +0000
      Re: A final word on casting. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-23 13:08 +0000
        Re: A final word on casting. Bart <bc@freeuk.com> - 2018-12-23 14:43 +0000
          Re: A final word on casting. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-23 14:56 +0000
            Re: A final word on casting. chanrasjid@gmail.com - 2018-12-23 07:08 -0800
              Re: A final word on casting. Bart <bc@freeuk.com> - 2018-12-23 15:55 +0000
                Re: A final word on casting. Bart <bc@freeuk.com> - 2018-12-23 16:07 +0000
                Re: A final word on casting. James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-23 08:21 -0800
                Re: A final word on casting. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-23 17:56 +0000
                  Re: A final word on casting. Bart <bc@freeuk.com> - 2018-12-23 19:23 +0000
                    Re: A final word on casting. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-23 20:12 +0000
                    Re: A final word on casting. James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-23 14:06 -0800
                    Re: A final word on casting. Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-28 09:34 -0800
                      Re: A final word on casting. Bart <bc@freeuk.com> - 2018-12-28 20:29 +0000
                        Re: A final word on casting. Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-28 15:07 -0800
                          Re: A final word on casting. Richard Damon <Richard@Damon-Family.org> - 2018-12-28 20:56 -0500
                            Re: A final word on casting. Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-29 09:22 -0800
                              Re: A final word on casting. Tim Rentsch <txr@alumni.caltech.edu> - 2019-01-01 13:27 -0800
                                Re: A final word on casting. Bart <bc@freeuk.com> - 2019-01-02 01:07 +0000
                                  Re: A final word on casting. Bart <bc@freeuk.com> - 2019-01-03 18:55 +0000
                                    Re: A final word on casting. Richard Damon <Richard@Damon-Family.org> - 2019-01-03 22:27 -0500
                                      Re: A final word on casting. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-04 16:25 -0500
                    Re: A final word on casting. Ike Naar <ike@iceland.freeshell.org> - 2018-12-28 19:10 +0000
                      Re: A final word on casting. James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-28 12:33 -0800
                  Re: A final word on casting. "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-23 14:11 -0800
                  Re: A final word on casting. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-24 02:54 -0800
                    Re: A final word on casting. fir <profesor.fir@gmail.com> - 2018-12-24 03:24 -0800
                      Re: A final word on casting. fir <profesor.fir@gmail.com> - 2018-12-24 03:29 -0800
                        Re: A final word on casting. fir <profesor.fir@gmail.com> - 2018-12-24 03:45 -0800
                    Re: A final word on casting. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-24 13:44 +0000
                    Re: A final word on casting. Richard Damon <Richard@Damon-Family.org> - 2018-12-24 08:51 -0500
                Re: A final word on casting. Richard Damon <Richard@Damon-Family.org> - 2018-12-23 14:53 -0500
                  Re: A final word on casting. Robert Wessel <robertwessel2@yahoo.com> - 2018-12-24 09:39 -0600
                    Re: A final word on casting. Richard Damon <Richard@Damon-Family.org> - 2018-12-24 13:38 -0500
                Re: A final word on casting. Manfred <noname@add.invalid> - 2018-12-23 21:22 +0100
                Re: A final word on casting. Manfred <noname@add.invalid> - 2018-12-23 21:33 +0100
              Re: A final word on casting. James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-23 10:56 -0500
                Re: A final word on casting. Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2018-12-23 17:18 +0100
          Re: A final word on casting. Bart <bc@freeuk.com> - 2018-12-23 20:03 +0000
      Re: A final word on casting. "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-28 14:47 -0500
    Re: A final word on casting. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-23 12:24 +0000
    Re: A final word on casting. Richard Damon <Richard@Damon-Family.org> - 2018-12-23 07:28 -0500
      Re: A final word on casting. Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-28 07:50 -0800
    Re: A final word on casting. fir <profesor.fir@gmail.com> - 2018-12-23 04:35 -0800
      Re: A final word on casting. fir <profesor.fir@gmail.com> - 2018-12-23 04:42 -0800
        Re: A final word on casting. fir <profesor.fir@gmail.com> - 2018-12-23 04:52 -0800
    Re: A final word on casting. James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-23 10:28 -0500
    Re: A final word on casting. Barry Schwarz <schwarzb@dqel.com> - 2018-12-23 11:39 -0800
      Re: A final word on casting. Ike Naar <ike@iceland.freeshell.org> - 2018-12-24 07:56 +0000
    Re: A final word on casting. chanrasjid@gmail.com - 2018-12-24 14:03 -0800
      Re: A final word on casting. Barry Schwarz <schwarzb@dqel.com> - 2018-12-24 14:39 -0800
        Re: A final word on casting. chanrasjid@gmail.com - 2018-12-24 14:50 -0800
          Re: A final word on casting. Keith Thompson <kst-u@mib.org> - 2018-12-24 15:34 -0800
        Re: A final word on casting. Keith Thompson <kst-u@mib.org> - 2018-12-24 15:23 -0800
          Re: A final word on casting. chanrasjid@gmail.com - 2018-12-24 20:34 -0800
      Re: A final word on casting. Keith Thompson <kst-u@mib.org> - 2018-12-24 14:52 -0800
        Re: A final word on casting. chanrasjid@gmail.com - 2018-12-24 20:25 -0800
      Re: A final word on casting. James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-24 17:52 -0500
      Re: A final word on casting. luser droog <luser.droog@gmail.com> - 2018-12-24 21:27 -0800
        Re: A final word on casting. luser droog <luser.droog@gmail.com> - 2018-12-24 21:39 -0800
        Re: A final word on casting. chanrasjid@gmail.com - 2018-12-24 22:36 -0800

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#139186

On 12/23/2018 7:11 AM, Bart wrote:
> Try:
> printf("%d\n", (int)1.9999999999999999999999999999999);
> 
> I seem to get the answer 2.

I had run into this issue in my debugger years ago.  I was displaying
what was in the st(x) registers and I wanted them to be contextual, so
that values around 1000 would display with a %6.2f format, etc., but
this was all in assembly so I had to get into the meat of it.

I wound up discovering that based on the precision of the value, it's
often best to add the smallest possible non-denormal value to the
floating point value before converting it.  This will force it to go
to the next largest value, which may be enough to tip it over to what
we would expect, so rather than seeing:

     1.99999999999999e+3

You see:

     2.00000000000001e+3

Then, when you range it into an appropriate value, you wind up with:

     2000.00

That little bit of rounding in the least significant bit makes all
the difference with floating point values (for display purposes).

How they actually work are visualized here.  You can do as Tim Rentsch
suggested and use your integer engine and get the significant digits,
and then range them into the exponent values if you want to pursue it:

     http://www.libsf.org/software/misc/base10_base2.ods

It's just integer math to add up where the bits are.  You can do it
without any loss.  32-bit and 64-bit floating points are always stored
with an implicit 1. in their binary portion, but 80-bit fp has an ex-
plicit 1.  Just iterate through and add up the 64-bit base-10 integer
values representing the bit pattern, and you'll have a true answer.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#138946

chanrasjid@gmail.com writes:

> I have been playing with C for about 30 years, but I could never get
> to really understand casting. I made various weak attempts and gave
> up; I knew I don't need to be professional in C.
>
> I take my layman approach to casting: it is to represent the value of
> a certain type in a different data type.

Let me clarify a few terms.

C support converting between values of different types.  These
conversions can be done implicitly or explicitly using a cast operator.
The effect is the same in either case, so what you call casting may be
happening even when there is no explicit cast operator.

So conversions apply to values, whereas objects, in C, are regions of
storage that use bits to represent values.  Casts and implicit
conversions have nothing to do with representations.  The representation
is set when a value is assigned to an object, and it is interpreted to
yield a value when an object is accessed.

> Some things I tested work and I don't care about its correctness. I
> always get it correct: (int) 1.23 always give 1.

Yes, (int)1.23 is always the value 1 of type int.  You get the same
conversion in other contexts too:

  void f(int x);
  ....
  f(1.23);      // 1.23 is converted to int in the call
  int i = 1.23; // 1,23 is converted to int here too.
  
> But if we reason
> things out, if casting tries to represent a float as any integer type,
> it is not possible.

(Note: float is a specific C type, but 1.23 is a constant of type
double.)

The conversion of 1.23 to int does not involve the representation of
either value in any way.  It's an operation that converts a value of
type double to a value of type int.

> So C may here just return the integral part; but
> it seems this is not "official".

No, it's official.  The C language specification says what should
happen.

> Casting a signed int to a long unsigned integer is meaningless if the
> original integer is negative;

That conversion, too, is both well-defined and "official".

> I think the experts know what result would be returned as per some C
> standards;

They do!  The The C standard says what (unsigned long)-1 means: it's the
largest value of type unsigned int.

> but then what is the purpose when it is meaningless.

How can something that has a well-defined meaning be meaningless?  You
mean, presumably, that you don't see the purpose of that conversion.
That's fine.  There are lots of things in this world I don't see the
purpose of.

> The only use I think is safe is casting compatible types to another
> with the larger storage, as int to _int64, or float to double. Casting
> double to float is OK as we expect a loss of precision.

Type conversion (what you call casting) has many more applications than
simply converting between arithmetic types.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#138947

On 12/23/18 6:02 AM, chanrasjid@gmail.com wrote:
> I have been playing with C for about 30 years, but I could never get to really understand casting. I made various weak attempts and gave up; I knew I don't need to be professional in C.
> 
> I take my layman approach to casting: it is to represent the value of a certain type in a different data type. 
> 
> Some things I tested work and I don't care about its correctness. I always get it correct: (int) 1.23 always give 1. But if we reason things out, if casting tries to represent a float as any integer type, it is not possible. So C may here just return the integral part; but it seems this is not "official".
> 
> Casting a signed int to a long unsigned integer is meaningless if the original integer is negative; I think the experts know what result would be returned as per some C standards; but then what is the purpose when it is meaningless.
> 
> The only use I think is safe is casting compatible types to another with the larger storage, as int to _int64, or float to double. Casting double to float is OK as we expect a loss of precision.
> 

The simplest description of casting is that it tells the compiler to
perform a conversion to the requested type. Sometimes it is a conversion
the compiler would be willing to do implicitly as if you assigned a
variable of the old type to the new type (like float to int, or signed
int to unsigned), or it could be a conversion that would be a constraint
violation like void* to long.

The casts that c would perform implicitly are generally 'safe', although
as you noted sometimes produce results that lose part of the value.
Converting floating point types to integer types will lose the fraction
of the number. Converting a type to another that doesn't represent the
full range of the first has the danger of overflow (this could be a
floating point type to an integer type, a larger type to a smaller, or a
signed to an unsigned). Not.e double to float can produce an overfloow,
as well as a precision lose, as double can express a wide range of
numbers than float (but often you don't see that as float expresses a
fairly wide range to start with)

Overflow of unsigned types is well defined by the standard, producing a
result that is correct modulo the range of the type, but yes, that can
seem meaningless at times.

[toc] | [prev] | [next] | [standalone]

#139169

Richard Damon <Richard@Damon-Family.org> writes:

> Overflow of unsigned types is well defined by the standard,
> producing a result that is correct modulo the range of the
> type,

If the conversion is from an integer type.  If converting from a
real type, an out-of-range value gives undefined behavior.

[toc] | [prev] | [next] | [standalone]

#138948

W dniu niedziela, 23 grudnia 2018 12:02:32 UTC+1 użytkownik chanr...@gmail.com napisał:
> I have been playing with C for about 30 years, but I could never get to really understand casting. I made various weak attempts and gave up; I knew I don't need to be professional in C.
> 
> I take my layman approach to casting: it is to represent the value of a certain type in a different data type. 
> 
> Some things I tested work and I don't care about its correctness. I always get it correct: (int) 1.23 always give 1. But if we reason things out, if casting tries to represent a float as any integer type, it is not possible. So C may here just return the integral part; but it seems this is not "official".
> 
> Casting a signed int to a long unsigned integer is meaningless if the original integer is negative; I think the experts know what result would be returned as per some C standards; but then what is the purpose when it is meaningless.
> 
> The only use I think is safe is casting compatible types to another with the larger storage, as int to _int64, or float to double. Casting double to float is OK as we expect a loss of precision.

casting f->i is specially dangerous idea

i once noticed it is specially dangerous when doing 2d graphics (and you want to provide functions for both integer and float coordinates)
 as if you got coordinates shifted towards zero when draw across axes yu got like one pixel stolen (-0.99 to 0.99 which length is roughly 2 become 0 to 0 which lengthh is 0 - and this just makes sprites to be deformed if draved on 0,0 point (you could not drave on it but you stil may logical cout it and its the case)

so this means that the default int 2 float correspondence dont work in such 2d graphics (asp if combined with typical 2d graphics conventions) and as far as i remember i decided to chose different ones: im niot quite remember but most sane seemed to define 0,0 and 0.0, 0.0 in the centre of top left pixel not in its top left corner and besides used clasical rounding 0.49 is 0 0.51 is 1
(this seems most logicaly fit, hovever there is also a problem of ataining top speed from routines and i dont remember if that granted this top speed

hovever what i describe is real problem

[toc] | [prev] | [next] | [standalone]

#138950

W dniu niedziela, 23 grudnia 2018 13:35:37 UTC+1 użytkownik fir napisał:
> W dniu niedziela, 23 grudnia 2018 12:02:32 UTC+1 użytkownik chanr...@gmail.com napisał:
> > I have been playing with C for about 30 years, but I could never get to really understand casting. I made various weak attempts and gave up; I knew I don't need to be professional in C.
> > 
> > I take my layman approach to casting: it is to represent the value of a certain type in a different data type. 
> > 
> > Some things I tested work and I don't care about its correctness. I always get it correct: (int) 1.23 always give 1. But if we reason things out, if casting tries to represent a float as any integer type, it is not possible. So C may here just return the integral part; but it seems this is not "official".
> > 
> > Casting a signed int to a long unsigned integer is meaningless if the original integer is negative; I think the experts know what result would be returned as per some C standards; but then what is the purpose when it is meaningless.
> > 
> > The only use I think is safe is casting compatible types to another with the larger storage, as int to _int64, or float to double. Casting double to float is OK as we expect a loss of precision.
> 
> casting f->i is specially dangerous idea
> 
> i once noticed it is specially dangerous when doing 2d graphics (and you want to provide functions for both integer and float coordinates)
>  as if you got coordinates shifted towards zero when draw across axes yu got like one pixel stolen (-0.99 to 0.99 which length is roughly 2 become 0 to 0 which lengthh is 0 - and this just makes sprites to be deformed if draved on 0,0 point (you could not drave on it but you stil may logical cout it and its the case)
> 
> so this means that the default int 2 float correspondence dont work in such 2d graphics (asp if combined with typical 2d graphics conventions) and as far as i remember i decided to chose different ones: im niot quite remember but most sane seemed to define 0,0 and 0.0, 0.0 in the centre of top left pixel not in its top left corner and besides used clasical rounding 0.49 is 0 0.51 is 1
> (this seems most logicaly fit, hovever there is also a problem of ataining top speed from routines and i dont remember if that granted this top speed
> 
> hovever what i describe is real problem

yet note that this convention i chosed
whan drawed  line form say 0.27 to 0.54
makes in integers correspondence to draw line form 0 to 0 and this like enforces
of drawing bots starting and ending point in other words it sugests to draw rectangles in a form of 0 to 99, 0 to 99
where 99 is inclusive not 0 to 100 , 0 to 100 when 100 is not-inclusive

i dont remember if this was exactly the reason i began to chose that inclusive convention, but maybe it was just that
(and i now use this inclusive)

[toc] | [prev] | [next] | [standalone]

#138953

W dniu niedziela, 23 grudnia 2018 13:43:05 UTC+1 użytkownik fir napisał:
> W dniu niedziela, 23 grudnia 2018 13:35:37 UTC+1 użytkownik fir napisał:
> > W dniu niedziela, 23 grudnia 2018 12:02:32 UTC+1 użytkownik chanr...@gmail.com napisał:
> > > I have been playing with C for about 30 years, but I could never get to really understand casting. I made various weak attempts and gave up; I knew I don't need to be professional in C.
> > > 
> > > I take my layman approach to casting: it is to represent the value of a certain type in a different data type. 
> > > 
> > > Some things I tested work and I don't care about its correctness. I always get it correct: (int) 1.23 always give 1. But if we reason things out, if casting tries to represent a float as any integer type, it is not possible. So C may here just return the integral part; but it seems this is not "official".
> > > 
> > > Casting a signed int to a long unsigned integer is meaningless if the original integer is negative; I think the experts know what result would be returned as per some C standards; but then what is the purpose when it is meaningless.
> > > 
> > > The only use I think is safe is casting compatible types to another with the larger storage, as int to _int64, or float to double. Casting double to float is OK as we expect a loss of precision.
> > 
> > casting f->i is specially dangerous idea
> > 
> > i once noticed it is specially dangerous when doing 2d graphics (and you want to provide functions for both integer and float coordinates)
> >  as if you got coordinates shifted towards zero when draw across axes yu got like one pixel stolen (-0.99 to 0.99 which length is roughly 2 become 0 to 0 which lengthh is 0 - and this just makes sprites to be deformed if draved on 0,0 point (you could not drave on it but you stil may logical cout it and its the case)
> > 
> > so this means that the default int 2 float correspondence dont work in such 2d graphics (asp if combined with typical 2d graphics conventions) and as far as i remember i decided to chose different ones: im niot quite remember but most sane seemed to define 0,0 and 0.0, 0.0 in the centre of top left pixel not in its top left corner and besides used clasical rounding 0.49 is 0 0.51 is 1
> > (this seems most logicaly fit, hovever there is also a problem of ataining top speed from routines and i dont remember if that granted this top speed
> > 
> > hovever what i describe is real problem
> 
> yet note that this convention i chosed
> whan drawed  line form say 0.27 to 0.54


well i see i got some bug in this description (as i meant here 0.27 in those in-pixel coordinates, yet i see
this inclusive conventions would make
that this line visible length would be jumping when moved in coordinates.. but im like wnted to say something a bit different

btw i dont know what to do with this jumping length, maybe this is standable
in normal wu-graphics (i mean antialiased) this length in reality jumps you just make light values darker when its longer to make sum of light the same as when its shorter

> makes in integers correspondence to draw line form 0 to 0 and this like enforces
> of drawing bots starting and ending point in other words it sugests to draw rectangles in a form of 0 to 99, 0 to 99
> where 99 is inclusive not 0 to 100 , 0 to 100 when 100 is not-inclusive
> 
> i dont remember if this was exactly the reason i began to chose that inclusive convention, but maybe it was just that
> (and i now use this inclusive)

[toc] | [prev] | [next] | [standalone]

#138966

On 12/23/18 06:02, chanrasjid@gmail.com wrote:
> I have been playing with C for about 30 years, but I could never get to really understand casting. I made various weak attempts and gave up; I knew I don't need to be professional in C.
> 
> I take my layman approach to casting: it is to represent the value of a certain type in a different data type.

Not quite. What you're describing is type conversion, not casting.
Casting is a special syntax for commanding a value of one type to be
converted to a value of a different type.

Type conversions can also occur implicitly, without use of a cast. Many
operators apply either the "integer promotions" (6.3.1.1p2) or the
"usual arithmetic conversions" (6.3.1.8) to one or more of their
arguments. If you call a variadic function, the variable arguments are
subject to the "default argument promotions" (6.5.2.2p6); if the
declaration for a function doesn't qualify as a function prototype
(which is NOT recommended), those promotions apply to all arguments of
the function. Finally, when you use an assignment operator, the value of
the right operand is converted to the type of the left operand, but only
if the constraints on those types listed in 6.5.16.1p2 apply. The same
constraints apply to a function return statement (6.8.6.4p3). If a
function is declared using a prototype, those constraints also apply
when converting function arguments to the types of the corresponding
parameters (6.5.2.2p7) (for variadic functions, this only applies to the
declared parameters, not the variable ones).

> Some things I tested work and I don't care about its correctness. I always get it correct: (int) 1.23 always give 1. But if we reason things out, if casting tries to represent a float as any integer type, it is not possible. So C may here just return the integral part; but it seems this is not "official".

What happens in that case is entirely "official". Section 6.3 of the C
standard specifies requirements that apply when a value of one type is
converted to a value of a different types. "When a finite value of real
floating type is converted to an integer type other than _Bool,
the fractional part is discarded" (6.3.1.4p1). Thus, (int)1.23 discards
the .23, giving 1, and (int)(-4.56) discards the .56, giving -4.

> Casting a signed int to a long unsigned integer is meaningless if the original integer is negative; I think the experts know what result would be returned as per some C standards; but then what is the purpose when it is meaningless.

The standard specifies that "... the value is converted by repeatedly
adding or subtracting one more than the maximum value that can be
represented in the new type until the value is in the range of the new
type." (6.3.1.3p2). On systems using 2's complement notation for signed
integers, this has the convenient property of being exactly what happens
naturally when the low-order n bits of an m-bit signed integer are
interpreted as an n-bit unsigned integer. This is sometimes precisely
what people want to have happen.

> The only use I think is safe is casting compatible types to another with the larger storage, as int to _int64, or float to double. Casting double to float is OK as we expect a loss of precision.

You can safely convert an integer value of any type to any signed
integer type that is capable of representing that value, whether the new
type is larger or smaller than the original type. The value is unchanged
by the conversion, only it's representation when stored in an object
changes. You can safely convert any integer type to any unsigned type,
in accordance with the rules given in 6.3.1.3p2.
Yes, you can convert any floating point value to any other floating
point type if that value is in the range of that type. As you say, the
result will have less precision, if the target type is a less precise one.

[toc] | [prev] | [next] | [standalone]

#138985

On Sun, 23 Dec 2018 03:02:18 -0800 (PST), chanrasjid@gmail.com wrote:

>I have been playing with C for about 30 years, but I could never get to really understand casting. I made various weak attempts and gave up; I knew I don't need to be professional in C.
>
>I take my layman approach to casting: it is to represent the value of a certain type in a different data type. 
>
>Some things I tested work and I don't care about its correctness. I always get it correct: (int) 1.23 always give 1. But if we reason things out, if casting tries to represent a float as any integer type, it is not possible. So C may here just return the integral part; but it seems this is not "official".
>
>Casting a signed int to a long unsigned integer is meaningless if the original integer is negative; I think the experts know what result would be returned as per some C standards; but then what is the purpose when it is meaningless.
>
>The only use I think is safe is casting compatible types to another with the larger storage, as int to _int64, or float to double. Casting double to float is OK as we expect a loss of precision.

I cannot think of a case where a cast would be appropriate when
assigning the value in a smaller object to a larger one.

The most frequent misuse of a cast operator in this newgroup is to
silence a compiler diagnostic.  We are constantly urging new
programmers that if they do not thoroughly understand what the
diagnostic is telling them, then silencing it with a cast is almost
always wrong.

That being said, there are cases where a cast is essential.  

One example is in the compare function that is passed to qsort.  The
function takes two constant pointers to void, const void*.  The
function needs to compare the two objects those pointers point to. For
sake of discussion, assume the two objects are elements of an array of
int and the pointers are named p1 and p2.  You cannot code
     if (p1 < p2)
because that would compare the addresses of the objects which is not
what you want.  You cannot code
     if (*p1 < *p2)
because you cannot dereference a void*.  Even if you could, how would
the compiler know you were comparing int values and not double values?
So you need to copy the values of p1 and p2 into int pointers (named
i1 and i2).  You cannot code
     int *i1 = p1;
because that would remove the const attribute.  Similarly you cannot
code
     const int *i1 = p1;
because there is no implicit conversion from const void* to const
int*.  So you are essentially forced to code
     const int *i1 = (const int*)p1;
or the slightly less rigorous
     int *i1 = (int*)p1;
prior to performing the comparison or something equivalent such as
    if (*(int*)p1 < *(int*)p2;

There are also cases where silencing the compiler diagnostic makes
sense.  

For example, a 32-bit int can hold the value 2^30+1 (using ^ to mean
exponentiation) exactly.  A 32 bit float cannot.  When assigning an
int to a float, some compilers will issue a diagnostic about possible
loss of significance.  If you KNOW that this situation will not occur
or KNOW that it will not be problem if it does occur, then using a
cast to eliminate the diagnostic is appropriate.

A similar situation occurs when assigning the value in a larger object
to a smaller object.  For example, strlen returns a size_t which is
usually larger than a short int.  But if you know that all your
strings are less than 16K characters long, there is nothing wrong with
coding
    short x = strlen(y);
If your compiler issues a diagnostic about possible overflow, then
silencing it with a cast would also be appropriate.

The point being that unnecessary or irrelevant diagnostics can cause
you to ignore a significant one that was buried in the weeds.
Eliminating the former can cause the latter to stand out better and
grab your attention.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#139008

On 2018-12-23, Barry Schwarz <schwarzb@dqel.com> wrote:
> That being said, there are cases where a cast is essential.  
>
> One example is in the compare function that is passed to qsort.  The
> function takes two constant pointers to void, const void*.  The
> function needs to compare the two objects those pointers point to. For
> sake of discussion, assume the two objects are elements of an array of
> int and the pointers are named p1 and p2.  You cannot code
>      if (p1 < p2)
> because that would compare the addresses of the objects which is not
> what you want.  You cannot code
>      if (*p1 < *p2)
> because you cannot dereference a void*.  Even if you could, how would
> the compiler know you were comparing int values and not double values?
> So you need to copy the values of p1 and p2 into int pointers (named
> i1 and i2).  You cannot code
>      int *i1 = p1;
> because that would remove the const attribute.  Similarly you cannot
> code
>      const int *i1 = p1;
> because there is no implicit conversion from const void* to const
> int*.  So you are essentially forced to code
>      const int *i1 = (const int*)p1;
> or the slightly less rigorous
>      int *i1 = (int*)p1;
> prior to performing the comparison or something equivalent such as
>     if (*(int*)p1 < *(int*)p2;

It can be done without casts:

  int const * const pi1 = p1, * const pi2 = p2;
  if (*pi1 < *pi2)

[toc] | [prev] | [next] | [standalone]

#139030

I think I have got the final word on casting:
"It is the set of rules to convert from one data type to another."
I think it is what Ben and others have said. It is as simple as that - hope I am right this time.

Just to satisfy myself, I google for "C casting" and read what some articles teach about C casting. Basically, it is what I seem to already know. 

The only thing that troubled me in the past was the  casting of signed int to unsigned :
while (number < 0) {
    number += MAX_UNSIGNED_INT + 1
}
It was explained that the cast here does not change the bit patterns; both values have the same bits, but values will be different as they depend on interpretation of the bits. I was thinking along why would anyone entertain having one of its computed -ve value assigned to an unsigned int. No one starts off with : unsigned int x = -123, y = -23,... rarely. So what is the purpose of casting.

As C allows for assignment of one type to a variable of a different type, a set of casting rules is needed.
So this is C type casting. 

Thanks for the many explanations. 

Merry Christmas!

[toc] | [prev] | [next] | [standalone]

#139033

On Mon, 24 Dec 2018 14:03:25 -0800 (PST), chanrasjid@gmail.com wrote:

>I think I have got the final word on casting:
>"It is the set of rules to convert from one data type to another."

You seem to have missed a major point.

A cast operation occurs only when there is a cast operator. Conversion
frequently occur without any casting.

>I think it is what Ben and others have said. It is as simple as that - hope I am right this time.
>
>Just to satisfy myself, I google for "C casting" and read what some articles teach about C casting. Basically, it is what I seem to already know. 

The Internet is not always the best technical reference.

>The only thing that troubled me in the past was the  casting of signed int to unsigned :
>while (number < 0) {
>    number += MAX_UNSIGNED_INT + 1
>}
>It was explained that the cast here does not change the bit patterns; both values have the same bits, but values will be different as they depend on interpretation of the bits. I was thinking along why would anyone entertain having one of its computed -ve value assigned to an unsigned int. No one starts off with : unsigned int x = -123, y = -23,... rarely. 

Since you have no cast operator, no casting has been performed.

For a machine that uses 2's complement, it is true that the bit
pattern doesn't change.  However for a machine using 1's complement or
signed magnitude, that is not true.

>So what is the purpose of casting.

The purpose of a cast is to allow you to force a conversion between
types for which no implicit conversion exists.  This is used
frequently for pointers.

A secondary use is to silence the diagnostic generated by some
compilers when you know the conversion will not cause the problem the
diagnostic is warning you about (e.g., loss of significance or
overflow).

>As C allows for assignment of one type to a variable of a different type, a set of casting rules is needed.
>So this is C type casting. 

A set of conversion rules is needed.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#139034

On Tuesday, December 25, 2018 at 6:39:42 AM UTC+8, Barry Schwarz wrote:
> On Mon, 24 Dec 2018 14:03:25 -0800 (PST), chanrasjid@gmail.com wrote:
> 
> >I think I have got the final word on casting:
> >"It is the set of rules to convert from one data type to another."
> 
> You seem to have missed a major point.
> 
> A cast operation occurs only when there is a cast operator. Conversion
> frequently occur without any casting.
> 
> >I think it is what Ben and others have said. It is as simple as that - hope I am right this time.
> >
> >Just to satisfy myself, I google for "C casting" and read what some articles teach about C casting. Basically, it is what I seem to already know. 
> 
> The Internet is not always the best technical reference.
> 
> >The only thing that troubled me in the past was the  casting of signed int to unsigned :
> >while (number < 0) {
> >    number += MAX_UNSIGNED_INT + 1
> >}
> >It was explained that the cast here does not change the bit patterns; both values have the same bits, but values will be different as they depend on interpretation of the bits. I was thinking along why would anyone entertain having one of its computed -ve value assigned to an unsigned int. No one starts off with : unsigned int x = -123, y = -23,... rarely. 
> 
> Since you have no cast operator, no casting has been performed.
> 
> For a machine that uses 2's complement, it is true that the bit
> pattern doesn't change.  However for a machine using 1's complement or
> signed magnitude, that is not true.
> 
> >So what is the purpose of casting.
> 
> The purpose of a cast is to allow you to force a conversion between
> types for which no implicit conversion exists.  This is used
> frequently for pointers.
> 
> A secondary use is to silence the diagnostic generated by some
> compilers when you know the conversion will not cause the problem the
> diagnostic is warning you about (e.g., loss of significance or
> overflow).
> 
> >As C allows for assignment of one type to a variable of a different type, a set of casting rules is needed.
> >So this is C type casting. 
> 
> A set of conversion rules is needed.
> 
> -- 
> Remove del for email

Yes, yours is the "philosophical" professional explanation of type casting. Introductory C textbooks does only as found in the internet; I did not read of such deeper explanations from introductory textbooks. 

Thanks.

[toc] | [prev] | [next] | [standalone]

#139039

chanrasjid@gmail.com writes:
> On Tuesday, December 25, 2018 at 6:39:42 AM UTC+8, Barry Schwarz wrote:
>> On Mon, 24 Dec 2018 14:03:25 -0800 (PST), chanrasjid@gmail.com wrote:
[...]
>> >As C allows for assignment of one type to a variable of a different
>> >type, a set of casting rules is needed.  So this is C type casting.
>> 
>> A set of conversion rules is needed.
>
> Yes, yours is the "philosophical" professional explanation of type
> casting. Introductory C textbooks does only as found in the internet;
> I did not read of such deeper explanations from introductory
> textbooks.

There's nothing "philosophical" about it, unless you consider the
distinction between a correct explanation and an incorrect explanation
to be a matter of philosophy.

If your introductory textbooks explain this incorrectly, you need
better textbooks.  Any book that claims that "cast" is synonymous
with "conversion", or that there's such a thing as an "implicit
cast", was written by someone who doesn't know C well enough to be
writing books about it.  Another strong indicator of a bad C book is
the use of "void main()" as if it were correct.  (It's unfortunate
that there are a lot of such books out there.)

Can you cite the textbooks in question?  We'd like to be able to steer
people away from them.  We can also recommend better books for you.

The definitive description of the C language is the ISO C standard.
The latest freely available draft of the current standard is
    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
It's not written for beginners, but I suggest you grab a copy and
see whether it's something you can refer to when you have questions.
(Conversions are discussed in section 6.3, cast operators in 6.5.3.)

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139037

Barry Schwarz <schwarzb@dqel.com> writes:
> On Mon, 24 Dec 2018 14:03:25 -0800 (PST), chanrasjid@gmail.com wrote:
[...]
>>So what is the purpose of casting.
>
> The purpose of a cast is to allow you to force a conversion between
> types for which no implicit conversion exists.  This is used
> frequently for pointers.
>
> A secondary use is to silence the diagnostic generated by some
> compilers when you know the conversion will not cause the problem the
> diagnostic is warning you about (e.g., loss of significance or
> overflow).

It can also be used to control when a conversion is performed, and to
what type, even for a conversion that could have been done implicitly.
This is most common in numeric expressions.

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139049

On Tuesday, December 25, 2018 at 7:23:36 AM UTC+8, Keith Thompson wrote:
> Barry Schwarz <schwarzb@dqel.com> writes:
> > On Mon, 24 Dec 2018 14:03:25 -0800 (PST), chanrasjid@gmail.com wrote:
> [...]
> >>So what is the purpose of casting.
> >
> > The purpose of a cast is to allow you to force a conversion between
> > types for which no implicit conversion exists.  This is used
> > frequently for pointers.
> >
> > A secondary use is to silence the diagnostic generated by some
> > compilers when you know the conversion will not cause the problem the
> > diagnostic is warning you about (e.g., loss of significance or
> > overflow).
> 
> It can also be used to control when a conversion is performed, and to
> what type, even for a conversion that could have been done implicitly.
> This is most common in numeric expressions.
> 
> -- 
> Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
> Will write code for food.
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

I don't have any C textbook in mine; I read those years back and they are are introductory type. I was never preparing myself for a career in programming, but only to use it to create some running program. I don have a copy of the official C standards; they are very interesting for people who really want to be serious in fully understanding C. I don't yet have the necessary computer basics for fully understanding such official document.

[toc] | [prev] | [next] | [standalone]

#139035

chanrasjid@gmail.com writes:
> I think I have got the final word on casting:
> "It is the set of rules to convert from one data type to another."
> I think it is what Ben and others have said. It is as simple as that -
> hope I am right this time.

No, that's not what "casting" means.

The term "cast" is often *incorrectly* used to refer to type conversion
in general.

"Conversion" means taking a value of some type and obtaining from it a
value of a (probably different) type.  A conversion can be an implicit
conversion (for example, in a simple assignment) or an explicit
conversion.  An explicit conversion is specified by a *cast*, an
expression consisting of a type name in parentheses followed by an
expression.  (The parenthesized type name is a cast operator).

The word "cast" refers *only* to that particular kind of expression.

A cast specifies exactly the same operation that would have been
performed if the same conversion had been done implicitly (*if* it's a
conversion that can be done implicitly; most pointer conversions require
casts).

(Strictly speaking, a unary-expression with no cast operator is also a
cast-expression, but that's only for syntactic convenience, consistent
with the way other kinds of expressions are defined in the grammar.)

> Just to satisfy myself, I google for "C casting" and read what some
> articles teach about C casting. Basically, it is what I seem to
> already know.

I suspect a lot of those articles repeat the same misconception, that an
implicit conversion is a "cast".  It isn't.

> The only thing that troubled me in the past was the casting of signed
> int to unsigned :
> while (number < 0) {
>     number += MAX_UNSIGNED_INT + 1
> }

That's a conversion, not a cast (and the macro is UINT_MAX).

> It was explained that the cast here does not change the bit patterns;
> both values have the same bits, but values will be different as they
> depend on interpretation of the bits. I was thinking along why would
> anyone entertain having one of its computed -ve value assigned to an
> unsigned int. No one starts off with : unsigned int x = -123, y =
> -23,... rarely. So what is the purpose of casting.

A conversion from a signed integer type to an unsigned integer type of
the same size *typically* doesn't change the bit pattern, but that's not
how it's defined (though the way it's defined is certainly motivated by
that).  On a system that uses ones'-complement or sign-and-magnitude,
rather than the vastly more common two's-complement, the conversion of a
negative integer to an unsigned type does change the bit pattern.

> As C allows for assignment of one type to a variable of a different
> type, a set of casting rules is needed.
> So this is C type casting. 

No, this is C conversion.

Converting any integer to an unsigned type is well defined -- mostly
because the result can be specified in a way that's easy to implement.
The standard's description of "repeatedly adding or subtracting one more
than the maximum value that can be represented in the new type until the
value is in the range of the new type" is not how it's actually
implemented; it's a way of expression, while referring only to *values*,
something that's actuallly done by simple a manipulation of the
*representation*.  The bits of the source value are simply copied, or
the high-order bits are discarded, or zero bits are added at the top,
depending on the relative sizes (*if* the system uses two's-complement).

Converting any integer to a signed type is defined more loosely.  If the
converted value is outside the range of the target type, the result is
implementation-defined.

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139047

On Tuesday, December 25, 2018 at 6:52:41 AM UTC+8, Keith Thompson wrote:
> chanrasjid@gmail.com writes:
> > I think I have got the final word on casting:
> > "It is the set of rules to convert from one data type to another."
> > I think it is what Ben and others have said. It is as simple as that -
> > hope I am right this time.
> 
> No, that's not what "casting" means.
> 
> The term "cast" is often *incorrectly* used to refer to type conversion
> in general.
> 
> "Conversion" means taking a value of some type and obtaining from it a
> value of a (probably different) type.  A conversion can be an implicit
> conversion (for example, in a simple assignment) or an explicit
> conversion.  An explicit conversion is specified by a *cast*, an
> expression consisting of a type name in parentheses followed by an
> expression.  (The parenthesized type name is a cast operator).
> 
> The word "cast" refers *only* to that particular kind of expression.
> 
> A cast specifies exactly the same operation that would have been
> performed if the same conversion had been done implicitly (*if* it's a
> conversion that can be done implicitly; most pointer conversions require
> casts).
> 
> (Strictly speaking, a unary-expression with no cast operator is also a
> cast-expression, but that's only for syntactic convenience, consistent
> with the way other kinds of expressions are defined in the grammar.)
> 
> > Just to satisfy myself, I google for "C casting" and read what some
> > articles teach about C casting. Basically, it is what I seem to
> > already know.
> 
> I suspect a lot of those articles repeat the same misconception, that an
> implicit conversion is a "cast".  It isn't.
> 
> > The only thing that troubled me in the past was the casting of signed
> > int to unsigned :
> > while (number < 0) {
> >     number += MAX_UNSIGNED_INT + 1
> > }
> 
> That's a conversion, not a cast (and the macro is UINT_MAX).
> 
> > It was explained that the cast here does not change the bit patterns;
> > both values have the same bits, but values will be different as they
> > depend on interpretation of the bits. I was thinking along why would
> > anyone entertain having one of its computed -ve value assigned to an
> > unsigned int. No one starts off with : unsigned int x = -123, y =
> > -23,... rarely. So what is the purpose of casting.
> 
> A conversion from a signed integer type to an unsigned integer type of
> the same size *typically* doesn't change the bit pattern, but that's not
> how it's defined (though the way it's defined is certainly motivated by
> that).  On a system that uses ones'-complement or sign-and-magnitude,
> rather than the vastly more common two's-complement, the conversion of a
> negative integer to an unsigned type does change the bit pattern.
> 
> > As C allows for assignment of one type to a variable of a different
> > type, a set of casting rules is needed.
> > So this is C type casting. 
> 
> No, this is C conversion.
> 
> Converting any integer to an unsigned type is well defined -- mostly
> because the result can be specified in a way that's easy to implement.
> The standard's description of "repeatedly adding or subtracting one more
> than the maximum value that can be represented in the new type until the
> value is in the range of the new type" is not how it's actually
> implemented; it's a way of expression, while referring only to *values*,
> something that's actuallly done by simple a manipulation of the
> *representation*.  The bits of the source value are simply copied, or
> the high-order bits are discarded, or zero bits are added at the top,
> depending on the relative sizes (*if* the system uses two's-complement).
> 
> Converting any integer to a signed type is defined more loosely.  If the
> converted value is outside the range of the target type, the result is
> implementation-defined.
> 
> -- 
> Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
> Will write code for food.
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

I understand you clearly. I think introductory textbooks generally don't give such details nor make us aware of some likely misconceptions. 

Thanks.   

[toc] | [prev] | [next] | [standalone]

#139036

On 12/24/18 17:03, chanrasjid@gmail.com wrote:
> I think I have got the final word on casting:
> "It is the set of rules to convert from one data type to another."

Nope - casting is use of a particular syntax to explicitly command the
conversion of data from one type to another. Conversions can also occur
without being commanded.

> I think it is what Ben and others have said. It is as simple as that - hope I am right this time.
> 
> Just to satisfy myself, I google for "C casting" and read what some articles teach about C casting. Basically, it is what I seem to already know. 
> 
> The only thing that troubled me in the past was the  casting of signed int to unsigned :
> while (number < 0) {
>     number += MAX_UNSIGNED_INT + 1
> }
> It was explained that the cast here does not change the bit patterns; both values have the same bits, but values will be different as they depend on interpretation of the bits.

That's true when working with signed data stored using 2's complement
format, which is overwhelmingly the most common format. This is not a
coincidence - that mandated behavior was deliberately chosen to match
the actual behavior of most real-world implementations. However, what
you said is NOT true when using 1's complement or sign-magnitude
formats, which are the other two formats permitted by the C standard.


> I was thinking along why would anyone entertain having one of its computed -ve value assigned to an unsigned int. No one starts off with : unsigned int x = -123, y = -23,... rarely. So what is the purpose of casting.

Since it's a conversion that can occur implicitly without use of a cast,
there is, indeed, little point in casting.
Overwhelmingly the most common reason I've seen for such a conversion is
to convert -1 to an unsigned type, which is guaranteed to result in the
largest representable value of that type. Macros from <limits.h> can
also be used for the same purpose - but are less convenient in cases
where a typedef is used.
I'm sure there are other good reasons for making use of this feature,
but offhand I can't remember any, so I hope other people will address
that question.

> As C allows for assignment of one type to a variable of a different type, a set of casting rules is needed.

C does not allow assignment of a value of one type to a variable of a
different type. What it does do is mandate (under certain circumstances)
conversion of the value from the source type to the destination type,
with such conversion occurring, at lease nominally, before the
assignment itself. It's a subtle distinction, and I'm not sure the
distinction matters, but that is how the standard describes the required
behavior.
Since these conversions occur implicitly, casting rules are not needed -
but type conversion rules are.

> So this is C type casting. 

"type casting" is something that happens to actors. In C, there is such
a thing as a type conversion, and a cast can be used to command such a
conversion to be performed, but "type casting" is not a term that can be
correctly used to describe any part of that process.

[toc] | [prev] | [next] | [standalone]

#139051

On Monday, December 24, 2018 at 4:03:39 PM UTC-6, chanr...@gmail.com wrote:
> As C allows for assignment of one type to a variable of a different type, a set of casting rules is needed.
> So this is C type casting. 
> 
> Thanks for the many explanations. 

Nit: it's just simply "casting". "Type-casting" is when you see the same actor
always playing variations of the same character in different films or tv shows.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web