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

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

how cast works?

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

Contents

  how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-07 08:28 -0300
    Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-07 08:33 -0300
      Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-07 13:13 -0700
      Re: how cast works? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-11 17:43 -0700
        Re: how cast works? Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-12 11:51 +0100
          Challenge/exercise problem - signum() function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 08:17 -0700
            Re: Challenge/exercise problem - signum() function Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-08-12 16:07 +0000
              Re: Challenge/exercise problem - signum() function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 09:57 -0700
    Re: how cast works? Dan Purgert <dan@djph.net> - 2024-08-07 20:00 +0000
      Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-07 13:26 -0700
      Re: how cast works? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-07 23:00 +0000
      Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-08 08:14 -0300
        Re: how cast works? Bart <bc@freeuk.com> - 2024-08-08 14:23 +0100
          Re: how cast works? Michael S <already5chosen@yahoo.com> - 2024-08-08 19:32 +0300
            Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-08 14:11 -0300
            Re: how cast works? Bart <bc@freeuk.com> - 2024-08-08 18:29 +0100
              Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-08 14:50 -0300
                Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-08 14:57 -0300
                Re: how cast works? Bart <bc@freeuk.com> - 2024-08-08 19:01 +0100
                  Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-08 15:13 -0300
                Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-08 12:29 -0700
              Re: how cast works? David Brown <david.brown@hesbynett.no> - 2024-08-08 19:58 +0200
                Re: how cast works? Bart <bc@freeuk.com> - 2024-08-08 20:09 +0100
                  Re: how cast works? David Brown <david.brown@hesbynett.no> - 2024-08-09 00:32 +0200
                    Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-08 16:14 -0700
                      Re: how cast works? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-09 02:47 +0000
                        Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-08 22:55 -0700
                        Re: how cast works? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-09 02:08 -0400
                      Re: how cast works? David Brown <david.brown@hesbynett.no> - 2024-08-09 18:16 +0200
                        Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-09 12:18 -0700
                          Re: how cast works? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-11 17:07 -0700
                            Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-11 20:14 -0700
                              Re: how cast works? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-03 06:02 -0700
                    Re: how cast works? Bart <bc@freeuk.com> - 2024-08-09 01:56 +0100
                      Re: how cast works? David Brown <david.brown@hesbynett.no> - 2024-08-09 19:08 +0200
                        Re: how cast works? Bart <bc@freeuk.com> - 2024-08-10 11:03 +0100
                  Re: how cast works? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-09 02:45 +0000
        Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-08 12:42 -0700
          Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-08 17:34 -0300
            Re: how cast works? Bart <bc@freeuk.com> - 2024-08-08 22:41 +0100
              Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-08 16:17 -0700
                Re: how cast works? Bart <bc@freeuk.com> - 2024-08-09 11:04 +0100
                  Re: how cast works? David Brown <david.brown@hesbynett.no> - 2024-08-09 19:12 +0200
                    Re: how cast works? Bart <bc@freeuk.com> - 2024-08-12 15:36 +0100
                  Re: how cast works? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-09 13:57 -0400
                    Re: how cast works? Bart <bc@freeuk.com> - 2024-08-09 21:59 +0100
                      Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-09 14:47 -0700
                        Re: how cast works? Bart <bc@freeuk.com> - 2024-08-10 00:32 +0100
                          Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-09 17:12 -0700
                      Re: how cast works? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-09 18:29 -0400
                        Re: how cast works? David Brown <david.brown@hesbynett.no> - 2024-08-13 11:18 +0200
                        Re: how cast works? Bart <bc@freeuk.com> - 2024-08-13 11:34 +0100
                        Re: how cast works? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-13 07:51 -0400
                          Re: how cast works? Bart <bc@freeuk.com> - 2024-08-13 14:01 +0100
                            Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-13 12:46 -0700
                              Re: how cast works? Bart <bc@freeuk.com> - 2024-08-13 21:51 +0100
                                Re: how cast works? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-13 16:46 -0700
                                  Re: how cast works? Bart <bc@freeuk.com> - 2024-08-14 00:56 +0100
                                    Re: how cast works? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-18 03:37 -0700
                    Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-09 14:29 -0700
                      Re: how cast works? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-09 18:35 -0400
                    Re: how cast works? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-09 21:30 +0000
                      Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-09 14:57 -0700
                        Re: how cast works? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-09 23:14 +0000
                          Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-09 16:58 -0700
                            Re: how cast works? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-10 00:06 +0000
                              Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-09 17:27 -0700
                              Re: how cast works? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-09 20:31 -0400
                            Re: how cast works? Bart <bc@freeuk.com> - 2024-08-10 01:11 +0100
                              Re: how cast works? David Brown <david.brown@hesbynett.no> - 2024-08-13 11:23 +0200
                          Re: how cast works? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-11 17:32 -0700
                      Re: how cast works? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-09 18:35 -0400
                      Re: how cast works? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-11 17:27 -0700
                  Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-09 12:23 -0700
                    Re: how cast works? Bart <bc@freeuk.com> - 2024-08-09 21:31 +0100
                      Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-09 13:49 -0700
                        Re: how cast works? Bart <bc@freeuk.com> - 2024-08-09 22:01 +0100
                  Re: how cast works? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 00:33 -0700
                    Re: how cast works? Bart <bc@freeuk.com> - 2024-08-12 12:21 +0100
                Re: how cast works? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-11 17:46 -0700
                  Re: how cast works? Bart <bc@freeuk.com> - 2024-08-12 02:00 +0100
                    Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-11 20:23 -0700
                    Re: how cast works? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-11 20:37 -0700
                      Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-11 21:33 -0700
                        Re: how cast works? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-12 16:57 +0100
                          Re: how cast works? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 10:04 -0700
                            Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-12 13:35 -0700
              Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-09 07:57 -0300
                Re: how cast works? Bart <bc@freeuk.com> - 2024-08-09 16:25 +0100
                  Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-09 12:06 -0700
                Re: how cast works? David Brown <david.brown@hesbynett.no> - 2024-08-09 19:20 +0200
                  Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-09 15:54 -0300
                    Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-09 16:05 -0300
                      Re: how cast works? David Brown <david.brown@hesbynett.no> - 2024-08-09 21:43 +0200
                      Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-09 13:28 -0700
                    Re: how cast works? David Brown <david.brown@hesbynett.no> - 2024-08-09 22:01 +0200
                      Re: how cast works? Bart <bc@freeuk.com> - 2024-08-10 11:17 +0100
                        Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-10 10:15 -0300
                          Re: how cast works? Bart <bc@freeuk.com> - 2024-08-10 17:14 +0100
                            Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-10 20:01 -0300
                              Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-10 17:10 -0700
                                Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-11 09:23 -0300
                                  Re: how cast works? Bart <bc@freeuk.com> - 2024-08-11 13:30 +0100
                                    Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-11 14:16 -0300
                                  Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-11 13:38 -0700
                                    Re: how cast works? Bart <bc@freeuk.com> - 2024-08-12 12:24 +0100
                    Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-09 13:26 -0700
                      Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-09 18:01 -0300
                        Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-09 14:53 -0700
                Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-09 12:03 -0700
                  Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-09 16:22 -0300
            Re: how cast works? David Brown <david.brown@hesbynett.no> - 2024-08-09 00:36 +0200
      Re: how cast works? Dan Purgert <dan@djph.net> - 2024-08-08 14:08 +0000
      Re: how cast works? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-09 02:42 +0000
    Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-07 13:08 -0700
      Re: how cast works? Thiago Adams <thiago.adams@gmail.com> - 2024-08-08 08:35 -0300
        Re: how cast works? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-08 12:39 -0700
        Re: how cast works? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-08 18:40 -0400
          Re: how cast works? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-11 17:15 -0700
      Is there an audio book version (Was: how cast works?) gazelle@shell.xmission.com (Kenny McCormack) - 2024-08-08 16:19 +0000
    Re: how cast works? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-07 23:03 +0000

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

