--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: g++-4.1: inline destructor must be defined in-class
- From: "Frank B. Brokken" <f.b.brokken@rug.nl>
- Date: Sat, 25 Nov 2006 14:27:34 +0100
- Message-id: <20061125132734.3668.28470.reportbug@suffix.rc.rug.nl>
Package: g++-4.1
Version: 4.1.1-19
Severity: normal
Dear Maintainers,
While performing maintenance on my Bobcat library, suddenly my program
Bisonc++ FTBFS. The maintenance to Bobcat involved placing all inline member
function definitions below their class interfaces. Removing all non-essential
stuff, the full source of the stripped-down version of the program that could
not be constructed looks like this:
class Class
{
public:
virtual ~Class();
virtual char const *what() const;
};
inline Class::~Class()
{}
int main()
{}
In its original version, the above program was implemented as follows:
class Class
{
public:
virtual ~Class()
{}
virtual char const *what() const;
};
int main()
{}
The difference being that the former program defines its destructor below the
class body, whereas the latter program defines it inside the class body. The
error that's reported is a linker error, suggesting that the vtable must be
linked even though no use of it is implied by the program:
/tmp/ccWzeW1i.o:(.rodata._ZTV5Class[vtable for Class]+0x10): undefined
reference to `Class::what() const'
I found a work-around, but consider that a kludge, since it is stated in my
copy of the C++ standard (where it says *either* an inline function's
declaration *or* its definition should contain `inline'):
> 9.4 Member functions [class.mfct]
>
> An inline member function (whether static or nonstatic) may also be defined
> outside of its class definition provided either its declaration in the class
> definition or its definition outside of the class definition declares the
> function as inline (7.1.2).
So, here's my kludge, which has `inline' in *both* the class definition *and*
the implementation:
class Class
{
public:
inline virtual ~Class();
virtual char const *what() const;
};
inline Class::~Class()
{}
int main()
{}
For the sake of completeness, I also tried a version having inline specified
in the class definition but not with the destructor's definition:
class Class
{
public:
inline virtual ~Class();
virtual char const *what() const;
};
Class::~Class()
{}
int main()
{}
This last variant also compiles and links flawlessly and is conform the
standard's text. So, it looks as though `inline' currently needs to be
specified explicitly for virtual destructor declarations, or that the virtual
destructor must be given an in-class implementation. I think requiring
`inline' in the class definition is a bug.
Kind regards,
Frank Brokken.
PS: reportbug reported that g++-4.1* is now at 4.1.1-20, but upgrading still
keeps the compiler at -19, which is also received when downloading
explicitly from packages/debian.org, even though it reports version
4.1.1-20 there for the i386 architectures. So, I tried all this on the -19
version.
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages g++-4.1 depends on:
ii gcc-4.1 4.1.1-19 The GNU C compiler
ii gcc-4.1-base 4.1.1-19 The GNU Compiler Collection (base
ii libc6 2.3.6.ds1-8 GNU C Library: Shared libraries
ii libstdc++6-4.1-dev 4.1.1-19 The GNU Standard C++ Library v3 (d
g++-4.1 recommends no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
- To: 400332-done@bugs.debian.org
- Subject: C++ and mudflap packages not built anymore from the gcc-4.1 source
- From: Matthias Klose <doko@debian.org>
- Date: Sun, 11 Apr 2010 14:30:31 +0000
- Message-id: <E1O0yBD-00084x-Oz@ravel.debian.org>
The C++ and mudflap binary packages are not built anymore from the
gcc-4.1 source package. Tagging this report as won't fix, and closing
the report.
Please check if the problem is fixed in gcc-4.4 (or gcc-4.5/gcc-snapshot).
If the problem is not fixed, and not yet reported for the new compiler
version(s), open a new report.
--- End Message ---