c# Casting v As operator
-
For those using c#, what do you prefer? A.
SomeObject obj = (SomeObject) e;
or B.
SomeObject obj = e as SomeObject;
www.software-kinetics.co.uk Wear a hard hat it's under construction
"Note that the as operator only performs reference conversions and boxing conversions. The as operator cannot perform other conversions, such as user-defined conversions, which should instead be performed using cast expressions." Two of three C# books I have here don't mention
asat all. -
I use the (cast) only when I know 'e is always SomeObject'. Which is a rare case - think stuff like
(ThisClass)base.MemberwiseClone(). Otherwise, I preferas+ null check overis+ cast. It looks cleaner to me, and is also more performant. 'a is T' gets compiled to the same IL as '(a as T) != null', sois+ cast ends up casting twice (and last time I checked, the JIT was too dumb to optimize that)." More formally, an expression of the form, Copyexpression as type is equivalent to, Copyexpression is type ? (type)expression : (type)null " http://msdn.microsoft.com/en-us/library/cscsdfbt(v=VS.80).aspx[^]
-
" More formally, an expression of the form, Copyexpression as type is equivalent to, Copyexpression is type ? (type)expression : (type)null " http://msdn.microsoft.com/en-us/library/cscsdfbt(v=VS.80).aspx[^]
Yes that's the specification of the behavior, but not how it's implemented.
Eric Lippert wrote:
The specification is clear on this point;
as(in the non-dynamic case) is defined as a syntactic sugar foris. However, in practice the CLR provides us instructionisinst, which ironically acts likeas. Therefore we have an instruction which implements the semantics ofaspretty well, from which we can build an implementation ofis. In short, de jureisisis, andasis asisis, but de factoisisasandasisisinst.http://blogs.msdn.com/b/ericlippert/archive/2010/09/16/is-is-as-or-is-as-is.aspx[^]
-
You have better clients than we do then. You tell them, you must implement this interface in order for this to work, and bam they completely fail to implement the interface.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
That's their problem.
-
PIEBALDconsult wrote:
what are you people doing?
SomeType obj = (SomeType)BloatedUglyUnreadableFrameworkFactory.CreateObject(someXMLStringThatIHopeWorksSometimesButNeverKnowForSure);
That deserves to blow up. What do you do once you've determined that it didn't work? Don't you just throw an Exception anyway?
-
Yes that's the specification of the behavior, but not how it's implemented.
Eric Lippert wrote:
The specification is clear on this point;
as(in the non-dynamic case) is defined as a syntactic sugar foris. However, in practice the CLR provides us instructionisinst, which ironically acts likeas. Therefore we have an instruction which implements the semantics ofaspretty well, from which we can build an implementation ofis. In short, de jureisisis, andasis asisis, but de factoisisasandasisisinst.http://blogs.msdn.com/b/ericlippert/archive/2010/09/16/is-is-as-or-is-as-is.aspx[^]
I'll code to the spec and assume hope they'll fix the implementation.
-
For those using c#, what do you prefer? A.
SomeObject obj = (SomeObject) e;
or B.
SomeObject obj = e as SomeObject;
www.software-kinetics.co.uk Wear a hard hat it's under construction
b. it's better, because if the cast is wrong, the member would be null ... so you don't have to surround your code with a "try {} catch {}" every few lines. :)
-
For those using c#, what do you prefer? A.
SomeObject obj = (SomeObject) e;
or B.
SomeObject obj = e as SomeObject;
www.software-kinetics.co.uk Wear a hard hat it's under construction
For reference Type, should have to use 'As' operator because of if casting is not compatible with target Object then it return null while 'Casting' throws an exception. For Value Type,'As' operator doesnot work.
-
For those using c#, what do you prefer? A.
SomeObject obj = (SomeObject) e;
or B.
SomeObject obj = e as SomeObject;
www.software-kinetics.co.uk Wear a hard hat it's under construction
-
For those using c#, what do you prefer? A.
SomeObject obj = (SomeObject) e;
or B.
SomeObject obj = e as SomeObject;
www.software-kinetics.co.uk Wear a hard hat it's under construction
I guess this wasn't a serious question, but just in case somebody who doesn't know looks in, I prefer b as it won't throw an exception if the conversion is not possible, but rather will return a null. According to MSDN[^] it's equivalent to this:
expression is type ? (type)expression : (type)nullbutexpressionis only evaluated once. -
I guess this wasn't a serious question, but just in case somebody who doesn't know looks in, I prefer b as it won't throw an exception if the conversion is not possible, but rather will return a null. According to MSDN[^] it's equivalent to this:
expression is type ? (type)expression : (type)nullbutexpressionis only evaluated once.I suppose my argument on that, is the programmer should know if conversion will take place or not, than letting the code take control.
www.software-kinetics.co.uk Wear a hard hat it's under construction
-
Splitting hairs :)
www.software-kinetics.co.uk Wear a hard hat it's under construction
Not really, C style casts are not recommended in C++ last I checked. Its preferred to use the C++ casts
dynamic_cast<T>(x),static_cast<T>(x),reinterpret_Cast<T>(x)andconst_cast<T>(x)as they make the intention more explicit. See : Stroustrup[^] -
Not really, C style casts are not recommended in C++ last I checked. Its preferred to use the C++ casts
dynamic_cast<T>(x),static_cast<T>(x),reinterpret_Cast<T>(x)andconst_cast<T>(x)as they make the intention more explicit. See : Stroustrup[^]The final years of coding MFC, I was using the xxx_cast operators religously.
www.software-kinetics.co.uk Wear a hard hat it's under construction
-
I prefer
asbecause it is safer:expression as type
is equivalent to:
expression is type ? (type)expression : (type)null
When you use casting you can get
StoopidTypeException.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
I fail to see why that is safer. In case (a), an exception can be raised if expression is of the wrong type. That seems entirely appropriate. In case (b), if an expression of the wrong type is supplied, the result is null. If a programmer fails to check this, the result is an exception anyway. There's a place for both of them. I generally prefer errors to generate exceptions early - i.e. at the cast, rather than the point of usage. So, if I really expect the result to be of a given type I use the former. If I'm using the cast as a shorthand for checking the type is OK, then casting, I prefer the latter.
-
I'll code to the spec and assume hope they'll fix the implementation.
There is always a difference between spec and implementation. A language spec is designed to specify what an implementer must achieve - how they achieve it is up to them. For example, nothing in the C++ spec specifies vtables are required to implement virtual functions. The vast majority of compilers implement them that way, but a vendor is free to do things some other way.
-
Wrong - a is C-style casting, not C++
No the first is compile time and the second is run time. 'as' keyword is used to RTTI
-
It depends. (A) will throw if the cast fails while (B) will evaluate to
nullif the cast fails. I use both depending on how I intend to handle the casting failure. /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
There's a little more than that. See here: what-s-the-difference-between-as-and-cast-operators[^]
Eusebiu
-
For those using c#, what do you prefer? A.
SomeObject obj = (SomeObject) e;
or B.
SomeObject obj = e as SomeObject;
www.software-kinetics.co.uk Wear a hard hat it's under construction
'B' is better, Because use of 'as' operator does not throw exception if casting is not successful where as 'A' will throw exception in case casting fails.
-
For those using c#, what do you prefer? A.
SomeObject obj = (SomeObject) e;
or B.
SomeObject obj = e as SomeObject;
www.software-kinetics.co.uk Wear a hard hat it's under construction
Often I see the 'as' keyword misused in a way that it hides the cause of a
NullReferenceException. For example, take a look at this crummy code:((foo as (Light)).SwitchOn(); // bad
If
foois not aLight, then aNullReferenceExceptionis raised. But iffoowasnullto begin with, then aNullReferenceExceptionis also raised. In either case, we can’t be certain if it is one or the other. When the ‘as’ is replaced by a direct cast, anInvalidCastExceptionis raised whenfoois not aLight; allowing us to distinguish between the two situations:((Light)foo).SwitchOn(); // better
Sometimes, therefore, the choice to use 'as' or a direct cast isn’t a choice at all.
Daniel Vaughan Twitter | Blog | Microsoft MVP | Projects: Calcium SDK, Clog | LinkedIn
-
For those using c#, what do you prefer? A.
SomeObject obj = (SomeObject) e;
or B.
SomeObject obj = e as SomeObject;
www.software-kinetics.co.uk Wear a hard hat it's under construction
I use this :
if(e is SomeObject)
{
SomeObject obj = (SomeObject)e;
}