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
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
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
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
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
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 ==
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
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
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
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
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
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
>>>
> 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
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
> 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()
>>
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
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
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
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
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
>
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
25 matches
Mail list logo
