C# – The Need for Explicit Type Conversion

cexplicittype conversion

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.

Best Answer

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.

Related Solutions

Programming Interfaces – Implicit vs Explicit Interfaces

You've already defined the important point- one is run-time and the other is compile-time. The real information you need is the ramifications of this choice.

Compiletime:

Pro: Compile-time interfaces are much more granular than run-time ones. By that, what I mean is that you can use only the requirements of a single function, or a set of functions, as you call them. You don't have to always do the whole interface. The requirements are only and exactly what you need.
Pro: Techniques like CRTP mean that you can use implicit interfaces to default implementations of things like operators. You could never do such a thing with run-time inheritance.
Pro: Implicit interfaces are much easier to compose and multiply "inherit" than run-time interfaces, and don't impose any kind of binary restrictions- for example, POD classes can use implicit interfaces. There's no need for virtual inheritance or other shenanigans with implicit interfaces- a big advantage.
Pro: The compiler can do way more optimizations for compile-time interfaces. In addition, the extra type safety makes for safer code.
Pro: It's impossible to do value typing for run-time interfaces, because you don't know the size or alignment of the final object. This means that any case which needs/benefits from value typing gains big benefits from templates.
Con: Templates are a bitch to compile and use, and they can be fiddly porting between compilers
Con: Templates cannot be loaded at run-time (obviously), so they have limits in expressing dynamic data structures, for example.

Runtime:

Pro: The final type doesn't have to be decided until run-time. This means that run-time inheritance can express some data structures much easier, if templates can do it at all. Also you can export run-time polymorphic types across C boundaries, for example, COM.
Pro: It's much easier to specify and implement run-time inheritance, and you won't really get any compiler-specific behaviour.
Con: Run-time inheritance can be slower than compile-time inheritane.
Con: Run-time inheritance loses type information.
Con: Run-time inheritance is way less flexible.
Con: Multiple inheritance is a bitch.

Given the relative list, if you do not need a specific advantage of run-time inheritance, do not use it. It is slower, less flexible, and less safe than templates.

Edit: It's worth noting that in C++ particularly there are uses for inheritance other than run-time polymorphism. For example, you can inherit typedefs, or use it for type tagging, or use the CRTP. Ultimately, though, these techniques (and others) really fall under "Compile-time", even though they are implemented using class X : public Y.

Java/C# – Why Can’t Implement RAII?

Such a language extension would be significantly more complicated and invasive than you seem to think. You can't just add

if the life-time of a variable of a stack-bound type ends, call Dispose on the object it refers to

to the relevant section of the language spec and be done. I'll ignore the problem of temporary values (new Resource().doSomething()) which can be solved by slightly more general wording, this is not the most serious issue. For example, this code would be broken (and this sort of thing probably becomes impossible to do in general):

File openSavegame(string id) {
    string path = ... id ...;
    File f = new File(path);
    // do something, perhaps logging
    return f;
} // f goes out of scope, caller receives a closed file

Now you need user-defined copy constructors (or move constructors) and start invoking them everywhere. Not only does this carry performance implications, it also makes these things effectively value types, whereas almost all other objects are reference types. In Java's case, this is a radical deviation from how objects work. In C# less so (already has structs, but no user-defined copy constructors for them AFAIK), but it still makes these RAII objects more special. Alternatively, a limited version of linear types (cf. Rust) may also solve the problem, at the cost of prohibiting aliasing including parameter passing (unless you want to introduce even more complexity by adopting Rust-like borrowed references and a borrow checker).

It can be done technically, but you end up with a category of things which are very different from everything else in the language. This is almost always a bad idea, with consequences for implementers (more edge cases, more time/cost in every department) and users (more concepts to learn, more possibility of bugs). It's not worth the added convenience.

Best Answer

Related Solutions

Programming Interfaces – Implicit vs Explicit Interfaces

Java/C# – Why Can’t Implement RAII?

Related Topic