"Anthony Heading" <anthony@magix.com.sg> wrote in message news:<bkupth$ra9$1@catv02.starcat.ne.jp>...
[color=blue][color=green]
> > Collection<Animal> depends on Animal<Collection> (via inheritance),
> > but Animal<Collection> depends on Collection<Animal> (via T::Name).
> > Can't do that.[/color]
>
> So I infer... but the rationale escapes me. Consider for contrast the code
> attached below, which _does_ run fine.
> It seems that function names are allowed to have such a circular dependency
> in templates, but not types.
> Why fundamentally is this OK, but the types are a no-can-do?[/color]
Actually, types are fine, too. What you did differently here was put
the use inside a function. Functions are exempt from this rule because
the compiler can pretend as though they are processed out of line,
whereas it can't generally do the same for declarations in the class.
For instance, this code compiles as well:
template <typename T> struct Animal {
void f () { typedef typename T::Name name; }
};
template <template <class> class T>
struct Collection : T< Collection<T> > {
typedef char *Name;
};
int main () { Collection<Animal>().f(); }
The reason this works is because the compiler can reinterpret Animal
thus:
template <typename T> struct Animal { void f (); };
template <typename T>
inline void Animal<T>::f () {
typedef typename T::Name name;
}
Note that the mutual dependence between the class definitions is gone
-- the definition of Animal does not use T at all. As a result,
Animal< Collection<Animal> > and Collection<Animal> can be fully
processed, and then Animal::f() can work with the result.
Note, also, that this only applies to the bodies of the functions. For
instance, you can't do this:
template <typename T> struct Animal {
void f (typename T::Name *);
};
This reintroduces Animal's dependence on T.
[color=blue][color=green]
> > Perhaps there should be a third class with traits for Animal, such
> > that Collection< Animal<Traits> > would be used instead. More likely,
> > Animal should either have a hardcoded Name type, or it should be some
> > kind of global (or scoped) typedef -- are you really going to use
> > Animals with different types of Name in your program?[/color]
>
> I am. Obviously this is somewhat of a toy example, but one could imagine
> Asian animals whose
> Names are wchar_t. Clearly these would have need a Collection zoo of their
> own, since the
> type signature is different, but yes I could have both in the same program.[/color]
It's hard for me to critique a toy program in a way that applies to
the real program it models, so I'll leave that alone. :)
[color=blue]
> With a real program, I have templates mixed into a single class, and I just
> find it puzzling
> that the _functions_ can happily cross-call each other by passing in the
> aggregate class as
> a template param to its constituents, but the _types_ cannot be used that
> way.[/color]
Again, the classes' definitions cannot be mutually independent, though
their member functions' definitions can, even when they use dependent
types.
BTW, the tried-and-true way to resolve recursive dependence is to add
a level of abstraction:
template <typename T>
struct Animal { typedef typename T::Name name; };
struct CollectionTraits { typedef const char *Name; };
template <template <class> class T>
struct Collection : Animal<CollectionTraits> {
};
- Shane
