[xml-cppdom-devel] Splitting up cppdom.h

[Patrick H. <pa...@13...>]

I am planning to implement automatic linking for CppDOM when building wit=
h
Visual C++, but I have run into what may be a significant problem. I thin=
k
that the fact that nearly all the CppDOM declarations are in cppdom.h
results in unnecessary exposure of information to code built on top of
CppDOM. That has not necessarily been an issue before, but with automatic=

linking, any code that includes a header that includes cppdom.h ends up
being built in such a way that it gets linked against cppdom.lib (or
whichever variant is used).

Consider the case of two pieces of code, A and B, where A is a library an=
d B
is an application. If A is using CppDOM internally, it has to be linked
against cppdom.lib. B, on the other hand, is not using CppDOM at all but =
is
just using the higher level interface provided by A. From what I have see=
n
over the last 2+ years, B should not have to be linked against cppdom.lib=

explicitly, though it would of course have to be linked against A.lib.

Implementing automatic linking with CppDOM as it is currently structured
means putting the #pragma directive in cppdom.h along with everything els=
e.
Since a library using CppDOM has no convenient mechanism for forward
declarations, the library's headers that use cppdom.h expose the whole
CppDOM API along with its own API even when this is totally unnecessary.
What I want to do is break up cppdom.h into a collection of headers (Node=
=2Eh,
NodePtr.h, Document.h, DocumentPtr.h, etc.) and corresponding implementat=
ion
files. At that point, cppdom.h would be a way to get all the CppDOM
declarations just as it is now, thus allowing full backwards compatibilit=
y
for existing code. However, code using CppDOM could be updated so as not =
to
expose the whole CppDOM API through the use of conveniently and centrally=

defined forward declarations.

My question, then, is this: are there any objections to this effort?
Frankly, it has always annoyed me that cppdom.h is a catch-all for just
about the whole CppDOM API, and this new issue is the proverbial last str=
aw
for me. Nevertheless, I do not want to spend the time splitting up the
cppdom.h if other people would prefer that the code remain structured as =
it
is. I can implement the automatic linking without splitting up cppdom.h, =
but
it will mean that CppDOM will be exposed indirectly/inadvertently (in the=

form of preprocessor symbols and linker options) to code that did not
previously need to know anything about it. Not implementing automatic
linking means that Windows users would have to identify the specific vers=
ion
of CppDOM's .lib file against which they want to link.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/