Steve Pope posted:
int main()
{
::Func(); /* Calls the external one*/
/* I don't think we've any way of calling
the internal one. */
}
Any thoughts on this?
Yes. The contents of the nameless namespace are local to
one sourcefile, so whoever's coding that file is free to
choose whatever identifiers they like for names within that
namespace, and so is always free to use ones that do not
conflict with their own code.
So there doesn't seem to be much of a need for a mechanism
to get around this deficiency.
Imagine this:
We have a load of header files pertaining to a particular library.
Everything in the library is defined in the global namespace (rather than
something like LibraryName::Ea tGrass() ).
In one of our own source files, we have a function within an anonymous
namespace called "EatGrass". This particular source file also happens to
contain "main". Here's how it looks at the moment:
namespace {
int EatGrass()
{
return 5;
}
}
int main()
{
EatGrass();
}
Later, we decide that we need something from the library, so we include a
header:
#include <somelibrary/consumption.hpp >
namespace {
int EatGrass()
{
return 5;
}
}
int main()
{
EatGrass();
}
Unfortunately now, we get a compile error because the function call is
ambiguous. Normally we'd rememdy this by placing the calling function
within the anonymous namespace also... but alas, the following give us a
linker error:
#include <somelibrary/consumption.hpp >
namespace {
int EatGrass()
{
return 5;
}
int main()
{
EatGrass(); /* Intends to call internal func */
}
}
int SomeOtherFunc()
{
EatGrass(); /* Intends to call external func */
}
Because we can't put "main" inside an anonymous namespace.
--
Frederick Gotham
