|
A word of advice not related to your problem: dump the macros! Use an enum instead, for example. One disadvantge of using macros is that they don't have scope and so can't be put into namespace and such.
enum { MAX = 1024 };
Steve
modified on Monday, March 17, 2008 1:49 AM
|
|
|
|
|
Thanks Steve,
My bad, any comments or replies to my original question?
regards,
George
|
|
|
|
|
I prefer the first; why make do_foo public ? This seems to go against the pattern being used.
Steve
|
|
|
|
|
Thanks Steve,
1.
Stephen Hewitt wrote: against the pattern
You mean template method pattern? or something which hides implementation details?
2.
Do you have some more formal examples about pre and post condition implementation in C++? The samples I wrote are by myself. I want to learn some formal ones.
regards,
George
|
|
|
|
|
|
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.
|
|
|
|