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

[Jason H]

> I think that this discussion is pointless.

I don't think any discussion is pointless. At the very least I learn of others' 
opinions, and on occasion, adopt them :-). Even if we don't change we at least 
never reached a threshold that we agreed to for change, which, is something. 
And not least of all, I'm always learning stuff from the Trolls.

Thank you all for the discussion.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Oswald Buddenhagen]

On Sun, Oct 20, 2019 at 12:14:29AM +0300, Ville Voutilainen wrote:

On Fri, 18 Oct 2019 at 19:53, Edward Welbourne  wrote:

Putting the * or & to the left of the space promotes the lazy reading of
a declaration as being

  type name;

which works just fine for the most common cases, but lulls readers into
using a mental model that will leave them entirely unprepared for the
subtleties that arise when anything trickier happens.


This logical argument doesn't work. There's evidently no such lull,


do you have evidence for that claim? eddy at least provided anecdotes.

nor does putting the type-meta-modifiers next to the variable name 
result in a deeper understanding of how declarators work


not as such, but each time someone asks about/doubts the current style, 
they get educated.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Ville Voutilainen]

On Fri, 18 Oct 2019 at 19:53, Edward Welbourne  wrote:
> Putting the * or & to the left of the space promotes the lazy reading of
> a declaration as being
>
>   type name;
>
> which works just fine for the most common cases, but lulls readers into
> using a mental model that will leave them entirely unprepared for the
> subtleties that arise when anything trickier happens.

This logical argument doesn't work. There's evidently no such lull,
nor does putting the type-meta-modifiers
next to the variable name result in a deeper understanding of how
declarators work, again evidently.
However, read below.

> And, in any case, it is senseless to change this in a whole code-base.

Agreed. It would indeed be a massive change, so there are very few
opportunities to make such
a change, and as time passes on, they get weaker and weaker due to
sheer inertia. We are,
apparently, past that point. I am going to admit that we are, and I
would like to emphasize that
I don't think it's a passive-aggressive admission of defeat. Changing
almost-every-line-everywhere
is something I speak against of in other contexts, like re-indenting,
so I appreciate and agree with what
Eddy and Andre are saying, for the most important parts. The only last
straw I have is that I don't think
the technical arguments for the status quo make much sense, but
consistency and inertia matter.
But, as I tend to say, and what always makes Simon chuckle, I can live
with that.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Thiago Macieira]

On Friday, 18 October 2019 09:18:05 PDT Konstantin Tokarev wrote:
> > Make git move the star for you at checkout time (similarly to its CRLF
> > options). Git "just" needs C++ code model support.
> 
> No it doesn't, regular smudge/clean filters can do the work (e.g. by calling
> clang-format)

The problem with this is that our current code does is not clean according to 
that clean filter. So making a modification to a file would mean reformatting 
everything, which will not be accepted in code review.

Another problem is dealing with line numbers obtained from other people, like 
backtraces, or just plain looking at past history via git show and git blame. 
You *have* to deal with the original.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Edward Welbourne]

Jason H (18 October 2019 01:38) asked:
> How many code parsers would this change (i.e. QtCreator or QDoc?) (if
> any)?

I would consider it a bug in any of our parsers if it cared at all about
the placement of spaces.  I am tolerably confident QDoc (based, now,
on LLVM) won't need any change for this.

The distinction here goes back to C.  Even there, it's a fussy detail.
Although the Qt coding style does indeed ask for one declaration per
line (which is generally a good practice, regardless of the present
discussion, although I'd make exceptions when variables are closely
related, such as paired x, y co-ordinates; or the year, month, day parts
of a date), the common illustration

  int *p, i;

does point to something significant about the semantics of type
declarations in C (and, thus, C++).  Consider also:

  char array[size], *pointer = array;

Even without the part after the comma, notice that the type of array is
char [size], yet you can't write

  char[size] array;

which the logic of

  char* pointer;

kinda wants.  With the part after the comma, it should be clear that the
form of a declaration in C isn't

  type name [, ...];

In fact, it's (slightly simplified)

  decl-specifiers  init-declarator [, ...];

