|
Yes, you are right, I should have written: "the compiler cannot always inline virtual functions...". However, the rationale behind virtual function is for supporting polymorphism, hence I assumed, in my answer, that late binding was the case of interest.
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]
|
|
|
|
|
There are two rather common examples where virtual functions are resolved statically, and therefore can be inlined without problem:
1. Explicitely calling the base class implementation
2. Virtual destructors. The compiler will automatically create a chain of calls to destructors according to the inheritance chain. These are resolved statically. The only thing that may be resolved dynamically (at runtime) is the top level call, and even that only if the compiler cannot determine the actual class at compile time
class Shape {
bool state;
public:
inline virtual void initialize() {
state = false;
}
inline virtual ~Shape() {}
};
class Square : public Shape {
float width;
public:
virtual void initialize() {
Shape::initialize();
width = 0.;
}
~inline virtual ~Square() {}
};
int main() {
Shape* pShape = new Square;
pShape->initialize;
delete pShape;
return 0;
}
|
|
|
|
|
You can inline virtual functions just like any others: either by using the 'inline' keyword, or just by writing the function definition right into the declaration. Sometimes this makes sense (such as for destructors), sometimes it doesn't. It mostly depends on whether or not a compiler is able to decide what class a particular object pointer actually points to. Somtimes this can only be detemined at runtime and in that case, obviously, no inlining will occur.
More information and examples can be found on the web, e. g. here: http://msdn.microsoft.com/en-us/magazine/cc301407.aspx[^] or here: http://drdobbs.com/cpp/184403747[^]
In short - if the type of an object pointer can only be determined at runtime, then inlining is not possible, even if the base class and all derived classes do have inlined implementations of that function. If you really, absolutely, desperately need a function to be inlined, either make sure that a particular version is being called (if that is even possible), or simply don't use inheritance for that. That said, since inlining is really only the very last step in performance optimization, it's usally not a real issue: if you can't inline, then you just don't.
|
|
|
|
|
How to get attachment filename without download attachment file in C++ or C# or Java? Which library support this?
|
|
|
|
|
Attachment to what? Outlook? Gmail? Hotmail? Other?
|
|
|
|
|
Attachment to message in Gmail mailbox.
|
|
|
|
|
I'd suppose that one of the 24 million, six hundred thousand google search results for gmail c/c++ api[^] would have the answer?
|
|
|
|
|
I have made my virtual pc using virtual hard disk. but when i put files in my virtual hard disk via windows explorer, i can not see them in my virtual pc. Is there any way to access these files through the virtual pc. I m using windows CE 7 as OS in my virtual pc.
|
|
|
|
|
What does your question have to do with C/C++/MFC?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
hi,
how do i detect memory leak, in a win32 console project?
Zo.Naderi-Iran
|
|
|
|
|
|
If all else fails, you can use the Signal Flare debugging pattern: Increase the size of your allocations (one at a time) by ten, and rerun your program. When the memory leak increases by ten, you've found the problem.
|
|
|
|
|
|
|
If using protocol TCP and UDP how to use more network bandwidth?
Especially, how to limit transfer speed of other application, when my program is transferring data?
|
|
|
|
|
Q1: Increase the packet-size as much as practical. The header size is fixed, so by increasing the total size of the packet, you are minimizing the proportion of the data that is used to just transfer the header.
The downside is that more packets will fail a CRC check, meaning you'll have to download a larger number of larger chunks of data in the event of CRC failure.
Q2: Don't know. I certainly wouldn't want a program to explicitly screw with the transfer speed of an app I was already running. I suspect that the best solution would be to have the user pause/shut-down these other programs themselves.
|
|
|
|
|
Assume your program can,Then, why others program can not?
If all the programs can, what will be the result?
|
|
|
|
|
So your application is more important than any other and you should be given priority?
Consider using QoS services[^]
/* Charles Oppermann */
http://weblogs.asp.net/chuckop
|
|
|
|
|
I have two views ( CMainView and CMembersView ) in my SDI application. The code below resizes my MFC GridCtrl according to size of app's window when the view is initialized.
I get valid values for CRect grid_rect {top=0 bottom=952 left=0 right=1819} in CMainView. But in CMemberView I am having some undesired values.
void CMembersView::OnInitialUpdate()
{
CFormView::OnInitialUpdate();
initialized = TRUE;
CWnd *pGridCtrl = this->GetDlgItem(IDC_MEMBERSGRID);
ASSERT(pGridCtrl);
CRect rect,grid_rect;
CWnd *pWnd = this->GetOwner();
pWnd->GetClientRect(rect);
pGridCtrl->GetWindowRect(grid_rect);
grid_rect = rect;
grid_rect.left += 16;
grid_rect.top += 150;
grid_rect.bottom -= 300;
grid_rect.right -= 16;
pGridCtrl->MoveWindow(grid_rect);
Where am I going wrong ?
Future Lies in Present.
Manmohan Bishnoi
|
|
|
|
|
The window size is never specified when you first call pGridCtrl->GetWindowRect(grid_rect); in the OnInitialUpdate.
Please write some codelike below in your CMembersView::OnSize
CWnd *pGridCtrl = this->GetDlgItem(IDC_MEMBERSGRID);
ASSERT(pGridCtrl); if ( ::IsWindow(pGridCtrl->GetSafeHwnd()) )
{
pGridCtrl->MoveWindow(..<the_desired_size_of_gridctrl_in_the_CMembersView)
}
modified on Thursday, August 25, 2011 4:08 AM
|
|
|
|
|
Doesn't help much.
---------------------------------------------
" Future Lies in Present "Manmohan Bishnoi
|
|
|
|
|
I guess you do not catch all my meaning.
If you just set the grid position in OnInitialUpdate, then even it works. There still some problem after you resize your application.
To make sure it works in all case, you must do it inside OnSize
CMembersView::OnSize:
CWnd *pGridCtrl = this->GetDlgItem(IDC_MEMBERSGRID);
ASSERT(pGridCtrl); if ( ::IsWindow(pGridCtrl->GetSafeHwnd()) )
{
CRect rctClient;
this->GetClientRect(&rctClient);
pGridCtrl->MoveWindow(0, 0, rctClient.Width()/2, rctClient.Height());
}
modified on Thursday, August 25, 2011 10:19 AM
|
|
|
|
|
yes you were right. now code is working.
thanks.
---------------------------------------------
" Future Lies in Present "Manmohan Bishnoi
|
|
|
|
|
IIRC GetXXXRect take pointers as parameters. Have you tried with
pGridCtrl->GetWindowRect(&grid_rect);
Same comment for the GetClientRect call a few line above.
|
|
|
|
|
This is working fine :-
void CMainView::OnInitialUpdate() {
CFormView::OnInitialUpdate();
initialized = TRUE;
CWnd *pGridCtrl = GetDlgItem(IDC_SALEPURCHASEGRIDCTRL);
CRect rect,grid_rect;
CWnd *pWnd = this->GetOwner();
pWnd->GetClientRect(rect);
pGridCtrl->GetWindowRect(grid_rect); grid_rect = rect;
grid_rect.left += 16;
grid_rect.top += 150;
grid_rect.bottom -= 300;
grid_rect.right -= 16;
pGridCtrl->MoveWindow(grid_rect); .
.
.
This is not working properly:-
void CMembersView::OnInitialUpdate()
{
CFormView::OnInitialUpdate();
initialized = TRUE;
CWnd *pGridCtrl = this->GetDlgItem(IDC_MEMBERSGRID);
ASSERT(pGridCtrl);
CRect rect,grid_rect;
CWnd *pWnd = this->GetOwner();
pWnd->GetClientRect(rect);
pGridCtrl->GetWindowRect(grid_rect); grid_rect = rect;
grid_rect.left += 16;
grid_rect.top += 150;
grid_rect.bottom -= 300;
grid_rect.right -= 16;
pGridCtrl->MoveWindow(&grid_rect);
.
.
.
---------------------------------------------
" Future Lies in Present "Manmohan Bishnoi
|
|
|
|