Sign up ×

The question came up in a discussion at StackOverflow.

Is there a clean distinction between the two concepts cast and convert (concerning the type of an object), or are these two words describing exactly the same? How about languages other than C++, Python and Java? EDIT: What if the types in question are primitive types, like int to float?

share|improve this question

3 Answers 3

up vote 4 down vote accepted

Theoretically speaking, the two concepts are vastly different:

Type Casting refers to exchanging one type (roughly speaking, an object structure) for another while Type Conversion refers to translating of values (roughly speaking, contents of the object), so that they may be interpreted as belonging to a new type. Theoretically, they never mix.

That said, practically speaking, while you can have one without another, it's, almost always, a bad idea. It rarely makes sense to change your perception of an objects' structure, without also altering its contents. Practically, they're almost always the same

share|improve this answer
This gets even more fun with a weakly typed language, like C, you can simply refer to a section of memory as a different type! – Sheldon Warkentin Feb 2 '12 at 23:18
That's not how the terms "cast" and "conversion" are used in C. See my answer. – Keith Thompson Feb 3 '12 at 0:31
I have edited the question. Do you have any thoughts about that? Thanks! – krlmlr Feb 3 '12 at 23:25
The answer doesn't change for primitives. – blueberryfields Feb 4 '12 at 16:24

Different languages define the words "cast" and "convert" differently; I don't think the question is meaningful other than in reference to a particular language.

In C, for example, the term "cast" properly refers only to an explicit cast operator, consisting of a type name in parentheses preceding the expression to be converted. A "conversion" converts a value of one type to a value of another type; some conversions are implemented by re-interpreting the bits that make up the representation, but it's defined as a value-to-value conversion. (Yes, that's true even for pointer conversions; it's possible for different pointer types to have different representations.)

Note that there is no such thing as an "implicit cast" in C.

Some conversions are explicit, specified by a cast operator. Others are implicit, and are applied in certain cases when an expression of one type is used in a context that needs an expression of a different type. The conversion performed is exactly the same in either case.

For example:

double x = 1.23;
int y = (int)x;  /* A cast, or explicit conversion, setting y to 1 */
int z = x;       /* An implicit conversion, setting z to 1. */

C++ is similar; it has the same casts and conversions as C, and it adds a functional notation equivalent to a C-style cast expression, plus 4 more specific keywords: const_cast, dynamic_cast, reinterpret_cast, and static_cast.

share|improve this answer
Am I the only person who dislikes casting as a means of converting floating-point numbers to integer types, or larger integer types to smaller ones? To my mind, casting should be appropriate for situations where a language designer could only choose one plausible behavior, and other means of conversion should be used when different behaviors would make sense in different contexts. For example, one could argue that a language should make (int)1.5-2*(int)(-1.5) yield 3, 4, 5, or 6, but if (int) had been replaced with truncInt, roundPeriodicInt, floorInt, or roundEvenInt,... – supercat Jan 28 '14 at 16:48
...there would be no ambiguity. Likewise, when casting a longer integer type to a shorter one, there are cases where numbers that don't fit the smaller type are expected and should wrap, and there are cases where such numbers are unexpected and should trigger an exception. Different languages have different behaviors with such casts, so it's hardly self-evidence which behavior a cast should have. Unless a language has both wrapping and non-wrapping integer types (a good design concept, IMHO, though I don't know any that do), specifying whether wrapping is expected would seem helpful. – supercat Jan 28 '14 at 17:05
@supercat: At least in C, a cast always specifies the same kind of conversion that would be performed implicitly by an assignment to an object of the same type -- if it's one of the conversions (mostly ones between arithmetic types) that can be done implicitly. Other kinds of conversions, e.g., specifying the kind of rounding/truncation for floating-point, can be done via function calls. – Keith Thompson Jan 28 '14 at 19:41
Certainly functions can be used; my point is that I think functions or members should be regarded as the proper means of performing conversions whose results might not represent the original values. I know C allows implicit float-to-integer conversions, and compatibility dictates it will probably always have to do so, but that doesn't mean it should. Pascal requires a call to Round or Trunc--IMHO a much cleaner design. – supercat Jan 28 '14 at 20:46

While casting, you read the instance of one class as if it is the instance of another class. It could be appliccable for this pair of classes or not. No runtime work except checking. Often the possible incompatibility could be caught on compiling stage.

While converting, you recombine or recount fields of an instance of one class into an instance of another class. If there is a function for it, it could be applicable or not for this very instance. All the work is done during runtime. No error could be checked while compiling.

share|improve this answer
That sounds language-specific. What language are you referring to? – Keith Thompson Feb 3 '12 at 0:31
Java, C++, C#, Pascal/Delphi. – Gangnus Feb 3 '12 at 0:48
C++ uses the terms "cast" and "conversion" in the same way as the C standard, with the addition of some specialized cast keywords; see my answer. – Keith Thompson Feb 3 '12 at 1:23

Your Answer


