[xsd-users] DLL's VS 2010 and dllexport problems revisited

[Boris Kolpackov]

Hi Gordan,

Gordan Sikic <gordan.sikic at uljanik.hr> writes:

> It is the similar problem as explained in "2010-september" thread. There
> are couple of mutually unrelated schemas, and every schema is compiled
> into one dll. On many places in schemas, string enumerations are used,
> and it turns out that resulting classes in c++ are inherited from
> ::xml_schema::string.
>
> [...]
>
> I tried it (and followed it correctly), more than once.

In this case you will need to create another (root) DLL which will
contain just xml-schema.hxx (generated with the --export-xml-schema)
option (step 1). You will also need to create a dummy xml-schema.cxx
file (step 2). All your other schemas must be compiled with the
--extern-xml-schema option to use this xml-schema.hxx from the root
DLL and also link to this root DLL (step 3).

Have you done all of this? 


> Maybe you can (if possible) send me example that is used in thread
> you refer to, so I can check it as well?

Unfortunately I cannot do this since it was provided by a customer
and we agreed not to make it public.


> Maybe I was little bit vague in my explanation. When I wrote
> automatically, I did not mean obligatory, just possibly, as some kind of
> command line option (some kind of regex?).

Yes, I understand.


> Ok, I understand that it is not route you are willing to take.
> I would just like to ask why do you think it is a problem to have
> hundreds of export macros within class, after all, it is automatically
> generated code?

The problem is not with classes that are generated from your schema
(there it will be relatively easy to add export macros for each function
provided, of course, there are no silly limitations/bugs that would prevent
us from exporting special functions, like c-tors, assignement operators,
etc).

The problem is with the built-in types. Thease are hand-written class
templates that reside in libxsd and some of them also derive from
std::string.

The XSD compiler simply generate a typedef for these types in the
xml_schema namespace (and template class EXPORT_MACROS foo<bar> if
exporting was requested). With the approach you are proposing we
will have to make the XSD compiler generate an export directive (if
such exists) for each member function in each such built-in type.
I would expect there will be hundreds of them. Plus, every time we
add or remove a member function from a built-in type, we will have
to remember to update the XSD compiler as well.

Boris