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
>