where the name is embedded somewhere in the init-declarator, but much of
the type information can be in the init-declarator with it; the
decl-specifiers only specify a base type and the storage class.  For
example,

  void (*handler)(int);

declares handler to be a pointer to a function that takes an int and
returns void; the decl-specifiers is just void, all the rest is the
init-declarator.  Next, consider (quoting a POSIX man-page):

  void (*signal(int sig, void (*func)(int)))(int);

declares signal to be a pointer to a function that takes an int sig and
a pointer of handler's type and returns a pointer of handler's type.
Again, void is the whole decl-specifiers; all of the rest is the
init-declarator.  I don't expect most readers of code to follow the
latter (I have to think about it myself), so I would *always* write it
as

  typedef void (*signal_handler_p)(int);
  signal_handler_p (*signal)(int, signal_handler_p);

to give readers slightly more of a chance of making sense of it.  The
typedef just echoes my declaration of handler, above, with "typedef
void" now as the decl-specifiers.  In the declaration of signal itself,
the initial signal_handler_p is the decl-specifiers; and the
init-declarator is all of the rest.

The init-declarator is a potentially complex text, that'll contain the
name, and the * or & of a declaration of a pointer or reference is part
of it, not part of the decl-specifiers.

Putting the * or & to the left of the space promotes the lazy reading of
a declaration as being

  type name;

which works just fine for the most common cases, but lulls readers into
using a mental model that will leave them entirely unprepared for the
subtleties that arise when anything trickier happens.

In X there's a callback type that returns void; I forget its name, but
naturally the X libraries typedef that callback type.  Long ago, I
cleaned up a mess that arose from some naive programmer defining
callbacks that returned that callback-type (rather than void) and took
the right argument lists.  Of course, he had to cast his callbacks to
the callback type when he tried to use them (because that wasn't their
actual type, but was what the API wanted).  Which meant his code was
littered with the callback type's name, where code that did the job
properly never mentioned the callback type's name *at all*.  Which meant
that other naive programmers, searching for something to copy and paste,
found his code and propagated his error at great length.  (When I
cleaned this all up, I took care to leave a comment next to each
callback's definition that named the callback type involved, so that
someone searching for that name would find correct code to copy.)  While
my fix for all of that was grinding its way through review and
integration, more instances of the error were introduced by naive
colleagues copying the same sources; I had to do a second round of
clean-up.

All of that arose because many programmers do not understand that type
declarations in C (hence also in C++) are more complicated than

  type name;

even though the callback parameter passed to the X library looked like
that in the library function's signature.

The (frankly minor) Good Thing about putting the * or & adjacent to the
name in a pointer or reference declaration is that it's a little
background reminder to everyone that some of the type info appears
syntactically bound to the name, not to the *base* type on the left.
This gives them just a tiny-bit better chance of coping better when they
meet less trivial types.  It's a tiny difference, but it's a nudge in
the right direction.

And, in any case, it is senseless to change this in a whole code-base.
We do have instances of the space after & or * and mostly we leave them

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

[Konstantin Tokarev]

18.10.2019, 19:11, "Sérgio Martins" :
> On Thu, Oct 17, 2019 at 7:05 PM 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?
>
> Make git move the star for you at checkout time (similarly to its CRLF 
> options).
> Git "just" needs C++ code model support.

No it doesn't, regular smudge/clean filters can do the work (e.g. by calling 
clang-format)

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Kyle Edwards via Development]

On Fri, 2019-10-18 at 17:09 +0100, Sérgio Martins wrote:
> Make git move the star for you at checkout time (similarly to its
> CRLF options).
> Git "just" needs C++ code model support.

I like this idea. While we're at it, let's also add automatic i18n
support to Git, so that developers can read and write in their native
tongue, while Git seamlessly translates it to and from the repository's
canonical language at checkout and commit time :)

Kyle
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Sérgio Martins]

On Thu, Oct 17, 2019 at 7:05 PM 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?

Make git move the star for you at checkout time (similarly to its CRLF options).
Git "just" needs C++ code model support.

Regards,
Sergio Martins
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Shegunov]

On Fri, Oct 18, 2019 at 6:40 PM Thiago Macieira
 wrote:
