Skip to content

Misc small cleanups#311

Closed
jjuhl wants to merge 6 commits intotexus:1.xfrom
jjuhl:misc-small-cleanups
Closed

Misc small cleanups#311
jjuhl wants to merge 6 commits intotexus:1.xfrom
jjuhl:misc-small-cleanups

Conversation

@jjuhl
Copy link
Contributor

@jjuhl jjuhl commented Feb 7, 2026

Hi Texus

Here's another small batch of small cleanups for you to consider :-)

Kind regards
Jesper Juhl

jjuhl added 6 commits February 5, 2026 17:05
Don't put nanosvg functions into the global namespace in a header
file, it'll polute the global namespace for all users of that header.
If fclose() fails, something is wrong, don't just carry on as if
nothing happened but report the error by throwing an exception.
The header files make no direct use of these includes, so they should
not be there. If implementation files need the headers they should
include them directly.
@texus
Copy link
Owner

texus commented Feb 8, 2026

Some feedback on 2 of your commits. I will cherry-pick the others and close this PR in a moment.

Avoid global names in header files

The global tgui::priv::nsvg... names have a reason to exist. When TGUI_USE_SYSTEM_NANOSVG is 1, a nanosvg.h file that isn't bundled with TGUI will be included. This is a C header, so it's functions are global. Your changes in src/SvgImage.cpp wouldn't compile when TGUI_USE_SYSTEM_NANOSVG is set because tgui::priv:: does not exist in that case.
The namespace thing is bit of a hack to avoid duplicate symbols in case TGUI uses it's bundled nanosvg.h and your own project would also use that library.

Note that the TGUI/extlibs/Include... header files are helper files to include dependencies. They exist so that a bunch of preprocessor code doesn't need to exist in every source file that needs that dependency. They are not meant to be included by the user, so they usually don't polute much. In this particular case, IncludeNanoSVG.hpp is only included in src/SvgImage.cpp.

Simplify some code by using std::any_of/std::all_of

I'm not used to using these functions, so I personally find the code slightly harder to read. That's just lack of experience with them though, I do believe it is good to use them and I should probably learn to use them more myself.

However, (and maybe it's just because I'm not used to them), I feel like it's wrong to use these functions when the body has side effects. I know that these functions will still execute the body sequentially, but I feel like any_of and all_of should only be used if the code COULD be parallelized in the future. So I don't really like the any_of call in TreeView.cpp because the call to markNodesDirty is a side-effect.

I have less of a problem with all_of in tests/Focus.cpp: the lambda only returns true or false without doing anything else.
I still have a small personal preference for a normal loop here because I'm not used to code like that were the lambda is more than one line, but I wouldn't mind if you changed more code to be like that.

I'm not merging the commit now because of the any_of call in TreeView.cpp, but if a future PR contains the all_of call in tests/Focus.cpp then I would definitely merge it.

@texus texus closed this Feb 8, 2026
@jjuhl
Copy link
Contributor Author

jjuhl commented Feb 8, 2026

Thanks a lot for your feedback. I''ll include the all_of change in a future PR and I'll keep the other feedback in mind.

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.

2 participants