Section 5.2.7 para 6 of the 26 January 1996 Draft states:

If the header <typeinfo> (18.5.1) is not included prior to a use of
typeid, the result of a typeid expression is an lvalue that has the
incompletely-defined class type const std::type_info, and a program
that explicitly names this class type before inclusion of the header
is ill-formed.


Does this mean that there can be a well-formed program that somehow
uses typeid without first including <typeinfo>?  Is so can you give me
some examples?  Would this be legal?  What should the compiler do with it?

int main()
{
  return typeid(int) == typeid(long);
}

I think it seems reasonable for the compiler to issue an error message
in any case where typeid is used and <typeinfo> is not included.  After
all, if <typeinfo> is not included the compiler doesn't know anything
about the type type_info, unless there is some internal hackery going
on.

It also seems reasonable that the type_info class could be used
to implement the dynamic_cast operator, but there is certainly no
requirement to include <typeinfo> when using dynamic_cast.

I can also see where type_info could be useful in implementing
exception handling, but again no <typeinfo> header is required.

(See gcc 2.7.2 for an example of this.)

Is a implementation allowed to require <typeinfo> be included
for these reasons?  Should be it?

Also due to the above draft paragraph it doesn't seem possible to
predefine the type_info class somehow (simulating the include
<typeinfo>).  So it seems an ugly hack of some sort is needed
no matter what, if the compiler wants to use the type_info class
directly.

Any one have comments on this?

--
Mike Rice (mpr@absoft.com)
Absoft Corporation
---
[ 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                             ]

"Michael Rice" <mpr@absoft.com> writes:

>Section 5.2.7 para 6 of the 26 January 1996 Draft states:
>
>If the header <typeinfo> (18.5.1) is not included prior to a use of
>typeid, the result of a typeid expression is an lvalue that has the
>incompletely-defined class type const std::type_info, and a program
>that explicitly names this class type before inclusion of the header
>is ill-formed.
>
>Does this mean that there can be a well-formed program that somehow
>uses typeid without first including <typeinfo>?

Yes.

>Is so can you give me some examples?  Would this be legal?
>What should the compiler do with it?
>
>int main()
>{
>  return typeid(int) == typeid(long);
>}

Your example is legal; the compiler should do the same thing that
it would do if <typeinfo> had been #included.

>I think it seems reasonable for the compiler to issue an error message
>in any case where typeid is used and <typeinfo> is not included.

That seems a little bit inconsistent with how other language builtins
are handled; C compilers don't issue an error message for the use of
`sizeof', even if you haven't included a header file which defines
`size_t'.

>... if <typeinfo> is not included the compiler doesn't know anything
>about the type type_info, unless there is some internal hackery going
>on.

Hence you can deduce there must be some internal hackery going on.

>Is a implementation allowed to require <typeinfo> be included
>for these reasons?

No.

> Should be it?

IMHO, no.

>Also due to the above draft paragraph it doesn't seem possible to
>predefine the type_info class somehow (simulating the include
><typeinfo>).  So it seems an ugly hack of some sort is needed
>no matter what, if the compiler wants to use the type_info class
>directly.

I think the basic idea is that the compiler is supposed to have a
built-in definition of `__typeinfo' (perhaps by automatically
#including a <__typeinfo> hedaer), and <typeinfo> is supposed to
contain `typedef __typeinfo typeinfo' or something similar.

This is easy enough to implement, and avoids invading the user's
namespace in cases when the <typeinfo> header has not been included.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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                             ]

Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote:
| >int main()
| >{
| >  return typeid(int) == typeid(long);
| >}
|
| Your example is legal; the compiler should do the same thing that
| it would do if <typeinfo> had been #included.

I disagree.  Surely since, by [expr.typeid] paragraph 6 the type of the
lvalue returned is an incomplete class type, the call to operator== is
ill-formed ?

The result of relational and comparison operators in [expr.rel] are only
defined for arithmetic and pointer types.  A comparison of two type_info
objects requires an overloaded operator==, and no such operator has been
declared.

