[Ext] Re: [xsd-users] DLLs and --generate-element-type --generate-element-map

[Nicolas Weidmann]

Hi Boris,

As discusses in another e-mail a few weeks ago, yes, I had to have my custom string implementation to solve the multiple-defined std::string.

I mostly used the code from the official XSD lib for my custom-string, just removed the inheritance to std::basic_string.

My architecture, split in several Conan packages:

- Conan packages of Code Synthesis components with added CMake functionality:
- XSD compiler and a CMake helper to ease the use of the compiler
- XSD lib, just made it depend on the appropriate xerces versions...

- Proprietary components:
- XSD Common library. The lib we are talking about in this email an in our previous discussions
- Provides custom double handling
- Implements a custom string to prevent the multiple std::string defined
- Other helpers: parse / serialize, XMLCh <-> char helpers and more

Then come independent XSD libraries that contain compiled XSD files.
Each lib is independent of the others.
They however all depend on XSD Common lib that provides the base xml_schema stuff and custom types.

>From what you wrote, if I am not wrong, I am not splitting hierarchies across several DLLs. So I would not need --export-maps.
Correct me if I'm wrong.



Nicolas Weidmann
Banque Lombard Odier & Cie SA
Rue de la Corraterie 11 - 1204 Genève - Suisse
T +41 22 709 23 17
www.lombardodier.com
-----Original Message-----
From: Boris Kolpackov <boris at codesynthesis.com>
Sent: mardi, 7 juillet 2026 09:30
To: Nicolas Weidmann <n.weidmann at lombardodier.com>
Cc: xsd-users at codesynthesis.com
Subject: Re: [Ext] Re: [xsd-users] DLLs and --generate-element-type --generate-element-map

Nicolas Weidmann <n.weidmann at lombardodier.com> writes:

> Using both --export-xml-schema & --export-symbol worked as you expected.
>
> However, with MSVC, I encountered the same issue I had with
> xsd::cxx::tree::string<C, B> regarding std::string being multiple-defined.

Did you arrange for a custom XML Schema string type when compiling
with --generate-xml-schema? I suspect with --export-xml-schema you
may have to similarly customize a few more built-in types that don't
derive from XML Schema string because they are now explicitly exported
(or comment out their export in the generated header).


> I then dropped --export-xml-schema & --export-symbol and added to my
> xml_schema epilogue:
>
> template class XML_SCHEMA_EXPORT ::xsd::cxx::tree::element_map<char, ::xml_schema::Type>;
>
> With this it works. I however had to add [...]
>
> Are there other templates I MUST export [...]?

I wouldn't go this manual export route for exactly this reason: now you
don't know what needs to be exported. If anything, I would go the other
way and comment out exports that cause issues and that you don't need.


> I noticed --export-maps, but didn't see any differences in the xml_schema
> header file generated. But the documentation mentions: Export polymorphism
> support maps...
>
> So, I should probably export other maps as well!?!

If you use polymorphism and your polymorphic type hierarchies are split
across several DLLs, then yes. Though this works a bit differently since
there is no built-in declarations for such maps, they are implementation
details. I think the documentation for these options (--export-maps and
--import-maps) is pretty clear on what needs to be done:

https://codesynthesis.com/projects/xsd/documentation/xsd.xhtml


> Another question, when using --generate-element-type --generate-element-map,
> I have to use element_map<...>::parse & serialize
>
> Are there equivalent helpers to [...]

No, the element types/maps are a pretty low-level (but flexible) mechanism
that you would normally wrap in a more restricted interface suitable for your
application.
[[ rethink everything. ]]<https://www.lombardodier.com>

[[LinkedIn]]<https://www.linkedin.com/company/lombard-odier>  [[Twitter]] <https://twitter.com/lombardodier>   [[Facebook]] <https://facebook.com/lombardodier>   [[Instagram]] <https://www.instagram.com/lombardodier/>   [[YouTube]] <https://www.youtube.com/channel/UCqatbeqXskmWejbm0KPLV3w>

*** IMPORTANT NOTICE REGARDING INSTRUCTIONS by EMAIL ***
Please be aware that instructions received by e-mail should be
considered delayed and not executed unless they have been
specifically confirmed by your relationship manager/banker.
Email traffic during turbulent times in the financial markets is
high and cannot always be acted upon at all times.
Lombard Odier cannot be held liable for such delay in execution
or for the non-execution of an instruction given by email even
if it was given in due time. Therefore, instructions requiring
immediate action must be communicated by telephone by calling
the bank’s registered landline.
Thank you for your understanding.

*** IMPORTANT INFORMATION ABOUT DATA PROTECTION ***
You might be receiving this because you have provided us with
your contact details. If this is the case note that we may process
your personal data for direct marketing purposes.
If you wish to object to this processing, please notify the
Group’s Data Protection Officer<mailto:group-dataprotection at lombardodier.com>.
For more information: www.lombardodier.com/privacy-policy

DISCLAIMER **********************************************
This message is intended only for use by the person
to whom it is addressed. It may contain information
that is privileged and confidential. Its content does
not constitute a formal commitment by any company
of the Lombard Odier group. If you are not the intended
recipient of this message, kindly notify the sender
immediately and destroy this message. Thank You.
*******************************************************(dch)*