Accelarated C++ doubt.

[Old Monk]

Hi all,

I have got a doubt in Koenig& Moo's AC++.
On page 228 and 230, authors provide definitions for Core and Grad
classes. Grad IS-A Core, i.e. public inheritance.
What puzzles me is that both have a non-virtual read member function
in the public interface.
std::istream& read(std::istream&);
It goes against the usual norm to not redefine non-virtual member
functions in derived classes (Meyers Item#37.)

Syntactically it's fine but I am suspecting if I got the authors'
wrong.
Am I missing on something?

Thanks,
Ol' Monk

[Alf P. Steinbach]

* Old Monk:

I have got a doubt in Koenig& Moo's AC++.
On page 228 and 230, authors provide definitions for Core and Grad
classes. Grad IS-A Core, i.e. public inheritance.
What puzzles me is that both have a non-virtual read member function
in the public interface.
std::istream& read(std::istream&);
It goes against the usual norm to not redefine non-virtual member
functions in derived classes (Meyers Item#37.)

Why should they redefine non-virtual member functions in derived
classes?

And since they're doing exactly that (according to you) your comment
doesn't seem to make much sense?

Can you give a link to Meyer's item #37, or if not, perhaps a quote?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Victor Bazarov]

Old Monk wrote:

I have got a doubt in Koenig& Moo's AC++.
On page 228 and 230, authors provide definitions for Core and Grad
classes. Grad IS-A Core, i.e. public inheritance.
What puzzles me is that both have a non-virtual read member function
in the public interface.
std::istream& read(std::istream&);
It goes against the usual norm to not redefine non-virtual member
functions in derived classes (Meyers Item#37.)

Syntactically it's fine but I am suspecting if I got the authors'
wrong.
Am I missing on something?

Probably the fact that a recommendation is just that, a recommendation.
You don't have to follow it, if that suits your purpose.

Unless it's a hard rule written in the language Standard (like "thou
shalt not dereference a null pointer"), not following it does _not_
make it wrong. It's up to you to understand why certain rules exist
and conduct your programming activities accordingly. It's called
_freedom_ and it comes with the understanding of the consequences.

Getting to the item #37, defining a certain function in a class may
be a requirement for using that function through a template, i.e. not
necessarily polymorphically. If the behaviour of the class must change
but the function is not virtual, there is no other way but to redefine
it.

Do not take everything you read literally.

Victor

[Francis Glassborow]

In article <a1**************************@posting.google.com >, Old Monk
<wv********@hotmail.com> writes

Hi all,

I have got a doubt in Koenig& Moo's AC++.
On page 228 and 230, authors provide definitions for Core and Grad
classes. Grad IS-A Core, i.e. public inheritance.
What puzzles me is that both have a non-virtual read member function
in the public interface.
std::istream& read(std::istream&);
It goes against the usual norm to not redefine non-virtual member
functions in derived classes (Meyers Item#37.)

Syntactically it's fine but I am suspecting if I got the authors'
wrong.
Am I missing on something?

Read a few more pages. However the thing that I would have an issue with
is their use of protected data. Protected data buys too little.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects