Retiring the component would be a massive loss of data and alignment between
projects. This before retirement proposal we should have a plan on how to
manage this area properly. Granted, this is a messy area without clear
ownership thus we can argue on what team / who should be the owner of the
The "flag" is basically "a call to reserve was made"? How do I clear the flag?
shrink_to_fit()/squeeze() do this along the way.
--
Best Regards,
Andrei
From: Ville Voutilainen
Sent: Thursday, September 10, 2020 4:38 PM
To: Andrei Golubev
Cc: development@qt-projec
On 10/09/2020 15:38, Ville Voutilainen wrote:
The "flag" is basically "a call to reserve was made"? How do I clear the flag?
Yes (CapacityReserved, in Qt 5). squeeze() / shrink_to_fit() were
supposed to clear it.
HTH,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Enginee
On Thu, 10 Sep 2020 at 16:04, Andrei Golubev wrote:
>
> Should I expect to do a reserve call with a *smaller* value than my
> current size is before removing elements from
> a container, in order to set a "target size"? For any standard
> container, such a reserve is a complete noop because
> it c
Should I expect to do a reserve call with a *smaller* value than my
current size is before removing elements from
a container, in order to set a "target size"? For any standard
container, such a reserve is a complete noop because
it can't be responded to by shrinking a capacity lower than the size,
On Thu, 10 Sep 2020 at 11:46, Andrei Golubev wrote:
>
> That's interesting. So the container remembers what sort of a reserve
> request I made on it, and uses
> that as the preferred size whenever the element count of the container
> changes?
>
> Yes. Calling reserve typically means that you do n
Hi all,
We released Qt Design Studio 1.6 today, see
https://www.qt.io/blog/qt-design-studio-1.6-released
Big thanks to everyone involved!
Best Regards,
Thomas Hartmann
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.o
But reallocating on erase still falls under the problem that it
invalidates everything, including the part before the erased range.
Indeed. This is why I mentioned it in the first place. This can be "disabled"
by calling reserve().
Anyhow, I am not against any of the options: have shrinking opti
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 eras
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 detache
That's interesting. So the container remembers what sort of a reserve
request I made on it, and uses
that as the preferred size whenever the element count of the container changes?
Yes. Calling reserve typically means that you do not want to have extra
reallocations while updating the container's
Hi all,
We have released Qt 5.15.1, see https://www.qt.io/blog/qt-5.15.1-released
Big thanks to everyone involved!
Br,
Jani Heikkinen
Release Manager
The Qt Company
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/li
On Wed, 9 Sep 2020 at 16:38, Andrei Golubev wrote:
>
> I don't understand what this means. Am I supposed to reserve a
> container to its current size before erasing elements
> from it, if I don't want the erase to shrink it?
>
> Yes.
That's interesting. So the container remembers what sort of a r
13 matches
Mail list logo
