On 24 July 2015 at 01:28, Thiago Macieira thiago.macie...@intel.com wrote:
On Thursday 23 July 2015 16:05:44 Guido Seifert wrote:
Op 23-7-2015 om 08:42 schreef Thiago Macieira:
Q_GADGET has existed since 4.0.
Sure, but it was undocumented API.
Not quite. It was badly documented API. I
Op 23-7-2015 om 08:42 schreef Thiago Macieira:
Q_GADGET has existed since 4.0.
Sure, but it was undocumented API.
Not quite. It was badly documented API. I think it was mentioned in the 4.8
docs in the Q_OBJECT section.
Guido
___
Interest
Den 23-07-2015 kl. 07:57 skrev Gunnar Roth:
Am 23.07.2015 um 07:51 schrieb Bo Thorsen b...@vikingsoft.eu
mailto:b...@vikingsoft.eu:
Den 23-07-2015 kl. 00:07 skrev Thiago Macieira:
Disabling C4244 /* conversion from 'type1' to 'type2', possible loss
of data
*/ is more than going to far. It
On Thursday 23 July 2015 09:21:13 Jérôme Godbout wrote:
I admit the int to unsigned
int is also a problem to become, -1 lead to 2^32 - 1, we can only do that
if you known negative number aren't used and should do a static_cast
or reinterpret_cast according to the situation and handle the
On Thursday 23 July 2015 09:40:14 Samuel Stirtzel wrote:
2015-07-22 22:52 GMT+02:00 Thiago Macieira thiago.macie...@intel.com:
And then there's another trick... we also began using -isystem with GCC
and
Clang, so they don't complain about warnings in Qt itself :-)
Hi,
is there a trick
On Thursday 23 July 2015 16:05:44 Guido Seifert wrote:
Op 23-7-2015 om 08:42 schreef Thiago Macieira:
Q_GADGET has existed since 4.0.
Sure, but it was undocumented API.
Not quite. It was badly documented API. I think it was mentioned in the 4.8
docs in the Q_OBJECT section.
What's
it should be float f = 2.0f; then. I understand the compiler should check
if value is in range and precision of a float before emitting a warning.
This mostly get annoying inside template function that can handle both
float and double, but putting a float inside a double is ok.
On Thu, Jul 23,
C4244 is particulary true since Qt mostly use int for every size matter,
which on 64 bits system generate a lot of warnings when connecting to Qt. I
hope we see a size_t or equivalent some day. I admit the int to unsigned
int is also a problem to become, -1 lead to 2^32 - 1, we can only do that
if
Nice! good to known, thanks Thiago
On Thu, Jul 23, 2015 at 1:23 PM, Thiago Macieira thiago.macie...@intel.com
wrote:
On Thursday 23 July 2015 09:21:13 Jérôme Godbout wrote:
I admit the int to unsigned
int is also a problem to become, -1 lead to 2^32 - 1, we can only do that
if you known
On Thursday 23 July 2015 08:00:20 Sze Howe Koh wrote:
On 23 July 2015 at 01:03, Guido Seifert warg...@gmx.de wrote:
- the QObject's connections? Will all copies emit the same signals, will
all copies have their slots called?
Worked somehow... probably through magic.
This was my
On Thursday 23 July 2015 08:06:29 Bo Thorsen wrote:
I know, but Thiago said he hadn't seen it actually do any warnings. And
I agree with him that I haven't seen it warn about integer types.
More to the point: I *have* seen warnings about integer conversions to smaller
integers despite this
Op 23-7-2015 om 08:42 schreef Thiago Macieira:
Q_GADGET has existed since 4.0.
Sure, but it was undocumented API.
André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Den 20-07-2015 kl. 14:51 skrev Guido Seifert:
Hi, just seen this in project's code. Worse, I have been told to do it
exactly this way in another code part. I must say I am less than
thrilled. On first glance this code seems to work. There is not much
copying around. The objects sit happily in
The problem with this kind of bad hack that people judge it on whether
or not they could get away with it. It compiles? Ship it!
I think your problem is that your spidey sense is ringing so hard that
you lost the ability to give arguments about this :)
Oh, I had plenty of arguments,
On Wednesday 22 July 2015 18:42:55 Scott Aron Bloom wrote:
While I 100% agree, one thing I really cant stand, is when 3rd party
vendors, DISABLE WARNINGS in their code, and don't re-enable them when
their code exits (Im looking at you Qt).
I thought we stopped doing that.
Of course, when we
On Wednesday 22 July 2015 14:39:40 Matthew Woehlke wrote:
(On that subject, -Werror=cast-qual also might have helped here; that's
another one I use and would encourage. Also -Werror=return-type, which
*EVERYONE* should use, period.)
I've fixed most -Wcast-qual errors in Qt the last 6 months.
On Wednesday 22 July 2015 18:42:55 Scott Aron Bloom wrote:
While I 100% agree, one thing I really cant stand, is when 3rd party
vendors, DISABLE WARNINGS in their code, and don't re-enable them when
their code exits (Im looking at you Qt).
I thought we stopped doing that.
Of course, when we
. giving qobject
copy/assignment constructor and put it in qlist/qmap
On 2015-07-21 19:39, Thiago Macieira wrote:
On Tuesday 21 July 2015 21:18:35 Jason H wrote:
Once I was put in charge of a project where an engineer had
replaced
(inherited) all the Qt Q* classes used in the project to classes
Hi Scott.
While I 100% agree, one thing I really cant stand, is when 3rd party vendors,
DISABLE WARNINGS in their code, and don't re-enable them when their code
exits (Im looking at you Qt).
Im not a g++ guru, but in VC++ #pragma( push) and #pragma( pop ) should be a
requirement for
For my company, when I first joined, the Idea of compiled with -Werror (or
the equiv on VC++) was so far down the road, that I thought it would never be
possible. We had close to 5000 warnings between windows and linux.
Lucky man, i once worked in a project where we had 7 warnings
Am 21.07.2015 um 21:18 schrieb Jason H:
Once I was put in charge of a project where an engineer had
replaced(inherited) all the Qt Q* classes used in the project
to classes that did not have a 'Q' as a first letter. No
other changes. And yes, that engineer was a contractor.
Let me guess: The
On Wednesday 22 July 2015 23:00:38 Gunnar Roth wrote:
This is evil!
Pardon me?
Limitation of English.
In Portuguese, there are two words for this. In proper text, the 1st person
this (isto, este, esta) refers to something close to the speaker or
something which you haven't said yet,
On 2015-07-21 19:39, Thiago Macieira wrote:
On Tuesday 21 July 2015 21:18:35 Jason H wrote:
Once I was put in charge of a project where an engineer had replaced
(inherited) all the Qt Q* classes used in the project to classes that did
not have a 'Q' as a first letter. No other changes. And
From: Gunnar Roth [mailto:gunnar.r...@gmx.de]
Sent: Wednesday, July 22, 2015 11:51 AM
To: Scott Aron Bloom
Cc: interest@qt-project.org
Subject: Re: [Interest] Need argumentative help. giving qobject
copy/assignment constructor and put it in qlist/qmap
Hi Scott.
While I 100% agree, one
Den 23-07-2015 kl. 00:07 skrev Thiago Macieira:
Disabling C4244 /* conversion from 'type1' to 'type2', possible loss of data
*/ is more than going to far. It is kind of sabotage imho.
Note that this does not apply to 64-bit to 32-bit conversions. Those are still
active, so C4244 does not seem
Am 23.07.2015 um 07:51 schrieb Bo Thorsen b...@vikingsoft.eu:
Den 23-07-2015 kl. 00:07 skrev Thiago Macieira:
Disabling C4244 /* conversion from 'type1' to 'type2', possible loss of data
*/ is more than going to far. It is kind of sabotage imho.
Note that this does not apply to 64-bit to
On 2015-07-22 16:52, Thiago Macieira wrote:
please take a look at the list of MSVC warnings we turn off completely:
http://code.woboq.org/qt5/qtbase/src/corelib/global/qglobal.h.html#897
Of those, C4275, C4514, C4800, C4097, C4786 and C4710 are stupid. I can't see
anyone who wants to know
On Wednesday 22 July 2015 20:51:21 Gunnar Roth wrote:
You are completely right, albeit there is a macro you can define so qt does
not switch of the warnings, but then you get warnings, bad if you compile
with warnings as errors. Our solution ist to have a Qt_prolog.h and
Qt_epilog.h which we
On Wednesday 22 July 2015 17:14:43 Matthew Woehlke wrote:
At least all three of the above are probably better restored to the
user's state after Qt code.
Again: we did it for a while then people complained that their code
regressed. So we turned them back off.
--
Thiago Macieira -
On Wednesday 22 July 2015 19:20:57 Scott Aron Bloom wrote:
For my company, when I first joined, the Idea of compiled with -Werror (or
the equiv on VC++) was so far down the road, that I thought it would never
be possible. We had close to 5000 warnings between windows and linux.
We had been
On Wednesday 22 July 2015 23:11:59 Gunnar Roth wrote:
Hello Thiago.
Of those, C4275, C4514, C4800, C4097, C4786 and C4710 are stupid. I can't
see anyone who wants to know those warnings.
Most are sure, but sometimes you need this diagnostic and you wonder why you
cannot switch it on.
. giving qobject
copy/assignment constructor and put it in qlist/qmap
On Wednesday 22 July 2015 17:14:43 Matthew Woehlke wrote:
At least all three of the above are probably better restored to the
user's state after Qt code.
Again: we did it for a while then people complained that their code
Hello Thiago.
Am 22.07.2015 um 22:45 schrieb Thiago Macieira thiago.macie...@intel.com:
On Wednesday 22 July 2015 20:51:21 Gunnar Roth wrote:
You are completely right, albeit there is a macro you can define so qt does
not switch of the warnings, but then you get warnings, bad if you compile
Hello Thiago.
Of those, C4275, C4514, C4800, C4097, C4786 and C4710 are stupid. I can't see
anyone who wants to know those warnings.
Most are sure, but sometimes you need this diagnostic and you wonder why you
cannot switch it on.
I'll concede we may have gone too far on C4244 and
On Wednesday 22 July 2015 22:11:10 Scott Aron Bloom wrote:
IYO, Would it be possible to make the restoration a QT option?
Ie #define QT_RESTORE_PRAGMA_STATE
#define QT_CC_WARNINGS
That's already there. Qt will not disable any warning. You've been warned.
--
Thiago Macieira - thiago.macieira
On 23 July 2015 at 01:03, Guido Seifert warg...@gmx.de wrote:
- the QObject's connections? Will all copies emit the same signals, will
all copies have their slots called?
Worked somehow... probably through magic.
This was my problem. It really looked like we could get away with it. The
But remember: Contractors are nothing more than colleagues, with just
another work model.
Yeah, but they don't get confronted with the mess they make...
HEY, HEY I am contractor... And I discovered the mess and cleaned it up. Do
you have an idea how often contractors are hired
hi,
i wonder why you just don't store QObject* in the lists?
moving from objects to pointers should be just fleißarbeit ;)
I 'inherited' the code. And yes, this is exactly what I do now... though it is
not 'just' fleißarbeit. To reintroduce proper memory management
proved to be a
Well here people who write that kind of code become project lead or product
managers , so they can no longer harm the code ;-)
Am 21.07.2015 um 18:34 schrieb Guido Seifert warg...@gmx.de:
hi,
i wonder why you just don't store QObject* in the lists?
moving from objects to pointers
On Tuesday 21 July 2015 21:18:35 Jason H wrote:
Once I was put in charge of a project where an engineer had replaced
(inherited) all the Qt Q* classes used in the project to classes that did
not have a 'Q' as a first letter. No other changes. And yes, that
engineer was a contractor.
Did you
Roth gunnar.r...@gmx.de
To: Guido Seifert warg...@gmx.de
Cc: interest@qt-project.org
Subject: Re: [Interest] Need argumentative help. giving qobject
copy/assignment constructor and put it in qlist/qmap
Well here people who write that kind of code become project lead or product
managers
On Tuesday 21 July 2015 21:18:35 Jason H wrote:
Once I was put in charge of a project where an engineer had replaced
(inherited) all the Qt Q* classes used in the project to classes that did
not have a 'Q' as a first letter. No other changes. And yes, that
engineer was a contractor.
Is that
One should think this is a clear warning sign. :-)
But the code worked. So problem solved. Now I am wondering if I was
over-cautious, or if there are less obvious problems. With different compilers?
Platforms? Some less known QMap/QList features, which might shuffle the objects
around? Not
The Qt documentation did it. :-) Where I am there are no bad developers. The
'do not copy QObject' was just an unfortunate lack of information. Together
with 'oh no, we don't have the time for a non-trivial redesign like that' I had
some convincing to do.
The point you listed below are the
From: Guido Seifert
Hi, just seen this in project's code. Worse, I have been told to do it
exactly this way in another code part.
What about:
- the QObject's parent? Is it set with setParent(other-parent()) or set to
nullptr?
- the QObject's thread? Is it guaranteed that it is the same thread
Hi Guido,
you mean they have patched qt and gave Object an assignment operator and copy
constructor?
Really?
Regards,
Gunnar
Am 20.07.2015 um 14:51 schrieb Guido Seifert warg...@gmx.de:
Hi, just seen this in project's code. Worse, I have been told to do it
exactly this way in another
: [Interest] Need argumentative help. giving qobject
copy/assignment constructor and put it in qlist/qmap
Hi Guido,
i know quite a many bad c/c++ code that worked … for a while ;-) thats the
problem with many bad c/c++ code, that it works somehow.
Am 20.07.2015 um 18:53 schrieb Guido Seifert
Hi Guido,
i know quite a many bad c/c++ code that worked … for a while ;-) thats the
problem with many bad c/c++ code, that it works somehow.
Am 20.07.2015 um 18:53 schrieb Guido Seifert warg...@gmx.de:
One should think this is a clear warning sign. :-)
But the code worked. So problem
Subject: [Interest] Need argumentative help. giving qobject copy/assignment
constructor and put it in qlist/qmap
Hi, just seen this in project's code. Worse, I have been told to do it exactly
this way in another code part. I must say I am less than thrilled. On first
glance this code seems
Am 21.07.2015 um 03:33 schrieb Tony Rietwyk:
[...] We'll need to see some code to decide how bad it is.
I'd say: Whatever the code looks like now, it is bad enough not to use
it any longer. And code is not static, so it can get worse any time... :-)
The Qt docs state that copying a QObject
make a mess of the implicit data
sharing?
Sent: Monday, July 20, 2015 at 1:02 PM
From: Gunnar Roth gunnar.r...@gmx.de
To: Guido Seifert warg...@gmx.de
Cc: interest@qt-project.org
Subject: Re: [Interest] Need argumentative help. giving qobject
copy/assignment constructor and put
51 matches
Mail list logo
