Re: [Interest] QMap and thread-safe.
On Fri, Jul 26, 2013 at 11:57 AM, Sze Howe Koh szehowe@gmail.comwrote:
On 26 July 2013 12:57, Mandeep Sandhu mandeepsandhu@gmail.com wrote:
On Thu, Jul 25, 2013 at 9:04 PM, Thiago Macieira
thiago.macie...@intel.com
int inc(int foo)
{
return foo++; // not atomic anywhere
Why? Because of the way foo is being received in this function, i.e by
reference (so any operation on foo has and added level of indirection)?
Because that's simply a shorthand for 3 separate operations. See
http://stackoverflow.com/questions/10503737/is-increment-an-integer-atomic-in-x86
Well, thats why I asked the previous question, i.e if foo is of machine
word size or less, _then_ will the compiler generate the atomic fetch and
add instruction or will that have to be done explicitly by the programmer?
I understand that any (programming) language statement that results in
multiple processor instructions will not be atomic (I'm not considering
explicit lock being done in the program), since instruction from other
processes/threads can be scheduled in-between.
I guess I better write a small program and see for myself what are the
instructions generated for it! :)
-mandeep
Regards,
Sze-Howe
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QMap and thread-safe.
On sexta-feira, 26 de julho de 2013 10:27:28, Mandeep Sandhu wrote: Doing both at the same time is not atomic anywhere unless you use specialised fetch-and-add instructions, which the compiler never generates for you. By both here, you mean fetch AND add, right? Right And in x86 such a operation (add) on a machine word is atomic w/o using special instructions? ADD is atomic, but usually an atomic increment is done with LOCK ADD, to ensure that no other processor is trying to access the same memory location. The compiler will never generate a LOCK. In other words, ADD is atomic for single-CPU operations. As soon as there's more than one CPU, it isn't enough. Eg if I had code like this running on a x86 machine: short foo; foo++; Will the increment be atomic or do I have to explicitly make it so by doing something extra? It will be atomic for something running in the same thread, such as a signal handler. It will probably be atomic for multi-CPU too. But you shouldn't do it. return foo++; // not atomic anywhere Why? Because of the way foo is being received in this function, i.e by reference (so any operation on foo has and added level of indirection)? Because it's fetch-and-add. Two operations. There's no guarantee of atomicity. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QMap and thread-safe.
On sexta-feira, 26 de julho de 2013 12:09:43, Mandeep Sandhu wrote: Well, thats why I asked the previous question, i.e if foo is of machine word size or less, _then_ will the compiler generate the atomic fetch and add instruction or will that have to be done explicitly by the programmer? And I had answered that in the email you replied to, asking the question: Doing both at the same time is not atomic anywhere unless you use specialised fetch-and-add instructions, which the compiler never generates for you. the compiler never generates for you -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Qt 4.8, MetaType
Good day! In the book C++ GUI Programming with Qt 4 (2nd Edition) there's not much information about QMetaType and the Qt's internal subsystem. There's the statement at qRegisterMetaTypehttp://qt-project.org/doc/qt-5.0/qtcore/qmetatype.html#qRegisterMetaType which says ...After a type has been registered, you can create and destroy objects of that type dynamically at run-time. To use the type T in QVarianthttp://qt-project.org/doc/qt-5.0/qtcore/qvariant.html, using Q_DECLARE_METATYPEhttp://qt-project.org/doc/qt-5.0/qtcore/qmetatype.html#Q_DECLARE_METATYPE() is sufficient. To use the type T in queued signal and slot connections, qRegisterMetaTypeT() must be called before the first connection is established . After reading qmetatype.cpp and qmetatype.h everything Q_DECLARE_METATYPE does is specialization of QMetaTypeId template structure. QVariant inside the static function compare in qvariant.cpp uses QMetaType::IsRegistered method which in fact checks if the type was registered in customTypes using either qRegisterMetaType or QMetaTypeIdT::qt_metatype_id() after Q_DECLARE_METATYPE. Why is it sufficient then to use Q_DECLARE_METATYPE for any template using the declared type? qRegisterMetaType only puts the type to be registered into customTypes vector registering constructor and destructor for the type with an ID (optionally an user may register operator and operator for the type). Why is it needed to use queued signal and slot connections and QObject::property() API? Furthermore, Q_OBJECT is required for a type using slots/signals. QObject does not meet CopyConstructible requirement for using either Q_DECLARE_METATYPE or qRegisterMetaType. I'd like to ask you to clearify this. Thank you. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QMap and thread-safe.
On Fri, Jul 26, 2013 at 12:30 PM, Thiago Macieira thiago.macie...@intel.com wrote: On sexta-feira, 26 de julho de 2013 10:27:28, Mandeep Sandhu wrote: Doing both at the same time is not atomic anywhere unless you use specialised fetch-and-add instructions, which the compiler never generates for you. By both here, you mean fetch AND add, right? Right And in x86 such a operation (add) on a machine word is atomic w/o using special instructions? ADD is atomic, but usually an atomic increment is done with LOCK ADD, to ensure that no other processor is trying to access the same memory location. The compiler will never generate a LOCK. In other words, ADD is atomic for single-CPU operations. As soon as there's more than one CPU, it isn't enough. Got it. Thanks for clearing this up! -mandeep ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] DBus on X11 using Qt5
On sexta-feira, 26 de julho de 2013 08:11:18, Ramakanthreddy Kesireddy wrote:
Yes Reply.type() is QDBusMessage::ReplyMessage
Ok. So what were the contents of the reply? Please print Reply.signature().
If you want more information, please do this:
1) add outside your function:
namespace QDBusUtil { QString argumentToString(const QVariant arg); }
2) add inside your function:
qDebug() QDBusUtil::argumentToString(Reply.arguments()[0]);
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 4.8, MetaType
On sexta-feira, 26 de julho de 2013 09:22:07, Alexander Syvak wrote: Why is it sufficient then to use Q_DECLARE_METATYPE for any template using the declared type? Because those template functions you referred to will do the registration for you if necessary, before accessing the information that is stored with the registration (namely, the functions to create and destroy). qRegisterMetaType only puts the type to be registered into customTypes vector registering constructor and destructor for the type with an ID (optionally an user may register operator and operator for the type). Why is it needed to use queued signal and slot connections and QObject::property() API? Because at that point there is no code that will do the registration for you. It needs to access the constructor and destructor and all it knows at that point is the name of the type (as found in the meta object). This is fixed in Qt 5.0. Furthermore, Q_OBJECT is required for a type using slots/signals. QObject does not meet CopyConstructible requirement for using either Q_DECLARE_METATYPE or qRegisterMetaType. Correct. That is not a question. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] App. is running after an exception is thrown.
Hello,
after calling w.show() there's method redefined void event_dlg::showEvent(
QShowEvent *). In this method there's an exception thrown. The process does
not terminate.
Can anyone througly explain why is the job running after calling either
close() of the only one and thus the last window (event_dlg w) or quit() of
the QApplication a?
#include event_dlg.h
#include QApplication
#include QMessageBox
#include QDebug
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
event_dlg w;
try
{
w.set_config_file(./events.xml);
w.show();
}
catch ( std::runtime_error e )
{
//QMessageBox msgBox;
//msgBox.setText(e.what());
//msgBox.exec();
//qDebug() w.close();
a.quit();
}
return a.exec();
}
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Fwd: Qt 4.8, MetaType
About the last statement. If an object uses internally slots and signals, it should inherit QObject. QObject is not copyconstructible, thus, the descendant as well. If the object requires queued signals or QObject::property() API then qRegisterMetaType() should be called, which requires CopyConstructible property of the object. It's a cycle here. Where is a misunderstanding? 2013/7/26 Thiago Macieira thiago.macie...@intel.com On sexta-feira, 26 de julho de 2013 09:22:07, Alexander Syvak wrote: Why is it sufficient then to use Q_DECLARE_METATYPE for any template using the declared type? Because those template functions you referred to will do the registration for you if necessary, before accessing the information that is stored with the registration (namely, the functions to create and destroy). qRegisterMetaType only puts the type to be registered into customTypes vector registering constructor and destructor for the type with an ID (optionally an user may register operator and operator for the type). Why is it needed to use queued signal and slot connections and QObject::property() API? Because at that point there is no code that will do the registration for you. It needs to access the constructor and destructor and all it knows at that point is the name of the type (as found in the meta object). This is fixed in Qt 5.0. Furthermore, Q_OBJECT is required for a type using slots/signals. QObject does not meet CopyConstructible requirement for using either Q_DECLARE_METATYPE or qRegisterMetaType. Correct. That is not a question. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] App. is running after an exception is thrown.
On sexta-feira, 26 de julho de 2013 20:19:58, Alexander Syvak wrote: after calling w.show() there's method redefined void event_dlg::showEvent( QShowEvent *). In this method there's an exception thrown. The process does not terminate. Please consider all event handlers and slots (when called via the signal-slot mechanism) as nothrow / noexcept. If you throw or fail to catch something, it's undefined behaviour. From that point on, your application is doomed. It will most likely crash. But, as you discovered, it may do something else. Fix the problem by catching the exception. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Fwd: Qt 4.8, MetaType
On sexta-feira, 26 de julho de 2013 20:20:57, Alexander Syvak wrote: About the last statement. If an object uses internally slots and signals, it should inherit QObject. Correct. QObject is not copyconstructible, thus, the descendant as well. Correct. If the object requires queued signals or QObject::property() API then qRegisterMetaType() should be called, which requires CopyConstructible property of the object. It's a cycle here. No, it isn't. Where is a misunderstanding? You're confusing the the object that contains properties (that derives from QObject and is not copyable) with the type of the property. The type of properties are what we call value-type: they are default- contructible, publicly destroyable, copyable, movable and often implicitly shared. For those reasons, they don't derive from QObject. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] App. is running after an exception is thrown.
I caught and threw again. 2013/7/26 Thiago Macieira thiago.macie...@intel.com On sexta-feira, 26 de julho de 2013 20:19:58, Alexander Syvak wrote: after calling w.show() there's method redefined void event_dlg::showEvent( QShowEvent *). In this method there's an exception thrown. The process does not terminate. Please consider all event handlers and slots (when called via the signal-slot mechanism) as nothrow / noexcept. If you throw or fail to catch something, it's undefined behaviour. From that point on, your application is doomed. It will most likely crash. But, as you discovered, it may do something else. Fix the problem by catching the exception. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] App. is running after an exception is thrown.
QCoreApplication::quit(), being an alias to QCoreApplication::exit(0),
does nothing outside an event loop which in your case is started afterwards.
On Jul 26, 2013 10:20 PM, Alexander Syvak alexander@gmail.com wrote:
Hello,
after calling w.show() there's method redefined void event_dlg::showEvent(
QShowEvent *). In this method there's an exception thrown. The process
does not terminate.
Can anyone througly explain why is the job running after calling either
close() of the only one and thus the last window (event_dlg w) or quit() of
the QApplication a?
#include event_dlg.h
#include QApplication
#include QMessageBox
#include QDebug
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
event_dlg w;
try
{
w.set_config_file(./events.xml);
w.show();
}
catch ( std::runtime_error e )
{
//QMessageBox msgBox;
//msgBox.setText(e.what());
//msgBox.exec();
//qDebug() w.close();
a.quit();
}
return a.exec();
}
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] App. is running after an exception is thrown.
So the a.exec() enters the event loop. Then the handler showEvent(QEvent*)
is executed. The std::runtime_error is thrown out of the handler to the
point of the previous call.
The exception is caught inside the main() function. The dialog is thus not
shown, but start executing again.
2013/7/26 Constantin Makshin cmaks...@gmail.com
QCoreApplication::quit(), being an alias to QCoreApplication::exit(0),
does nothing outside an event loop which in your case is started afterwards.
On Jul 26, 2013 10:20 PM, Alexander Syvak alexander@gmail.com
wrote:
Hello,
after calling w.show() there's method redefined void event_dlg::showEvent
(QShowEvent *). In this method there's an exception thrown. The process
does not terminate.
Can anyone througly explain why is the job running after calling either
close() of the only one and thus the last window (event_dlg w) or quit() of
the QApplication a?
#include event_dlg.h
#include QApplication
#include QMessageBox
#include QDebug
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
event_dlg w;
try
{
w.set_config_file(./events.xml);
w.show();
}
catch ( std::runtime_error e )
{
//QMessageBox msgBox;
//msgBox.setText(e.what());
//msgBox.exec();
//qDebug() w.close();
a.quit();
}
return a.exec();
}
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] App. is running after an exception is thrown.
On sexta-feira, 26 de julho de 2013 21:40:42, Alexander Syvak wrote: I caught and threw again. Catch and don't rethrow. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Support for multiple 'out' parameters in qdbusxml2cpp
I've observed that qdbusxml2cpp doesn't emit the QMetaCall that would
forward a D-Bus method-call message from the adaptor along to the business
logic class that provides slots to implement all the various methods.
E.g., if I have:
method name=Foo
arg name=inValue direction=in type=s/
arg name=outValue1 direction=out type=s/
arg name=outValue2 direction=out type=s/
/method
the adaptor code for this method ends up looking like:
...
public Q_SLOTS:
QString MyInterfaceAdaptor::Foo(const QString inValue, QString
outValue2)
{
// handle method call MyInterfaceAdaptor.Foo
//return static_castYourObjectType *(parent())-Hello(inValue,
outValue);
}
Is there a design reason behind this? I examined the source to
qdbusxml2cpp, and it doesn't give any rationale why this type of call isn't
marshaled through a QMetaObject::invokeMethod() call the same as the
others. Passing the additional 'out' parameters as by-ref variables would
seem straightforward enough.
-Matt
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] App. is running after an exception is thrown.
From the documentation for QCoreApplication::exit:
After this
function has been called, the application leaves the main event loop and
returns from the call to exec(). The exec() function returns returnCode.
If the event loop is not running, this function does nothing.
QCoreApplication::quit Equivalent to calling
QCoreApplication::exit(0). Thus your call to a.quit() is doing nothing.
Therefore, there is nothing telling the event loop to stop once it
starts.
Please NOTE: These commands stop the event loop return to the
caller. They do not immediately exit the application or the caller. So
if you move this call inside the event loop, you will need to return out
of the caller.
Karl
On 2013-07-26 14:17, Alexander Syvak wrote:
So the a.exec() enters the event loop. Then the handler
showEvent(QEvent*) is executed. The std::runtime_error is thrown out of
the handler to the point of the previous call.
The exception is
caught inside the main() function. The dialog is thus not shown, but
start executing again.
2013/7/26 Constantin Makshin
cmaks...@gmail.com
QCoreApplication::quit(), being an alias to
QCoreApplication::exit(0), does nothing outside an event loop which in
your case is started afterwards.
On Jul 26, 2013 10:20 PM,
Alexander Syvak alexander@gmail.com wrote:
Hello, after
calling w.show() there's method redefined void
event_dlg::showEvent(QShowEvent *). In this method there's an exception
thrown. The process does not terminate.
Can anyone througly explain
why is the job running after calling either close() of the only one and
thus the last window (event_dlg w) or quit() of the QApplication a?
#include event_dlg.h
#include QApplication
#include QMessageBox
#include QDebug
int main(int
argc, char *argv[])
{
QApplication a(argc, argv);
event_dlg w;
try
{
w.set_config_file(./events.xml);
w.show();
}
catch ( std::runtime_error e )
{
// QMessageBox
msgBox;
// msgBox.setText(e.what());
//
msgBox.exec();
// qDebug() w.close();
a.quit();
}
return a.exec();
}
___
Interest mailing
list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest [1]
___
Interest mailing
list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest [1]
___
Interest mailing
list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest [1]
Links:
--
[1]
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Support for multiple 'out' parameters in qdbusxml2cpp
On sexta-feira, 26 de julho de 2013 15:27:21, Matt Hoosier wrote:
I've observed that qdbusxml2cpp doesn't emit the QMetaCall that would
forward a D-Bus method-call message from the adaptor along to the business
logic class that provides slots to implement all the various methods.
E.g., if I have:
method name=Foo
arg name=inValue direction=in type=s/
arg name=outValue1 direction=out type=s/
arg name=outValue2 direction=out type=s/
/method
the adaptor code for this method ends up looking like:
...
public Q_SLOTS:
QString MyInterfaceAdaptor::Foo(const QString inValue, QString
outValue2)
{
// handle method call MyInterfaceAdaptor.Foo
//return static_castYourObjectType *(parent())-Hello(inValue,
outValue);
}
Is there a design reason behind this? I examined the source to
qdbusxml2cpp, and it doesn't give any rationale why this type of call isn't
marshaled through a QMetaObject::invokeMethod() call the same as the
others. Passing the additional 'out' parameters as by-ref variables would
seem straightforward enough.
Hi Matt
According to the source code, the comment comes from:
if (parentClassName.isEmpty())
cs //;
else
cs ;
and it later shows:
if (parentClassName.isEmpty())
cs static_castYourObjectType *(parent())-;
else
cs parent()-;
The presence of YourObjectType in the output you pasted to us confirms the
analysis.
The reason why it's commented out is that you didn't tell qdbusxml2cpp what
the parent class type is. It can't write the code that will make the call
without that information.
You should pass the -l argument to qdbusxml2cpp, which sets the parent class
name. (option -c was taken to mean the name of the class that qdbusxml2cpp is
generating and -p was taken to mean the name of the file for the proxy class,
which is the old name for what we now call the interface class).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] App. is running after an exception is thrown.
The show event is synchronous, i.e. it's not queued and showEvent() is
called almost directly from show()'s internals. That means things in your
code happen in this order:
1) you call show();
2) at one place inside show() there is a call to
QCoreApplication::sendEvent() which in turn calls your showEvent();
3) your showEvent() throws an exception;
4) control goes to the catch block which calls QCoreApplication::quit();
5) QCoreApplication::exit() sees there's no active event loops and returns
without doing anything;
6) you call QCoreApplication::exec() which starts an event loop.
The exception prevents show() from finishing its work so your windows
remains invisible. But it still exists (it wasn't shown, but nobody closed
it either), so exec() happily runs the event loop, not knowing the
application is in an unusable state.
On Jul 27, 2013 12:18 AM, Alexander Syvak alexander@gmail.com wrote:
So the a.exec() enters the event loop. Then the handler showEvent(QEvent*)
is executed. The std::runtime_error is thrown out of the handler to the
point of the previous call.
The exception is caught inside the main() function. The dialog is thus not
shown, but start executing again.
2013/7/26 Constantin Makshin cmaks...@gmail.com
QCoreApplication::quit(), being an alias to QCoreApplication::exit(0),
does nothing outside an event loop which in your case is started afterwards.
On Jul 26, 2013 10:20 PM, Alexander Syvak alexander@gmail.com
wrote:
Hello,
after calling w.show() there's method redefined void event_dlg::
showEvent(QShowEvent *). In this method there's an exception thrown.
The process does not terminate.
Can anyone througly explain why is the job running after calling either
close() of the only one and thus the last window (event_dlg w) or quit() of
the QApplication a?
#include event_dlg.h
#include QApplication
#include QMessageBox
#include QDebug
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
event_dlg w;
try
{
w.set_config_file(./events.xml);
w.show();
}
catch ( std::runtime_error e )
{
//QMessageBox msgBox;
//msgBox.setText(e.what());
//msgBox.exec();
//qDebug() w.close();
a.quit();
}
return a.exec();
}
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] App. is running after an exception is thrown.
On sábado, 27 de julho de 2013 00:58:19, Constantin Makshin wrote:
The exception prevents show() from finishing its work so your windows
remains invisible. But it still exists (it wasn't shown, but nobody closed
it either), so exec() happily runs the event loop, not knowing the
application is in an unusable state.
Let me be clear: the application is in *undefined* state. The QtGui code is not
exception safe, which means the exception unwind process did any number of bad
things to the internal state and left things in possibly very bad conditions.
The correct version of the code is:
QApplication a(argc, argv);
event_dlg w;
try
{
w.set_config_file(./events.xml);
}
catch ( std::runtime_error e )
{
//QMessageBox msgBox;
//msgBox.setText(e.what());
//msgBox.exec();
//qDebug() w.close();
return 1;
}
w.show();
return a.exec();
There MUST NOT be any try { } block around w.show(). That function CANNOT
throw, so do not make it throw against its wishes. If something causes it to
throw by accident, your application should be allowed to crash, so it creates
a core dump for you to analyse in the debugger.
If you catch the exception, debugging will be harder. More importantly, if you
catch the exception, you MUST NOT show a dialog. Do not use QtGui again. If an
exception unwound the stack in QtGui, then QtGui is now in an undefined state,
which means your application could do worse things than crash.
Also, please note that in Qt 5 an exception unwinding QtGui will cause a
crash, no questions asked, before your catch handler gets called.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Support for multiple 'out' parameters in qdbusxml2cpp
Hi Thiago,
Thanks for replying. I'd traced through the logic in qdbusxml2cpp's source
as well before posting, and saw the same chunk of logic that determines
whether to emit only the placeholder.
Okay, I agree that I could pin down the parent class name and get automatic
dispatch wired up. But I'd like to understand why the normal
QMetaObject::invokeMethod() dispatch isn't allowed in this case (that is,
more than one 'out' parameter). At about line 1026 of a recent Git copy, we
have:
bool usingInvokeMethod = false;
if (parentClassName.isEmpty()
method.inputArgs.count() = 10
method.outputArgs.count() = 1)
usingInvokeMethod = true;
if (usingInvokeMethod) {
...
// emits code to do QMetaObject::invokeMethod(parent(), ...);
...
} else {
// The behavior you cited earlier, where either parent()-method()
is directly
// called or the placeholder YourObjectType code is used
}
The test up top there forbids the generated code from ever using
QMetaObject::invokeMethod() if there's more than one output argument for
the D-Bus method. Why's that? The MOC doesn't generally have any trouble
plumbing up calls using arbitrarily many arguments, including non-const ref
types that would be used to pass down out parameters.
-Matt
On Fri, Jul 26, 2013 at 3:45 PM, Thiago Macieira
thiago.macie...@intel.comwrote:
On sexta-feira, 26 de julho de 2013 15:27:21, Matt Hoosier wrote:
I've observed that qdbusxml2cpp doesn't emit the QMetaCall that would
forward a D-Bus method-call message from the adaptor along to the
business
logic class that provides slots to implement all the various methods.
E.g., if I have:
method name=Foo
arg name=inValue direction=in type=s/
arg name=outValue1 direction=out type=s/
arg name=outValue2 direction=out type=s/
/method
the adaptor code for this method ends up looking like:
...
public Q_SLOTS:
QString MyInterfaceAdaptor::Foo(const QString inValue, QString
outValue2)
{
// handle method call MyInterfaceAdaptor.Foo
//return static_castYourObjectType *(parent())-Hello(inValue,
outValue);
}
Is there a design reason behind this? I examined the source to
qdbusxml2cpp, and it doesn't give any rationale why this type of call
isn't
marshaled through a QMetaObject::invokeMethod() call the same as the
others. Passing the additional 'out' parameters as by-ref variables would
seem straightforward enough.
Hi Matt
According to the source code, the comment comes from:
if (parentClassName.isEmpty())
cs //;
else
cs ;
and it later shows:
if (parentClassName.isEmpty())
cs static_castYourObjectType *(parent())-;
else
cs parent()-;
The presence of YourObjectType in the output you pasted to us confirms
the
analysis.
The reason why it's commented out is that you didn't tell qdbusxml2cpp what
the parent class type is. It can't write the code that will make the call
without that information.
You should pass the -l argument to qdbusxml2cpp, which sets the parent
class
name. (option -c was taken to mean the name of the class that qdbusxml2cpp
is
generating and -p was taken to mean the name of the file for the proxy
class,
which is the old name for what we now call the interface class).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QXmlStreamReader and qDebug()
Here're 2 code snippets with different outputs: #1 qDebug() pxml-start_element() pxml-name(); qDebug() pxml-read_element_text(); #2 qDebug() pxml-start_element() pxml-name() pxml-read_element_text(); pxml is a pointer to the class incapsulating the QXmlSteamReader object. start_element() = isStartElement() name() = name().toString() read_element_text() = readElementText() The first snippet yields true NAME CONTENT The second snippet yields false NAME Why? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QXmlStreamReader and qDebug()
On sábado, 27 de julho de 2013 00:04:36, Alexander Syvak wrote: qDebug() pxml-start_element() pxml-name(); qDebug() pxml-read_element_text(); #2 qDebug() pxml-start_element() pxml-name() pxml-read_element_text(); Why? The functions aren't called in the same order. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Support for multiple 'out' parameters in qdbusxml2cpp
On sexta-feira, 26 de julho de 2013 16:35:24, Matt Hoosier wrote: Okay, I agree that I could pin down the parent class name and get automatic dispatch wired up. But I'd like to understand why the normal QMetaObject::invokeMethod() dispatch isn't allowed in this case (that is, more than one 'out' parameter). Because invokeMethod cannot pass non-const references. That's a limitation of QMetaObject::invokeMethod. Or, at least, it was a limitation when this code was written back in Qt 4.2 days. Looking at the Q_ARG macro and its classes today, looks like I fixed it for Qt 4.7: http://gitorious.org/qt/qt/commit/67cd8cc97104e38f2e3bae03b2a4c3575c73c461 https://bugreports.qt-project.org/browse/QTBUG-8592 It appears to be testing this particular code: // make the INVOKABLE call without a return type QDBusVariant arg3(hello), arg4(world); QVERIFY(QMetaObject::invokeMethod(iface, ping_invokable, Q_RETURN_ARG(QDBusVariant, retArg), Q_ARG(QDBusVariant, arg3), Q_ARG(QDBusVariant, arg4), Q_ARG(QDBusVariant, retArg2))); Which is exactly your case. So apparently it is now supported, but I've never got around to updating the generator, especially because all serious users of the generator pass the -l parameter. The test up top there forbids the generated code from ever using QMetaObject::invokeMethod() if there's more than one output argument for the D-Bus method. Why's that? The MOC doesn't generally have any trouble plumbing up calls using arbitrarily many arguments, including non-const ref types that would be used to pass down out parameters. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QXmlStreamReader and qDebug()
Inside the qdebug.h qDebug() creates QDebug object with QTextStream object encapsulated. operator is evaluated from the left to the right each time returning QDebug object. Why would there be any randomness? And start_element() with name() should not influent on the execution reult of the read_element_text() only because they are queries. 2013/7/27 Thiago Macieira thiago.macie...@intel.com On sábado, 27 de julho de 2013 00:04:36, Alexander Syvak wrote: qDebug() pxml-start_element() pxml-name(); qDebug() pxml-read_element_text(); #2 qDebug() pxml-start_element() pxml-name() pxml-read_element_text(); Why? The functions aren't called in the same order. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QXmlStreamReader and qDebug()
Il 27/07/2013 00:51, Alexander Syvak ha scritto: operator is evaluated from the left to the right each time returning QDebug object. That's only half of the story. When in your code you have something like this: qDebug() a b c; that will get parsed by the compiler into something like this: operator(operator(operator(qDebug(), a), b), c); Now, what's the order of evaluation of the parameters of topmost operator call? That's it: C++ leaves it to the implementation. Under x86, for various reasons (*), arguments gets evaluated right to left and pushed to the stack in that order. That means c gets evaluated before b, and b before a. If a, b, c are function calls that modify a global state, your results will be... unexpected. Which is what you're experiencing. (*) for instance, for being able to implement variadic functions more easily: the known parameters are on the top of the stack. Hope this helps, -- Join us at Qt Developer Days 2013! - https://devdays.kdab.com Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QStackedWidget and QListView
There's a model inherited from the QAbstractListModel. The dialog lay out
is implemented as following
main_layout_raw_ptr = new (std::nothrow) QVBoxLayout;
create_toolbar();
main_layout_raw_ptr-addLayout(toolbars_layout_raw_ptr);
create_central_layout();
main_layout_raw_ptr-addLayout(central_layout_raw_ptr);
this-setLayout(main_layout_raw_ptr);
The central layout is QHBoxLayout with two widgets: QListView and
QStackedWidget.
central_layout_raw_ptr = new (std::nothrow) QHBoxLayout;
listview_raw_ptr = new (std::nothrow) QListView;
listview_raw_ptr -setModel(list_model_raw_ptr);
central_layout_raw_ptr-addWidget(listview_raw_ptr );
stacked_pages_raw_ptr = new (std::nothrow) QStackedWidget;
central_layout_raw_ptr-addWidget(stacked_pages_raw_ptr, 1); //
stretch factor is set
connect(listview_raw_ptr ,SIGNAL(currentRowChanged(int)),
stacked_pages_raw_ptr, SLOT(setCurrentIndex(int)) );
When the dialog is shown the next function body is executed
emit beginResetModel();
try
{
obs = psr.parse(events_src_file);
}
catch ( std::runtime_error )
{
emit endResetModel();
throw;
}
emit endResetModel();
However, the result is [image: Встроенное изображение 1]
Where is a mistake?
p.PNG___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
