Any way to allow forward declaration in a template class?

Question

I have a template class defined as such:

template <typename T> void ProxyNoOp(T *) {} template <typename T> void ProxyDelete(T * ptrT) {delete ptrT;} template <typename T, typename C, void (* Release)(T *) = ProxyNoOp<T> > class Proxy { public: class Container : public std::list<T *> { public: Container() {} ~Container() {clear();} void clear() { iterator clsEnd = end(); for (iterator clsCurrent = begin(); clsCurrent != clsEnd; ++clsCurrent) { T * ptrT = *clsCurrent; static_cast<Proxy *>(ptrT)->m_ptrContainer = NULL; Release(ptrT); } } }; private: iterator m_clsPosition; C * m_ptrContainer; public: Proxy() : m_ptrContainer(NULL) {} ~Proxy() { if ( m_ptrContainer != NULL ) { Container * ptrContainer = static_cast<Container *>(m_ptrContainer); static_cast<std::list<T *> >(ptrContainer)->erase(m_clsPosition); } } C * GetContainer() const {return m_ptrContainer;} }; 

Most of the code has been removed or modified for the sake of brevity. The idea of ​​the data structure is that the container does not support references to the contained elements, but the elements contained in it support the reference to the PLUS container at their position in the container, making deletion quick (constant time) and automatically (called in the destructor)

The problem with this approach can be demonstrated with this code:

 #include "proxy.h" // the above template class class Child; class Parent : public Proxy<Child, Parent>::Container {}; class Child : public Proxy<Child, Parent> {}; 

When compiling Parent definition of Proxy<Child, Parent>::Container causes an error in this line: static_cast<Proxy *>(ptrT)->m_ptrContainer = NULL; - At the compilation point, Child not defined, only declared. If you reorder the Parent and Child declarations as follows:

 #include "proxy.h" class Parent; class Child : public Proxy<Child, Parent> {}; class Parent : public Proxy<Child, Parent>::Container {}; 

the definition of Proxy<Child, Parent> causes an error in this line: Container * ptrContainer = static_cast<Container *>(m_ptrContainer); , the reason is the same as before - at this compilation point, Parent not fully defined.

Is there any way around this and using patterns? Is there a standard data structure in STL, BOOST, etc. that does this?

EDIT:

The code will not compile as is, I should have been more clear about this (to quote myself from above: most of the code has been removed or modified for brevity.). It doesn’t actually use std::list<T *> , but the user is double-linked, which is actually the same. I did not want to post a ton of helper code when I asked only about this problem.

I did not ask for criticism on the data structure itself (although I am fine to hear it), but for those who wonder why it was created here, there are several examples:

The game engine has models and instances of these models, for example, a war game in which there is one model of tanks and any number of tanks created from it. Classes can be written as such:

 class Instance; class Model : public Proxy<Model, Instance, ProxyDelete<Instance> >::Container {...}; class Instance : public Proxy<Model, Instance, ProxyDelete<Instance> > {...}; 

When a model is deleted, all instances created from this model must also be deleted (therefore, the template parameter ProxyDelete<Instance> ), since it does not make sense for the instance to exist without the model from which it was made.

Suppose your rendering of a graphical user interface (GUI) keeps track of all visible elements (buttons, frames, etc.), so it knows what to do, but the text is rendered differently, as this is a different call to the graphical API:

 class GuiTextElement; class GuiRenderer : public Proxy<GuiRenderer, GuiTextElement, ProxyNoOp<GuiTextElement> >::Container {...}; class GuiTextElement : public Proxy<GuiRenderer, GuiTextElement, ProxyNoOp<GuiTextElement> > {...}; 

---

Less discerning would say: "Why don't you just add std::list<Instance *> as a member of Model and std::list<GuiTextElement *> as a member of GuiRenderer ?". Here are a few reasons:

• Elements belonging to their containers are not automatically deleted when the container is destroyed (yes, I know boost::ptr_list ).
• There is no way, without adding another member of the class, to refer to the container using the contained element. For example, to get a Model from Instance .
• If you added a class member to run # 2, you will also need to update it when the items are removed from their containers.
• For speed fanatics - if the contained elements do not support the iterator in their position in the container, before this element can be deleted, you must first find it.

Answer 1

I don’t think the code you showed us shows the problem you are asking for.

I made minimal changes to get past the earlier compiler errors, so I could get to the point where I could reproduce your problem. But by doing this, your problem does not exist.

Here are my changes:

• Add #include <list> .
• Replace each instance of iterator with typename Container::iterator
• Make Container inherit from list publicly, not privately, so I get access to its type iterator .

You can try adding them one by one to find out which errors are solved by each of them: none of them has anything to do with your problem. Or you can download the code and compile it yourself.

I compiled this using three different compilers: clang-4.2, g ++ - 4.6 and g ++ - 4.2-apple; in C ++ 11 and C ++ 98 modes, where necessary; with enabled -Wall. In all cases, it compiles without any errors or warnings.

Also, I don’t see how the linked string can have the error you described. It doesn't matter if T or C incomplete, because all you do is:

• static_cast a T * to a Proxy * , which requires only a T declaration not defined.
• Access to the Proxy element, which does not depend on the type T
• Set the C * value to NULL, for which you only need to declare C , and not defined.

The previous line depends on calling operator * on iterator and, apparently, for your class, which may be dependent on T or C , but this cannot lead to an error on the next line.

So, there are several possibilities:

• The error is not what you described and did not indicate on the line you described, and the problem is in the iterator class or list class that you did not show us.
• The code you showed us is so different from your real code that it no longer has a trace of the part that causes the problem.
• My trivial changes are not as trivial as I thought, and somehow fixed your problem.