msnkd's profilePoor programmer's BlogPhotosBlogListsMore  |  Tools Help |
|
September 21 STL vector and Some memory concerns.I know STL vector is smart & very efficient . But when we using it lacks some memory deallocation functions other than destructor.
This is depending according to the version of Visual studio you are using . If you are using VS7 , the vector::clear() will remove all memory used by the vector. Otherwise , i mean if the compiler is VS2005 , you are in trouble. The vector hasn't any functions to release all memory used by it , except ~vector() (destructor). Consider the following situations using VS2005 vector <int> myVec; for(int i = 0 ; i < 10000; i++) myVec.push_back(i); // ....some codes....... myVec.erase(myVec.begin()+1,myVec.end()); // removed all elements except the first.
// But memory still allocated , because vector
// reserved the memory for future allocations.
erase will mearly just removes elements from the vector and calls destructor (->~_ty()). So still the memory is not deallocated(call myVec.capacity() to see the allocated bytes) .. What to do ? if you want to free up memory (Ofcourse u can delete , the last way). One trick is to copy the contents to a new vector and again recopy it to the original vector , see below. Here the new vector(copy) will takes only the actual memory (it can be verifed using vector::capacity() ). During the recopy to original vector (myVec = copy) , the unwated memory is deleted.
Like
{
vector<int> copy = myVec;
myVec = copy.
}
So now the memory will be delted.. Ofcourse it makes some perfomance imacpt due to copy operation . But In some cases it can save a lot of memory . It depends upon the type of applcation.
Note : I have checked this only with Visaul Studio 7 , 8's implementaion of STL. September 20 GetOpenFileName() And Some Deep crashes..I think most of all windows programmers are familiar with GetOpenFileName() API (in MFC CFileDialog class).This api popups a open file dialog letting users to select the file they want. Okay , I am going into the matter. Try opening notepad. 1. click open from menu , now you can see open file dialog. Navigate to Desktop 2 move the mouse pointer around some file till tool tip visible. 3. Now cancel the dialog (press cancel or ESC) 4. Try to repeat the same thing (make sure again you go to desktop) , you will be awaited with a crash. Notepad disappears. Interestingly This happens only with Desktop. I don't why . So you might ask me how it mess up swith the GetOpenFileName.Yes it relates , try calling GetOpenFileName in win32 App (not MFC). You can see the same behavior , your application crashes.. This is Bug in windows XP ( Service pack??? , any oher Version ??? ) .. i don't about any other versions. If you debug the application you can't see any stack trace . This also happens with the GetSaveFileName api also. For calling GetOpenFileName you need initialize COM , by calling CoInitialize(0) in the first of the program and call CoUnitinialize in the end of the program. Then it should work. The interesting thing is that in MSDN there is no information about this. If you call like this as show below , still you can expect the crash. CoInitialize(0); I don't know the exact reason . But my guess is that the GetOpenFileName() / SaveFileName() creats 4 threads . Even you close the dialog these thread exists , and these threads might call some com calls , after your CoUnitialize() . That may cause some problems. The most important this is that , There is a chance to crash every application , that uses GetOpenOpenFile/GetSaveFile dialog (and not initializing COM) . Seriously.. September 13 Multiple Invalidate ? Some funny codes.I found some codes few weeks back , some thing like in the following snippets, OnUpdateEvent() { // some codes Invalidate(); Invalidate(); Invalidate(); } Why that programmer given 3 Invalidate() , when i asked he said that , in that event paint event should trigger , Otherwise the UI will be have some bad looks. Ok . His intention is good. But giving 3 Invalidate continuously doesn't means paint message will trigger 3 times. Most possibly here paint event (WM_PAINT) occurs only once. If it is any other custom messages , we can expect the event as the number of times , that messages has sent. But the paint event the OS handles in some special manner. In each paint event OS keeps a flag (if you read windows internals 4th edition , you can find more information , i forgot the exact names of those ), so even if we call InvalidateRect many times, the os checks whether the repainting is actually needed. Thats why 3 invalidate() s doesn't working one after another. At the end the moral story is don't rely on paint event. Only do painting stuff inside that.  |
. |
|
