|
I only use it in assert-statements, so that a bad-pointer is detected during development.
In a production version I only check for NULL-pointers.
I have the impression (but I'm not sure anymore), that the function is quite efficient as long as the pointer is valid. If the pointer is invalid, an internal exception is thrown, which is caught by the IsBadReadPtr function. In that case, there is a lot of overhead handling the exception, which makes it much slower.
You could always try to execute IsBadReadPtr in a loop and see its effect on a valid and on an invalid pointer.
But ... even if IsBadReadPtr returns success, it does not mean that the pointer is a valid pointer in your context. Suppose your pointer once pointed to e.g. a window structure, but that one has been freed, and its memory is now being reused by another data structure. Your window-pointer will then point to valid memory, but not to a window-structure anymore, which will crash your application later (in the best case), or corrupt other memory, files or your database (in the worst case). Therefore I wouldn't rely on IsBadReadPtr alone.
Another trick that can be used is to store a checksum in the first [four] bytes of a structure (or class). That way, you can always check the first bytes of your structure to see whether it is the kind of struct you would expect.
I do this sometimes (only in development versions, again for performance reasons).
<marquee>Enjoy life, this is not a rehearsal !!!
|
|
|
|
|
Thanks for the info.
I guess I need to just perform some testing and see how well it performs. I am most concerned with the performance on valid pointers so the overhead of exceptions for bad pointers isn't really an issue for me.
The particular application which lead me to the question is a Windows NT service I have written which powers a web site. I use the IsBadReadPtr/IsBadWritePtr functions in the release builds to insure stability. You are correct that just because IsBadXXXPtr returns false does not mean that you have a valid object. I also use dog-tags (similar to your suggestion of a checksum except that there is a tag at the beginning and the end of the class/struct) on the important structures and classes and validate them before accessing their data, again to insure stability.
I think I will do some performance testing and write an article on the results.
|
|
|
|
|
I split a window into two parts(left and right)using CSplitterWnd .I want to dynamically changing right view. I have a method, but it must destory last view and create the view i want.how can i change the right view and don't destory the view before
thanks!!!!!
|
|
|
|
|
I've run Depends on my application and determined that it needs:
mfc42.dll
msvcrt.dll
msvcp60.dll
wsock32.dll
shell32.dll
1. Am I allowed to redistribute these files?
2. Is it wise to redistribute these files? shell32.dll is 8M! Can I assume that a reasonable system will have a recent shell32.dll?
J
May the bear never have cause to eat you.
|
|
|
|
|
See REDIST.TXT in your VC 6 directory for a list of files you can redistribute. IIRC WinSock has its own installer which you can redistribute.
I should point out that it will save you a huge amount of headaches if you statically link to MFC. That way you don't have to redistribute the huge DLLs, nor worry about what happens if the machine has a newer version of the DLLs (will it break your code? probably not, but you never know; why risk it?).
Jamie Hale wrote:
Can I assume that a reasonable system will have a recent shell32.dll?
Absolutely not. Beginning with 98 and 2000, each OS has one and only one version of shell32. 95 and NT 4 can have one of three different versions depending on whether they have the Active Desktop shell installed.
--Mike--
"Adventure. Excitement. A Jedi craves not these things."
-- Silent Bob
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Michael Dunn wrote:
See REDIST.TXT in your VC 6 directory for a list of files you can redistribute. IIRC WinSock has its own installer which you can redistribute.
I should point out that it will save you a huge amount of headaches if you statically link to MFC. That way you don't have to redistribute the huge DLLs, nor worry about what happens if the machine has a newer version of the DLLs (will it break your code? probably not, but you never know; why risk it?).
I will have a look at the file. I've also changed my app so they use MFC statically (with dozens of multiply defined symbols...  ) so that should cut it down a bit.
Michael Dunn wrote:
Absolutely not.
Ahh crap. So how do I go about distributing an application that relies on SHBrowseForFolder() and the like? Can I just assume that if MSDN says "Needs 98 or later" that any 98 or later machine will have a shell32.dll that supports SHBrowseForFolder()?
J
May the bear never have cause to eat you.
|
|
|
|
|
need to print last n lines if the text as well as n is specified in the program.
|
|
|
|
|
Um, we won't do your homework for you.
--Mike--
"Adventure. Excitement. A Jedi craves not these things."
-- Silent Bob
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Hi.
I just discovered an interesting properties of formview in MFC. Consider a formview that displays multiple dialog boxes as windows. The program displays the dialog box windows via ShowWindow(SW_SHOW). However, for some reason the framework will suddenly hide the dialog box windows if the user presses a control key, i.e. ESC, ENTER, etc. Thus, when the user presses a control key, the framework hides all dialog bow windows and all you see is controls that are embedded in the formview via Resource Editor.
I would like to know is it possible to circumvent this property of MFC's formview?
Thanks,
Kuphryn
|
|
|
|
|
Hi
maybe you just have to overried OnOK() and OnCancel()
of that dialog box classes. cause when you press ENTER
OnOK() will be called and the window destroys itself. the
same thing happens for ESC and OnCancel()
|
|
|
|
|
|
when I use "DestroyWindow" to Destroy a view, there are errors appear as follow:
"Warning: calling DestroyWindow in CWnd::~CWnd; OnDestroy or PostNcDestroy in derived class will not be called.
Warning: calling DestroyWindow in CWnd::~CWnd; OnDestroy or PostNcDestroy in derived class will not be called."
can you tell me the possile reason ?
thanks in advance.
liuty
|
|
|
|
|
hi
are you trying to destroy a window in that window's class
deconstructor? I think when deconstructor is called, the
window is already destroyed, so no message can be sent to it,like WM_DESTROY( which invokes OnDestroy).
|
|
|
|
|
QUESTION 1:
i just want to confirm that I can register and unregister my ATL-COM wizard created server by calling LoadLibrary and invoke DllRegisterServer/DllUnregisterServer directly - as opposed to command line util Regsvr32.
For some reason, the code is not working, and with no compiler or runtime error - I cant even tell if the function call has been executed. I know however that the register the component does not exist in registry - after i run the following subroutine:
//TO UNREGISTER SERVER:
int UnRegQueryGen(char * pszDll)
{
DWORD dwError;
typedef STDAPI (*PFUNC) (void); //QUESTION 2: This will cause : error C2159: more than one storage class specified
//So, I changed it to:
typedef void (*PFUNC) (void); //and it seems to work fine (i.e. no compiler error)
//<caution! quote="" from="" msdn..="">
//If the string specifies a path but the file does not exist in the specified directory, the function fails. When specifying a path, be sure to use backslashes (\), not forward slashes (/).
//STEP 1: Load dll.
HINSTANCE hLib;
hLib = LoadLibrary(_T(pszDll));
//STEP 2: un-register server
if(hLib!=NULL)
{
PFUNC pFunc = NULL;
pFunc = (PFUNC) GetProcAddress(hLib, _T("DllUnregisterServer"));
if(pFunc!=NULL)
{
//Unregister the server!
pFunc();
}
else
{
//Additional exception handling here.
dwError = GetLastError();
FreeLibrary(hLib);
return 0;
}
}
else
{
//Additional exception handling here.
dwError = GetLastError();
return 0;
}
FreeLibrary(hLib);
return 1;
}
//TO REGISTER A SERVER
int RegQueryGen(char * pszDll)
{
typedef void (*PFUNC) (void);
//STEP 1: Load dll.
HINSTANCE hLib;
hLib = LoadLibrary(_T(pszDll));
//STEP 2: register server
if(hLib!=NULL)
{
PFUNC pFunc = NULL;
pFunc = (PFUNC) GetProcAddress(hLib, _T("DllRegisterServer"));
if(pFunc!=NULL)
{
//register the server!
pFunc();
}
else
{
//Additional exception handling here.
FreeLibrary(hLib);
return 0;
}
}
else
{
//Additional exception handling here.
return 0;
}
FreeLibrary(hLib);
return 1;
}
One last point, the exposed DllRegisterServer and DllUnregisterServer is implemented by ATL Wizard, so, I dont think there's anything to do with it.
Thanks!
norm
|
|
|
|
|
Hi.
I am working on a project that contains a formview class with multiple dialog windows visible. As the user make changes to each dialog box, I want to update the document class. I implemente a message solution. The dialog boxes update send messages to the view class. The view class update the document class.
In general, the solution above is adequate. However, in this particular project, the dialog windows are visible in the formview. I would like to know is there other more elegant solutions?
For example, is it possible to implement a GetDocument() function that returns a pointer to the document class inside the dialog boxes? As another example, how about passing the dialog boxes pointers to the document class? I do not want to implement these solution unless messages fail. Thus these solutions should be last resorts.
Thanks,
Kuphryn
|
|
|
|
|
I'm sure there are a million answers to your question. But I would stick to the message solution. It is the best way for windows to communicate. I would not pass pointers to class objects around to be used. That could be potentially dangerous. If the WPARAM and LPARAM parameters seem to limiting remember you can allocate memory (or objects; classes, structs, etc.) and pass the pointer to another window through a message.
if(IsWindow(hwnd))
{
CThing *pThing = new CThing;
PostMessage(hwnd, WM_NEW_THING, 0, (LPARAM)pThing);
}Just remember the receiver of the message is responible for deleting the memory.
long CMyWnd::OnNewThing(WPARAM wParam, LPARAM lParam)
{
ASSERT(lParam);
CThing *pThing = (CThing *)lParam;
...
delete pThing;
}One more thing, in the OnDestory method of the CWnd class make sure you have no more WM_NEW_THING messages in the queue. Their memory should be deleted if they are.
MSG msg;
while(::PeekMessage(&msg, (HWND)NULL, WM_NEW_THING, WM_NEW_THING, PM_REMOVE))
{
CThing *pThing = (CThing *)msg.lParam;
delete pThing;
}Hope this helps.
Jonathan Craig
www.mcw-tech.com
|
|
|
|
|
Recommendation noted.
Thanks,
Kuphryn
|
|
|
|
|
where can get stuff about these?
|
|
|
|
|
The easiest way is to put a batch file that does it onto the PC in question and execute it remotely.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
hi, what's wrong with copying a file with fread and fwrite?
int CopyQueryGenDll(char * pszOutfile)
{
FILE *stream;
//Size of QueryGenAlpha.dll = 249 kB
int nDllSize = 1000;
char * buffer = new char[nDllSize];
if(buffer==NULL)
{
//Exception handling here.
return 0;
}
int i=0;
int numread = 0;
int numwritten = 0;
//Initialize buffer:
for(i=0; i
|
|
|
|
|
1) You're trying to read and write a binary file in text mode - the carriage return line feed translations are going to screw it up.
2) Why not just use CopyFile()?
Dave
|
|
|
|
|
thanks, just did. i tried to stay with stdio.h because it's more portable - in case if any part of the code needs to be deployed under a UNIX environment.
norm
|
|
|
|
|
Hi!
I always wondered why VC6 and VC.NET do not use multiple compiler instances when running on a SMP box. On unix running gnu make in parallel mode is just an argument away. Why can't have this on VC too?
|
|
|
|
|
How many PC's have more than one processor ?
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Seems like a chicken and egg question to me  .
I'm pretty sure many developers would buy SMP machines if their compiler could use the power to divide compile times by two!
All my dev machines are SMP for quite simple reasons, the first being that programming multithreaded code and testing it only on mono proc machines is one of the best way to shoot one slef in the foot .
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
