Half hearted _Bool

Discussion in 'C Programming' started by sandeep, Jun 25, 2010.

  1. sandeep

    sandeep Guest

    In C99 the new _Bool boolean data type was introduced. However this seems
    to be a token gesture! There was no attempt to integrate it into the
    standard library. For example, functions like isdigit still return int
    instead of the new _Bool (which has implicit casts to and from int, so
    there would be no incompatability with existing code)

    Compare this to the new restrict keyboard which is introduced into the
    declarations of many standard library functions, potentially causing
    subtle compatability bugs if programs compiled for C99 are linked against
    C90 libraries.

    Does anyone have any insight here?
    sandeep, Jun 25, 2010
    #1
    1. Advertising

  2. sandeep

    Eric Sosman Guest

    On 6/25/2010 5:18 PM, sandeep wrote:
    > In C99 the new _Bool boolean data type was introduced. However this seems
    > to be a token gesture! There was no attempt to integrate it into the
    > standard library. For example, functions like isdigit still return int
    > instead of the new _Bool (which has implicit casts to and from int, so
    > there would be no incompatability with existing code)


    Where's the benefit in returning _Bool instead of zero/nonzero?
    I suppose you could then write

    if (isdigit(ch) ^ islower(ch))

    .... but when was the last time you wanted to do such a thing? (Note
    that `if (!isdigit(ch) ^ !islower(ch))' gives you the same effect
    today, should you desire it.)

    Meanwhile, the change would invalidate existing code that uses
    function pointers to point at the isxxx() functions:

    void doSomething(const char *string, int (*is_xxx)(int)) {
    ...
    }

    doSomething("The Answer is 42!", isdigit);

    If isdigit() suddenly changed to a _Bool-valued function, compilers
    would start complaining about this sort of thing in perfectly good
    code. Code breakage has certainly been committed, but only in pursuit
    of some real or imagined benefit. What benefit flows from this change,
    a benefit valuable enough to excuse the breakage?

    --
    Eric Sosman
    lid
    Eric Sosman, Jun 25, 2010
    #2
    1. Advertising

  3. sandeep

    Guest

    On Jun 25, 4:18 pm, sandeep <> wrote:
    > In C99 the new _Bool boolean data type was introduced. However this seems
    > to be a token gesture! There was no attempt to integrate it into the
    > standard library. For example, functions like isdigit still return int
    > instead of the new _Bool (which has implicit casts to and from int, so
    > there would be no incompatability with existing code)



    It would break anything expecting a function pointer to a routine
    returning an int, to which you passed a pointer to isdigit().


    > Compare this to the new restrict keyboard which is introduced into the
    > declarations of many standard library functions, potentially causing
    > subtle compatability bugs if programs compiled for C99 are linked against
    > C90 libraries.



    Why do you think it would be valid to link a C99 program against a C89/
    C90 standard library?
    , Jun 25, 2010
    #3
  4. sandeep

    sandeep Guest

    Eric Sosman writes:
    > Meanwhile, the change would invalidate existing code that uses
    > function pointers to point at the isxxx() functions:
    >
    > void doSomething(const char *string, int (*is_xxx)(int)) {
    > ...
    > }
    >
    > doSomething("The Answer is 42!", isdigit);


    This is also true of introducing restrict into the declaration of strcpy
    etc.

    > If isdigit() suddenly changed to a _Bool-valued function, compilers
    > would start complaining about this sort of thing in perfectly good code.
    > Code breakage has certainly been committed, but only in pursuit of some
    > real or imagined benefit. What benefit flows from this change, a
    > benefit valuable enough to excuse the breakage?


    What was the point of introducing a _Bool type at all then? User code
    could already make its own bool or boolean or __bool definitions if
    necessary - why bother with a new type that doesn't appear anywhere in
    the Standard Library API?
    sandeep, Jun 26, 2010
    #4
  5. sandeep

    Eric Sosman Guest

    On 6/26/2010 7:17 AM, sandeep wrote:
    > Eric Sosman writes:
    >> Meanwhile, the change would invalidate existing code that uses
    >> function pointers to point at the isxxx() functions:
    >>
    >> void doSomething(const char *string, int (*is_xxx)(int)) {
    >> ...
    >> }
    >>
    >> doSomething("The Answer is 42!", isdigit);

    >
    > This is also true of introducing restrict into the declaration of strcpy
    > etc.


    My understanding of `restrict' is not especially firm, but I
    believe you're wrong about this. 6.7.3p7 says "[...] deleting all
    instances of [restrict] from all preprocessing translation units
    composing a conforming program does not change its meaning [...]"
    So in particular, the presence or absence of `restrict' in the
    declaration of a function pointer's prototype doesn't make any
    difference.

    FWIW, gcc agrees with me: The trivial translation unit

    #include <string.h>
    char * (*func)(char * R, const char * R) = strcpy;

    .... compiles without complaint and produces the same object code
    whether R is defined as `restrict' or defined as empty.

    >> If isdigit() suddenly changed to a _Bool-valued function, compilers
    >> would start complaining about this sort of thing in perfectly good code.
    >> Code breakage has certainly been committed, but only in pursuit of some
    >> real or imagined benefit. What benefit flows from this change, a
    >> benefit valuable enough to excuse the breakage?

    >
    > What was the point of introducing a _Bool type at all then? User code
    > could already make its own bool or boolean or __bool definitions if
    > necessary - why bother with a new type that doesn't appear anywhere in
    > the Standard Library API?


    I don't think `long long' or `signed char' are used as function
    values or arguments, either. As for the usefulness of _Bool -- well,
    I think it's of marginal utility. C certainly managed without it
    for a considerable span of time. C also managed without complex
    numbers for a considerable span. Some people (myself included) see
    no pressing need for either, but others quite clearly did so -- and
    more to the point, they made a sufficiently strong case to convince
    the C99 Committee. I wasn't there, didn't hear the arguments for and
    against, and am not in a position to assess them.

    --
    Eric Sosman
    lid
    Eric Sosman, Jun 26, 2010
    #5
  6. sandeep

    Tim Rentsch Guest

    sandeep <> writes:

    > Eric Sosman writes:
    >> Meanwhile, the change would invalidate existing code that uses
    >> function pointers to point at the isxxx() functions:
    >>
    >> void doSomething(const char *string, int (*is_xxx)(int)) {
    >> ...
    >> }
    >>
    >> doSomething("The Answer is 42!", isdigit);

    >
    > This is also true of introducing restrict into the declaration of strcpy
    > etc.


    Not so, because of 6.7.5.3p15, whose last sentence reads (parentheses
    present in original):

    (In the determination of type compatibility and of a composite
    type, each parameter declared with function or array type is
    taken as having the adjusted type and each parameter declared
    with qualified type is taken as having the unqualified version
    of its declared type.)

    This means the 'restrict's in the definitions of strcpy() etc don't
    affect the type compatibilities of those functions, any more than
    if the parameters in the definition were 'const' or 'volatile'.


    >> If isdigit() suddenly changed to a _Bool-valued function, compilers
    >> would start complaining about this sort of thing in perfectly good code.
    >> Code breakage has certainly been committed, but only in pursuit of some
    >> real or imagined benefit. What benefit flows from this change, a
    >> benefit valuable enough to excuse the breakage?

    >
    > What was the point of introducing a _Bool type at all then? User code
    > could already make its own bool or boolean or __bool definitions if
    > necessary - why bother with a new type that doesn't appear anywhere in
    > the Standard Library API?


    The semantics of _Bool differ in some significant ways from
    the sementics of other integer types. User code can make
    a "bool" or "boolean" type, but it isn't possible to make
    a type that has the same semantics as _Bool without having _Bool.
    Tim Rentsch, Jun 26, 2010
    #6
  7. sandeep

    Tim Rentsch Guest

    Richard Heathfield <> writes:

    > sandeep wrote:
    >> In C99 the new _Bool boolean data type was introduced. However this
    >> seems to be a token gesture! There was no attempt to integrate it
    >> into the standard library.

    >
    > Others have dealt with that point already, so I'm just here to pick a nit.
    >
    >> For example, functions like isdigit still return int instead of the
    >> new _Bool (which has implicit casts to and from int, so there would
    >> be no incompatability with existing code)

    >
    > Here's the nit: there is no such thing as an implicit cast. A cast is
    > an *explicit* conversion, by definition. If you have a copy of the C99
    > Standard (or at least a draft), see 6.3 Conversions.


    This complaint is silly. "Implicit" is a perfectly good English
    word, and anyone who is familiar enough with English to know what
    "implicit" means understands what the phrase "implicit cast" is
    meant to connote here. If the writing were meant as technically
    precise, then okay, the objection might be reasonable; but the
    writing is meant as English, and it is perfectly good English.
    Tim Rentsch, Jun 26, 2010
    #7
  8. In article <>,
    Tim Rentsch <> wrote:
    ....
    >This complaint is silly. "Implicit" is a perfectly good English
    >word, and anyone who is familiar enough with English to know what
    >"implicit" means understands what the phrase "implicit cast" is
    >meant to connote here. If the writing were meant as technically
    >precise, then okay, the objection might be reasonable; but the
    >writing is meant as English, and it is perfectly good English.


    You are right, of course. But...

    Alas, in CLC, "explicit cast" is right up with there with "void main" in
    terms of "phrases that push the regs' buttons" - and wind them up
    like a top.

    You'll get used to it.

    --
    Faced with the choice between changing one's mind and proving that there is
    no need to do so, almost everyone gets busy on the proof.

    - John Kenneth Galbraith -
    Kenny McCormack, Jun 26, 2010
    #8
  9. sandeep

    jacob navia Guest

    Richard Heathfield a écrit :
    > Tim Rentsch wrote:
    >
    > <snip>
    >
    >> This complaint is silly. "Implicit" is a perfectly good English
    >> word, and anyone who is familiar enough with English to know what
    >> "implicit" means understands what the phrase "implicit cast" is
    >> meant to connote here.

    >
    > It connotes "implicit explicit conversion". Gosh, how meaningful.
    >
    >

    No, it denotes implicit conversion as anyone with good faith can understand.

    An explicit conversion is

    int m (int)4.67;

    An implicit conversion is

    int m = 5.876;

    If you substitute conversion for "cast" (as anyone with good faith can
    do) you understand what is going on. You want to put your own meaning
    into the language used by people that do not know you nor have any
    interest in using the words with the meaning you want to put into them.

    Please understand that english is not your personal property and that
    other people will use it in slightly different ways as you do. Since
    they have the same rights as you, they can decide:

    a) Use english in the way Mr R. Heathfield wants
    b) Use english as THEY want, Mr Heathfield notwithsatnding.
    jacob navia, Jun 26, 2010
    #9
  10. On 26/06/2010 19:48, jacob navia wrote:
    > Richard Heathfield a écrit :
    >> Tim Rentsch wrote:
    >>
    >> <snip>
    >>
    >>> This complaint is silly. "Implicit" is a perfectly good English
    >>> word, and anyone who is familiar enough with English to know what
    >>> "implicit" means understands what the phrase "implicit cast" is
    >>> meant to connote here.

    >>
    >> It connotes "implicit explicit conversion". Gosh, how meaningful.
    >>
    >>

    > No, it denotes implicit conversion as anyone with good faith can
    > understand.
    >
    > An explicit conversion is
    >
    > int m (int)4.67;
    >
    > An implicit conversion is
    >
    > int m = 5.876;
    >
    > If you substitute conversion for "cast" (as anyone with good faith can
    > do) you understand what is going on. You want to put your own meaning
    > into the language used by people that do not know you nor have any
    > interest in using the words with the meaning you want to put into them.
    >
    > Please understand that english is not your personal property and that
    > other people will use it in slightly different ways as you do. Since
    > they have the same rights as you, they can decide:
    >
    > a) Use english in the way Mr R. Heathfield wants
    > b) Use english as THEY want, Mr Heathfield notwithsatnding.
    >


    ISO/IEC 9899:TC3 draft, 6.3p1, reads:

    "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)."

    There exist conversions. Only explicit ones can be called cast.

    Since "cast" = "explicit conversion", then:
    "implicit cast" = "implicit explicit conversion"

    i.e. somewhat misleading as "absolute relative motion" could be
    in physics: i mean "absolute motion" or "relative motion"?

    So: i mean "explicit conversion" or "implicit conversion"?

    I know that experts well understand what they are talking
    about, but you always have to keep in mind that readers
    are not all experts and maybe don't know how to check
    the ISO Standard.

    Since conversions are some of the 'hottest spots'
    in the C language, it would be in general a good habit to get
    a little 'picky' when dealing with them.

    Regards
    Vincenzo Mercuri, Jun 26, 2010
    #10
  11. Tim Rentsch <> writes:
    > Richard Heathfield <> writes:
    >> sandeep wrote:
    >>> In C99 the new _Bool boolean data type was introduced. However this
    >>> seems to be a token gesture! There was no attempt to integrate it
    >>> into the standard library.

    >>
    >> Others have dealt with that point already, so I'm just here to pick a nit.
    >>
    >>> For example, functions like isdigit still return int instead of the
    >>> new _Bool (which has implicit casts to and from int, so there would
    >>> be no incompatability with existing code)

    >>
    >> Here's the nit: there is no such thing as an implicit cast. A cast is
    >> an *explicit* conversion, by definition. If you have a copy of the C99
    >> Standard (or at least a draft), see 6.3 Conversions.

    >
    > This complaint is silly. "Implicit" is a perfectly good English
    > word, and anyone who is familiar enough with English to know what
    > "implicit" means understands what the phrase "implicit cast" is
    > meant to connote here. If the writing were meant as technically
    > precise, then okay, the objection might be reasonable; but the
    > writing is meant as English, and it is perfectly good English.


    I disagree.

    Yes, we all know that "implicit cast" really means "implicit
    conversion"; understanding what was meant is not the point.

    The point is that the word "cast" has a very specific meaning,
    and that meaning is specific to C, so questions of common English
    are not quite as relevant as they might otherwise be.

    If we loosely use the word "cast" to mean any conversion, implicit
    or explicit, then what do we call the operator consisting of a
    parenthesized type name?

    We have two perfectly good words, "conversion" and "cast", with
    related by quite distinct meanings. I don't want to lose that
    useful distinction. I don't want to have to qualify every use of
    either word with "explicit" or "implicit".

    This isn't to imply that anyone who uses the phrase "implicit
    cast" is stupid or evil. It's a common mistake, and a perfectly
    understandable one. But it is, in my opinion, a mistake, and one
    worth correcting.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 26, 2010
    #11
  12. sandeep

    Paul N Guest

    On 26 June, 14:49, Tim Rentsch <> wrote:
    > Richard Heathfield <> writes:
    > > sandeep wrote:
    > >> In C99 the new _Bool boolean data type was introduced. However this
    > >> seems to be a token gesture! There was no attempt to integrate it
    > >> into the standard library.

    >
    > > Others have dealt with that point already, so I'm just here to pick a nit.

    >
    > >> For example, functions like isdigit still return int instead of the
    > >> new _Bool (which has implicit casts to and from int, so there would
    > >> be no incompatability with existing code)

    >
    > > Here's the nit: there is no such thing as an implicit cast. A cast is
    > > an *explicit* conversion, by definition. If you have a copy of the C99
    > > Standard (or at least a draft), see 6.3 Conversions.

    >
    > This complaint is silly.  "Implicit" is a perfectly good English
    > word, and anyone who is familiar enough with English to know what
    > "implicit" means understands what the phrase "implicit cast" is
    > meant to connote here.  If the writing were meant as technically
    > precise, then okay, the objection might be reasonable;  but the
    > writing is meant as English, and it is perfectly good English.


    Erm, I beg to differ. I don't see how the sentence can make sense
    under any reasonable definition of "implicit". You have to adjust the
    meaning of "cast" to include "conversion", which is a bit of a stretch
    for a technical term.

    And as Richard said, it is only a nit. But clearly, as Kenny says, one
    which fires up the pedants.
    Paul N, Jun 26, 2010
    #12
  13. sandeep <> writes:
    [...]
    > What was the point of introducing a _Bool type at all then? User code
    > could already make its own bool or boolean or __bool definitions if
    > necessary - why bother with a new type that doesn't appear anywhere in
    > the Standard Library API?


    I think that was part of the point. One programmer defines his own
    "bool" type, another defines "boolean", another defines "__bool",
    another defines "TBool", and so on and so on. Adding a boolean type
    to the language encourages consistency, at least in future code.

    And, as others have mentioned, _Bool has properties that no user-defined
    C90 type can have, such as conversion yielding either 0 or 1.

    Personally, I would have preferred it if C had has "bool" from the
    beginning, and had used it consistently in the library.

    _Bool is a compromise. It gives is a standard Boolean type, but we're
    still stuck with a great deal of existing code.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 26, 2010
    #13
  14. sandeep

    Eric Sosman Guest

    On 6/26/2010 2:47 PM, Keith Thompson wrote:
    > [...]
    > If we loosely use the word "cast" to mean any conversion, implicit
    > or explicit, then what do we call the operator consisting of a
    > parenthesized type name?


    A "mistake," more often than not.

    --
    Eric Sosman
    lid
    Eric Sosman, Jun 26, 2010
    #14
  15. sandeep

    Tim Rentsch Guest

    Richard Heathfield <> writes:

    > Tim Rentsch wrote:
    >
    > <snip>
    >
    >> This complaint is silly. "Implicit" is a perfectly good English
    >> word, and anyone who is familiar enough with English to know what
    >> "implicit" means understands what the phrase "implicit cast" is
    >> meant to connote here.

    >
    > It connotes "implicit explicit conversion". [snip]


    Perhaps you mean it *denotes* "implicit explicit conversion".
    "Connotes" means something different. Clearly the use quoted
    (and which was snipped in your response) *connotes* something
    besides "implicit explicit conversion".
    Tim Rentsch, Jun 27, 2010
    #15
  16. sandeep

    Tim Rentsch Guest

    Keith Thompson <> writes:

    > Tim Rentsch <> writes:
    >> Richard Heathfield <> writes:
    >>> sandeep wrote:
    >>>> In C99 the new _Bool boolean data type was introduced. However this
    >>>> seems to be a token gesture! There was no attempt to integrate it
    >>>> into the standard library.
    >>>
    >>> Others have dealt with that point already, so I'm just here to pick a nit.
    >>>
    >>>> For example, functions like isdigit still return int instead of the
    >>>> new _Bool (which has implicit casts to and from int, so there would
    >>>> be no incompatability with existing code)
    >>>
    >>> Here's the nit: there is no such thing as an implicit cast. A cast is
    >>> an *explicit* conversion, by definition. If you have a copy of the C99
    >>> Standard (or at least a draft), see 6.3 Conversions.

    >>
    >> This complaint is silly. "Implicit" is a perfectly good English
    >> word, and anyone who is familiar enough with English to know what
    >> "implicit" means understands what the phrase "implicit cast" is
    >> meant to connote here. If the writing were meant as technically
    >> precise, then okay, the objection might be reasonable; but the
    >> writing is meant as English, and it is perfectly good English.

    >
    > I disagree.
    >
    > Yes, we all know that "implicit cast" really means "implicit
    > conversion"; understanding what was meant is not the point.
    >
    > The point is that the word "cast" has a very specific meaning,
    > and that meaning is specific to C, so questions of common English
    > are not quite as relevant as they might otherwise be.
    >
    > If we loosely use the word "cast" to mean any conversion, implicit
    > or explicit, then what do we call the operator consisting of a
    > parenthesized type name?
    >
    > We have two perfectly good words, "conversion" and "cast", with
    > related by quite distinct meanings. I don't want to lose that
    > useful distinction. I don't want to have to qualify every use of
    > either word with "explicit" or "implicit".


    Even allowing use of the phrase "implicit cast", I don't think you
    have to. Let me explain why.

    The word "cast" in "implicit cast" doesn't just mean 'conversion'.
    In fact C does implicit conversions in lots of different places,
    in the sense that if a cast is an explicit conversion than a
    conversion without using a cast is an implicit conversion. But
    only some implicit conversions are meant by the phrase "implicit
    cast". For example, if we have 'a + b', with variables 'a' and
    'b' both shorts, the values are converted to type int before the
    addition is done. This situation does do implicit conversion, but
    does not fall under what was meant by "implicit cast" in the
    original posting. In particular, an "implicit cast" is meant to
    cover those cases where an inter-type (or inter-type-category?)
    conversion is allowed in assignment-like contexts. This subset
    is an important subset to identify, because it corresponds to
    situations where "something surprising" happens. (Obviously
    how "surprising" it is depends on the person, but I think you
    can see what I mean.)

    Other languages sometimes use the word "coercion" in connection
    with this sort of implicitly-supplied conversion. Unfortunately
    other languages use "coercion" to mean something very different,
    so it isn't a good term to use in general. The problem is, C
    has no term (in the sense that the Standard doesn't employ any
    sort of term) to describe this situation, viz., where one type
    is assignable to another but not (always) interoperable otherwise.
    If we have 'void *pv;' and 'char *pc;', then 'pc = pv;' is allowed,
    but 'pc - pv' is not allowed, as one example. Because there is
    no Standard-sanctioned term for this kind of important case,
    people pick a phrasing that they think expresses their meaning.
    Under the circumstances, using the phrase "implicit cast" is
    natural, and IMO better than many of the alternatives.


    > This isn't to imply that anyone who uses the phrase "implicit
    > cast" is stupid or evil. It's a common mistake, and a perfectly
    > understandable one. But it is, in my opinion, a mistake, and one
    > worth correcting.


    I wouldn't call using "implicit cast" as an English phrase a
    mistake, because I don't think it's 'wrong'. Of course it's
    not technically accurate use of jargon. It isn't meant to
    be. If there is confusion on that point, that confusion
    might be worth pointing out, ie, if someone thinks 'implicit
    cast' has a well-defined meaning under C Standard terminology,
    that misunderstanding may deserve some comment. But if used
    as a phrase in ordinary English, I don't think it should be
    called "wrong", even if does make some of the more literal-minded
    readers grit their teeth.

    So here is my challenge to c.l.c readers (or at least those
    following this thread): Don't like the phrase "implicit cast"?
    Suggest a better one. Remember, we're looking for a term that
    applies not to all cases where a conversion is implied by the
    semantics, but only to cases such as assignment-like contexts
    (and if you want you can say exactly which contexts fall into that
    category). I'm happy to recommend another term be used, if
    someone can come up with something that's clearly better.
    Tim Rentsch, Jun 27, 2010
    #16
  17. sandeep

    Tim Rentsch Guest

    Paul N <> writes:

    > On 26 June, 14:49, Tim Rentsch <> wrote:
    >> Richard Heathfield <> writes:
    >> > sandeep wrote:
    >> >> In C99 the new _Bool boolean data type was introduced. However this
    >> >> seems to be a token gesture! There was no attempt to integrate it
    >> >> into the standard library.

    >>
    >> > Others have dealt with that point already, so I'm just here to pick a nit.

    >>
    >> >> For example, functions like isdigit still return int instead of the
    >> >> new _Bool (which has implicit casts to and from int, so there would
    >> >> be no incompatability with existing code)

    >>
    >> > Here's the nit: there is no such thing as an implicit cast. A cast is
    >> > an *explicit* conversion, by definition. If you have a copy of the C99
    >> > Standard (or at least a draft), see 6.3 Conversions.

    >>
    >> This complaint is silly. "Implicit" is a perfectly good English
    >> word, and anyone who is familiar enough with English to know what
    >> "implicit" means understands what the phrase "implicit cast" is
    >> meant to connote here. If the writing were meant as technically
    >> precise, then okay, the objection might be reasonable; but the
    >> writing is meant as English, and it is perfectly good English.

    >
    > Erm, I beg to differ. I don't see how the sentence can make sense
    > under any reasonable definition of "implicit". You have to adjust the
    > meaning of "cast" to include "conversion", which is a bit of a stretch
    > for a technical term.


    Sorry, I don't understand the last point. Certainly a 'cast'
    operation includes a conversion (assuming it's to a different
    type than the to-be-casted expression). What are you saying here?
    In any event I have explained the phrase "implicit cast" at
    some length in another response.

    > And as Richard said, it is only a nit. [snip]


    I understand it bothers some people. I just don't think
    it's wrong to use as a phrase in ordinary English. The
    word "nit" implies some sort of technical quibble, but
    I think it also implies some degree of objective fact.
    In the case here I believe that objective fact is lacking;
    what's being offered is just personal opinion, but
    dressed up as some sort of technically verifiable objection.
    It's my opinion that there are no grounds here for such
    an objection, because the phrase wasn't presented as
    technically literal writing.
    Tim Rentsch, Jun 27, 2010
    #17
  18. sandeep

    Tim Rentsch Guest

    Richard Heathfield <> writes:

    > Tim Rentsch wrote:
    >> Richard Heathfield <> writes:
    >>
    >>> Tim Rentsch wrote:
    >>>
    >>> <snip>
    >>>
    >>>> This complaint is silly. "Implicit" is a perfectly good English
    >>>> word, and anyone who is familiar enough with English to know what
    >>>> "implicit" means understands what the phrase "implicit cast" is
    >>>> meant to connote here.
    >>> It connotes "implicit explicit conversion". [snip]

    >>
    >> Perhaps you mean it *denotes* "implicit explicit conversion".
    >> "Connotes" means something different. Clearly the use quoted
    >> (and which was snipped in your response) *connotes* something
    >> besides "implicit explicit conversion".

    >
    > I accept the correction on "connote", but I'd love to hear what you
    > think "implicit cast" "connotes".


    I wrote on this in my response to Keith Thompson's posting.
    Tim Rentsch, Jun 27, 2010
    #18
  19. sandeep

    Tim Rentsch Guest

    pete <> writes:

    > Tim Rentsch wrote:
    >
    >> This complaint is silly. "Implicit" is a perfectly good English
    >> word, and anyone who is familiar enough with English to know what
    >> "implicit" means understands what the phrase "implicit cast" is
    >> meant to connote here.
    >> If the writing were meant as technically
    >> precise, then okay, the objection might be reasonable; but the
    >> writing is meant as English, and it is perfectly good English.

    >
    > Er..., um, No.
    >
    > Everybody who knows English, knows what "implicit" means.
    >
    > The word "cast" as used in C,
    > doesn't have any other meaning except a technical one.


    Is it so hard to imagine that an English phrase could use one
    word in its ordinary English sense and use another word in its
    technical sense? I thought it was understood that 'cast' is
    used here in the sense of 'explicit conversion' (said explicit
    conversions being supplied by a 'cast operator'). I think we
    can accept 'cast' as being used in its technical sense but
    still make sense of "implicit cast" as a phrase in English.
    Do you see what I mean?
    Tim Rentsch, Jun 27, 2010
    #19
  20. Tim Rentsch <> writes:
    [...]
    > So here is my challenge to c.l.c readers (or at least those
    > following this thread): Don't like the phrase "implicit cast"?
    > Suggest a better one.


    "Conversion".

    > Remember, we're looking for a term that
    > applies not to all cases where a conversion is implied by the
    > semantics, but only to cases such as assignment-like contexts
    > (and if you want you can say exactly which contexts fall into that
    > category). I'm happy to recommend another term be used, if
    > someone can come up with something that's clearly better.


    How is that distinction useful, and how do you know that the previous
    poster intended to make that distinction?

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 27, 2010
    #20
    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. trint
    Replies:
    4
    Views:
    681
    =?ISO-8859-1?Q?G=F6ran_Andersson?=
    Sep 11, 2007
  2. Szabolcs  Nagy

    pll: who uses _Bool

    Szabolcs Nagy, Oct 27, 2007, in forum: C Programming
    Replies:
    48
    Views:
    1,460
    Charlie Gordon
    Nov 6, 2007
  3. Philipp Klaus Krause

    _Bool bitfields and cast / assignment

    Philipp Klaus Krause, Jun 14, 2010, in forum: C Programming
    Replies:
    5
    Views:
    581
    Tim Rentsch
    Jun 20, 2010
  4. joe chesak
    Replies:
    7
    Views:
    264
    (r.*n){2}
    Sep 23, 2010
  5. Mike Ballard
    Replies:
    6
    Views:
    258
    Dr.Ruud
    Nov 15, 2005
Loading...

Share This Page