[Development] The age-old T* foo vs. T *foo

[Jason H]

You're staring down the business end of a Saturn-V...
I for one, never liked
QObject* x, y;
because x is a pointer, and y is not. It seems like they should both be QObject*s.
Meanwhile:
QObject *x, y;
makes it very clear (clearer?) that x is a pointer and y is not.
Parenthesizing things shows just how awkward it is:
QObject(* x), (y); // really gotta reach for that star. (See what I did there!?)
vs.
QObject (*x), (y);

Of course readability was never C's strong suit.
I'd be ok with single decleartions:
QObject* x; // can't miss interpret this
QObject y;  // or this

But because you can have multiple variable declarations on a line (arguably the real thing to change) we're stuck with the confluence of two rules yielding chaos. This is an unfortunate lack of specificity in the standard.


> Sent: Thursday, October 17, 2019 at 1:11 PM
> From: zoltan.lutor at gmail.com
> To: ville.voutilainen at gmail.com
> Cc: development at qt-project.org
> Subject: Re: [Development] The age-old T* foo vs. T *foo
>
> Ooo, age old debate! ;)
>
> fingers crossed it will not end up in flame war...
>
> br,
>
> Zoltan
>
> ps: I'm with you... ;)
>
> On Thursday, October 17, 2019, Ville Voutilainen wrote:
> > Since we are about to do a major version upgrade, should be stop being
> > a special snowflake in the C++ world and start attaching pointer-stars
> > and reference-ampersands to the type instead of to the variable?
> >
> > As a quick example of how our current style is just odd, consider
> >
> > for (auto &&x : oink)
> >
> > Sure, that's in accordance with our style. It looks very out of place when
> > coming back to our code after adventures in other code. Quick reading
> > of it tends to suggest that it's a by-value thing since quick eyes see
> > auto without any decorations.
> >
> > I don't expect the transition, should we agree to have it, to be easy
> > for people accustomed to the Qt style. I also don't have any sort of numbers
> > about whether our style is used elsewhere. In contrast, people with lots
> > of exposure to non-Qt style tend to have to fight ours, it just doesn't come
> > naturally.
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > https://lists.qt-project.org/listinfo/development
> >
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>