[Development] are clangs 3.5 new builtin_operator_(new/delete) also useable for Qt Container optimization?
these new builtins allows clang to optimize operator new/delete
operations far better then before
__builtin_operator_new
__builtin_operator_delete
patches in review for clang 3.5
clang: http://reviews.llvm.org/rL210137
libc++: http://reviews.llvm.org/rL210211
the libc++ patch is very small and maybe the Qt container library
can also benefit from an clang specific specialization
#example 1
#include
#include
int main()
{
const std::vector a{1,2};
const std::vector b{4,5};
const std::vector ints
{
std::accumulate(a.begin(),a.end(),1),
std::accumulate(b.begin(),b.end(),2),
};
return std::accumulate(ints.begin(),ints.end(),100);
}
clang 3.4.1
main: # @main
pushq %rbp
pushq %r15
pushq %r14
pushq %rbx
pushq %rax
movl $8, %edi
callq operator new(unsigned long)
movq %rax, %r14
movabsq $8589934593, %rax # imm = 0x20001
movq %rax, (%r14)
movl $8, %edi
callq operator new(unsigned long)
movq %rax, %rbx
movabsq $21474836484, %rax # imm = 0x50004
movq %rax, (%rbx)
movl (%r14), %r15d
movl 4(%r14), %ebp
movl $8, %edi
callq operator new(unsigned long)
leal 1(%r15,%rbp), %ebp
testq %rax, %rax
movl %ebp, (%rax)
movl $11, 4(%rax)
je .LBB0_5
movq %rax, %rdi
callq operator delete(void*)
.LBB0_5:# %_ZNSt6vectorIiSaIiEED2Ev.exit25
testq %rbx, %rbx
je .LBB0_7
movq %rbx, %rdi
callq operator delete(void*)
.LBB0_7:# %_ZNSt6vectorIiSaIiEED2Ev.exit23
addl $111, %ebp
testq %r14, %r14
je .LBB0_9
movq %r14, %rdi
callq operator delete(void*)
.LBB0_9:# %_ZNSt6vectorIiSaIiEED2Ev.exit21
movl %ebp, %eax
addq $8, %rsp
popq %rbx
popq %r14
popq %r15
popq %rbp
ret
movq %rax, %rbp
movq %rbp, %rdi
callq _Unwind_Resume
movq %rax, %rbp
jmp .LBB0_14
movq %rax, %rbp
testq %rbx, %rbx
je .LBB0_14
movq %rbx, %rdi
callq operator delete(void*)
.LBB0_14: # %_ZNSt6vectorIiSaIiEED2Ev.exit15
testq %r14, %r14
je .LBB0_16
movq %r14, %rdi
callq operator delete(void*)
.LBB0_16: # %_ZNSt6vectorIiSaIiEED2Ev.exit
movq %rbp, %rdi
callq _Unwind_Resume
GCC_except_table0:
.byte 255 # @LPStart Encoding = omit
.byte 3 # @TType Encoding = udata4
.asciz "\266\200\200" # @TType base offset
.byte 3 # Call site Encoding = udata4
.byte 52 # Call site table length
.long .Lset0
.long .Lset1
.long .Lset2
.byte 0 # On action: cleanup
.long .Lset3
.long .Lset4
.long .Lset5
.byte 0 # On action: cleanup
.long .Lset6
.long .Lset7
.long .Lset8
.byte 0 # On action: cleanup
.long .Lset9
.long .Lset10
.long 0 # has no landing pad
.byte 0 # On action: cleanup
Ralph Smith patched clang/libc++
main: # @main
movl $115, %eax
retq
#example 2
#include
int main()
{
return std::string("hello").size();
}
clang 3.4.1
main: # @main
pushq %rbx
subq $32, %rsp
leaq 16(%rsp), %rdi
leaq 8(%rsp), %rdx
movl $.L.str, %esi
callq std::basic_string,
std::allocator >::basic_string(char const*, std::allocator
const&)
movq 16(%rsp), %rax
leaq -24(%rax), %rdi
movl std::basic_string,
std::allocator >::_Rep::_S_empty_rep_storage, %ecx
cmpq %rcx, %rdi
movl -24(%rax), %ebx
jne .LBB0_1
.LBB0_6:# %_ZNSsD1Ev.exit
movl %ebx, %eax
addq $32, %rsp
popq %rbx
ret
.LBB0_1:
addq $-8, %rax
movl $__pthread_key_create, %ecx
testq %rcx, %rcx
je .LBB0_3
movl $-1, %ecx
lock
xaddl %ecx, (%rax)
movl %ecx, 28(%rsp)
movl 28(%rsp), %ecx
jmp .LBB0_4
.LBB0_3:
movl (%rax), %ecx
leal -1(%rcx), %edx
movl %edx, (%rax)
.LBB0_4:#
%_ZN9__gnu_cxxL27__exchange_and_add_dispatchEPii.exit.i.i.i
testl %ecx, %ecx
jg .LBB0_6
leaq 24(%rsp), %rsi
callq std::basic_string,
std::allocator >::_Rep::_M_destroy(std::allocator const&)
jmp .LBB0_6
.L.str:
.asciz "hello"
Ralph Smith patched clang/libc++
main: # @main
movl $5, %eax
retq
the results of gcc and VS2013 optimizations are far away
from what clang can do with these patches
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Jul 16, 2014, at 1:45 PM, Poenitz Andre wrote: > Olivier Goffart wrote: >> Jędrzej Nowacki wrote: >> [...] What is wrong with string -> int or bytearray -> int? >>> >>> At the very least, _implicit_ conversions should not lose data, >>> i.e. a A a1; B b = a1; A a2 = b; round trip ideally should yield >>> a1 == a2. >>> >>> If I am ready to give up information, I'd like to need to say so >>> in the code explicitly. (And yes, part of the deed is done in the >>> core language, but even there compilers start to nag about it.) > >> André, QVariant conversions are not implicit, they are explicit. > > I am aware of that. I tried to answer the question of "What is wrong > with string -> int or bytearray -> int”. QVariant::operator== is not symmetric :( :( :( QDateTime dateTime = QDateTime::currentDateTime(); QTime time = dateTime.time(); qDebug() << (QVariant(dateTime) == QVariant(time)); qDebug() << (QVariant(time) == QVariant(dateTime)); --> false true > We admittedly left the original context here (and in other parts of the > discussion), but the question was posed in context that I read an > example of an conversion that one would always consider convenient > to have, and I started with "At the very least, _implicit.." supposedly > setting the context of the answer. > > Anyway. To summarize my position in the original context: QVariant > is as it is. It is convenient at times, and it is already too convenient > at times. "Easy type conversion" is a different use case than "Type > agnostic storage". QVariant does a bit of both, only the second one > has ever been useful _to me_, I have been bitten by the first. As > there are typically also more direct ways to convert types than to > pass through QVariant, I consider the possibility to do type conversion > through QVariant a mis-feature, and adding even more conversion > abilities would be a step into the wrong direction _for me_. This is > a personal opinion. > > Andre' -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Webkit2 /qt5.3.1 on EGLFS platform
Hello, Does anybody succeed to play webkit2/qt5.3.1 on any EGLFS platform? I failed on two (one mips, one arm) . As I dig more, I found two issues, both SIGBUS on QtWebProcess . The first one, i created a dirty patch, you can see [1] . Any suggestions/comments of this patch is appreciated, later I will try to push the change to codereview if the quality becomes good enough with your help. The second one I can't understand now and that's the major reason I write this mail. I have a gdb backtrace for arm platform in this case[2] ,could somebody point me what is the real issue ? I tried to force QtWebProcess to use offscreen QPA, same issue. Again, any suggestions regards to generic Webkit2 is appreciated. [1] https://gist.github.com/pluswave/5c064b5f2cc18413e6cd [2] https://gist.github.com/pluswave/8b3f2e25f6d1f53c7140 Best Regards, Zhang Zengbo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] are clangs 3.5 new builtin_operator_(new/delete) also useable for Qt Container optimization?
On Thursday 17 July 2014 10:27:39 Dennis Luehring wrote: > these new builtins allows clang to optimize operator new/delete > operations far better then before > > __builtin_operator_new > __builtin_operator_delete > > patches in review for clang 3.5 > clang: http://reviews.llvm.org/rL210137 > libc++: http://reviews.llvm.org/rL210211 > > the libc++ patch is very small and maybe the Qt container library > can also benefit from an clang specific specialization I'm afraid Qt containers can't fully enjoy those optimization: QArrayData::allocate which is used by most of the container is not inline. C++14 is allowing compiler to optimize allocation done with new or malloc (by removing them). But explicit call to "::operator new()" (used in allocators for example) are still not allowed to be optimized because the standard require them to be able to be replaced by the user. But Qt don't use custom allocators. According to grep, the only place where "operator new" is used directly in Qt is QSharedPointer[2]. And I believe it is better to change the code to call the normal new. (I'm not sure why it's done this way.) So there is no place in Qt where this __builtin_operator_new make sens. But thanks for the notification. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html [2] http://code.woboq.org/qt5/qtbase/src/corelib/tools/qsharedpointer_impl.h.html#_ZN15QtSharedPointer33ExternalRefCountWithCustomDeleter6createEPT_T0_PFvPNS_20ExternalRefCountDataEE -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Thursday 17 of July 2014 10:51:03 you wrote: > QVariant::operator== is not symmetric > > QDateTime dateTime = QDateTime::currentDateTime(); > QTime time = dateTime.time(); > > qDebug() << (QVariant(dateTime) == QVariant(time)); > qDebug() << (QVariant(time) == QVariant(dateTime)); > > --> > false > true We could make it symmetric, if you want. My recommendation is to not use the comparison at all. If you want more "features" of QVariant you can look into isNull() this is a perfect randomizer :P. The whole discussion took wrong direction. I didn't want to discuss QVariant API, which is not fixable, even Qt6 would not help, to much staff depends on it. Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] problem with configured scrolling, when building Qt from source
Hello together, in KDE I reverse my scrolling and all applications use the reversed scrolling, only those who are build with my build (5.3.1) of Qt are using the native scrolling of my system. If I build my applications with the prebuild libraries scrolling is working, the way its configured in KDE settings. Can someone please tell my if I have to install some package or do I have to add a special configure flag, when building Qt? My current configure flags are: ./configure -developer-build -opensource -nomake examples -nomake tests -opengl -confirm-license -plugin-sql-mysql -no-gtkstyle Thanks in advance Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Thursday 17 Jul 2014 13:28:10 Jędrzej Nowacki wrote: > On Thursday 17 of July 2014 10:51:03 you wrote: > > QVariant::operator== is not symmetric > > > > QDateTime dateTime = QDateTime::currentDateTime(); > > > > QTime time = dateTime.time(); > > > > qDebug() << (QVariant(dateTime) == QVariant(time)); > > qDebug() << (QVariant(time) == QVariant(dateTime)); > > > > --> > > false > > true > > We could make it symmetric, if you want. A equals operator that is not symetric is broken. Such a class cannot be reliably used in std nor qt containers. Or do you know which way around, QList::contains uses the equals operation? daniel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Thursday 17 July 2014 13:33:49 Daniel Teske wrote: > A equals operator that is not symetric is broken. Such a class cannot be > reliably used in std nor qt containers. Or do you know which way around, > QList::contains uses the equals operation? Note that none of the class which have a member operator== is symmetric. Most of the class had an operator== as a member in Qt4 but that was a design mistake. New classes should have a friend operator== instead. Example: qDebug() << (QUrl() == QString()); // true qDebug() << (QString() == QUrl()); // compilation error That's because QUrl has a bool QUrl::operator==(const QUrl&); Instead of bool operator==(const QUrl &, const QUrl&); The later is symmetric, but the former is not. This is also valid for operator< and related. (That was just to go a bit more out of topic :-)) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Thursday 17 of July 2014 13:33:49 Daniel Teske wrote:
> On Thursday 17 Jul 2014 13:28:10 Jędrzej Nowacki wrote:
> > On Thursday 17 of July 2014 10:51:03 you wrote:
> > > QVariant::operator== is not symmetric
> > >
> > > QDateTime dateTime = QDateTime::currentDateTime();
> > >
> > > QTime time = dateTime.time();
> > >
> > > qDebug() << (QVariant(dateTime) == QVariant(time));
> > > qDebug() << (QVariant(time) == QVariant(dateTime));
> > >
> > > -->
> > > false
> > > true
> >
> > We could make it symmetric, if you want.
>
> A equals operator that is not symetric is broken. Such a class cannot be
> reliably used in std nor qt containers. Or do you know which way around,
> QList::contains uses the equals operation?
The example above shows what happens in case of a missing conversion, in this
case QTime can be converted to QDateTime, but the QDateTime can not be
converted to the QTime. Fail.
The operator was / is / will be broken. Even if we make it symmetric, it will
remain conceptually broken. It should compare QVariants and then (maybe) the
wrapped value, while currently it tries a fuzzy comparison of the wrapped
value only. It should look more or less like that:
bool operator ==(const QVariant &left, const QVariant& right)
{
return left.userType() == right.userType() &&
!QMetaType::compare(left.constData(), rigth.constData(), left.userType());
}
To make it more ridiculous, currently it would not work as QMetType::compare
do not know about built-in types :P
There are few ways to fix it, sorted from the smallest impact on a user code
base to a-bomb size:
- Add conversion QDateTime -> QTime (Up to now only Olivier agreed with me
that it is ok to add a new conversions)
- If two QVaraints are not equal we can check if swapping left and right sides
helps. Inefficient, another behavior change and as odd as the current behavior.
Nothing to gain really.
- Always compare QVariants twice left to right and right to left. Terribly
inefficient, more sensible output. Big behavior change as most of comparison
would return false.
- Allow comparisons of the same types or if there is explicitly registered
comparisons otherwise return false. Completely different behavior then the
current one.
- Do not allow QVariant comparison, we can not support custom types if they do
not register conversion anyway so why bother.
Cheers,
Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Semantics of QState when state machine execution is stopped
On Sunday 06 July 2014 23:55:14 BogDan wrote: > [..] > > >> I presume that changing the semantics here (i.e. triggering > >> QAbstractState::onExited when the machine is stopped) isn't appropriate, > >> as it may break existing applications, but I'm not exactly sure. > > > >I think it would be far less risk of breaking existing applications to > >simply set active = false on all active states when the machine is > >stopped. Does that not address the problematic use case(s)? > It will be inconsistent, because when you stop a state machine the state > will become inactive but it remains entered ... activeChanged entered and > exited signals are describing the same thing: if the current state is > active or not. But when the state machine is stopped any active state can't > remain active. So, IMHO the fact that exited signal is not emitted when a > state machine is stopped is a bug and should be fixed. > > Yours, > BogDan. After some discussion between Brett, me and Bogdan, we concluded that the following approach is probably the best: - Don't change the semantics of QSM (i.e. don't trigger QAbstractState::onExited when the machine is stopped) - QAbstractState::active property stays 'true' in case the machine is stopped - QAbstractState::active is set to false as soon as the machine is restarted This behavior mirrors the semantics of QStateMachine::configuration. After the machine has stopped, QStateMachine::configuration still contains the set of last active states. Only when restarting the machine, the configuration is cleared. Plus, this approach cannot break existing applications. Review-request updated: https://codereview.qt-project.org/#/c/88596/ Greets -- Qt Developer Days 2014 • October 6 - 8 at BCC, Berlin • Save the dates! Kevin Funk | kevin.f...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. 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] Converting types in Qt
On Jul 17, 2014, at 2:38 PM, Jędrzej Nowacki wrote:
> On Thursday 17 of July 2014 13:33:49 Daniel Teske wrote:
>> On Thursday 17 Jul 2014 13:28:10 Jędrzej Nowacki wrote:
>>> On Thursday 17 of July 2014 10:51:03 you wrote:
QVariant::operator== is not symmetric
QDateTime dateTime = QDateTime::currentDateTime();
QTime time = dateTime.time();
qDebug() << (QVariant(dateTime) == QVariant(time));
qDebug() << (QVariant(time) == QVariant(dateTime));
-->
false
true
>>>
>>> We could make it symmetric, if you want.
>>
>> A equals operator that is not symetric is broken. Such a class cannot be
>> reliably used in std nor qt containers. Or do you know which way around,
>> QList::contains uses the equals operation?
>
> The example above shows what happens in case of a missing conversion, in this
> case QTime can be converted to QDateTime, but the QDateTime can not be
> converted to the QTime. Fail.
Actually, adding a conversion QTime -> QDateTime wouldn’t help, because that
conversion cannot “invent” the correct missing date information.
So, QVariant(dateTime) == QVariant(time) would still fail, because the date of
the datetime that is created when converting time->datetime will not be the
same as the original datetime.
In the presence of lossy conversions, you need to do conversions in both
directions to make operator== symmetric.
>
> The operator was / is / will be broken. Even if we make it symmetric, it will
> remain conceptually broken. It should compare QVariants and then (maybe) the
> wrapped value, while currently it tries a fuzzy comparison of the wrapped
> value only. It should look more or less like that:
>
> bool operator ==(const QVariant &left, const QVariant& right)
> {
> return left.userType() == right.userType() &&
> !QMetaType::compare(left.constData(), rigth.constData(), left.userType());
> }
>
> To make it more ridiculous, currently it would not work as QMetType::compare
> do not know about built-in types :P
>
> There are few ways to fix it, sorted from the smallest impact on a user code
> base to a-bomb size:
> - Add conversion QDateTime -> QTime (Up to now only Olivier agreed with me
> that it is ok to add a new conversions)
> - If two QVaraints are not equal we can check if swapping left and right
> sides
> helps. Inefficient, another behavior change and as odd as the current
> behavior.
> Nothing to gain really.
> - Always compare QVariants twice left to right and right to left. Terribly
> inefficient, more sensible output. Big behavior change as most of comparison
> would return false.
> - Allow comparisons of the same types or if there is explicitly registered
> comparisons otherwise return false. Completely different behavior then the
> current one.
> - Do not allow QVariant comparison, we can not support custom types if they
> do
> not register conversion anyway so why bother.
>
> Cheers,
> Jędrek
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
--
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Jul 17, 2014, at 1:28 PM, Jędrzej Nowacki wrote: > On Thursday 17 of July 2014 10:51:03 you wrote: >> QVariant::operator== is not symmetric >> >> QDateTime dateTime = QDateTime::currentDateTime(); >>QTime time = dateTime.time(); >> >>qDebug() << (QVariant(dateTime) == QVariant(time)); >>qDebug() << (QVariant(time) == QVariant(dateTime)); >> >> --> >> false >> true > > We could make it symmetric, if you want. My recommendation is to not use the > comparison at all. If you want more "features" of QVariant you can look into > isNull() this is a perfect randomizer :P. > The whole discussion took wrong > direction. I didn't want to discuss QVariant API, which is not fixable, even > Qt6 would not help, to much staff depends on it. Well, the discussion is still sort of the same (and sort of not). The original question was, if we can/should add new type conversions, and/or which kind of conversions these could be. I think the investigations here about the API and workings of QVariant give some hints on what an answer to that might be. There is no need to expose the brokenness of the API even more by adding conversions that trigger it. operator== would be less bad if there were only symmetric and lossless conversions, so do not introduce any additional lossy or asymmetric conversions. Also, the uses of QVariant::toString (&fromString), that we have found in Qt Creator ((de)serialization of QVariantMaps), definitely break if this conversion is *not* lossless (or not symmetric). "int <-> long” kind of conversions might be sort of ok-ish, since the actual conversion can still fail if the long doesn’t fit into int, i.e. for values that actually fit into both types the conversion is lossless, for values that do not fit into both types, the conversion fails in one direction, and is not possible to start with in the other direction. Since this can only be found out during runtime, I’d try to avoid that though, and definitely not put that into the extreme. I would avoid conversions between containers that do not have the exact same type. "QLinkedList <=> QVector” maybe, “QLinkedList <=> QVector” ... no. Do not add conversions that do not have a “canonical way” to do it, and which do not have a corresponding toXXX function without parameters in the corresponding types. The exception to the “canonical way" rule *might* be toString/fromString conversions, because of its usefulness. There is no canonical way to convert bool <-> string, but it might be useful for things like (de)serialization. (I’m not very convinced of toString conversion being very useful in the MVC context, actually, except maybe for quick-hack-debugging. For production you should be in better control of what you show to your user. I’m only half-convinced about its usefulness for (de)serialization.) Taking QString out of the rule has the disadvantage that it makes it harder if you actually want to hold string “data” in your variant (for which you would want saner conversion rules). Br, Eike -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Jul 17, 2014, at 3:14 PM, Ziller Eike wrote: > > On Jul 17, 2014, at 1:28 PM, Jędrzej Nowacki > wrote: > >> On Thursday 17 of July 2014 10:51:03 you wrote: >>> QVariant::operator== is not symmetric >>> >>>QDateTime dateTime = QDateTime::currentDateTime(); >>> QTime time = dateTime.time(); >>> >>> qDebug() << (QVariant(dateTime) == QVariant(time)); >>> qDebug() << (QVariant(time) == QVariant(dateTime)); >>> >>> --> >>> false >>> true >> >> We could make it symmetric, if you want. My recommendation is to not use the >> comparison at all. If you want more "features" of QVariant you can look into >> isNull() this is a perfect randomizer :P. > > >> The whole discussion took wrong >> direction. I didn't want to discuss QVariant API, which is not fixable, even >> Qt6 would not help, to much staff depends on it. > > Well, the discussion is still sort of the same (and sort of not). The > original question was, if we can/should add new type conversions, and/or > which kind of conversions these could be. I think the investigations here > about the API and workings of QVariant give some hints on what an answer to > that might be. > There is no need to expose the brokenness of the API even more by adding > conversions that trigger it. > > operator== would be less bad if there were only symmetric and lossless > conversions, so do not introduce any additional lossy or asymmetric > conversions. > Also, the uses of QVariant::toString (&fromString), that we have found in Qt > Creator ((de)serialization of QVariantMaps), definitely break if this > conversion is *not* lossless (or not symmetric). (As Marco mentioned, Qt Quick Designer also uses QVariant’s fuzzy/type-converting comparison, but there it also breaks if the conversion is lossy or not symmetric.) > "int <-> long” kind of conversions might be sort of ok-ish, since the actual > conversion can still fail if the long doesn’t fit into int, i.e. for values > that actually fit into both types the conversion is lossless, for values that > do not fit into both types, the conversion fails in one direction, and is not > possible to start with in the other direction. > Since this can only be found out during runtime, I’d try to avoid that > though, and definitely not put that into the extreme. > > I would avoid conversions between containers that do not have the exact same > type. "QLinkedList <=> QVector” maybe, “QLinkedList <=> > QVector” ... no. > > Do not add conversions that do not have a “canonical way” to do it, and which > do not have a corresponding toXXX function without parameters in the > corresponding types. > The exception to the “canonical way" rule *might* be toString/fromString > conversions, because of its usefulness. There is no canonical way to convert > bool <-> string, but it might be useful for things like (de)serialization. > (I’m not very convinced of toString conversion being very useful in the MVC > context, actually, except maybe for quick-hack-debugging. For production you > should be in better control of what you show to your user. I’m only > half-convinced about its usefulness for (de)serialization.) Taking QString > out of the rule has the disadvantage that it makes it harder if you actually > want to hold string “data” in your variant (for which you would want saner > conversion rules). > > Br, Eike > > -- > Eike Ziller, Senior Software Engineer - Digia, Qt > > Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] are clangs 3.5 new builtin_operator_(new/delete) also useable for Qt Container optimization?
On Thursday 17 July 2014 12:20:56 Olivier Goffart wrote: > But Qt don't use custom allocators. According to grep, the only place where > "operator new" is used directly in Qt is QSharedPointer[2]. And I believe > it is better to change the code to call the normal new. (I'm not sure why > it's done this way.) Because we need to split the memory allocation from the initialisation of the object. The memory is allocated for the object plus the 16 bytes required for the QSharedPointer internal data in one go. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Thu, Jul 17, 2014 at 02:36:22PM +0200, Olivier Goffart wrote: > On Thursday 17 July 2014 13:33:49 Daniel Teske wrote: > > A equals operator that is not symetric is broken. Such a class cannot be > > reliably used in std nor qt containers. Or do you know which way around, > > QList::contains uses the equals operation? > > Note that none of the class which have a member operator== is symmetric. > Most of the class had an operator== as a member in Qt4 but that was a design > mistake. New classes should have a friend operator== instead. > > Example: > > qDebug() << (QUrl() == QString()); // true > qDebug() << (QString() == QUrl()); // compilation error > > > That's because QUrl has a "because" is the bigger half of a red herring here. > bool QUrl::operator==(const QUrl&); > Instead of > bool operator==(const QUrl &, const QUrl&); > > The later is symmetric, but the former is not. The fact that the former is asymmetric is indeed not nice, already for esthetic reasons. But the fact that it actually _hurts_ is only due to the non-explicit QUrl(const QString &url, ParsingMode mode = TolerantMode) constructor. If that is not available, e.g. after #define QT_NO_URL_CAST_FROM_STRING, neither version compiles. That's symmetric, and good. > This is also valid for operator< and related. > > (That was just to go a bit more out of topic :-)) We are still on track. The topic is "free type conversion cause trouble", or "Why there shouldn't be more type conversions through QVariant". Andre' PS: Random side-track question: How comparable are values of type 'int' and 'QUrl' if one applies 'common sense'? I even accept answer related to non-0 int values only. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Thu, Jul 17, 2014 at 02:38:40PM +0200, Jędrzej Nowacki wrote: > On Thursday 17 of July 2014 13:33:49 Daniel Teske wrote: > > On Thursday 17 Jul 2014 13:28:10 Jędrzej Nowacki wrote: > > > On Thursday 17 of July 2014 10:51:03 you wrote: > > > > QVariant::operator== is not symmetric > > > > > > > > QDateTime dateTime = QDateTime::currentDateTime(); > > > > > > > > QTime time = dateTime.time(); > > > > > > > > qDebug() << (QVariant(dateTime) == QVariant(time)); > > > > qDebug() << (QVariant(time) == QVariant(dateTime)); > > > > > > > > --> > > > > false > > > > true > > > > > > We could make it symmetric, if you want. > > > > A equals operator that is not symetric is broken. Such a class cannot be > > reliably used in std nor qt containers. Or do you know which way around, > > QList::contains uses the equals operation? > > The example above shows what happens in case of a missing conversion, in this > case QTime can be converted to QDateTime, but the QDateTime can not be > converted to the QTime. Fail. The broad problem here is _too many_ conversions. In this case specifically the QDate-to-QDateTime conversion. > The operator was / is / will be broken. Even if we make it symmetric, it will > remain conceptually broken. It should compare QVariants and then (maybe) the > wrapped value, while currently it tries a fuzzy comparison of the wrapped > value only. It should look more or less like that: It does not have to remain broken. The only reason to not fix it right now are compatibility promises. A trivial solution (and one of the few correct ones) is to consider QVariants as equal if and only if they have identical type and their typed values are the same, according to a (proper) equivalence relation set up for this type. Of course one can come up with more elaborate schemes to set up equivalency classes like putting all integral type into one bucket. Some might even make sense. What won't work are chains of conversions int - QChar - QString - QStringList without a direct conversion from int to QStringList. > There are few ways to fix it, sorted from the smallest impact on a user code > base to a-bomb size: > - Add conversion QDateTime -> QTime (Up to now only Olivier agreed with me > that it is ok to add a new conversions) Not acceptable. This loses precision, and consequently can't be made transitive, i.e. there will be objects a, b, and c such that a == b, b == c, with a != c. > - If two QVaraints are not equal we can check if swapping left and right > sides > helps. Inefficient, another behavior change and as odd as the current > behavior. > Nothing to gain really. Not acceptable. Albeit ths would solve the symmetry problem, the transitivity problem remains. > - Always compare QVariants twice left to right and right to left. Terribly > inefficient, more sensible output. Big behavior change as most of comparison > would return false. Not acceptable. The ransitivity problem remains. We are looking in the right direction, though: Things are less often equal than it appears to be "convienient". > - Allow comparisons of the same types or if there is explicitly registered > comparisons otherwise return false. Completely different behavior then the > current one. [*] Acceptable for Qt 6 (and for Qt 5 as opt-in, due to the changed behaviour) if and only if the "explicitly registered comparison functions" don't violate any of the symmetricy/transitive/reflexive requirements. > - Do not allow QVariant comparison, we can not support custom types if they > do > not register conversion anyway so why bother. Acceptable for Qt 6 (and for Qt 5 as opt-in, due to the changed behaviour), but overshooting. QVariants of the same type with usable comparison for that type are perfectly comparable. The solution is [*]. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
