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
Micros
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 b
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 &v;
I don't know what you're talking about.
> QRect(const
On Thursday, 17 October 2019 17:28:34 PDT Henry Skoglund wrote:
> std::string s = std::format("{0:b} {0:d} {0:x}", 42); // s ==
> "101010 42 2a"|
>
> Using QString::arg() works fine but it's getting harder to ignore all
> the new C++ stuff and C++20 looks to be one of the bigger additions to
> t
On Thursday, 17 October 2019 17:28:34 PDT Henry Skoglund wrote:
> Perhaps the time has come to think about a retirement plan for QString?
Sure. As soon as the C++ standard has something that we can replace it with
*and* we can reliably use it for all our target compilers.
Since the earliest this
Thanks for the answers!
I haven't got much experience yet of std::string so I thought the grass
was greener over there. But sure, functions like split() and trimmed() I
use regularly, and they indeed seem to be lacking in std::string.
So sorry QString about that brief moment of infidelity, won't
On Fri, 18 Oct 2019 at 08:43, Alexander Nassian
wrote:
>
> C++ hasn‘t even proper Unicode handling integrated. std::string is a mess in
> my opinion.
>
> Beste Grüße / Best regards,
> Alexander Nassian
>
> Am 18.10.2019 um 02:30 schrieb Henry Skoglund :
>
> > Hi, while writing lots of QString s
C++ hasn‘t even proper Unicode handling integrated. std::string is a mess in my
opinion.
Beste Grüße / Best regards,
Alexander Nassian
> Am 18.10.2019 um 02:30 schrieb Henry Skoglund :
>
> Hi, while writing lots of QString string fiddling code (keyboard macro
> utility) I feel something tugg
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 e
Hi, while writing lots of QString string fiddling code (keyboard macro
utility) I feel something tugging at my sleeve:
the upcoming C++20, looking at std::format(), it seems really handy, e.g.:
std::string s = std::format("String '{}' has {} characters\n", string,
string.length());
// for a G
> > 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
&v;
QRect(const QPoint &topLeft, const QSize &size)
QRect(const QPoint &topLeft, const QPoint &bottomRight)
boolc
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 i
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 a
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 reference-ampersand
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 w
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 referen
>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 o
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?) th
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
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 attachi
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)
S
The coin production baseline update has been reverted back to the
previous state 1.1 since the QEMU targets were broken in multiple branches.
New attempt will be scheduled for next week.
On 10/16/19 1:40 PM, Aapo Keskimolo wrote:
> Hi Qt Developers,
>
>
> We are preparing for Coin production up
26 matches
Mail list logo
