Re: Cyclic dependency?
Louis Lavery wrote:
The following compiles under g++ 3.2 and vc7, but should it
compile on all platforms?
/* test.cpp */
#include <list>
struct Vertex;
struct Edge;
typedef std::list<Vertex>::iterator Vit;
typedef std::list<Edge>::iterator Eit;
struct Vertex
{
Eit eit;
};
struct Edge
{
Vit vit;
};
Yes, the declarations of Vertex and Edge are portable. The fact that
each struct has an iterator data member referring to the other is
perfectly valid. After all, an iterator is much like a pointer (and in
fact may be a pointer). So replacing the iterator data member with a
pointer may help illustrate the relationship between Vertex and Edge.
struct Edge;
struct Vertex
{
Edge* eit;
};
struct Edge
{
Vertex* vit;
};
In fact, the pointer is probably more useful than a lone iterator.
Because wthout its container, an iterator cannot be used to iterate.
For example, there is no way to tell whether ++eit or --eit can be
safely dereferenced - in fact there is no way tell whether eit itself
has been initialized with a valid iterator and can itself be safely
deferenced. A pointer that cannot safely be dereferenced could be set
to NULL.
Furthermore, it seems likely a Vertex object may have more than one
associated Edge, and likewise that an Edge object may have more than
one associated Vertex. So instead of an iterator data member, why not
have the data member be the iterator's container itself?
For one reason, neither Edge or Vertex could have a data member
container that stored Edges and Vertexes by value - since each type
would end up containing an instance of the other - and indirectly an
instance of its own type. There are ways to avoid self-inclusion: the
data member container could be declared as a pointer or as a reference
to a container - or the data member container could hold pointers to -
or std::tr1::reference_wrappers of - instances of the other type.
Greg
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]