public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* typeid strangeness
@ 2001-07-17 17:32 Stefan Seefeld
  2001-07-17 18:20 ` Ross Smith
  2001-07-18  8:09 ` Carlo Wood
  0 siblings, 2 replies; 5+ messages in thread
From: Stefan Seefeld @ 2001-07-17 17:32 UTC (permalink / raw)
  To: gcc

hi there,

I'm not certain whether my observations reflect a bug or
whether I have some profound misunderstanding. I'v got a
class tree based on a 'ServantBase' base class with methods
_add_ref() and _remove_ref().
For debugging purposes, I'd like to track these calls, so I
implement them like this:

void ServantBase::_add_ref()
{
   Guard<Mutex> guard(mutex);
   ++_refcount;
#ifdef LCLOG
   Logger::log(Logger::lifecycle) << "ServantBase::_add_ref on " << this << " ("
   << typeid(this).name() << "): new count is " << _refcount << std::endl;
#endif
}

and I'd (of course) like to see which specific subclass / instance gets called.
However, the type that is being reported is always the base class itself, not
the actual type. What is wrong ?
(this happens with gcc 2.95.x as well as gcc 3.0)

(passing the object reference into a function (void foo(const ServantBase &),
say) and evaluating the type there works fine).

Regards, 
Stefan

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: typeid strangeness
  2001-07-17 17:32 typeid strangeness Stefan Seefeld
@ 2001-07-17 18:20 ` Ross Smith
  2001-07-17 18:34   ` Stefan Seefeld
  2001-07-18  8:09 ` Carlo Wood
  1 sibling, 1 reply; 5+ messages in thread
From: Ross Smith @ 2001-07-17 18:20 UTC (permalink / raw)
  To: Stefan Seefeld; +Cc: gcc

Stefan Seefeld wrote:
> 
> void ServantBase::_add_ref()
> {
>    Guard<Mutex> guard(mutex);
>    ++_refcount;
> #ifdef LCLOG
>    Logger::log(Logger::lifecycle) << "ServantBase::_add_ref on " << this << " ("
>    << typeid(this).name() << "): new count is " << _refcount << std::endl;
> #endif
> }
> 
> and I'd (of course) like to see which specific subclass / instance gets called.
> However, the type that is being reported is always the base class itself, not
> the actual type. What is wrong ?

Did you forget to make _add_ref() virtual? If it's non-virtual, then the
this pointer will have the static type of the caller (i.e. always
ServantBase) instead of the dynamic type.

-- 
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
"Unix has always lurked provocatively in the background of the operating
system wars, like the Russian Army."                  -- Neal Stephenson

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: typeid strangeness
  2001-07-17 18:20 ` Ross Smith
@ 2001-07-17 18:34   ` Stefan Seefeld
  2001-07-17 21:10     ` Ross Smith
  0 siblings, 1 reply; 5+ messages in thread
From: Stefan Seefeld @ 2001-07-17 18:34 UTC (permalink / raw)
  To: Ross Smith; +Cc: gcc

Ross Smith wrote:


> Did you forget to make _add_ref() virtual? If it's non-virtual, then the
> this pointer will have the static type of the caller (i.e. always
> ServantBase) instead of the dynamic type.


no, the method in question is virtual. In fact, I found out that passing
'*this' instead of 'this' to typeid() works, so I use that now. Still, I
can't believe the behavior for pointer types is correct.

Regards,
		Stefan

 



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: typeid strangeness
  2001-07-17 18:34   ` Stefan Seefeld
@ 2001-07-17 21:10     ` Ross Smith
  0 siblings, 0 replies; 5+ messages in thread
From: Ross Smith @ 2001-07-17 21:10 UTC (permalink / raw)
  To: Stefan Seefeld; +Cc: gcc

Stefan Seefeld wrote:
> 
> Ross Smith wrote:
> 
> > Did you forget to make _add_ref() virtual? If it's non-virtual, then the
> > this pointer will have the static type of the caller (i.e. always
> > ServantBase) instead of the dynamic type.
> 
> no, the method in question is virtual. In fact, I found out that passing
> '*this' instead of 'this' to typeid() works, so I use that now. Still, I
> can't believe the behavior for pointer types is correct.

Aha -- I hadn't noticed that you were calling it on the this pointer
itself rather than *this. The compiler is behaving correctly. See
section 5.2.8 para 3 of the C++ standard. typeid is only polymorphic
when its operand is an lvalue of a polymorphic class type; it doesn't
work with pointers. Arguably this is a bad rule -- it's certainly
inconsistent with dynamic_cast, the other half of the RTTI system -- but
that's what the standard says.

-- 
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
"Unix has always lurked provocatively in the background of the operating
system wars, like the Russian Army."                  -- Neal Stephenson

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: typeid strangeness
  2001-07-17 17:32 typeid strangeness Stefan Seefeld
  2001-07-17 18:20 ` Ross Smith
@ 2001-07-18  8:09 ` Carlo Wood
  1 sibling, 0 replies; 5+ messages in thread
From: Carlo Wood @ 2001-07-18  8:09 UTC (permalink / raw)
  To: Stefan Seefeld; +Cc: gcc

On Tue, Jul 17, 2001 at 08:31:45PM -0500, Stefan Seefeld wrote:
> For debugging purposes, I'd like to track these calls, so I
> implement them like this:
...
> #ifdef LCLOG
>    Logger::log(Logger::lifecycle) << "ServantBase::_add_ref on " << this << " ("
>    << typeid(this).name() << "): new count is " << _refcount << std::endl;
> #endif

You might want to use libcwd instead.
See http://libcw.sourceforge.net/debugging/

-- 
Carlo Wood <carlo@alinoe.com>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2001-07-18  8:09 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-17 17:32 typeid strangeness Stefan Seefeld
2001-07-17 18:20 ` Ross Smith
2001-07-17 18:34   ` Stefan Seefeld
2001-07-17 21:10     ` Ross Smith
2001-07-18  8:09 ` Carlo Wood

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).