On 16 April 2012 10:20, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
I don't see what this has to do with abstract classes.
struct A { virtual void foo() {} }; struct B : A {};
boost::shared_ptr<A> p(new B);
should issue that warning.
If you bother to try that, you'll find that shared_ptr will correctly call B's destructor, so it shouldn't issue a warning. It also demonstrates why you can't rely on the warning, since it will disappear with the slightest of changes.
This isn't just about Boost.Exception. I'm not arguing against it making its destructor virtual.
All the warnings being reported are about error_info not having a virtual destructor; I don't see anything specific to shared_ptr here.
The warning turns up in shared_ptr_test. I think I mentioned that before.
First, it's specific to that compiler. What if tomorrow a new compiler decides to add that kind of warning too?
You really can't program for future compiler warnings.
What if it occurs in slightly different scenarios?
Explain please.
Also it's not clear how warnings are suppressed with those mechanisms, especially when templates are involved.
They're not clear to you because you never use them.
See, we have something that seems to depend on include order here. That's the worst possible behaviour.
That's the system header pragma, which, as I previously said, is problematic. I claimed that the warning mechanism introduced in 4.6 is not fragile. Please stop confusing the two.
It looks like if I include boost/exception_ptr.hpp first, then all possible warning messages (which *are* useful) would be suppressed from the boost/shared_ptr.hpp header.
That's a problem in exception, not with the change we're discussing. It probably should move its warning pragmas to after it includes other headers.
I've made codebases of several hundreds of thousands of lines of code warning-free on a variety of different compilers, yet I cannot say I share your experience.
Well done, that's great, but different development techniques are available. Much of boost is pretty low level, so we often include code that would be problematic in higher level development. shared_ptr deals with deleting objects so that we don't have to. We do need to put thought into disabling warnings, and not just do it everywhere. But a dogmatic insistence on the correctness of all warnings is almost as bad as dismissing them out of hand.