-
Notifications
You must be signed in to change notification settings - Fork 91
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
Namespace for globals? #1468
Labels
proposal
A code/feature outline proposal
Comments
We've been starting to use namespaces a bit more in recent PRs (see #1415 and the recent derivatives changes, for example) and I think it would be great to expand this effort. As you've noted, by itself this could break code but there are ways to avoid this. I can think of (at least) two ways we could manage this in the interim:
|
Implemented by #1470. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Would it be a good idea to put the global variables defined in
globals.hxx
(mesh
anddump
) into a namespace likebout::globals
?I've come across bugs a few times caused by parts of the library using the global
mesh
when they should have been using a local one.If we put
using namespace bout::globals
intophysicsmodel.hxx
then user code could use the global namespaces transparently and (once #1464 is merged) theusing
statement would not propagate into any library code exceptphysicsmodel.hxx/cxx
. This would help root out any remaining unintentional uses of the global variables in the library code, and places that we do want them (like default arguments) can use e.g.bout::globals::mesh
to avoid any possibility of name conflicts.The text was updated successfully, but these errors were encountered: