[Development] Converting types in Qt
Ziller Eike
Eike.Ziller at digia.com
Wed Jul 16 12:37:45 CEST 2014
On Jul 16, 2014, at 11:58 AM, Konrad Rosenbaum <konrad at silmor.de> wrote:
> 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
> words.
>
> 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?
This can be considered an API fail, which is why you can explicitly turn off these type of conversions for your applications by defining QT_NO_CAST_TO_ASCII QT_NO_CAST_FROM_ASCII (which we e.g. do for Qt Creator).
Br, Eike
--
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
More information about the Development
mailing list