Topic: typeinfo destructor


Author: Ian Haggard <ian@shellus.com>
Date: 1997/07/04
Raw View
> If ~type_info was protected or private, wouldn't the following well-formed
> program fail to compile?
>
> #include <iostream>
> #include <typeinfo>
>
> void main()
> {
>    cout << typeid(int).name() << '\n';;
> }
Since typeid returns a const type_info&, this should work just fine.
The reference will just go out of scope, and no destructors will be
called.

Let me quote from the Dec. 96 Draft:
>  5.2.8  Type identification                               [expr.typeid]
>
> 1 The  result  of  a  typeid  expression  is  an  lvalue  of  type const
>   std::type_info (_lib.type.info_).  The lifetime of the object referred
>   to  by  the  lvalue extends to the end of the program.  Whether or not
>   the destructor is called for the type_info object at the  end  of  the
>   program is unspecified.
>From my reading of this, it seems that to allow the destructor of the
type_info class to be public is positively dangerous.

I did notice, however, that Dinkumware seems have read the standard
incorrectly.  Their documentation on class type_info states:
> An expression of the form typeid x is the only way to construct a
> (temporary) typeinfo object.  The class has only a private copy
> constructor. Since the assignment operator is also private, you cannot
> copy or assign objects of class typeinfo either.
BTW The URL for this is:
http://www.dinkumware.com/htm_cpl/typeinfo.html#type_info

As an aside, Dinkumware's (mis)interpretation seems to me very
limiting.  With their interpretation it is impossible to have an object
which contains a const type_info& or const type_info*.
--
Ian Haggard  ||  ian@shellus.com (work)  ||  IanHaggard@juno.com (home)
GNU/Linux -- "Oh, no, Mr Bill!" || #define employer_opinion !my_opinion
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]





Author: Ian Haggard <ian@shellus.com>
Date: 1997/07/02
Raw View
In the December '96 draft, I notice that the destructor for class
type_info is public (sec. 18.5.1).  Is there any reason for this or is
this just an omission?  I would think the destructor should either be
private or protected, depending on the compiler's implementation of
rtti.
--
Ian Haggard  ||  ian@shellus.com (work)  ||  IanHaggard@juno.com (home)
GNU/Linux -- "Oh, no, Mr Bill!" || #define employer_opinion !my_opinion
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: heh@beamtech.com (Howard E. Hinnant)
Date: 1997/07/03
Raw View
In article <33B97887.699C@shellus.com>, Ian Haggard <ian@shellus.com> wrote:

> In the December '96 draft, I notice that the destructor for class
> type_info is public (sec. 18.5.1).  Is there any reason for this or is
> this just an omission?  I would think the destructor should either be
> private or protected, depending on the compiler's implementation of
> rtti.

If ~type_info was protected or private, wouldn't the following well-formed
program fail to compile?

#include <iostream>
#include <typeinfo>

void main()
{
   cout << typeid(int).name() << '\n';;
}

The error that my implementation would give is:

Error   : illegal access to protected/private member

-Howard
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]