Simple, you do *anything* and what your class does changes.
No, no, NO!
Come on, my example doesn't change the behaior of the class -- period. It
may
(and very well does) change the state or behavior of the *SYSTEM*, but we
are
*not* talking about that.
If your method changes the system, then the behaviour of your class now
includes that change to the system, a classes behaviour is *EVERYTHING*, not
just the class state. Even if it doesn't change the result of the call it
still changes behaviour(and even in your example it *could* change the
result of the call by throwing an exception). Its likely behaviour you
*must* document, and treat as a behaviour change.
Of course, if you don't consider adding the chance of new exceptions, new
ways to fail, or new possible constraints on parameters a change in
behaviour, I think our definitions of the word differ.
In everything but an idealized world, an override should be automatically
considered a change in behaviour. Even if you can guarentee ironclad that it
works without any behaviour change, you still leave the chance that a change
*elsewhere* could change behaviour elsewhere(which is part of the problem, a
code change *anywhere* is a change in behaviour, potentially in the entire
system, even if its not entirely noticable or anything that actually effects
change).
The point was, is, and will continue to be: virtual methods can be used
to
change behavior ***OR*** for other reasons that *DO NOT CHANGE BEHAVIOR*,
which
is what I've illustrated.
:
This does change behaviour. (And I don't
think I want/need to tell you how.)
Then don't post a response! We are (presumably) all here for
constructive
and
educational reasons, so you statement provides nothing and actually
confuses
the issue.
Please elaborate on why you think this changes class behavior. I'll
probably
learn something.
Simple, you do *anything* and what your class does changes. If that call
throws an exception you are adding a point of failure, if that call
instantiates objects you are using memory(and perhaps creating a memory
leak), if that call deletes random files you are probably angering
users, if
that call changes an object or variable the underlying method uses in
another class you could introduce unexpected bugs and it all may rain
down
on someone elses head because of it. Simply because your call leaves the
instance alone does *NOT* mean that its behaviour isn't changed, its
state
simply isn't. Behaviour is considerably more than simply what Method A
does
to Field B. Your example likely doesn't change the object but
potentially
changes the entire universe the object exists in.
I expect to read your headers, see and
recognize common patterns, understand
your identifiers, and use this interface
as it is with as little need for looking
it up in the docs as possible. If you
don't provide that, then that's one darn
good reason to look for another provider.
I'm not following. Maybe my statements weren't clear, but my
intention is
this: any well-meaning programmer that produces code potentially for
anyone
else (either directly or indirectly), should include complete and
correct
documentation.
It is extremely difficult (at best) to determine expected behavior
from
prototypes and definitions alone (meaning, no documentation, *NO*
comments).
If *you* can take naked prototypes and definitions and understand the
usage,
behavior, and characteristics of the interface, then you are in a
definite
minority. Personally, I rely heavily on the documentation.
Hendrik Schober wrote:
[...]
The only reason to make a function virtual
is to allw it to be overridden. Overriding
a function is changing behaviour.
Not true.
class A
{
public:
virtual void a()
{
// do something
}
};
class B : public A
{
public:
virtual void a()
{
A::a();
trace("processing a");
}
}
This doesn't change behavior, but is a very valid and real-world
case
of
virtual overrides.
This does change behaviour. (And I don't
think I want/need to tell you how.)
Don't expect us to carefully read douments
that contradict your code.
???
I do expect you to carefully read documents that define the
behavior,
usage,
and intent of my interfaces.
I expect to read your headers, see and
recognize common patterns, understand
your identifiers, and use this interface
as it is with as little need for looking
it up in the docs as possible. If you
don't provide that, then that's one darn
good reason to look for another provider.
[...]
Schobi
--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org
"Sometimes compilers are so much more reasonable than people."
Scott Meyers
--
Bret Pehrson
mailto:
[email protected]
NOSPAM - Include this key in all e-mail correspondence
<<38952rglkwdsl>>