> Third option:
>
> char * const key;

Which is my style in my own projects - detaching the asterisk(s) with
whitespaces both sides. And in c++ there are types composed from
multiple tokens already, so it isn't anything original either way. The
discussion boils down to that - a style preference, which means it's
best decided by majority vote, which we don't have, nor do we employ,
thus from my point of view that makes it rather impractical bordering
irrelevant.

Kind regards,
Konstantin.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Thiago Macieira]

On Thursday, 17 October 2019 23:02:06 PDT Kai Pastor, DG0YT wrote:
> char *const key  vs.  char* const key

Third option:

char * const key;

I've seen all three in Qt source, though I think your first one is the one 
that strictly follows our coding style guidelines.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[André Somers]

On 18/10/2019 02:37, Kevin Kofler wrote:

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?

No, because it is syntactically not a part of the type, as evidenced by the
int *x, y; example that others have already pointed out. Semantically, it
is, but the semantics are only computed after doing the syntactic parsing,
so the whitespace should preferentially match the syntax.

And I consider the idea of banning comma declarations to work around this
issue to be nothing more than a workaround for poor notation not matching
the syntax of the language.


Apparently there are already good reasons not to do that even before 
considering T* foo vs T *foo, as it has been banned by the style already:


https://wiki.qt.io/Qt_Coding_Style#Declaring_variables

So this potential change will not cause issues in this area.


Personally, I have always preferred the T* foo (and T& bar) style, as to 
me the pointer-ness or reference-ness *is* part of the type of the 
variable. It is evident in how big the type is, in how typeid identifies 
the type of the variable, in type deduction...


Anyway, I doubt it's worth changing it.

André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Tokarev]

17.10.2019, 21:06, "Ville Voutilainen" :
> As a quick example of how our current style is just odd, consider
>
> for (auto & : 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 buy this. Space before '&&' may confuse simple tools like grep when
used naively, but definitely not a human reader.

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Vitaly Fanaskov]

Hi,


I think that this discussion is pointless. Style is mostly the matter of 
preferences, but:

1) We have a huge code base with the certain code style.

2) We have official guidelines.

3) We have a tool for auto code formatting.


I don't see any good reasons to change the entire code base or make it 
inconsistent, and adjust docs and tools. If a person is not used to the 
Qt style, he or she might use clang formatting tool for this.

On 10/17/19 8:04 PM, 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 & : 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@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Allan Sandfeld Jensen]

On Thursday, 17 October 2019 22:01:34 CEST Martin Smith wrote:
> >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.
> But that argues for not allowing the comma.
> 
> QObject* x;
> QObject* y;
> 
> I've always done it that way.
> 
Pretty sure that is also Qt code guidelines, and if not should be ;)


Allan


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Kai Pastor, DG0YT]

Am 17.10.19 um 23:24 schrieb Ville Voutilainen:

On Fri, 18 Oct 2019 at 00:16, André Pönitz  wrote:

And it's not "just our style".

LLVM uses the same style for stars and ampersands. Who else?


From clang-format-configurator [1], I see these base formats using the 
Qt style:


LLVM
Google
Microsoft

The other style is used by:

Chromium
Mozilla
Webkit

Kai.


[1] https://zed0.co.uk/clang-format-configurator/

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Kai Pastor, DG0YT]

Am 17.10.19 um 23:55 schrieb André Pönitz:

On Fri, Oct 18, 2019 at 12:24:12AM +0300, Ville Voutilainen wrote:

On Fri, 18 Oct 2019 at 00:16, André Pönitz  wrote:

On Thu, Oct 17, 2019 at 09:04:36PM +0300, 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?

No.

Why?

It's a huge effort for discussion and conversion effort
for practically no gain.

And it opens the gate for more such fruitless discussions
snake_style vs camelStyle
east const vs west const
getter/setter naming convention
Q prefix
namespaces
indentation
...

I also think that there are more than enough open issues
in JIRA that, when solved, would have more practical impact
than shifting around white space in the code base.


Maybe the discussion is not fruitless, even it only helps to write down 
the rationale for the current style. Especially "const" is the most 
interesting keyword next to pointer-star.


