Re: [Development] Container refactor update
On Thursday June 21 2012, André Pönitz wrote:
On Thu, Jun 21, 2012 at 01:06:16AM +0200, Marc Mutz wrote:
On Thursday June 21 2012, André Pönitz wrote:
On Wed, Jun 20, 2012 at 08:52:55AM +0200, Marc Mutz wrote:
Hi Thiago,
[you knew this would be coming, I don't let you down]
On Monday June 18 2012, Thiago Macieira wrote:
* port QList
Before actually porting QList (esp. as I take the above to mean
that QList won't be bound to void* slots anymore): Is there
than *anything* in QList that QVector doesn't do at least as
good or that could be ported over to QVector (reserving space
in front for prepends comes to mind, though I'd argue that code
that uses this a lot is broken by design anyway).
Inserting in the middle of a container of complex data. In both
cases O(n), but a simple move of a block of pointers in one case
but not on the other.
So that's a corner case of a corner case QList is optimized for. C++98
throw specifications would still be alive and kicking if that was a
valuable goal :)
QList::append is not a corner case in my world.
You were talking about inserting in the middle, not append here.
Same for an append() that triggers
re-allocation actually.
Contrary to popular believe the constant hidden in big-O _does_
matter in practice...
Sorry, I was assuming familiarity with
http://marcmutz.wordpress.com/effective-qt/containers/#the-data
which suggests that QList doesn't outperform QVector even in its own
sweet spot (QString, QByteArray).
I am afraid your randomly selected use case does not match my
randomly selected use case.
At least the results differ.
For, say,
#include QList
#include QVector
#include math.h
struct A
{
A() : a(sin(12)) {}
A(const A b) : a(sin(b.a) + cos(b.a)) {}
int a;
};
struct Foo
{
A a[100];
};
int list()
{
QListFoo f;
for (int i = 0; i != 1; ++i)
f.append(Foo());
return f.size();
}
int vector()
{
QVectorFoo f;
for (int i = 0; i != 1; ++i)
f.append(Foo());
return f.size();
}
int main()
{
return list() + vector();
}
callgrind just came up with a 3:1 advantage _in favour_ of QList.
And that ratio can be made look arbitrarily worse by adding more load
to the copy constructor.
Except that my randomly selected usecases appear all over the place in Qt
APIs and yours doesn't, I agree.
Then it should be called QArrayList and the QList name freed for an
implementation with less surprising memory layout (ie. QVector).
Anyway, the rally point for my post was Thiago's observation that
QListQString with the new QString of 3*sizeof(void*) - I quote - will
be horrible. If you change QList to be efficient for QString again, what
else do you have but a QVector?
I haven't seen a single Qt developer team (Qt devs not
excepting) that is fully aware of the performance
characteristics and memory layout of QList.
That's an interesting observation that does not _fully_
seem to match mine ;-}
Case in point: QListQModelIndex, QListQVariant and QListbool. The
first two copy-construct all elements onto the heap, the latter wastes
87.5% (on 64bit) of the allocated memory on padding.
What's the rationale for preferring QList here? Wouldn't you agree that
these would have better used QVector? Wouldn't you agree that changing
QList to QVector all over Qt 5 is a bit too source-incompatible and that
therefore backing QList by QVector would be a decent thing to do?
Replacing QList by QVector internally in cases where is makes sense is a
no-brainer. Making them equivalent, less so...
The problem I have with QList is that the user needs to work hard not to make
QList suck memory and speed-wise (mark it movable, be of the correct size)
whilst the cases where its indirection really do give a benefit are, indeed,
corner cases.
A specialised container is suggested as a good default container _and_ has the
most attractive name, and in 95% of all use-cases, a QVector would have been
preferable.
This is bad API design.
If you want to preserve the semantics of QList, do so, but don't call it a
good default container and don't give it the most attractive name :)
Thanks,
Marc
--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On Thursday June 21 2012, Marc Mutz wrote:
A(const A b) : a(sin(b.a) + cos(b.a)) {}
Btw: this class doesn't meet normal copy operation semantics and is therefore
not something anyone would ever stuff into a container (copies do not compare
equal). Such a class would be held by (smart) pointer instead.
--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On Thursday June 21 2012, Thiago Macieira wrote: On quinta-feira, 21 de junho de 2012 08.26.23, Marc Mutz wrote: You meant sizeof(T) _=_ 32 _||_ T is movable, right? Yes and no. sizeof(T) = 32 T is movable Assuming move constructors become ubiquitous on types that you'd want to put into a homogeneous container, I wonder if a special case for large or non-movable types is needed at all. I'll add move support to QVector. But I want QList to always use realloc. If your type can't be realloc'ed, then QList should indirect. What's the rationale for this design choice? But whatever it may be: May I ask you to reconsider? The movable trait (as in Q_MOVABLE_TYPE, not T) is nothing a compiler can automatically detect, not even theoretically (consider out-of-line copy ctors, e.g.). So when you say T is movable, what you really mean is T is _declared_ movable by the user. The fact that T needs to be declared movable for QListT to not use per-element free-store allocations then means that the Qt *default* container performs horribly (quoting yourself) for *all* types except if the user takes *manual* action (which might not be easy to do if the type in question doesn't have yet a Qt dependency, e.g. if it comes from a third-party library; there'll be no got place to put the required Q_DECLARE_TYPEINFO). I consider this API the wrong way around, don't you? :) Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update [Caution: Message contains Suspicious URL content]
Von: development-bounces+helmut.muelner=joanneum...@qt-project.org
[mailto:development-bounces+helmut.muelner=joanneum.at@qt-
project.org] Im Auftrag von André Pönitz
Gesendet: Donnerstag, 21. Juni 2012 02:00
An: Marc Mutz
Cc: development@qt-project.org
Betreff: Re: [Development] Container refactor update [Caution: Message
contains Suspicious URL content]
On Thu, Jun 21, 2012 at 01:06:16AM +0200, Marc Mutz wrote:
On Thursday June 21 2012, André Pönitz wrote:
On Wed, Jun 20, 2012 at 08:52:55AM +0200, Marc Mutz wrote:
[...]
#include QList
#include QVector
#include math.h
struct A
{
A() : a(sin(12)) {}
A(const A b) : a(sin(b.a) + cos(b.a)) {}
int a;
};
struct Foo
{
A a[100];
};
int list()
{
QListFoo f;
for (int i = 0; i != 1; ++i)
f.append(Foo());
return f.size();
}
int vector()
{
QVectorFoo f;
for (int i = 0; i != 1; ++i)
f.append(Foo());
return f.size();
}
int main()
{
return list() + vector();
}
callgrind just came up with a 3:1 advantage _in favour_ of QList.
And that ratio can be made look arbitrarily worse by adding more load to the
copy constructor.
[...]
I measured this programming using MSVC2010 with /Ox and Rational Quantify and
also the a 3:1 factor.
But: QList::append calls new 1 times, QVector::append never calls new but
QVectorData::allocate twice and QVector::realloc once.
If I add f.reserve(1) in both cases, QList::append still call new 1
times, and QVectorData::allocate is still called only twice, and QVector is
faster than QList (by a small but consistent margin).
Without optimization QVectorData::allocate is call 24 times (for the first
case, still 3:1).
This looks like MSVC2010 can optimize away QVector resizes. And you can get
arbitrary results if you make the constructor heavier and the copy constructor
lighter.
Best regards,
Helmut
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On quinta-feira, 21 de junho de 2012 09.36.29, Marc Mutz wrote: But I want QList to always use realloc. If your type can't be realloc'ed, then QList should indirect. What's the rationale for this design choice? Because it's the current design. All I'm doing is remove the overhead of void* slots and expanding the size to include our typical types. But whatever it may be: May I ask you to reconsider? Yes. The benchmark just posted (1x allocating new) is a very important thing to consider. I'm not saying that I'll do it, but I'll think about it. The movable trait (as in Q_MOVABLE_TYPE, not T) is nothing a compiler can automatically detect, not even theoretically (consider out-of-line copy ctors, e.g.). So when you say T is movable, what you really mean is T is _declared_ movable by the user. Yes, that's what I mean. The fact that T needs to be declared movable for QListT to not use per-element free-store allocations then means that the Qt *default* container performs horribly (quoting yourself) for *all* types except if the user takes *manual* action (which might not be easy to do if the type in question doesn't have yet a Qt dependency, e.g. if it comes from a third-party library; there'll be no got place to put the required Q_DECLARE_TYPEINFO). I consider this API the wrong way around, don't you? :) If you put it that way, yes. The original goal of having QList store pointers was to be very quick on reallocations. If it knows that its array is always movable, it can hardcode calls to realloc, instead of malloc a new array and copy/move the items. The result is that mutating a list of any type is very quick. In other words: QList is optimised for mutating a list (appending, prepending, inserting in the middle, popping from the ends, erasing from the middle). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
Hi Thiago, [you knew this would be coming, I don't let you down] On Monday June 18 2012, Thiago Macieira wrote: * port QList Before actually porting QList (esp. as I take the above to mean that QList won't be bound to void* slots anymore): Is there than *anything* in QList that QVector doesn't do at least as good or that could be ported over to QVector (reserving space in front for prepends comes to mind, though I'd argue that code that uses this a lot is broken by design anyway). So, can we please just have the equivalent of template typename T using QList = QVectorT; after moving the members that QList has but QVector lacks over to QVector? I'd be more than happy to volunteer a patch. I haven't seen a single Qt developer team (Qt devs not excepting) that is fully aware of the performance characteristics and memory layout of QList. Most just use it because it has a nicer name than QVector. Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On 19.06.2012 11:04, Olivier Goffart wrote:
templatetypename T QMetaObject AT::staticMetaObject = { ... };
Hi Oliver,
looking at this with some hacking on moc,
templateclass T
class Foo : public QObject
{
Q_OBJECT
public:
Foo() {}
signals:
void asignal(T t);
};
it looks like generating templated code isn't complicated:
void FooT::qt_static_metacall
...
but then we also get
static const char qt_meta_stringdata_FooT[] = {
FooT\0\0t\0asignal(T)\0
};
Isn't this a big problem?
When Fooint is used, we would need the meta type information
with 'int' not with T:
static const char qt_meta_stringdata_Fooint[] = {
Fooint\0\0t\0asignal(int)\0
};
Peter
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On Wednesday 20 June 2012 10:47:01 Peter Kümmel wrote:
On 19.06.2012 11:04, Olivier Goffart wrote:
templatetypename T QMetaObject AT::staticMetaObject = { ... };
Hi Oliver,
looking at this with some hacking on moc,
templateclass T
class Foo : public QObject
{
Q_OBJECT
public:
Foo() {}
signals:
void asignal(T t);
};
it looks like generating templated code isn't complicated:
void FooT::qt_static_metacall
...
but then we also get
static const char qt_meta_stringdata_FooT[] = {
FooT\0\0t\0asignal(T)\0
};
Isn't this a big problem?
When Fooint is used, we would need the meta type information
with 'int' not with T:
static const char qt_meta_stringdata_Fooint[] = {
Fooint\0\0t\0asignal(int)\0
};
That's because you are looking at Qt4.
In Qt5 it is could be something more like FooT\0asignal\0\0T\0t\0
And you can connect using the new pointer function syntax.
And some little changes would be required to the other syntax for it to work,
but it should be possible (as now, the signature of the signal is only
reconstructed at runtime)
Fooint foo;
connect(foo, Fooint::asignal, this, Bar::setInt);
connect(foo, SIGNAL(signal(int)), this, SLOT(setInt(int)));
--
Olivier
Woboq - Qt services and support - http://woboq.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On Wednesday 20. June 2012 11.25.28 ext Peter Kümmel wrote:
On 20.06.2012 11:09, Olivier Goffart wrote:
static const char qt_meta_stringdata_Fooint[] = {
Fooint\0\0t\0asignal(int)\0
};
That's because you are looking at Qt4.
In Qt5 it is could be something more like FooT\0asignal\0\0T\0t\0
And you can connect using the new pointer function syntax.
And some little changes would be required to the other syntax for it to
work, but it should be possible (as now, the signature of the signal
is only reconstructed at runtime)
Fooint foo;
connect(foo,Fooint::asignal, this,Bar::setInt);
connect(foo, SIGNAL(signal(int)), this, SLOT(setInt(int)));
OK, connection would work. But what I mean is, from the meta type
perspective Fooint and Foodouble would have the same meta type.
Therefore the idea to use specialization, then you could define
qt_meta_stringdata_Foo for each type.
Peter
Just a side note. From c++ and qt meta type perspective Fooint and
Foodouble are unrelated and completely different types.
Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On 20.06.2012 12:31, Thiago Macieira wrote:
On quarta-feira, 20 de junho de 2012 10.47.01, Peter Kümmel wrote:
When Fooint is used, we would need the meta type information
with 'int' not with T:
static const char qt_meta_stringdata_Fooint[] = {
Fooint\0\0t\0asignal(int)\0
};
Who generates this?
moc, we simply tell it for which types it should generate it.
This was the idea for Q_QOBJECT_SPECIALISATION(int)
Peter
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On quarta-feira, 20 de junho de 2012 13.09.40, Peter Kümmel wrote:
On 20.06.2012 12:31, Thiago Macieira wrote:
On quarta-feira, 20 de junho de 2012 10.47.01, Peter Kümmel wrote:
When Fooint is used, we would need the meta type information
with 'int' not with T:
static const char qt_meta_stringdata_Fooint[] = {
Fooint\0\0t\0asignal(int)\0
};
Who generates this?
moc, we simply tell it for which types it should generate it.
This was the idea for Q_QOBJECT_SPECIALISATION(int)
Please tell me what it should generate for these classes then:
template typename T class Foo
{
Q_OBJECT
signals:
void asignal(typename std::make_unsignedT::type)
void othersignal(typename std::remove_referenceT::type )
};
template typename T class FooT *
{
Q_OBJECT
signals:
void ptrsignal(T);
};
template int Size class Bar
{
Q_OBJECT
signals:
void asignal(typename QIntegerForSizeSize::Unsigned);
};
Note that I can make this as complex as you can ask.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
Is it me or this thread was badly derailed? Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On segunda-feira, 18 de junho de 2012 23.58.47, Thiago Macieira wrote: * port QString, QByteArray and moc - the meta object will no longer need to keep 24 bytes per string QString and moc are done, though I somehow introduced a regression in tst_moc in something completely unrelated. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On 20.06.2012 13:38, Thiago Macieira wrote:
On quarta-feira, 20 de junho de 2012 13.09.40, Peter Kümmel wrote:
On 20.06.2012 12:31, Thiago Macieira wrote:
On quarta-feira, 20 de junho de 2012 10.47.01, Peter Kümmel wrote:
When Fooint is used, we would need the meta type information
with 'int' not with T:
static const char qt_meta_stringdata_Fooint[] = {
Fooint\0\0t\0asignal(int)\0
};
Who generates this?
moc, we simply tell it for which types it should generate it.
This was the idea for Q_QOBJECT_SPECIALISATION(int)
Please tell me what it should generate for these classes then:
I see, string based matching signal/slots will not work,
only simple replacements would make sense,
asignal(T t) - asignal(int t).
But to get different meta types we still can use a specialization:
templatetypename T class Foo
{
Q_OBJECT
signals:
void asignal(typename std::make_unsignedT::type)
void othersignal(typename std::remove_referenceT::type)
};
With a typedef cp is maybe enough:
template
class FooT
{
Q_OBJECT
public:
typedef int T;
signals:
void asignal(typename std::make_unsignedT::type)
void othersignal(typename std::remove_referenceT::type)
};
static const char qt_meta_stringdata_Fooint[] = {
Fooint\0\0t\0asignal(...)\0
The signal signature as string isn't relevant than any more.
And not all template tricks have to be supported.
Currently Qt says
Template classes not supported by Q_OBJECT
we could switch to something like
Template class is too complex to be a QObject
Peter
templatetypename T class FooT *
{
Q_OBJECT
signals:
void ptrsignal(T);
};
templateint Size class Bar
{
Q_OBJECT
signals:
void asignal(typename QIntegerForSizeSize::Unsigned);
};
Note that I can make this as complex as you can ask.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On Tue, Jun 19, 2012 at 09:55:28PM -0400, Stephen Chu wrote: Just a reminder that these changes are causing failure to build debug dumper in Creator. https://bugreports.qt-project.org/browse/QTCREATORBUG-7558 I think this is fixed in current master branch. Until further notice, or until Qt 5.0 is out, you will have to have a recent Qt Creator build if you want to have dumpers matching a current Qt 5.0 build. There have been changes to the Qt containers after the Qt Creator 2.5 release, and there are probably one or two more to come. I tried pretty hard to keep 2.5 as up-to-date as possible to the Qt 5 branch at the time of release, but one cannot expect to be able to predict details of not-yet-invented changes ;-} Andre' PS: A side note: I really appreciate the current work on the containers, and requiring a up-to-date Qt Creator to handle a bleeding edge version of Qt seems a reasonable price for the improvements. Of course, I also appreciate a friendly nudge _before_ someone touches containers, or QObject internals. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On 6/20/12 6:20 PM, André Pönitz wrote: On Tue, Jun 19, 2012 at 09:55:28PM -0400, Stephen Chu wrote: Just a reminder that these changes are causing failure to build debug dumper in Creator. https://bugreports.qt-project.org/browse/QTCREATORBUG-7558 I think this is fixed in current master branch. Until further notice, or until Qt 5.0 is out, you will have to have a recent Qt Creator build if you want to have dumpers matching a current Qt 5.0 build. There have been changes to the Qt containers after the Qt Creator 2.5 release, and there are probably one or two more to come. I tried pretty hard to keep 2.5 as up-to-date as possible to the Qt 5 branch at the time of release, but one cannot expect to be able to predict details of not-yet-invented changes ;-} Andre' PS: A side note: I really appreciate the current work on the containers, and requiring a up-to-date Qt Creator to handle a bleeding edge version of Qt seems a reasonable price for the improvements. Of course, I also appreciate a friendly nudge _before_ someone touches containers, or QObject internals. Thanks. Is a completely new Creator required for it to work or just the files (dumper.cpp, etc) for building the dumper? Try as I might, I just cannot get Creator built in my system. If replacing the dumper source files is all it takes, I can do the surgery easily. :) Or will there be snapshots available? I see Windows and Linux ones but never Mac version at http://builds.qt-project.org/view/Qt%20Creator/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On Wed, Jun 20, 2012 at 08:52:55AM +0200, Marc Mutz wrote: Hi Thiago, [you knew this would be coming, I don't let you down] On Monday June 18 2012, Thiago Macieira wrote: * port QList Before actually porting QList (esp. as I take the above to mean that QList won't be bound to void* slots anymore): Is there than *anything* in QList that QVector doesn't do at least as good or that could be ported over to QVector (reserving space in front for prepends comes to mind, though I'd argue that code that uses this a lot is broken by design anyway). Inserting in the middle of a container of complex data. In both cases O(n), but a simple move of a block of pointers in one case but not on the other. Same for an append() that triggers re-allocation actually. Contrary to popular believe the constant hidden in big-O _does_ matter in practice... So, can we please just have the equivalent of template typename T using QList = QVectorT; after moving the members that QList has but QVector lacks over to QVector? -1. QList serves a purpose. I haven't seen a single Qt developer team (Qt devs not excepting) that is fully aware of the performance characteristics and memory layout of QList. That's an interesting observation that does not _fully_ seem to match mine ;-} Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On Thursday June 21 2012, André Pönitz wrote: On Wed, Jun 20, 2012 at 08:52:55AM +0200, Marc Mutz wrote: Hi Thiago, [you knew this would be coming, I don't let you down] On Monday June 18 2012, Thiago Macieira wrote: * port QList Before actually porting QList (esp. as I take the above to mean that QList won't be bound to void* slots anymore): Is there than *anything* in QList that QVector doesn't do at least as good or that could be ported over to QVector (reserving space in front for prepends comes to mind, though I'd argue that code that uses this a lot is broken by design anyway). Inserting in the middle of a container of complex data. In both cases O(n), but a simple move of a block of pointers in one case but not on the other. So that's a corner case of a corner case QList is optimized for. C++98 throw specifications would still be alive and kicking if that was a valuable goal :) Same for an append() that triggers re-allocation actually. Contrary to popular believe the constant hidden in big-O _does_ matter in practice... Sorry, I was assuming familiarity with http://marcmutz.wordpress.com/effective-qt/containers/#the-data which suggests that QList doesn't outperform QVector even in its own sweet spot (QString, QByteArray). So, can we please just have the equivalent of template typename T using QList = QVectorT; after moving the members that QList has but QVector lacks over to QVector? -1. QList serves a purpose. Then it should be called QArrayList and the QList name freed for an implementation with less surprising memory layout (ie. QVector). Anyway, the rally point for my post was Thiago's observation that QListQString with the new QString of 3*sizeof(void*) - I quote - will be horrible. If you change QList to be efficient for QString again, what else do you have but a QVector? I haven't seen a single Qt developer team (Qt devs not excepting) that is fully aware of the performance characteristics and memory layout of QList. That's an interesting observation that does not _fully_ seem to match mine ;-} Case in point: QListQModelIndex, QListQVariant and QListbool. The first two copy-construct all elements onto the heap, the latter wastes 87.5% (on 64bit) of the allocated memory on padding. What's the rationale for preferring QList here? Wouldn't you agree that these would have better used QVector? Wouldn't you agree that changing QList to QVector all over Qt 5 is a bit too source-incompatible and that therefore backing QList by QVector would be a decent thing to do? Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On Wed, Jun 20, 2012 at 06:27:35PM -0400, Stephen Chu wrote: Thanks. Is a completely new Creator required for it to work or just the files (dumper.cpp, etc) for building the dumper? Try as I might, I just cannot get Creator built in my system. If replacing the dumper source files is all it takes, I can do the surgery easily. :) Only dumper.cpp in this case (and the compilation is Mac-only) The necessary change is f4ea50b52. Or will there be snapshots available? I see Windows and Linux ones but never Mac version at http://builds.qt-project.org/view/Qt%20Creator/ Would hopefully, at some point of time qualify as answer? ;-} Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On quinta-feira, 21 de junho de 2012 00.20.11, André Pönitz wrote: I tried pretty hard to keep 2.5 as up-to-date as possible to the Qt 5 branch at the time of release, but one cannot expect to be able to predict details of not-yet-invented changes ;-} C'mon, just use your crystal ball a little harder! -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On quarta-feira, 20 de junho de 2012 08.52.55, Marc Mutz wrote: Hi Thiago, [you knew this would be coming, I don't let you down] On Monday June 18 2012, Thiago Macieira wrote: * port QList Before actually porting QList (esp. as I take the above to mean that QList won't be bound to void* slots anymore): Is there than *anything* in QList that QVector doesn't do at least as good or that could be ported over to QVector (reserving space in front for prepends comes to mind, though I'd argue that code that uses this a lot is broken by design anyway). So, can we please just have the equivalent of template typename T using QList = QVectorT; after moving the members that QList has but QVector lacks over to QVector? My plan is *almost* that. QListT will be a QVectorT if sizeof(T) 32 T is movable Otherwise, QListT will be backed by a QVectorT * and the pointer will be dereferenced in the accessor functions. The value of 32 is chosen because it will be the size of QVariant on 64-bit platforms. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On terça-feira, 19 de junho de 2012 00.32.37, Peter Kümmel wrote: Do you know folly https://github.com/facebook/folly and had a look at folly's code? https://github.com/facebook/folly/blob/master/folly/FBVector.h Performance wise it could be interesting, because at some places it uses lock-free code. Yes, I know about it. No, I did not look at it. I cannot do that because I need to write code of my own. I cannot look at other people's code and submit to the Qt Project under the CLA, unless it's in the public domain. What's more, lock-free is a technique for making thread-safe containers. Qt containers are not meant to be that. And when you say at some places it uses lock-free, it implies that in other places it doesn't, which means those places use locks and that's not acceptable. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On Mon, Jun 18, 2012 at 11:58 PM, Thiago Macieira thiago.macie...@intel.com wrote: Here's the current status of my endeavour: Hi Thiago. As you may have figured out by now, I am one of those who plea for an extra set of container widgets deriving from QObject. You know, so they can support slots and signals. But seeing how hard people work to get performance out of the core containers, I guess it will never happen. Yes, of course, it comes from some bad experiences I had learning how to expose QLists to QML. But the discussion is universal in the Qt universe. Is this crazy talk? I would imagine that given a set of containers like ... hmm ... QSmartList, QSmartMap, QSmartHash inheriting from QObject (yes, I know ... moc and templates bla bla - I could live with fixed key/value-types if that's what it takes - java did before going parametric), that us poor programmers would not have to work so hard to keep complicated interconnected data objects synchronized between the UI and e.g. a database or over a network wire. I mean.. SIGNAL(itemAdded) would be nice from time to time. Am I alone in this? What would it take? No clue. I'm sure you all have thought immensely about this before. One simple guess: All methods on a QList needs to check quickly if this is a monitored list when changing it. If so, those methods could notify their depending QObject monitor (QSmartList) which then emitted the signal. Then again, I can easily be convinced that the current approach is better. I wouldn't suggest wrapping plain ol' datatypes inside QObjects for simple Q_PROPERTIES, so why lists and maps? Best regards, Rene Jensen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On 19.06.2012 08:44, Thiago Macieira wrote: Yes, I know about it. No, I did not look at it. I cannot do that because I need to write code of my own. I cannot look at other people's code and submit to the Qt Project under the CLA, unless it's in the public domain. You must not read other code?! Then sorry for the link. Hope you could everybody convince you haven't clicked on the link, at least when your eyes were open ;) What's more, lock-free is a technique for making thread-safe containers. Qt containers are not meant to be that. And when you say at some places it uses lock-free, it implies that in other places it doesn't, which means those places use locks and that's not acceptable. I don't know what code is thread save. Seems the vector is not, like yours. Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On terça-feira, 19 de junho de 2012 09.21.46, Peter Kümmel wrote: On 19.06.2012 08:44, Thiago Macieira wrote: Yes, I know about it. No, I did not look at it. I cannot do that because I need to write code of my own. I cannot look at other people's code and submit to the Qt Project under the CLA, unless it's in the public domain. You must not read other code?! Then sorry for the link. Hope you could everybody convince you haven't clicked on the link, at least when your eyes were open ;) If I read their code and then implement a vector soon after or at the same time, one could argue that I copied their code onto Qt. That's why I don't do it. What's more, lock-free is a technique for making thread-safe containers. Qt containers are not meant to be that. And when you say at some places it uses lock-free, it implies that in other places it doesn't, which means those places use locks and that's not acceptable. I don't know what code is thread save. Seems the vector is not, like yours. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On 19.06.2012 09:11, Rene Jensen wrote: Is this crazy talk? I would imagine that given a set of containers like ... hmm ... QSmartList, QSmartMap, QSmartHash inheriting from QObject (yes, I know ... moc and templates bla bla - I could live with fixed key/value-types if that's what it takes - java did before going parametric), Maybe there's a time moc embeds clang and can 'understand' template code. Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On 19.06.2012 09:39, Thiago Macieira wrote: On terça-feira, 19 de junho de 2012 09.21.46, Peter Kümmel wrote: On 19.06.2012 08:44, Thiago Macieira wrote: Yes, I know about it. No, I did not look at it. I cannot do that because I need to write code of my own. I cannot look at other people's code and submit to the Qt Project under the CLA, unless it's in the public domain. You must not read other code?! Then sorry for the link. Hope you could everybody convince you haven't clicked on the link, at least when your eyes were open ;) If I read their code and then implement a vector soon after or at the same time, one could argue that I copied their code onto Qt. That's why I don't do it. So even no Apache licensed code could be used within Qt? Sound like Qt's version of not invented here. What's more, lock-free is a technique for making thread-safe containers. Qt containers are not meant to be that. And when you say at some places it uses lock-free, it implies that in other places it doesn't, which means those places use locks and that's not acceptable. I don't know what code is thread save. Seems the vector is not, like yours. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On terça-feira, 19 de junho de 2012 09.54.15, Peter Kümmel wrote: So even no Apache licensed code could be used within Qt? Irrelevant. The CLA says that I can only submit code I authored myself. That excludes everything that has a copyright, regardless of the license. Third-party code can only be imported under the Chief Maintainer's authorisation and after a legal scan. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On terça-feira, 19 de junho de 2012 09.51.32, Peter Kümmel wrote: On 19.06.2012 09:11, Rene Jensen wrote: Is this crazy talk? I would imagine that given a set of containers like ... hmm ... QSmartList, QSmartMap, QSmartHash inheriting from QObject (yes, I know ... moc and templates bla bla - I could live with fixed key/value-types if that's what it takes - java did before going parametric), Maybe there's a time moc embeds clang and can 'understand' template code. Moc can understand template code just fine for the output it produces. The problem is that the meta object format does not allow for signals and slots containing template parameters in their signature. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On 19.06.2012 09:58, Thiago Macieira wrote: On terça-feira, 19 de junho de 2012 09.54.15, Peter Kümmel wrote: So even no Apache licensed code could be used within Qt? Irrelevant. The CLA says that I can only submit code I authored myself. That excludes everything that has a copyright, regardless of the license. Thanks, that makes it clear. Third-party code can only be imported under the Chief Maintainer's authorisation and after a legal scan. OK, at least it is possible. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
BTW, are there any plans to use lock-free techniques somewhere within Qt? Or have you already evaluated it? The lock-free strategy looks a bit like transactional memory: try it until it is right. Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On terça-feira, 19 de junho de 2012 10.07.36, Peter Kümmel wrote: BTW, are there any plans to use lock-free techniques somewhere within Qt? Or have you already evaluated it? The lock-free strategy looks a bit like transactional memory: try it until it is right. Morten wrote one implementation a few years ago. One of the big problems with lock-free is to ensure no ABA problems, and that requires a bit better control of the atomics than QBasicAtomic provides. In particular, it requires a weak mode for LL/SC architectures and it requires a double-pointer atomic for non-LL/SC architectures. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On 19.06.2012 10:00, Thiago Macieira wrote:
On terça-feira, 19 de junho de 2012 09.51.32, Peter Kümmel wrote:
On 19.06.2012 09:11, Rene Jensen wrote:
Is this crazy talk? I would imagine that given a set of containers like
... hmm ... QSmartList, QSmartMap, QSmartHash inheriting from QObject
(yes, I know ... moc and templates bla bla - I could live with fixed
key/value-types if that's what it takes - java did before going
parametric),
Maybe there's a time moc embeds clang and can 'understand' template code.
Moc can understand template code just fine for the output it produces. The
problem is that the meta object format does not allow for signals and slots
containing template parameters in their signature.
But moc could not produce code like this, so I would say it is not just fine:
- header:
templateclass T
struct A : public QObject
{
signals:
void aSignal(T);
public:
void foo(){...}
};
- somewhere:
Aint a;
- moc file/header:
template
struct Aint : public QObject
{
Q_QOBJECT
signals:
void aSignal(int);
// simple copy of code in base template
void foo(){...}
};
+ the typical moc code
But for this all source code needs to be scanned,
not only the headers.
Peter
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On 06/19/2012 11:58 AM, Thiago Macieira wrote: On terça-feira, 19 de junho de 2012 09.54.15, Peter Kümmel wrote: So even no Apache licensed code could be used within Qt? Irrelevant. The CLA says that I can only submit code I authored myself. That excludes everything that has a copyright, regardless of the license. I don't think that Peter was suggesting you to import the code from folly, but just to have a look at how it's implemented. IANAL, but I think that you can have a look at any software code which you obtained legally, and pick this and that idea from it; as long as you close the original source file in your editor and let a couple of days pass before starting writing your own, you are authoring original code. Just make sure that you empty the clipboard. ;-) Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On 19 Jun, 2012, at 10:07 , ext Peter Kümmel wrote: BTW, are there any plans to use lock-free techniques somewhere within Qt? http://qt.gitorious.org/qt/qtbase/blobs/master/src/corelib/tools/qfreelist_p.h http://qt.gitorious.org/qt/qtbase/blobs/master/src/corelib/tools/qfreelist.cpp ;) Or have you already evaluated it? The lock-free strategy looks a bit like transactional memory: try it until it is right. This is one approach, but there are others. I'd love to see more of them show up in Qt :) -- Bradley T. Hughes bradley.hug...@nokia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On 19 June 2012 09:24, Alberto Mardegan ma...@users.sourceforge.net wrote: On 06/19/2012 11:58 AM, Thiago Macieira wrote: On terça-feira, 19 de junho de 2012 09.54.15, Peter Kümmel wrote: So even no Apache licensed code could be used within Qt? Irrelevant. The CLA says that I can only submit code I authored myself. That excludes everything that has a copyright, regardless of the license. I don't think that Peter was suggesting you to import the code from folly, but just to have a look at how it's implemented. IANAL, but I think that you can have a look at any software code which you obtained legally, and pick this and that idea from it; as long as you close the original source file in your editor and let a couple of days pass before starting writing your own, you are authoring original code. Just make sure that you empty the clipboard. ;-) Please, do NOT do that. Stick to clean room implementations. You don't want to be involved in legal matters for copyright infringement because someone argues that you have a good memory and indeed copied the design. Unfortunately, reading/using 3rd party, publicly available code is not OK in general. There are companies that won't allow you to work for them if you ever contributed to open source projects. -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On Tuesday 19 June 2012 10:22:02 Peter Kümmel wrote:
On 19.06.2012 10:00, Thiago Macieira wrote:
On terça-feira, 19 de junho de 2012 09.51.32, Peter Kümmel wrote:
On 19.06.2012 09:11, Rene Jensen wrote:
Is this crazy talk? I would imagine that given a set of containers like
... hmm ... QSmartList, QSmartMap, QSmartHash inheriting from QObject
(yes, I know ... moc and templates bla bla - I could live with fixed
key/value-types if that's what it takes - java did before going
parametric),
Maybe there's a time moc embeds clang and can 'understand' template code.
Moc can understand template code just fine for the output it produces. The
problem is that the meta object format does not allow for signals and
slots
containing template parameters in their signature.
But moc could not produce code like this, so I would say it is not just
fine:
moc needs small adaptations, that's true. But here your example involve
specialisation of template, which i think is another level.
What would be possible with some addapation is
templatetypename T class A : public QObject { Q_OBJECT
signal: void someSignal(T);
};
///
Then moc should basically be adjusted to generate what it generates now, but
adding template typename T in front of everything, and some other small
adjustemnt
template typename T QMetaObject AT::staticMetaObject = { ... };
template typename T void AT::someSignal() {
QMetaObject::activate(this, staticMetaObject, 0); }
template typename T void AT::qt_metacall(...) {
...
case 0: someSignal(*reinterpret_castT*(*args[1]))
}
Not very complicated, but the other point is that then one should include the
moc everywhere.
And is it really worth it?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On terça-feira, 19 de junho de 2012 12.24.58, Alberto Mardegan wrote: I don't think that Peter was suggesting you to import the code from folly, but just to have a look at how it's implemented. IANAL, but I think that you can have a look at any software code which you obtained legally, and pick this and that idea from it; as long as you close the original source file in your editor and let a couple of days pass before starting writing your own, you are authoring original code. Just make sure that you empty the clipboard. Notwithstanding what Peppe said, I don't have a few days to wait :-) However, we can do a clean-room reimplementation: if someone looks at their code and tells me what clever solutions they came up with, it would be nice. But, TBH, I don't expect much. There are only so many ways to implement a vector. It's got a memory block with items in it :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On terça-feira, 19 de junho de 2012 10.22.02, Peter Kümmel wrote:
Moc can understand template code just fine for the output it produces. The
problem is that the meta object format does not allow for signals and
slots
containing template parameters in their signature.
But moc could not produce code like this, so I would say it is not just
fine:
Let me emphasise what I said: it can read code just fine for the uses that it
makes. It can parse templates up to an extent. It does not parse what it
cannot use anyway.
- header:
templateclass T
struct A : public QObject
{
signals:
void aSignal(T);
public:
void foo(){...}
};
- somewhere:
Aint a;
- moc file/header:
template
struct Aint : public QObject
{
Q_QOBJECT
signals:
void aSignal(int);
// simple copy of code in base template
void foo(){...}
};
+ the typical moc code
But for this all source code needs to be scanned,
not only the headers.
Or you need to tell moc which instantiations to produce.
Since there is no way of doing that right now, moc cannot instantiate anything
for you. Then we go back to my assertion that moc works fine for the output
that it *can* produce. :-)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On 19.06.2012 11:28, Thiago Macieira wrote:
On terça-feira, 19 de junho de 2012 10.22.02, Peter Kümmel wrote:
Moc can understand template code just fine for the output it produces. The
problem is that the meta object format does not allow for signals and
slots
containing template parameters in their signature.
But moc could not produce code like this, so I would say it is not just
fine:
Let me emphasise what I said: it can read code just fine for the uses that it
makes. It can parse templates up to an extent. It does not parse what it
cannot use anyway.
- header:
templateclass T
struct A : public QObject
{
signals:
void aSignal(T);
public:
void foo(){...}
};
- somewhere:
Aint a;
- moc file/header:
template
struct Aint : public QObject
{
Q_QOBJECT
signals:
void aSignal(int);
// simple copy of code in base template
void foo(){...}
};
+ the typical moc code
But for this all source code needs to be scanned,
not only the headers.
Or you need to tell moc which instantiations to produce.
Yes, this would make things much simpler.
The only big change would be that a moc generated header
needs to be included:
foo.h:
templateclass T
struct A : public QObject
{ ...
// only defined for moc
Q_QOBJECT_SPECIALISATION(int
};
#include foo.moc.h
Since there is no way of doing that right now, moc cannot instantiate anything
for you. Then we go back to my assertion that moc works fine for the output
that it *can* produce. :-)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On 19.06.2012 11:04, Olivier Goffart wrote:
On Tuesday 19 June 2012 10:22:02 Peter Kümmel wrote:
On 19.06.2012 10:00, Thiago Macieira wrote:
On terça-feira, 19 de junho de 2012 09.51.32, Peter Kümmel wrote:
On 19.06.2012 09:11, Rene Jensen wrote:
Is this crazy talk? I would imagine that given a set of containers like
... hmm ... QSmartList, QSmartMap, QSmartHash inheriting from QObject
(yes, I know ... moc and templates bla bla - I could live with fixed
key/value-types if that's what it takes - java did before going
parametric),
Maybe there's a time moc embeds clang and can 'understand' template code.
Moc can understand template code just fine for the output it produces. The
problem is that the meta object format does not allow for signals and
slots
containing template parameters in their signature.
But moc could not produce code like this, so I would say it is not just
fine:
moc needs small adaptations, that's true. But here your example involve
specialisation of template, which i think is another level.
What would be possible with some addapation is
templatetypename T class A : public QObject { Q_OBJECT
signal: void someSignal(T);
};
///
Then moc should basically be adjusted to generate what it generates now, but
adding templatetypename T in front of everything, and some other small
adjustemnt
templatetypename T QMetaObject AT::staticMetaObject = { ... };
templatetypename T void AT::someSignal() {
QMetaObject::activate(this, staticMetaObject, 0); }
templatetypename T void AT::qt_metacall(...) {
...
case 0: someSignal(*reinterpret_castT*(*args[1]))
}
Not very complicated, but the other point is that then one should include the
moc everywhere.
And is it really worth it?
To make QObject THE base class within a framework it is necessary I think.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On segunda-feira, 18 de junho de 2012 23.58.47, Thiago Macieira wrote: Here's the current status of my endeavour: Update: QtDeclarative breaks horribly because qhashedstring_p.h uses QStringData, which has changed completely. Can someone please rewrite QHashedString not to use QStringData? Do not make any assumptions about QString's internals, since I'm changing it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On terça-feira, 19 de junho de 2012 11.42.10, Peter Kümmel wrote:
The only big change would be that a moc generated header
needs to be included:
foo.h:
templateclass T
struct A : public QObject
{ ...
// only defined for moc
Q_QOBJECT_SPECIALISATION(int
};
#include foo.moc.h
With the macro, there's no need to include the moc output.
Unless that moc.h file is a different one that contains a C++11 extern template
indication only, plus the necessary Q_DECL_IMPORT.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
Thiago Macieira wrote: Performance considerations: * ref() does two 1-bit tests before the atomic increment * deref() does one 1-bit test before the atomic decrement * needsDetach() does one 2-bit test and a check for the refcount's value I think these are the operations that can afford to be expensive. All of them are done where we're potentially i) allocating memory and copying data (e.g. unsharable data), ii) destroying elements and releasing memory (e.g. last owner), or iii) detaching for mutating data (e.g., shared data). needsDetach and condition iii) above is where we could potentially save some by skipping the checks altogether under fairly limited and user-controlled situations with the oft-mentioned ref-counted-but-not-checked base class. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On terça-feira, 19 de junho de 2012 12.01.49, Thiago Macieira wrote: On segunda-feira, 18 de junho de 2012 23.58.47, Thiago Macieira wrote: Here's the current status of my endeavour: Update: QtDeclarative breaks horribly because qhashedstring_p.h uses QStringData, which has changed completely. Can someone please rewrite QHashedString not to use QStringData? Do not make any assumptions about QString's internals, since I'm changing it. Turns out that QJsonValue did a similar hack, so I had to fix it. I think that that the solution I came up with, currently named QStringPrivate, will probably be enough. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
