|
Okay. Thanks.
Key mistake: "&"
Kuphryn
|
|
|
|
|
Yes, but it's a very strong difference.
|
|
|
|
|
I created an MFC Extention DLL, and declare each class in the DLL with AFX_EXT_CLASS. It compiled fine, and the DLL was generated.
Now, I'm using the DLL's classes in a my application. In the application, I just coded something like :
<br />
CPacketAction* ppak;<br />
ppak = new CPacketAction();<br />
<br />
delete ppak;<br />
In the delete code, I got exception. The constructor and destructor didn't do anything, so it's just a problem of memory allocation. But, what's wrong ? It bothered me more than a week, but I couldn't solve it.
The error message in debug window is :
HEAP[TestServer.exe]: Heap block at 003B71E8 modified at 003B7270 past requested size of 80
Could anyone help ?
|
|
|
|
|
Forgot to tell, though the class's constructor didn't do anything, the base class did. It's derived from a base class called CPacketBase, which has a member variable called m_buffer of CBuffer type.
In the constructor of CBuffer, it does VirtualAlloc(...), and the destructor of it does VirtualFree(...). Will it be the consequnce of the memory access violation ??? If so, how can I solve it ?
|
|
|
|
|
I'm not quite sure if this applies to your problem, but you may want to check out
"Wrong Operator Delete Called for Exported Class ", ID: Q122675 at msdnlib
|
|
|
|
|
I do not know if this applies to your problem, but there are certain issues that you have to have in mind when working with DLL's and heaps.
If you allocate an object on the heap in your DLL, then DO NOT deallocate it from the calling application, because it may not be the same allocator used there!.
That is: the runtime libraries used are not the same, and so you may try to deallocate a piece of memory that is not referenced by the allocation structure, and this may lead to Unexpected Behaviour.
I may be talking BS here, because i never saw this problem in the real world, i just read it somewhere in an old WDJ issue, so i can't honestly tell you that what you are seeing is the result of such an error.
Jan
"It could have been worse, it could have been ME!"
|
|
|
|
|
As you can see from my code before, delete is the next line to new, so they should be new / delete in the same application, but just the declaration is in the DLL ... really so weired.
Hiya, Everybody ^^
|
|
|
|
|
Hi,
These two word always appear in my book, for example,
There is a class called CFn. And...
1> CFn fn; // this will create an object fn in stack
2> CFn* pFn=new CFn(); // this will create an object in heap
My problem is the advantages and disvantages of an object created in heap vs in stack. Plz explain them in detail.
Thank you in advance.
Best regard.
I confess that I am a stubborn guy, but why not put things thoroughly, logically and systematically clean. One concrete prolem is worth a thousand unapplied abstractions.
|
|
|
|
|
When you create an object on the stack, you are basically creating a variable in the current stack frame in which you are operating. Stack varaibles automatically go away when you exit the function call that they were defined in.
The heap is where dynamic memory is allocated from. When you declare an object on the heap, you have to allocate memory for it, usually with new or malloc, or in the case of the windows API GlobalAlloc. The pointer that you recieve from one of these allocations will not be destroyed until you explicitly destroy it. You can destroy heap memory that you have previously allocated with delete, free, or GlobalFree, each of these calls corresponding to the allocators that I mentioned earlier.
The advantages of the stack is that you do not have to manage the memory, just declare the variable and start using it. It will clean up after itself when the function exits. The disadvantage is that you have to know how much memory that you need at compile time, and the variables that you declare are not persistent outside of the function that they are described in.
The advantage of the heap is that you can decide how much memory that you need at runtime, and the variables will persist as long as you need them.
Checkout my Guide to Win32 Paint for Intermediates
|
|
|
|
|
The previous comments are correct, but one of the things most often forgotten about stack .vs. heap allocation is speed: stack allocation basically requires moving the stack pointer (register) to allocate a block of memory. Heap allocation includes overhead that can range from simple management of heap blocks and can go so far as to involve the operating system to request more free pages of memory.
Stack allocation of memory is much faster than heap allocation, and heap allocation is much slower than stack allocation. That is why you never treat CString or CComBSTR objects like they were free!
Also, the hidden information in the previous comment about stack memory cleaning itself up is that you should never pass the address of a stack-allocated variable to a function that may store that pointer. By the time that function gets around to using that pointer, the memory that the pointer points to will be invalid. Worse yet, it might not crash when it uses that pointer, it might just corrupt another function's local variables.
Lastly, heap access is normally serialized, which prevents two threads from messing with (allocating or deallocating memory) the heap at once, and that is good (but is the cause of a small part of the slwoing overhead). However, if you are doing any serious multithreaded development, you need to be careful of how you (mis)use dynamically allocated memory, and maybe even create seperate heaps for your threads, to reduce the effects of heap contention. Threads each get their own stack, so their stack allocations to not effect other threads.
Peace!
-=- James.
|
|
|
|
|
James R. Twine wrote:
heap access is normally serialized
I think you mean "synchronized". 
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Ravi Bhavnani wrote:
I think you mean "synchronized".
Quoted from MSDN docs: "To ensure thread safety, the heap has to serialize access to itself" and "The default behavior is to serialize access to the heap". True, a synchronization object is used for this.
The difference is that "Serialization" basically means "one thing after the other, and one at a time". "Synchronization" usually involves multiple threads at work, where two threads can actually try to manipulate something at the same time.
Although I agree as much as to say that the two terms are often used interchangeably...
Peace!
-=- James.
|
|
|
|
|
I'd like to add the formatting rebars seen in apps like word to a dialog I'm writing. Is this possible, or will I have to create my own?
skydiving....if at first you don't succeed, you're fecked!
|
|
|
|
|
Do you want to embed word control into a Dialog?
If:
you can send a app to you!
|
|
|
|
|
Do you want to embed word control into a Dialog?
If:
I can send a app to you!
|
|
|
|
|
Hi,
Plz look into this class, what will happen with static member variable?
class A
{
private:
char m_a1;
static double m_b1;
};
Tell me in detail, plz. Thank you in advance.
Best regard.
I confess that I am a stubborn guy, but why not put things thoroughly, logically and systematically clean. One concrete prolem is worth a thousand unapplied abstractions.
|
|
|
|
|
The variable m_b1 will exist once across all instances of this class. It could be set or accessed using A:m_b1, except that you've made it private.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002
|
|
|
|
|
This might not be fully accurate, but I think the memory structure of an object created with the class will look something like this:
vtbl -> (functions)
m_b1 -> (one single instance of double)
m_a1
Each object share the vtbl and the reference to m_b1, and allocate memory for m_a1. There will only exist code for the functions and space for m_b1 at one place, no matter how many objects you create from the class. On the other hand each object will be able to access their own memory for m_a1.
/moliate
|
|
|
|
|
moliate wrote:
This might not be fully accurate [...]
Actually, it is pretty good, except for two things:
1: A class will not have a vtable in it's layout unless it has virtual methods (or inherits them from a base class).
2: The layout (placement) of the vtable is implementation dependent. It is correct for VC++ (currently), but might not be for other compilers, or in the future.
Peace!
-=- James.
|
|
|
|
|
Thanks for your comments.
I know that the placement ot the vtbl is implementation dependant (thanks to painful experiences with Mac). I am still a bit unclear about non-virtual member functions, however. I assume that they are not replicated in every object instance? Is there a separate pointer like the vtbl for them?
Could you help me to become a better C++ programmer?
Cheers
/moliate
|
|
|
|
|
moliate wrote:
I am still a bit unclear about non-virtual member functions, however. I assume that they are not replicated in every object instance? Is there a separate pointer like the vtbl for them?
IIRC, neither virtual or "normal" member functions are replicated for every instance of a object. The old idea of "one copy of code, multiple copies of data" comes to mind.
Yes, if the object contains virtual methods, then each instance of the object gets a copy of it's vtable. This is needed for polymorphism. But it is just the vtable that is in the memory layout of the object, not the code for the functions themselves. That code still exists in one place, and the vtable is used to get to them.
moliate wrote:
Could you help me to become a better C++ programmer?
That is what this site is (supposed to be) for! :P
(Note, I used "object" above instead of "class" because both classes and structs can contain member functions...)
Peace!
-=- James.
|
|
|
|
|
Since almost everyone interested in CodeProject already has a version of Visual C++, why does CodeProject only offer the non-upgrade version of Visual Studio.net for $799?
The upgrade price for Visual Studio.net, professional version, is $195.99 after rebate, from Programmers Paradise.
|
|
|
|
|
No responses to this post leads me to believe that the Code Project $799 offer for the non-upgrade version of Visual Studio.net is not what we need. Most of us want to UPGRADE to Visual Studio.net. The $195.99 offer from Programers Paradise may be the best deal,
|
|
|
|
|
I'm using VC++ 6.0 and when I add a Tab Control onto my Dialog box in the resource editor, the form will no longer load. I was wondering if anyone had any idea as to how I can remedy this so that my form will load with the Tab Control on it?
thx
Quinn
|
|
|
|
|
Make sure InitCommonControlsEx() has been called to initialize the tab control.
Developers that like shiny objects also dig case mods and scratch-and-sniff stickers. Klaus Probst, The Lounge
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
