"Stuart MacMartin" <sj*@igs.net> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com
Don't worry, I wasn't about to do that.
We introduced "using std;" to force using a standard min and max.
We wanted to be sure that any conflict in names was caught (and we
just hit another moving to a new redhat platform) rather than
inadvertently
using the wrong one - one that might not be what we expect. And yes
we found some that didn't do what std::min and max do (though I can't
recall the details) I can handle that case by doing "using std::min;
using std::max;" globally (and similarly any other routine where we
ALWAYS mean the std one).
Does it offend your sensibilities to decide globally that certain
routines are used? e.g. globally do using Replacement::sort;
Stuart
A lot of the rationale for namespaces comes from using code from multiple
suppliers in the one project. You might decide that the global use of a
particular function is appropriate, but what happens if you use a third
party library that depends on using a different function? Putting something
in a header file so as to deliberately create a name clash where the wrong
function is used in some legacy code is a useful tactic, but that doesn't
mean you have to leave it there after the uses of the wrong function have
been identified. One perhaps non-obvious problem with putting using
directives / declarations in header files is that it means that program
behaviour may depend on the order in which headers are included, which is a
fragility that should be avoided if possible.
If your using directives/declarations only occur in a single header file and
if you manage to always include it first, then you have a situation in which
you just have a whole lot of identifiers in the global namespace throughout
your program. This needn't be a huge problem, particularly if you make
little use of third party libraries. After all, it is how programs were
written before namespaces became part of the language. If you have a large
project and it would be a lot of work to change it, then you might decide to
live with this. You do, however, give up some of the benefits of namespaces.
There are circumstances in which a less-than-ideal design makes economic
sense for an existing project, given the cost of change (and, for small
projects, the problems that arise from less-than-ideal design, if any, are
often small enough to be managed manually). That is a judgement for you to
make.
--
John Carson