FW: [xml] Win32/MSVC Facelift

["Vakoc, Mark" <Mark_Vakoc jdedwards com>]

> > I strongly agree that xmlwin32version.h should be removed.
> > [...] Seems redundant.
>
> Not anymore. It sounded redundant yesterday, but today I have read the
> post from Yon Derek :-)

What about delivering xmlversion.h in a condition ready to use?  cgywin and
unix will all 
overwrite this from xmlversion.h.in, but msvc would use the delivered copy.

> > Really?  I've always seem to encounter profiling/debug features in the
> > utilites that would only build when some of hte debug features were
> > #define'ed in that wouldn't typically be included in a release build.

> Really. You can debug and profile what you see fit, just always use the
> same C-Runtime, without debug or profile info. Conflicts arise from
> using different C-Runtimes for debug or profile build.

I meant the utilities seemed to use debug functionality of libxml2 defined
in xmlversion.h that you wouldn't
normally include in a release build, not c runtime debug/release.

> No, no #pragmas. Even if every compiler should silently ignore all
> #pragmas it doesn't understand, many don't. MS compiler is a typical
> example of these. You can change the default alignment in the project
> settings in the MSVC IDE. Those who do it and know what they did are not
> exactly novices; they would know what went wrong without drowning the
> world's mailing lists in help-me tears. Besides, there is no reason why
> libxml should fail with different alignment.

Keep in mind that you plan to distribute binaries and libraries that people
will use.  
Not everyone uses 8 byte struct alignmnet.  So their 1byte aligned program
linked against libxml2 compiled with 8 byte alignment will trigger 0xC000005
faster than you can say 'quick fix'.  Prepare for those help-me tears.
Libxml will work fine with any byte alignment, but without #pragma's telling
the compiler how libxml was built, any program linking against it will
encounter problems when passing structures in and out of libxml when the
program was built with something other than 8byte alignment or whatever
libxml is defined to use.

> No, this is not a solution, and that because __cdecl is the only calling
> convention we can use. __stdcall produces smaller executables because
> the stack cleanup code is generated once for each function instead of
> once for each call, but exactly that carries an important limitation: a
> __stdcall function cannot have variable argument list. Use __cdecl.
> Those few nanobytes of extra stack mrproperring are really not a big
> deal.

Again consider you are distributing binaries and libraries.  Use __cdecl, no
problem -- thats your perogative.  Just remember that the defacto standard
for msvc programming is the __stdcall method.  The merits of this really
don't matter, its a fact.  

If people want to use the libxml, they are going to include the headers.  If
there is nothing in the header indicating the calltype, it will use the
default.  Remember, I may now compiling my program and I have elected to use
__stdcall.

This all boils down to whether you want to create a robust library for win32
or one that will simply compile.  A robust library allows developers to
easily incorporate libxml into their projects without requiring them to make
changes to their existing project (such as byte alignment and calling
convention).  Sure you can make your project that includes libxml mimic
libxml in order to function (8 byte, __cdecl).  But all it takes is two
library creators with differing views on these settings to cause a real
headache.  

Take a lesson from nearly every header Microsoft delivers:  a #pragma
pack(push, x) and #pragma pack(pop) pair, and a macro defining the calling
convention for each function (i.e. WINAPI, STDMETHODCALLTYPE, etc.).  They
work, and provide the greatest flexibility.