From n.weidmann at lombardodier.com  Wed Jun 17 03:57:37 2026
From: n.weidmann at lombardodier.com (Nicolas Weidmann)
Date: Wed Jun 17 09:21:42 2026
Subject: [xsd-users] XSD & Windows DLL linkage issues with std::string
Message-ID: <17da37e455d642d5ac6a0495a168aacd@lombardodier.com>

Hello,

I am new to XSD, so be indulgent? ?

I am encountering linking issues in the following configuration when creating a Windows DLL for my data-binding:


  *   XSD 4.2.0
  *   Visual Studio 2017, v141 & C++17
  *   CMake 3.30.2

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@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QEAA@AEBV01@@Z) already defined in ClassUsingTheDataBinding.obj [LibraryUsingTheDatabinding.vcxproj]
I get this issue for every constructor and method of std::string used in the ?client? library.
Since I include some XSD library headers directly, I have XSD_CXX11 globally defined for both projects.
Has someone already encountered a similar issue?
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

[[ 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@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)*

From boris at codesynthesis.com  Wed Jun 17 09:46:23 2026
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Jun 17 09:46:36 2026
Subject: [xsd-users] XSD & Windows DLL linkage issues with std::string
In-Reply-To: <17da37e455d642d5ac6a0495a168aacd@lombardodier.com>
References: <17da37e455d642d5ac6a0495a168aacd@lombardodier.com>
Message-ID: <boris.20260617154045@codesynthesis.com>

Nicolas Weidmann <n.weidmann@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@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QEAA@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

From n.weidmann at lombardodier.com  Wed Jun 17 13:25:05 2026
From: n.weidmann at lombardodier.com (Nicolas Weidmann)
Date: Thu Jun 18 09:04:02 2026
Subject: [Ext] Re: [xsd-users] XSD & Windows DLL linkage issues with
	std::string
In-Reply-To: <boris.20260617154045@codesynthesis.com>
References: <17da37e455d642d5ac6a0495a168aacd@lombardodier.com>
	<boris.20260617154045@codesynthesis.com>
Message-ID: <4c56ac1c86d44e21b6013f6fceaa70f6@lombardodier.com>

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

Nicolas Weidmann <n.weidmann@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@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QEAA@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@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)*


From n.weidmann at lombardodier.com  Fri Jun 19 06:33:06 2026
From: n.weidmann at lombardodier.com (Nicolas Weidmann)
Date: Fri Jun 19 06:47:17 2026
Subject: [Ext] Re: [xsd-users] XSD & Windows DLL linkage issues with
	std::string
In-Reply-To: <4c56ac1c86d44e21b6013f6fceaa70f6@lombardodier.com>
References: <17da37e455d642d5ac6a0495a168aacd@lombardodier.com>
	<boris.20260617154045@codesynthesis.com>
	<4c56ac1c86d44e21b6013f6fceaa70f6@lombardodier.com>
Message-ID: <8e4c55b3081443d7ada4d83da5c0d503@lombardodier.com>

Hello Boris,

I could narrow the problem down to this line 56 of xsd/cxx/tree/types.hxx:

      template <typename C, typename B>
      class string: public B, public std::basic_string<C>

The issue is with the inheritance of std::basic_string.

I wrote a wrapping class that uses, as underlying, a std::string, and the link errors are gone as you implied.

I however now have the following issues with one of my data-bindings:

unexpected enumerator encountered

I will double check vs the original xsd::cxx::tree::string to see if I have done anything wrong...

Unless you know exactly what I missed...

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: Nicolas Weidmann
Sent: mercredi, 17 juin 2026 19:25
To: xsd-users@codesynthesis.com
Subject: RE: [Ext] Re: [xsd-users] XSD & Windows DLL linkage issues with std::string

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

Nicolas Weidmann <n.weidmann@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@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QEAA@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@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)*


From boris at codesynthesis.com  Mon Jun 22 08:28:05 2026
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Jun 22 08:28:18 2026
Subject: [Ext] Re: [xsd-users] XSD & Windows DLL linkage issues with
	std::string
In-Reply-To: <8e4c55b3081443d7ada4d83da5c0d503@lombardodier.com>
References: <17da37e455d642d5ac6a0495a168aacd@lombardodier.com>
	<boris.20260617154045@codesynthesis.com>
	<4c56ac1c86d44e21b6013f6fceaa70f6@lombardodier.com>
	<8e4c55b3081443d7ada4d83da5c0d503@lombardodier.com>
Message-ID: <boris.20260622142503@codesynthesis.com>

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

