On Thu, Nov 11, 2004 at 10:07:43AM -0500, David Abrahams wrote:
Christoph Ludwig <cludwig@cdc.informatik.tu-darmstadt.de> writes:
As I mentioned in previous posts the following code program
#include <boost/type_traits/is_abstract.hpp> #include <iostream>
template<typename T> struct A { virtual void f() = 0; }
int main() { if(boost::is_abstract<A<int> >::value) { std::cout << "A<int> is abstract"; else { std::cout << "A<int> is not abstract"; } }
erroneously outputs "A<int> is not abstract" if compiled with gcc 3.4.
However, the regression tests report that gcc 3.4 passes the is_abstract test. The reason is that above error is triggered only if A<int> is not instantiated by the compiler; but is_abstract_test.cpp does not test class template specializations at all.
Why don't we just get is_abstract to cause the instantiation? It seems to me that you'd need to do that anyway in order to detect abstractness. As a matter of fact, I have some doubts about your diagnosis, since I can't imagine any way that is_abstract could work without doing the instantiation.
Well, it's really Giovanni Bajo's diagnosis who implemented the support for DR 337 in gcc 3.4, IIUC. So I am going to trust him on this... :-) There was agreement on gcc bugzilla that section 14.7.1/p4 of the standard requires the instantiation of the class template and that gcc is in error not to do so. But this bug won't be fixed in the 3.4 release series. I will give a workaround within is_abstract that forces the instantiation some thought later in the evening. But even if I come up with a patch, I think it is worth explicitly testing whether is_abstract interacts well with templates. This compiler bug has shown again that errors creep in where you don't expect them. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html