This is familiar:

const char *key = "word"  vs.  const char* key = "word"
// east-side const: char const *key...

But what its the most readable for a const pointer?

char *const key  vs.  char* const key

Kai.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Ville Voutilainen]

On Fri, 18 Oct 2019 at 02:38, Jason H  wrote:
>
> > > And it's not "just our style".
> >
> > LLVM uses the same style for stars and ampersands. Who else?
>
> That's another reason I prefer T *v; because you never see T& v, it's always 
> T 

I don't know what you're talking about.

> QRect(const QPoint , const QSize )
> QRect(const QPoint , const QPoint )
> boolcontains(const QPoint , bool proper = false) const
> boolcontains(const QRect , bool proper = false) const
> voidgetCoords(int *x1, int *y1, int *x2, int *y2) const
> voidgetRect(int *x, int *y, int *width, int *height) const
> int height() const
>
> is const Point& topLeft a thing?

Not in our code, but probably a more common thing than the alternative we use.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Kevin Kofler]

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?

No, because it is syntactically not a part of the type, as evidenced by the 
int *x, y; example that others have already pointed out. Semantically, it 
is, but the semantics are only computed after doing the syntactic parsing, 
so the whitespace should preferentially match the syntax.

And I consider the idea of banning comma declarations to work around this 
issue to be nothing more than a workaround for poor notation not matching 
the syntax of the language.

int* x; is just as misleading use of whitespace as:
if (foo)
  bar;
  baz;
(indented this way and without braces).

Kevin Kofler

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Jason H]

> > And it's not "just our style".
>
> LLVM uses the same style for stars and ampersands. Who else?

That's another reason I prefer T *v; because you never see T& v, it's always T 


QRect(const QPoint , const QSize )
QRect(const QPoint , const QPoint )
boolcontains(const QPoint , bool proper = false) const
boolcontains(const QRect , bool proper = false) const
voidgetCoords(int *x1, int *y1, int *x2, int *y2) const
voidgetRect(int *x, int *y, int *width, int *height) const
int height() const

is const Point& topLeft a thing? I like the indirection modifier next to the 
variable.

But if you change * you should change &.

How many code parsers would this change (i.e. QtCreator or QDoc?) (if any)?

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[André Pönitz]

On Fri, Oct 18, 2019 at 12:24:12AM +0300, Ville Voutilainen wrote:
> On Fri, 18 Oct 2019 at 00:16, André Pönitz  wrote:
> >
> > On Thu, Oct 17, 2019 at 09:04:36PM +0300, 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?
> >
> > No.
> 
> Why?

It's a huge effort for discussion and conversion effort
for practically no gain.

And it opens the gate for more such fruitless discussions
   snake_style vs camelStyle
   east const vs west const
   getter/setter naming convention
   Q prefix
   namespaces
   indentation
   ...

I also think that there are more than enough open issues
in JIRA that, when solved, would have more practical impact
than shifting around white space in the code base.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Matthew Woehlke]

On 17/10/2019 17.24, Ville Voutilainen wrote:
> On Fri, 18 Oct 2019 at 00:16, André Pönitz  wrote:
>>
>> On Thu, Oct 17, 2019 at 09:04:36PM +0300, 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?
>>
>> No.
> 
> Why?
> 
>>
>> And it's not "just our style".
> 
> LLVM uses the same style for stars and ampersands. Who else?

https://github.com/uncrustify/uncrustify uses stars-with-variable. (That
said, my own code, both personal and professional, typically uses
stars-with-type.)

-- 
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Danila Malyutin]

git, gcc, Linux?

пт, 18 окт. 2019 г. в 00:25, Ville Voutilainen :

> On Fri, 18 Oct 2019 at 00:16, André Pönitz  wrote:
> >
> > On Thu, Oct 17, 2019 at 09:04:36PM +0300, 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?
> >
> > No.
>
> Why?
>
> >
> > And it's not "just our style".
>
> LLVM uses the same style for stars and ampersands. Who else?
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Ville Voutilainen]

On Fri, 18 Oct 2019 at 00:16, André Pönitz  wrote:
>
> On Thu, Oct 17, 2019 at 09:04:36PM +0300, 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?
>
> No.