> I wrote a wrapping class that uses, as underlying, a std::string, and
> the link errors are gone as you implied.
> 
> I however now have the following issues with one of my data-bindings:
> 
> unexpected enumerator encountered
> 
> I will double check vs the original xsd::cxx::tree::string to see if I
> have done anything wrong...
> 
> Unless you know exactly what I missed...

Not off the top of my head. But I believe this error is the result
of not being able to match any enumeration value in the generated
code. If the same worked with the original string type, then I would
look into the comparison operator (operator==) of your wrapper.

From n.weidmann at lombardodier.com  Mon Jun 22 10:27:44 2026
From: n.weidmann at lombardodier.com (Nicolas Weidmann)
Date: Tue Jun 23 05:12:09 2026
Subject: [Ext] Re: [xsd-users] XSD & Windows DLL linkage issues with
	std::string
In-Reply-To: <boris.20260622142503@codesynthesis.com>
References: <17da37e455d642d5ac6a0495a168aacd@lombardodier.com>
	<boris.20260617154045@codesynthesis.com>
	<4c56ac1c86d44e21b6013f6fceaa70f6@lombardodier.com>
	<8e4c55b3081443d7ada4d83da5c0d503@lombardodier.com>
	<boris.20260622142503@codesynthesis.com>
Message-ID: <ef240379383e453d864ea63e26c45d38@lombardodier.com>

Hello Boris,

Thank you for your advice.

I threw everything away, copy / pasted the original code, removed the inheritance to std::basic_string and grepped for string<C in the XSD library headers to make sure I implemented every method and operators correctly.

And it solved the problem.

I must have missed something, but it was not related to those 4 operators, as I already had them in my initial implementation:

1. operator ==(const char*, const my_string&)
2. operator ==(const my_string&, const char*)
3. & 4. The equivalent for !=

I think I messed up with the initialization of the xsd::cxx::tree::simple_type base somewhere.

So, now everything works and links properly...

Thanks a lot for your help!

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@codesynthesis.com>
Sent: lundi, 22 juin 2026 14:28
To: Nicolas Weidmann <n.weidmann@lombardodier.com>
Cc: xsd-users@codesynthesis.com
Subject: Re: [Ext] Re: [xsd-users] XSD & Windows DLL linkage issues with std::string

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

> I wrote a wrapping class that uses, as underlying, a std::string, and
> the link errors are gone as you implied.
>
> I however now have the following issues with one of my data-bindings:
>
> unexpected enumerator encountered
>
> I will double check vs the original xsd::cxx::tree::string to see if I
> have done anything wrong...
>
> Unless you know exactly what I missed...

