C++ Templates: Coding error or compiler bug?

Question

I'm trying to use templates to get std:list of items, where each item has a pointer to the list which contains it, but I keep hitting a compiler message.

Here's a very stripped down version of the code.

template <class E> class Item  
{
    public:
     E* owner; // pointer to list that owns us.
};

template <class E> class BaseList: public std::list<E>
{
protected:
    typedef std::list<E> inherited;
public:

    void push_back(const E &e)
    {
     E tmp(e);
     tmp.owner = this;  // This line gives the error.
     inherited::push_back(tmp);
    }
};

class MyList;

class MyItem : public Item<MyList>
{
};

class MyList : public BaseList<MyItem>
{
};

void foo()  // test code to instantiate template
{
    MyList l;
    MyItem m;
    l.push_back(m);
}

However, my compiler barfs at the line:-

     tmp.owner = this;

Error is:

[BCC32 Error] Unit7.cpp(30): E2034 Cannot convert 'BaseList<MyItem> * const' to 'MyList *'

It's like "this" has somehow become const, but I can't see why. Compiler is Codegear C++Builder 2009.

I admit I'm not 100% happy using templates, so I'm unsure if this is my problem or the compilers. The same code without template use compiles fine, but obviously that's not what I want, as I have several item/list classes that want to work this way.

Also, is there a better technique that would avoid having all the "owner" pointers in each item?

EDIT: I think I stripped the example down too far: "MyList" actually introduces new methods, which "MyItem" must then access through the "owner" pointer.

SUMMARY: Thanks for all comments and answers. As the accepted answer says, the problem is simply one of type incompatibility between pointer to a BaseList vs. MyList.

The issues raised about deriving from STL containers and alternative designs are also helpful, but the solution I've used is essentially identical to Luc Touraille's one below.

Answer 1

At line 30, "this" is a pointer to a BaseList<MyIteM>, not a MyList. You can substitute a class with a derived one, but not the other way around.

You can either typedef MyList to be a BaseList<MyItem>, like so:

typedef BaseList<MyItem> MyList

or let MyItem derive from Item<BaseList<MyItem> > instead.

When you derive from a type, you create a different type. When you typedef, you create an alias for that type. So when you typedef the compiler will accept this.

Answer 2

Shouldn't it be tmp.owner = static_cast<MyList*>(this). The type of E is MyList in the MyItem hence E* will be MyList* . The type of this pointer will be BaseList*, hence compiler gives the error that you can not convert the base class pointer to the derived class pointer.

Answer 3

In addition to the answers you already have, I would also point out that the standard library collection classes are not intended to be derived from, as they do not have virtual destructors, and none of their member functions is virtual.

Answer 4

It's hard to say if there's a better solution, when you don't say what it is you need. Why do each element need a pointer to the list they're stored in?

Anyway, bad things can happen when you inherit from standard containers. They don't have virtual destructors, so you have to be very careful.

A better solution might be to just provide a free function performing the push_back:

template <typename T>
void push_back(std::list<T>& list, const T& t) {
        T tmp(t);
        tmp.owner = this;
        list.push_back(tmp);
}

Apart from avoiding the nonvirtual destructor problem, it also solves your compiler error, because you now only have one type of list.

Of course, if we know why you need this owner pointer in the first place, better still solutions may exist.

Edit

In response to your edit and the comments, use composition, not inheritance:

struct House {
  std::string zipcode;
  std::list<Person> persons;

  void AddPerson(const Person& person) {
    Person tmp(person);
    tmp.owner = this; // The owner field should be a house, not the list of persons.
    persons.push_back(tmp);
  }
};

Although I'm not sold on the almost circular references you get when a House stores a list of Persons, and a Person has a pointer to the House it's in.

I'd prefer to decouple these classes as much as possible. If I want to send a letter to a person, I'd call SendLetter(Person, House). Send a letter to this person in that house.

Answer 5

On the side note, you should not extend any classes from std, they are not built for it.

Specifically they don't have virtual destructor so when you call delete on pointer to base class your derived class's destructor will never get called.

You can read more on it http://stackoverflow.com/questions/679520/advice-on-a-better-way-to-extend-c-stl-container-with-user-defined-methods

Answer 6

I like jalf's free function idea. I'd make it:

template <class X, class Y> // X must have a push_back(Y) member, Y must have an X* owner member
void push_back(X& container, Y value)
{
    value.owner = container;
    container.push_back(value);
}

This is agnostic over whether the X passed is

• a container itself,
• is derived from a container as in the original code
• or contains a container and has a forwarding push_back function

Answer 7

As it has already been pointed out, the affectation

tmp.owner = this;

fails because this doesn't have the same type as tmp.owner. One solution is to perform a cast, but to do so, you need to provide the container type to BaseList. This can be done using a typedef in Item. Here is the code:

template <class Item> class BaseList
{      
  public:

    void push_back(Item i)
    {
        i.owner = static_cast<Item::containerType *>(this); // note the cast
        items.push_back(i);
    }

    Item & back() { return items.back(); }

  protected:
    std::list<Item> items;
};


template <class Container> class Item
{
    public:
        typedef Container containerType; // Typedef used by BaseList

        containerType* owner; // pointer to list that owns us. 
};

I also removed the public derivation of std::list: as many said, this is (most of the time) best avoided ; you should consider using composition, or maybe private inheritance.

P.S.: I tried making owner private and BaseList<Item>::push_back friend of Item, but I didn't manage to do it. Is it possible at all? (If too long to answer in comment, feel free to ask a question and answer it)

Answer 8

Regarding const: The type BaseList<MyItem> * const that the compiler mentions is a red herring -- it's not a pointer-to-a-const-object, but a pointer that is const, i.e. an address that won't change. (When you think about it, this never changes to point to something else, does it?)