[Development] Some Qt3D feedback

Sean Harmer sean.harmer at kdab.com
Tue Jun 16 15:58:21 CEST 2015


On Tuesday 16 Jun 2015 15:33:00 André Somers wrote:
> Marc Mutz schreef op 16-6-2015 om 15:41:
> > On Tuesday 16 June 2015 11:39:56 Ulf Hermann wrote:
> >>> Note that in a world of auto variables, class names are no longer _that_
> >>> important. Functions are important, they are still visible. But other
> >>> than at initial creation, class names fade to be background.
> >>> 
> >>> And now you tell me how using lots of auto is bad for readability,
> >>> because you never know what type the variable has, to which I will
> >>> reply that in Python, Perl, PHP, JavaScript and others, there's no
> >>> way to spell the type of a variable, and people write very large
> >>> projects in these languages and never look back.
> >> 
> >> Uh, no, you either don't write large projects in PHP (or Perl), or you do
> >> look back with *fond* memories. At least that's my experience. And the
> >> insane type system of PHP definitely has something to do with this. So, I
> >> do like to make it clear what types I'm using (except for specific
> >> situations like iterators in loops) and namespaces can definitely help
> >> here. I understand we're not exposing them in public API today, but that
> >> doesn't mean they're useless.
> > 
> > Don't confuse the problems of dynamic type systems with not mentioning the
> > variable type.
> > 
> > This is the style advocated by the likes of Scott Meyers:
> >      auto widget = new QWidget(this);
> >      auto layout = new QVBoxLayout(widget);
> >      auto le = new QLineEdit(widget);
> 
> If we go use arguments-by-authority: according to Alexander Stepanov
> Scott Meyers is not to be taken seriously :-) Seeing you refered to his
> lectures before, I will assume you are familiar with his critisms...
> 
> > For type conversions, you're supposed to use static_cast on the rhs:
> >      auto integer = static_cast<int>(someLongLong);
> 
> Sorry, but that just looks silly to me. Why obfusticate the type of the
> variable - making it harder to reason about the code - when it yields
> you nothing at all? If we're talking about something like an iterator,
> by all means use auto, but for the case above, I don't find a good
> reason to do this.
> 
> > All this is still statically typed, and at some point QtC will show you
> > the
> > type of the variable when you hover, if it doesn't already.
> 
> It is great that creator can/will be able to do this and it certainly
> helps, but that doesn't mean it is good practice to rely on it if not
> needed. It is nice to be able reason about a piece of code from any
> editor, or when printed on a sheet of paper too...
> 
> 
> Anyway, the issue I was refering to is not too related to the use of
> auto IMHO. I was wondering what the impact was of this (from your
> earlier example):
> 
> auto transform = new QTransform();
> 
> Which transform would that be? Is this code about QtGui::QTransform or
> Qt3D::QTransform? You will need more context to tell, possibly up to the
> top of the file somewhere to find a using clause. The question I posted
> was if this would be a problem in practice or not, especially when
> posting a snippet using these classes somewhere or trying to find
> documentation on the class. Perhaps the answer is "No, no problem", but
> it is still as aspect to think about.

That would be clear from the context imho. Reasoning about code does not 
usually happen in isolation to the extent of single line snippets.

There is a good probability that in a TU using Qt3D::QTransform that you will 
be dealing with 3D content and aggregating the transform into a QEntity. If 
you are using QTransform you are almost certainly concerned with purely 2D 
painting operations we're all familiar with

Therefore the context would give a very strong indication to the reader about 
disambiguation and if you do happen to have a corner case where you're using 
both QTransform and Qt3D::QTransform in the same TU either provide more 
context to the snippet or don't use a using namespace directive and be 
explicit.

Cheers,

Sean
-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts



More information about the Development mailing list