|
|
Thanks Steve,
I do not think it contains a sample of pre and post conditions and it only mentions the term pre and post condition check. I have read this article before.
If I am wrong, please feel free to correct me and point out the sample you refer in this article.
regards,
George
|
|
|
|
|
The pre and post checks would obviously be specific to the function and the interface "contract".
Steve
|
|
|
|
|
Thanks Steve,
My question is more about the pattern of pre- and post- condition check. Not about how to do a specific implementation. I have performend some search, but failed to find any definition.
Any recommended resources?
regards,
George
|
|
|
|
|
It is not public. Or did he just cheat changing it without notice?
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
|
|
|
|
|
It's public in class Derived in the second example.
Steve
|
|
|
|
|
You're right, I was blind  .
But we were both more than blind, because second example is completely wrong (recursive madness). 
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
|
|
|
|
|
Well, if I state it is a precondition then I don't check it (i.e. I may check it in Debug build, not in Release one).
BTW approach (1) is possibly better because it frees Derived class methods from implementing checking logic (I mean, using approach (2) you must remember to call foo(i) and this is not good expecially if Derived class developer is not the same person who designed Base class).
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,
Do you have some formal samples about pre- and post- condition pattern simple POC implementation? I have performed some search but can not find relevant stuff. Or you think my implementation is good enough.
Any ideas or recommendations?
regards,
George
|
|
|
|
|
No, I haven't.
I still stand in my original opinion: if I state a precondition then I haven't to check it.
Anyway, I like your first approach.
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,
With your agreement on my 1st approach of implementation, I think I am confident enough. 
regards,
George
|
|
|
|
|
See here[^].
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
|
|
|
|
|
So, you prefer implementation 1, I think, right, CPallini?
regards,
George
|
|
|
|
|
|
Thanks CPallini,
Can you let me know what is the bug please?
regards,
George
|
|
|
|
|
OK, I do the exercise for you... 
int main()
{
Derived d;
d.do_foo (1000);
return 0;
}
in the above code you need to change d.do_foo(1000); to d.foo(1000); to avoid recursion. BTW if you followed Stephen Hewitt's suggestion, declaring private the Derived class do_foo member, then the compiler was able to stop you from committing recursion madness (it's called OOP nemesis).
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,
You are correct. My bad. Actually, I have not tested it comprehensively. I just show my ideas about what the pattern looks like.
1.
So, if I fix the bug, you think both could be called pre- and post- condition pattern?
2.
If yes, what do you think the pros and cons of each implementation?
regards,
George
|
|
|
|
|
George_George wrote: 1.
So, if I fix the bug, you think both could be called pre- and post- condition pattern?
Well, a Design Pattern is the (at least at time of proposal) best solution to a well known problem. I don't know if one of your examples satisfy this requirement.
However we can say your examples satisfy the pre- condition design constraint.
George_George wrote: 2.
If yes, what do you think the pros and cons of each implementation?
I already asnwered (supposing the code correct) this, here [^].
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,
Your reply is clear. I am surprising to see we can not find a reference implementation (in C++, Java or etc.) of pre- and post- condition checkingt design pettern.
Let us just assume my reference implementation (1) is correct.
regards,
George
|
|
|
|
|
Hello everyone,
I am just a little confusing and not 100% confident about the following case. In the following sample, function call foo (called in function goo in class Foo) will call foo in class Goo, other than foo in class Foo, because we are using an instance of Goo g and no matter in which class, right?
(I have tested the result is correct, and I am asking the reason here.)
#include <iostream>
using namespace std;
class Foo {
public:
void goo()
{
foo();
}
private:
virtual void foo() = 0;
};
void Foo::foo()
{
cout << "I am here. " << endl;
}
class Goo : public Foo {
public:
void foo()
{
Foo::foo();
}
};
int main()
{
Goo g;
g.foo();
return 0;
}
thanks in advance,
George
|
|
|
|
|
George_George wrote: because we are using an instance of Goo g and no matter in which class, right?
No, Its instance of Goo and foo is a virtual function. Try foo in Foo as non-virtual function. But i wonder why you ask this simple question after some great questions.
|
|
|
|
|
Sorry, Rajkumar. It is my bad and typo. The code in the original post should be,
int main()
{
Goo g;
g.goo();
return 0;
}
Any comments or replies to my original question?
regards,
George
|
|
|
|
|
What change it seems same to me.
I mean yes it is the instance of Goo, but not only because this the object of Goo, it is because that foo is a virtual function. Since foo is a virtual function in class Foo it is bind at runtime to the final derived class Goo::foo. Lot of useful features using this feature of polymorphism. Base class can call the derive class function without knowing the derived class type, Callbacks in MFC like CWinThread::InitInstance is implemented using this feature that Developer of the library doenot know which is the class user going to create CMyWinThread derived class of CWinThread and overriding the InitInstance causes CMyWinThread::InitInstance is called back at CWinThread class.
|
|
|
|
|
Thanks Rajkumar,
What makes me confused is the pure virtual function, in the past I am not sure whether its behavior is like normal non-virtual function or plain virtual function.
Now I understand it resembles the same behavior as the normal virtual function, right?
regards,
George
|
|
|
|
|
George_George wrote: Now I understand it resembles the same behavior as the normal virtual function, right?
yes, but pure virtual functions requires that derived class must have an implementation while normal virtual function doenot restricts it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
