[C++-sig] Avoid Implicitly conversion for non direct conversion

[Hans Meine]

Am Mittwoch, 06. Januar 2010 14:10:02 schrieb Renato Araujo:
> On Wed, Jan 6, 2010 at 4:59 AM, Hans Meine <hans_meine at gmx.net> wrote:
> > But only if you pass objects that need to be converted, right?
>
> Yes but this is the user level I would like to avoid this.

Ah, you fear users saying "PySide is slow" because they're unknowingly using 
implicit conversions?  How slow is this really?  IMO BPL method calls are not 
blazingly fast anyway, since there is a lot of stuff happening at runtime, so 
one should not try to call millions of methods in the first place.

I am not convinced there's a problem, so maybe you could try to ignore it for 
now.

> I have a class QVariant (Docs:
> http://doc.trolltech.com/4.6/qvariant.html) with many constructos, adn
> each type has your implicitly conversion rule.
> One example is QCorlor (Docs:
> http://doc.trolltech.com/4.6/qcolor.html) this is implicitly
> conversible from "int".
>
> Then when I create a QVariant(1) (passing int as argument)
> boost.python call the QVariant(QColor) constructor. I think this
> happening because boost.python try the implicitly conversion before
> verify the other basics signatures.

Yes, but here the implicit conversion is not the problem IMO, but the fact 
that BPL tries the overloaded functions one-by-one and uses the first 
matching, instead of the "best" one.

> This is one of the case I have a
> lot of others because I have more then 100 classes and more then 200
> implicitly conversions rules, it's almost impossible to me,  manager
> this if the conversion can happen in every class level.

I see, this is exactly the problem that I had in mind when I wrote about the 
overloading problem.  (Without overloading, implicit conversion should not bug 
you, right?)

> > You might have problems with overloaded functions, in which case Troy's
> > recently suggested BPL extension would most likely help.  (I am looking
> > forward to its integration).
>
> Where I can get more info about this I searched in ML but I did not
> find any info related.

Cf. recent thread "Implementation of proper overload resolution".

HTH,
  Hans