C / C++ / MFC

FirstPrevNext

Re: CreateNamedPipe hph9-Mar-04 3:44 hph 9-Mar-04 3:44  ok, thanks! and what does this mean ? Re: CreateNamedPipe David Crow9-Mar-04 4:07 David Crow 9-Mar-04 4:07  See if these two help: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/createnamedpipe.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/named_pipe_type_read_and_wait_modes.asp "The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998) Re: CreateNamedPipe hph9-Mar-04 4:24 hph 9-Mar-04 4:24  yes it helped, thank you, i got it! Debug System Wide Hooks bilal789-Mar-04 1:53 bilal78 9-Mar-04 1:53  Hi All! How to debug the system wide hooks? Any artical or material will be highly appreciated. Regards, Bilal Anjum Out of virtual memory martin_j9-Mar-04 1:44 martin_j 9-Mar-04 1:44  Hi all! I have a question regarding the computer's virtual memory. I am writing a program to simulate all kind's of combinations of a poker hand. To do this I wrote 5 while statements. This will give a complexity of about O(50 exp 5) = O(312 500 000) in the last while statement I will do some calculations. The problem is that when I run the program a run out of virtual memory ( I have increased the limit to 4GB ). I am confused why I run out of memory, I did't think the while statements would consume any memory (almost) . Could it be that I have a memory leak in the calculations that I make. So I guess my question is; will these while statements use all the computer's virtual memory depending on the complexity? Thanx! Martin_j Re: Out of virtual memory David Crow9-Mar-04 2:18 David Crow 9-Mar-04 2:18  martin_j wrote: I have increased the limit to 4GB. Not possible, even if you were using Windows 2000 AS or DS with the /3GB switch. martin_j wrote: So I guess my question is; will these while statements use all the computer's virtual memory depending on the complexity? No, while statements do not use memory in the quantity you are asking. It sounds like you need to open the Performance Monitor when your program starts and watch its memory consumption. "The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998) Re: Out of virtual memory Prakash Nadar9-Mar-04 2:38 Prakash Nadar 9-Mar-04 2:38  Are you allocating any memory in these while loops ??? You need to check ur system performance. Is there any considerable amount of harddisk space left ? MSN Messenger. prakashnadar@msn.com Re: Out of virtual memory martin_j9-Mar-04 2:59 martin_j 9-Mar-04 2:59  Thanx for your answer. I do call a procedure in the last while statement wich is using pointers. So I'm afraid I do not delete these pointers properly. While I check the system performance I can see that I use more and more virtual memory. It stops at about 2.1GB (all used) and then fills the RAM. Thereafter the program crashes. I do have about 100GB frre space on the hard drive. I talked to a friend and he proposed that I should use case statements instead. What would be the differense? /Martin Martin_j Re: Out of virtual memory wb9-Mar-04 3:31 wb 9-Mar-04 3:31  I think... the you should delete your pointers properly! Re: Out of virtual memory David Crow9-Mar-04 3:33 David Crow 9-Mar-04 3:33  martin_j wrote: So I'm afraid I do not delete these pointers properly. Properly or not, are you deleting them at all? Remember that every new must have a matching delete. martin_j wrote: I should use case statements instead. What would be the differense? Instead of what? The switch/case statement is synonymous with the if/else statement. "The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998) Re: Out of virtual memory martin_j9-Mar-04 3:41 martin_j 9-Mar-04 3:41  Sorry, I meant do/until. I do delete all pointers as far as I can see. Is there an easy way to debug the program and see if there is a memory leak? /Martin Martin_j Re: Out of virtual memory wb9-Mar-04 3:46 wb 9-Mar-04 3:46  if you use MFC you can just run your app for a short time with the Debuger attached, then exit it and in the debug-output-window you should see your mem leaks Re: Out of virtual memory martin_j9-Mar-04 3:48 martin_j 9-Mar-04 3:48  Thanx Martin_j Re: Out of virtual memory David Crow9-Mar-04 3:57 David Crow 9-Mar-04 3:57  Even if you aren't using MFC, you can still debug memory leaks with functions like: _CrtMemCheckpoint() _CrtMemDifference() _CrtMemDumpStatistics() "The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998) Re: Out of virtual memory martin_j9-Mar-04 4:06 martin_j 9-Mar-04 4:06  Great thanx Martin_j Re: Out of virtual memory Prakash Nadar9-Mar-04 4:40 Prakash Nadar 9-Mar-04 4:40  Oopss, sorry i accidently clicked on 1 instead of 5. I was looking for something like this all the time. MSN Messenger. prakashnadar@msn.com Release <-> Debug woes Phil.Benson9-Mar-04 1:12 Phil.Benson 9-Mar-04 1:12  Hi I have the following problem: I have an executable that loads dlls (MFC extension dll´s). All the dll´s are based on a parent class with various functions. To name a few BOOL mfb_open_database (LPCTSTR); CString mfx_get_module_name(); CString mfx_get_item_text (LPVOID); The functions are called from the main application using a pointer to the dll class.. x_txt = px_dll->mfx_get_item_text((LPVOID)something); The functions in the dll´s are all with AFX_MANAGE_STATE(..) because I´m loading things from the (DLL´s) resources The funny thing is only the mfx_get_module_name() does not work, all the others do. Tracing through this (I have added the debug symbols to the release mode of a dll and the exe) It comes about when the constructors for the CString objects are called. As far as I can tell, the DLL creates a CString object to be returned. Instead of a "Deep" copy, only the reference of it´s m_pchData is copied to the CString Object in the exe, and when the destructor for the CString Object in the exe is called, the MFC crashes and says that the Object that is to be destroyed is not in the "correct" heap. I have tried adding ::LockBuffer() to the CString object that is created in the DLL as the returned object but to no avail. I have checked all the project settings etc. and can´t find anything wrong. This function worked perfectly well up until yesterday, until my devstudio crashed a few times. I´ve checked all the settings in Project setings but can´t find anything un toward. Has anybody any idea´s I´m at my wits end.... Thanks in advance Phil bum... and I thought I´d got rid of all the bugs Re: Release <-> Debug woes wb9-Mar-04 3:33 wb 9-Mar-04 3:33  are the dlls AND the app the same build type?? Release or Debug? I spent some days on a realy anoying bug. My App was Release Build and the DLL was Debugbuild and it crashes all the time!! solution-> use the same build type. Re: Release <-> Debug woes Phil.Benson9-Mar-04 3:42 Phil.Benson 9-Mar-04 3:42  Yes, same build type. The really stupid thing is, that before the DevStudio crash everything worked fine bum... and I thought I´d got rid of all the bugs Re: Release <-> Debug woes wb9-Mar-04 3:56 wb 9-Mar-04 3:56  sure? I also thought all the time, my DLLs and the App are the same build, BUT somewhere deep was a silly path to the wrong directory with the wrong DLLs. don't know other reason.. sory. Re: Release <-> Debug woes Phil.Benson9-Mar-04 4:13 Phil.Benson 9-Mar-04 4:13  Yes I´ve checked.. I´ll have another look at the settings in a text editor, but in the IDE everything seems to be ok. And thanks for helping... Phil bum... and I thought I´d got rid of all the bugs Re: Release <-> Debug woes Phil.Benson22-Apr-04 1:48 Phil.Benson 22-Apr-04 1:48  I have finally found the problem. In one of my base classes I have over written the OnDraw() and OnEraseBkgnd() to draw a custom background. Instead of using the MFC message entry macro, ON_WM_ERASEBKGND(), ON_WM_PAINT(), I used the API one: ON_MESSAGE(WM_PAINT, ...) etc. This all worked fine in debug mode, but crashed in release. Now everything works fine bum... and I thought I´d got rid of all the bugs Are DLL`s slow? GDavy9-Mar-04 0:56 GDavy 9-Mar-04 0:56  Hello there, Once a dll is loaded into the address-space of an application is there a delay in the execution of code from the DLL itself? I mean is code from the DLL executed slower then when that same code would have been compiled in the application itself? Regards Re: Are DLL`s slow? Prakash Nadar9-Mar-04 1:03 Prakash Nadar 9-Mar-04 1:03  Calls within the dll itself will be same as calls within the exe only. But may be the calls between the exe and the dll could be slow coz the calls go through the CALL Gates i.e far calls. MSN Messenger. prakashnadar@msn.com Re: Are DLL`s slow? Anonymous9-Mar-04 4:26 Anonymous 9-Mar-04 4:26  There will be no noticeable difference, and certainly not anything worth bothering about. The kernel is a DLL after all!

Last Visit: 31-Dec-99 18:00     Last Update: 3-May-24 12:00 Refresh ᐊ Prev1...13463134641346513466134671346813469134701347113472 Next ᐅ

General    News    Suggestion    Question    Bug    Answer    Joke    Praise    Rant    Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.