My thought was that well-formed programs that used typeid but that
didn't #include <typeinfo> could only use typeid trivially :

 int main (int, char **) { typeid(int) ; return 0 ; }

| >I think it seems reasonable for the compiler to issue an error message
| >in any case where typeid is used and <typeinfo> is not included.
|
| That seems a little bit inconsistent with how other language builtins
| are handled; C compilers don't issue an error message for the use of
| `sizeof', even if you haven't included a header file which defines
| `size_t'.

Not a valid analogy.  sizeof returns a fundamental type.  Which particular
type it returns is implementation defined, and the size_t type is merely a
useful alias for whichever fundamental type it actually is.  You don't have
to have a declaration of size_t in order to use sizeof.

Whereas std::type_info is not a fundamental type.  Neither is it a type
alias.  Since [expr.typeid] says that an incomplete class type with the
correct name is implicitly declared if the <typeinfo> header is not
included, all of the restrictions on incomplete types apply to the result
of the typeid operator.

I must admit, the provisions of [expr.typeid] do seem rather odd.  It looks
like a halfway house between making type_info a fundamental type (like
bool) and restricting typeid to only be well-defined in the case that
<typeinfo> has been included previously.  The result is the worst of both
worlds, where the compiler has to implicitly declare std::type_info if it
encounters typeid before <typeinfo>, but where std::type_info still has the
appearance and semantics of a user-defined class type.

Even then, a conformant compiler has to violate [basic.types] in order to
implement typeid.  A conformant compiler has to create objects of type
std::type_info, even if std::type_info is an incomplete type.  Yet
[basic.types] specifically states that "no object shall be created to have
incomplete type".  Do we have an inconsistent language definition, or what ?

On the other hand, I cannot see what other solution could have been arrived
at.  It is desired that typeid return a class type.  It is desired that
typeid be well-formed even if <typeinfo> has not been previously included.
What other solution is possible ?

| I think the basic idea is that the compiler is supposed to have a
| built-in definition of `__typeinfo' (perhaps by automatically
| #including a <__typeinfo> hedaer), and <typeinfo> is supposed to
| contain `typedef __typeinfo typeinfo' or something similar.
|
| This is easy enough to implement, and avoids invading the user's
| namespace in cases when the <typeinfo> header has not been included.

But how does a type in namespace std "invade the user's namespace"
*anyway* ?  Answer : it doesn't.  So this is a non-issue.

In theory, std::type_info could be accorded the same status as bool.
As far as I can see, there are only two reasons why this hasn't been done.

The first is that it is desirable that all standard class types be defined
in headers.  Making std::type_info a built-in type would mean that it would
be in the unique position of being a class type that could be used without
it being defined.

The second is that removing std::type_info from a header and making it a
fundamental type would mean that a lot of extra wording in [expr.eq] and
[basic.fundamental] would be necessary, in order to describe the effects of
the == and != operators on objects of that type, and the implicit declarations
of the pseudo-function-members name() and before(const type_info &).

These seem pretty sound reasons for not making std::type_info into a
fundamental type.

