[Kde-bindings] SMOKE copy constructor problem

[Richard Dale]

On Tuesday 08 June 2004 10:27, Germain Garand wrote:
> Le Mardi 08 Juin 2004 06:15, Richard Dale a écrit :
> > I've had a problem with copy constructors with SMOKE. A copy constructor
> > is added for a Smoke class, even if the original C++ class didn't have
> > one, according to the following rule:
> >
> > # If the class has no explicit copy constructor, and it can be copied,
> > # generate the copy constructor.
> > if ( !$classNode->{HasCopyConstructor}
> >            && $classNode->{CanBeCopied}
> >           && $classNode->{CanBeInstanciated} ) {
> > 		...
> > }
> >
> > QListViewItem and KListViewItem have these additional constructors, but
> > it causes problems with ruby. I tried a QListViewItem example in PerlQt
> > and that worked ok, even though it found ambiguous method calls:
> >
> > perl listview.pm
> > Ambiguous method call for :
> >         QListViewItem::QListViewItem(QListViewItem)
> > Candidates are:
> >         QListViewItem* QListViewItem::QListViewItem(QListViewItem*)
> >         QListViewItem* QListViewItem::QListViewItem(const QListViewItem&)
> >
> > Taking first one...
> >
> >
> > In ruby it fails and won't run because ambiguous calls are an error.
>
> I thought you had an ambiguous methods resolver aswell?
> do you bail out when you can marshall either e.g as an int, a double or a
> long or is that only for classes?
Yes, qtruby has the same logic as PerlQt apart from matching classes. I think 
you implemented a 'nearest subclass' match, whereas QtRuby just goes for an 
exact match first or any subclass is second best. I've been meaning to copy 
the latest PerlQt code for that..
 
If there is an ambiguous method call, it doesn't just choose the first one 
like PerlQt - it's an error. Maybe PerlQt should only allow ambiguous methods 
with no 'use strict' option?

> > But both ruby and perl won't work with KListViewItems because the copy
> > constructor expects a 'const KListViewItem&' argument, while all the
> > normal constructors expect a parent QListViewItem to be passed. So the
> > copy constructor will get called instead of the correct one that expects
> > a parent.
> >
> > I would expect this PerlKDE code won't work:
> >
> >
> > I haven't got PerlKDE setup, so I can't try it out and confirm, but I
> > think
>
> Confirmed. The copy constructor gets picked up.
>
> > these autogenerated copy constructors should be removed from the Smoke
> > runtime as they're more trouble than they're worth.
>
> The problem is not what they are worth for the user, it's that right now we
> need them from the binding in at least two circumstances:
> - when we have to marshall a const ref "ToLanguage"
> - when we have to marshall a stack item "FromLanguage"
>
> when this happens, we have to be able to locate a copy constructor, even
> the default, or we are in deep troubles...
Yes, I wasn't sure if there was some problem like this. But I couldn't see 
that the cf_deepcopy flag was being used:

baldhead duke 1186% pwd
/home/duke/src/PerlQt-3.008/PerlQt
baldhead duke 1187% grep deepcopy *
smokeperl.h:    bool hasCopy() const { return flags() & Smoke::cf_deepcopy; }
baldhead duke 1188% grep hasCopy *
smokeperl.h:    bool hasCopy() const { return flags() & Smoke::cf_deepcopy; }

> the first could be fixed in Smoke by building a copy of const ref
> arguments, that would then be freed by the binding,
> but the second is unavoidable....
Maybe that sounds too complicated

> A simple plan would be to add some logic in the binding to remove copy ctor
> methods from the ambiguous list (testing for cf_deepcopy beforehand),
> or much better: go the BIC route and add an mf_copyctor method flag...
> what do you think?
Yes, we need a way of having some 'internal methods' which wouldn't be visible 
via pqtapi, but could be used by marshallers (if I could work out where 
cf_deepcopy is used at the moment). I don't think there are enough QtRuby 
users yet for BIC to be an issue for ruby.

-- Richard