#387415

Bart <bc@freeuk.com> writes:
[...]
> Take:
>
>     int a; double x;
>
>     x = (double)a;
>
> The cast is implicit here but I've written it out to make it clear.

[...]

The *conversion* could be done implicitly, but you've used a cast (i.e.,
an explicit conversion) to make it clear.

There is no such thing as an "implicit cast" in C.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#387422

On 09/08/2024 00:17, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> Take:
>>
>>      int a; double x;
>>
>>      x = (double)a;
>>
>> The cast is implicit here but I've written it out to make it clear.
> 
> [...]
> 
> The *conversion* could be done implicitly, but you've used a cast (i.e.,
> an explicit conversion) to make it clear.
> 
> There is no such thing as an "implicit cast" in C.
> 

Suppose I write this code:

     x = a;                  // implicit 'conversion'
     x = (double)a;          // explicit 'conversion'


My compiler produces these two bits of AST for the RHS of both expressions:

1 00009 r64---|---2 convert: sfloat_c i32 => r64
1 00009 i32---|---|---1 name: t.main.a.1

1 00010 r64---|---2 convert: sfloat_c i32 => r64
1 00010 i32---|---|---1 name: t.main.a.1

So whatever you call that `(double)` part of the second line, which is 
written explicitly, exactly the same thing is done internally (ie 
'implicitly') to the first line. (The 09/10 are line numbers.)

