Re: [Boost-users] boost::exception_detail::error_info_base does not have virtual destructor

Subject: Re: [Boost-users] boost::exception_detail::error_info_base does not have virtual destructor
From: Ted Byers (r.ted.byers_at_[hidden])
Date: 2011-03-17 18:22:23

>From: boost-users-bounces_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Emil Dotchevski
>Sent: March-17-11 5:27 PM
>On Thu, Mar 17, 2011 at 1:58 PM, Ted Byers <r.ted.byers_at_[hidden]> wrote:
>>  I do have a little sympathy with your, and his, position, when 
>> dealing with extremely tight time constraints, but not a lot.  If one 
>> of the design criteria is that the code being produced must be widely 
>> portable, then I pass it through the range of platforms and compilers 
>> that we have to support, and as far as it is possible, I try to treat 
>> all warnings as errors.
>
>The virtual destructor warning goes directly against a conscious design
decision. In my opinion it also teaches programmers a bad habit. This
doesn't make the warning any less annoying of course, so I'm doing my best
to suppress it.

I would like to understand why making destructors virtual when there are
other virtual member functions might be seen as a bad habit.  

I would also appreciate it if you can educate me (while I am so old I can
recall fighting off T.Rex so I could enjoy my bronto-burgers, I'm not too
old to learn something new.  :-)  

What, precisely, was that conscious design decision, and what is the
rationale for it?

It is my experience that when two experienced developers disagree about a
practice, it is born of differences in the nature of the problems they have
faced in the past, and the information they have at their disposal.  If you
were to look at the applications I develop, you'd find very few objects
created on the stack.  Almost everything goes on the heap, managed by the
most appropriate of the boost smart pointers.  In my environmental modelling
software, for example, the application starts off with almost nothing in the
heap, but as the user builds the model, he may end up producing hundreds or
even thousands of instances of sometimes complex UDTs, and these UDTs are
often drawn from complex inheritance trees (but almost never involving
multiple inheritance ;-).  Connections between these instances can often be
quite complex, so there is, in the base class, a function that breaks all
connections among the objects before any attempt is made to delete anything.
Because the number of UDTs is quite large, and there is a common modelling
interface for which there are virtual functions (as pure virtual functions
in the base class), all these objects are managed in a single std::vector
containing smart pointers having pointers to the base class.  About 99% of
the effort in these applications is focussed on these UDTs, and the
containers managing them, and managing the resources they require (which
varies wildly among UDTs).

>The fact that we're having this discussion is another upside: it shows the
reader that at least some people think that it is an error to "fix" this
particular warning. :)

Agreed.

Cheers

Ted