|
The max value of a double is well below infinity.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Computers would no longer need people if they could handle infinite numbers.
And I doubt people would need computers if we could handle them ourselves.
----------
There go my people. I must find out where they are going so I can lead them.
- Alexander Ledru-Rollin
|
|
|
|
|
The easiest way is to perform a divide by 0 with floating point exceptions disabled - 1.0 / 0.0 will do the trick. However, note that most of the math functions don't work with infinite numbers. You can disable floating point exceptions using _controlfp().
Obviously, use -1.0 / 0.0 if you want -ve infinity.
BTW, you can represent infinity with a float or a double, despite what others have said... See here[^]
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
There are some defines in float.h that might be of use: DBL_MAX, FLT_MAX, etc.
- S
50 cups of coffee and you know it's on!
|
|
|
|
|
I have a variable (CString) Username which has a username.
And a variable (Byte) m_type.
If Username starts and ends with _ (f.ex _John_)
then m_type = 0 (emploee)
Else m_type = 1 (client)
How i type these in C++ MFC code ?
|
|
|
|
|
see CString's Length and GetAt member functions.
if (str.GetAt(0)=='_') ... etc. use Length to make sure you don't try to GetAt a character that's past the end of the string.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
there is a way Getat(0) =="_" (from left)
GetAt(0)=="_" (from right) ? (so dont need to use length
|
|
|
|
|
yes, there is. it's called "Right"
but you still need to know how long the string is, because GetAt, Left, Right and Mid will all fail if you try to get characters past the end of the string.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
oh i got ur point, thanks very much 
|
|
|
|
|
Hi Can some one please explain me the following...not the MSDN defination please
STDMETHODCALLTYPE
__export
__declspec
-- modified at 14:25 Wednesday 17th May, 2006
|
|
|
|
|
koumodaki wrote: STDMETHODCALLTYPE
If you are even remotely familar with the preprocessor, this should explain it:
#ifdef _WIN32 // Win32 doesn't support __export
#define STDMETHODCALLTYPE __stdcall
#else
#define STDMETHODCALLTYPE __export __stdcall
#endif
koumodaki wrote: __export
__declspec(dllexport) allows you to export functions, data and objects.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
in the easiest way ?
Using c++.
thank you.
-- modified at 12:50 Wednesday 17th May, 2006
|
|
|
|
|
<br />
uint32_t value; <br />
int i; <br />
uint8_t *cptr = (uint8_t *)&value; <br />
<br />
<br />
<br />
<br />
<br />
for (i = 0; i < sizeof(uint32_t); i++) <br />
cptr[i] = i + 1; <br />
<br />
<br />
<br />
<br />
<br />
switch (value) { <br />
case 0x01020304: <br />
printf("32 bit int is big-endian\n"); <br />
break; <br />
<br />
<br />
case 0x04030201: <br />
printf("32 bit int is little-endian about 8 bits\n"); <br />
break; <br />
<br />
<br />
case 0x03040102: <br />
printf("32 bit int is little-endian about 16 bits\n"); <br />
break; <br />
<br />
<br />
default: <br />
printf("I don't understand the result\n"); <br />
break; <br />
} <br />
google[^]
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Hmm.. isn't detecting the endianess at runtime a bit too late? 
--
100% natural. No superstitious additives.
|
|
|
|
|
not necessarily. for example, if you're writing cross-platform code that reads a particular format of binary file, and you know the files are always written in Intel order, you can write ReadShort and ReadInt functions that will convert those data types on-the-fly to the appropriate order, for the machine running the code.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Since endianess is hardcoded for a particular platform (I don't know of any platform/CPU architecture which has a variable endianess), you can do these decisions at compile time, rather than runtime. A good side effect of handling endianess at compile time, is that you'll always get the best possible performance on systems in scenarios where endians match.
--
100% natural. No superstitious additives.
|
|
|
|
|
Jörgen Sigvardsson wrote: A good side effect of handling endianess at compile time, is that you'll always get the best possible performance on systems in scenarios where endians match.
of course.
i was just pointing out that it's possible (if not necessarily ideal) to handle it at run-time, too.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
We use MIPS cores and our reference designs have jumpers on which let you decide one endianess.
There are can be a test at startup to make sure this is set to match the code.
Elaine ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
The tigress is here
|
|
|
|
|
endian jumpers! Who would've thought!
--
100% natural. No superstitious additives.
|
|
|
|
|
There are/were some file formats that specified the endianness of the file in the header.
This allowed the file to be saved in a format that was optimal based on the type of machine that would be reading/writting the data the most.
There are also formats that use both types:
http://ccrma.stanford.edu/courses/422/projects/WaveFormat/[^]
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Yeah, but you wouldn't be testing the system itself then, just the input from the file header.
--
100% natural. No superstitious additives.
|
|
|
|
|
True, you wouldn't need to directly test your system - if you hard coded the endianness of it into your code.
If you want portable code then you will need functions such as:
SysToBig( long& ), BigToSys( long& ), SysToLittle(), ...
Those functions need to know if they are a no-op (e.g. SysToLittle() on a PC), or actually perform a swap.
To me, i generally treat endianness like socket code, always call the ntols, ... functions.
On a PC they do swaps but on other (big-endian) systems they are a no-op.
_I_ don't need to know the system endianness, but the ntols funstions do.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
I too use ntol functions, mainly because of the reasons you mention. It's fool proof.
--
100% natural. No superstitious additives.
|
|
|
|
|
|
Joshua Quick wrote: That means endianess is not determined at compile time.
Yes it is. PowerPC nor Intel have variable endianess. Nor is it possible to run Intel code directly on a PowerPC and vice versa, so it's not like the same code is shared between the platforms. The Universal Binary contains sections (I think they call it bundles or forks or something like that at Apple) for each platform - copies of eachother. The Intel section is executed on an Intel machine, and the PPC section is executed on the PPC.
The data however may be of varying endianess - I don't know. If you look at the guidelines you provided a link to, it only speaks of data having different endians, and that you have to guard against that - and something that may be a real problem, as the OS is released on platform with differing endianess.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