Since C likes to use the term 'cast' for such conversions, I don't see a 
problem with talking about implicit and explicit versions.

It just seems to irk the pedantics here.

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

#387427

On 09/08/2024 12:04, Bart wrote:
> On 09/08/2024 00:17, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> Take:
>>>
>>>      int a; double x;
>>>
>>>      x = (double)a;
>>>
>>> The cast is implicit here but I've written it out to make it clear.
>>
>> [...]
>>
>> The *conversion* could be done implicitly, but you've used a cast (i.e.,
>> an explicit conversion) to make it clear.
>>
>> There is no such thing as an "implicit cast" in C.
>>
> 
> Suppose I write this code:
> 
>      x = a;                  // implicit 'conversion'
>      x = (double)a;          // explicit 'conversion'
> 
> 
> My compiler produces these two bits of AST for the RHS of both expressions:
> 
> 1 00009 r64---|---2 convert: sfloat_c i32 => r64
> 1 00009 i32---|---|---1 name: t.main.a.1
> 
> 1 00010 r64---|---2 convert: sfloat_c i32 => r64
> 1 00010 i32---|---|---1 name: t.main.a.1
> 
> So whatever you call that `(double)` part of the second line, which is 
> written explicitly, exactly the same thing is done internally (ie 
> 'implicitly') to the first line. (The 09/10 are line numbers.)
> 

You've written it yourself.  Both are conversions - one is implicit, the 
other is explicit.

> Since C likes to use the term 'cast' for such conversions, I don't see a 
> problem with talking about implicit and explicit versions.
>

C does not "like" to use the term "cast" for anything other than cast 
operations, as defined by the C standards.  Implicit conversions are not 
casts.

/You/ might like to call implicit conversions "casts", but you'd be 
wrong to do so.

> It just seems to irk the pedantics here.

You mean, people who know what they are talking about rather than those 
that make up stuff as they go along?

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

#387514

On 09/08/2024 18:12, David Brown wrote:
> On 09/08/2024 12:04, Bart wrote:
>> On 09/08/2024 00:17, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> Take:
>>>>
>>>>      int a; double x;
>>>>
>>>>      x = (double)a;
>>>>
>>>> The cast is implicit here but I've written it out to make it clear.
>>>
>>> [...]
>>>
>>> The *conversion* could be done implicitly, but you've used a cast (i.e.,
>>> an explicit conversion) to make it clear.
>>>
>>> There is no such thing as an "implicit cast" in C.
>>>
>>
>> Suppose I write this code:
>>
>>      x = a;                  // implicit 'conversion'
>>      x = (double)a;          // explicit 'conversion'
>>
>>
>> My compiler produces these two bits of AST for the RHS of both 
>> expressions:
>>
>> 1 00009 r64---|---2 convert: sfloat_c i32 => r64
>> 1 00009 i32---|---|---1 name: t.main.a.1
>>
>> 1 00010 r64---|---2 convert: sfloat_c i32 => r64
>> 1 00010 i32---|---|---1 name: t.main.a.1
>>
>> So whatever you call that `(double)` part of the second line, which is 
>> written explicitly, exactly the same thing is done internally (ie 
>> 'implicitly') to the first line. (The 09/10 are line numbers.)
>>
> 
> You've written it yourself.  Both are conversions - one is implicit, the 
> other is explicit.

Something you might observe here is that both lines are represented, 
despite the fact that the x's value is immediately overwritten after the 
first assignment, and its value is not used even after the second.

What follows was actually not shown, but it doesn't matter.

You presumably would use optimisation flags every time, so risking 
unpredictable chunks of the output disappearing depending on how early 
they cut in.

In fact, if I do this (a, x have int, double types):

     a;
     x;

my compiler produces some output, namely, evaluating and leaving results 
into a register:

     mov  eax,  [rbp+`main.a]
     movq XMM4, [rbp+`main.x]

gcc however produces no output even with -O0.

(I'd wanted to see what gcc did with an 'open' expression, one which 
would not be coerced into a particularly type, but those are rare in C 
code.)


> 
>> Since C likes to use the term 'cast' for such conversions, I don't see 
>> a problem with talking about implicit and explicit versions.
>>
> 
> C does not "like" to use the term "cast" for anything other than cast 
> operations, as defined by the C standards.  Implicit conversions are not 
> casts.
> 
> /You/ might like to call implicit conversions "casts", but you'd be 
> wrong to do so.
> 
>> It just seems to irk the pedantics here.
> 
> You mean, people who know what they are talking about rather than those 
> that make up stuff as they go along?


