[Kde-bindings] SMOKE copy constructor problem

Germain Garand germain at ebooksfrance.org
Tue Jun 8 09:27:29 UTC 2004


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?

>
> 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:
>
>         my $kListView = KDE::ListView(this, "");
>         $kListView->addColumn("Content");
>         $kListView->setSorting(-1);
>
>         my $item0 = KDE::ListViewItem($kListView);
>         $item0->setText(0, "Root");
>         $item0->setOpen(1);
>
>         my $item3 = KDE::ListViewItem($item0);
>         $item3->setText(0, "Level 1, Third Item");
>
>         my $item1 = KDE::ListViewItem($item0);
>         $item1->setText(0, "Level 1, First Item");
>
>         my $item2 = KDE::ListViewItem($item0, $item1);
>         $item2->setText(0, "Level 1, Second Item");
>
> 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...

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....

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?

Germain

>
> -- Richard




More information about the Kde-bindings mailing list