|
I'm basically curious about the heap, and how the operating system manages this type of memory.
I have a couple of applications, in which I have created and allocated alot of data which resides in a single C++ class instance, and I have not used any explicit heap memory allocation functions. This seems to work fine, and I'm not likely to have any security-related problems (these objects are NOT COM objects, nor, are they shared resources nor accessed externally from my local machine).
The size of these objects are in the range of 100 KB to about 350 KB. I'm wondering if this is a good idea, to just let the memory manager allocate this data, or should I explicitly allocate a private heap? These objects are usually used just as single instances,...occasionally, it will be deleted and re-allocated, but typically they are just single use class objects.
Of course, I could break up the objects into alot of smaller components, but, then again, is this necessarily a good idea?
I'd appreciate any suggestions. Thanks.
|
|
|
|
|
How are you allocating the objects? Using new? new allocates its memory from the heap. You're almost certainly better off leaving the memory allocation details to the system.
Steve
|
|
|
|
|
Global variables kill optimization opportunities. Unless you understand memory well and will do all work from this class, you do not want to manage your own pool of memory like that. If you did chose to manage your own memory, then you may use C functions instead of new (especially if the data types are all primitive like double, long, int, etc.). This means that you have to handle construction, destruction properly yourself, but you can get speedups by bypassing unnecessary initializations.
|
|
|
|
|
It depends on your compilers runtime library but generally the operating system doesn't have a lot to do with the C++ heap. As a first approximation what happens for newing objects is that the runtime allocates a big chunk of memory and then suballocates objects out of that block. When it runs out of that block it allocates another and starts allocating out of that.
However the real world of C++ allocators and operating system heaps is rarely that simple anymore. For example Windows 2000 (I think, haven't got my reference books to check so I could well be wrong) introduced a small object heap that allocated chunks of memory for objects of different size ranges to avoid fragmentation of the heap. At least one C++ compiler I've used used a similar set of blocks for different sizes for the same reasons.
Other optimisations I've seen include different heaps or blocks per thread. Most programmers don't want their threads blocking if a memory allocation is attempted and then there's the whole issue of using garbage collection for recovering memory for the heap rather than doing it when the program deletes an object. If you defer memory recovery to a garbage collector you end up avoiding one of the bottle necks in multithreaded code if the heap is shared between threads.
So basically only worry about it if you find that you can't create the objects you need or if you've profiled your app and found that it's spending way too much time in the memory allocator.
Cheers,
Ash
PS: There's no such thing as "class objects" in C++. Classes are just things the compiler sees, once the program is compiled classes don't really exist anymore, unlike Java or Smalltalk where everything's an object including classes.
|
|
|
|
|
Yes, the objects are created with the new operator, that way I can just call delete on the object pointer. It's mostly for convenience.
...And, I only have one main thread in these applications,...the sequence of operations are not all that complicated. The end result is to write alot of the data to file.
I had thought that for small objects, they would somehow live on the stack. (Shows you how ignorant I am of memory management.)
The term "class objects" I just use to describe what is a contiguous block of data. You seemed to get the idea pretty clearly.
Thanks for the information. I'll play around with it a little, just to get a better idea of how it works.
|
|
|
|
|
I am facing a problem where i dont receive the MSMQ events on 64 bit machine. The same code works fine on a 32 bit server but not on 64. Below is how the Sink mapping is done.
BEGIN_SINK_MAP(CMailQueueServer)
SINK_ENTRY_EX(0, DIID__DMSMQEventEvents, 0, Arrived)
SINK_ENTRY_EX(0, DIID__DMSMQEventEvents, 1, ArrivedError)
END_SINK_MAP()
I can queue up messages but the event doesnt get fired, the items in the queue remains unprocessed. Does it have to be handled differently in 64 bit server?
Any help will be greatly appreciated!!!
Hariharan.T
|
|
|
|
|
Hi,
I am trying to figure out a way to draw a polygon directly onto a dib. Currently when the user selects points on the image(view) I draw it directly onto the DC until the user click right mouse button at which point I would like to actually update it on the bitmap that I am displaying. My bitmap is a DIB derived by my own class which has access to bitmap handle (HBITMAP) and bitmap data etc.
One way is to draw a polygon manually by computing all the indices and update pixel by pixel, but for bigger polygons it gets tedious and I am not in favor of doing this way.
Any help is greatly appreciated.
thanks
PT
|
|
|
|
|
See the competitors (funny enough, it is a returning link...) [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hello,
Does anyone know of a simple package to allow for plotting line plots from visual c++ 2008? I'd love to use koolplot because it seems to be the quickest and simplest route, but it keeps looking for missing header files (i.e. graphics.h, jview.h, interfacekit.h, ...).
Thanks!
P.S. I'm using windows os.
modified on Tuesday, June 15, 2010 11:19 AM
|
|
|
|
|
b-rad311 wrote: koolplot
it looks like this toolkit needs some pre-requisite that are not that obvious for a standard Windows environment.
anyway, me think the best solution right now comes from our own Cedric Moonen :
High-speed Charting Control[^]
Max.
Watched code never compiles.
|
|
|
|
|
|
How to control two threads accessing same variable
in MFC
|
|
|
|
|
Use a critical section[^] to protect the access. On the other hand, if your variable is a standard type (int, char, bool, ...) you don't need to protect it because writing or reading it is an atomic operation.
|
|
|
|
|
I believe 16 and 32 bit integer writes are atomic on x86 ONLY if they are aligned.
|
|
|
|
|
Forgive me for being slightly cynical, but if I have an 32 bit integer that's not aligned on a 32 bit boundary an x86 won't read it in one fell swoop. And if you're doing an update to a variable you generally need to lock it somehow to get the correct memory barriers inserted into your code.
Cheers,
Ash
|
|
|
|
|
with a lot of attention.
Use synchronization mechanisms like mutex, critical sections, .... especially when trying to write the variable.
Watched code never compiles.
|
|
|
|
|
...and equally especially when trying to read the variable. 
|
|
|
|
|
|
hello, everyone.
"the attempt to edit the code in cimageDoc::OnSegManual in file--- imagedoc.cpp failed" POPS UP, when mapping menu item to function in MFC classWizard. And The files are writable.
How can I mend the problem?
|
|
|
|
|
I have simple template method in my class. I think it is self-explaining:
template<class T> T* GetCell(int row,int col)
{
return ((T*)GridCellGet(col,row,0,0,RUNTIME_CLASS(T)));
}
It works in debug build (MFC DLL), but it does not compile in release (static) build. It seems RUNTIME_CLASS() has different definition for DLL and static builds. Error message is:
error C2039: 'classT' : is not a member of ....<br />
It teems preprocessor replaces RUNTIME_CLASS(T) with 'T' instead of type name, I guess it has higher priority. Do you have idea how to solve this?
Thank you.
|
|
|
|
|
Use #ifdef __DEBUG__ to compile differently in debug and release?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers don't kill programs, users kill programs <
> "It doesn't work, fix it" does not qualify as a bug report. <
|
|
|
|
|
Goto declaration of RUNTIME_CLASS macro in afx.h and you will see something like
#define _RUNTIME_CLASS(class_name) ((CRuntimeClass*)(&class_name::class##class_name))
#ifdef _AFXDLL
#define RUNTIME_CLASS(class_name) (class_name::GetThisClass())
#else
#define RUNTIME_CLASS(class_name) _RUNTIME_CLASS(class_name)
#endif
If you have _AFXDLL defined in your project replace RUNTIME_CLASS(T) with T::GetThisClass()
Otherwise you will have a problem. The macro will expand to &T::classT which will fail, and you will need some other construct.
Edit: This might work (NOT tested)
template<class T> T* GetCell(int row,int col)
{
return ((T*)GridCellGet(col,row,0,0,T().GetRuntimeClass()));
}
|
|
|
|
|
Thank you, it works, but I think it always creates temporary object so it will be bit inefficient but maybe it won't be noticeable problem.
|
|
|
|
|
Ok. If performance is critical, you could solve this by having a class variable (static T temp) to use to avoid the constructor each time. Who knows, that construct might even win you some kind of most-akward-contruct-of-the-year award.
<edit>Ah forget about that and just cache the return value of T().GetRuntimeClass().
</edit>
It's a bit fishy that you had different behavior in debug and release. You might want to check what defines you have in release vs debug. If _AFXDLL is defined in debug it should be defined in release as well. Notice that it's implicitly defined when defining some other symbols like _AFXEXT (and what else)
home
modified on Tuesday, June 15, 2010 9:22 AM
|
|
|
|
|
hai
This started happening when I added a malloc and free. I checked in Debug it is while freeing the memory.
I tried the runtime lib settings.It was initally /MDd that time this error _CrtIsValidHeapPointer was coming.Then I tried to changed to /MTd then it in call stack shm_test.exe1_unlock_fhandle( ) was there.
chikach
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