You yourself said that my own language is just C with a different 
syntax. Since I've worked on various implementations of it most of my 
life, is it possible that I might know what I'm talking about as well?

What I haven't done with my language is to create a reference document 
with its own precisely defined nomenclature, whose existence then 
requires that any casual discussion about ANY aspects of it to use 
exactly those terms and no others.

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

#387429

On 09/08/2024 12:04, Bart wrote:
> On 09/08/2024 00:17, Keith Thompson wrote:
...
>> There is no such thing as an "implicit cast" in C.
>>
> 
> Suppose I write this code:
> 
>      x = a;                  // implicit 'conversion'
>      x = (double)a;          // explicit 'conversion'
> 
> 
> My compiler produces these two bits of AST for the RHS of both expressions:
> 
> 1 00009 r64---|---2 convert: sfloat_c i32 => r64
> 1 00009 i32---|---|---1 name: t.main.a.1
> 
> 1 00010 r64---|---2 convert: sfloat_c i32 => r64
> 1 00010 i32---|---|---1 name: t.main.a.1

Of course - an implicit conversion has exactly the same effect as a
explicit conversion, if the source and destination types are the same.
That doesn't make it correct to use the term "cast" to describe anything
other than an explicit conversion.
> 
> So whatever you call that `(double)` part of the second line, which is 
> written explicitly, exactly the same thing is done internally (ie 
> 'implicitly') to the first line. (The 09/10 are line numbers.)
> 
> Since C likes to use the term 'cast' for such conversions, ...

No, C only uses the term "cast" to describe the following:

"6.5.4	Cast operators
1 cast-expression:
unary-expression
( type-name ) cast-expression" (6.5.4p1)

A cast is a piece of syntax that is used to explicitly request that a
conversion be performed. Conversions that are explicitly requested in C
code are referred to as casts only by people who don't understand what
they're saying - the standard never refers to them as such.

> ... I don't see a 
> problem with talking about implicit and explicit versions.

There's nothing wrong with talking about implicit conversions versus
explicit conversions. Explicit conversion are also called casts.

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

#387448

On 09/08/2024 18:57, James Kuyper wrote:
> On 09/08/2024 12:04, Bart wrote:

> 
> A cast is a piece of syntax that is used to explicitly request that a
> conversion be performed. Conversions that are explicitly requested in C
> code are referred to as casts only by people who don't understand what
> they're saying - the standard never refers to them as such.

Are you sure? What else would they be known as?

> 
>> ... I don't see a
>> problem with talking about implicit and explicit versions.
> 
> There's nothing wrong with talking about implicit conversions versus
> explicit conversions.

Of course! Because those terms happen to be used in a couple of places 
in the standard. Usage of any terms not appearing in the standard is 
apparently outlawed in this newsgroup.

> Explicit conversion are also called casts.


"6.5.4p3

Conversions that involve pointers, other than where permitted by the 
constraints of 6.5.16.1, shall be specified by means of an explicit cast."

Here it uses the term 'explicit cast'. Why is that; isn't the term 
'cast' unambiguous without needing to say 'explicit'?

Also, what is exactly is the difference between 'explicit conversion' 
and 'explicit cast'?

Why can't there also be a similar correlation between 'implicit 
conversion' and 'implicit cast'? The only reason I can see is that out 
of these four terms, only 3 of them happen to appear in the standard.

I don't see that as a compelling reason why that term should be 
considered absolutely wrong; 'implicit cast' just never came up.

It's not as though the standard provides an official glossary, but even 
if it did, surely people ought to be allowed to use alternate terms for 
an informal discussion? This is a not a committee meeting.

I remember people here getting castigated for using the term 'type 
cast'. And yet, in H.2.4p1:

"The LIA−1 type conversions are the following type casts:"


Look also at H.2.4p4 (also p5):

"C’s conversions (casts) from floating-point to floating-point can meet 
LIA−1 requirements if an implementation uses round-to-nearest (IEC 60559 
default)."

Here it clearly indicates that 'conversions' (presumably both implicit 
and explicit) are also known as 'casts'.

This seems to imply (no pun) that 'implicit casts' are a thing; the 
opportunity to use that term just never came up.

I don't wish to be rude to you or KT but .....

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

#387453

Bart <bc@freeuk.com> writes:
> On 09/08/2024 18:57, James Kuyper wrote:
>> On 09/08/2024 12:04, Bart wrote:
>
>> A cast is a piece of syntax that is used to explicitly request that
>> a
>> conversion be performed. Conversions that are explicitly requested in C
>> code are referred to as casts only by people who don't understand what
>> they're saying - the standard never refers to them as such.
>
> Are you sure? What else would they be known as?

