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
[Development] Compiling current qt5 git version with MSVC2010
While building the current qt5 git version I get several failures from idc.exe with Invalid allocation size and a very large number, which seems to be the debug value for uninitialized varibles. I debugged one of those occurences and found line 1128 (f) in qaxserver.cpp: int argc; (void)new QApplication(argc, 0); I think argc should be initialized. Best regards, Helmut ___ 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
[Development] templates as QObjects
After the noise here real code: https://qt.gitorious.org/~syntheticpp/qt/qt4/commit/c1b839494d90e8c1a93b0dd2e08a2a365095d89f Based on Qt 4.8.2. moc creates a header when it finds a template, if not then nothing changes. (It builds Qt with the patch, but it's a hack in the parser) In summary Fooint foo1; Fooint foo2; Foodouble foo3; // works QObject::connect(foo1, SIGNAL(asignal(T)), foo2, SLOT(aslot(T))); // this should be possible, but string matching fails // no problem in Qt5 QObject::connect(a, SIGNAL(asignal(int)), foo1, SLOT(aslot(T))); // this should not be possible, but it runs because of the (void*) casts in the background // maybe catched in Qt5 QObject::connect(foo1, SIGNAL(asignal(T)), foo3, SLOT(aslot(T))); It's only an experiment, to see what could be done without using clang. Maybe I bring it up at the QtCS. Peter ___ 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] buildsystem branches (about to be) integrated
Oswald Buddenhagen said: moin, the buildsystem branch of qtbase is currently being integrated. this is ~120 commits worth of qmake project file fixes and cleanups. there are some changes to how modularization (in particular configure tests) is handled, and cross-building should be supported without hacks finally. the immediate impact: - lots of build scripts which employ various hacks will instantly break. don't panic and (mostly) just delete some code from them. use configure -xplatform spec -sysroot root make as you would intuitively expect. don't play tricks with funny qmake and make invocations. - the other modules will spit out lots of warnings now. *DON'T* do anything about them for now. i have patches prepared for all modules already. i will explicitly add the module owners to the reviews. *don't* stage anything yourself. once my patches are through, there will be still some warnings left. you'll be invited to fix them at this point. - some build configurations will work even worse than before until everything is integrated. the only variants which are expected to be safe are developer builds without -prefix and module-by-module builds with -prefix. catch me on IRC if something breaks for you and no obvious solution seems to help. but remember that not every breakage is due to this branch being integrated. ;) The qtbase merge has caused examples and tests to be silently disabled in all Linux and Mac CI builds. That is fixed by https://codereview.qt-project.org/29088 . Please refrain from staging risky changes until that is integrated. Windows builds and projects other than qtbase seem to be unaffected. ___ 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
