Convert double to fixed point integer format - hard way versus easy way...
-
As it's C++, define a macro. :-D
Macros are not considered "best practice". I use them where I feel it is warranted. This is not one of those cases. A static inline function will be indistinguishable from a macro in terms of the code generated by any decent compiler and is generally preferred.
-
Macros are not considered "best practice". I use them where I feel it is warranted. This is not one of those cases. A static inline function will be indistinguishable from a macro in terms of the code generated by any decent compiler and is generally preferred.
geoffs wrote:
A static inline function will be indistinguishable from a macro in terms of the code generated
Not necessarily true. A macro will always be expanded by the preprocessor, and the code compiled as is. An inline function will only be inlined if the compiler thinks it's a good idea (for example it might be if you are optimising for speed, it may not be if you are optimising for size). Don't forget
inlineis a request to the compiler, not a command. It can leave the code as a function if it wants to. A macro forces the issue - a function leaves it to the compiler to decide. -
geoffs wrote:
A static inline function will be indistinguishable from a macro in terms of the code generated
Not necessarily true. A macro will always be expanded by the preprocessor, and the code compiled as is. An inline function will only be inlined if the compiler thinks it's a good idea (for example it might be if you are optimising for speed, it may not be if you are optimising for size). Don't forget
inlineis a request to the compiler, not a command. It can leave the code as a function if it wants to. A macro forces the issue - a function leaves it to the compiler to decide.Although this is getting away from the original intent of my posting, you are correct that inline is merely a request to the compiler. For all intensive purposes, in most cases, a simple function as shown will be inlined by the compiler. There will be exceptions to that case.
-
Although this is getting away from the original intent of my posting, you are correct that inline is merely a request to the compiler. For all intensive purposes, in most cases, a simple function as shown will be inlined by the compiler. There will be exceptions to that case.
That's why I put the smiley.
geoffs wrote:
intensive purposes
intents and purposes
-
That's why I put the smiley.
geoffs wrote:
intensive purposes
intents and purposes
-
As it's C++, define a macro. :-D
"As it's C++, define a macro." That's a horror in itself. C++ provides inline functions that would do the same job much better. Indeed, the potential pitfalls of the C preprocessor are one of the main motivations for this feature.
-
"As it's C++, define a macro." That's a horror in itself. C++ provides inline functions that would do the same job much better. Indeed, the potential pitfalls of the C preprocessor are one of the main motivations for this feature.
The language provides that feature?
-
Macros are not considered "best practice". I use them where I feel it is warranted. This is not one of those cases. A static inline function will be indistinguishable from a macro in terms of the code generated by any decent compiler and is generally preferred.
-
I was delving into code for other modifications and came upon some previous programmer's apparent confusion... Supposing you had a value in double (c++) format and wanted to convert it to a 20.12 fixed point format contained in a 32-bit value. The source value was guaranteed to also not be larger than what the 20 bit integer portion could represent. How would you go about implementing this conversion? Think about it. Meanwhile, here's the code I found (suitably cleansed of any incriminating information):
uint32 ConvertDoubleToFixedPoint32_12(double temp)
{
uint32 whole;
double getFrac;
uint32 fraction;whole = (uint32)temp;
// get the fractional part
// put the whole number in a double
getFrac = (double) whole;// take the whole from the original to get the fraction
//4096 12-bits shift for the decimal
fraction = (uint32)((temp - getFrac) * 4096);//shift up whole number to for the format, make room for the faction
whole = whole << 12;
whole |= fraction;return whole;
}Got that? :wtf: How would you have done that same conversion? Scroll down to see an alternative...
static inline uint32 ConvertDoubleToFixedPoint32_12(double temp)
{
return (static_cast<uint32>(temp * 4096));
}Sigh...
-
Depends on what you mean by a "normal" cast... 1. If you mean a C-style cast (ie: (uint32) <something> ), then my answer would be that the code is C++ and the correct thing to do is to use the new style casts provided by the C++ language. They are there for a good reason. 2. If you mean, why did I not just allow implicit casting to uint32 by the compiler, it's because assigning a double value to an unsigned long produces a warning message ('possible loss of data') depending on the warning level set for the compilation. Since I compile at the higher warning levels and will see the warning, and have a policy of not allowing warnings from my code, I do the explicit cast. The issues I touched on above are very well described and explained at this site: C++ FAQ Lite. This is a great site for beginners and seasoned c++ programmers.