[Development] Converting types in Qt
konrad at silmor.de
Wed Jul 16 11:58:28 CEST 2014
On Wednesday 16 July 2014 08:41:07 Poenitz Andre wrote:
> Olivier Goffart wrote:
> > It's always a dilemma. We have to look at how likely we are to break
> > applications and I don't think adding a conversion is likely to cause
> > breakages.
> Type safety is a safety net that catches errors very early in the
> software production and deployment cycle, and one of the features
> that makes a programming language usable for the development
> of large applications at a reasonable pace.
I feel I need to clear up some misconceptions here: the kind of type safety
offered by C++ is a possibility, but not a necessity for fast and safe
development of large applications. I've done Smalltalk for quite some time -
it does not have a static type system like C++ and development is still
faster than in most C++ based environments - I'd even go as far as saying it
is slightly faster to develop with Smalltalk than it is to develop with Qt
(I still prefer Qt for its more modern API). The key is usually great
documentation, good tooling, good APIs and fast turn-around from adding a
few lines to seeing them in action (in the last point C++ can't even hope to
compete with Smalltalk, the other three are quite good with Qt).
> Implicit type conversions kill type safety. This is widely recognized
> as a bad thing. In case of C++ some are "unavoidable" due to the
> C legacy, but e.g. for user-defined conversion operators we now got
> "explicit", _because_ people learned the hard way that implicit
> conversions are causing more trouble than wanted.
Let's not mix up too much here: type conversions are necessitated by the
fact that C++ has static typing - otherwise you would not get much done with
it - from the Smalltalk point of view C++ is not polymorphic. Implicit type
conversions are necessitated by the fact that programmers (like me) are lazy
bastards and don't like to read lines which are longer than a couple of
The explicit keyword is just a way of telling the compiler that a
constructor is NOT a type conversion - however, I'm not entirely sure
whether it was such a brilliant idea to have two kinds of implicit user
defined conversion (constructors and type operators).
So, just get used to the idea of prefixing each constructor with an
"explicit" and only consider removing it again afterwards.
> This is a kind of "convenience" I don't need, and I pretty much prefer
> the inconvenience of having to spell out type conversions explicitly.
Reminds me of the early days of Java - almost every cast was explicit and
you wrote endless lines of casts just to get a very simple resource.
Thanks, but no thanks.
In short: you need a certain amount of convenience to not hinder the
programmer. Too much magic in the background and it is just as bad. The
difficulty seems to be to define the ideal point between convenience and
shooting yourself into the foot all the time.
As long as QVariant mirrors the abilities of C++ (i.e. only using implicit
conversions that are also available in plain C++, plus maybe a few very
obvious ones, like toString) we are fine. More and we'll get weird bug
reports, less and programmers will constantly bitch about it.
BTW: you can already implicitly cast QByteArray->QString, so why not allow
it through QVariant?
More information about the Development