RE: [xml] Win32/MSVC Facelift

["Igor Zlatkovic" <izlatkovic daenet de>]

>   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.
Now reading my own post again, I wrongly sounded as if I have added the
second specifier intermixed with the return type for fun. In fact it was
because it is the only way it works. Read on.

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

Please don't. Such patch would break the build under MSVC totally. This
construct can only be used to specify the export/import declaration,
nothing else. (We allready have had a discussion about that and we
decided to use .def.src file instead.)

With the calling convention mentioned in that XMLPUBLICFUNC, the above
would not compile under MSVC. Reading back, I see I forgot to mention
this in earlier posts. The above declaration would expand to:

  __declspec(dllexport) __cdecl
  int xmlSomeFunc(int arg);

and the MSVC compiler would have nothing better to say but:

  error C2059: syntax error : 'type'

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.

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

>   Can this and the C++ wrappers be put in HEADER_START and HEADER_END
> macros ? This would keep the header cleans and allow 
> customization from
> the win32config.h header (or any other system specific one) without
> having to modify everything each time there is a new compiler 
> showing up !!!

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.

I still don't see a need for any of it. When I use a C library in a C++
program and the linker faults, I do a

  extern "C" {
  #include <libxml/somefile.h>
  #include <libxml/anotherfile.h>  
  }

in my sources. Problem solved. Simiarily, I say that Win32/MSVC client
code which changes the default alignment should do a:

  #pragma pack(push, 8)
  #include <libxml/somefile.h>
  #include <libxml/anotherfile.h>  
  #pragma pack(pop)

and peace there shall be. The chance that libxml starts using a
different alignment in the future is extremely small. The chance that
structures become different and binary compatibility breaks is much
bigger. 

I don't know. I can offer to include microsoftificated headers in the
precompiled Win32 binary version, should someone provide a patch. Would
that be enough?

Ciao
Igor