   Type Casting
  Type casting is generally bad and what not from I've been told, but whenever I see people using casting in tutorials and such they *usually* use float_variable=(float)integer_variable;...but just in my opinionfloat_variable=float(integer_variable);Looks better, so is there any actual overhead difference or does this not matter at all? Usually when most people choose the same thing it has some underlying reasoning.   
  No difference other than aesthetic appeal, which will obviously be different depending on who you ask. I tend to use the C-style casts because they are more common and widely used. See no reason to use the function-style casts.   ;  Technically, the first one tells the compiler "treat this int as float and assign it", and the second one tells the compiler "create a temporary float object using the integer constructor and copy it".In practice, the output should be 100% identical on any decent compiler, since it is allowed to optimize out the temporary object (and hopefully will, too).   ;  The former is more conventional and widely used which is as good a reason as any to continue using it, in my opinion.Of course, in C++, I use C++-style casts (including numeric_cast).   ;Quote:Original post by samothTechnically, the first one tells the compiler "treat this int as float and assign it", and the second one tells the compiler "create a temporary float object using the integer constructor and copy it".The two are technically identical. In the case of primitives, both casting forms have identical behavior. In the case of user-defined types, both construct temporary objects.   ;  Ok, it's good to see that I won't see any tangible negative effects. Thank you.   ;  The main reason for using parenthesis with the type are pointer types:(BITMAP *) bmpIf you try the following:BITMAP *(bmp)this is what the compiler will try to do:BITMAP (*bmp)Now do you see why everybody uses the former?   ;Quote:Original post by Sik_the_hedgehogIf you try the following:BITMAP *(bmp)this is what the compiler will try to do:BITMAP (*bmp)I don't think that's true. If the compiler were to interpret the parentheses as delimiting a parenthesized expression, rather than as part of a cast-expression, the result would be a typename followed by an expression, which is not legal. So even if BITMAP did have a constructor which took a pointer to whatever-bmp-is, it would fail to compile.   ;Quote:Original post by wioneoType casting is generally bad and what not from I've been told, but whenever I see people using casting in tutorials and such they *usually* use float_variable=(float)integer_variable;...but just in my opinionfloat_variable=float(integer_variable);Looks better, so is there any actual overhead difference or does this not matter at all? Usually when most people choose the same thing it has some underlying reasoning.why not just use float_variable = static_cast<float>(integer_variable);   ;Quote:Original post by SneftelQuote:Original post by Sik_the_hedgehogIf you try the following:BITMAP *(bmp)this is what the compiler will try to do:BITMAP (*bmp)I don't think that's true. If the compiler were to interpret the parentheses as delimiting a parenthesized expression, rather than as part of a cast-expression, the result would be a typename followed by an expression, which is not legal. So even if BITMAP did have a constructor which took a pointer to whatever-bmp-is, it would fail to compile.It's legal to do int(blah) even in C (or at least GCC allows it, I tried it before). It looks like the compiler just takes into account the parenthesis for token grouping, not for casting. You know, maybe I should check if it isn't just a GCC extension...I know this is an issue with function pointers. Basically:void *ptr()isn't the same as(void *)ptr()The reason is that the compiler will attach the * to the token at the right, not the one at the left. The explanation I gave about pointer casting follows the same logic, with the compiler attaching the * to the wrong token.EDIT: I just checked the C reference doc I have (n1256.pdf, Committee Draft, September 7 2007), it looks like it doesn't document the type (expression) form at all, only the (type) expression one. I may have missed something, but it looks like the former shouldn't be legal at all...EDIT 2: more specifically:Quote:cast-expression: unary-expresion ( type-name ) cast-expression