Il 10/09/20 08:48, Andrei Golubev ha scritto:
That's the dilemma that Andrei was talking about. Either solution is
valid and
both have a way for you to tell QList to do what you want.
Oh, but it's not a question of "if". It is already done in latest dev
this way, the shrinking
Il 10/09/20 04:31, Thiago Macieira ha scritto:
This is another against automatic shrinking; it may invalidate
everything rather than just the erased area. I don't understand the
"detach" part, is it about holding references across a detach, so they
refer to the original container, not the
On 09/09/2020 10:55, Andrei Golubev wrote:
Small update on QList::erase: the iterator invalidation model will be
aligned with std::vector's erase (in progress of merging the change to
dev and it got approved already). This means that, when erasing, only
the iterators that correspond to erased
On 03/09/2020 08:54, Lars Knoll wrote:
I think we have long in most of the important places today. I agree that adding long
to the overload set is somewhat annoying, but it could be an inline method mapping to
QIntegerForSize::type.
Has anybody ever looked how many places we would actually
On 03/09/2020 06:08, Thiago Macieira wrote:
Because qsizetype is the same type as qint64, which is the same type as
qlonglong (which exists for historical reasons, because older VC++ didn't
support "long long").
I'm very sorry, I'm lost now -- are you using as a postulate "on 64 bit
systems"?
On 02/09/2020 16:49, Thiago Macieira wrote:
Lars has asked for qsizetype to be defined as the same type (not just the same
size) as ptrdiff_t. Effectively, this means defining qint64 as the same type
as int64_t. Sounds easy, right?
Please remember that qlonglong is the same type in Qt as
On 02/09/2020 21:18, Andrei Golubev wrote:
Also not sure whether it is an implementation detail or the behavior
that should always be anticipated.
People build performance sensitive code assuming the cost of certain
operations -- like, assuming that erasing elements from a vector never
Il 02/09/20 16:34, NIkolai Marchenko ha scritto:
Since we're apparently heading to QVector being an alias to QList as
opposed to what was a previous proposed solution. Can someone please
elaborate on what breakages we can expect to happen in the old code with
this paradigm shift? It seems like
Il 02/09/20 17:38, Andrei Golubev ha scritto:
But yes, good job bringing this up. In Qt 6 code base we also do the
shrinking in erase. So this already is not aligned with std::vector.
Even if the capacity has been reserved by the user?
Thanks,
--
Giuseppe D'Angelo |
Il 02/09/20 10:04, Ville Voutilainen ha scritto:
Interesting. I'm curious what sort of repacking happens on erase, and why
it wasn't done in such a way that e.g. QVector is 4 pointers instead
of 3, so that
the element storage wouldn't necessarily be at the beginning of the
allocated block;
in
Il 02/09/20 15:32, Dmitriy Purgin ha scritto:
As far as I remember, until recently, for years we were told in this
mailing list to move away from QList and use QVector as default, because
QList will be deprecated/removed in Qt 6 anyway.
Search in this ML's archives. The short story:
* QList
Il 01/09/20 19:31, Thiago Macieira ha scritto:
There's no violation. Your code was incorrect in the past, it just happened to
work.
This isn't true...
Assume any and all non-const function will invalidate iterators.
... because this is sketchy. It has never been 100% documented, but
Il 01/09/20 19:33, Thiago Macieira ha scritto:
All non-const functions that may detach should be coded so they DO detach.
That is, after any and all non-const functions, the refcount of the container
should be 1.
This is the contract, and it's OK. I don't think however that this is
what was
Hi,
Thanks for the heads up!
Il 31/08/20 13:50, Andrei Golubev ha scritto:
The invalidation existed before for cases when a container could detach
(due to copy-on-write) or reallocate (due to growing or squeezing).
This sounds incorrect? Which invalidation did happen due to COW?
Now
this
Il 01/09/20 16:23, Thiago Macieira ha scritto:
So even if you use %td or %zd, GCC will complain in one of three different
platform configurations (namely, 64-bit Unix).
Pedantically, do we need the PRIxQSS (?) macro and friends to use
qsizetype into qWarning etc.?
Thanks,
--
Giuseppe
On 01/09/2020 11:20, Maurice Kalinowski wrote:
* QIM::multidata
https://codereview.qt-project.org/c/qt/qtbase/+/302905
Currently +2, waiting for integration
* QKeyCombination + removal of operator+(QFlags, *)
https://codereview.qt-project.org/c/qt/qtbase/+/297566
Currently +1,
Quick question (before Hyrum's law kicks in): qsizetype is currently
defined as ptrdiff_t, but is it documented to be so?
For instance, is one supposed to print it in printf using %td?
Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a
Il 26/08/20 08:46, Lars Knoll ha scritto:
I would hope that there are no other exceptions required. If something is not
done, but can easily be pushed to 6.1, you know what to do. If anybody knows
about something else that can’t be pushed please talk to me, so we can figure
out what to do
Hi,
Il 27/08/20 16:47, Thiago Macieira ha scritto:
So, can someone take a look at what it would take to make the models use 64-
bit and come up with a proper guide for how to maintain code that compiles and
works on both Qt5 and Qt6? The latter is very important: if you can't easily
maintain
Hi,
Il 27/08/20 02:46, Thiago Macieira ha scritto:
A QListView of 2 billion lines with where each line is a QString one to 7
characters in length would be 2G * (24 + 32) = 96 GB of memory use.
QListWidget's overhead is much worse.
This isn't accurate; QListView (with the default delegate)
Il 25/08/20 21:05, André Pönitz ha scritto:
why I wanted a configure time switch to choose the size of qsizetype).
This doesn't really help if Qt comes with your distribution or even with
the Qt installers.
What I meant is that it would be a porting aid towards Qt 6, rather than
a switch to
Il 25/08/20 07:49, Thiago Macieira ha scritto:
But how about models? This is an honest question. Does it make sense for
tables and lists that big? Note that an item*view* has a purpose of being
viewed, so how does one display such a huge list, tree or table?
Just another thought -- models
On 24/08/2020 17:02, Marcel Krems wrote:
I have two reviews which have been cherry-picked to 5.15 with a
merge-conflict.
I have resolved the conflicts and pushed new changesets, but the status
is still "Work in Progress".
How do I change the status back to "Active" or if I am not allowed to
On 24/08/2020 11:17, Mathias Hasselmann wrote:
Do you have examples showing verifiable evidence, or do you share a feeling?
There has been quite a flurry of patches into Qt fixing the generated
warnings (shortening 64-to-32, using "%d" in printf, and the like). I
don't have a way to list
On 23/08/2020 16:06, Marcel Krems wrote:
If they keep using int there could be a lot of warnings like this one:
warning: implicit conversion loses integer precision: 'qsizetype' (aka
'long long') to 'int' [-Wshorten-64-to-32]
I'm afraid that these warnings will be all over the place anyhow.
Il 20/07/20 07:21, Thiago Macieira ha scritto:
ASM is not a solution. There's at least one major compiler (MSVC) that doesn't
allow any assembler.
What do you mean, MSVC doesn't allow inline ASM?
I'm not proposing that the ASM itself needs to be emitted by moc, moc
could just call a function
Il 19/07/20 20:42, Thiago Macieira ha scritto:
In that sense, Peppe's suggestion of C++17 offsetof is better.
To clarify, I was proposing to do something like this:
Type Klass::_qt_property_api_propertyName::value() const
{
/*1*/ const size_t propertyMemberOffset =
Il 19/07/20 12:51, Oswald Buddenhagen ha scritto:
- the compiler becomes intentionally belligerent, in which case an
override switch will be provided as well (if not instantly, then after
the outcry that immediately follows)
File under "surely no compiler will optimize away X!", for X
Il 19/07/20 12:51, Oswald Buddenhagen ha scritto:
- the compiler somehow starts to actually make use of the freedom
granted by the fact that QObject is not standard-layout (this, btw, is
also the reason why peppe's suggestion to use offsetof doesn't fix
UB).
offsetof is
Il 18/07/20 12:08, Arno Rehn ha scritto:
Can't we just hide the QProperty behind a method call, like with an
ordinary getter method? E.g.
class Foo
{
// ...
QPropert () {
Q_D(Foo);
return d->bar;
}
};
struct FooPrivate {
QProperty bar;
};
Sure, property
Il 17/07/20 19:55, Thiago Macieira ha scritto:
moc generates:
Type Klass::_qt_property_api_propertyName::value() const
{
const size_t propertyMemberOffset =
reinterpret_cast(&(static_cast(nullptr)->propertyName));
const auto *thisPtr = reinterpret_cast(
Il 17/07/20 19:36, Thiago Macieira ha scritto:
So in your example QSctpSocket would still be 24 bytes, because the
inheritance is not deep enough to make sizeof 32?
Yes, with the IA-64 ABI, assuming we don't mandate [[no_unique_address]] of
course.
Still, is it worth breaking ABI for sparing
Il 17/07/20 17:30, Thiago Macieira ha scritto:
I will give a +2 for this patch, since I prefer it. That means adding
properties doesn't imply an extra 8 bytes per class in the hierarchy. Imagine
a user class hierarcy like QSctpSocket -> QTcpSocket -> QAbstractSocket ->
QIODevice -> QObject. If
Il 17/07/20 11:36, Lars Knoll ha scritto:
And it’s cleaner, because using the union trick, we do access several members
of the union at the same time. It works on all compilers but I’m not 100%
convinced it’s fully defined behavior according to C++, even if the members
don’t have data.
To
Il 17/07/20 14:09, Ulf Hermann ha scritto:
QAction *action = ~~~;
auto prop = action->text;
This already gives you the string. You cannot retrieve the property
itself. You can alternatively do action->text() or action->text.value().
They all do the same thing.
Uhm... sorry, no, this doesn't
Il 16/07/20 17:40, Volker Hilsheimer ha scritto:
The struct has no data itself, so ideally would be of size zero.
I'm missing some piece of the puzzle: if you take action->text, and text
is a zero-size struct, how does the operator() applied to it figure out
which action needs to read the
Il 17/07/20 11:05, Lars Knoll ha scritto:
No, we should just static_assert for [[no_unique_address]] being available on
the platforms where we expect it. That is, anywhere but on certain MSVCs.
Some older embedded toolchains don’t have the flag neither.
If we make it a configure feature, we
Il 16/07/20 12:43, Volker Hilsheimer ha scritto:
For pre-C++20 (where it’s possible to have zero-size structs), and for
compilers that don’t respect the [[no_unqiue_address]] attribute, all these
struct-instances are put into a union. In that case, a class using QProperty
will be larger (by
Il 16/07/20 12:43, Volker Hilsheimer ha scritto:
For pre-C++20 (where it’s possible to have zero-size structs), and for
compilers that don’t respect the [[no_unqiue_address]] attribute, all these
struct-instances are put into a union. In that case, a class using QProperty
will be larger (by
Il 21/06/20 13:22, Lars Knoll ha scritto:
We are making use of dynamic_cast and typeid in Qt nowadays, so I guess it’s
high time we adjust the wiki.
In the light of this: has anyone thought of deprecating in Qt 6 the
ad-hoc casting functions like qgraphicsitem_cast, qstyleoption_cast and
so
Il 20/06/20 22:45, Thiago Macieira ha scritto:
On Saturday, 20 June 2020 11:31:25 PDT Alberto Mardegan wrote:
I think I missed an announcement about Qt applications having to use
RTTI; on the opposite, I thought that the whole point of QMetaObject was
not to require RTTI support; has this
Il 20/06/20 21:31, Alberto Mardegan ha scritto:
Sorry, my wording was imprecise: we want to know if q is a*proper*
subclass of QProcess (that is, a derived class).
Note that inherits() / className() will not work as intended if the
subclass does not use Q_OBJECT. Only typeid() will tell you
Il 11/06/20 11:11, Edward Welbourne ha scritto:
That then leaves the question of whether we deprecate in Qt 6 or remove
these macros. I shall leave Marc, who I understand as wanting the
latter option, to make the case for it, lest I misrepresent that case.
I fear the macros are going to be
On 5/28/20 8:21 PM, Matthew Woehlke wrote:
if a .cpp file has a #include "myclass.moc" type statement, that .cpp
file has to be processed by moc
Huh?*Why*?
A direct use case of this is to support having Q_OBJECT classes defined
in a .cpp file. That requires moc to parse foo.cpp file and
Il 28/05/20 16:18, Matthew Woehlke ha scritto:
While that may be true, changing it now is going to break*every* user
that uses these methods to generate compound transformations... and
it'll be a silent break. I would be*very* surprised if that doesn't
generate more bug reports.
I 100%
On 5/27/20 3:58 PM, Matthew Woehlke wrote:
*Nothing* there clearly states, at least to my reading, whether the
"new" transform happens*before* or*after* any existing transforms that
the QTransform is already doing.
IMO, changing this to clarify that would help significantly.
Sure,
Il 25/05/20 17:40, Thiago Macieira ha scritto:
On Monday, 25 May 2020 04:37:26 PDT Edward Welbourne wrote:
The "comparisons" heading might stretch as far as using a UTF-8 key to
do a look-up in a QString-keyed hash,
Using UTF-8 data to look up in a QString-keyed hash will require conversion to
On 5/25/20 8:51 AM, Tony Sarajärvi wrote:
Or are you having new features coming in 5.15.1+ that would require additional
coding to make it MSVC 2015 compatible?
I strongly hope that there are *no* new features in patch releases. The
question is mostly whether you want to support MSVC 2015
Il 23/05/20 03:06, Thiago Macieira ha scritto:
As we're reviewing the changes Lars is making to get rid of QStringRef, Lars,
Marc and I came to the conclusion that QUtf8StringView is required for Qt 6.0.
That's because some methods that previously returned QStringRef now return
QStringView and
On 5/22/20 7:43 PM, Jason H wrote:
I guess to some degree it depends on how you define "essential".
The definition is:
"Qt Essentials define the foundation of Qt on all platforms. They are
available on all supported development platforms and on the tested
target platforms."
This
Hi,
Il 21/05/20 11:38, Val Doroshchuk ha scritto:
The license is not changed, plans just to not ship QtMultimedia with Qt
essentials,
can be installed separately. Possibly we also support only a limited set
of platforms.
Qt Essentials must work on every platform, according to the definition
On 5/16/20 6:16 PM, Thiago Macieira wrote:
That opens a philosophical question. In:
QString s = u"a a\u0301"; // U+0301 COMBINING ACUTE ACCENT
s.replace('a', 'b');
Should we now have a b with accent? (b́)
It's not philosophical at all, it's a defining question: at which level
does
Il 16/05/20 17:52, Arnaud Clère ha scritto:
Regarding the relevance of a QUtf8String, I feel like it would not be so
useful unless it allows to view its content as QChar instead of char (or
char8_t) since handling multibyte characters is so error prone. At least
a QChar handles most unicode
Il 13/05/20 16:44, Matthew Woehlke ha scritto:
Note that adding the QString(char16_t*) constructor
Pedantic, but surely you meant `char16_t const*`.
Hey, you can't nitpick here ...
This can be solved with a third overload:
template
void foo(char16_t ()[N]) { foo(QStringView{s, N});
On 5/12/20 6:12 PM, Иван Комиссаров wrote:
So the question is - is it possible to allow to construct QString from unicode
literal?
"Not yet", but adding a constructor from char16_t to QString makes sense.
This creates a problem down the line: today you have a
f(QString)
and you call it
On 5/12/20 12:20 PM, Иван Комиссаров wrote:
* Exceptions can be done where significant performance gains can be
demonstrated and the API will by design not require a copy of the data (e.g.
XML writer, stream writers, date time handling)
Let me disagree here. The decision should be taken on
Hi,
Il 07/05/20 23:11, Flaviu Tamas ha scritto:
$ git push gerrit HEAD:refs/for/5.15.0
ssh: connect to host codereview.qt-project.org port 22: Connection timed out
fatal: Could not read from remote repository.
The right port is 29418.
See also https://wiki.qt.io/Setting_up_Gerrit#Local_Setup
Il 28/04/20 21:45, Matthew Woehlke ha scritto:
* QList gets adapted so that its internal array allocates 3 *
sizeof(void*) per element, so that e.g. Q6StringList won't require a
per-item allocation. This would then also avoid allocations for other
datatypes, e.g. QStringView, QImage, maybe
Il 28/04/20 11:16, Kevin Kofler ha scritto:
* or the SSO gets reverted.
It's not SSO.
Is there any actual evidence that it is a win in practice?
Yes. But it's not SSO.
And on what hardware?
Enough to justify the adoption in all std::string implementations and in
3rd party ones as well
On 4/25/20 4:49 PM, André Pönitz wrote:
Spam detection software, running on the system "mx.qt-project.org",
has identified this incoming email as possible spam. The original
[*SIGHS*]
We all know the story that began with
"We knew for a long time that QList is not a good default
On 4/24/20 9:03 PM, Jason H wrote:
In fact, it is-a QList. What's the problem here with its naming?
Because I can't QSringList{"me", "you"}.join() with a QList.
I didn't say that it's a typedef for QList, but is-a -- it
inherits, precisely to provide that kind of convenience.
Thinking
On 4/24/20 8:57 AM, Joerg Bornemann wrote:
Alternatively, proposal 3 (aka "do almost nothing"):
template class QVector { implementation }
template using QList = QVector;
No deprecation of QVector.
No replacement of QList with QVector in our API.
Rationale: QList is our default
On 4/24/20 12:36 PM, Edward Welbourne wrote:
Giuseppe D'Angelo (24 April 2020 10:19) asked
Which "one year release approach" are we talking about here?
That would be Vitaly's proposal to have major releases yearly.
I must be missing something: how would that help, regarding the problem
at
On 4/23/20 11:10 PM, Vitaly Fanaskov wrote:
How often do you think we can play this game until people look for
something they consider more stable?
Moving to one year release approach doesn't equal to make Qt less stable.
Which "one year release approach" are we talking about here?
On 4/23/20 6:54 PM, Manuel Bergler wrote:
This is a documentation bug or a Creator bug. You're supposed to land on
this anchor:https://doc.qt.io/qt-5/qvariant.html#QVariantList-typedef
Technically this is the correct place to land on, but it isn't
helpful. Just like Julius, if I have a
On 4/23/20 5:04 PM, Julius Bullinger wrote:
Another suggestion: Get rid if the aliases; use the fully-qualified
types instead.
I'm always irritated if I open the documentation of QVariantList from
within Qt Creator, and land on the QVariant docu instead. I'm interested
in the features of the
On 4/23/20 1:20 PM, Edward Welbourne wrote:
So how much harm does it really cause, to keep both names; and use
whichever feels like the more natural description of the value one is
returning ?
I missing the bigger picture about this thread. What are we trying to
assess / solve?
== Source
On 4/23/20 10:55 AM, Simon Hausmann wrote:
So take for example this function in QIconEngine:
virtual QList availableSizes(QIcon::Mode mode =
Icon::Normal, QIcon::State state = QIcon::Off) const;
If we change that to QVector, we require our users to clutter their code
base with #ifdefs. If
On 4/14/20 11:30 AM, Allan Sandfeld Jensen wrote:
> No, any GUI-related API requires QGuiApplication, and any widget-related
> API QApplication.
>
In theory, but see https://codereview.qt-project.org/c/qt/qtbase/+/47846
I would stick to the documented contract, without any fancy ad-hoc
Hi,
On 4/14/20 1:34 AM, Konstantin Tokarev wrote:
The golden rule is that you're not allowed to touch any Qt API without
creating a Q*Application object first, unless the documentation says
otherwise.
Question is whether Q_Core_Application should be sufficient for using and image
format
Il 13/04/20 18:50, Kevin Kofler ha scritto:
Today, a user on #fedora-kde ran across a crash which resulted from:
* a GTK+/GNOME application (Jami) using (for some reason) QImage to load
images, without a QGuiApplication or QApplication constructed, vs.
* a QImage format plugin
Il 10/03/20 13:45, Jani Heikkinen ha scritto:
We haven't been blocking Beta (n) lately because of ongoing API review. Earlier
when there were only one beta we did that. After we started to deliver several
beta releases we stopped to block betas because of not finalized API review.
And I think
Il 10/03/20 10:53, Jani Heikkinen ha scritto:
It seems API review is still ongoing and many reviews are missing +2:
But, out of curiosity, why was the beta published when API review was
still ongoing?
Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB
Il 24/02/20 13:48, Mitch Curtis ha scritto:
In that case, I share the same concerns as Andre in that it requires IDEs to
have knowledge about Qt. I only use Creator, so it won't bother me, but it will
affect others who are e.g. transitioning or are so used to another IDE that
they'd never
Hi,
Something that I've always wondered about (and hopefully whose reasons
have been lost in the Nokia times) is why FocusScope exists a dedicated
item, rather than simply being an ordinary property on Item?
Any custom QQuickItem subclass can be a FocusScope, it just needs to set
a flag on
Il 21/02/20 17:42, Thiago Macieira ha scritto:
The first step would be for both qmake and cmake projects to warn if the
project doesn't declare keywords or no_keywords. Allow that to stay for 2 or 3
years so projects do update to declare their choices. This can start right
now, in 5.15.
At some
Il 21/02/20 13:59, Shawn Rutledge ha scritto:
(Some people name every slot function starting with the word “slot” to make
clear what it is.)
So, literally any function they write, since _anything_ can be a slot?
Or any function in a QObject subclass? (Not to mention that functions
are
Il 20/02/20 14:44, Kai Köhne ha scritto:
As a counter proposal that (I hope) would get broader consensus, I suggest to
just do this for 'emit': QTBUG-82379 .
I don't think this is exactly a counter proposal for the plan or the
scheduling posted by Marc, though. We're now bikeshedding about
Il 21/02/20 09:23, Kai Köhne ha scritto:
Another alternative is to actually use C++ attributes for this:
[[qt::emit]] somethingChanged();
C++ attributes are required since C++11, and since C++17 the compiler is also
required to just ignore one's it doesn't know [1]. Because it is part of
Il 21/02/20 12:49, Julien Cugnière ha scritto:
Isn't that true of any function call though ? Any function could end
up deleting this, or trigerring code in another thread, or anything.
For example, a normal function call could end up emiting a signal, and
as such, any function could be as
Il 21/02/20 12:15, Ville Voutilainen ha scritto:
without any annotation is not what we want. We'd miss vital information and
reduce readability.
Can you please explain what that vital information is?
That control is leaving the "local" function, and *anything* can happen
at that point.
Il 13/02/20 10:57, Vitaly Fanaskov ha scritto:
I think that moving Qt smart pointers to Qt5Compat module creates almost
no hassle. For Qt users it should be a one line in the terminal to
replace includes in their code bases (probably also prepend a namespace
to classes' names, but I'm not sure
Il 03/02/20 23:55, André Pönitz ha scritto:
On Mon, Feb 03, 2020 at 10:25:21PM +0100, Giuseppe D'Angelo wrote:
Il 03/02/20 20:38, André Pönitz ha scritto:
Directly affected are for instance functions operating on full containers in
https://doc.qt.io/qt-5/qtalgorithms-obsolete.html
Just
Il 04/02/20 00:49, André Pönitz ha scritto:
I've asked "what's wrong with the C++ smart pointers" a dozen times and
never received a satisfactory answer.
Did you? I am - to some degree truly - afraid I didn't notice.
[snip]
I apologize, I should've asked more clearly: "what's wrong with the
Il 03/02/20 17:56, Jason H ha scritto:
As a result, the code of a Qt-using program should be readable by average developers not big into C++.
But no one is imposing super-advanced C++ features on Qt users and Qt
applications...
Meanwhile, it also does not serve anyone to duplicate stl. I
Il 03/02/20 20:38, André Pönitz ha scritto:
Directly affected are for instance functions operating on full containers in
https://doc.qt.io/qt-5/qtalgorithms-obsolete.html
Just to set the record straight, the main reason why qAlgorithm(begin,
end) as well as qAlgorithm(container) have
Il 03/02/20 14:59, Vitaly Fanaskov ha scritto:
If we're going for this logical fallacy, then let's up the ante: a
unique pointer is just a shared pointer without copy semantics. Why
not using shared pointers everywhere?
Well, I hope it was rhetorical question, please, let me know if not.
On 02/02/2020 22:45, André Pönitz wrote:
This is a logical fallacy; "I don't need it, noone else does".
But this is the argument the de-Qt-ers use when it comes to Qt convenience
they don't need.
Which Qt convenience in particular? I seem to be advocating against
duplication "for the sake of
On 02/02/2020 21:26, Alberto Mardegan wrote:
This is a logical fallacy; "I don't need it, noone else does".
Yes, but it's a logical fallacy you yourself made up
Excuse me?
In my work experience, when I'm
not allowed to use Qt and am restricted to the STL, all the times I had
to use
On 02/02/2020 17:34, Alberto Mardegan wrote:
On 01/02/20 15:02, Giuseppe D'Angelo via Development wrote:
Il 01/02/20 12:44, Alberto Mardegan ha scritto:
On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote:
About QUniquePointer: what's the point of reinventing std::unique_ptr
under
On 02/02/2020 17:38, Alberto Mardegan wrote:
On 01/02/20 15:32, Giuseppe D'Angelo via Development wrote:
Il 01/02/20 12:37, Alberto Mardegan ha scritto:
Do we need to have such a counterpart? In my work experience, when I'm
not allowed to use Qt and am restricted to the STL, all the times I
On 02/02/2020 18:17, Иван Комиссаров wrote:
No one answered my question about QObject::deleteLater:
And what about the QObject::deleteLater() method? Any ideas how this should
look like with smart pointers?
You can specify custom deleters for smart pointers. For QScopedPointer
there's
Il 01/02/20 13:31, Allan Sandfeld Jensen ha scritto:
On Samstag, 1. Februar 2020 10:15:02 CET you wrote:
Il 01/02/20 09:27, Allan Sandfeld Jensen ha scritto:
To me the name is still perfect. It makes perfect sense. Just because it
is
movable doesn't mean you move the object itself, a move
Hi,
Il 01/02/20 22:55, Vitaly Fanaskov ha scritto:
The consensus was reached against such a decision. A scoped pointer
should not be able to escape scope. Yes, in C++17 this is now not
entirely true, but the name strongly implies it.
Perhaps, it's a good time to reconsider it. Scoped
Il 01/02/20 12:37, Alberto Mardegan ha scritto:
Do we need to have such a counterpart? In my work experience, when I'm
not allowed to use Qt and am restricted to the STL, all the times I had
to use std::unique_ptr was to get the same behaviour as a QScopedPointer.
So you never had to pass one
Il 01/02/20 12:44, Alberto Mardegan ha scritto:
On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote:
About QUniquePointer: what's the point of reinventing std::unique_ptr
under a different name?
A Qt-ish API!
Example?
* Is it just going to be an alias, to be more Qtish? Then why
Il 01/02/20 09:27, Allan Sandfeld Jensen ha scritto:
To me the name is still perfect. It makes perfect sense. Just because it is
movable doesn't mean you move the object itself, a move moves the content of
the object. So each move triggers a move of the payload of a scoped pointer to
another
On 31/01/2020 23:46, Vitaly Fanaskov wrote:
I'd suggest QUniquePointer. Honestly, I don't think we have too many
alternatives here. We can try Rust-like naming (something like QBox), but it
just looks weird and tells nothing about ownership semantics.
After that we can write "using
On 31/01/2020 21:09, Allan Sandfeld Jensen wrote:
QScopedPointer is exactly the counterpart to unique_ptr, the only difference
is the decision not to provide a move constructor and assignment when we
finally were allowed to use C++11,
"Only difference" is a major understatement here.
The
On 31/01/2020 18:28, Lisandro Damián Nicanor Pérez Meyer wrote:
For what it's worth: when I replied Thiago in the CVEs thread I also got
another mail from someone saying "I'm not Thiago". According to the
headers the mail was received trough the mailing list... Is there any
chance that someone
201 - 300 of 490 matches
Mail list logo
