I'm running in to an issue with a QT-based Mac app, where the Qt frameworks
and plugins are bundled, hoping for some guidance... It looks like I'm
seeing something like this:
1. On the target mac system, with QT installed at e.g.
/usr/local/Cellar/qt/5.10.0 (same version as the one bundled in the
On Friday, 9 February 2018 10:09:03 PST Eric Lemanisser wrote:
> That is not my experience: https://godbolt.org/g/ZZG1mp
That's not a valid test because you forgot the -m32 switch. Disabling SSE2 on
64-bit is nonsensical.
Try this one instead: https://godbolt.org/g/C853Gx
As I said in the other
On Friday, 9 February 2018 08:36:59 PST Thiago Macieira wrote:
> > Qt is built with SSE2 by default since 5.3.0. Is there a reason for not
> > enabling by default SSE2 for application compilation ? If not I'll start
> > working on a change doing that.
>
> Because we didn't want to force that on us
That is not my experience: https://godbolt.org/g/ZZG1mp
Le ven. 9 févr. 2018 à 18:58, Marian Beermann a écrit :
> SSE et al are mostly helpful if you have code either using these
> instructions directly (assembly, intrinsics) or being written in a way
> that the optimizer can easily take advanta
SSE et al are mostly helpful if you have code either using these
instructions directly (assembly, intrinsics) or being written in a way
that the optimizer can easily take advantage of (see what Thiago wrote).
For general application code they generally do very little if anything
by themselves.
-M
QPointer might help you to control QObject's lifetime
On Fri, Feb 9, 2018 at 6:38 PM, Alexander Ivash wrote:
> Hi,
>
> There is a code like the following:
>
> QVariant objectNameVariant = item->property( "objectName" );
> QString objectNameString = objectNameVariant.toString();
> qDebug () << "o
Hi,
There is a code like the following:
QVariant objectNameVariant = item->property( "objectName"
);
QString objectNameString =
objectNameVariant.toString();
qDebug () << "objectNameString: "
On Friday, 9 February 2018 08:15:19 PST Eric Lemanisser wrote:
> Qt is built with SSE2 by default since 5.3.0. Is there a reason for not
> enabling by default SSE2 for application compilation ? If not I'll start
> working on a change doing that.
Because we didn't want to force that on users. It's
Qt is built with SSE2 by default since 5.3.0. Is there a reason for not
enabling by default SSE2 for application compilation ? If not I'll start
working on a change doing that.
Also, any plan migrating to SSE3 or SSSE3 ?
Eric Lemanissier
___
Interest mai
Think about C++ classes and files. If you have 3 classes like A, B and C, it is
common practice
to have them defined in 3 header files in particular if they are complex
classes, even if both B and C inherits from A.
And hardly anyone would try to put the 3 of them in a single header file, even
On Thursday, 8 February 2018 13:22:12 CET william.croc...@analog.com wrote:
> If I create a separate .pro file for lib and main,
> I would then have to create yet a third file
> to hold the common lines for inclusion in those first
> two. That is not moving in the right direction.
>
> The bad appr
11 matches
Mail list logo
