What about this.
Move the entire definition of Connection to a base object, such as
ConnectionBase, except for the method(s) (I only see one) that need
to include the Query object. Put ConnectionBase in a different .h
file.
Make the Query dependent upon ConnectionBase, which is not dependent
upon Query. It should take very little wizardry to treat a Connection
object as a ConnectionBase invisibly (At worst you'll need an operator
on the Connection object but I don't think you'll even need that).
Such changes would then, I would think, be invisible to the client.
All of this would be moot if gcc simply supported the 'export' keyword.
Warren Young wrote:
> I just got a Fedora Core 3 system up and running, and it comes with
GCC 3.4.2. And yet again, they've managed to tighten down the C++
language the compiler accepts.
>
> I've already fixed a couple of small buglets that it caught, but now
I'm stuck on a big one: the circular dependency betwen Connection and
Query. The Connection class must #include query.h for various reasons;
query() member function, for instance. Likewise, Query needs access to
the declaration of class Connection, to be able to expand some of the
template member functions that it declares. GCC won't defer expansion
of the templates like it used to, until both headers are fully parsed.
>
> I'm soliciting opinions on the best way to break this circle.
>
