Re: namespcae scoping and names of external symbols;a compiler bug?
Andrew Marlow wrote:
Hello guys,
I have come across the following style of coding using namespaces:
fred.h
=======
namespace fred {
class bert { public :
void doSomething() { ... }
:
:
}
fred.cpp
========
#include "fred.h"
using namespace fred;
bert::doSomething()
{
:
:
}
The app "joe" uses class fred as follows:
joe.cpp
=======
#include "fred.h"
:
:
fred::bert obj;
obj.doSomething();
With g++ used on both solaris and linux everything links just fine, but on
Windoze (cough, cough) with Visual Studio .NET 2003, the app fails to link.
It says it cannot find the symbol fred::bert::doSomething. It turns out
that the lib contains the symbol bert::doSomething. In other words, the
class bert has leaked into the global namespace.
The two bert::doSomething() function signatures do not agree with each
other: the one in fred.h returns void, while the one in fred.cpp
returns an int (and uses the syntax for an implicit int that is no
longer legal in C++.)
Since gcc is unable to differentiate two functions that differ only by
their return types, it treats the doSomething() in fred.cpp as the
implementation of the doSomething() declaration in fred.h, whereas the
Microsoft compiler is able to discern that that the two are not a
match.
So it would appear that a bug in the source code is being masked by a
bug in the gcc compiler: there is no implementation of void
fred::bert::doSomething() that should be found in this program.
(assuming of course that the inline implementation of
bert::doSomething() in fred.h that is indicated in the example provided
was a mistake - otherwise the problem would a multiply-defined member
function, and not the linking error described).
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]