Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Consider the following code:

DerivedClass drbObj = (DerivedClass)obj;

Here obj is of type Object and this is reasonable since Object is the base type of every Class in C#.

Here, since the type of derObj is defined at compile time, what is the need to explicitly use type conversion here. Can't the compiler predict on it's own that it will be of DerivedClass. I understand that, the Conversion type doesn't have to match the Derived type, but for practical purpose, it will only be as useful as the Derived type.

Could someone explain with a small, hypothetical example, as to why the Explicit Type Conversion is necessary when a reference of type Object is being assigned to a derived class.

From what I know, in C, there is no need to do perform Explicit type conversion from void* to any pointer and the compiler can handle it, based on the type of the pointer to which the converted value is being assigned.

share|improve this question
1  
Trying DerivedClass drbObj = (DerivedClass)obj; where class DerivedClass : Object was an InvalidCastException however DerivedClass drgObj = obj as DerivedClass; worked just fine. That may just be nit-picking though :) –  Dylan Yaga Oct 27 '11 at 11:52
1  
@DylanYaga, using (SomeType)x and x as SomeType are two very different constructs in C# (don't know about other languages). The first is an assertion (you're willing to deal with the exception if the types are incompatible), the second is an attempt (and yields null if the types are incompatible). –  Michael Kjörling Oct 27 '11 at 12:24
    
@MichaelKjörling Always learning, thank you :) This may also help Direct casting vs 'as' operator? –  Dylan Yaga Oct 27 '11 at 12:45
    
C is 30-something years older than C#. C has "weak typing" and allows/performs a lot of implicit conversions. This is one of the major flaws of the C language. –  user29079 Oct 27 '11 at 13:50
add comment

2 Answers 2

up vote 7 down vote accepted

The reason why you have to do this is pretty simple:

Because that's the way the language was designed.

While yes, the C# designers could have decided to infer that your intent was to cast obj based solely on your declaration, they chose not to do so, probably because such an inference would cause more problems than it solved.

I can think of two reasons why they might have chosen not to infer the cast to DerivedObj:

1) Because it's inconsistent. Though for assignment (as in your example) it may seem logical to perform the inference, there are a ton of situations you would need to perform the cast explicitly, and making the casting behavior consistent makes the language conceptually simpler. For example, let's say you were writing a piece of code that needed to set the obj's ID to 5, knowing ahead of time that it was a DerivedObj. You'd still have to do the cast:

((DerivedObj)obj).ID = 5;

2) Because it's dangerous. Performing the cast at assignment is an "are you sure?" kind of check which makes you think twice about what the object really is before assigning. I would say that's a feature of the language, and definitely not worth a special-case casting behavior just for assignment. In fact, if you really created obj by saying obj = new object() somewhere, the cast will fail anyway.

share|improve this answer
add comment

Can't the compiler predict on it's own that it will be of DerivedClass.

No? How on earth would it predict that? You want it to solve the Halting problem? Objects may be useless (and a shitty, shitty design) but there are millions of classes derived from Object. How would the compiler know which one to pick?

The reason the cast is necessary is because it could fail at run-time, and the compiler wants to know that you're sure. Explicit casting is much safer than implicit casting.

From what I know, in C, there is no need to do perform Explicit type conversion from void* to any pointer and the compiler can handle it, based on the type of the pointer to which the converted value is being assigned.

That's a bad thing, not a good thing, and conversion != casting. Casts are bad. Try not to use them.

share|improve this answer
9  
"Casts are bad??" That's the first time I've ever heard someone say that. –  Dave Markle Oct 27 '11 at 11:48
1  
@DaveMarkle: Then you obviously don't listen to the right people. Casts should be used with the same caution as gotos. –  back2dos Oct 27 '11 at 12:16
1  
The type system is safe. Casting subverts that safety. –  DeadMG Oct 27 '11 at 12:48
1  
"Cannot convert const int* to int* ? Bah, eat typecast, stupid compiler!" In that context, casts are bad. Otherwise they are usually good, especially when you are trying to avoid the very subtle yet common bugs caused by C/C++ implicit integer promotion and balancing. –  user29079 Oct 27 '11 at 13:46
1  
I'll concede that a design that requires a heavy use of casting is bad. But I won't concede that casts themselves are bad, or that a programmer who uses them is doing something bad. For example, if you read from a weakly-typed DataTable in .NET into certain variables, you'll likely be using casts a lot -and that's fine- even though the design which caused you to use those casts in the first place might not be the best. –  Dave Markle Oct 27 '11 at 14:16
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.