I believe James made a small error here, either omitting a "not" or
accidentally writing "explicitly" rather than "implicitly".

With that correction, I presume what James wrote is clear enough.
I ask you not to pretend that you still don't understand it.

[...]
> Here it uses the term 'explicit cast'. Why is that; isn't the term
> 'cast' unambiguous without needing to say 'explicit'?

It's redundant.

> Also, what is exactly is the difference between 'explicit conversion'
> and 'explicit cast'?

The both mean the same thing in C, but "explicit cast" is redundant.

> Why can't there also be a similar correlation between 'implicit
> conversion' and 'implicit cast'? The only reason I can see is that out
> of these four terms, only 3 of them happen to appear in the standard.

Because a cast is an explicit operator.

> I don't see that as a compelling reason why that term should be
> considered absolutely wrong; 'implicit cast' just never came up.
>
> It's not as though the standard provides an official glossary,

In fact it does.  Some terms are defined in section 3, and others are
defined elsewhere in the standard (definitions are denoted by italics).
I don't see a definition for the term "cast", but it's clearly described
in N3220 6.5.4 "Cast operators".

Array indexing is defined in terms of pointer arithmetic.  The
evaluation of `a[i]` involves an implicit addition operation.  It does
not involve an implicit "+" symbol.

> even if it did, surely people ought to be allowed to use alternate
> terms for an informal discussion? This is a not a committee meeting.

You're allowed to write whatever nonsense you like, and the rest of us
are allowed to tell you that you're wrong.

Explain why using the word "cast" incorrectly is better than using it
correctly.  Explain why you can't just refer to explicit and implicit
conversions.  Do you have a motivation other than being annoying?

> I remember people here getting castigated for using the term 'type
> cast'. And yet, in H.2.4p1:
>
> "The LIA−1 type conversions are the following type casts:"

That wording is no longer there in more recent editions.  Annex H refers
to LIA-1 (Language Independent Arithmetic), ISO/IEC 10967–1; perhaps
that standard use the term "type casts".  (I'm not going to pay CHF 216
to find out.)

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#387460

On 09/08/2024 22:47, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 09/08/2024 18:57, James Kuyper wrote:
>>> On 09/08/2024 12:04, Bart wrote:
>>
>>> A cast is a piece of syntax that is used to explicitly request that
>>> a
>>> conversion be performed. Conversions that are explicitly requested in C
>>> code are referred to as casts only by people who don't understand what
>>> they're saying - the standard never refers to them as such.
>>
>> Are you sure? What else would they be known as?
> 
> I believe James made a small error here, either omitting a "not" or
> accidentally writing "explicitly" rather than "implicitly".
> 
> With that correction, I presume what James wrote is clear enough.
> I ask you not to pretend that you still don't understand it.

I guessed it was some sort of mistake. That's why I politely asked if he 
was sure.

 > I ask you not to pretend that you still don't understand it.

I might also ask you not to pretend you don't know what is meant by 
'implicit cast'. Or worse, pretending that other people might be confused.

I'm sure most of those won't have gone anywhere near the standard, so 
they won't be aware that in the 700 pages of N1570.PDF, 'explicit cast' 
occurs all of once, while 'implicit cast' occurs one time less often, 
which appears to be the sole reason for have a go at anyone who commits 
the sin of using that expression.


> [...]
>> Here it uses the term 'explicit cast'. Why is that; isn't the term
>> 'cast' unambiguous without needing to say 'explicit'?
> 
> It's redundant.

OK. Does that mean we're allowed to use redundant terms too?

>> Also, what is exactly is the difference between 'explicit conversion'
>> and 'explicit cast'?
> 
> The both mean the same thing in C, but "explicit cast" is redundant.
> 
>> Why can't there also be a similar correlation between 'implicit
>> conversion' and 'implicit cast'? The only reason I can see is that out
>> of these four terms, only 3 of them happen to appear in the standard.
> 
> Because a cast is an explicit operator.

It's something that is done in the code to alter the evaluation of some 
expression. An 'explicit cast', which has to be requested in the source 
code, necessarily has some syntax associated with it.

An 'implicit cast' (by which I mean, for your benefit as it puzzles 
nobody else, implicit type conversion), obviously /doesn't/ have any 
relevant syntax! If it had, then it would be explicit...

