[PyQt] Patch fixing some const issues

Phil Thompson phil at riverbankcomputing.com
Fri Aug 11 22:08:23 BST 2017


On 11 Aug 2017, at 5:44 pm, oliver <oliver.schoenborn at gmail.com> wrote:
> 
> Without seeing the code this may be Irrelevant but one thing I remember about autopointer is that it has move semantics. So for "a=b" with both being autopointer, causes b to become an autopointer to null. B can be an autopointer to const but cannot be a const autopointer.

Maybe the best thing is just to add an annotation that suppresses the generation of this particular helper. As this is using pointers it shouldn't be needed anyway.

Phil

> On Fri, Aug 11, 2017, 12:22 Shaheed Haque, <srhaque at theiet.org> wrote:
> On 11 August 2017 at 16:55, Phil Thompson <phil at riverbankcomputing.com> wrote:
> On 11 Aug 2017, at 4:37 pm, Shaheed Haque <srhaque at theiet.org> wrote:
> >
> >
> >
> > On 11 August 2017 at 16:02, Phil Thompson <phil at riverbankcomputing.com> wrote:
> > On 11 Aug 2017, at 1:47 pm, Shaheed Haque <srhaque at theiet.org> wrote:
> > >
> > > Hi,
> > >
> > > Based on 4.19.4.dev1708081632, I see some issues with the emitted code involving casts. There are several cases, but here is one example that illustrates the issue:
> > >
> > > ===  4.19.4.dev1708081632 output ===
> > > static void assign_std_auto_ptr_0100GpgME_EditInteractor(void *sipDst, SIP_SSIZE_T sipDstIdx, const void *sipSrc)
> > > {
> > >     reinterpret_cast< ::std::auto_ptr< ::GpgME::EditInteractor> *>(sipDst)[sipDstIdx] = *reinterpret_cast<const ::std::auto_ptr< ::GpgME::EditInteractor> *>(sipSrc);
> > > }
> > > ==============================
> > >
> > > The above won't compile with errors boiling down, IIUC, to the fact that the RHS has type "const something", and this is not compatible with the LHS which has type "something" without the const. Now, I'll confess that I'm a bit rusty on some of this, but I think the correct fix is to cast away the constness of sipSrc earlier, like this:
> > >
> > > === patched version ===
> > > static void assign_std_auto_ptr_0100GpgME_EditInteractor(void *sipDst, SIP_SSIZE_T sipDstIdx, const void *sipSrc)
> > > {
> > >     reinterpret_cast< ::std::auto_ptr< ::GpgME::EditInteractor> *>(sipDst)[sipDstIdx] = *reinterpret_cast< ::std::auto_ptr< ::GpgME::EditInteractor> *>(const_cast<void *>(sipSrc));
> > > }
> > > ===================
> > >
> > > Now, the LHS and the RHS match, and the compiler is happy. There are 4 similar cases in gencode.c which I patched, as below. This patch also includes my diffs for the static_cast<int>s from https://www.riverbankcomputing.com/pipermail/pyqt/2017-August/039494.html.
> > >
> > > (There is also one slightly different usage of reinterpret_cast<const ...> but I am not sure if that is implicated or not).
> >
> > I don't see why the RHS breaks the constness. Is std::auto_ptr doing something out of the ordinary?
> >
> > As I hinted, I'm well outside my comfort zone here, so take anything say with a pinch of salt. That said...
> >
> > It *might* well be auto_ptr-related, but I'm not sure, because the second paragraph on page http://en.cppreference.com/w/cpp/memory/auto_ptr seems to suggest that the RHS is being modified by the assignment (but that seems astonishing to me, so perhaps I am misreading it?). It is also true that all of the other templated types I am trying to support work fine in this regard.
> >
> > At any rate, the voluminous errors that result all seem to point to the assignment itself being bad, and to my simple-minded thinking, the problem is more that with the original formulation, the RHS is a const-qualified type, while the LHS is not.
> 
> Yes but the expression is making a copy of the object on the RHS so the mis-match shouldn't make a difference.
> 
> My reading is that the documentation saying that the RHS is changed by the assignment, and that the const is interfering with that!
>  
> Phil
> 
> _______________________________________________
> PyQt mailing list    PyQt at riverbankcomputing.com
> https://www.riverbankcomputing.com/mailman/listinfo/pyqt
> -- 
> Oliver
> My StackOverflow contributions
> My CodeProject articles
> My Github projects
> My SourceForget.net projects



More information about the PyQt mailing list