This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
RE: c++/1748
- To: nobody at gcc dot gnu dot org
- Subject: RE: c++/1748
- From: Vlad Socaciu <vsocaciu at mbird dot com>
- Date: 29 Jan 2001 19:06:00 -0000
- Cc: gcc-prs at gcc dot gnu dot org,
- Reply-To: Vlad Socaciu <vsocaciu at mbird dot com>
The following reply was made to PR c++/1748; it has been noted by GNATS.
From: Vlad Socaciu <vsocaciu@mbird.com>
To: nathan@gcc.gnu.org
Cc: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Subject: RE: c++/1748
Date: Mon, 29 Jan 2001 11:02:34 -0800
Thanks for the info. I did provide source code, a detailed output of the
compilation step and the output of the actual program run but perhaps your
bug tracking system didn't record this information. Here they are again.
1. The code (doesn't do anything but display the typeid().name() for some
types to see hw this feature works):
#include <iostream>
#include <typeinfo>
class ALPHA
{
public:
ALPHA(){}
virtual ~ALPHA(){}
};
class BETA : public ALPHA
{
public:
BETA(){}
~BETA(){}
};
int main()
{
ALPHA* p_a = new ALPHA;
ALPHA* p_b0 = new BETA;
BETA* p_b1 = new BETA;
cerr << typeid( p_a ).name() << endl;
cerr << typeid( p_b0 ).name() << endl;
cerr << typeid( p_b1 ).name() << endl;
cerr << typeid( int ).name() << endl;
cerr << typeid( char* ).name() << endl;
}
2. The compilation (we use Sparc Solaris 7):
~/C_CPP%g++ typeid_test.cc -o ty -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs
gcc version 2.95.2 19991024 (release)
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/cpp -lang-c++ -v -D__GNUC
__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -Dsparc -Dsun -Dunix -D_
_svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__sp
arc -D__sun -D__unix -Asystem(unix) -Asystem(svr4) -D__EXCEPTIONS -D__GCC_NE
W_VARARGS__ -Acpu(sparc) -Amachine(sparc) typeid_test.cc
/var/tmp/ccLr9v3c.ii
GNU CPP version 2.95.2 19991024 (release) (sparc)
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/../../../../include/g++-3
/usr/local/include
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/../../../../sparc-sun-sol
aris2.7/include
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
End of omitted list.
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/cc1plus
/var/tmp/ccLr9v3c.ii -quiet -dumpbase typeid_test.cc -version -o
/var/tmp/ccYgW1oj.s
GNU C++ version 2.95.2 19991024 (release) (sparc-sun-solaris2.7) compiled by
GNU C version 2.95.2 19991024 (release).
/usr/local/sparc-sun-solaris2.7/bin/as -V -Qy -s -o /var/tmp/ccSjcvKC.o
/var/tmp/ccYgW1oj.s
GNU assembler version 2.10 (sparc-sun-solaris2.7) using BFD version 2.10
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/collect2 -V -Y
P,/usr/ccs/lib:/usr/lib -Qy -o ty
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crt1.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crti.o
/usr/ccs/lib/values-Xa.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crtbegin.o -L/usr/local/l
ib/gcc-lib/sparc-sun-solaris2.7/2.95.2 -L/usr/local/sparc-sun-solaris2.7/lib
-L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/lib
/var/tmp/ccSjcvKC.o -lstdc++ -lm -lgcc -lc -lgcc
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crtend.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crtn.o
GNU ld version 2.10 (with BFD 2.10)
Supported emulations:
elf32_sparc
elf64_sparc
3. The program output:
~/C_CPP%ty
P5ALPHA
P5ALPHA
P4BETA
i
Pc
As you can see, it displays "P5ALPHA" where I expected "ALPHA", "P4BETA"
where I expected just "BETA" and some characters where I expected "int" and
"char*". It may be that "i" stands for "int" and "Pc" for pointer to char
but if this is the way it is supposed to work, could you explain what are
the coding rules? Thanks.
-----Original Message-----
From: nathan@gcc.gnu.org [mailto:nathan@gcc.gnu.org]
Sent: Monday, January 29, 2001 8:35 AM
To: gcc-gnats@gcc.gnu.org; nobody@gcc.gnu.org; vsocaciu@mbird.com
Subject: Re: c++/1748
Synopsis: perhaps incorrect type_info class data
State-Changed-From-To: open->closed
State-Changed-By: nathan
State-Changed-When: Mon Jan 29 08:35:16 2001
State-Changed-Why:
not a bug. You've not provided source code, however
the strings that typeid (T).name produces are implementation
defined. G++ produces names that a guaranteed unique for each
type.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1748&database=gcc