On the other hand, this *is* the same C++ committee that was prepared to
take the wchar_t type alias and turn it into a fundamental type, instead of
giving us `long char' as God intended ...
---
[ 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
]

>>>>> Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> writes:

> "Michael Rice" <mpr@absoft.com> writes:

>> Section 5.2.7 para 6 of the 26 January 1996 Draft states:
>>
>> If the header <typeinfo> (18.5.1) is not included prior to a use of
>> typeid, the result of a typeid expression is an lvalue that has the
>> incompletely-defined class type const std::type_info, and a program
>> that explicitly names this class type before inclusion of the header
>> is ill-formed.

>> Is so can you give me some examples?  Would this be legal?
>> What should the compiler do with it?
>>
>> int main()
>> {
>>   return typeid(int) == typeid(long);
>> }

> Your example is legal; the compiler should do the same thing that
> it would do if <typeinfo> had been #included.

I disagree.  The compiler does not know how to compare objects of the
incompletely-defined class type std::type_info.  This is ill-formed.  You
must #include <typeinfo> before you can do anything with type_info nodes
other than pass them around.

>> ... if <typeinfo> is not included the compiler doesn't know anything
>> about the type type_info, unless there is some internal hackery going
>> on.

> Hence you can deduce there must be some internal hackery going on.

Or you can deduce that the compiler doesn't know anything about the type,
apart from its existence.

>> Also due to the above draft paragraph it doesn't seem possible to
>> predefine the type_info class somehow (simulating the include
>> <typeinfo>).  So it seems an ugly hack of some sort is needed
>> no matter what, if the compiler wants to use the type_info class
>> directly.

> I think the basic idea is that the compiler is supposed to have a
> built-in definition of `__typeinfo' (perhaps by automatically
> #including a <__typeinfo> hedaer), and <typeinfo> is supposed to
> contain `typedef __typeinfo typeinfo' or something similar.

I disagree.  "incompletely-defined class type" says to me that there is an
implicit

namespace std { class type_info; }

at the beginning of all translation units, and that's what typeid returns.
Note that the semantics for a typedef are significantly different from the
semantics for a class; thus <iosfwd>.

In fact, this is what I have implemented for g++ 2.8.  The compiler doesn't
know about the members of type_info, but it does know how to create
type_info objects (through implementer-space library functions).

Jason
---
[ 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
]

In article AA02072@absoft.absoft.com, "Michael Rice" <mpr@absoft.com> writes:
>Section 5.2.7 para 6 of the 26 January 1996 Draft states:
>
>If the header <typeinfo> (18.5.1) is not included prior to a use of
>typeid, the result of a typeid expression is an lvalue that has the
>incompletely-defined class type const std::type_info, and a program
>that explicitly names this class type before inclusion of the header
>is ill-formed.
>
>
>Does this mean that there can be a well-formed program that somehow
>uses typeid without first including <typeinfo>?  Is so can you give me
>some examples?  Would this be legal?  What should the compiler do with it?

The situation is (somewhat) analagous to type size_t. If you ask for "sizeof",
the result has type size_t, and you can use it in any context where you
don't specifically need to know what type size_t is. Example:
 double d = sizeof(int);
Type size_t must have an implicit conversion to double, so the code is OK.
(The analogy breaks down because size_t must be a typedef of an unsigned
integer type.)

Just as the compiler knows the characteristics of size_t, it also knows
the characteristics of std::type_info. You can use a typeid expression
without including <typeinfo> as long as you don't do anything with the
result that depends on knowing the type. Example:
 main()
 {
  typeid(int); // we are not using the result
 }
You can't do very much that is useful without including <typeinfo>, but
no special language rules are needed. Your example
>int main()
>{
>  return typeid(int) == typeid(long);
>}
fails because you are comparing incomplete types. I believe a slightly
different example would be valid, however:
 main()
 {
  return &typeid(int) == &typeid(long);
 }
A pointer to an incomplete type is allowed as long as it isn't dereferenced,
and you can compare any two pointers of the same type for equality.

The implementation in the compiler is not a problem. As with size_t, a
common solution is for the compiler to predefine the type with a private name
(or with no name), and a header file causes the public name to be associated
with that type.

Example 1: The compiler predefines __size_t_type as a typedef for some
unsigned integer type. Header files could then contain:
 typedef __size_t_type size_t;

Example 2: Type size_t is implemented as unsigned int, and the type of a
sizeof expression has no name but is the same type as unsigned int. Header
files could then contain:
 typedef unsigned int size_t;

The compiler implementor supplies the standard header files, so everything
matches properly.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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
]

In article <4okesj$7iv@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU
(Fergus Henderson) writes:

>"Michael Rice" <mpr@absoft.com> writes:
>>Does this mean that there can be a well-formed program that somehow
>>uses typeid without first including <typeinfo>?
>>Is so can you give me some examples?  Would this be legal?
>>
>>int main()
>>{
>>  return typeid(int) == typeid(long);
>>}
>
>Your example is legal; the compiler should do the same thing that
>it would do if <typeinfo> had been #included.

I disagree.  This was discussed at some length in the standards committee.
Personally, I favored making any use of typeid ill-formed unless <typeinfo>
was previously included, but the opinions of others prevailed :-P.

For the above example, note that the typeid would have an incompletely-
defined class type, and therefore the operator== provided in the
type_info class would not be visible.  So the example is ill-formed.

 [Moderator's note: J. Stephen Adamczyk is right and I was wrong.
 I missed the bit where it said "incompletely-defined"
 in 5.2.7[expr.typeid]/6.  Sorry about that.  -fjh.]

There are well-formed programs that use typeid without <typeinfo>, e.g.,

int main() {
  void *p = (void *)&typeid(int);
}

but it's not clear to me that any of these cases are useful.

Steve Adamczyk
---
[ 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                             ]

Steve Clamage (clamage@Eng.Sun.COM) wrote:
| I believe a slightly different example would be valid, however:
|  main()
|  {
|   return &typeid(int) == &typeid(long);
|  }

Tut tut Steve.  You really must get out of that bad habit of using implicit
int.  [diff.dcl] paragraph 4, don't you know.  (-:

But is an implementation allowed to extend std::type_info by providing an
override of operator& ?

If so, then by [expr.unary.op] paragraph 4, the above results in undefined
behaviour.

[lib.member.functions] is not clear as to whether the stated means are the
*only* means by which an implementation may add function members to a class
in the standard library.

If you change [lib.member.functions] to be clear on this point, then the
above example is well-formed (assuming the extra `int' (-:).  On the other
hand, this may be overly restrictive on implementations.

