> I'd still like to emphasize that it's much easier to make sync API of > async one rather then do the reverse. IMHO that single argument should > be enough to decide in favour of async API.
And how would you do such a thing easily? Assuming we are talking about Qt signal/slot asynchronous APIs those are a real pain to turn into a synchronous API without ending up in a horrible mess of nested QEventLoops that sometimes abort for no obvious reason (they do when the inner event loop has no reason to quit but one further out does). There are ways of implementating asynchronous APIs that do not have this problem of course but Qt's usual way of implementing them is not among those as far as I can tell as a regular Qt user. -- Mit freundlichen Grüßen, Matthias Hörmann fon: +49 (0) 521 - 329647-29 fax: +49 (0) 521 - 329647-40 email: [email protected] --------------- saltation GmbH & Co. KG | Niederwall 43 | 33602 Bielefeld Sitz Bielefeld | Amtsgericht Bielefeld HRA 15344 Persönlich haftende Gesellschafterin: saltation Beteiligungs-GmbH | Niederwall 43 | 33602 Bielefeld Sitz Bielefeld | Amtsgericht Bielefeld HRB 39339 Geschäftsführer: Daniel Brün --------------- _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
