Increase compiler warning levels and associated code changes

[benalexau]

Thanks for Better Enums. It's incredibly useful.

Some projects wishing to include enum.h might be following the advice of enabling all available compiler warning flags (eg C++ Coding Standards by Herb Sutter and Andrei Alexandrescu, Item #1, "Compile cleanly at high warning levels"). Such projects currently need to either modify enum.h or use #pragm directives to disable warnings for that file.

This PR modifies the example and test Makefile to enable all available warning flags, along with associated code changes to comply with the resulting compiler warnings. This allows enum.h to be directly used in projects without editing or #pragma directives. The test cases pass and the examples execute without error.

[aantron]

Hi, Ben, and thank you for the first pull request. It's good to see the library getting usage :)

I'm strongly in favor of what you have done. I had actually forgotten that there are many flags not included in -Wall.

At the moment, I have a messy topic branch that is considerably different from master. I haven't merged any of the changes into master for a while because they result in non-trivial divergence from the documentation. I am still new to GitHub. What's the right thing to do in this case? Apply the changes myself to the extent possible, and credit you with git commit --author? I do have a private devel branch that could be published, but the topic branch that I'm working on is yet another branch. It rewrites a lot of the same files as this pull request. I wouldn't want to show it in its current state, as it has an extremely messy commit history that I intend to squash.

Thanks again!

[benalexau]

If you're happy with the changes, I'd suggest to merge this PR into the current master so other users can obtain a more warning level friendly enum.h that remains compatible with the current documentation. This also lets you more easily merge those changes you wish to preserve into your local topic branch. Adding the extra compiler flags to your local topic branch will be useful as it will highlight warning flags etc as you go about your refactoring.

[aantron]

Thanks. Let me give them a proper review, especially the #pragma.

I am indeed now planning to more meticulously enable warning flags for each compiler in my topic branch.

[aantron]

This is caused by a mistake on my part. operator = should be "normal", i.e. have return type const _eat_assign& and return *this.

[aantron]

If you don't mind, I will merge the edits you made to silence the warnings into master, except for the #pragma, and make sure credit on the commit is to you. Is this the right thing to do, or is the custom to have the submitter always update the pull request? In the latter case, I think this should be squashed first.

[benalexau]

@aantron, thanks. I have made the changes you requested (ie removed Makefile warning flag additions, squashed commits, avoided use of #pragma in enum.h). If you can take a look at the updated commit, I am happy to make further changes to assist.

[aantron]

@benalexau, thanks – it looks good. The only request I have is that you change the commit message, since this now doesn't add any flags, just makes sure the code will compile if people do add them.

[benalexau]

Commit message modified.

[aantron]

Thank you :)

[benalexau]

Congratulations on your first pull request cycle. I hope there will be many more! :-)

[aantron]

@benalexau thanks for helping me with it :) I have one last question – I tried the web merging UI despite reservations and now I have your commit coming off master and then getting merged right back into it in the history. Is that what people want to see, or this is a problem of GitHub? I prefer to turn this into a straight line and push -f the fixed master.

[benalexau]

Normally the "merge" message gets its own commit. I personally agree it looks ugly. You also get these a lot with even git pull if you don't use --rebase. I see you have done a push -f already to fix it up, though. :-)

[aantron]

Yeah, I'm going to shoot for having a "clean" history for as long as possible :) Thanks for all your help. Have a good whatever time of day it is, guessing morning :)