|
|
A pure virtual destructor is any destructor marked as virtual with = 0 after it's signature, e.g:
class T
{
public:
virtual ~T() = 0;
};
Making a destructor pure virtual means very little more than making the destructor virtual (and you do that to make sure the correct destructor is called when you delete an object through a base class pointer). The additional bit is that it means the derived class has to define it's own destructor and not rely on the base class one.
One additional wrinkle is that all pure virtual destructors have to have an implementation, unlike normal pure virtual member functions which don't have to have one.
Cheers,
Ash
|
|
|
|
|
Hi,
I have developed and application based on modeless dialogs (the view is a formview and the others are CDialog and I show and hide them as corresponds). But I have a problem because when a modeless dialog has the caption, the mainframe loses it and I cannot access to the menu and toolbar from acceleratos because they don't have the caption.
How could I keep always caption on the mainframe? Maybe all dialogs can be defined as formview?
Thank in advance
|
|
|
|
|
Don't make the dialog a child of your main window, set its parent window to NULL. In that way it will be a child of the desktop and will not take the focus from your main window.
It's time for a new signature.
|
|
|
|
|
Or you can leave it like child of your window and put return FALSE in OnInitDialogfunction
|
|
|
|
|
What? 
It's time for a new signature.
|
|
|
|
|
Hi,
Thank you for your help, but unfortunately it didn't work.
I set:
BOOL CDlgListaPt::Create()
{
return CDialog::Create(CDlgListaPt::IDD);
this->SetParent(NULL);
}
and also tried in Oninitdialog method but the mainframe lose caption
my dialog is a popup non-modal dialog that is created from the view (what is a formview)
If I change the dialog style to child, the mainframe keeps caption but I cannot control de dialog.
The other solution returning false in oninitdialog it didn't work either.
Regards
|
|
|
|
|
how many threads can possibly be made in a program please explian launguage wise
|
|
|
|
|
CreateThread documentation [^], Remarks section:
The number of threads a process can create is limited by the available virtual memory. By default, every thread has one megabyte of stack space. Therefore, you can create at most 2,048 threads. If you reduce the default stack size, you can create more threads. However, your application will have better performance if you create one thread per processor and build queues of requests for which the application maintains the context information. A thread would process all requests in a queue before processing requests in the next queue.
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]
|
|
|
|
|
|
jt_snjy07 wrote: how many threads can possibly be made in a program please explian launguage wise
http://www.nvidia.com/object/fermi_architecture.html[^]
Thousands, many thousands.... probably not the architecture you meant.... but you didn't specify any limits. 
_________________________
John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
Shhhhh.... I am not really here. I am a figment of your imagination.... I am still in my cave so this must be an illusion....
|
|
|
|
|
It depends on the thread library's implementation. For example if you were mad enough to create a user mode library then the number of threads would depend on how many thread contexts you could fit into memory in one process. If you're using kernel threads then it depends on how the OS is implemented and how many thread contexts it reserves space for.
Cheers,
Ash
|
|
|
|
|
Whenever I hear this question (it comes up a lot) I immediately suspect it's from someone who's application is using way too many.
Steve
|
|
|
|
|
C calling convention we all know defines a way how the parameters are pushed onto the stack.
My question is when and how does this C calling conventions matters to a user?
When the user will have to bother about the calling conventions in his project?
|
|
|
|
|
For instance when you write a dll that could be used in programs which are using another calling convention. Typically, using a C dll in a VB program.
|
|
|
|
|
|
|
Nah, It's time for WTF.
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]
|
|
|
|
|
WTF (What The F..k) ??? you mean WPF!
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
No, I meant just WTF: bad irony as you may call it (The OP looks, IMHO, a bit pointless).
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]
|
|
|
|
|
CPallini wrote: (The OP looks, IMHO, a bit pointless).
He also sounds a bit clueless.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I have been using it for 1 1/2 years and love it.
-Saurabh
|
|
|
|
|
QT is more easy to use than MFC, i think.
|
|
|
|
|
I have to agree there. I've only recently started getting into QT and I'm impressed. I can't see why I'd ever bother with MFC again if I was given a choice.
Steve
|
|
|
|
|
I'm currently updating my XCrashReport article, and I had forgotten that I have some assembler in it:
__asm
{
mov eax, fs:[4]
mov pStackTop, eax
}
The purpose of this is to get the top of the stack, so I can do a stack dump. Unfortunately, I need to replace it, since VS doesn't allow asm code when compiling for x64.
I have found this code, which works ok in x86:
NT_TIB *pTib = (NT_TIB *)NtCurrentTeb();
PVOID pStackTop = pTib->StackBase;
I am just wondering if this will work on x64 as well (haven't had a chance to try it yet).
Anyone have any experience with this technique?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
