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
Hi Qt Developers,
Thank you for your amazing work at this library.
This message is a cross-posting with the Qt Forum (
https://forum.qt.io/topic/107830/issues-with-qformbuilder-all-properties-modified-invalid-ui)
more detailed information can be found there as well as pictures showcasing
the Desi
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 th
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 instea
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 an
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 fo
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. Th
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.
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 syn
17.10.2019, 21:06, "Ville Voutilainen" :
> 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 ten
We are happy to announce the release of Qt Creator 4.11 Beta!
https://www.qt.io/blog/qt-creator-4.11-beta-released
--
Eike Ziller
Principal Software Engineer
The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika
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 t
13 matches
Mail list logo
