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 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)
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
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
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*
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
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
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
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
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
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
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
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.
--
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
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
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
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*
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
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
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
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*
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
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
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
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
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
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
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
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
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,
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
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
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
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,
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
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
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 ...
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
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
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
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
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
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
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
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
45 matches
Mail list logo
