|
P: n/a
|
Question is as in subject.
For example:
class BaseClass {
public:
void func() { do something; } // I don't want this function being
overloaded in its inherited class
};
class ChildClass : BaseClass {
public:
void func() { do otherthing; } // this should be inhibited when
compiling
}
| |
Share this Question
|
P: n/a
|
"modemer" <me@privacy.net.invalid> wrote in message
news:d1**********@domitilla.aioe.org... Question is as in subject.
For example:
class BaseClass {
public:
void func() { do something; } // I don't want this function being
overloaded in its inherited class
};
class ChildClass : BaseClass {
public:
void func() { do otherthing; } // this should be inhibited when
sorry, typo, should be: prohibited
compiling
}
| |
|
P: n/a
|
modemer wrote: Question is as in subject.
For example:
class BaseClass {
public:
void func() { do something; } // I don't want this function being
overloaded in its inherited class
};
class ChildClass : BaseClass {
public:
void func() { do otherthing; } // this should be inhibited when
compiling
}
The 'ChildClass::func' does not overload 'BaseClass::func'. The 'func'
name from the base class is _hidden_ by the derived class' member.
Perhaps when you learn how things work, you won't need the "prevention"
you ask about. What particular problem do you think you're going to
solve by preventing what you call "overloading"?
V | |
|
P: n/a
|
Victor Bazarov wrote:
Perhaps when you learn how things work, you won't need the "prevention"
you ask about. What particular problem do you think you're going to
solve by preventing what you call "overloading"?
The problem of a derived class designer trying to solve problems in a
problem domain that the base class designer knows little or nothing
about, using techniques that the base class designer didn't think of.
See also: "How can I force all derived classes, however remote, to
override this function," "How can I prevent anyone from deriving from
this class," and "How can I make everyone do what I know is best for them."
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com) | |
|
P: n/a
|
Pete Becker wrote: Victor Bazarov wrote:
Perhaps when you learn how things work, you won't need the "prevention"
you ask about. What particular problem do you think you're going to
solve by preventing what you call "overloading"?
The problem of a derived class designer trying to solve problems in a
problem domain that the base class designer knows little or nothing
about, using techniques that the base class designer didn't think of.
See also: "How can I force all derived classes, however remote, to
override this function," "How can I prevent anyone from deriving from
this class," and "How can I make everyone do what I know is best for them." http://www.siscom.net/~morgan/ | |
|
P: n/a
|
Pete Becker wrote: See also: "How can I force all derived classes, however remote, to
override this function," "How can I prevent anyone from deriving from
this class," and "How can I make everyone do what I know is best for
them."
Don't write the class.
--
Salu2 | |
|
P: n/a
|
"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:%a*******************@newsread1.mlpsca01.us.t o.verio.net... modemer wrote: Question is as in subject.
For example:
class BaseClass {
public:
void func() { do something; } // I don't want this function
being overloaded in its inherited class
};
class ChildClass : BaseClass {
public:
void func() { do otherthing; } // this should be inhibited when
compiling
}
The 'ChildClass::func' does not overload 'BaseClass::func'. The 'func'
name from the base class is _hidden_ by the derived class' member.
Perhaps when you learn how things work, you won't need the "prevention"
you ask about. What particular problem do you think you're going to
solve by preventing what you call "overloading"?
V
I feel so sleepy now, sorry for making 2 mistakes in this question. Right,
it shouldn't be overload.
Let me say this question in another way. Suppose I am a base class designer,
I believe my func() in base class is the best solution for certain goal.
This base class is going to be used by other programmers, they are just
allowed to create their own child class inherated from my base class, but I
don't want to write any email notice to say "func() is reserved for base
class, don't use it in your derived class, otherwise base::func() will never
be called when child::func() is called", I want to know how to let compiler
raise an error when the programmer happened defines func() in his child
class. | |
|
P: n/a
|
Julián Albo wrote: Pete Becker wrote:
See also: "How can I force all derived classes, however remote, to
override this function," "How can I prevent anyone from deriving from
this class," and "How can I make everyone do what I know is best for
them."
Don't write the class.
<g>
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com) | |
|
P: n/a
|
"James Aguilar" <jf**@cec.wustl.edu> wrote in message
news:d1**********@newsreader.wustl.edu... What you're asking is, "How do I make this function 'final,'" I think.
You don't.
http://www.parashift.com/c++-faq-lit....html#faq-23.9
- JFA1
I am a little bit disappointed with the FAQ's answer. It just likes choose
yes or no for base class inheritability. But I just want part of functions
in base class are final, others could be overrided. Maybe like you said, I
am not allowed to do what I want. | |
|
P: n/a
|
"modemer" <me@privacy.net.invalid> wrote in message
news:d1**********@domitilla.aioe.org...
"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:%a*******************@newsread1.mlpsca01.us.t o.verio.net... modemer wrote: > Question is as in subject.
>
> For example:
>
> class BaseClass {
> public:
> void func() { do something; } // I don't want this function being > overloaded in its inherited class
> };
>
> class ChildClass : BaseClass {
> public:
> void func() { do otherthing; } // this should be inhibited when
> compiling
> }
The 'ChildClass::func' does not overload 'BaseClass::func'. The 'func'
name from the base class is _hidden_ by the derived class' member.
Perhaps when you learn how things work, you won't need the "prevention"
you ask about. What particular problem do you think you're going to
solve by preventing what you call "overloading"?
V
I feel so sleepy now, sorry for making 2 mistakes in this question. Right,
it shouldn't be overload.
Let me say this question in another way. Suppose I am a base class
designer,
I believe my func() in base class is the best solution for certain goal.
This base class is going to be used by other programmers, they are just
allowed to create their own child class inherated from my base class, but
I
don't want to write any email notice to say "func() is reserved for base
class, don't use it in your derived class, otherwise base::func() will
never
be called when child::func() is called", I want to know how to let
compiler
raise an error when the programmer happened defines func() in his child
class.
Simply don't make the function virtual, and writers of the derived classes
will know (if they know C++) that the function cannot be overridden.
But, it's not your job to try to prevent them from "hiding" your function by
writing their own. They should know better. You could add a comment in the
class definition, where the function is declared, that this function is not
intended to be overridden and should also not be hidden by writers of
derived classes, but, honestly, simply making it not virtual should be
sufficient.
It's just not possible to prevent programmers from screwing up their derived
classes, if they really want to. But if you do your job well, and document
anything you think is important, then the rest should really be up to them
as professional programmers.
Just my $.02, of course.
-Howard | |
|
P: n/a
|
modemer wrote: Let me say this question in another way. Suppose I am a base class
designer,
I hope nobody's business card ever says that...
I believe my func() in base class is the best solution for certain goal.
This base class is going to be used by other programmers, they are just
allowed to create their own child class inherated from my base class, but
I don't want to write any email notice to say "func() is reserved for base
class, don't use it in your derived class, otherwise base::func() will
never be called when child::func() is called", I want to know how to let
compiler raise an error when the programmer happened defines func() in his child
class.
The ultimate way to do this in C++ is a sternly worded comment.
To attempt to back that up with muscle, read the book /Unit Test Frameworks/
by Paul Hamill, and focus on the Abstract Test pattern.
Write test cases for each of your base class's behaviors. Make the setUp()
for this test suite virtual. Write another Sternly Worded Comment advising
your Derived Class Designers to inherit the test suite and override the
setUp(). Create the derived class object in this method, and expect it to
pass all the tests the base class object passes.
This is an automated way to approach enforcing the Liskov Substitution
Principle, which a more formal title for the principle you seek - the Don't
Screw My Class Up Principle.
--
Phlip http://industrialxp.org/community/bi...UserInterfaces | |
|
P: n/a
|
modemer wrote: Suppose I am a base class designer,
I believe my func() in base class is the best solution for certain goal.
You are entitled to your opinion.
This base class is going to be used by other programmers, they are just
allowed to create their own child class inherated from my base class, but I
don't want to write any email notice to say "func() is reserved for base
class, don't use it in your derived class,
Can you make func() private?
otherwise base::func() will never
be called when child::func() is called", I want to know how to let compiler
raise an error when the programmer happened defines func() in his child
class.
Why do you care about an unrelated function in a derived class?
If you want to limit access to the internals of your Base objects, make
those internals private, and provide access only through methods in the
base class. E.g:
#include <iostream>
struct Base {
public:
Base( ): m_i( 0 ) { }
virtual ~Base( ) { }
virtual void set( int i ) {
// Override me all you want. You can't set m_i
// without going through proper channels.
std::cout << "I am the One True Way to set m_i.\n";
m_i = i;
}
virtual int get( ) {
std::cout << "I am the One True Way to get m_i.\n";
return m_i;
}
private:
Base( Base const& ) {
throw "Don't copy Base.\n";
}
Base operator = ( Base const& ) {
throw "Don't assign to Base.\n";
}
int m_i;
};
struct Derived: Base {
void set( int i ) {
// For a compile time error, try this: m_i = i;
Base::set( i ); // Pretty much your only option.
}
};
int main( ) {
Derived d;
d.set( 3 );
} | |
|
P: n/a
|
"modemer" <me@privacy.net.invalid> wrote in message
news:d1**********@domitilla.aioe.org...
"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:%a*******************@newsread1.mlpsca01.us.t o.verio.net... modemer wrote: Question is as in subject.
For example:
class BaseClass {
public:
void func() { do something; } // I don't want this function being overloaded in its inherited class
};
class ChildClass : BaseClass {
public:
void func() { do otherthing; } // this should be inhibited when
compiling
}
The 'ChildClass::func' does not overload 'BaseClass::func'. The 'func'
name from the base class is _hidden_ by the derived class' member.
Perhaps when you learn how things work, you won't need the "prevention"
you ask about. What particular problem do you think you're going to
solve by preventing what you call "overloading"?
V
I feel so sleepy now, sorry for making 2 mistakes in this question. Right,
it shouldn't be overload.
Let me say this question in another way. Suppose I am a base class
designer, I believe my func() in base class is the best solution for certain goal.
This base class is going to be used by other programmers, they are just
allowed to create their own child class inherated from my base class, but
I don't want to write any email notice to say "func() is reserved for base
class, don't use it in your derived class, otherwise base::func() will
never be called when child::func() is called", I want to know how to let
compiler raise an error when the programmer happened defines func() in his child
class.
Thank you guys gave so many suggestions. But it looks like all of these
suggestions are just like "tricky/rule" or even "algorithm", not a C++
standard feature, now I know C++ doesn't support this feature and I have to
find any way to workaround with my this quesion. | |
|
P: n/a
|
modemer wrote: > Question is as in subject.
>
> For example:
>
> class BaseClass {
> public:
> void func() { do something; } // I don't want this function being > overloaded in its inherited class
> };
>
> class ChildClass : BaseClass {
> public:
> void func() { do otherthing; } // this should be inhibited when
> compiling
> }
The 'ChildClass::func' does not overload 'BaseClass::func'. The 'func'
name from the base class is _hidden_ by the derived class' member.
Perhaps when you learn how things work, you won't need the "prevention"
you ask about. What particular problem do you think you're going to
solve by preventing what you call "overloading"?
...
Let me say this question in another way. Suppose I am a base class designer,
I believe my func() in base class is the best solution for certain goal.
This base class is going to be used by other programmers, they are just
allowed to create their own child class inherated from my base class, but I
don't want to write any email notice to say "func() is reserved for base
class, don't use it in your derived class, otherwise base::func() will never
be called when child::func() is called", I want to know how to let compiler
raise an error when the programmer happened defines func() in his child
class.
There's one thing that is not clear in your question. There are several
details in your posts that seem to suggest that in the real code the
base class' function is virtual. In the code sample above the function
is not virtual. Several people here missed this important fact and gave
you answers that apply to virtual functions only, and, surprisingly, you
didn't object. Can you, please, clarify whether the function you are
talking about is virtual or not?
--
Best regards,
Andrey Tarasevich | |
|
P: n/a
|
"modemer" <me@privacy.net.invalid> wrote in message
news:d1**********@domitilla.aioe.org... Thank you guys gave so many suggestions. But it looks like all of these
suggestions are just like "tricky/rule" or even "algorithm", not a C++
standard feature, now I know C++ doesn't support this feature and I have
to find any way to workaround with my this quesion.
I'd be interested in a real example of a member function that absolutely
should never be overridden by a derived class. It seems to me that to come
to this conclusion you would have to think of every imaginable derived class
and know that overriding your function can never work (but if that's true,
would anyone ever want to override it?). Also, as someone else mentioned,
the fact that your function is not virtual and cannot actually be overridden
anyway - only hidden - is a strong sign that it shouldn't be messed with. I
would expect most programmers to instinctively avoid hiding base class
functions because an object's behaviour would vary according to whether the
static type of a pointer or reference is the base or derived class. I think
you're in trouble if you have to design your classes to thwart incompetence.
DW | |
|
P: n/a
|
modemer wrote: "James Aguilar" <jf**@cec.wustl.edu> wrote in message
news:d1**********@newsreader.wustl.edu...
What you're asking is, "How do I make this function 'final,'" I think.
You
don't.
http://www.parashift.com/c++-faq-lit....html#faq-23.9
- JFA1
I am a little bit disappointed with the FAQ's answer. It just likes choose
yes or no for base class inheritability. But I just want part of functions
in base class are final, others could be overrided. Maybe like you said, I
am not allowed to do what I want.
I must admit I find myself wondering if there is _any_ legitimate reason
for what you are trying to do. Suppose I inherit from your class and
want to do something as simple and proper as to count the number of
times your function is called. So I override it, in my version add to a
counter and then call your version. What, specifically, could you be
doing in that function that is messed up by my doing this? Unless you
are avoiding virtuals altogether, and so inheritance is static - but
that is my problem, or the problem of the class users, who must avoid
situations requiring dynamic resolution.
--
Ron House ho***@usq.edu.au http://www.sci.usq.edu.au/staff/house | |
|
P: n/a
|
"modemer" <me@privacy.net.invalid> wrote in message
news:d1**********@domitilla.aioe.org...
"James Aguilar" <jf**@cec.wustl.edu> wrote in message
news:d1**********@newsreader.wustl.edu... What you're asking is, "How do I make this function 'final,'" I think.
You don't.
http://www.parashift.com/c++-faq-lit....html#faq-23.9
- JFA1
I am a little bit disappointed with the FAQ's answer. It just likes choose
yes or no for base class inheritability. But I just want part of functions
in base class are final, others could be overrided. Maybe like you said, I
am not allowed to do what I want.
That's exactly what I'm saying. There is no facility in the C++ language
that supports that behavior. Java lacks const-ness, which, IMO, is far more
important.
- JFA1 | |
|
P: n/a
|
"Andrey Tarasevich" <an**************@hotmail.com> wrote in message
news:ov********************@comcast.com... modemer wrote: > Question is as in subject.
>
> For example:
>
> class BaseClass {
> public:
> void func() { do something; } // I don't want this function
being > overloaded in its inherited class
> };
>
> class ChildClass : BaseClass {
> public:
> void func() { do otherthing; } // this should be inhibited when
> compiling
> }
The 'ChildClass::func' does not overload 'BaseClass::func'. The 'func'
name from the base class is _hidden_ by the derived class' member.
Perhaps when you learn how things work, you won't need the "prevention"
you ask about. What particular problem do you think you're going to
solve by preventing what you call "overloading"?
...
Let me say this question in another way. Suppose I am a base class
designer, I believe my func() in base class is the best solution for certain goal.
This base class is going to be used by other programmers, they are just
allowed to create their own child class inherated from my base class,
but I don't want to write any email notice to say "func() is reserved for base
class, don't use it in your derived class, otherwise base::func() will
never be called when child::func() is called", I want to know how to let
compiler raise an error when the programmer happened defines func() in his child
class.
There's one thing that is not clear in your question. There are several
details in your posts that seem to suggest that in the real code the
base class' function is virtual. In the code sample above the function
is not virtual. Several people here missed this important fact and gave
you answers that apply to virtual functions only, and, surprisingly, you
didn't object. Can you, please, clarify whether the function you are
talking about is virtual or not?
--
Best regards,
Andrey Tarasevich
Thanks for pointing out the key word "virtual". Actually in this question,
virtual or not is not important because my object is to prevent *specific*
function(not all functions) in base class being defined in derived class no
matter it's virtual or not as long as there is a way to do, if derived class
happened defined(we have to believe that programmers have different
understandings about a system), C++ compiler should raise an error, but
unfortunately, nobody could answer this question directly, that means there
is not this kind of feature in C++.
When I studied C++, I noticed that C++ is trying the best to offer all
possibilities to control how member function of class is handled, like
private/protect/public/virtual/static/overload/override/namingConvention
etc. This is why I am looking for if there is a feature like the one
mentioned in my question. If this feature exists, I think the code or logic
would be more clear, simple or even easier on bug control, source code
maintain. | |
|
P: n/a
|
On Tue, 22 Mar 2005 11:09:01 -0500 in comp.lang.c++, "modemer"
<me@privacy.net.invalid> wrote, Thanks for pointing out the key word "virtual". Actually in this question,
virtual or not is not important because my object is to prevent *specific*
function(not all functions) in base class being defined in derived class
I would be a lot more interested if you were asking how to accomplish
some goal, rather than asking how to *prevent* accomplishing
something. | |
|
P: n/a
|
"modemer" <me@privacy.net.invalid> wrote in message
news:d1**********@domitilla.aioe.org...
Thanks for pointing out the key word "virtual". Actually in this question,
virtual or not is not important because my object is to prevent *specific*
function(not all functions) in base class being defined in derived class
The virtual keyword *does* apply to a specific function! (Sure, there is
also virtual inheritance, but that's not what was being pointed out to you.)
Placing the virtual keyword in front of an individual function allows it to
be overridden in derived classes. By *not* placing the virtual keyword in
front of it, you *prevent* overriding that function. You cannot prevent
"hiding" the function, however.
no
matter it's virtual or not as long as there is a way to do, if derived
class
happened defined(we have to believe that programmers have different
understandings about a system), C++ compiler should raise an error, but
unfortunately, nobody could answer this question directly, that means
there
is not this kind of feature in C++.
Correct...there is no such feature. Our point has been that such a feature
is not needed.
You state that "programmers have different understandings about a system".
Well, that's a pretty broad statement, but if you have a programmer working
for you who doesn't know that a function without the keyword "virtual" is
not overrideable, then that programmer needs to go back to school! :-) It's
not a matter of differences of opinion on how a system works, it's basic
rules of C++, and it's vital that they (and you) understand it.
When I studied C++, I noticed that C++ is trying the best to offer all
possibilities to control how member function of class is handled, like
private/protect/public/virtual/static/overload/override/namingConvention
etc. This is why I am looking for if there is a feature like the one
mentioned in my question. If this feature exists, I think the code or
logic
would be more clear, simple or even easier on bug control, source code
maintain.
It's not neccesarily an error to "hide" a base class function. It may in
fact be exactly what is needed in some specific cases. But as the base
class writer, I can see that you might think it may *never* be useful (for
some specific function, anyways). You may even be right...but you may also
be wrong.
Your idea has been discussed before. As I believe was stated elsewhere, the
thought was a "final" keyword. You can do a search on groups.google.com,
using C++, final, and virtual as search terms, and you should find more info
on the subject.
-Howard | | This discussion thread is closed Replies have been disabled for this discussion. | |  Question stats - viewed: 2446
- replies: 20
- date asked: Jul 23 '05
|
