Re: [boost] throw_exception rev. 44954 -> g++ warnings
Hi Emil,
I don't want to turn this into an argument; I only asked if there is an official Boost policy on the subject. Is there a requirement that boost compiles with -Wall without warnings on all compilers?
I don't know if there is a formal policy, but I know a couple of years ago boost wasn't clean for compiling with -Wall. In the meantime, someone must have worked pretty hard to eliminate all the warnings. It would be nice if that investment could be preserved. When developing new code, -Wall catches many problems that would otherwise go undetected until much later, when it is usually much more effort to figure out what's wrong since the mind has moved on to other things. I see, in the meantime you've checked in destructors, but without the virtual keyword. Therefore the warnings didn't go away. Is this an oversight? I'm currently testing with the "virtual" added (below). This seems to eliminate all warnings. Ralf Index: boost/exception/detail/counted_base.hpp =================================================================== --- boost/exception/detail/counted_base.hpp (revision 45057) +++ boost/exception/detail/counted_base.hpp (working copy) @@ -34,6 +34,7 @@ protected: + virtual ~counted_base() throw() { } Index: boost/exception/detail/cloning_base.hpp =================================================================== --- boost/exception/detail/cloning_base.hpp (revision 45057) +++ boost/exception/detail/cloning_base.hpp (working copy) @@ -23,6 +23,7 @@ protected: + virtual ~cloning_base() throw() { }
On Fri, May 02, 2008 at 10:25:56PM -0700, Ralf W. Grosse-Kunstleve wrote:
I don't want to turn this into an argument; I only asked if there is an official Boost policy on the subject. Is there a requirement that boost compiles with -Wall without warnings on all compilers?
I don't know if there is a formal policy, but I know a couple of years ago boost wasn't clean for compiling with -Wall. In the meantime, someone must have worked pretty hard to eliminate all the warnings. It would be nice if that investment could be preserved. When developing new
Right, warning free code is a good idea. Nevertheless one should specify Boost include path via -isystem path/to/boost and not via -I path/to/boost if one doesn't want to see the warnings in system libraries with gcc. Jens
On Fri, May 2, 2008 at 10:25 PM, Ralf W. Grosse-Kunstleve <rwgk@yahoo.com> wrote:
I see, in the meantime you've checked in destructors, but without the virtual keyword. Therefore the warnings didn't go away. Is this an oversight?
No, I wasn't trying to remove the warnings. I believe that the correct way to remove this particular GCC warning is to use -Wno-non-virtual-dtor. Other compilers generate bogus warnings also, for example msvc warns if you use strcpy, but the solution is not to "fix" the code and use strcpy_s; instead you disable the warning.
I'm currently testing with the "virtual" added (below). This seems to eliminate all warnings.
I don't need help "fixing" the warnings; these destructors are non-virtual by design. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Fri, May 2, 2008 at 10:25 PM, Ralf W. Grosse-Kunstleve <rwgk@yahoo.com> wrote:
I see, in the meantime you've checked in destructors, but without the virtual keyword. Therefore the warnings didn't go away. Is this an oversight?
No, I wasn't trying to remove the warnings.
I believe that the correct way to remove this particular GCC warning is to use -Wno-non-virtual-dtor.
Other compilers generate bogus warnings also, for example msvc warns if you use strcpy, but the solution is not to "fix" the code and use strcpy_s; instead you disable the warning.
This is not a bogus warning, it often catches real problems in the code. Just because in your case, the destructor does not need to be virtual, I should not be forced to globally disable an otherwise good warning.
I'm currently testing with the "virtual" added (below). This seems to eliminate all warnings.
I don't need help "fixing" the warnings; these destructors are non-virtual by design.
And what exact problem will arise if there's virtual specifier added when compiling for gcc? Or it will just spoil the purity of design? - Volodya
On Saturday 03 May 2008 13:01, Emil Dotchevski wrote:
On Fri, May 2, 2008 at 10:25 PM, Ralf W. Grosse-Kunstleve
<rwgk@yahoo.com> wrote:
I see, in the meantime you've checked in destructors, but without the virtual keyword. Therefore the warnings didn't go away. Is this an oversight?
No, I wasn't trying to remove the warnings.
I believe that the correct way to remove this particular GCC warning is to use -Wno-non-virtual-dtor.
How about temporarily disabling the warning in your library code with a pragma? See: http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html -- Frank
Emil Dotchevski wrote:
I don't need help "fixing" the warnings; these destructors are non-virtual by design.
How do you prevent then any users deriving from your classes, from adding their own destructors ? Their destructors might not be invoked, since the base destructor isn't virtual. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld:
How do you prevent then any users deriving from your classes, from adding their own destructors ? Their destructors might not be invoked, since the base destructor isn't virtual.
How does this look in code?
struct A { ~A() {} // non-virtual virtual void foo() {} }; struct B : A { ~B() {} void foo() {} }; /////////// A* a = new B; delete a; // doesn't call ~B(), but should Regards Hartmut
On Sat, May 3, 2008 at 1:13 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
Stefan Seefeld:
How do you prevent then any users deriving from your classes, from adding their own destructors ? Their destructors might not be invoked, since the base destructor isn't virtual.
How does this look in code?
struct A { ~A() {} // non-virtual virtual void foo() {} };
struct B : A { ~B() {} void foo() {} };
/////////// A* a = new B; delete a; // doesn't call ~B(), but should
1) The code that generates the bogus warning never deletes object of a derived type through a base type pointer, so your example is irrelevant to this discussion. 2) The types that generate the warnings are not part of the public interface of the library and users should not be deriving them. 3) In general, there are two ways to protect users from making this type of mistake: - One is to make the destructor public and virtual; this tells the user that they are welcome to delete an object through the base type pointer. - The other is to make the destructor protected and non-virtual, which tells the user that they are not allowed to delete an object through the base type pointer. Both are equally valid and therefore the compiler is wrong to issue a warning in the latter case. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Peter Dimov wrote:
Stefan Seefeld:
How do you prevent then any users deriving from your classes, from adding their own destructors ? Their destructors might not be invoked, since the base destructor isn't virtual.
How does this look in code?
#include <iostream> struct Base { ~Base() { std::cout << "~Base" << std::endl;} }; struct Derived : Base { ~Derived() { std::cout << "~Derived" << std::endl;} }; void destruct(Base *b) { delete b;} int main(int, char **) { Derived *derived = new Derived; destruct(derived); } Run the above code as is, and with the base destructor made virtual, to see the difference. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
AMDG Stefan Seefeld wrote:
#include <iostream>
struct Base { ~Base() { std::cout << "~Base" << std::endl;} };
struct Derived : Base { ~Derived() { std::cout << "~Derived" << std::endl;} };
void destruct(Base *b) { delete b;}
int main(int, char **) { Derived *derived = new Derived; destruct(derived); }
Run the above code as is, and with the base destructor made virtual, to see the difference.
That's true, but AFAICT, completely irrelevant in this case. In Christ, Steven Watanabe
AMDG Stefan Seefeld wrote:
Emil Dotchevski wrote:
I don't need help "fixing" the warnings; these destructors are non-virtual by design.
How do you prevent then any users deriving from your classes, from adding their own destructors ? Their destructors might not be invoked, since the base destructor isn't virtual.
The class is an implementation detail of the library, isn't it? User's should not be deriving from it at all. In Christ, Steven Watanabe
participants (9)
-
Emil Dotchevski -
Frank Mori Hess -
Hartmut Kaiser -
Jens Seidel -
Peter Dimov -
Ralf W. Grosse-Kunstleve -
Stefan Seefeld -
Steven Watanabe -
Vladimir Prus