FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	Comment on GotW #93 Solution: Auto Variables, Part 2 by Andrei Alexandrescu Thanks Herb for bringing this to my attention. Replies @Sebastian within. >This doesn't help much. The unexpected type conversion happens as part of integer_expr; all the "helper" does is afterwards cast it back. Yes, the behavior of unsigned to signed when not in range isn't undefined, just implementation-defined, but that's enough to make the code non-portable. This seems to be a misunderstanding of the intent. You use as_xxx in lieu of a cast, and eliminates committal to the width of the type without eliminating committal to the consequences of changing signedness. >> double f4 = f1 + f2; // … this might keep more bits of precision >This is incredibly obscure and would definitely not pass code review from me. If you want higher precision, cast the inputs to double. If you don't want higher resolution, assign the result to a float. Everything else is just a maintenance nightmare. Makes sense (especially for +, which would use ADDSS thus operating in single precision). My point here is that a common pattern in math code is: * use float for input due to store size restrictions * do intermediate computation in double because it costs just a little more for a big win in accuracy * get back to float when writing results to the store Due to this pattern, you want to actively cast to double early in the computation chain, sometimes as simple as double x = array[k]; If auto were used, x and computations derived from it would be float. That’s what I’m saying. Read More »
	Delievered to you by Feedamail. Unsubscribe