They use templates like Signal0<>, Signal1<T1>, Signal2<T1,T2>, etc. with fixed argument length instead of a more uniform solution like variadic templates.
The code in the library is pretty old and I suppose that an update with regards to C++11/14/17 would make it much better in every regard.
When the original article was written (and I remember reading it many, many moons ago) variadic templates were not yet available. And this project seems to have been last updated 4 years ago, so a lot of boilerplate templates is understandable.
For DSPs, there's typically only a single, proprietary compiler available, and supporting the latest C++ standards isn't high priority for the companies making them.
The author of this has been a long time contributor to D and brought these ideas (and many other things) to the language. He's probably the biggest reason D's CTFE (compile time function evaluation) is as powerful as it is, having done most of the implementation.
Yes (a shameful plug :)), I've used macros to generate code for different number of arguments for std::function like lib for pre-C++11 compilers (back in 2009): https://github.com/zura-kh/yaf.Function
As fleitz says, std::function can do more. It can accept any callable. The delegate is restricted to just calling functions. In particular, it means that the client can't bind any extra parameters which can be really useful.
That said, popular implementations of std::function employ small object optimizations so the usescases that delegate supports doesn't incur heap allocations. I would guess that delegate has a slight upper hand when it comes to call performance. I really doubt the difference would matter when used in GUI programming.
'Class template std::function is a general-purpose polymorphic function wrapper. Instances of std::function can store, copy, and invoke any Callable target -- functions, lambda expressions, bind expressions, or other function objects, as well as pointers to member functions and pointers to data members.'
This clearly does more than the OPs code and therefore has more complexity.
I had a ~ 6 month stint using Qt, after coming from iOS/OSX development. I found it to be a really cumbersome mechanism, particularly when concurrency was involved. I feel like there is a lot of momentum around functional reactive. Anyone know of a comparison between this and reactive approaches?
They are a useful mechanism for linking different parts of a program without having to couple objects together. OOP can lead to a lot of inflexibility, but historically has been the most obvious mechanism in C++ for one object to learn about what another object is doing: pass a pointer to itself, etc. But this often requires inheritance, polymorphism, virtual interfaces, a number of idioms that can complicate this basic requirement. Signals and slots allow the objects to not know anything about each other, not store pointers to each other, be more or less isolated, except for this one little connection between them that is otherwise anonymous to both.
Observer pattern. Say you have some event that occurs, and some objects that want to know about it. You make a signal and connect some observers to it. When you fire the signal the observers receive some parameters and do their calculations.
Why it's interesting alternative: regular observer pattern make observed code depend (at compile time) on the observing code. Signals/slots remove this dependency, and allow for external configuration of these.
It's a dependency injection mechanism when you think about it.
Someone posts a link to A and immediately there is a comment - "How is it better than B? How is it different from C?" You know what, bud, if you know about B and C, excellent. Why don't you take a look at A and do everyone a favor and answer your own question. Otherwise it sound like a lazy-ass highbrow dismissal - "Pfft, A? Why bother? There is B, for chrissake, that even the last imbecile here is familiar with."
Please try and make a sliver of effort when commenting on other people's work.
Because my time is limited and I would like to know why I should spend time evaluating it, instead of using a battle tested library that exists since late 90's and that follows modern C++.
If the OP only wants to learn how to do it, or to build its portfolio for a possible job interview, it is fair enough and I don't need to bother with it.
If the author wants to do a kick-ass replacement of libsigc++, then it is probably worth my expensive time to look into it.
Everyone's time is limited, whether it's useful to you (or not), only you can say. You are basically implying that the time of other people is less valuable than yours when you say "please tell me why I must look at it".
i'll respectfully disagree. it's very useful if somebody who has used both (or one but with good understanding of the other) could comment exactly what are the pros and cons of both solutions; to put it differently, why you should use one instead of the other.
Do you check all the libraries and programming languages yourself, or do you rely on the opinion of others via blogs, books, magazine articles, comments in forums like HN?
Regardless of why you said it, you could've worded in a more civil way. Compare -
How is this better than Xyz?
to
How does this compare to Xyz?
It's one character longer, but it doesn't automatically imply that the original submission is a crap not worthy even a shortest glimpse. Unless of course the purpose of your comment was indeed to show that you are the royalty of the programming world whose time is very expensive.
I love asking that question, because usually somebody chimes in with deep understanding of the relevant domain that I don't have and can't get unless I'm using it daily.
For example, recently someone linked to Dolphin smalltalk, and I asked how it was different than Pharo - I'm not an expert in either, and the answer was greatly illuminating.
Also, this kind of question usually leads to me looking at other items related to the thing posted that I was unaware of. I don't think it's a bad question at all. Hell, sometimes the author comes in to explain it!
The code in the library is pretty old and I suppose that an update with regards to C++11/14/17 would make it much better in every regard.