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

   int xmlSomeFunc(int arg);

   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

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?


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