I have a class inheriting from two other classes, where one of the base classes has a virtual destructor, and the other one, a non-virtual destructor.
There are very few exceptions to the rule, but when a class does not have a virtual destructor you should not derive from it. It can be acceptable if you can provide guarantees that no code will EVER call a destructor on a derived object that uses a base type pointer, and that all non-virtual behavior in the base class, when that base class is used anywhere, will NEVER interfere with derived class designs. In your case I would probably go so far as to prohibit all dynamic allocation of the combined object. Even people who are language lawyers need to go back and double-check the code when you attempt to inherit with non-virtual destructors.
If people just follow the very good advice Herb Sutter (the guy who runs the c++ language committee) has frequently given, that all destructors should either be public and virtual or protected and non-virtual, then everyone would be a lot happier in life.
Just from your description and code sample, I'm pretty much certain that whatever you are proposing has a better solution. Most likely it involves composition.
edit: Following up, what you described is rarely done. The main reason for doing that type of thing is to mix with third-party libraries in extremely awkward situations that have no workaround. Beware, because the 3rd party library might have made assumptions about the function pointers because they one they gave you has a non-virtual destructor. Their code is likely going to be doing something that breaks or slices or otherwise damages the combined object. Inheritance is a very powerful link. Multiple inheritance of concrete classes is almost always the wrong design choice.
Edited by frob, 20 February 2014 - 03:54 PM.