On Saturday, 3 November 2018 14:27:33 PDT Kevin Kofler wrote:
> But that also removes one major argument for changing QList to yet another
> QVector: the argument was that QStringList or QList would be
> inefficient with SSO QString, but that is moot if QString stays as it is.
A minimal SSO QStrin
Thiago Macieira wrote:
> Whether we'll have SSO is not decided.
That's good news, because I'm not convinced that that is a good idea,
either. It should be done only if it really is a win.
But that also removes one major argument for changing QList to yet another
QVector: the argument was that Q
On Saturday, 3 November 2018 07:47:53 PDT Kevin Kofler wrote:
> 4*sizeof(ptr) (i.e., at most 32 bytes) is not a large object. (Won't even
> the new QString with SSO be larger than that?) A large object is more like
> 100+ or even 1000+ bytes.
Whether we'll have SSO is not decided. But either way,
Lars Knoll wrote:
> I’ve tried a bit and for most use cases where the list and the object are
> of reasonable size (e.g. 4*sizeof(ptr)and ~100 items in the list) that
> overhead is actually just as large.
4*sizeof(ptr) (i.e., at most 32 bytes) is not a large object. (Won't even
the new QString wi
Olivier Goffart wrote:
> (We should probably deprecate QQueue right now and tell people to use
> std::deque)
Please no!
The API is just not comparable: QQueue uses nicer terminology (enqueue,
dequeue, head) and is implicitly shared, and most importantly, is consistent
with the other Qt containe
Il 03/11/18 03:16, Иван Комиссаров ha scritto:
Sure. Sorry for std::array_view (it maybe a QSet or QVector or gsl::span
whatever more convinient/faster).
The basic idea is here:
In the model:
void multipleData(QModelIndex index, std::array_view
roles, std::function enumerator)
{
for (auto
Sure. Sorry for std::array_view (it maybe a QSet or QVector or gsl::span
whatever more convinient/faster).
The basic idea is here:
In the model:
void multipleData(QModelIndex index, std::array_view roles,
std::function enumerator)
{
for (auto&& role: roles) {
if (role == Qt::DisplayRole
Il 02/11/18 20:13, Иван Комиссаров ha scritto:
Nice idea to have such a method. But is't it a pessimization to return a vector
which certainly allocates?
Don't throw rocks in me, what about passing std::function that can enumerate
roles?
As I said, we can bikeshed on the signature. How do you
Nice idea to have such a method. But is't it a pessimization to return a vector
which certainly allocates?
Don't throw rocks in me, what about passing std::function that can enumerate
roles?
Иван Комиссаров
> 2 нояб. 2018 г., в 17:52, Giuseppe D'Angelo via Development
> написал(а):
>
> Hi,
>
Hi,
Il 02/11/18 07:05, Shawn Rutledge ha scritto:
This is reasonable given the tree-of-tables that QAbstractItemModel models;
there's the bigger question of whether the one-API-fits-all is a good way
forward, however I don't see anyone willing to rewrite the model classes for
this. (There are
On 2 Nov 2018, at 10:10, André Pönitz
mailto:apoen...@t-online.de>> wrote:
On Fri, Nov 02, 2018 at 08:20:39AM +, Ulf Hermann wrote:
Depends on usage.
See e.g. 551efd91990e07902e5324f720cf5585865c323d
QmlProfiler: Use QList for QmlRange container when loading .qtd
As we are using this
On 11/2/18 10:10 AM, André Pönitz wrote:
> On Fri, Nov 02, 2018 at 08:20:39AM +, Ulf Hermann wrote:
>>> Depends on usage.
>>>
>>> See e.g. 551efd91990e07902e5324f720cf5585865c323d
>>>
>>> QmlProfiler: Use QList for QmlRange container when loading .qtd
>>>
>>> As we are using th
On Fri, Nov 02, 2018 at 08:20:39AM +, Ulf Hermann wrote:
> > Depends on usage.
> >
> > See e.g. 551efd91990e07902e5324f720cf5585865c323d
> >
> > QmlProfiler: Use QList for QmlRange container when loading .qtd
> >
> > As we are using this as a queue, with many calls to takeFirst(
On 02.11.18 09:20, Ulf Hermann wrote:
Depends on usage.
See e.g. 551efd91990e07902e5324f720cf5585865c323d
QmlProfiler: Use QList for QmlRange container when loading .qtd
As we are using this as a queue, with many calls to takeFirst(), a
QVector is prohibitively expensive
> On 2 Nov 2018, at 04:45, Thiago Macieira wrote:
>
> On Thursday, 1 November 2018 19:18:11 PDT Kevin Kofler wrote:
>> Thiago Macieira wrote:
>>> We're studying what to do with QList, but the idea is that the name
>>> "QList" will be completely ok and identical to QVector. The technical
>>> mecha
> Depends on usage.
>
> See e.g. 551efd91990e07902e5324f720cf5585865c323d
>
> QmlProfiler: Use QList for QmlRange container when loading .qtd
>
> As we are using this as a queue, with many calls to takeFirst(), a
> QVector is prohibitively expensive here.
I should have used QQu
On Thu, Nov 01, 2018 at 08:45:58PM -0700, Thiago Macieira wrote:
> On Thursday, 1 November 2018 19:18:11 PDT Kevin Kofler wrote:
> > Thiago Macieira wrote:
> > > We're studying what to do with QList, but the idea is that the name
> > > "QList" will be completely ok and identical to QVector. The tec
> On 31 Oct 2018, at 13:21, Giuseppe D'Angelo via Development
> wrote:
>
> Hi,
>
> Il 31/10/18 11:19, Иван Комиссаров ha scritto:
>> 1) QAbstractItemModel. I want to introduce change that adds QModelIndex
>> parameter to headerData(). For now, QHeaderView ignores the rootIndex()
>> propert
On Thursday, 1 November 2018 19:18:11 PDT Kevin Kofler wrote:
> Thiago Macieira wrote:
> > We're studying what to do with QList, but the idea is that the name
> > "QList" will be completely ok and identical to QVector. The technical
> > mechanism is in flux.
>
> That means you will be pessimizing
Thiago Macieira wrote:
> We're studying what to do with QList, but the idea is that the name
> "QList" will be completely ok and identical to QVector. The technical
> mechanism is in flux.
That means you will be pessimizing element inserts and removals from O(n) to
O(mn), where n is the length of
On Thursday, 1 November 2018 03:58:17 PDT Sascha Cunz wrote:
> > Qt6 won't be fully source-compatible. The idea is that we'll break it
> > to fix
> > things, but attempt to keep compatible as much as possible to avoid
> > death by a
> > thousand paper cuts.
>
> Does this rule out some kind of smar
I've seen that kind of argument before, so that's why I want put a comment
in here.
On Thu, Nov 1, 2018 at 12:58 PM Sascha Cunz wrote:
> I've seen lots of commercial code bases in the past where QObject
> inheriting classes are combined with QExplicitlySharedDataPointer -
> while at the same tim
On 2018-10-31 16:46, Thiago Macieira wrote:
Qt6 won't be fully source-compatible. The idea is that we'll break it
to fix
things, but attempt to keep compatible as much as possible to avoid
death by a
thousand paper cuts.
Does this rule out some kind of smart pointer that would be used to hold
On Wednesday, 31 October 2018 03:19:46 PDT Иван Комиссаров wrote:
> Hello, Thiago wrote in the "buildsystem thread" that Qt 6 will be source
> compatible with Qt5. As long as I fully support source-compatibility with
> both hands, I would like to ask several questions about possible
> source-breaki
Hi,
Il 31/10/18 11:19, Иван Комиссаров ha scritto:
1) QAbstractItemModel. I want to introduce change that adds QModelIndex
parameter to headerData(). For now, QHeaderView ignores the rootIndex()
property which prevents creating models with sub tables in each index (only
tree models are suppo
Hello, Thiago wrote in the "buildsystem thread" that Qt 6 will be source
compatible with Qt5. As long as I fully support source-compatibility with both
hands, I would like to ask several questions about possible source-breaking
changes.
1) QAbstractItemModel. I want to introduce change that add
26 matches
Mail list logo
