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

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

Allen Bierbaum wrote:
> Patrick Hartling wrote:
>=20
>> I am planning to implement automatic linking for CppDOM when building =
with
>> Visual C++, but I have run into what may be a significant problem. I t=
hink
>> 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 automa=
tic
>> linking, any code that includes a header that includes cppdom.h ends u=
p
>> 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=
 and B
>> is an application. If A is using CppDOM internally, it has to be linke=
d
>> against cppdom.lib. B, on the other hand, is not using CppDOM at all b=
ut is
>> just using the higher level interface provided by A. From what I have =
seen
>> 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 structur=
ed
>> means putting the #pragma directive in cppdom.h along with everything =
else.
>> 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 unnecessar=
y.
>> What I want to do is break up cppdom.h into a collection of headers (N=
ode.h,
>> NodePtr.h, Document.h, DocumentPtr.h, etc.) and corresponding implemen=
tation
>> 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 compatibi=
lity
>> for existing code. However, code using CppDOM could be updated so as n=
ot to
>> expose the whole CppDOM API through the use of conveniently and centra=
lly
>> defined forward declarations.
>> =20
>>
> It sounds like this last sentence is really the goal of this effort. =20
> Namely make a way that a library using cppdom can include a header to=20
> get the symbols but not require applications that included that same=20
> library header to link against cppdom.  Is this a correct assesment?

Yes.

> If so, I would suggest that before we go to all the trouble of splittin=
g=20
> things up you could first just create the forward declaration header =20
> (maybe something like cppdom_decls.h or something) and then test to mak=
e=20
> sure that this will work the way you envision it with other libraries.

That's not a bad idea. However, I have decided to try a different approac=
h
than breaking up cppdom.h. I changed the usage of the #pragma directive s=
o
that it only does automatic linking when user code requests it. That mean=
s
that code that didn't need to be linked against CppDOM before does not en=
d
up with an embedded comment saying that it needs to be linked against it
now. I am running a build now to test this, and so far it is working. I
haven't built or run any applications yet, however.

> As far as breaking cppdom up, the current structure has never really=20
> bothered me because in order to use cppdom you would pretty much have t=
o=20
> include the headers all the classes defined right now in cppdom.h.  In =

> that way it really is the public interface file.  The internal details =

> like the parser are in other files.  So I guess I am not set against=20
> splitting things up but I think users are going to include cppdom.h=20
> anyway just to cut down on the number of files they have to remember to=
=20
> include.

That's why I said I would retain cppdom.h in a form that gets the same
results that it does now. I guess it just seems "cleaner" to me to have o=
ne
class per file, but perhaps I have written too much Java code in my time.=
 :)

 -Patrick


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