Thanks a lot.
I also found a warning message about this if I used the `bridge pattern' (aka
pimpl idiom) in my code.
For example, here are 2 files:
==========
// interface.hxx
#include <memory>
struct TestImpl;
class Test {
public:
Test();
~Test();
void foo();
private:
std::auto_ptr<TestImpl> pImpl;
};
==========
and
==========
// TestImpl.cxx
#include <algorithm>
#include <map>
#include <ext/hash_map>
#include "interface.hxx"
using namespace std;
namespace {
template <class T>
struct CompareValue {
size_t operator()(const T &lhs, const T &rhs) const
{
return lhs < rhs;
}
};
}
struct TestImpl {
TestImpl() : test(new map<int, int, CompareValue<int> >) { }
void foo();
map<int, int, CompareValue<int> > *test;
};
void TestImpl::foo()
{
(*test)[1] = 2;
}
Test::Test() : pImpl(new TestImpl)
{
}
Test::~Test()
{
}
void Test::foo()
{
pImpl->foo();
}
==========
When I compiled TestImpl.cxx, I got the following warning message:
warning: 'TestImpl' has a field 'TestImpl::test' whose type uses the anonymous
namespace
Although my program can work normally, I'm still awaring of this warning
message.
Since the bridge pattern is widely used in my huge software project for saving
the compile-time,
I worried that this change of GCC will break it in the future.
I know GCC provide the visibility attribute, but it's not helpful in this case.
Should I put the definition of CompareValue<> to other namespaces?
Brian Dessent wrote:
Ling-hua Tseng wrote:
If I compile this file with g++ 4.2 by the following command:
g++ -c test.cxx
and then use this command to check symbol:
nm test.o
I cannot find the global varible `test' in symbol table:
This was an intentional change as part of the overhaul of C++ visibility
semantics in 4.2. The motivation for this aspect of the change comes
about from the realization that anonymous namespaces are implemented by
adding a randomly-generated string to the mangled name so that they're
guaranteed to be unique to their translation unit. So it would be
impossible or at least extremely cumbersome to actually refer to such a
symbol from another module, and thus giving them hidden visibility just
cuts down on useless indirection and overhead.
http://gcc.gnu.org/gcc-4.2/changes.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21581
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01511.html
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01322.html
Brian
