Re: namespaces, class libraries, and VERY large projects
"Alan McKenney" <alan_mckenney1@yahoo.com> writes:
(I think most programmers tend to do whatever
will get their code written, compiled, and out the door quickest.)
OK, now that I've finished whining: I would go with explicitly
qualified names, with "using" statements for frequently used
names.
Official terminology: "using-declarations."
And your "using" statements should be in your .cpp files, not
in headers. You want don't want to have to be hunting through
a million .h files to find out where a name comes from.
Don't use "using namespace" statements.
Official terminology: "using-directives."
If the likelihood of name
collisions is high enough to require namespaces, then you'll have
to get rid of them, anyway, and adding qualifiers everywhere in
a million lines of code after you've written, debugged, and
forgotten
them is a *lot* harder than doing it right the first time.
I used to be virulently opposed to using-directives, but there are a
few places where they really make sense. For example, when composing
namespaces:
namespace domain2
{
using namespace domain1;
// additional stuff
}
They also make sense at function scope (or even namespace scope in a
...cpp file) when trying to make certain kinds of idiomatic code read
well:
using namespace mpl::placeholders; // for _1, _2, ... _N
typedef mpl::fold<
seq
, mpl::if<boost::is_base_and_derived<_2,_1>, _1, _2>
, void
>::type t;
(A general rule: do your best to write code you won't have to
revisit. The cost of changing one line of code goes up both as time
passes and as the amount of code that depends upon it goes up.)
I don't even use "using namespace std" or "using std::string" or
"using std::cout" statements. It makes it easer to find them
with search commands.
Me neither, as a rule.
I don't have a lot of experience with nested namespaces.
Nested namespaces are great! However, I have a hard time imagining a
project that could be structured so that all lookups can be
unqualified due to namespace nesting. Normally, you want the
outer-level components to be drawing on those in inner namespaces, not
the other way around. Projects don't typically form a hierarchy with
the highest-level components at the leaves.
Nested namespaces can be made more convenient with namespace aliases.
How come nobody ever mentions namespace aliases?
namespace mpl = boost::mpl;
My experience with nested classes has run into enough annoying
restrictions that I would not use nested namespaces on a big project
until I had a fair amount of experiences on projects small enough
that un-nesting them later on wouldn't be a big problem.
See namespace aliases.
A further problem with trying to avoid qualification is the unexpected
effects of argument dependent lookup, even when calling functions
within the same namespace:
namespace foo
{
bar::x y;
template <class T> int f(T) { ... }
int z = f(y); // might not call foo::f!
}
Qualification is the best way to suppress those.
namespace foo
{
bar::x y;
template <class T> int f(T) { ... }
int z = foo::f(y);
}
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]