RE: [xml] Win32/MSVC Facelift

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

> >   Well adding one specifier before the declaration is okay. Adding 2
> > intermixed with the type is not a progress in my opinion ! 
> > I don't think
> > it will make it more readable for human, but I'm pretty sure it will
> > make it far harder for processing tools. 
> >   No I don't like this. One extra keyword is enough of a pain, and
> > this should not impact the declaration itself. I vetoe this out.

> Somehow I knew you would :-) But, I haven't made my point well enough.

I also don't like too many macros if unneeded.

> >    XMLPUBLICFUNC
> >    int xmlSomeFunc(int arg);
> >
> >    XMLPUBLICVAR
> >    int xmlSomeVar;
> >
> >    If you provide patches for this I will incorporate them,

> __declspec(dllexport) __cdecl
>  int xmlSomeFunc(int arg);
>
> and the MSVC compiler would have nothing better to say but:
...

> The calling convention must be specified after the return type and that
> means that the only way to do this is the one you vetoed out.

However int __declspec(dllexport) __cdecl xmlSomeFunc(int arg); is valid,
allowing a single macro to be used for function declaration.  Since __cdecl
is defined only for programs using the headers, a non exported function
would simply omit the macro (hence really only dropping the __declspec()),

> >   There is already similar cruft for the C++ compilers. This makes me 
> > sick to add one more of those, what does this bring ? Why is alignment
> > a concern ?
>
> That puzzles me as well. 

For me, it's a client server application where the same code is compiled for
various platforms.  On win32 clients, alignmnet was chosen at 1byte
alignment, but on NT servers 8byte.  I believe the initial concern was
performance vs. memory usage.  Regardless, in my scenario I now have a lot
of:

#pragma pack(push,LIBXML_BYTE_ALIGNMENT /* 8 */)
#include <libxml/tree.h>
#pragma pack(pop).

Cluttered, I hoped to remove this by having this incorporated into libxml
like the standard headers we use.

> Sure you can put it in the macro, but that would introduce other
> problems. libxml sources include (win32)config.h first thing, but the
> code of a program which is merely based on libxml doesn't. This means
> that you must get those definitions in the client code somehow and
> (win32)config.h is not exactly a public header.

Have there ever been thoughts on creating a master libxml header that would
in itself include
the various other components compiled in (such as tree.h,xpath.c,etc..) and
client programs would need
only include the single header?