>> I don't see that as a compelling reason why that term should be
>> considered absolutely wrong; 'implicit cast' just never came up.
>>
>> It's not as though the standard provides an official glossary,
> 
> In fact it does.  Some terms are defined in section 3, and others are
> defined elsewhere in the standard (definitions are denoted by italics).
> I don't see a definition for the term "cast", but it's clearly described
> in N3220 6.5.4 "Cast operators".
> 
> Array indexing is defined in terms of pointer arithmetic.  The
> evaluation of `a[i]` involves an implicit addition operation.  It does
> not involve an implicit "+" symbol.

You've snipped my quote from H.2.4p5 where it says:

   ... conversions (casts) ...

Here they are also 'mixing up' operations and syntax.

Here's the signature of a function from my C compiler which deals with 
conversions:

   func docast(unit p, int t, hard=1)unit =

(A 'unit' is an AST mode; 't' is a type code.) 'hard' is 1 for an 
explicit conversion, and 0 for an implicit one.

(Explicit or 'hard' casts enable some conversions that would be 
otherwise be invalid. And in that last sentence, I used both 'cast' and 
'conversion' just to avoid using the same term in quick succession. I'm 
sure many of the word choices in the standard are for similar reasons.)

> You're allowed to write whatever nonsense you like, and the rest of us
> are allowed to tell you that you're wrong.

And some of us are allowed to think or say that you're being hopelessly 
pedantic.

> 
> Explain why using the word "cast" incorrectly is better than using it
> correctly.  Explain why you can't just refer to explicit and implicit
> conversions.  Do you have a motivation other than being annoying?

'Cast' is shorter, and more directly is associated with conversions to 
do with types.

In my compiler for example, '*conv*' is used in many different contexts 
(eg. case conversion). '*cast*' is only used in two functions, both to 
do with C type conversions.

But I also use both terms just to mix it up.

>> I remember people here getting castigated for using the term 'type
>> cast'. And yet, in H.2.4p1:
>>
>> "The LIA−1 type conversions are the following type casts:"
> 
> That wording is no longer there in more recent editions.  Annex H refers
> to LIA-1 (Language Independent Arithmetic), ISO/IEC 10967–1; perhaps
> that standard use the term "type casts".

My point is that even the professionals who write such documents get it 
'wrong', according to you.

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

#387464

Bart <bc@freeuk.com> writes:
> On 09/08/2024 22:47, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
[...]
> I might also ask you not to pretend you don't know what is meant by
> 'implicit cast'. Or worse, pretending that other people might be
> confused.

Of course I understand exactly what you mean by "implicit cast".  You
mean "implicit conversion".  A phrase can be both clear and incorrect.
If you used the phrase "male cow" I would assume you mean "bull" and/or
"steer".

> I'm sure most of those won't have gone anywhere near the standard, so
> they won't be aware that in the 700 pages of N1570.PDF, 'explicit
> cast' occurs all of once, while 'implicit cast' occurs one time less
> often, which appears to be the sole reason for have a go at anyone who
> commits the sin of using that expression.

Nobody has accused you of any "sin".  Don't exaggerate.