If, however, it *is* permissible for an implementation to extend a standard
class with additional non-virtual members, then the result is that a
well-formed program can do very little with typeid unless it includes the
<typeinfo> header.  e.g.

 int main ( int, char ** ) { typeid(int) ; return 0 ; }

I don't think that it can even bind a reference to the lvalue returned by
the typeid operator

 int
 main ( int, char ** )
 {
  std::type_info & t = typeid(int) ; // ill-formed
  return 0 ;
 }

because [expr.typeid]#6 has been violated.  [expr.typeid]#6 says that
std::type_info cannot be named before <typeinfo> has been included, which
one assumes is the non-normative equivalent of saying :

[proposed amendment #1 to expr.typeid#6] :

 "A program that uses the name std::type_info before the inclusion
 of the <typeinfo> header is ill-formed."

How do you bind, or even declare, a reference if you cannot use the
type name ?

It does seem that without <typeinfo> included, the return value of the
typeid operator cannot be used *at* *all*.

In which case, why are we bothering with [expr.typeid]#6 in the first
place ?  It's obviously a hack to try to make typeid well-formed when
<typeinfo> is not included.  But since typeid cannot be used in any way
without the inclusion of <typeinfo>, what's the point ?

[proposed amendment #2 to expr.typeid] :

 Delete #6, insert the following as #1, and renumber :

 "A program that uses the typeid operator before the inclusion of
 the <typeinfo> header is ill-formed."
---
[ 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                             ]

jason@cygnus.com (Jason Merrill) writes:

| Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> writes:
|
| >> int main()
| >> {
| >>   return typeid(int) == typeid(long);
| >> }
|
| > Your example is legal; the compiler should do the same thing that
| > it would do if <typeinfo> had been #included.
|
| I disagree.  The compiler does not know how to compare objects of the
| incompletely-defined class type std::type_info.  This is ill-formed.  You
| must #include <typeinfo> before you can do anything with type_info nodes
| other than pass them around.

I was mistaken -- Jason Merrill is right.  Sorry about that.

| "incompletely-defined class type" says to me that there is an implicit
|
| namespace std { class type_info; }
|
| at the beginning of all translation units, and that's what typeid returns.
[...]
| In fact, this is what I have implemented for g++ 2.8.

That's not an unreasonable position, but it doesn't seem to handle
the last part of [5.2.7/6]:

>>> If the header <typeinfo> (18.5.1) is not included prior to a use of
>>> typeid, the result of a typeid expression is an lvalue that has the
>>> incompletely-defined class type const std::type_info, and a program
>>> that explicitly names this class type before inclusion of the header
>>> is ill-formed.

This seems to require a diagnostic for

 std::typeinfo *ptr;

if <typeinfo> hasn't been included.  Does g++ 2.8 issue that diagnostic?

If this requirement is difficult to implement, perhaps it should be dropped.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.


[ 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                             ]

Jason Merrill (jason@cygnus.com) wrote:
| The compiler does not know how to compare objects of the
| incompletely-defined class type std::type_info.  This is ill-formed.  You
| must #include <typeinfo> before you can do anything with type_info nodes
| other than pass them around.
|
| [...]
|
| "incompletely-defined class type" says to me that there is an implicit
|
| namespace std { class type_info; }
|
| at the beginning of all translation units,

Except that if there were, then std::type_info could be used by a program
that did not include the <typeinfo> header.

This is not the case, because [expr.typeid]#6 *also* states that any
program that names the class type before including <typeinfo> is ill-formed
(which I assume is trying to say that any program that uses the name
"std::type_info" before including <typeinfo> is ill-formed).

You cannot "pass around" objects without having some way of naming the type
of those objects.  You cannot even bind references to those objects.  So what
can you do with them ?  Almost nothing :

 int main ( int, char ** ) { typeid(int) ; return 0 ; }

As I said in my last message, it looks like all of the compromises in
[expr.typeid]#6 are for naught.  Why don't we just bite the bullet and say
that a program that uses the typeid operator without including <typeinfo>
beforehand is ill-formed ?
---
[ 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
]

J. Stephen Adamczyk (jsa@edg.com) wrote:
| I disagree.  This was discussed at some length in the standards committee.
| Personally, I favored making any use of typeid ill-formed unless <typeinfo>
| was previously included,

A man after my own heart.  (-:

| but the opinions of others prevailed :-P.

There are some pretty weighty arguments on our side.  There must be
something quite extraordinary on the other side to outweigh them.  What is
it that is so desirable about allowing a program to use typeid without
first including <typeinfo> ?  What useful code can one write ?

| There are well-formed programs that use typeid without <typeinfo>, e.g.,
|
| int main() {
|   void *p = (void *)&typeid(int);
| }

Except that [lib.member.functions] does not explicitly state that an
implementation *cannot* add operator& to std::type_info.  And since it
doesn't, any code such as the above invokes undefined behaviour on any
implementation that has a std::type_info::operator& .

[Alternative #1, proposed amendment to lib.member.functions] :

    Change

 "An implementation can declare additional non-virtual member
 function signatures with a class : [by X, by Y, and by Z]"

    to

 "An implementation can only declare additional non-virtual member
 function signatures with a class : [by X, by Y, and by Z]"

[Alternative #2, proposed amendment to expr.typeid] :

    Delete #6, insert the following as #1, and renumber.

    "A program that uses the typeid operator before the inclusion of the
    <typeinfo> header is ill-formed."
---
[ 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
]

jason@cygnus.com (Jason Merrill) writes:

>> I think the basic idea is that the compiler is supposed to have a
>> built-in definition of `__typeinfo' (perhaps by automatically
>> #including a <__typeinfo> hedaer), and <typeinfo> is supposed to
>> contain `typedef __typeinfo typeinfo' or something similar.

>I disagree.  "incompletely-defined class type" says to me that there is an
>implicit

>namespace std { class type_info; }

>at the beginning of all translation units, and that's what typeid returns.

That would make "type_info" unique in being predeclared without being
predefined. I asked this question of the people who generated the
rule in question, and they said that was not the intent. I think the
wording of 5.2.7 Type identification [expr.typeid] should be made more
explicit.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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                             ]