|
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
|
|
|
|
|
i am using onctlcolor message to set the the background color of edit controls.
the problem is that the background only changes background color if there is text in the control and only for the length of the text.
can the background color be changed regardless of what is in the control for data?
thank you
|
|
|
|
|
Sounds like you're using SetBgColor(). Instead (or in addition) create a solid color brush and return that.
Developers that like shiny objects also dig case mods and scratch-and-sniff stickers. Klaus Probst, The Lounge
|
|
|
|
|
no i am using setbkcolor()
this is the onctlcolor
it works the ok but it only changes the color behind the text not all the background of the control. if there is no text the color will not change at all.
when i want the color to change i call Invalidate()
HBRUSH PREFS::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
int nCtrl = pWnd ->GetDlgCtrlID();
switch(nCtrl){
case IDC_BCOLOR:
pDC->SetBkColor(RGB(m_red,m_green,m_blue));
break;
/////////////////////plus more
}
return hbr;
}
|
|
|
|
|
jafrazee wrote:
no i am using setbkcolor()
Sorry, typo (yes i am too lazy to bother checking each post against MSDN before submitting  )
What you need to do is this (assume you've added a member to your class of type HBRUSH and named it m_hBrush, since you'll need to delete this when done with it):
HBRUSH PREFS::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
int nCtrl = pWnd->GetDlgCtrlID();
switch (nCtrl)
{
case IDC_BCOLOR:
pDC->SetBkColor(RGB(m_red,m_green,m_blue));
if ( NULL != m_hBrush )
::DeleteObject(m_hBrush);
m_hBrush = ::CreateSolidBrush(RGB(m_red,m_green,m_blue));
hbr = m_hBrush;
break;
}
return hbr;
}
Alternately, you could just keep a handle of a pre-created brush as a class member and return that.
Explanation:
The background color set using SetBkColor() applies to the text only, as you've noticed. In order to color the rest of the background, you need to return a brush of the appropriate color. This is what the code in bold does above. Windows does not delete the brush when it is done with it, so you must remember to do so after the window is destroyed (or before creating and returning a different brush, as shown).
Developers that like shiny objects also dig case mods and scratch-and-sniff stickers. Klaus Probst, The Lounge
|
|
|
|
|
|
Don't forget to invalidate the entire region of the controls to force a paint.
Jeremy L. Falcon
"The One Who Said, 'The One Who Said...'"
<nobr>
Homepage : Feature Article : Sonork = 100.16311
|
|
|
|
|
I know that this is probably simple for most of you guys but as I have just started to program in C++ I haven't figured out how to do this. I was trying to output an integer and pad the blank spaces as zeros. I have not seen anything in C++ that would let me do that in a simple form using the "cout" function. If I am wrong please enlighten me or give me some ideas.
Thanks
Paul_from_Connecticut
|
|
|
|
|
Use setfill just like this:
cout<<setfill('0')<<setw(5)<<100<<endl;
00100
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I have this DLL (non-MFC or anything like that) that does 2 things:
a) loads up an app, passes in some params. Simple, eh? Just call MyApp.exe, pass in the params, good to go. Next part.
b) finds one of the existing instances of MyApp.exe (don't care really which one), and pass in some params.
I'd normally use FindWindow, but since the title of my app changes, I can't search for "MyAppTitle".
Anybody know of any (relatively) simple methods of finding if MyApp.exe is already running?
(MyApp is a MFC-written, dialog-based, multi-instance-allowing app).
Thanks in advance.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
