8000 Prefix local variable message in CHECK macros with UnitTest_ by JonChesterfield · Pull Request #116 · unittest-cpp/unittest-cpp · GitHub
[go: up one dir, main page]

Skip to content

Prefix local variable message in CHECK macros with UnitTest_ #116

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

Merged
merged 1 commit into from
Jul 16, 2016
Merged

Prefix local variable message in CHECK macros with UnitTest_ #116

merged 1 commit into from
Jul 16, 2016

Conversation

JonChesterfield
Copy link
Contributor

to reduce the risk of name collisions with application code

…e the risk of name collisions with application code
@JonChesterfield
Copy link
Contributor Author

I'm not entirely sure what the whitespace conventions are for this project, so I've compensated for the increase in variable length when changing from message to UnitTest_message by removing nine of the trailing spaces in each case.

@pjohnmeyer pjohnmeyer self-assigned this Jul 16, 2016
@pjohnmeyer pjohnmeyer added this to the 1.6.2 milestone Jul 16, 2016
@pjohnmeyer
Copy link
Member

Sorry for the long delay.

I have no problem with the changes and I'm going to merge this pull, but I'm curious what the "risk of name collisions" is? If I'm not mistaken, the variables are in their own scopes and should be hiding variables of the same name in user code. If you don't mind, I'd like to know the problem you had as a result of the name collision.

@pjohnmeyer pjohnmeyer merged commit c7a9e7f into unittest-cpp:master Jul 16, 2016
@JonChesterfield
Copy link
Contributor Author

Hey,

Thanks for merging. Iirc it was to placate MSVC warning about one variable (hiding|shadowing) another.

Editing the macro was preferable to dropping the variable shadowing warning as it found an interesting bug elsewhere in our code. I don't remember gcc or clang complaining, but I might be wrong about that.

Thanks

@pjohnmeyer
Copy link
Member

That's what I expected. Knowing this might inform a "better" solution somewhere down the line. Thanks for the PR!

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
0