[xsd-users] Issue with VS2017

[rjl at third-monday.com]

This morning's updates:

1) I upgraded to XSD 4.0.0 - no need to upgrade Xerces (from 3.1.1) as 
far as I can tell.

2) I implemented the updates to the XML code generation as described in 
the 1st note below (added ' --export-xml-schema --hxx-prologue 
"\#include \"model/util/Defines.h\"" --export-symbol MODEL_EXPORTAPI) to 
the xmlSchema.h generation.

3) Pushed on the 'static debug' build for the model n engine libraries 
to make sure they were, indeed, 'debug'-worthy builds.

4) Figgered out how to make my app programs depend on the libraries 
using Qt qmake variables so they're relinked should any of the libraries 
change.

Everything seems to work.  Point '2)' really isn't needed now as I'm 
building my libs statically.

I think I can enter the weekend with something accomplished!  This has 
been bugging me for days....

Thanks again for the explanation about the VS changes w.r.t. 
'std::string'.

r

On 2019-03-29 09:57, rjl at third-monday.com wrote:
> 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