Hi Tuukka, Ville,
On 2019-09-19 15:02, Ville Voutilainen wrote:
On Thu, 19 Sep 2019 at 14:49, Tuukka Turunen
wrote:
A lot of the Qt functionality works perfectly well on INTEGRITY. Even
the advanced graphics such as Qt Quick, Qt 3D and Qt 3D Studio. I do
not see it reasonable to claim that
On 2019-09-19 10:56, Lars Knoll wrote:
4. drop Integrity support (or update to a newer version) ASAP (for
Qt 5.15 if not 5.14).
This is a bit black and white. You’re proposing to drop all of
INTEGRITY because you’re not willing to work around things on that
platform for one patch that is in
From a comment by Ville on Gerrit, I take that:
On 2019-09-19 10:41, Mutz, Marc via Development wrote:
So, I update my requests:
1. List a maintainer for INTEGRITY in https://wiki.qt.io/Maintainers
That person seems to be Ville.
2. That maintainer should either find the missing linker flag
On 2019-09-18 17:33, Thiago Macieira wrote:
On Wednesday, 18 September 2019 08:16:46 PDT Giuseppe D'Angelo via
Development
wrote:
> We've never required C++11 Standard Library. We've only required the core
> language and the integrity compiler does support it just fine.
Not really, it also
, atomics,
future/promise, and the use of the thread_local keyword.
So, is the CI just using a totally outdated toolchain?
Thanks,
Marc
On 2019-09-18 12:29, Mutz, Marc via Development wrote:
Hi,
Can someone expand on the plan forward for the supported INTEGRITY
toolchains?
Lars is talking
Hi,
Can someone expand on the plan forward for the supported INTEGRITY
toolchains?
Lars is talking about using C++17 for Qt 6, yet the INTEGRITY version in
the CI for Qt 5.14 doesn't even support C++_11_. It's a constant pain
for anything constexpr-related, and now it turns out that while
On 2019-08-23 10:31, Mutz, Marc via Development wrote:
If that's the case, shouldn't we run, not walk, to replace our
internal uses with std::mutex + std::condition_variable to have only
one mutex?
Since it _is_ the case, I've sat down and ported QReadWriteLock from
QMutex + QWaitCondition
Hi,
Qt uses C++ feature test macros (__cpp_...) to detect post-C++11
features, and the status quo is that we only support compilers that
provide them.
This proposal does not intend to change this.
This proposal intends to change the de-facto status quo in how we check
these feature macros.
On 2019-09-06 19:26, Thiago Macieira wrote:
On Friday, 6 September 2019 09:04:09 PDT Giuseppe D'Angelo via
Development
wrote:
I was actually proposing option A, to avoid clashes. The Qt::
namespace
at the moment is simply too big to reasonably claim that there will be
no conflicts. A few
On 2019-09-06 14:34, Lars Knoll wrote:
On 6 Sep 2019, at 14:10, Giuseppe D'Angelo via Development
wrote:
Il 06/09/19 11:26, Mutz, Marc via Development ha scritto:
The change is SC, and makes namespaced and non-namespaced builds
behave
the same.
Small question: the claim here
Hi,
I would like to propose to make the existing Qt namespace inline and
move all of Qt's declarations into it.
== TL;DR: ==
Qt can already, optionally, be configured into a user-specified
namespace (QT_BEGIN_NAMESPACE/QT_END_NAMESPACE, -qtnamespace), and this
is one of the build
Hi,
Over the years, compilers (at least GCC) have started to interpret
Q_UNLIKELY not only as a way to encode information for the branch
predictor, but more and more to move code marked as such into a
completely different (.cold) ELF section, which is where the exception
tables and stack
On 2019-08-23 14:31, Allan Sandfeld Jensen wrote:
[...]
condition_variable_any::_M_mutex
I didn't say _any :)
The std::conditional_variable has the same problem QWaitCondition has.
I don't think so:
https://code.woboq.org/gcc/libstdc++-v3/include/std/condition_variable.html#166
takes
On 2019-05-29 12:53, Mutz, Marc via Development wrote:
=== QWaitCondition -> std::condition_variable(_any) ===
Plumbing that std::condition_variable can do better.
So, I've looked at QWaitCondition because I had a need to call wait()
with a QBasicMutex instead of a QMutex, and that does
On 2019-08-22 21:09, Danila Malyutin wrote:
Can't it be alleviated/improved by providing user-defined literal for
QString(Literal)? So that one would only write a["b"_qs] = "c"_qs.
Yes.
++ways_to_construct;
:)
Fun aside, in C++20, this may actually alleviate some of the problems of
On 2019-08-22 23:43, Ville Voutilainen wrote:
I have
always wanted to maximize
the amount of people who can read my source code, and that means
emojis are out. :)
I don't believe European languages as written by you and me are the
benchmark here. Asian locales (incl. Russian/Cyrillic) are. It
On 2019-08-22 15:42, Tor Arne Vestbø wrote:
On 22 Aug 2019, at 15:11, Mutz, Marc via Development
wrote:
We need to collectively understand that implementing a library is
different from the library's API and from use of the API. Anyone who
thinks otherwise is invited to have a look
On 2019-08-22 14:59, Kevin Kofler wrote:
Mutz, Marc via Development wrote:
For me, the problem is QUtf8XXX::size() - what should that return?!
IMHO, obviously the number of bytes. You can have additional O(N)
numCodePoints() and (if needed) utf16Size() (which takes needed
surrogate
pairs
On 2019-08-22 14:48, Martin Smith wrote:
Now that we use clang in Creator and QDoc, suppose we write a QString
source code analysis tool using clang. The tool would parse sources
looking for uses of QString and then analyzing the code patterns where
QString is used to find possible optimizations
On 2019-08-22 13:42, Lars Knoll wrote:
That's why we are not removing QLatin1String: the Latin1 algorithm is
as fast
as memcpy. The only thing better than that is zero copies.
We could also turn this around: Are we over-optimising here? Do we
have the right balance between ease of use and
On 2019-08-21 14:13, Sérgio Martins via Development wrote:
On 2019-08-20 16:56, Bogdan Vatra via Development wrote:
Hi,
Isn't silly to have so many wrappers around a such a simple thing as
strings? All the major frameworks out there (i.e. Java, C#) they have
a single
String which does all
Hi,
I need a thumbs up or down, finally, on
https://codereview.qt-project.org/c/qt/qtbase/+/262894 (3x +1 already)
https://codereview.qt-project.org/c/qt/qtbase/+/266737
Thanks,
Marc
___
Development mailing list
Development@qt-project.org
Hi,
In light of a recent attempt to re-introduce QStringLiteral, relacing
QLatin1String, I'd like to remind everyone that QStringLiteral has a lot
of drawbacks and should not be used unless it saves a memory allocation.
Drawbacks include:
- doubled storage requirements (2 bytes/char) over a
On 2019-08-17 07:13, Sze Howe Koh wrote:
[...]
Which should we implement? I personally prefer (2) as it it can be
added to Qt 5.x and provides backward compatibility while keeping the
nice compact function names. We could enable QT_NO_COW by default in
Qt 6.5 LTS and then remove the old function
Hi,
It seems that the presence of QWeakPointer::data() in the past has given
many Qt developers the wrong impression and they're now fighting hard to
keep that impression intact when porting away from deprecated data().
So here's some re-education. Ignore at your own peril :)
= Lesson 1:
On 2019-08-13 09:50, Friedemann Kleint wrote:
> VC++ 2019
Just for the record, this compiler still has a number of optimizer
bugs,
see https://bugreports.qt.io/browse/QTQAINFRA-2875 .
Also JFTR: Peppe found one of the bugs rumoured to be a MSVC bug was a
problem in _our_ code, the
On 2019-08-12 22:13, Thiago Macieira wrote:
On Monday, 12 August 2019 13:03:47 PDT Mutz, Marc via Development
wrote:
The milestone is std::byte, which which we could put QByteArray on a
sound basis. And char8_t, which would make QUtf8String(View) fly.
QByteArray, due to its dual string / byte
On 2019-08-12 21:33, Thiago Macieira wrote:
[...]
Is there any really cool or
important feature for us to require GCC 8, instead of 7? Like the
enforced
copy elision we'll need to deprecate QMutexLocker.
We don't need guaranteed copy elision, we need CTAD for that. If we have
CTAD, we can
On 2019-08-12 14:34, Allan Sandfeld Jensen wrote:
On Monday, 12 August 2019 14:21:25 CEST Ville Voutilainen wrote:
On Mon, 12 Aug 2019 at 15:10, Allan Sandfeld Jensen
wrote:
> explicit(bool): We use some ugly patterns in places to simulate this.
Can you point me to those? I do know what
On 2019-08-10 15:41, Kevin Kofler wrote:
Mutz, Marc via Development wrote:
But that's the whole point Olivier was making two years ago: ref() is
_documented_ to be a memory barrier:
https://doc.qt.io/qt-5/qatomicinteger.html#ref:
But QSharedDataPointer is NOT documented to call
+1
On 2019-08-09 13:42, Alex Blasche wrote:
[...]
she
[...]
his
At the risk of putting my foot in it...
The inconsistent use of pronouns leaves me confused now :)
Sona sound like a female name, indeed, but so does Alex...
___
Development mailing
On 2019-08-08 12:48, Lars Knoll wrote:
Even if we don’t change QAtomic, there seems to be also little need to
introduce whole new classes because QSD, QSDP and QESDP do *not*
specify that refcounting is ordered.
Once more, please don't mix these things up:
- QISP is a replacement for QSDP and
On 2019-08-08 12:33, Philippe wrote:
No. When you call detach(), you're in a mutating function of the
object
and you can assume that you're the only thread executing on a member
function of that thread, because if that's not the case, you're in UB
land. Only const methods are allowed to execute
On 2019-08-08 11:29, Philippe wrote:
Yet, what is the usefullness of qIntrusiveDetached()?
qIntrusiveDetached() makes it possible to use std::atomic ref counts
(which don't have ref() and deref()). It's separate from
qIntrusiveClone() because the latter is more often overloaded than the
On 2019-08-08 09:36, Lars Knoll wrote:
On 7 Aug 2019, at 20:00, Mutz, Marc via Development
[...]
Changing ref() from seq_cst to relaxed and documenting that should be
ok for Qt 6, as it’ll still to the right thing for its indented use
case. At least it is very much preferable over duplicating
On 2019-08-08 10:29, Philippe wrote:
Looks good, except that your proposed qIntrusiveDetached()
has (apparently) the same "uncertainty" that caused
shared_ptr::unique()
to be deprecated.
https://en.cppreference.com/w/cpp/memory/shared_ptr/unique
The problem with shared_ptr::unique() is
On 2019-08-07 23:09, Mutz, Marc via Development wrote:
[...]
It also adds
- constexpr default ctor and ctor from nullptr
- implicit ctor from nullptr (but explicit from T*)
- qintrusivesharedpointer.h doesn't transitively include the world
(I think I can even drop the and - if we
can
On 2019-08-07 22:01, Konstantin Tokarev wrote:
It would be even better if it was possible to choose type of reference
counting,
e.g. via template parameter. In many cases atomic counters are not
needed
and just reduce performance.
On 2019-08-07 21:46, Philippe wrote:
On Wed, 07 Aug 2019
Hi Philippe,
This was discussed in
https://codereview.qt-project.org/c/qt/qtbase/+/66118. See, in
particular, Olivier's comment.
TL;DR: ref() is documented to be ordered, so cannot be changed.
Consequently, I didn't merge it even with Thiago's +2.
To fix, we'd need to port all of the Qt
On 2019-07-26 03:29, Thiago Macieira wrote:
On Thursday, 25 July 2019 06:11:48 PDT Mutz, Marc via Development
wrote:
We've come to that point already with QT_NO_LINKED_LIST and
QT_NO_JAVA_STYLE_ITERATORS. We can now globally enable them. The last
uses in QtBase (tests) already undef them
On 2019-07-17 08:05, Mutz, Marc via Development wrote:
The qt5.git integration[1] hasn't happened for a month or so (ok two
weeks)
It still hasn't. QtBase devs need an integration a week, not one per
month, to work efficiently.
The current state is not acceptable. The integration of Jun
On 2019-07-17 11:01, Edward Welbourne wrote:
[3] https://codereview.qt-project.org/c/qt/qtlottie/+/267618
Please clarify: what's the problem here ?
It's merged ...
It's merged, and the next qt5 integration that reached qtlottie errored
out with the same error, so the error message is lying
Hi,
The qt5.git integration[1] hasn't happened for a month or so (ok two
weeks) and the qtbase 5.13 → dev merge[2] is sitting there for three
days waiting for someone with merge privs to do conflict resolution.
Does anyone feel responsible for
- qtlottie vs. buildsystem, fixing the
On 2019-07-16 18:11, Matthew Woehlke wrote:
[...]
The basic
algorithm (iterate through 'haystack' looking for 'needle') is common
regardless of the string types. The points that differ (e.g. only
starting the search at code points, computing lengths) use overloaded
helper functions which can be
On 2019-07-13 21:39, Volker Hilsheimer wrote:
On 13 Jul 2019, at 13:41, Thiago Macieira
wrote:
On Friday, 12 July 2019 17:37:59 -03 Matthew Woehlke wrote:
That said, I took a look at startsWith, and... surprise! It is
*already
a template*. So at least in that case, it isn't obvious why adding
On 2019-07-12 22:37, Matthew Woehlke wrote:
[...]
So, perhaps you should suggest a more specific example?
I did: replace and relational operators. And you're right to look at
startsWith(), because that is indeed binary (*this being the first
argument). And it's also one which is thoroughly
On 2019-07-12 17:27, Matthew Woehlke wrote:
On 11/07/2019 15.01, Thiago Macieira wrote:
[...]
Except that the whole point of those methods is that they can be more
efficient when the encoding is known and therefore templating won't
help.
So those cases can employ specializations. Or,
On 2019-07-11 10:13, André Pönitz wrote:
On Wed, Jul 10, 2019 at 10:01:04PM -0300, Thiago Macieira wrote:
On Wednesday, 10 July 2019 09:55:02 -03 André Pönitz wrote:
> As far as I understand there's a perceived need to have "full" utf8
> literals, and there's a need to have ASCII literals.
On 2019-07-10 14:55, André Pönitz wrote:
On Wed, Jul 10, 2019 at 11:29:15AM +0200, Mutz, Marc via Development
wrote:
On 2019-07-10 10:50, Arnaud Clere wrote:
> Hi all,
>
> So, do I understand correctly that:
> 1. QUtf8String may be required in Qt7 to solve problems due to C++2x
On 2019-07-10 10:50, Arnaud Clere wrote:
Hi all,
So, do I understand correctly that:
1. QUtf8String may be required in Qt7 to solve problems due to C++2x
char8_t
I wouldn't say required. I also don't think it needs to wait until Qt 7.
Qt 7 is where we may depend on C++20 and can use char8_t
Hi,
Before this gets any more traction: Aye! for QUtf8String, nay for the
implementation.
On 2019-07-08 09:46, Arnaud Clere wrote:
//! Explicitely utf8 encoded byte array
class QUtf8String : public QByteArray
{
public:
using QByteArray::QByteArray;
QUtf8String(const QByteArray& o) :
On 2019-07-08 09:24, Mutz, Marc via Development wrote:
- QLatin1StringView - what QLatin1String is now [requires porting, but
it's just s/QLatin1String/QLatin1StringView/g in client code]
→ https://codereview.qt-project.org/c/qt/qtbase/+/267375
On 2019-07-08 04:43, Thiago Macieira wrote:
On Sunday, 7 July 2019 23:26:40 -03 Konstantin Ritt wrote:
As we have string views now, I'd vote for deprecating the string
manipulation methods in QByteArray. I doubt we could make QByteArray a
true
vector of bytes now, without breaking lots of the
On 2019-07-06 17:31, Fabian Kosmale wrote:
Yes,
in hindsight this doesn't scale and it was also totally backwards. The
issue is that the char8_t overload introduces ambiguity in the
overload set, so instead of adding more overloads we should just
remove it unless it really matches. So just add
On 2019-07-06 16:38, Konstantin Tokarev wrote:
06.07.2019, 17:20, "Mutz, Marc via Development"
:
On 2019-07-06 14:50, Fabian Kosmale wrote:
[...]
See https://godbolt.org/z/e6OinY for how this would look for a
trivial function.
[...]
Now also handle test(NULL) and extend
On 2019-07-06 14:50, Fabian Kosmale wrote:
[...]
See https://godbolt.org/z/e6OinY for how this would look for a
trivial function.
[...]
Now also handle test(NULL) and extend to binary:
test2([0, NULL, nullptr, "", u8""], [0, NULL, nullptr, "", u8""])
This doesn't scale...
Thanks,
Marc
On 2019-07-06 14:58, Thiago Macieira wrote:
On Saturday, 6 July 2019 07:43:39 -03 Mutz, Marc via Development wrote:
So, if GCC is right, we have no way of adapting our API to not break
in
C++20. So we need to decide what to break:
a) using 0 for nullptr, or
b) using u8"Hello" at
Hi,
C++20 is coming along, and it brings a disruptive change, one that far
surpasses the C++17 noexcept break: u8"Hello" is now const char8_t[], no
longer const char[].
To estimate the amount of breakage this will cause, assuming that using
u8"" is good practice today, to indicate that a
On 2019-06-27 16:10, Frederik Gladhorn wrote:
[...]
On a related note, now that things are generally working with the new
Gerrit,
I was wondering if we want to consider plugins. There is one to add
reviewers
based on git blame
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
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
On 2019-06-12 08:23, Philippe wrote:
On Wed, 12 Jun 2019 07:54:29 +0200
Nicolas Arnaud-Cormos via Development
wrote:
Whenever Qt is adding a new feature there's a teachability issue that
needs to be handled. Any duplication with the C++ standard adds
cognitive load to students.
One could
On 2019-06-12 09:20, Ulf Hermann wrote:
I don't think that (non-)COW is a problem in the scenario under
discussion.
Having the thing COW makes the porting simpler at the cost of
suboptimal
performance. If we wrote a COW container as a drop-in replacement for
QMap or QHash with
On 2019-06-11 09:48, Lars Knoll wrote:
On 11 Jun 2019, at 09:35, Olivier Goffart wrote:
On 11.06.19 09:17, Lars Knoll wrote:
So, is removing it worth all the hassle to us and our users?
Q_FOREACH is a macro and it doesn’t really cost us anything to keep
it around. Yes, it has issues with non
On 2019-05-17 10:18, Giuseppe D'Angelo via Development wrote:
QHash ones are bidirectional
Nope.
(Go look yourself, it's too hilarious for spoilers)
___
Development mailing list
Development@qt-project.org
On 2019-06-06 15:49, Lars Knoll wrote:
On 6 Jun 2019, at 15:36, Mutz, Marc via Development
wrote:
On 2019-06-06 15:14, Konstantin Tokarev wrote:
[...]
There is a principle of single level of abstraction [1], and inline
implementation
of flat map can be viewed of violation of such principle
On 2019-06-06 15:14, Konstantin Tokarev wrote:
[...]
There is a principle of single level of abstraction [1], and inline
implementation
of flat map can be viewed of violation of such principle. If flat map
implementations
were kept speparately, it would indeed make code easier to read and
On 2019-06-06 14:04, Lars Knoll wrote:
On 6 Jun 2019, at 13:39, Mutz, Marc via Development
wrote:
[...]
You are equating Qt users and Qt implementers. You can maintain the Qt
API, but use more efficient data structures in the implementation. You
seem to be implying that these two things
On 2019-06-06 12:24, Ola Røer Thorsen wrote:
tor. 6. jun. 2019 kl. 10:21 skrev Vitaly Fanaskov
:
Qt is GUI framework. Not only, yes, but this is the main purpose.
+/-
10MB is almost nothing for GUI apps. Slightly faster
lookup/insertions,
cache line, proper alignment... Well, nice to have, but
On 2019-06-06 12:24, Lars Knoll wrote:
On 6 Jun 2019, at 11:08, Simon Hausmann
wrote:
Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
[...]
I have the feeling that some participants of these discussions
thought
they joined an adulation club for Qt API lovers instead.
I don't quite
On 2019-06-06 11:08, Simon Hausmann wrote:
Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
[...]
Do you guys _actually_ think that readability of Qt code trumps
_everything_?
For me the answer is "no". I believe that for the majority of Qt code
we
should strike for a
On 2019-06-06 10:17, Vitaly Fanaskov wrote:
As a library implementer, you are simply not _allowed_ the freedom to
use a convenient tool over the most efficient one. That is, to put it
mildly, a disservice to users and a disgrace to the profession of
programmers.
Well, optimization is probably
On 2019-06-06 09:47, Simon Hausmann wrote:
[...]
However I don't find your arguments that find_if/lower_bound is not
harder to read convincing. I continue to agree with Joerg and Tor Arne
and feel that the API of the associative containers results in code
that
is more compact, visually less
On 2019-06-06 08:24, Joerg Bornemann wrote:
On 6/5/19 5:49 PM, Mutz, Marc via Development wrote:
As a library implementer, you are simply not _allowed_ the freedom to
use a convenient tool over the most efficient one. That is, to put it
mildly, a disservice to users and a disgrace
On 2019-05-16 20:18, Mutz, Marc wrote:
[...]
[1] Paraphrasing what Alex Stepanov teaches in his A9 courses: No C
programmer would _ever_ get the idea to use a self-rebalancing
red-black tree for something that holds a dozen elements. Because once
you understand what is required to implement one,
On 2019-06-05 10:40, Edward Welbourne wrote:
[...]
If some things are deprecated and never removed (QRegEx springs to
mind), while others get removed (comparably) soon after deprecation
(e.g. everything we're currently deprecating with intent to remove in
Qt
6), maintainers of client code get
On 2019-06-03 14:27, Bernhard Lindner wrote:
> > > So, yes, this is borne out of frustration with the lack of maintenance
> > > of QtCore plumbing. I don't see that changing and I acknowledge and
> > > understand that the focus of development has shifted towards QML.
> > Suppose you implement
On 2019-06-03 11:26, Lars Knoll wrote:
[...]
== QSharedDataPointer / QExplicitlySharedDataPointer ==
[...]
I see no reason at all for removing those, quite to the contrary. They
are very helpful for building refcounted classes (explicitly or
implicitly shared).
I'd still like to deprecate
On 2019-05-30 20:35, Thiago Macieira wrote:
On Wednesday, 29 May 2019 08:13:51 PDT Olivier Goffart wrote:
[...]
> === QWaitCondition -> std::condition_variable(_any) ===
Yes.
Can't change QWaitCondition without changing QMutex. It's all or
nothing.
I believe std::condition_variable_any
On 2019-05-30 20:27, Thiago Macieira wrote:
On Wednesday, 29 May 2019 08:17:15 PDT Mutz, Marc via Development
wrote:
But of course, that's a fallacy, because as soon as Qt internally uses
said inline functions, every use of them by the user with a different
STL is an ODR violation and therefore
Hi,
This is not meant to be a summary of the thread so far, but the
definition of a possible solution space:
= The meaning of deprecation
I think of deprecation as a means to tell users that the designers of
the deprecated API think that there is some deep flaw in the API that
makes it
On 2019-05-30 10:23, Alberto Mardegan wrote:
It's not clear to me why splice() cannot be implemented: it would just
mean that the list data would detach as in all other non-const methods.
Or am I missing something?
You're passing two iterators. In order to implement slice(), you'd need
to
On 2019-05-29 16:06, Vitaly Fanaskov wrote:
=== QAtomic -> std::atomic ===
It already is just a thin wrapper around std::atomic, so there's not
much point keeping it.
There is the interesting question in light of this: are we really going
to widely use std::* in public interfaces of Qt? If
On 2019-05-29 13:52, Konstantin Tokarev wrote:
29.05.2019, 13:56, "Mutz, Marc via Development"
:
Hi,
Here's a list of stuff I consider has served it's purpose and is no
longer needed, with respective replacements:
= Priority 1 =
== QSharedDataPointer / QExplicitlySharedD
Ah, I thought you'd might win this one :)
On 2019-05-29 13:48, Philippe wrote:
[snip usual rambling]
=== QAtomic -> std::atomic ===
There would be subbtle traps for code conversion:
eg. std::atomic::load() uses std::memory_order_seq_cst
while QAtomic::load() uses relaxed ordering
That is
Hi,
Here's a list of stuff I consider has served it's purpose and is no
longer needed, with respective replacements:
= Priority 1 =
== QSharedDataPointer / QExplicitlySharedDataPointer ==
These are basically Qt-internals, and should never have been public in
the first place. It's _because_
On 2019-05-25 17:24, Konstantin Ritt wrote:
сб, 25 мая 2019 г., 12:30 Mutz, Marc via Development
Repeat after me: default ctors do _not_ establish a valid value.
Perhaps you mean "trivial type's default ctors do _not_ establish a
valid value"?
No, I actually meant default ctor. W
Further to the question about default ctors for such "obvious" stuff as
On 2019-05-21 10:27, Mutz, Marc via Development wrote:
class QRect {
int x, y, w, h;
public:
QRect() = default;
};
QRect r; // partially-formed
r.x(); // compilers _already_
On 2019-05-24 11:03, Lars Knoll wrote:
[...]
You conveniently didn’t quote the first part of my answer. I didn’t
say that. I said I really want to ensure that we get a zero copy
conversion between QList and QVector where this doesn’t imply
(possible) incorrectness in the code. That’s the case
On 2019-05-24 09:35, Lars Knoll wrote:
On 23 May 2019, at 13:26, Mutz, Marc via Development
wrote:
[...]
You said that QList should vanish from Qt API. So we don't care. We'll
have that switch to make QList _be_ QVector for ese of porting, but as
a template alias. There's your zero-copy
On 2019-05-23 10:40, Lars Knoll wrote:
[...]
4. Use QVector to implement QList, if sizeof(Foo) <=
sizeof(quint64) and Foo is movable. I’m intentionally not using
sizeof(void *) here, as types with sizes between 4 and 8 bytes would
not have stable references in cross platform code, so I do not
On 2019-05-22 22:38, Konstantin Shegunov wrote:
What about a rather smart (in terms of storage) circular buffer; a
vector. Then the push, pop, enqueue and dequeue would be amortized
O(1)?
You mean like QCircularBuffer?
___
Development mailing list
Hi Lars,
On 2019-05-22 15:49, Lars Knoll wrote:
Let’s conclude the topic of QList. I do see the concern about silent
source breakages. Here’s what we’ll (I’ll) do then for Qt 6:
1. Rename QList to QArrayList and make QList an alias to QArrayList
Agreed.
2. Move QStringList and
On 2019-05-22 18:25, Иван Комиссаров wrote:
What about fast prepend in [QList]
Please look at the source and do experiments. Years ago, I think I found
that it's just not true. There's a prepend optimisation, yes, but it
only kicks in if you _only_ do prepends. If you mix in but a single
On 2019-05-21 13:03, Konstantin Ritt wrote:
вт, 21 мая 2019 г., 11:32 Mutz, Marc via Development
:
And while the partially-formed
state can be extended to non-pimpled classes easily:
class QRect {
int x, y, w, h;
public:
QRect() = default;
};
QRect r; // partially-formed
r.x(); // compilers
On 2019-05-21 12:52, Julien Cugnière wrote:
Le mar. 21 mai 2019 à 10:32, Mutz, Marc via Development
a écrit :
It is, however, be an acceptable stop-gap measure, and here a
compromise
may emerge, for keeping old code working while preparing for a
fully-implemented partially-formed state
Hi Lars,
There is a fine line between a proper partially-formed state and
basically folding std::optional into every value class.
The former is a compile-time state. It is not observable at runtime,
because any code which would observe a difference invokes UB. This is
the same principle as
On 2019-05-20 22:58, Konstantin Shegunov wrote:
[...]
I agree as well, although I have a minor nitpick. Q_ASSERT works only
if it was not stripped while building Qt. Meaning that I'm often
working, as I'm sure other users, on Linux especially, with the
default (i.e. release) version of Qt from
On 2019-05-20 23:43, André Pönitz wrote:
On Mon, May 20, 2019 at 11:23:13PM +0200, Mutz, Marc via Development
wrote:
On 2019-05-20 23:21, André Pönitz wrote:
> > > Exhibit A:
> > >
> > > foo().contains(x)
> > >
> > >
> > > Exhibit B:
On 2019-05-20 23:14, Konstantin Shegunov wrote:
On Mon, May 20, 2019 at 11:32 PM Mutz, Marc via Development
wrote:
All I'm saying is that there are tons of examples (QGradient) where
the
use of an owning container in the API is just a very bad idea and
limits
the implementor's freedom
1 - 100 of 114 matches
Mail list logo
