RE: [xml] Win32/MSVC Facelift

  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.

   int xmlSomeFunc(int arg);

   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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]