Terminology : casting/conversion

Discussion in 'C Programming' started by Richard G. Riley, Mar 11, 2006.

  1. Would it be wrong to use "implicit casting" instead of the standards
    "implicit conversion" when talking about implicit conversions between
    certain data types. The standard mentions "explicit conversion" for a
    cast operation
    Richard G. Riley, Mar 11, 2006
    #1
    1. Advertising

  2. Richard G. Riley wrote:
    > Would it be wrong to use "implicit casting" instead of the standards
    > "implicit conversion" when talking about implicit conversions between
    > certain data types. The standard mentions "explicit conversion" for a
    > cast operation


    If a cast is an explicit conversion then an "implicit cast" would be an
    implicit explicit conversion, does that make much sense to you?

    Robert Gamble
    Robert Gamble, Mar 11, 2006
    #2
    1. Advertising

  3. Richard G. Riley

    Chris Torek Guest

    In article <>
    Richard G. Riley <> wrote:
    >Would it be wrong to use "implicit casting" instead of the standards
    >"implicit conversion" when talking about implicit conversions between
    >certain data types.


    It is certainly more consistent (and I think much less misleading)
    to use the phrase "implicit conversion". This is because the C
    standard defines "cast" as, in effect, "the syntactic construct
    consisting of a parenthesized type-name followed by a value
    expression, which causes an explicit conversion".

    The "followed by a value" part is to handle C99's aggregate constants,
    which use remarkably similar syntax, except that the parenthesized
    type-name is followed by an open brace. That is:

    (int)3.14159

    uses a cast, but:

    (int []){ 3, 1, 4, 1, 5, 9 }

    does not -- the parenthesized type supplies the information needed
    to construct the correct aggregate type, here "array 6 of int".
    Note that the same sequence of six "int" constants might be used
    to initialize something that is not an array at all:

    struct zorg {
    char a;
    double b;
    short c;
    long d;
    float e;
    int f;
    };
    ...
    (struct zorg){ 3, 1, 4, 1, 5, 9 }

    If a "cast" is nothing more than the explicit syntactic construct,
    an "implicit cast" must be an "implicit explicit syntactic construct":
    oxymoronic, like "large small" or "jumbo shrimp". :)

    (The last line above is meant more to point out that such things
    do exist in English, and it would be possible for the C Standard
    to define the phrase "implicit cast" as an alternative for "implicit
    conversion". But it does not, and there is no need to clutter
    one's vocabulary with Extra Alternative Options from the Bureau of
    Redundancy Department.)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Mar 11, 2006
    #3
  4. Richard G. Riley

    Michael Mair Guest

    Richard G. Riley schrieb:
    > Would it be wrong to use "implicit casting" instead of the standards
    > "implicit conversion" when talking about implicit conversions between
    > certain data types. The standard mentions "explicit conversion" for a
    > cast operation


    In my understanding: Yes. C99, 6.3#1 speaks of operand value
    type conversions taking place automatically as implicit
    conversions -- which are opposed to casts (which are explicit
    conversions).
    An "implicit cast" makes no sense as it cannot be a cast.

    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
    Michael Mair, Mar 11, 2006
    #4
  5. On 2006-03-11, Chris Torek <> wrote:
    > In article <>
    > Richard G. Riley <> wrote:
    >>Would it be wrong to use "implicit casting" instead of the standards
    >>"implicit conversion" when talking about implicit conversions between
    >>certain data types.

    >
    > It is certainly more consistent (and I think much less misleading)
    > to use the phrase "implicit conversion". This is because the C
    > standard defines "cast" as, in effect, "the syntactic construct
    > consisting of a parenthesized type-name followed by a value
    > expression, which causes an explicit conversion".
    >
    > The "followed by a value" part is to handle C99's aggregate constants,
    > which use remarkably similar syntax, except that the parenthesized
    > type-name is followed by an open brace. That is:
    >
    > (int)3.14159
    >
    > uses a cast, but:
    >
    > (int []){ 3, 1, 4, 1, 5, 9 }
    >
    > does not -- the parenthesized type supplies the information needed
    > to construct the correct aggregate type, here "array 6 of int".
    > Note that the same sequence of six "int" constants might be used
    > to initialize something that is not an array at all:
    >
    > struct zorg {
    > char a;
    > double b;
    > short c;
    > long d;
    > float e;
    > int f;
    > };
    > ...
    > (struct zorg){ 3, 1, 4, 1, 5, 9 }
    >
    > If a "cast" is nothing more than the explicit syntactic construct,
    > an "implicit cast" must be an "implicit explicit syntactic construct":
    > oxymoronic, like "large small" or "jumbo shrimp". :)
    >
    > (The last line above is meant more to point out that such things
    > do exist in English, and it would be possible for the C Standard
    > to define the phrase "implicit cast" as an alternative for "implicit
    > conversion". But it does not, and there is no need to clutter
    > one's vocabulary with Extra Alternative Options from the Bureau of
    > Redundancy Department.)



    thanks for the replies guys.
    Richard G. Riley, Mar 11, 2006
    #5
  6. On 2006-03-11, Michael Mair <> wrote:
    > Richard G. Riley schrieb:
    >> Would it be wrong to use "implicit casting" instead of the standards
    >> "implicit conversion" when talking about implicit conversions between
    >> certain data types. The standard mentions "explicit conversion" for a
    >> cast operation

    >
    > In my understanding: Yes. C99, 6.3#1 speaks of operand value
    > type conversions taking place automatically as implicit
    > conversions -- which are opposed to casts (which are explicit
    > conversions).
    > An "implicit cast" makes no sense as it cannot be a cast.


    I see that, but in my twisted logic I guess that if its not an
    explicit cast but a conversion is being done "implicitly" then its an
    implicit cast ... ie same result but without the cast : or is that
    where I'm making my mistake? The result is not the same? I could be
    just confusing myself here : it has been known..

    >
    > Cheers
    > Michael
    Richard G. Riley, Mar 11, 2006
    #6
  7. Richard G. Riley said:

    > On 2006-03-11, Michael Mair <> wrote:
    >> An "implicit cast" makes no sense as it cannot be a cast.

    >
    > I see that, but in my twisted logic I guess that if its not an
    > explicit cast


    Whoops - an "explicit cast" would be an "explicit explicit conversion".

    > but a conversion is being done "implicitly" then its an
    > implicit cast


    i.e. an "implicit explicit conversion", which, as Chris pointed out, is
    oxymoronic.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Mar 11, 2006
    #7
  8. On 2006-03-11, Richard Heathfield <> wrote:
    > Richard G. Riley said:
    >
    >> On 2006-03-11, Michael Mair <> wrote:
    >>> An "implicit cast" makes no sense as it cannot be a cast.

    >>
    >> I see that, but in my twisted logic I guess that if its not an
    >> explicit cast

    >
    > Whoops - an "explicit cast" would be an "explicit explicit conversion".
    >


    Richard, lets stick with this because I'm really confused here : no
    shit.

    If I do

    p = (char *)p2;

    Is this an "explicit" cast? Or just a cast?

    p = p2;

    Here are p & p2 are pointers but the compiler "implicitly" converts
    one to the other since they are different base pointer types.

    Now to my really confused mind, it would be ok to call this an
    "implicit cast"?

    To be honest I never really gave it much thought before, but soon
    realised that if one is to joing in the mud slinging then ones
    vocabulary has to be spot on.


    >> but a conversion is being done "implicitly" then its an
    >> implicit cast

    >
    > i.e. an "implicit explicit conversion", which, as Chris pointed out, is
    > oxymoronic.
    >
    Richard G. Riley, Mar 11, 2006
    #8
  9. Richard G. Riley

    Chris Torek Guest

    In article <>
    Richard G. Riley <> wrote:
    >If I do
    >
    > p = (char *)p2;
    >
    >Is this an "explicit" cast? Or just a cast?


    I would call it just "a cast". Specifically, the cast (or
    "cast expression" or "cast-expression") is the part on the right
    hand side of the assigment. From a C99 draft:

    6.3.4 Cast operators

    Syntax

    [#1]

    cast-expr:
    unary-expr
    ( type-name ) cast-expr
    ...
    Semantics

    [#4] Preceding an expression by a parenthesized type name
    converts the value of the expression to the named type.
    This construction is called a cast.73 A cast that specifies
    no conversion has no effect on the type or value of an
    expression.74

    __________

    73. A cast does not yield an lvalue. Thus, a cast to a
    qualified type has the same effect as a cast to the
    unqualified version of the type.

    74. If the value of the expression is represented with
    greater precision or range than required by the type
    named by the cast (6.2.1.7), then the cast specifies a
    conversion even if the type of the expression is the
    same as the named type.


    I will note that the phrase "explicit cast" *does* appear in the
    (draft) Standard, right in the section I elided above:

    Constraints

    [#2] Unless the type name specifies a void type, the type
    name shall specify qualified or unqualified scalar type and
    the operand shall have scalar type.

    [#3] Conversions that involve pointers, other than where
    permitted by the constraints of 6.3.16.1, shall be specified
    by means of an explicit cast.

    However, this is the only occurrence of that phrase, and it appears
    after the following:

    6.2 Conversions

    [#1] Several operators convert operand values from one type
    to another automatically. This subclause specifies the
    result required from such an implicit conversion, as well as
    those that result from a cast operation (an explicit
    conversion). The list in 6.2.1.7 summarizes the conversions
    performed by most ordinary operators; it is supplemented as
    required by the discussion of each operator in 6.3.

    [#2] Conversion of an operand value to a compatible type
    causes no change to the value or the representation.

    Paragraph #1 here makes it clear that a cast is an explicit
    conversion, and there are other kinds of conversions that are
    implicit.

    > p = p2;
    >
    >Here are p & p2 are pointers but the compiler "implicitly" converts
    >one to the other since they are different base pointer types.


    You need to show declarations (or at least those base types) first,
    here. :)

    To make it "work right" let me supply them now, along with the rest
    of the original code:

    char *p;
    void *p2;
    ... /* presumably this code sets p2 */
    p = (char *)p2;
    ...
    p = p2;

    Both assignments are now correct. There is only one cast, on the
    right hand side of the first ordinary assignment operator.

    >Now to my really confused mind, it would be ok to call [the
    >second expression] an "implicit cast"?


    I think it is much better to use the phrase "implicit conversion"
    (in this case, from "void *" to "char *"). Reserve the word "cast"
    to refer only to the syntactic (source-code) construct.

    (I do not know if you have ever worked on the "compiler geek" side
    of the computer, but if you have -- or if you can recall the
    appropriate college courses -- you might note that modern compilers
    generally comprise a number of loosely, or at least not overly
    tightly, coupled pieces. One or two front end parts break up the
    input into "lexemes" or "tokens" that can be recognized by simple
    regular expressions. These feed into a "parser" that turns
    syntactically-correct "sentences" into, typically, a "parse tree".
    In a toy compiler, this parse tree is almost unconnected to the
    original source, although in real compilers the tree is highly
    decorated so that each piece can be tracked back to the appropriate
    source line or even character, both for error messsages -- which
    need to refer you back to the source code -- and for associating
    final machine instructions with source code for the debuggers.

    The parse tree is then manipulated by a semantic analyzer that
    replaces the original tree with something equivalent. Semantics
    analysis is where most optimization occurs. Consider the following
    C parse tree fragment:

    (LIST
    (ASSIGN (VAR sum) (DOUBLECONST 0.0))
    (ASSIGN (VAR i) (INTCONST 0))
    (LOOP-WHILE (LESS-THAN (VAR i) (INTCONST 10))
    (ASSIGN (VAR sum)
    (PLUS (VAR sum)
    (DEREF
    (PLUS (ADDR arr)
    (TIMES (VAR i) (INTCONST 8))))))
    (ASSIGN (var i) (PLUS (VAR i) (INTCONST 1))))
    )

    This parse tree might arise out of the source code:

    sum = 0.0;
    for (i = 0; i < 10; i++)
    sum += arr;

    where "sum" is a double and "i" is an int. The "INTCONST 8" is
    simply the size of a double, and the DEREF nodes occur because
    arr "means" *(arr + i), so the syntactic front-end handler simply
    generates a (DEREF (PLUS ...)) node in every case.

    The semantic analyzer's job includes discovering that the variable
    "i" is not used after the loop, so the loop can -- if this is
    profitable -- be strength-reduced to eliminate the embedded
    multiply:

    (LOOP-WHILE (LESS-THAN (VAR i) (INTCONST 80))
    (ASSIGN (VAR sum)
    (PLUS (VAR sum)
    (DEREF
    (PLUS (ADDR arr) (VAR i)))))
    (ASSIGN (var i) (PLUS (VAR i) (INTCONST 8))))

    This loop is equivalent if and only if "i" is dead after this point.
    If not, the strength-reduction can still be done by rewriting each
    (VAR i) with (VAR i2), where i2 is created by the compiler, and
    adding a final (ASSIGN (VAR i) 10) after the loop. [Depending on
    the compiler, the strength-reducer may simply automatically insert
    a new variable, and let later dead-code optimization remove the
    unneeded one(s).]

    Following -- or in some, hairier compilers, intermingled with --
    semantic analysis and overall high-level optimization, the compiler
    must do instruction selection/generation and scheduling. On
    modern CPUs, instruction scheduling is just as hard a problem
    as semantic analysis, and the selection and generation do affect
    which optimizations are appropriate, so this is basically where
    all the money is. :)

    On the compiler-geek side, syntax is "mere" syntax: the Lisp-like
    parse tree above is just as good as the C fragment, and in many
    cases quite preferable. Of course, not all humans feel the same
    way about "mere" syntax. A spoonful of "syntactic sugar" often
    seems to help the medicine go down.)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Mar 11, 2006
    #9
  10. Richard G. Riley

    Eric Sosman Guest

    Richard G. Riley wrote:
    >
    > If I do
    >
    > p = (char *)p2;
    >
    > Is this an "explicit" cast? Or just a cast?


    It is a "cast," and it is "explicit," but "explicit cast"
    is overkill. In `a + b' would you call the `+' an "explicit
    addition operator?"

    > p = p2;
    >
    > Here are p & p2 are pointers but the compiler "implicitly" converts
    > one to the other since they are different base pointer types.


    Assuming that they're assignment-compatible; if `p' is
    a `double*' and `p2' is a `char*', this would require a
    diagnostic. But yes: If they're something like `double*'
    and `void*', the conversion is implicit.

    > Now to my really confused mind, it would be ok to call this an
    > "implicit cast"?


    No; there's no such thing. It's an implicit conversion,
    that is, a conversion that occurs in the absence of an operator
    (all operators are explicit).

    I think that you (and you're not by any means alone) have
    somehow stirred the two different notions of "conversion" and
    "cast" into the same can of muddy-colored paint. If you make
    a point of separating them:

    - A "conversion" is the act of deriving a value of one type
    from a value of another. Some conversions (`int' -> `long',
    `char*' -> `void*', others) occur automatically when the
    context requires them; these are "implicit" conversions.

    - A "cast" is an operator that causes a conversion (except
    in degenerate cases like casting an `int' to an `int', or
    casting anything to `void'). Since it is written out in
    the source code, right there where anyone can see it, it
    is necessarily "explicit."

    .... your confusion may diminish.

    A single expression can have both implicit and explicit
    conversions, e.g. `(double)5 / 9': the conversion of five from
    `int' to `double' is explicit and caused by the cast, while
    the conversion of nine from `int' to `double' is implicit,
    implied by the rules of the division operator. And, of course,
    an expression can also have unnecessary explicit conversions,
    as in `(double)5 / (double)9' -- there can be sometimes be
    value in inserting extra casts as a kind of documentation.

    --
    Eric Sosman
    lid
    Eric Sosman, Mar 11, 2006
    #10
  11. On 2006-03-11, Eric Sosman <> wrote:

    > I think that you (and you're not by any means alone) have
    > somehow stirred the two different notions of "conversion" and


    I think you're right and in over 15 years of programming this is the
    first time I ever really considered the words : it was someone calling
    me an idiot somewhere for using the wrong word which woke me up :)

    > "cast" into the same can of muddy-colored paint. If you make
    > a point of separating them:
    >
    > - A "conversion" is the act of deriving a value of one type
    > from a value of another. Some conversions (`int' -> `long',
    > `char*' -> `void*', others) occur automatically when the
    > context requires them; these are "implicit" conversions.
    >
    > - A "cast" is an operator that causes a conversion (except
    > in degenerate cases like casting an `int' to an `int', or
    > casting anything to `void'). Since it is written out in
    > the source code, right there where anyone can see it, it
    > is necessarily "explicit."
    >
    > ... your confusion may diminish.


    It is, but ... (please stick with me) ... there are cases where "casts
    are not required" because of an implicit conversion? This is right,
    yes?


    >
    > A single expression can have both implicit and explicit
    > conversions, e.g. `(double)5 / 9': the conversion of five from
    > `int' to `double' is explicit and caused by the cast, while


    "The cast causes an explicit conversion"?. Fine.

    > the conversion of nine from `int' to `double' is implicit,
    > implied by the rules of the division operator. And, of course,
    > an expression can also have unnecessary explicit conversions,
    > as in `(double)5 / (double)9' -- there can be sometimes be
    > value in inserting extra casts as a kind of documentation.
    >


    Thanks Eric : nothing I didnt "know" in practice, but now the terminology is
    clearer : for now :-; Funny how as you stay away from academic
    reasoners the vocab slips so bad :( Before you know it I'll be calling
    pointers "references" ...
    Richard G. Riley, Mar 11, 2006
    #11
  12. Thaks Chris : you & Eric have cleared it up. There was a piece of crud
    stuck to my cerebral cortex which your explanations dissolved :) Uni
    was over 15 years ago too : so proper terminology might have, cough,
    suffered a little.


    On 2006-03-11, Chris Torek <> wrote:
    > In article <>
    > Richard G. Riley <> wrote:
    >>If I do
    >>
    >> p = (char *)p2;
    >>
    >>Is this an "explicit" cast? Or just a cast?

    >
    > I would call it just "a cast". Specifically, the cast (or
    > "cast expression" or "cast-expression") is the part on the right
    > hand side of the assigment. From a C99 draft:
    >
    > 6.3.4 Cast operators
    >
    > Syntax
    >
    > [#1]
    >
    > cast-expr:
    > unary-expr
    > ( type-name ) cast-expr
    > ...
    > Semantics
    >
    > [#4] Preceding an expression by a parenthesized type name
    > converts the value of the expression to the named type.
    > This construction is called a cast.73 A cast that specifies
    > no conversion has no effect on the type or value of an
    > expression.74
    >
    > __________
    >
    > 73. A cast does not yield an lvalue. Thus, a cast to a
    > qualified type has the same effect as a cast to the
    > unqualified version of the type.
    >
    > 74. If the value of the expression is represented with
    > greater precision or range than required by the type
    > named by the cast (6.2.1.7), then the cast specifies a
    > conversion even if the type of the expression is the
    > same as the named type.
    >
    >
    > I will note that the phrase "explicit cast" *does* appear in the
    > (draft) Standard, right in the section I elided above:
    >
    > Constraints
    >
    > [#2] Unless the type name specifies a void type, the type
    > name shall specify qualified or unqualified scalar type and
    > the operand shall have scalar type.
    >
    > [#3] Conversions that involve pointers, other than where
    > permitted by the constraints of 6.3.16.1, shall be specified
    > by means of an explicit cast.
    >
    > However, this is the only occurrence of that phrase, and it appears
    > after the following:
    >
    > 6.2 Conversions
    >
    > [#1] Several operators convert operand values from one type
    > to another automatically. This subclause specifies the
    > result required from such an implicit conversion, as well as
    > those that result from a cast operation (an explicit
    > conversion). The list in 6.2.1.7 summarizes the conversions
    > performed by most ordinary operators; it is supplemented as
    > required by the discussion of each operator in 6.3.
    >
    > [#2] Conversion of an operand value to a compatible type
    > causes no change to the value or the representation.
    >
    > Paragraph #1 here makes it clear that a cast is an explicit
    > conversion, and there are other kinds of conversions that are
    > implicit.
    >
    >> p = p2;
    >>
    >>Here are p & p2 are pointers but the compiler "implicitly" converts
    >>one to the other since they are different base pointer types.

    >
    > You need to show declarations (or at least those base types) first,
    > here. :)
    >
    > To make it "work right" let me supply them now, along with the rest
    > of the original code:
    >
    > char *p;
    > void *p2;
    > ... /* presumably this code sets p2 */
    > p = (char *)p2;
    > ...
    > p = p2;
    >
    > Both assignments are now correct. There is only one cast, on the
    > right hand side of the first ordinary assignment operator.
    >
    >>Now to my really confused mind, it would be ok to call [the
    >>second expression] an "implicit cast"?

    >
    > I think it is much better to use the phrase "implicit conversion"
    > (in this case, from "void *" to "char *"). Reserve the word "cast"
    > to refer only to the syntactic (source-code) construct.
    >
    > (I do not know if you have ever worked on the "compiler geek" side
    > of the computer, but if you have -- or if you can recall the
    > appropriate college courses -- you might note that modern compilers
    > generally comprise a number of loosely, or at least not overly
    > tightly, coupled pieces. One or two front end parts break up the
    > input into "lexemes" or "tokens" that can be recognized by simple
    > regular expressions. These feed into a "parser" that turns
    > syntactically-correct "sentences" into, typically, a "parse tree".
    > In a toy compiler, this parse tree is almost unconnected to the
    > original source, although in real compilers the tree is highly
    > decorated so that each piece can be tracked back to the appropriate
    > source line or even character, both for error messsages -- which
    > need to refer you back to the source code -- and for associating
    > final machine instructions with source code for the debuggers.
    >
    > The parse tree is then manipulated by a semantic analyzer that
    > replaces the original tree with something equivalent. Semantics
    > analysis is where most optimization occurs. Consider the following
    > C parse tree fragment:
    >
    > (LIST
    > (ASSIGN (VAR sum) (DOUBLECONST 0.0))
    > (ASSIGN (VAR i) (INTCONST 0))
    > (LOOP-WHILE (LESS-THAN (VAR i) (INTCONST 10))
    > (ASSIGN (VAR sum)
    > (PLUS (VAR sum)
    > (DEREF
    > (PLUS (ADDR arr)
    > (TIMES (VAR i) (INTCONST 8))))))
    > (ASSIGN (var i) (PLUS (VAR i) (INTCONST 1))))
    > )
    >
    > This parse tree might arise out of the source code:
    >
    > sum = 0.0;
    > for (i = 0; i < 10; i++)
    > sum += arr;
    >
    > where "sum" is a double and "i" is an int. The "INTCONST 8" is
    > simply the size of a double, and the DEREF nodes occur because
    > arr "means" *(arr + i), so the syntactic front-end handler simply
    > generates a (DEREF (PLUS ...)) node in every case.
    >
    > The semantic analyzer's job includes discovering that the variable
    > "i" is not used after the loop, so the loop can -- if this is
    > profitable -- be strength-reduced to eliminate the embedded
    > multiply:
    >
    > (LOOP-WHILE (LESS-THAN (VAR i) (INTCONST 80))
    > (ASSIGN (VAR sum)
    > (PLUS (VAR sum)
    > (DEREF
    > (PLUS (ADDR arr) (VAR i)))))
    > (ASSIGN (var i) (PLUS (VAR i) (INTCONST 8))))
    >
    > This loop is equivalent if and only if "i" is dead after this point.
    > If not, the strength-reduction can still be done by rewriting each
    > (VAR i) with (VAR i2), where i2 is created by the compiler, and
    > adding a final (ASSIGN (VAR i) 10) after the loop. [Depending on
    > the compiler, the strength-reducer may simply automatically insert
    > a new variable, and let later dead-code optimization remove the
    > unneeded one(s).]
    >
    > Following -- or in some, hairier compilers, intermingled with --
    > semantic analysis and overall high-level optimization, the compiler
    > must do instruction selection/generation and scheduling. On
    > modern CPUs, instruction scheduling is just as hard a problem
    > as semantic analysis, and the selection and generation do affect
    > which optimizations are appropriate, so this is basically where
    > all the money is. :)
    >
    > On the compiler-geek side, syntax is "mere" syntax: the Lisp-like
    > parse tree above is just as good as the C fragment, and in many
    > cases quite preferable. Of course, not all humans feel the same
    > way about "mere" syntax. A spoonful of "syntactic sugar" often
    > seems to help the medicine go down.)
    Richard G. Riley, Mar 11, 2006
    #12
  13. Richard G. Riley

    Eric Sosman Guest

    Richard G. Riley wrote:

    > On 2006-03-11, Eric Sosman <> wrote:
    >
    > It is, but ... (please stick with me) ... there are cases where "casts
    > are not required" because of an implicit conversion? This is right,
    > yes?


    Yes: Sometimes the conversion called for by a cast is the
    same one the compiler would have done implicitly had the cast
    been absent:

    long l;
    l = 42; /* implicit int => long */
    l = (long)42; /* explicit int => long */

    > Thanks Eric : nothing I didnt "know" in practice, but now the terminology is
    > clearer : for now :-; Funny how as you stay away from academic
    > reasoners the vocab slips so bad :( Before you know it I'll be calling
    > pointers "references" ...


    If you want That Other Language, you know where to find it. ;-)

    A certain looseness of language can be useful at times, as
    it can condense long-winded descriptions into brief phrases that
    don't interrupt the flow of thought. We say that the argument to
    strlen() is a "pointer to a string," which is more convenient
    than saying it is a "pointer to a char somewhere in an array
    containing a zero-valued char at or after the pointed-to char."
    We speak of a pointer that points "just past the end of an array,"
    which you may wish to contrast with the Standard's long-winded
    prose that describes the properties of that pointer without using
    the troublesome notion of the existence of a "one past the end"
    element. We speak of the limit of f(x) "as x approaches x0,"
    rather than use the long-winded epsilons and deltas of a calculus
    text, which carefully defines "limit" without appealing to ideas
    of "motion."

    Convenient as loose speech can be, sometimes greater precision
    is required -- as, for example, when someone is asking about the
    fine distinctions! (And sometimes someone who seems to be speaking
    precisely is not in fact doing so. At the closing for a house
    purchase, the bank's lawyer asked to "see" my check for the down
    payment. I passed it to him, and the ritual proceeded. Some time
    later as he got ready to leave, he asked if there were any questions.
    "One," said I. "Did you want me to sign that check?" He had used
    the brief and inexact "Let me see the check" instead of "Sign the
    check and give it to me in the presence of these witnesses," and
    what with me being a first-time buyer and him being a professional
    I had assumed he was speaking precisely. It would have been nice
    to buy the house for a Whole Lot Less than the agreed price, but even
    as a first-time buyer I had a hunch I wouldn't get away with it ...)

    --
    Eric Sosman
    lid
    Eric Sosman, Mar 11, 2006
    #13
  14. Richard G. Riley

    Richard Bos Guest

    "Richard G. Riley" <> wrote:

    > Would it be wrong to use "implicit casting" instead of the standards
    > "implicit conversion" when talking about implicit conversions between
    > certain data types. The standard mentions "explicit conversion" for a
    > cast operation


    It's about as right as using "implicit right turn sign" for a bend in
    the road.

    Richard
    Richard Bos, Mar 13, 2006
    #14
  15. Richard G. Riley

    Richard Bos Guest

    "Richard G. Riley" <> wrote:

    > On 2006-03-11, Richard Heathfield <> wrote:
    > > Richard G. Riley said:
    > >
    > >> I see that, but in my twisted logic I guess that if its not an
    > >> explicit cast

    > >
    > > Whoops - an "explicit cast" would be an "explicit explicit conversion".


    Oh, bull.

    > Richard, lets stick with this because I'm really confused here : no
    > shit.
    >
    > If I do
    >
    > p = (char *)p2;
    >
    > Is this an "explicit" cast? Or just a cast?


    It is a cast. Since a cast is a source code construct, _all_ casts are
    explicit. Calling it an explicit cast is therefore redundant, but not
    actually wrong.

    > p = p2;
    >
    > Here are p & p2 are pointers but the compiler "implicitly" converts
    > one to the other since they are different base pointer types.
    >
    > Now to my really confused mind, it would be ok to call this an
    > "implicit cast"?


    No. It's a conversion. There is no (type) in the code, so there is no
    cast, implicit or otherwise.

    Richard
    Richard Bos, Mar 13, 2006
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. anon
    Replies:
    6
    Views:
    503
  2. kevin
    Replies:
    11
    Views:
    5,775
    Andrew McDonagh
    Jan 8, 2005
  3. Wally Barnes
    Replies:
    3
    Views:
    506
    Wally Barnes
    Nov 20, 2008
  4. Sosuke

    Up casting and down casting

    Sosuke, Dec 20, 2009, in forum: C++
    Replies:
    2
    Views:
    541
    James Kanze
    Dec 20, 2009
  5. Paul
    Replies:
    63
    Views:
    1,195
Loading...

Share This Page