Boost C++ Libraries: Ticket #3730: compilation problem with is_virtual_base_of when class contains abstract methods

attachment set

Tue, 08 Dec 2009 12:53:41 GMT

attachment → test_diamond2.cpp

example program to reproduce problem

John Maddock — Tue, 08 Dec 2009 16:22:13 GMT

I can't at present see a way to fix this, here's a reduced test case:

#include <map>
#include <iostream>
#include <boost/type_traits.hpp>
class base {
public:
    base() : i(0) {}
    base(int i) : i(i)
    {
        m[i] = "text";
    }
    virtual void method1() = 0;
    virtual ~base() {};
private:
    int i;
    std::map<int, std::string> m;
};
class derived1 : virtual public base {
public:
};
class derived2 : virtual public base {
public:
};
class intermediate : public derived1, public derived2 {
public:
    intermediate() {}
    intermediate(int i) : base(i) {}
    void method1();
};
void intermediate::method1()
{
}
class final : public intermediate {
public:
    final() {}
    final(int i) : base(i) {}
};
//
// This class demonstrates what we need to make work inside is_virtual_base_of.
// MSVC compiles this just fine (likewise is_virtual_base_of), and only complains
// when attempting to use method1.  Other compilers (GCC, Intel on Linux) complain
// as soon as X is declared, likewise when instantiating is_virtual_base_of.
//
struct X : final, virtual intermediate
{
 X();
 X(const X&);
 X& operator=(const X&);
 ~X()throw();
};
int main( int /* argc */, char* /* argv */[] )
{
   X x;
   x.method1();
   boost::is_virtual_base_of<intermediate, final>::type t;
   return t.value != true;
}

cc set

manfred.doudar@… — Fri, 29 Jan 2010 01:41:52 GMT

cc manfred.doudar@… added

Since Final inherits from Intermediate, and X from both - you in effect have a "diamond" since X can take a path either through Final or Intermediate. In which case:

class final : public virtual intermediate

should resolve matters, no?

status changed; resolution set

John Maddock — Thu, 06 Jan 2011 11:30:35 GMT

status new → closed
resolution → wontfix

Class Final is defined outside our control - that's the issue - I'm closing this as "unfixable" for now.

barry.searle@… — Mon, 10 Jan 2011 12:25:05 GMT

What happens next? will it be removed from release versions of the library? or modified so it at least compiles?

anonymous — Mon, 10 Jan 2011 12:57:29 GMT

Nothing happens next - unless someone can come up with a fix - as far as anyone can tell it's simply not possible to make the trait work in every possible case like this - since the trait isn't part of the next std the only solution for occational difficult cases like this, is for the user to supply a specialisation of is_virtual_base_of.

HTH, John.

John Maddock — Mon, 10 Jan 2011 13:19:58 GMT

(In [67912]) Document the restrictions on is_virtual_base_of. Refs #3730.

John Maddock — Mon, 10 Jan 2011 13:23:55 GMT

(In [67913]) Document the restrictions on is_virtual_base_of. Refs #3730.

John Maddock — Mon, 10 Jan 2011 16:55:20 GMT

(In [67916]) Document the restrictions on is_virtual_base_of. Refs #3730.