By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,804 Members | 1,634 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,804 IT Pros & Developers. It's quick & easy.

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

P: n/a
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}
};


Jul 22 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
"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::~BasicMidReader()' 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
Jul 22 '05 #2

P: n/a
"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::~BasicMidReader()' 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
Jul 22 '05 #3

P: n/a

"Victor Bazarov" <v.********@comAcast.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
Jul 22 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.