Not off the top of my head. But I believe this error is the result
of not being able to match any enumeration value in the generated
code. If the same worked with the original string type, then I would
look into the comparison operator (operator==) of your wrapper.
[[ 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@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)*


From n.weidmann at lombardodier.com  Tue Jun 23 01:19:04 2026
From: n.weidmann at lombardodier.com (Nicolas Weidmann)
Date: Tue Jun 23 05:12:09 2026
Subject: [xsd-users] Fails to parse complex type extensions
Message-ID: <137e71d8d36949ef8972a46f2cb212ac@lombardodier.com>

Hello,

I have an XSD containing several complex types. Let's call them A, B, C & D

B is an extension of A, C of B and D of C.

Only A has an associated element name a

This means that only A gets a generated function name parseA.

I have a document containing a D, but I can't parse it as parseA explicitly tests for the type to be "a":

   if (n.name () == "a" && n.namespace_ () == "the-namespace")
    {
      ::std::unique_ptr< A > r (::xsd::cxx::tree::traits< A, char >::create (e, f, 0));

      return r;
    }

    throw ::xsd::cxx::tree::unexpected_element < char > (
      n.name (),
      n.namespace_ (),
      "a",
      "the-namespace");

What options did I forget to pass when invoking the XSD compiler?

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

[[ 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@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)*

From n.weidmann at lombardodier.com  Tue Jun 23 05:38:10 2026
From: n.weidmann at lombardodier.com (Nicolas Weidmann)
Date: Wed Jun 24 09:56:36 2026
Subject: [xsd-users] RE: Fails to parse complex type extensions
In-Reply-To: <137e71d8d36949ef8972a46f2cb212ac@lombardodier.com>
References: <137e71d8d36949ef8972a46f2cb212ac@lombardodier.com>
Message-ID: <1f45d33c88184841a4f47523c24007cc@lombardodier.com>

Hello,

I get a similar issue when serializing.

I create an instance of D, and since no serialized exists, I invoke serializeA, and the resulting document is a A instead of a D

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

From: Nicolas Weidmann
Sent: mardi, 23 juin 2026 07:19
To: 'xsd-users@codesynthesis.com' <xsd-users@codesynthesis.com>
Subject: Fails to parse complex type extensions

Hello,

I have an XSD containing several complex types. Let's call them A, B, C & D

B is an extension of A, C of B and D of C.

Only A has an associated element name a

This means that only A gets a generated function name parseA.

I have a document containing a D, but I can't parse it as parseA explicitly tests for the type to be "a":

   if (n.name () == "a" && n.namespace_ () == "the-namespace")
    {
      ::std::unique_ptr< A > r (::xsd::cxx::tree::traits< A, char >::create (e, f, 0));

      return r;
    }

    throw ::xsd::cxx::tree::unexpected_element < char > (
      n.name (),
      n.namespace_ (),
      "a",
      "the-namespace");

What options did I forget to pass when invoking the XSD compiler?

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<http://www.lombardodier.com>

[[ 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@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)*

From boris at codesynthesis.com  Wed Jun 24 09:59:43 2026
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Jun 24 09:59:55 2026
Subject: [xsd-users] Fails to parse complex type extensions
In-Reply-To: <137e71d8d36949ef8972a46f2cb212ac@lombardodier.com>
References: <137e71d8d36949ef8972a46f2cb212ac@lombardodier.com>
Message-ID: <boris.20260624155729@codesynthesis.com>

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

> I have an XSD containing several complex types. Let's call them A, B, C & D
> 
> B is an extension of A, C of B and D of C.
> 
> Only A has an associated element name a
> 
> This means that only A gets a generated function name parseA.
> 
> I have a document containing a D, but I can't parse it as parseA
> explicitly tests for the type to be "a":

Smells like polymorphism to me:

https://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.11

From n.weidmann at lombardodier.com  Wed Jun 24 10:44:17 2026
From: n.weidmann at lombardodier.com (Nicolas Weidmann)
Date: Thu Jun 25 07:56:17 2026
Subject: [Ext] Re: [xsd-users] Fails to parse complex type extensions
In-Reply-To: <boris.20260624155729@codesynthesis.com>
References: <137e71d8d36949ef8972a46f2cb212ac@lombardodier.com>
	<boris.20260624155729@codesynthesis.com>
Message-ID: <c4e705f1a14a469ab3ba4329b6cb4d4f@lombardodier.com>

Hello Boris,

Thank you for your answer.

I was already doing https://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.11

But by re-reading that example, I realized it was the test document that was wrong...

It was <D>...</D> instead of <a xsi:type="D">...</a>

After the correction, my test successfully worked when std::dynamic_pointer_cast<D>(the_parsed_document)...

Thanks for your patience!

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@codesynthesis.com>
Sent: mercredi, 24 juin 2026 16:00
To: Nicolas Weidmann <n.weidmann@lombardodier.com>
Cc: xsd-users@codesynthesis.com
Subject: [Ext] Re: [xsd-users] Fails to parse complex type extensions

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

> I have an XSD containing several complex types. Let's call them A, B, C & D
>
> B is an extension of A, C of B and D of C.
>
> Only A has an associated element name a
>
> This means that only A gets a generated function name parseA.
>
> I have a document containing a D, but I can't parse it as parseA
> explicitly tests for the type to be "a":

Smells like polymorphism to me:

https://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.11
[[ 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@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)*


From n.weidmann at lombardodier.com  Fri Jun 26 09:03:54 2026
From: n.weidmann at lombardodier.com (Nicolas Weidmann)
Date: Mon Jun 29 10:26:42 2026
Subject: [xsd-users] DLLs and --generate-element-type --generate-element-map
In-Reply-To: <boris.20260624155729@codesynthesis.com>
References: <137e71d8d36949ef8972a46f2cb212ac@lombardodier.com>
	<boris.20260624155729@codesynthesis.com>
Message-ID: <4a98add6123e4b6b9df979fbe42efe2c@lombardodier.com>

Hello,

I wanted to use --generate-element-type --generate-element-map in order to have a single parse & serialize as our code heavily relies on templates and parseMyType, etc. are not generic.

It works fine as long as all the libs are static, but I need to have the different data-binding libraries to be DLLs.

In that case, it fails as the different dlls have their own element map and the application code has its own, empty, element map.

Do I have to implement my own --custom-type for the element map ?

If yes, what to pass to --custom-type ?
And are there any traits or else to implement as well ?

Regards,

Nicolas
[[ 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@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)*


From boris at codesynthesis.com  Tue Jun 30 10:10:39 2026
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Jun 30 10:10:52 2026
Subject: [xsd-users] DLLs and --generate-element-type
	--generate-element-map
In-Reply-To: <4a98add6123e4b6b9df979fbe42efe2c@lombardodier.com>
References: <137e71d8d36949ef8972a46f2cb212ac@lombardodier.com>
	<boris.20260624155729@codesynthesis.com>
	<4a98add6123e4b6b9df979fbe42efe2c@lombardodier.com>
Message-ID: <boris.20260630160126@codesynthesis.com>

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

> I wanted to use --generate-element-type --generate-element-map in
> order to have a single parse & serialize as our code heavily relies
> on templates and parseMyType, etc. are not generic.
> 
> It works fine as long as all the libs are static, but I need to have
> the different data-binding libraries to be DLLs.
> 
> In that case, it fails as the different dlls have their own element
> map and the application code has its own, empty, element map.
> 
> Do I have to implement my own --custom-type for the element map?

No, the overall approach is to have a "root" DLL that exports the
single map that everyone else imports. The element map is a class
template (with a static data member which is the actual map) and
exporting templates from DLLs is a murky business. If you want
to give it a go, the starting point would be to generate the
header for XML Schema built-in types (which includes the
element_map) and export it from your root DLL. Something along
these lines:

xsd cxx-tree \
  --generate-element-map \
  --generate-element-type \
  --export-xml-schema \
  --export-symbol XML_SCHEMA_EXPORT \
  --generate-xml-schema  \
  xml-schema.xsd

You would need to define XML_SCHEMA_EXPORT appropriately. You will also
need to have this header included in at least one source file that belongs
to the root DLL in order to have the template instantiations exported.

Once this is done, all your actual schemas would be compiled with
--extern-xml-schema in order to use this shared header.

From n.weidmann at lombardodier.com  Tue Jun 30 10:21:16 2026
From: n.weidmann at lombardodier.com (Nicolas Weidmann)
Date: Wed Jul  1 08:34:28 2026
Subject: [Ext] Re: [xsd-users] DLLs and --generate-element-type
	--generate-element-map
In-Reply-To: <boris.20260630160126@codesynthesis.com>
References: <137e71d8d36949ef8972a46f2cb212ac@lombardodier.com>
	<boris.20260624155729@codesynthesis.com>
	<4a98add6123e4b6b9df979fbe42efe2c@lombardodier.com>
	<boris.20260630160126@codesynthesis.com>
Message-ID: <b99868d2c23a4243993573e3b0c80878@lombardodier.com>

Hello Boris,

Thanks for your help !

I have 1 common lib and different libs for each data-binding.

I am correctly building the common lib as a DLL with regards to my own custom classes.
But I forgot to use --export-symbol for generating the xml-schema header...

I use --export-symbol for the different data-bindings DLLs, but completely forgot about the common lib...

I am working on another task this week.

I will give you a feedback ASAP next week.

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@codesynthesis.com>
Sent: mardi, 30 juin 2026 16:11
To: Nicolas Weidmann <n.weidmann@lombardodier.com>
Cc: xsd-users@codesynthesis.com
Subject: [Ext] Re: [xsd-users] DLLs and --generate-element-type --generate-element-map

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

> I wanted to use --generate-element-type --generate-element-map in
> order to have a single parse & serialize as our code heavily relies
> on templates and parseMyType, etc. are not generic.
>
> It works fine as long as all the libs are static, but I need to have
> the different data-binding libraries to be DLLs.
>
> In that case, it fails as the different dlls have their own element
> map and the application code has its own, empty, element map.
>
> Do I have to implement my own --custom-type for the element map?

No, the overall approach is to have a "root" DLL that exports the
single map that everyone else imports. The element map is a class
template (with a static data member which is the actual map) and
exporting templates from DLLs is a murky business. If you want
to give it a go, the starting point would be to generate the
header for XML Schema built-in types (which includes the
element_map) and export it from your root DLL. Something along
these lines:

xsd cxx-tree \
  --generate-element-map \
  --generate-element-type \
  --export-xml-schema \
  --export-symbol XML_SCHEMA_EXPORT \
  --generate-xml-schema  \
  xml-schema.xsd

You would need to define XML_SCHEMA_EXPORT appropriately. You will also
need to have this header included in at least one source file that belongs
to the root DLL in order to have the template instantiations exported.

Once this is done, all your actual schemas would be compiled with
--extern-xml-schema in order to use this shared header.
[[ 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@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)*