Why?

>
> And it's not "just our style".

LLVM uses the same style for stars and ampersands. Who else?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[André Pönitz]

On Thu, Oct 17, 2019 at 09:04:36PM +0300, 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?

No.

And it's not "just our style".

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Philippe]

For sure, one very  rarely sees T *foo in C++ projects.
Not without a reason.

Philippe

On Thu, 17 Oct 2019 21:04:36 +0300
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 & : 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@qt-project.org
> https://lists.qt-project.org/listinfo/development


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Alexander Nassian]

The * or & or && always have an impact on the actual type the variable has. So 
my logical implication would be that *, &, && has to be placed there: QObject* 
x and not QObject *x.

Beste Grüße / Best regards,
Alexander Nassian

> Am 17.10.2019 um 20:06 schrieb Ville Voutilainen 
> :
> 
> 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 & : 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@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 













—


bitshift dynamics GmbH
Neudorfer Str. 1, 79541 Lörrach

Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747

Geschäftsführer: Alexander Nassian, Markus Pfaffinger



http://www.bitshift-dynamics.de 


Zentrale: +49 762158673 - 0
Fax: +49 7621 58673 - 90


Allgemeine Anfragen: 
i...@bitshift-dynamics.com 
Technischer 
Support: supp...@bitshift-dynamics.com 

Buchhaltung: 
invo...@bitshift-dynamics.com 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Vasily Pupkin]

Declaring variables

   - Declare each variable on a separate line

https://wiki.qt.io/Qt_Coding_Style

Multiple declarations on the same line is not a valid argument as long as
they are forbidden.

Asterisk position, imho, should be based on the mental model.

X* x - is an identifier that names a variable. It's type is a pointer to X
and it's size btw is the same as any other pointer to object.

I have just chimed in to ask about the state of introducing automatic
coding styling.
https://bugreports.qt.io/browse/QTCREATORBUG-22149?jql=text%20~%20%22linter%22

https://bugreports.qt.io/browse/QTCREATORBUG-21877?jql=text%20~%20%22coding%20style%22




чт, 17 окт. 2019 г. в 23:13, Kyle Edwards via Development <
development@qt-project.org>:

> On Thu, 2019-10-17 at 20:01 +, Martin Smith wrote:
> > But that argues for not allowing the comma.
> >
> > QObject* x;
> > QObject* y;
> >
> > I've always done it that way.
>
> +1 for not allowing the comma. It's not as much of an issue for simple
> types (int x, y), but combining it with pointers and references
> introduces ambiguity and makes the code less readable - and readability
> is, IMHO, far more important than saving a few keystrokes.
>
> Kyle
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Kyle Edwards via Development]

On Thu, 2019-10-17 at 20:01 +, Martin Smith wrote:
> But that argues for not allowing the comma.
> 
> QObject* x;
> QObject* y;
> 
> I've always done it that way.

+1 for not allowing the comma. It's not as much of an issue for simple
types (int x, y), but combining it with pointers and references
introduces ambiguity and makes the code less readable - and readability
is, IMHO, far more important than saving a few keystrokes.

Kyle
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Martin Smith]

>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.

But that argues for not allowing the comma.

QObject* x;
QObject* y;

I've always done it that way.


From: Development  on behalf of Jason H 

Sent: Thursday, October 17, 2019 9:34 PM
To: zoltan.lu...@gmail.com
Cc: development@qt-project.org
Subject: Re: [Development] The age-old T* foo vs. T *foo

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.lu...@gmail.com
> To: ville.voutilai...@gmail.com
> Cc: development@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 & : 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@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> >
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Ville Voutilainen]

On Thu, 17 Oct 2019 at 22:34, Jason H  wrote:
>
> 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.

I don't think this is news to anyone, but the usual suggestion to
avoid that problem is not writing comma-separated declarations. That
tends to work perhaps surprisingly well, in practice.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [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.lu...@gmail.com
> To: ville.voutilai...@gmail.com
> Cc: development@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 & : 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@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> >
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[zoltan . lutor]

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 & : 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@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development