casting vs creating an instance

[Jon Skeet [C# MVP]]

Analysis ought to show that the return value is unused and optimize away the
cast.  The function itself can't be optimized away because you've specified
NoInlining, of course, and I guess that prevents the JIT from inspecting it
for side effects and removing it, but there's no such barrier to eliminating
storage of the return value, is there?

True, true. I did at one point use the value, but removed it to keep
things simpler.

Would you expect a simple nullity test to be enough to prohibit that?

(Of course the return value *is* used when there's a cast, because the
cast might fail.)

Jon

 

[Ben Voigt [C++ MVP]]

True, true. I did at one point use the value, but removed it to keep
things simpler.

Would you expect a simple nullity test to be enough to prohibit that?

(Of course the return value *is* used when there's a cast, because the
cast might fail.)

Good point. I guess whether you think the compiler needs to preserve that
depends on whether you see the InvalidCastException as error recovery or
general-purpose flow control. So ultimately it is a side-effect which is
part of the public contract and the compiler can't remove it.

 

[Jon Skeet [C# MVP]]

Good point. I guess whether you think the compiler needs to preserve that
depends on whether you see the InvalidCastException as error recovery or
general-purpose flow control. So ultimately it is a side-effect which is
part of the public contract and the compiler can't remove it.

Yes, I think it's sufficiently well-defined that it can't be removed.

However, the storage *could* be removed for the non-casting version,
which is what I thought you were originally referring to