xml-cppdom-devel

[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/

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

[Aron B. <ar...@ia...>]

I completely agree with you on this one. I also get annoyed with 
libraries that include their entire API in a single header. As long as 
it does not break existing applications, I say go for it.

-Aron

Patrick Hartling wrote:
> 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 think
> 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 and 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 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 structured
> 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 unnecessary.
> What I want to do is break up cppdom.h into a collection of headers (Node.h,
> NodePtr.h, Document.h, DocumentPtr.h, etc.) and corresponding implementation
> 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 compatibility
> 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 straw
> 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 version
> of CppDOM's .lib file against which they want to link.
>
>  -Patrick
>
>
>   
> ------------------------------------------------------------------------
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xml-cppdom-devel mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
>   

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

[Allen B. <al...@vr...>]

Patrick Hartling wrote:

>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 think
>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 and 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 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 structured
>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 unnecessary.
>What I want to do is break up cppdom.h into a collection of headers (Node.h,
>NodePtr.h, Document.h, DocumentPtr.h, etc.) and corresponding implementation
>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 compatibility
>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.
>  
>
It sounds like this last sentence is really the goal of this effort.  
Namely make a way that a library using cppdom can include a header to 
get the symbols but not require applications that included that same 
library header to link against cppdom.  Is this a correct assesment?

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

As far as breaking cppdom up, the current structure has never really 
bothered me because in order to use cppdom you would pretty much have to 
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 
splitting things up but I think users are going to include cppdom.h 
anyway just to cut down on the number of files they have to remember to 
include.

-Allen

>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 straw
>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 version
>of CppDOM's .lib file against which they want to link.
>
> -Patrick
>
>
>  
>
>------------------------------------------------------------------------
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Xml-cppdom-devel mailing list
>Xml...@li...
>https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
>  
>

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/