Christian Boos <[EMAIL PROTECTED]> writes:
> |The proposed implementation differs from the existing ones in several
> |ways:
> |
> |1. Signals and slots are regular member functions. The only
> | requirement is that the classes which will implement signals and
> | slots must inherit from a common 'Relay' class, hence the name of
> | the library. Because signal and slots are regular member
> | functions, their usage is type-safe, and this safeness is ensured
> | at compile-time.
This first feature looks quite nice, this way there's no special syntax
for signals and callbacks. Hmm, how does this make difference between
emit and normal function call? (does functions used for emitting signals
need to do something special?) (sorry, only took quick look into it...)
> |2. The static type-checking is provided by templates and there's no
> | need for a preprocessor.
> |
> |3. The connectivity mechanism between signals and slots is open and
> | can be extended. Some examples of extensions are provided, like
> | providing default arguments at connection time, connectivity
> | between signals and regular functions, and more...
one extensions that has been found usefulk with gtk-- is extra arguments
given at connection time. (== passing data from point where connection
is made to the callback -- usually its constant data that determines which
button or menuitem has been pressed. Reduces number of callbacks people
need to use..) (for harmony this probably is not that important, qt uses
other ways to go over it -- see qt's menu connection code)
> |5. The signal/slot communications support an asynchronous mode,
> | facilitating real-time responsiveness when writing GUIs.
> |
> |6. Lastly, this implementation is meant to [be] resource friendly and fast
> | (thanks to the STL).
> But for now, what's of primary interest for me is what you think of
> the Relay++ library. It will still be time to discuss the details of
> integration later.
it looks again different approach to same problem. (maybe someone
should make a web page listing all known methods for implementing
typesafe callbacks :) The way of using memberfunction pointers as
signal identity looked nice idea.
> (*) This leads me to a general remark. Qt has been designated in the
> early 90 (am I right?), and since then, the C++ language has evolved
> quite much. I found that many things in Qt's design are now obsolated
> by what modern C++ can do (rtti, the string-based signal/slots,
> and the ad-hoc collections come to mind).
btw, why is connect() in relay++ as global function? it could well be inside
some class... member templates would allow that - this is something gtk--
couldnt do because of gcc2.7.2.
> Speaking of that, can you tell me if the priority scheme found in
> the GTK+ mechanism and not in the Qt one (hence not in the Relay++
> one) is really useful?
I dunno... Guess its not well enough known feature and has rarely been
used.
--
-- Tero Pulkkinen -- [EMAIL PROTECTED] --
