casting vs creating an instance

  • Thread starter Thread starter Yankee Imperialist Dog
  • Start date Start date
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?
Click to expand...

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
 
Jon said:
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.)
Click to expand...

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.
 
Ben Voigt said:
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.
Click to expand...

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 :)
 
Back
Top