Skip to content
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

function pointers for signal-slot connections in effects system #10

Merged

Conversation

Be-ing
Copy link

@Be-ing Be-ing commented Dec 29, 2018

Qt 5 allows using function pointers for signal-slot connections instead of the hacky old SIGNAL and SLOT macros. The new syntax allows compile time type checking and IDEs can make sense of it. No more typos breaking connections!

@Be-ing Be-ing mentioned this pull request Dec 29, 2018
14 tasks
@kshitij98 kshitij98 merged commit b9605cc into kshitij98:effects_refactoring Jan 2, 2019
@kshitij98
Copy link
Owner

Ohh great, Thank you for the pull request!

Copy link

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can improve the Lambda readability.

// pointer syntax if the slot has more parameters than the signal, so use a lambda
// to hack around this limitation.
connect(m_pControlMetaParameter, &ControlObject::valueChanged,
this, [=](double value){slotEffectMetaParameter(value);} );
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefere to explicit list the copied values. Here it is [this] I think.
Can we also explicit add the second parameter and remove the default?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a bit confused by C++'s lambda capturing feature. What is the benefit of listing specific variables when you can simply specify to capture whatever you need? Is it just to make the captured variables explicit?

Copy link
Author

@Be-ing Be-ing Jan 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can tell, the only downside of default captures is the possibility of accidentally capturing more than intended.

https://stackoverflow.com/questions/6181464/do-c11-lambdas-capture-variables-they-dont-use

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me [this] is more easy to read [=]. In case of a longer function it helps to protect the namespace and tells if we use a deep copy or not. On the other hand since there is no real downside. I don't mind.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I'll use this when it is the only captured parameter in the future. I'm okay leaving it how it is here though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants