In the hope that jules will find the time to fix these soon, I’m sharing with the community the fix for quite a lot of annoying and trivial warnings in the JUCE codebase I use.
These are fixes for warnings I get when building JUCE in Xcode with the LLVM compiler.
I keep a fairly “high-but-not-paranoid” number of warning flags enabled, just to be sure that my code is not prone to some hard-to-track bugs that should have been evident if only the proper warning was raised.
I wonder why jules himself does not enable those flags (I mean something frankly useful, like cast warnings or hidden symbol warnings), but that’s subjet for another whole discussion topic.
For those interested, here are the fixes:
As you may have noticed, I have decided to create my own fork of JUCE on github, tightly updated with the changes made on the JUCE official tip, and with some commits to fix such things as these warnings. I plan to add more in the future, that will be posted in this topic as well for those that are interested.
Ideally, I’d like this to be more streamlined for those that want to incorporate these changes into their JUCE repositories, but I’m relatively new to GitHub and I have to properly understand the workflow involved with exchanging changes between forks. Feel free to advice on this subject!
This is probably because -Wall does not actually enable them all. These in particular are triggered enabling the warning about “Hidden Local Variables” in the Xcode project settings.
Just out of curiosity, why do you just “occasionally” enable them?
Well, I don’t want to leave them enabled in the demo projects, so I usually turn them on in Xcode, and then forget that the changes get overwritten when I re-save them with the introjucer. I should probably crank them up in my private projects, but TBH although it’s quite therapeutic to sit and clean them up, I don’t remember ever actually finding a bug that way, so I’m not as paranoid as I used to be.
Well, as a developer that has to mantain projects that have already their warning flags set, it is very painful when JUCE is being updated and new warnings slip in. Simply ignoring them taking them for granted comlpetely misses the purpose of warnings altogether.
Oh, I’m not at all disagreeing, and I’ve always been a bit of a warnings nazi too.
I’ve always compiled with maximum warnings in MSVC, but got frustrated with doing it in GCC because there was never a way of selectively turning them off in specific files or sections of code. But now that more recent GCC and LLVM provide pragma control, I should probably start getting a bit more pedantic about it again.
There’s nothing wrong with initialising structs as { 0 }… Until everyone has c++11 support, I think that’s the officially correct thing to do. In fact, I wouldn’t be confident that old compilers will actually clear the structure if you just use {}, they may just leave it uninitialised.
good point. I was thinking about a #define that evaluates to { } when C++11 support is detected, and to { 0 } when is not… but that’s probably too much.
