Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[WIP] Interconnect: enable connecting stateful lambdas #63
Previously, it was only possible to connect non-capturing lambdas. This should allow all lambdas to be connected through use of std::function.
i.e. this was not possible to do before:
This might lead to a drop in performance because of the added indirection of std::function. If this is a concern, it would probably be possible to find a SFINAE way to keep the old direct cast variant where applicable, and use the new pattern, however this would mean more complicated code. Also, modern compilers/STL implementations of std::function might be smart enough to detect and optimize the state-less case anyways?
Hi, thanks a lot for your contribution!
First things first:
Yeah, you need to first install to some location which is on the PATH and then run the tests, that works.
Now, for the actual code -- sorry to say that, but I can't accept code that uses
A counter-suggestion: there's
Hopefully my suggestion is clear enough, unfortunately right now I don't have enough time to flesh out a concrete implementation.
Hi, thanks for the feedback! Sure, I understand your concerns - std::function is neither optimal regarding regarding compile-time or runtime, this was just the fastest way I could see to get stateful lambdas working, so I wanted to get your feedback on it.
I understand your suggestion, it was what I was looking to do initially, but the std::function solution seemed a simpler first shot at the problem. I will look into getting it done using the
@@ Coverage Diff @@ ## master #63 +/- ## ======================================== + Coverage 97.61% 100% +2.38% ======================================== Files 80 1 -79 Lines 5451 336 -5115 ======================================== - Hits 5321 336 -4985 + Misses 130 0 -130
Ok, so I gave it another try but it seems like it's not as simple as I thought.
to be honest, I am unsure what to make of that, any suggestions?
So! This made my hair grey
To begin with, the internals of the Interconnect library were quite old and shitty (lots of heap allocations, virtual calls and other indirections) and quite inflexible to extend any further so the first thing I wanted to do was rework those to make them easier to add new features to. That's now done (took me almost a week, argh) and it opens the door to new possibilities such as connecting signals to signals, passing the emitter object as a parameter to the slot, combined member / lambda slots and so on. These will be added later if I get the time, for now they live in the fractal of TODO lists.
To ensure I'm actually improving the performance, I added a benchmark for the original code only to discover that
Besides that, the rework made me realize that virtual calls are not so slow after all, so while the reworked version is ~30% faster in shooting signals overall, most of the gains are due to everything else removed, moving away from virtual calls actually made the actual call slightly slower in debug (I have a bunch of ideas how this could get improved, but later.)
Finally, while doing final testing I realized signals across shared object boundaries got broken by the recent introduction of
If you are interested, original benchmark is in 0b185b3 and the reworked version (supporting stateful lambdas, general function objects as well as