|
Tim's is probably the simplest method.
You can also opt for trapping these kinds of problems using structured exception handling. In your case it looks like an Integer Overflow exception (0xC0000095).
Do a search for "_try" in MSDN and take a look at this article[^].
[edit]
Yet another option is to put the code inside a try/catch-all block:
int Multiply(int iA, int iB)
{
try
{
return iA * iB;
}
catch (...)
{
}
}
[/edit]
Regards,
Alvaro
All you need in this life is ignorance and confidence, and then success is sure. -- Mark Twain
|
|
|
|
|
How do I enable integer overflow trapping? It doesn't seem to be on by default.
Eddie Breeveld
|
|
|
|
|
I guess this could do:
inline bool mult_overflow(int a,int b)
{
return a!=0 && (a*b)/a!=b;
}
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
int mult(int iA, int iB)
{
int product = iA * iB;
if(iB != 0 || product / iB != iA)
throw MathException;
return product;
}
I believe this works.
|
|
|
|
|
I always used CWnd when working with MFC, never really used HWND as I never really programmed fully Win32 applications.
Is there an advantage to use HWND to keep objects in containers ( for example ? ) instead of CWnd* ?
std::vector<HWND> hwndVector;
std::vector<CWnd*> cwndVector;
Thanks.
Max.
|
|
|
|
|
As for the efficiency, none at all (both types of objects occupy the same space). Using HWND will tend to make things more complicat, specially in multithreaded code, where it is not easy to retrive the "true" CWnd attached to a given HWND . So, I'd say you're better off using CWnd * s.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Joaquín M López Muñoz wrote:
Using HWND will tend to make things more complicat, specially in multithreaded code
But if you're passing Window handles between threads you have to use HWNDs as the CWnd/HWND mapping doesn't go across the thread boundary properly.
|
|
|
|
|
It is the mapping HWND ->CWnd that does not hold across threads, not the other way around. Handling a CWnd object from a thread other than the one which created the CWnd is just fine (modulo concurrency problems).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
If you have a single-threaded application storing CWnd* is more practical, easier to use.
You CANNOT use the CWnd* in a different thread, than the thread, where the given CWnd* was created. What you can do is you pass the HWND for the given window to the thread, and in that thread you create your CWnd* using CWnd::FromHandle(hwnd), after that, you can use this CWnd* in this thread. So it's more practical to store HWND in this kind of environment.
I could give you some examples, when you could use CWnd* in a multithreaded application, but it's very wrong.
Zolee
|
|
|
|
|
You CANNOT use the CWnd* in a different thread, than the thread, where the given CWnd*
I do not agree with that. Can you give some example in which using a CWnd * across threads is wrong and doing the same with a CWnd * obtained via CWnd::FromHandle is right?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
How can I get the app Path without geting the app name?
\Larsson
|
|
|
|
|
If you have the app path and name, use strrchr to look for the last ocurrence of \ , insert a string-terminating 0 there and you're done.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Can you please send me a code to se what to do??
\Larsson
|
|
|
|
|
_splitpath
You can pick your friends, and you can pick your nose, but you can't pick your friend's nose.
|
|
|
|
|
somewhere useful
char * szDir = (char*) malloc(300);;
GetCurrentDirectory( 300,szDir);
and don't forget to....
free(szDir);
Bryce
|
|
|
|
|
Here is the routine I use:
CString CDemoApp::GetFullAppName() const
{
char szFilename[_MAX_PATH] , szDrive[_MAX_DRIVE], szDir[_MAX_DIR], szFname[_MAX_FNAME], szExt[_MAX_EXT];
GetModuleFileName(AfxGetInstanceHandle(), szFilename, _MAX_PATH);
_splitpath(szFilename, szDrive, szDir, szFname, szExt);
CString strAppPath(CString(szDrive) + CString(szDir) + CString(szFname));
return strAppPath;
}
Steve
|
|
|
|
|
Hi
Can someone please tell me how to split a window in vc++ without using splitter windows???? Is it possible to do it??? And if there is no other way than using CSplitterWnd, well what can i do for the border unmoveable!????
Also i'm trying to write something like a window-based chat application ( actually the app will have other modules other than chat ).. if anyone is willing to share his app with me, I'd be very grateful.. :P
Thanx
Hamchoy
|
|
|
|
|
I put in three menu items, but at different times so in my resource.h file I have:
#define ID_SMARTREMUS 32781
#define ID_SMARTORIGINAL 32782
#define ID_Q14 32795
plus lots of ID_s between 32782 and 32795...
I wanted to use ON_COMMAND_RANGE but now my range has gotten messed up because of the intervening IDs.
If I went into resource.h and manually did (these numbers below are unique):
>#define ID_SMARTREMUS 35000
#define ID_SMARTORIGINAL 35001
#define ID_Q14 35002
#define ID_ABSOLUTELAST 35500
#define APS_NEXT_COMMAND_VALUE 35501
would that be okay? Then I would do the range from ID_SMARTREMUS to ID_ABSOLUTELAST in case I add more. So can I slavage my project or did some other stuff get modified when I gave the menu item its ID?
Appreciate your help,
ns
|
|
|
|
|
This is just fine IMHO. Just remember to do a "Rebuild all" after manually touching resource.h (sometimes the compiler does not "see" these changes).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Since you think its safe, I'm checking it out right now....
Appreciate your help,
ns
|
|
|
|
|
Odd thing is, the stuff in red didnt change though I made the manual changes:
<code>
#define ID_SMARTREMUS 50000
#define ID_SMARTORIGINAL 50001
#define ID_Q14 50002
#define APS_NEXT_COMMAND_VALUE 50003
#ifdef APSTUDIO_INVOKED
#ifndef APSTUDIO_READONLY_SYMBOLS
#define _APS_3D_CONTROLS 1
#define _APS_NEXT_RESOURCE_VALUE 138
<code>#define _APS_NEXT_COMMAND_VALUE 32784</code> I dont think I wrote this part (I cant remember), but its not changed. Do I need to change it to 50003?
#define _APS_NEXT_CONTROL_VALUE 1011
#define _APS_NEXT_SYMED_VALUE 101
#endif
#endif
Appreciate your help,
ns
|
|
|
|
|
Everything should be fine: if _APS_NEXT_COMMAND_VALUE is 32784 and your range begins at 50000, there's plenty of room for new commands before they hit you.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Oh I see......so I dont need to put in the line myself:APS_NEXT_COMMAND_VALUE = 50003
.....it seems to ignore it. I was instructed by some article to do this....
Appreciate your help,
ns
|
|
|
|
|
I changed the APS to 50003 even in the ifdef APSTUDIO_INVOKED block, and put in a new menu ID.....and rebuilt all . Well, it gave the new ID the number 32784, and the _APS jumped to 32785 automatically in that block! (in the ifdef). My given value of 50003 is unheeded and unchanged!
Appreciate your help,
ns
|
|
|
|
|
Maybe you are confusing APS_NEXT_COMMAND_VALUE and _APS_NEXT_COMMAND_VALUE (with a leading underscore)?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|