Virtual function 'BasicMidReader ::~BasicMidRead er()' conflicts with base class 'base 'TMemoryStream'

[tomek]

Can anybody explain why can I not get rid of the above message
in the following class definition? [I am using Borland C++ Builder 5.0]
Thank you in advance.
class BasicMidReader : public TMemoryStream
{
//some private date
public:
BasicMidReader( char* FN)
{// some code}
~BasicMidReader () {// some code}
};

[David Fisher]

"tomek" <ts**@op.pl> wrote:

Can anybody explain why can I not get rid of the above message
in the following class definition? [I am using Borland C++ Builder 5.0] .... class BasicMidReader : public TMemoryStream
{
//some private date
public:
BasicMidReader( char* FN)
{// some code}
~BasicMidReader () {// some code}
};

I haven't used Borland C++, but just a guess:

"virtual function 'BasicMidReader ::~BasicMidRead er()' conflicts with base
class" sounds like TMemoryStream could have a virtual destructor, and you
haven't declared ~BasicMidReader () as virtual. If so, I would expect this to
be a warning rather than an error, since inherited virtual functions are
also virtual - even if they don't say so (but they should !)

(BTW: in general, all destructors should be virtual unless you are sure the
class will never be used as a base class - this even applies if the
destructor is empty (ie. there is nothing to explicitly delete)).

David F

[Victor Bazarov]

"David Fisher" <no****@nospam. nospam.nospam> wrote...

"tomek" <ts**@op.pl> wrote:

Can anybody explain why can I not get rid of the above message
in the following class definition? [I am using Borland C++ Builder 5.0] ...

class BasicMidReader : public TMemoryStream
{
//some private date
public:
BasicMidReader( char* FN)
{// some code}
~BasicMidReader () {// some code}
};

I haven't used Borland C++, but just a guess:

"virtual function 'BasicMidReader ::~BasicMidRead er()' conflicts with base
class" sounds like TMemoryStream could have a virtual destructor, and you
haven't declared ~BasicMidReader () as virtual. If so, I would expect this

to be a warning rather than an error, since inherited virtual functions are
also virtual - even if they don't say so (but they should !)
Why should they? If the language says that 'if any base class has
a virtual destructor, the class' destructor is virtual even if not
declared such', why declare it virtual? It's virtual already.
(BTW: in general, all destructors should be virtual unless you are sure the class will never be used as a base class - this even applies if the
destructor is empty (ie. there is nothing to explicitly delete)).

That is nonsense. Even if you use some class as a base class for
something else, its destructor doesn't have to be virtual if you
will never delete a dynamically allocated object polymorphically .

Declaring functions virtual when there is no need, only leads to
performance degradation and wasted space.

Victor

[David Fisher]

"Victor Bazarov" <v.********@com Acast.net> wrote:

inherited virtual functions are
also virtual - even if they don't say so (but they should !)

Why should they? If the language says that 'if any base class has
a virtual destructor, the class' destructor is virtual even if not
declared such', why declare it virtual? It's virtual already.

Just to make it clearer to the reader.

(BTW: in general, all destructors should be virtual unless you are sure the class will never be used as a base class - this even applies if the
destructor is empty (ie. there is nothing to explicitly delete)).

That is nonsense. Even if you use some class as a base class for
something else, its destructor doesn't have to be virtual if you
will never delete a dynamically allocated object polymorphically .

Declaring functions virtual when there is no need, only leads to
performance degradation and wasted space.

Of course; I should have said, "unless you are sure the class will never be
used as a polymorphic base class." But assuming that the writer does not
have complete control over the future use of the class (which is most of the
time in a software company), you never know how the class is going to be
modified over time. It is also easy to forget to make a destructor virtual,
and hard to track this down if there is a problem (it happened to me !)

David F