blend function urgently needed in kdelibs
huntedhacker at tiscali.co.uk
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 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:
// 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...
Ubuntu/Kubuntu: http://www.ubuntu.org http://www.kubuntu.org
Please avoid sending me Word or PowerPoint attachments.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel