KDE/kdevplatform

[David Nolden]

Am Montag 11 Mai 2009 12:12:36 schrieb Andreas Pakulat:
> On 11.05.09 10:45:05, David Nolden wrote:
> > I've got to say, I don't like this specific kind of krazy fixes.
> >
> > - Q_SLOTS is plain ugly
>
> Yet, it disambiguates the far too general "slots" macro. This is not
> negotiable.
Which exact "slots" macro? Why does it work for me? Qt will define that macro 
anyway, whether we use it or not.

> > - assigning a character to a string may be allowed in the case of
> > QString, but semantically it's wrong and ugly, and additionally to that
> > we've already seen such changes cause new bugs. It's a micro optimization
> > that is irrelevant in these use-cases, and I think it shouldn't be done
> > on a general basis, given the disadvantages (Chance of new bugs, semantic
> > wrongness)
>
> Well, I'm not seeing us divert from QString in the mid or long term, so
> thats fine. However I agree that in most cases this is micro-optimization
> thats totally useless. So I suggest to simply mark these places as
> krazy-excluded (via an inline-comment) unless profiling shows that it
> really is a bottle-neck.
The problem about characters is that C++ will happily implicitly convert them 
to anything(float, int, anything that has a default-constructor taking one of 
those, ...). So I think it's bad practice to use them in place of strings. We 
already had bugs resulting from this. The replacement does not work properly 
in all contexts, and that's why it better should not be done at all(except 
when needed for performance reasons).

> And regarding the "semantically wrong and ugly", I don't follow you at all.
> Adding a character to a list of characters is just fine with me. It works
> in the real world (hey thats how I write), it works when typing files so I
> don't see any reason (except arbitrary limits imposed by the language or
> other string classes) why this shouldn't work in code.
Well, I'm talking about assigning, not about appending. 

Using characters in string assignment is equivalent to doing this:
QList<int> list;
list = 5;

Expecting to get a list that contains one item "5". This is breaking the 
standard conventions/semantics used in C++, and that's what makes it ugly.

Greetigns, David