blend function urgently needed in kdelibs

Alex Merry huntedhacker at
Wed May 23 09:44:53 BST 2007

On Tuesday 22 May 2007, Matthew Woehlke wrote:
> Thiago Macieira wrote:
> > The two constructors:
> >     KColor( const QColor& );
> >     KColor( const KColor& );
> > are different in meaning. The latter one is a copy-constructor and
> > it generally makes no sense to make it explicit. So you can leave
> > it as it is.
> [snip]
> > [snip link]
> > In this case, I would say that the whole point is to allow implicit
> > casting, so you want to tell krazy that you know it is implicit.
> > Just add an " // implicit" after it to tell krazy to go away.

You don't need the "implicit" mark after the copy-constructor - Krazy is 
intelligent enough to know that copy-constructors shouldn't be 

What I think Thiago meant by that comment was that he assumed KColor( 
const QColor& ); was intended to be implicit, eg: so this would work:
QColor qcolor;
// other stuff
KColor kcolor = qcolor;
For example, QString has an implicit constructor that takes a const char 

The reason for the libs policy is that, in most cases, things like this 
don't make sense, semantically, and it's easy to forget that both sides 
of the assignment don't have the same type.  The explicit keyword 
forces you to do "KColor kcolor(qcolor)" (ie: "make a KColor out of 
this QColor", rather than "this KColor should 'be the same' as this 

In the case of KColor, both make sense, since KColor is meant to 
represent the same thing (a colour) as QColor.

Hope this explanation makes some sort of sense...


Please avoid sending me Word or PowerPoint attachments.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the kde-core-devel mailing list