[Ext] Re: [xsd-users] XSD & Windows DLL linkage issues with std::string

[Nicolas Weidmann]

Dear Boris,

Thank you for you quick reply!

I was on holidays this afternoon and will be tomorrow as well.

I will look at both #1 and #3 on Friday and will let you know...

Regarding #1, we already have a custom xsd::cxx::tree::traits<...> for doubles, so this could be a candidate.

Regarding DLLs, we have an application that requires DLLs for almost everything due to massive link times (& memory usage) otherwise.

Regards,

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: mercredi, 17 juin 2026 15:46
To: Nicolas Weidmann <n.weidmann at lombardodier.com>
Cc: xsd-users at codesynthesis.com
Subject: [Ext] Re: [xsd-users] XSD & Windows DLL linkage issues with std::string

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

> I can create my DLL and test it without any issues.
>
> However as soon as I use my data-binding in another library that is also to
> be generated as a DLL, I get link errors regarding std::string:
>
> data-binding.lib(data-binding.dll) : error LNK2005: "public: __cdecl std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::basic_string<char,struct std::char_traits<char>,class std::allocator<cha
> r> >(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QEAA at AEBV01@@Z) already defined in ClassUsingTheDataBinding.obj [LibraryUsingTheDatabinding.vcxproj]

Ok, let me describe the problem so that you have an idea about what's
going on here (this is the typical setup, yours is a variant with two
DLLs, but it's the same underlying problem):

1. XSD built-in types (e.g., xml_schema::string) derive from std::string
   (this is done so that you can "seamlessly" pass xml_schema::string
   where std::string is expected).

2. In VC++, when you export a class (xml_schema::string in our case,
   caused by the --export-xml-schema option), it automatically exports
   the base class. So in our case std::string (aka std::basic_string)
   gets exported as well. There doesn't seem to be any way to disable
   exporting of or "unexport" a base class in VC++.

3. When you build your executable, there could be some source files that
   include "xml-schema.hxx" (generated with --generate-xml-schema) and
   therefore "see" std::string as imported from the DLL. There could also be
   source files that do no include any generated code and therefore don't
   "see" std::string as imported but rather as defined in the
   executables. When you then try to link object files corresponding to such
   source files together, you get the multiple definition error (one is
   imported from the DLL while the other is locally defined).

The easiest solution is, well, not to package generated source code into
DLLs, if you are able to.

The next easiest solution is to address #3 by making sure that every
source file in the executable that includes <string> also includes
"xml-schema.hxx" so that they also "see" std::string as imported. This
is not a very clean but fairly easy fix.

The cleaner but more involved fix would be to address #1 and not
derive from std::string. This can be done with type customization
but it will also limit the xml_schema::string functionality (no
implicit substitution for std::string). If you would like to go
down this route, see:

http://wiki.codesynthesis.com/Tree/Customization_guide

And, specifically, the "Customizing the XML Schema built-in types"
section:

http://wiki.codesynthesis.com/Tree/Customization_guide#Customizing_the_XML_Schema_built-in_types
[[ 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)*