[xsd-users] Issue with VS2017

[rjl at third-monday.com]

Thanks for the response.

Yes, I can upgrade to the latest XSD.  Will that require an upgrade to 
Xerces, as well?

All of the XSD Tree generated code is linked into the 'model' 
DLL/library.  The 'engine' DLL/library and all of the apps use those 
structures from the model library.

VS2017 complains mightly about classes in a DLL library with 'dllexport' 
that contain 'std::string' attributes (e.g., 'private: std::string 
_name;' in the class).

That's what that 'NamedObject' class looks like as I referenced in my 
original msg.

I like using DLLs for development because they simplify building as I'm 
working - no need to re-link apps when some lines in a library changed.

However, I think I may have made progress by doing away with DLLs during 
development.  I think I can build 'static debug' libraries and apps.  
That'll increase development time (e.g,. must wait for apps to re-link) 
but it'll save the rest of the hair on my head as I move forward.

I'll let you know what I find after upgrading and reading the 
discussions listed below.

Thanks again,
r

On 2019-03-29 09:32, Boris Kolpackov wrote:
> rjl at third-monday.com <rjl at third-monday.com> writes:
> 
>> I'm using XSD 3.3.0 and Xerces 3.1 on Windows.
>> 
>> [...]
>> 
>> I'm migrating to VS2017 [...]
> 
> As a first step, I would suggest that you upgrade to at least XSD 
> 4.0.0,
> or even to the next version pre-release:
> 
> https://codesynthesis.com/~boris/tmp/xsd/4.1.0.a11/
> 
> 
>> I'm getting some rather strange LNK2005 errors on std::string methods
>> and operators.
> 
> In a nutshell, the reason for these errors is:
> 
> 1. XSD implements certain basic types by deriving from std::string
>    (because they have the 'is-a' relationship to xsd:string in XML
>    Schema).
> 
> 2. MSVC automatically applies the dllimport/dllexport of a derived
>    class to a base class that doesn't have its own (and which
>    std::string doesn't).
> 
> 3. In MSVC 2017 (but not 2008) the implementation of std::string
>    now contains non-inline member functions (or inline ones that
>    the compiler chooses not to inline in Debug).
> 
> 4. If you have two or more DLLs that include the generated code,
>    then you may end up with duplicate std::string symbols because
>    they both export them (see 2 above).
> 
> There are various ways to solve this problem with the easiest
> being to place all the generated code into a single DLL. For
> other ways see this earlier post:
> 
> http://www.codesynthesis.com/pipermail/xsd-users/2010-September/003011.html
> 
> With this email containing more analysis/information on the problem:
> 
> http://www.codesynthesis.com/pipermail/xsd-users/2010-September/003019.html