I have pointed out that you are misusing a word that has a clear
definition, and that using the correct term "implicit conversion" would
be at least as clear and would cost you nothing.  (Compare the extra 6
letters to the volume of text you've emitted arguing about it.)

>> [...]
>>> Here it uses the term 'explicit cast'. Why is that; isn't the term
>>> 'cast' unambiguous without needing to say 'explicit'?
>> It's redundant.
>
> OK. Does that mean we're allowed to use redundant terms too?

Nobody said you aren't.

[...]

> You've snipped my quote from H.2.4p5 where it says:
>
>   ... conversions (casts) ...

That wording does not appear in more recent drafts.

[...]

>> Explain why using the word "cast" incorrectly is better than using it
>> correctly.  Explain why you can't just refer to explicit and implicit
>> conversions.  Do you have a motivation other than being annoying?
>
> 'Cast' is shorter, and more directly is associated with conversions to
> do with types.
> 
> In my compiler for example, '*conv*' is used in many different
> contexts (eg. case conversion). '*cast*' is only used in two
> functions, both to do with C type conversions.
>
> But I also use both terms just to mix it up.
>
>>> I remember people here getting castigated for using the term 'type
>>> cast'. And yet, in H.2.4p1:
>>>
>>> "The LIA−1 type conversions are the following type casts:"
>> That wording is no longer there in more recent editions.  Annex H
>> refers to LIA-1 (Language Independent Arithmetic), ISO/IEC 10967–1;
>> perhaps that standard use the term "type casts".
>
> My point is that even the professionals who write such documents get
> it 'wrong', according to you.

Yes, and unlike you, they willingly correct their errors.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#387456

Bart <bc@freeuk.com> writes:
> On 09/08/2024 18:57, James Kuyper wrote:
...
>> A cast is a piece of syntax that is used to explicitly request that
>> a
>> conversion be performed. Conversions that are explicitly requested in C
>> code are referred to as casts only by people who don't understand what
>> they're saying - the standard never refers to them as such.
>
> Are you sure? What else would they be known as?

As Keith said, that's a typo - the second "explicitly" should have been
"implicitly".

[...]
> Here it uses the term 'explicit cast'. Why is that; isn't the term
> 'cast' unambiguous without needing to say 'explicit'?

It's redundant, and occurs only once in the entire standard. The purpose
of that redundancy was to emphasize that what the conversion it
describes never happens implicitly (unlike many of the other conversions).

> Also, what is exactly is the difference between 'explicit conversion'
> and 'explicit cast'?

None

> Why can't there also be a similar correlation between 'implicit
> conversion' and 'implicit cast'?

The C standard defines "implicit conversion" and "explicit conversion"
in 6.3p1, and the definition it provides for "explicit conversion" is
"those [conversions] that result from a cast operation". it provides a
grammar production for a cast expression, and none for a implicit cast
expression.

> even if it did, surely people ought to be allowed to use alternate
> terms for an informal discussion? This is a not a committee meeting.

Every time you use a term with a standard-define meaning in a way that
doesn't match the meaning defined for it by the standard, you create
potential confusion. If that's what you want to do, go ahead, but it
seems an odd thing to do.

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

#387537

On 10/08/2024 00:29, James Kuyper wrote:
> Bart <bc@freeuk.com> writes:
> 
>> Also, what is exactly is the difference between 'explicit conversion'
>> and 'explicit cast'?
> 
> None
> 

It is possible that the C standards authors here were envisaging other 
types of explicit conversion in the future.   For example, C++ has 
multiple forms of explicit conversion, at least some of which could 
reasonably be copied into C (such as the functional notation explicit 
type conversions - "int(x)", meaning the same as the cast "(int) x").

You could argue that the C standards use the term "explicit conversion" 
to make it clear that there are no /implicit/ conversions involved.  It 
does not matter if the explicit conversion is done with a cast operator, 
or in some other way - even if C (currently) has no other way to achieve 
the effect.

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

#387539

On 09/08/2024 23:29, James Kuyper wrote:
> Bart <bc@freeuk.com> writes:

> 
>> Why can't there also be a similar correlation between 'implicit
>> conversion' and 'implicit cast'?
> 
> The C standard defines "implicit conversion" and "explicit conversion"
> in 6.3p1, and the definition it provides for "explicit conversion" is
> "those [conversions] that result from a cast operation". it provides a
> grammar production for a cast expression, and none for a implicit cast
> expression.

What would the syntax look like for an implicit cast?

There isn't any. If there was, it wouldn't be implicit!

> 
>> even if it did, surely people ought to be allowed to use alternate
>> terms for an informal discussion? This is a not a committee meeting.
> 
> Every time you use a term with a standard-define meaning in a way that
> doesn't match the meaning defined for it by the standard, you create
> potential confusion. If that's what you want to do, go ahead, but it
> seems an odd thing to do.


What standard-defined meaning is attributed to 'implicit cast'? Since as 
everyone keeps telling me, that term is not used.

Does that mean it's up for grabs?

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

#387541

On 8/9/24 18:29, James Kuyper wrote:
> Bart <bc@freeuk.com> writes:
...
>> Why can't there also be a similar correlation between 'implicit
>> conversion' and 'implicit cast'?
> 
> The C standard defines "implicit conversion" and "explicit conversion"
> in 6.3p1, and the definition it provides for "explicit conversion" is
> "those [conversions] that result from a cast operation". it provides a
> grammar production for a cast expression, and none for a implicit cast
> expression.

Note, in particular, that if there were such a thing as an implicit
cast, then, as the name implies, an implicit cast would qualify as a
cast. Since, according to the above definition, all conversions that
result from casts would qualify as "explicit conversions", that would
include conversions that result from implicit casts. In other words, all
conversions would be explicit conversions. In addition, per 6.3p1, the
conversions described in 6.3 would also be implicit conversions, which
is just plain ridiculous.

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

#387542

On 13/08/2024 12:51, James Kuyper wrote:
> On 8/9/24 18:29, James Kuyper wrote:
>> Bart <bc@freeuk.com> writes:
> ...
>>> Why can't there also be a similar correlation between 'implicit
>>> conversion' and 'implicit cast'?
>>
>> The C standard defines "implicit conversion" and "explicit conversion"
>> in 6.3p1, and the definition it provides for "explicit conversion" is
>> "those [conversions] that result from a cast operation". it provides a
>> grammar production for a cast expression, and none for a implicit cast
>> expression.
> 
> Note, in particular, that if there were such a thing as an implicit
> cast, then, as the name implies, an implicit cast would qualify as a
> cast. Since, according to the above definition, all conversions that
> result from casts would qualify as "explicit conversions", that would
> include conversions that result from implicit casts. In other words, all
> conversions would be explicit conversions. In addition, per 6.3p1, the
> conversions described in 6.3 would also be implicit conversions, which
> is just plain ridiculous.

If that were the case then the use of 'cast' would be more likely to be 
qualified.

I get that the standard mainly intends 'cast' to mean that bit of 
syntax, '(T)X', by which you can force a particular conversion.

But '(T)X' can also be described as a conversion, or an explicit 
conversion, or a coercion (this more where an automatic implicit 
conversion does not exist), as well as a cast.

Then I think it's perfectly acceptable to use all these terms 
interchangeably when there is no confusion. In that case, using 
'implicit cast' to mean the same as explicit or automatic conversion 
shouldn't present any problems.

Other than to C Standard purists.

Of course, if it is necessary to be much more precise and specific /for 
a reason/, then you'd need to take more care.

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

#387545

Bart <bc@freeuk.com> writes:
[...]
> I get that the standard mainly intends 'cast' to mean that bit of
> syntax, '(T)X', by which you can force a particular conversion.

No, the standard *exclusively* uses "cast" to mean that bit of syntax
(except in Annex H, but those incorrect uses of the word are corrected
in C23).  But of course you know that.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#387548

On 13/08/2024 20:46, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> I get that the standard mainly intends 'cast' to mean that bit of
>> syntax, '(T)X', by which you can force a particular conversion.
> 
> No, the standard *exclusively* uses "cast" to mean that bit of syntax
> (except in Annex H, but those incorrect uses of the word are corrected
> in C23).  But of course you know that.

Blimey, you're not to let this go are you?

N1570 contains 2 instances of 'casting' (one is to do with type 
conversion; the other with voting).

Plus 9 instances of 'casts'. And 56 instances of 'cast', but many of 
those are part of 'cast operator', or 'cast expression' (separate from 
/cast-expression/).

There is also the confusing '(cast)', with 'cast' in italics, but that's 
in the already discredited Annex H. (Confusing because I thought a cast 
included the parentheses.)

You're making me as obsessed with this as you are!

Well, here's an interesting titbit: in my syntax, 'cast' is a reserved 
word that can be used for type conversion as 'cast(X, T)', meaning 
'(T)X' in C, used when the normal 'T(X)' is ambiguous.

So, for all this fuss about 'cast' in the Standard, it isn't even a 
reserved word in C itself.

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

#387549

Bart <bc@freeuk.com> writes:

> So, for all this fuss about 'cast' in the Standard, it isn't even
> a reserved word in C itself.

Many or most of the defined terms in the C standard are not
keywords or reserved words in the C language.

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

#387551

On 14/08/2024 00:46, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
> 
>> So, for all this fuss about 'cast' in the Standard, it isn't even
>> a reserved word in C itself.
> 
> Many or most of the defined terms in the C standard are not
> keywords or reserved words in the C language.

My point was, if 'cast' /was/ a reserved word, then you'd have to get it 
just right with no quibbling.

But it isn't. A bit silly to apply just as strict rules to humans 
discussing topics in English. It's not as though usenet messages are 
going to be compiled with 'gcc -Wpedantic'!

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

#387632

Bart <bc@freeuk.com> writes:

> On 14/08/2024 00:46, Tim Rentsch wrote:
>
>> Bart <bc@freeuk.com> writes:
>>
>>> So, for all this fuss about 'cast' in the Standard, it isn't
>>> even a reserved word in C itself.
>>
>> Many or most of the defined terms in the C standard are not
>> keywords or reserved words in the C language.
>
> My point was, if 'cast' /was/ a reserved word, then you'd have to
> get it just right with no quibbling.

I knew what you meant.

> But it isn't.  A bit silly to apply just as strict rules to humans
> discussing topics in English.

Not silly at all, in the context of educated discussions in a
technical newsgroup.

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

#387451

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> A cast is a piece of syntax that is used to explicitly request that a
> conversion be performed. Conversions that are explicitly requested in C
> code are referred to as casts only by people who don't understand what
> they're saying - the standard never refers to them as such.

I think you omitted a "not" in the above, or meant to write "implicitly"
rather than "explicitly".

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

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

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

csiph-web