On 2019-06-18 22:56, Alberto Mardegan wrote:
[...]
if (d)
It's not if (d) which I expect to be used for detaching, but just the
bool operator itself, if only as a short-cut to d.detach().
[...]
Sure, it is possible that some new issues will be found after the Qt6
release, but given the size
On Tuesday, 18 June 2019 13:56:36 PDT Alberto Mardegan wrote:
> Well... Expecting the data to detach on an `if (d)` check seems worth
> incurring into a breakage
> But I certainly cannot exclude that there is some code out there which
> happens to work exactly because of this implicit detach, so i
On 18/06/2019 23:27, Matthew Woehlke wrote:
So... to be clear, your plan is to deprive Qt users of a (mostly)
perfectly good wheel, that *is* being used by said users, and instead
tell all of those users that they need to go (individually) reinvent the
wheel?
Why depriving? They can stay around
On 18/06/2019 22:56, Alberto Mardegan wrote:
On 18/06/19 10:43, Mutz, Marc via Development wrote:
On 2019-06-18 08:18, Alberto Mardegan wrote:
Adding a const bool operator to QSharedDataPointer would solve the
problem, wouldn't it?
And (silently) break code that relies on the current behavio
On 18/06/2019 03.43, Mutz, Marc via Development wrote:
> BTW: this is the proposed replacement of QSDP/QESDP for Qt-internal use:
> https://codereview.qt-project.org/c/qt/qtbase/+/115213 and no, it will
> most certainly _not_ be public API again. It's the fact that these
> implementation details of
On 18/06/19 10:43, Mutz, Marc via Development wrote:
> On 2019-06-18 08:18, Alberto Mardegan wrote:
>>
>> Adding a const bool operator to QSharedDataPointer would solve the
>> problem, wouldn't it?
>
> And (silently) break code that relies on the current behaviour, yes.
Well... Expecting the data
On Tuesday, 18 June 2019 09:01:31 PDT Thiago Macieira wrote:
> They're the only ones we couldn't fall back to Linux's AF_ALG or OpenSSL's
> support, which often contain more optimised code that ours.
If we remove Keccak, then we could remove all the hash implementations from
QtCore, on Linux, and
On Tuesday, 18 June 2019 11:01:07 PDT Giuseppe D'Angelo via Development wrote:
> On 18/06/2019 18:01, Thiago Macieira wrote:
> > We have them because we made a mistake when we added SHA3 support. We've
> > kept them for compatibility, for people who had hashes to compare to and
> > had accidentally
On 18/06/2019 18:01, Thiago Macieira wrote:
We have them because we made a mistake when we added SHA3 support. We've kept
them for compatibility, for people who had hashes to compare to and had
accidentally used Keccak.
They're the only ones we couldn't fall back to Linux's AF_ALG or OpenSSL's
s
On 18 Jun 2019, at 11:30, Richard Moore mailto:r...@kde.org>>
wrote:
On Tue, 18 Jun 2019 at 17:02, Thiago Macieira
mailto:thiago.macie...@intel.com>> wrote:
We have them because we made a mistake when we added SHA3 support. We've kept
them for compatibility, for people who had hashes to compa
On Tue, 18 Jun 2019 at 17:02, Thiago Macieira
wrote:
> We have them because we made a mistake when we added SHA3 support. We've
> kept
> them for compatibility, for people who had hashes to compare to and had
> accidentally used Keccak.
>
>
Yes, we should deprecate this.
Rich
___
We have them because we made a mistake when we added SHA3 support. We've kept
them for compatibility, for people who had hashes to compare to and had
accidentally used Keccak.
They're the only ones we couldn't fall back to Linux's AF_ALG or OpenSSL's
support, which often contain more optimised
On Monday, 17 June 2019 23:55:44 PDT Joerg Bornemann wrote:
> Sure, I guess even for Qt 5 a configure option -no-debug-runtime or such
> would make sense.
We've lived with this for 20 years, we can wait a few more.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel
> Matthew Woehlke
> The difference between QBS and CMake is like the difference between a
> bright-eyed recruit just out of school and a grizzled veteran.
Ok, then, please, provide a simple toolchain file to use e.g. a
bare-metal KEIL C51 [1] compiler. And then, we will to see, how it
does in QBS
Christian Gagneraud wrote:
> Basically your argumentation is: I'm right, they are all wrong. Only
> CMake can save us all.
No, that is not my argumentation at all. Congratulations, you managed to
come up with an ad-hominem strawman!
My actual argumentation is based on logic and consistency.
On 6/17/19 5:09 PM, Thiago Macieira wrote:
That's assistant. But do we need a standalone qch viewer application?
Yes please. There is at least one user who loves Qt and dislikes
QtCreator. While it is possible to view Qt Help in a browser, it is more
comfortable to use Assistant with its spe
On Tue, 18 Jun 2019 at 20:24, Kevin Kofler wrote:
>
> Christian Gagneraud wrote:
> > Please elaborate:https://gcc.gnu.org/install/configure.html
> >
> > Just from the top of the document:
> > --with-pkgversion
> > --with-bugurl
> > ...
> > --enable-shared
> > --enable-multiarch
> > ...
> >
> > You
Christian Gagneraud wrote:
> Please elaborate:https://gcc.gnu.org/install/configure.html
>
> Just from the top of the document:
> --with-pkgversion
> --with-bugurl
> ...
> --enable-shared
> --enable-multiarch
> ...
>
> Your argumentation is ill-formed.
Of course there are examples where it is cl
On 2019-06-18 08:18, Alberto Mardegan wrote:
On 05/06/19 01:39, Kevin Kofler wrote:
Mutz, Marc via Development wrote:
and produces surprises such as
https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=96dc9a19ae11ca140d681f0e2605b5f4b953e581
My existing QSharedDataPointer c
19 matches
Mail list logo
