Re: c++/1593: Problem with nested namespaces

[Daniel Jacobowitz <drow at false dot org>]

The following reply was made to PR c++/1593; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@false.org>
To: klaas.gadeyne@mech.kuleuven.ac.be
Cc: gdb-gnats@sources.redhat.com
Subject: Re: c++/1593: Problem with nested namespaces
Date: Tue, 23 Mar 2004 11:59:57 -0500

 On Tue, Mar 23, 2004 at 04:44:06PM -0000, klaas.gadeyne@mech.kuleuven.ac.be wrote:
 > namespace WRAPPED
 > {
 >   class Foo : public BASE::Foo
 >   {
 >   public:
 >     Foo() : BASE::Foo(){};
 >     virtual ~Foo(){};
 >   };
 > }
 
 > So mywrapped is now reported to be empty, where I expected to see
 > something like
 > 
 > 1: mywrapped = {<Foo> = {<No data fields>}, <No data fields>}
 
 > The problem does not exist when:
 > - The code is compiled with g++ 2.95.4
 > - All code is inlined in 1 file (yes, that's why there are 3 files above :)
 > - I omit the member function method and put the constructor implementation
 >   in the cpp file.
 > - When Foo in namespace WRAPPED is renamed into Boo
 
 Yes.  Unfortunately, this isn't a bug in GDB - there just isn't enough
 information in the object files.  If you try a prerelease snapshot of
 GCC 3.4, I believe it will work OK.
 
 The basic problem is that by explicitly providing a constructor and
 destructor, you've suppressed the implicit operator=.  In GCC 3.x (but
 not in 2.95.4, to explain the first bullet above), this is the only
 default method whose full mangled name appears in the debug
 information - constructors and destructors don't.  We use it to infer
 the correct name of the type.
 
 The other things just tweak the search order.  We're looking up the
 type Foo by name and finding the wrong one - we don't realize it's
 really WRAPPED::Foo.
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer