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

Fix and modernize listener<> #2139

Merged
merged 2 commits into from
Jan 8, 2024
Merged

Conversation

lmoureaux
Copy link
Contributor

Commit d1f50af broke the listener<> template in a subtle way: the destructor wouldn't remove listeners from the set because dynamic_cast to a derived type returns nullptr in a destructor. This caused a segfault upon saving map images.

In order to solve both the warning that lead to the commit and the new bug, change the set of instances to hold listener* instead of A*, and use dynamic_cast in invoke since the A objects are still valid there.

While I was there, I changed invoke() to be a variadic template. It wasn't one because the code originally had to support C++03.

Commit d1f50af broke the listener<> template
in a subtle way: the destructor wouldn't remove listeners from the set because
dynamic_cast to a derived type returns nullptr in a destructor. This caused a
segfault upon saving map images.

In order to solve both the warning that lead to the commit and the new bug,
change the set of instances to hold listener<A>* instead of A*, and use
dynamic_cast in invoke since the A objects are still valid there.

While I was there, I changed invoke() to be a variadic template. It wasn't one
because the code originally had to support C++03.
@lmoureaux lmoureaux requested a review from jwrober January 6, 2024 00:26
@lmoureaux
Copy link
Contributor Author

Backport required - or at least revert the equivalent of d1f50af in stable

@jwrober jwrober added the back-port back-port candidate label Jan 6, 2024
Copy link
Collaborator

@jwrober jwrober left a comment

Choose a reason for hiding this comment

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

Looks good. Do we need to worry about the warning from the macOS CI?

@blabber
Copy link
Collaborator

blabber commented Jan 7, 2024

Looks good. Do we need to worry about the warning from the macOS CI?

I see these in FreeBSD too. This is nothing to worry about in my opinion. The cause is that macOS and FreeBSD use clang/LLVM as the default compiler.

One could conditionalize the warning using something like this, I am not sure if it is worth it though:

#if defined(__GNUC__) && !defined(__clang__)
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
#endif

This simplifies the user interface and removes a clang warning about it being
potentially uninitialized.

See longturn#2139.
@lmoureaux
Copy link
Contributor Author

Looks good. Do we need to worry about the warning from the macOS CI?

Further improving the code helped removing the warning.

@lmoureaux lmoureaux requested a review from jwrober January 8, 2024 00:10
@jwrober jwrober merged commit 9ef87d4 into longturn:master Jan 8, 2024
20 checks passed
lmoureaux added a commit that referenced this pull request Jan 20, 2024
This simplifies the user interface and removes a clang warning about it being
potentially uninitialized.

See #2139.
lmoureaux added a commit to lmoureaux/freeciv21 that referenced this pull request Mar 17, 2024
This simplifies the user interface and removes a clang warning about it being
potentially uninitialized.

See longturn#2139.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
back-port back-port candidate
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants