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