On Friday 24 Oct 2008 9:07:32 pm [email protected] wrote:
> But even if the docs would state that "the order of slot execution" is in
> the "order of connection" I would feel uncomfortable if my design had to
> rely on that *implicit* implementation detail.
> I mean if you are sure that you are connecting only 4 signals - and only
> those 4 signals! - and the corresponding slots have to be called in that
> and that order, and you connect them "statically" in one place (in some
> c'tor which is only called once during application lifetime or so), you
> could probably live with that.
> But my experience shows that as soon as an application becomes a bit more
> complex signal/slot handling can very quickly become very complicated to
> understand! ("One signal triggering a slot, triggering another slot which
> triggers another signal...", or the same slot called multiple times,
> because with each little change the model emits a signal, ...)
> Adding to that the fact that signal/slots can be *dynamically*
> connected/disconnected at runtime, how would you make sure that no other
> code has "connected that slot which was meant to be connected *after* your
> slot which you are about to connect"? Etc.
> Trying to debug something like that is likely to become a nightmare. Why?
> Because you are using *implicitly* the fact that slots are called in the
> order of connection. But if you connect from different places in code... uh
Real time systems IMHO are about being deterministic. So if its not clear at
design time how many slots would be connected and the impact of doing so then
it probably cannot be considered a real time. Yet, i cannot dispute your point
of view. From the library point of view all i think one can expect is a
guaranteed deterministic behavior.
To unsubscribe - send a mail to [email protected] with
"unsubscribe" in the subject or the body.
List archive and information: http://lists.trolltech.com/qt-interest/