On sexta-feira, 28 de dezembro de 2012 09.28.50, André Somers wrote: > > How do you think about defining all signals/callbacks as copies of QSignal > > delegate class? This class must provide: 1. Template header for setting > > signal`s prototype. > > 2. Overloaded "=" operator for adding callback references to list. > > References point to methods of classes. 3. Control for destroying objects > > that contain connected callback functions. 4. "emit()" function for > > calling all connected callback functions from the list. > Again: what is the benefit? What does it solve? What drawbacks does it have?
By the way, here are two more requirements that people haven't put forth yet. The first is an absolute requirements, one without which your solution cannot even be considered. The second is a loose requirement. The first requirement is the ability to add a new signal to an existing public class without breaking binary compatibility. If you don't understand what binary compatibility is, please read [1] and make sure you *understand* it. The second is source compatibility with the existing codebase of Qt-based applications. If you're proposing something that requires porting effort, then your solution needs to provide that much of a technical benefit to offset the effort and hassle in changing over hundreds of millions of lines of code. [1] http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ (it's also the first hit on Google for "binary compatibility c++" and the second for "binary compatibility", right after the Wikipedia link) -- 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
