|
Thanks CPallini,
What harm will be if we make the following 3 methods virtual? I think the design architecure is still clean as your sample without code change, right?
void do_common1();
void do_common2();
bool test_common();
regards,
George
|
|
|
|
|
George_George wrote: What harm will be if we make the following 3 methods virtual?
Actually no harm.
George_George wrote: I think the design architecure is still clean as your sample without code change, right?
Nope. In original design there is a (conventional) clean distinction between invariant pieces of (common used) code and methods designed to exploit polymorphism.
If you make the above methods virtual (and even if you don't change the remaining code) then you imply that polymorphism may happen on these little pieces of (common used) code. The developer examining Derived::do_things() method then should be aware that changes may are not only inside the method logic itself but also inside its 'elementary' commonly used blocks. This double-layered kind of polymorphism is not a mistake but doesn't contribute to project neatness.
BTW: As usual, this is going on my arrogant assumptions 
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
|
|
|
|
|
Thanks CPallini,
So, you mean for the 3 non-virtual "common" methods, it means derived class and base class should share common code? So, making the 3 non-virtual "common" methods virtual will make developer confused about potential efforts to override and provide differences (polymorphism)?
regards,
George
|
|
|
|
|
George_George wrote: So, you mean for the 3 non-virtual "common" methods, it means derived class and base class should share common code?
They are made for that purpose.
George_George wrote: So, making the 3 non-virtual "common" methods virtual will make developer confused about potential efforts to override and provide differences (polymorphism)?
It makes more difficult to interpretate do_thing() actual behaviour.
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
|
|
|
|
|
Thanks CPallini,
So, your answer and pattern to this question is, if code are common in both base and derived class, and derived class has no need to override it, do not make it virtual?
regards,
George
|
|
|
|
|
My answer to the question is slighty different: if small pieces of code are common in the hierarchy of classes (it applies mainly to complex class hierachies) then make those methods available to the whole class hierarchy (hence the base class is a good place for them) but don't make them virtual (if you don't need them, don't use them), leaving polymorphism be done in the right places, i.e. bigger methods (of course small and big tradeoff is subjective).
The above is, IMHO, the substance of the original text.
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
|
|
|
|
|
Thanks CPallini,
A small confusion. I think whether or not making a method virtual is dependent on whether derived class needs to override it, and has nothing to do with whether the method is big or small.
Why do you making decision whether a method is virtual or not also based on whether the method is big or small? what is your trade-off?
regards,
George
|
|
|
|
|
George_George wrote: A small confusion. I think whether or not making a method virtual is dependent on whether derived class needs to override it, and has nothing to do with whether the method is big or small.
Well this is true. Neverthless whenever we're talking about little pieces of common code, IMHO we have two points to consider:
(1) such methods have little functionality, i.e. if you don't need it you can replace the call with few lines of code.
(2) such methods are shared by a relevant number of other methods, i.e. you can find calls to such methods here and there.
From this viewpoint, IMHO, the design is cleaner if such pieces of code remains unchanged.
But, I know, at the end, it is matter of taste.
George_George wrote: Why do you making decision whether a method is virtual or not also based on whether the method is big or small? what is your trade-off?
No. I make my decision based on the overall structure of the project and provided the points (1) and (2) hold for such 'helper' methods.
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
|
|
|
|
|
Thanks CPallini,
Looks cool! You have made me clear about your points.
regards,
George
|
|
|
|
|
For mechanism, it's more flexible with an efficency tradeoff.
For semantics, the design will not be so clear.
Using virtual only when necessary will be a good choice considering efficiency and flexibility.
|
|
|
|
|
Thanks followait,
What is your trade-off? I think for the "little piece" common part, derived class can utilize it and overrides it, so why not make it virtual and protected?
regards,
George
|
|
|
|
|
In my opinion, a design would be better if it can guide the using of it, for example, it should prevent coders from overriding the functions that should not be overridden.
modified on Wednesday, March 19, 2008 8:57 AM
|
|
|
|
|
Thanks followait,
I think your points and answers to this question are, if code are common in both base and derived class, and derived class has no need to override it, do not make it virtual?
regards,
George
|
|
|
|
|
Simply, virtual function is invented for polymorphism.
In essence, a virtual function is an indirect call to a non-virtual function, so it can always replace a non-virtual function, with more flexibility and less efficiency.
|
|
|
|
|
Thanks followait,
1.
followait wrote: a virtual function is an indirect call to a non-virtual function
You mean through vtable?
2.
followait wrote: so it can always replace a non-virtual function
You mean virtual function has all the functions of a non-virtual function?
regards,
George
|
|
|
|
|
1.
Yes.
2.
Yes, but more.
|
|
|
|
|
Thanks followait,
Question answered.
regards,
George
|
|
|
|
|
Here is its implementation. Simply compared with ==. It seems not very useful in practical, doesn't it?
BOOL Equals(IN const RectF & rect) const
{
return X == rect.X &&
Y == rect.Y &&
Width == rect.Width &&
Height == rect.Height;
}
modified on Wednesday, March 19, 2008 2:00 AM
|
|
|
|
|
Ouch!
It may be fine if you use integers/whole numbers 
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hi 2 All!!!
When I install visual studio .Net 2003 in Windows Vista it does not installed why?
*****THANKS N ADVANCE****
Mathen.K
(I WILL TRY MY LEVEL BEST )
|
|
|
|
|
|
Probably because you suck at asking questions. It's been a long time, I am seeing you ask two different questions over and over. One is that your program will work in XP, but not on Vista. And the other is that you fail to install VS 2003 on Vista. And you won't ever give us a remotest clue to solve the problem.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
rowdy_vc++ wrote: why?
Maybe because it failed. Other than that, I'm unsure.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi all,
I have something like this in one of the header file:
VAL Val1[1];
where VAL is defined as:
struct VAL
{
LPWSTR pszVal;
LPWSTR pszEmailAdrVal;
ULONG ulVal;
SYSTEMTIME stVal;
BOOL fVal;
};
when I doing something like this in CPP file:
Val1[0] = {L"Jack", L"Jack@somewhere.com", 256, {2006, 3, 4, 9, 0, 0, 0, 0}, TRUE};
I got "missing ';' before '{'" compilation errors. What's the reason behind this?
Thanks,
|
|
|
|
|
LiYS wrote: Val1[0] = {L"Jack", L"Jack@somewhere.com", 256, {2006, 3, 4, 9, 0, 0, 0, 0}, TRUE};
You cannot do like this after the object has been constructed. The object gets contructed at the statement
VAL Val1[1];
So the only option is to do as follows
VAL Val1[1] = {L"Jack", L"Jack@somewhere.com", 256, {2006, 3, 4, 9, 0, 0, 0, 0}, TRUE};
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
