> 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
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
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
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
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
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
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
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
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.
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 -
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
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
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
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
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
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
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
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
> > 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
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
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
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
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
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
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
>
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
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
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
t 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 po
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?)
.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
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
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)
33 matches
Mail list logo
