From boris at codesynthesis.com Tue Nov 3 08:17:39 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Nov 3 08:37:59 2020 Subject: [xsde-users] xsd/e: Compiler warnings from copy ctor of var_const_iterator (sequence.hxx:428) In-Reply-To: <290be19ac76b6f3875eb0048ede29cc6bdb31565.camel@sdl.usu.edu> References: <290be19ac76b6f3875eb0048ede29cc6bdb31565.camel@sdl.usu.edu> Message-ID: Jonathan Haws writes: > The code seems to behave the same at runtime when I remove that copy > constructor and just use the compiler default (which from what I can > tell should produce nearly identical code). All versions of GCC that > I have tried build properly and no issues at runtime. > > Can you help me understand what is going on? Yes, that copy assignment operator should not be necessary. However, I've fixed this[1] by adding the matching copy constructor. From the commit message: "Instead of adding the copy constructor we could have also dropped the copy assignment since it is identical to what would be implied. It's not, however, clear why it was added in the first place (it was added before we started tracking development with git). Chances are, some old and broken compiler is confused by the other assignment operator. So to be on the safe side we rather add the copy constructor." > Is there a newer version of xsd/e that I can use? 3.2.0 is the latest official release. There are some pre-release snapshots[2] but they don't include this fix. The easiest is probably just to patch your copy of 3.2.0. [1] https://git.codesynthesis.com/cgit/xsde/xsde/commit/?id=70bd99294d2054a69329c362a4c2d6f4bd0714b3 [2] https://codesynthesis.com/~boris/tmp/xsde/ From Jonathan.Haws at sdl.usu.edu Tue Nov 3 10:39:08 2020 From: Jonathan.Haws at sdl.usu.edu (Jonathan Haws) Date: Tue Nov 3 10:59:52 2020 Subject: [xsde-users] xsd/e: Compiler warnings from copy ctor of var_const_iterator (sequence.hxx:428) In-Reply-To: References: <290be19ac76b6f3875eb0048ede29cc6bdb31565.camel@sdl.usu.edu> Message-ID: <76be20cc262161a21bab58d5d10bc0b911583d3d.camel@sdl.usu.edu> On Tue, 2020-11-03 at 15:17 +0200, Boris Kolpackov wrote: > Yes, that copy assignment operator should not be necessary. However, > I've fixed this[1] by adding the matching copy constructor. From the > commit message: > > "Instead of adding the copy constructor we could have also dropped > the copy > assignment since it is identical to what would be implied. It's not, > however, > clear why it was added in the first place (it was added before we > started > tracking development with git). Chances are, some old and broken > compiler is > confused by the other assignment operator. So to be on the safe side > we > rather add the copy constructor." > This is exactly what I needed. Thanks! > > Is there a newer version of xsd/e that I can use? > > 3.2.0 is the latest official release. There are some pre-release > snapshots[2] but they don't include this fix. The easiest is > probably just to patch your copy of 3.2.0. Acknowledged. Will there be a new release in the near future? In the meantime, we'll likely just point to this commit. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5562 bytes Desc: not available Url : https://codesynthesis.com/pipermail/xsde-users/attachments/20201103/e8dca813/smime.bin From boris at codesynthesis.com Wed Nov 4 10:51:26 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Nov 4 11:11:38 2020 Subject: [xsde-users] xsd/e: Compiler warnings from copy ctor of var_const_iterator (sequence.hxx:428) In-Reply-To: <76be20cc262161a21bab58d5d10bc0b911583d3d.camel@sdl.usu.edu> References: <290be19ac76b6f3875eb0048ede29cc6bdb31565.camel@sdl.usu.edu> <76be20cc262161a21bab58d5d10bc0b911583d3d.camel@sdl.usu.edu> Message-ID: Jonathan Haws writes: > Will there be a new release in the near future? We don't have a definitive plan yet, we still want to rework the build system quite a bit. But if you have any problems getting this commit applied in a manageable way, let me know and we will figure something out.