-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Interconnect: enable connecting stateful lambdas #63
[WIP] Interconnect: enable connecting stateful lambdas #63
Conversation
@mosra not sure if I should request against |
|
Hi, thanks a lot for your contribution! First things first:
Against
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 |
Previously, it was only possible to connect non-capturing lambdas. This should allow all lambdas to be connected through use of std::function
bfa2699
to
32c2116
Compare
Codecov Report
@@ 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 Continue to review full report at Codecov.
|
Seems to work but currently induces overhead with non-capturing lambdas
however, there is still an open problem of unresolved linkage..
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? |
I think I know where the problem is, the function pointer / lambda overload of connect() needs to be done a bit differently. I have some ideas and will look into this tomorrow -- ping me again in case I forget ;) |
@mosra any updates? I am happy to give it another try, but this seems like less related to the code and more to linker/dll export, which might take too much time for me to dive into.. |
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 |
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?