B
Ben Bacarisse
Eric Sosman said:
long long is used as both. For example llabs and lldiv.
long long is used as both. For example llabs and lldiv.
T
Tim Rentsch
pete said:
The usage in "implicit cast" isn't incorrect. It may not
follow the rules of usage that you prefer, but that doesn't
make it incorrect. I don't have any problem with someone
saying the phrase is technically imprecise; I just don't
think it's fair to say it's outright wrong.
T
Tim Rentsch
Keith Thompson said:
That covers more ground than I attribute to "implicit cast". If
we use "conversion" for both sets of cases, often it will be hard
to tell which sense of "conversion" is meant.
Here is a list (probably partial) of conversions that are done
without needing a cast operator:
lvalue to value
array to pointer-to-first-element
function to pointer-to-function (plus implied * when calling)
RHS value on assignment to LHS type (usual cases, see below)
argument to parameter (for prototyped functions)
argument to parameter (for non-prototyped functions)
return expressions to function result type
promotion of integer operands to 'int' or greater
usual arithmetic conversions
some special cases (eg, ?:, some cases of assignment)
controlling expressions in 'if', etc.
To me, only some of these cases fall under the heading of "implicit
cast". For example, the lvalue-to-value conversion: there isn't even
any way of /writing/ this conversion using a cast operator -- hence I
wouldn't expect it to be included if someone said "implicit cast".
To answer your question more directly, I think it's useful in
"chunking" the different kinds of "invisible" conversions that C has,
and in talking about those conversions, to have a short convenient
phrase that is limited to "assignment-like" cases: namely, certainly
assignment and argument-to-parameter for prototyped functions, and
return expressions, and controlling expressions; maybe also integer
promotions and argument-to-parameter for non-prototyped functions;
almost certainly not lvalue-to-value, array to pointer, or function to
function pointer; probably not the usual arithmetic conversions; and
I'll just say unsure on the others. I believe there's a natural
division of the different kinds of "invisible" conversions that C
supplies, both as beginners understand C and as (some) more expert
C'ers understand C, and it's useful to identify one subset or the
other. The dividing line may not be sharply defined, but it's
still useful to be able to distinguish the two sides easily. A
phrase like "implicit cast" (or perhaps another phrase) could do
that.
I don't know, specifically, which distinction may have been
intended, or indeed if there was any conscious thought on
the matter. However, reading over what was said, I believe
that not all cases of "invisible" conversions would fall
under the "implicit cast" label. For example, assigning an
int to an int, the RHS (which is an int) is converted to int
(the type of the LHS); there is an "invisible" conversion,
but I expect very few people (even those who don't mind the
phrase generally) would say there's an "implicit cast" in such
cases.
E
Eric Sosman
Is this the same person who recently took me to task for
describing one integer type as "narrower" than another?
I
Ian Collins
But it is an oxymoron. A cast requires an intervention on the part of
the programmer.
"Conversion", or if you wish to replace an oxymoron with a tautology:
"Implicit Conversion"
K
Keith Thompson
[...]Tim Rentsch said:
Yes, it is.
The word "cast" has a very specific meaning. It refers to an
operator consisting of a type name in parentheses.
If you want to make a distinction between different kinds of implicit
conversions, I'm prepared to convince that that might be useful.
But blurring the meaning of the well-defined word "cast" is not
the best way to do it.
And I don't believe that most people who use the term "implicit
cast" are trying to make such a distinction; they just don't know
what the word "cast" means. (This isn't an attack; the solution
is simply to tell them.)
x[y] is equivalent to *(x+y) (add extra parentheses to taste).
We might say that there's an implicit addition and dereference; we
don't talk about an implicit "+" sign and an implicit "*" operator.
K
Keith Thompson
Ian Collins said:On 06/27/10 08:11 PM, Tim Rentsch wrote: [...]
"Conversion", or if you wish to replace an oxymoron with a tautology:
"Implicit Conversion"
"Implicit Conversion" isn't a tautology; conversions can be either
implicit or explicit.
I
Ian Collins
Ian Collins said:On 06/27/10 08:11 PM, Tim Rentsch wrote: [...]
"Conversion", or if you wish to replace an oxymoron with a tautology:
"Implicit Conversion"
"Implicit Conversion" isn't a tautology; conversions can be either
implicit or explicit.
It is in context.
N
Nick Keighley
and many different variants are there? I know of one project that had
three different boolean types (and one of them had TRUE, FALSE and
MAYBE !)
<snip>
N
Nick Keighley
C should have had "bool" and "null" keywords from the beginning. And
function prototypes should have been compulsary (and no this isn't
"monday morning quarter backing", there were precedents).
N
Nick Keighley
ah, so "implicit cast" has some ambiguity... I know plenty of people
(probably including the person who first used the term "implicit cast"
in this thread) who use "cast" as a synonymn (or replacement for)
"conversion".
I was kind of on your side up till about here. If we employ Jacob's so-
called "good faith" argument (why does he always have to reduce it
personalities?) then it is clear that most people mean "implicit
conversion" when they use "implicit cast". I'll pick up on it
occaisionally but it doesn't really bother me. You (Tim Rentsch) seem
to be tryign to destroy the "good faith" argument by arguing there is
some subtle distinction. It illudes me at the moment.
really? How do you know he meant to restrict "implicit cast" in this
way? The isn't just "good faith" but "stupendous spectacular wonderful
faith", probably comes with a tamborine and a mug of horlicks.
T
Tim Rentsch
Ian Collins said:
Yes, like the phrase "a deafening silence" (also an oxymoron),
the meaning is somewhat at odds with the literal meaning of
the individual elements. English can be like that.
I explained in a response to Keith Thompson why "conversion"
by itself seems inadequate for this purpose.
or if you wish to replace an oxymoron with a tautology:
"Implicit Conversion"
That seems worse than just plain "conversion". The set
of conversions under consideration is decidedly /less/
implicit than some other (implicit) conversions, in the
sense that they stand out more.
(By the way, the word you're looking for is probably not
"tautology" but "pleonasm".)
T
Tim Rentsch
Eric Sosman said:
It is. Ironic, ain't it?
Okay strike that. You deserve better -- let me see if I can give
a more reasoned reply.
I see two important differences between the two situations.
First, the contexts of the two comments were different. For
'"narrower"', the comments were meant to explain the rules of C.
In this kind of context, it's important to be specific (not
necessarily precise, but specific) about what factors are
relevant to the issue at hand. Using '"narrower"' fulfills this
purpose: it identifies the important property, while at the same
time making clear that it does not identify it precisely, but is
serving as a kind of shorthand for a more elaborate rule given in
the Standard. In contrast, the comments surrounding 'implicit
cast' were not an effort to explain the rules of C but were
asking a question in a discussion about C. In that kind of
conversion, it's assumed that people generally know the rules;
it isn't as important to use careful terminology because we
expect that other folks will generally understand what we're
saying. In the first kind of context, 'implicit cast' should be
put in double quotes, as '"narrower"' was; whereas, in the
second kind of context, it's okay to leave them out, because the
phrase isn't meant to reference a specific requirement in the
Standard but rather refer to a set of circumstances that (we
hope) most readers will understand based on context. More
succinctly, in the first case it's important to use terms
specifically, but in the second case it isn't.
The second difference has to do with the nature of my reponses in
the two cases. For 'implicit cast', everyone (or at least most
people) know the writer is using language in a sloppy way; it's
okay to be sloppy, because it's expected that people generally
understand what he's talking about. The situation is different
for the comments using '"narrower"'. The term '"narrower"' is
perfectly appropriate, nothing wrong with that. However, when
explaining the rules of C, I think it's important to describe
them accurately, even if not exactly precisely. My objection in
that case was not about the term used but because I thought the
explanation offered wasn't quite accurate. That's important when
explaining to an audience that doesn't yet understand; it's not
as important when talking about a subject with a group that
presumably already does understand.
Does it make more sense now what (I think) are the differences
between the two cases?
T
Tim Rentsch
Keith Thompson said:
I'll say that a different way. It's accepted under regular informal
English (even with 'cast' having its usual technical meaning). People
might object to it as being technically bogus, or technically stupid,
or whatever, and technically they're probably right; however it is
still perfectly acceptable as informal English.
Yes, if the person speaking is using words in a technically precise
way (and talking about C), I'd agree with you. Obviously different
people embrace this attitude to varying degrees (and also varying at
different times).
I'm okay with that. I wouldn't want to claim that 'implicit cast'
is the best term (or way) to reference such a subset. I understand
the term used in this way, but I'm not saying it's the best way, not
at all.
In some cases I think that's right. I don't think it's right
in all cases.
Unfortunately cast operations don't have analogous terminology to
addition/+ and dereference/*. The word 'cast' refers to both the
abstract operation and to the construction that symbolizes the
operation. Also, anticipating a possible objection, note that we
can't use just the word 'conversion' to mean the operation of
casting: because, a cast takes a type as one of its arguments. To
say this another way, in a regular (implicit) conversion, it's the
rules of the Standard that dictate the target type; whereas in a
cast, it's the cast operation itself that dictates the target type.
In a sense what we're missing is a term that means "conversion plus
choice of target type". Unfortunately the closest term for such a
thing that the Standard uses is 'cast'.
T
Tim Rentsch
Richard Heathfield said:
I'm responding just briefly here; there are comments on
other points in several other recent followups.
I think that's a foolish attitude. Obviously different
people use language in different ways and differently
at different times. There's nothing wrong with informal
English; there's also nothing wrong with formal English.
Refusing to recognize the differences between them (or
refusing to acknowledge the existence of one or the other)
is likely to alienate or antagonize people, especially
those new to C and/or new to the newsgroup.
T
Tim Rentsch
Nick Keighley said:
I do think 'implicit cast' is meant to signify a (non-explicit)
conversion, but usually I think it is not used to mean /all/ the
cases of conversions implied by Standard requirements. For example,
in 'x = y;', the subexpression 'y' is converted from an lvalue to
the value held in the variable, but most people wouldn't call
that an implicit cast (even those who use the term otherwise).
I don't know what you mean by the "good faith" argument. However I
think I should point out a difference between _meaning_ a proper
subset (of implicit conversions) and _intending to mean_ a proper
subset (of implicit conversions). I think most people who use a
term like 'implicit cast' actually mean a proper subset of all
implicit conversions, but they may not _be aware_ that the set of
conversions they're talking about is a proper subset. So I don't
think my reading of 'implicit cast' is really that different from
yours.
It's my sense of what was meant based on the writing. Obviously
I can't know what the writer was really thinking, or if he was
conscious of considering the issue at all, but it seems like
he is talking about just a subset of all implicit conversions,
and this subset looks like the most likely bet.
T
Tim Rentsch
pete said:
Please notice an important distinction: I don't mean to
say he was _intending_ to make a distinction, only that it's
likely that what he meant in his statement is actually just
a proper subset of all implied conversions. If we're
willing to read between the lines a bit often it's possible
to get a better sense of what question is really being
asked and what may be preventing their finding an answer.
If we can do that, there's a much better chance both that
an answer can be given _and_ that the questioner can be
educated about how to frame (and phrase) the question.
Often it's more of an advantage to know how to ask the
question than to find out what the answer is.
S
Seebs
It couldn't.
But one of the meta-rules of human language is that things which are clearly
meaningless are adjusted until they mean something. "implicit cast", as you
point out, is obviously incoherent. However, there's an obvious resolution;
the word expressly stated is understood to *override* qualities which would
otherwise have been there.
It's like "inedible food". "food" is pretty much by definition edible; you
could understand "food" to mean "edible material". So "inedible food" is
something like "inedible edible material". Since "inedible" was explicit,
it wins, so you end up with "inedible material", with a connotation that the
material was of a sort that you might normally expect to be edible.
An "implicit cast", then, would be an implicit (conversion which you might
otherwise expect to be explicit). Interestingly, "implicit cast" probably
has connotational differences from "implicit conversion" -- it suggests that
the conversion in question is of the sort that could be done with a cast,
as opposed to some other kind of conversion. For instance, I'd argue that
the behavior of (void *) in C is an example of an implicit conversion of a
sort which would usually be accomplished by a cast -- so if someone called
it an "implicit cast", I'd understand that.
I prefer not to do that, because I think the term "cast" means more than just
"explicit conversion", referring to the syntax rather than to the generated
code. But I think it's fairly clear how human lanugage normally resolves
that kind of contradiction. Between modern culture and the development of
language, there are plenty of examples of this.
-s
K
Keith Thompson
Tim Rentsch said:
It's accepted in the same way that "irregardless" is accepted.
The term "implicit cast" *only* applies to C, so arguments about regular
informal English don't really apply; 99% of English speakers probably
don't know what a "cast" is in this context.
You seem to be making an artificial distinction between "technically
right" and "right". I don't agree that there is such a distinction.
And if the person is using words in a technically *imprecise* (i.e.,
wrong) way, he's likely to use a phrase like "implicit cast".
So what's wrong with pointing out that "conversion" is a better and more
correct way to express the concept that was being expressed?
I think it is.
I don't even remember who used the term "implicit cast" in this
thread (and I hope he or she isn't feeling picked on now). But I
don't believe that person was making the distinction you're trying
to make, either explicitly or implicitly.
No, it does not. The word "cast" refers to an expression consisting
of an expression preceded by a parenthesized type name. The Standard
uses the term "Cast operators" in a section title, but doesn't define
it as far as I can tell; it's reasonable to assume that it refers
to the parenthesized type name that forms part of a cast expression.
The abstract operation is not a "cast"; it's a "conversion".
It's the rules of the Standard that dictate the source and target types
in both cases. It's just different rules.
Close, but not close enough. I don't see why we *need* a term for
"conversion plus choice of target type". And I'm unwilling to
give up the extremely useful existing term "cast", with its utterly
unambiguous meaning, for this concept.
Actually, we already have a term for "conversion plus choice of
target type". It's the phrase "conversion plus choice of target
type".
N
Nick
Keith Thompson said:
I think the distinction to be drawn here is /not/ between technical and
common English, but between C Standardese and technical computer talk.
No wonder it's lead to a lot of normally sensible people digging
themselves holes from which to throw things at each other.
There term "cast" exists outside C but in the world of programming
languages, to mean turning one sort of value into another.
For example, you'll get plenty of hits on a search for "cast in python",
"cast in SQL", "cast in javascript" etc.
Not all languages do it by putting a type name in brackets. And at
different times different languages need to be told to do it, or do it
automatically.
So there are things that can sensibly be called "implicit casts" and
"explicit casts". It just happens that, in the C standard, "implicit
casts" are called "conversions" and "explicit casts" are called "casts"
(I think). It's not that surprising that people who talk lots of
languages occasionally use the broader, but still technical, term rather
than the peculiar to C one.