"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

|>  J. Kanze wrote:
|>  >
|>  > Is the lifetime of the char array pointed to by the return value of
|>  > type_info::name() also so guaranteed.  (It's a horrible thought, but
|>  > would it be legal for an implementation to have all calls to
|>  > type_info::name() return a pointer to a static buffer, which got
|>  > overwritten on each call.)
|>
|>  Any implementation that claims to work in a multi-threaded environment
|>  would have to store all its type names as constant strings.

In practice, it's hard to imagine a reasonable implementation that does
otherwise.  I was just wondering about what the standard formally
requires.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3580C202.10C45BA@ix.netcom.com>,
  "Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:
>
> J. Kanze wrote:
> >
> > Is the lifetime of the char array pointed to by the return value of
> > type_info::name() also so guaranteed.  (It's a horrible thought, but
> > would it be legal for an implementation to have all calls to
> > type_info::name() return a pointer to a static buffer, which got
> > overwritten on each call.)
>
> Any implementation that claims to work in a multi-threaded environment
> would have to store all its type names as constant strings.
>
> It just goes to show you, it's impossible to write a standard in which
> every possibility is spelled out in advance.

Furthermore, if the implementation were to overwrite a static buffer on each
call, it would have to copy the name from somewhere.  Conceivably it could
keep the type name compressed, and expand it when it overwrote the static
buffer, but any savings in the data are likely to be shadowed by the extra
code needed to de-compress the data.

So here's a case where doing what was intended is FAR simpler than trying to
pervert it and yet remain compliant.

It does remind me of a different suggestion I recently heard, though, about
having a compliant compiler that deliberately does things differently, in
order to quickly flag compatibility problems in code that may happen to work
locally.  There are already real compilers that do this for the limited
problem of memory allocation -- i.e. overwriting deleted data with a pattern
or making it inaccessible.

Doing this for every documented C++ feature seems to be a much bigger
problem, perhaps infeasible.  I suppose such a compiler would have to
twist the RTTI as far as possible; perhaps even by returning class names
that can't be easily mapped to the source code names; i.e. at runtime
select a unique but random combination of letters and digits.  Then on
one particular run, the name of int might be "X1", the name of long might
be "3UR23", the name of class istream might be "3UR2", etc.!

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paris (U.E.), le 15/06/1998

AllanW@my-dejanews.com wrote:

[SNIP]

> It does remind me of a different suggestion I recently heard, though, about
> having a compliant compiler that deliberately does things differently, in
> order to quickly flag compatibility problems in code that may happen to work
> locally.  There are already real compilers that do this for the limited
> problem of memory allocation -- i.e. overwriting deleted data with a pattern
> or making it inaccessible.
>
> Doing this for every documented C++ feature seems to be a much bigger
> problem, perhaps infeasible.  I suppose such a compiler would have to
> twist the RTTI as far as possible; perhaps even by returning class names
> that can't be easily mapped to the source code names; i.e. at runtime
> select a unique but random combination of letters and digits.  Then on
> one particular run, the name of int might be "X1", the name of long might
> be "3UR23", the name of class istream might be "3UR2", etc.!

[SNIP]

 I would definitely welcome such a tool! Not only would it be great for
testing portability, but it would also allow one to be fiendish in the
classroom  :-)  !

  Hubert Holin
  Hubert.Holin@Bigfoot.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker <petebecker@acm.org> writes:

|>  jkanze@otelo.ibmmail.com wrote:
|>  >
|>  > Using a strcmp on the results of name() is not guaranteed to work, as
|>  > far as I can tell.
|>
|>  Not for users. But it's OK for an implementation to do this, provided
|>  that it guarantees that names are, in fact, unique.

But I'm not an implementation.  Probably the most frequent use I make of
type_info like structures (only type_info like, since not all compilers
support RTTI at present) is as an index into a map.  Of course, if it is
an STL map, there is no problem -- I use before as an ordering
function.  But if I want to use a hash map, I'm out of luck, since there
is no way of getting a usable hash value.  (I have a function for
calculating a hash value from a void* in my portability kit.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

stephen.clamage@Sun.COM (Steve Clamage) writes:

|>  The lifetime of a type_info object is required to extend to the end
|>  of the program. You can safely keep pointers and references to the
|>  original object.

Is the lifetime of the char array pointed to by the return value of
type_info::name() also so guaranteed.  (It's a horrible thought, but
would it be legal for an implementation to have all calls to
type_info::name() return a pointer to a static buffer, which got
overwritten on each call.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

J. Kanze wrote:
>
> Is the lifetime of the char array pointed to by the return value of
> type_info::name() also so guaranteed.  (It's a horrible thought, but
> would it be legal for an implementation to have all calls to
> type_info::name() return a pointer to a static buffer, which got
> overwritten on each call.)

Any implementation that claims to work in a multi-threaded environment
would have to store all its type names as constant strings.

It just goes to show you, it's impossible to write a standard in which
every possibility is spelled out in advance.

--

Ciao,
Paul
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Alexandre Oliva wrote:
>
> type_infos, OTOH, have a direct correspondence with
> actual types

Is that entirely true? Obviously, two different types will never return
the same type_info, but isn't it expressly legal for the same type to
return different typeinfo objects at different times, as long as they
compare equal with operator==?

If so, I think this is in order to accommodate dumb linkers that have no
mechanism for ensuring that only a single copy of a type_info will be
kept when multiple modules introduce it. It's too bad, because if the
linker could be counted on to be this smart, then type_infos would
become atoms, and operator== could be implemented as a simple address
comparison (as could operator<). This would vastly speed up programs
that use type_infos as map keys, for instance--especially if the
alternative is to do a strcmp on the name strings, which is what Borland
does. Incidentally, I don't really understand why Borland does that,
since its linker is smart enough to ensure the uniqueness of type_info
objects.

--

Ciao,
Paul


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul D. DeRocco wrote:
>
> Incidentally, I don't really understand why Borland does that,
> since its linker is smart enough to ensure the uniqueness of type_info
> objects.

 It's because of DLLs. The linker doesn't see the contents of a DLL, so
can't merge duplicate objects.
 Note, however, that the first part of the test for equality is checking
whether the two references refer to the same object. It's only if they
don't that the names are compared.
 -- Pete
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3578C2EA.18AA8308@ix.netcom.com>,
  "Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:
>
> Alexandre Oliva wrote:
> >
> > type_infos, OTOH, have a direct correspondence with
> > actual types
>
> Is that entirely true? Obviously, two different types will never return
> the same type_info, but isn't it expressly legal for the same type to
> return different typeinfo objects at different times, as long as they
> compare equal with operator==?
>
> If so, I think this is in order to accommodate dumb linkers that have no
> mechanism for ensuring that only a single copy of a type_info will be
> kept when multiple modules introduce it. It's too bad, because if the
> linker could be counted on to be this smart, then type_infos would
> become atoms, and operator== could be implemented as a simple address
> comparison (as could operator<). This would vastly speed up programs
> that use type_infos as map keys, for instance--especially if the
> alternative is to do a strcmp on the name strings, which is what Borland
> does. Incidentally, I don't really understand why Borland does that,
> since its linker is smart enough to ensure the uniqueness of type_info
> objects.

Using a strcmp on the results of name() is not guaranteed to work, as
far as I can tell.  There is no guarantee that two different types
have different names.  For map, the correct function to use is below.
And an implementation which does ensure that there is only a single
instance for each type can legally implement below as a comparison
of the this pointers, I believe.

Of course, if you want a hash_map (as I usually do), then you're out
of luck.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker wrote:
>
> Paul D. DeRocco wrote:
> >
> > Incidentally, I don't really understand why Borland does that,
> > since its linker is smart enough to ensure the uniqueness of type_info
> > objects.
>
>         It's because of DLLs. The linker doesn't see the contents of a DLL, so
> can't merge duplicate objects.

On re-reading, this needs a bit of clarification:

When linking an executable, the linker doesn't see the contents of the
DLLs that the executable uses, so it can't merge objects that are
duplicated in different DLLs.
 -- Pete


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jkanze@otelo.ibmmail.com wrote:
>
> Using a strcmp on the results of name() is not guaranteed to work, as
> far as I can tell.

Not for users. But it's OK for an implementation to do this, provided
that it guarantees that names are, in fact, unique.


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Why the class std::type_info is designed to be prevent copying?
I read 'The C++ programing language 3rd edi.'. And in section 15.4.4, RTTI
is described. I would like to use such a kind of map as map< type_info, ...
>, so I've first created the helper class as followings.

class my_type_info {
private :
    const type_info* info ;
public :
    my_type_info() : info( 0 ) {}
    my_type_info( const type_info& sorc ) : info( &sorc ) {}
    my_type_info( const my_type_info& sorc ) : info( sorc.info ) {}
    my_type_info& operator =( const my_type_info& sorc ) { info = sorc.info
;
    }
    bool operator ==( const my_type_info& another ) {
        return *info == *another.info ;
    }
    bool operator <( const my_type_info& another ) {
        return info->before( *another.info ) ;
    }
    bool operator !=( .....
    bool operator >( .....
    .....
} ;

Now map< my_type_info, ... > is well-defined. But I'm not sure which we may
assume the return value of typeid() refers to something of temporary object
or global static object. If it is temporary object, the design of the class
my_type_info is bad. But Stroustrup's description of p.415 seems to say that
type_info objects are global objects. Can we assume so? No example there
bind the type_info object in any const references nor const pointers.

Secondly, for safety I decide to design my map to be the form map< const
char*, ... > where const char* is a string pointer got by
typeid(...).name(). This is just as Stroustrup's example. Here I assume that
C-strings got by typeid(...).name() will never go. Again, can we assume so?

Thanks to your help.

Hiroshi ODA
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

HiroshiOda wrote:

> Secondly, for safety I decide to design my map to be the form map< cons=
t
> char*, ... > where const char* is a string pointer got by
> typeid(...).name().=20

Note that type_info.name() returns an implementation-defined=20
NTBS. There is no requirement that different types be=20
associated with different NTBS. A conforming implementation=20
could return "Gotcha!" for every type. IMHO, this makes it a
poor choice as a `safe' key.

>         This is just as Stroustrup's example. Here I assume that
> C-strings got by typeid(...).name() will never go. Again, can we assume=
 so?

hmmm, I just had a look and don't think BS encourages using
typeid(...).name() as a key although there is a somewhat=20
confusing leap between p 415 and p 416 (3rd printing).

--
Christian Millour                 mailto:chris161@club-internet.fr
Ing=E9nieur Conseil en Informatique     Tel/Fax:+33 [0]1 30 21 22 80
32 rue Edouard Charton         78000 Versailles             FRANCE


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article 0@210.134.196.10, "HiroshiOda" <HiroshiOda@root.or.jp> writes:
>
>Why the class std::type_info is designed to be prevent copying?

To allow implementors maximum freedom in the implementation, and
because there doesn't seem to be any need for copies. In particular,
you can get only pointers and references to a type_info object,
and the actual object might be of a class derived from type_info.
If you could copy it, you'd get a slice, which would not have
the same properties as the original.

> ... I'm not sure which we may
>assume the return value of typeid() refers to something of temporary object
>or global static object.

The lifetime of a type_info object is required to extend to the end
of the program. You can safely keep pointers and references to the
original object.

---
Steve Clamage, stephen.clamage@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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35727d32.0@210.134.196.10>, "HiroshiOda"
<HiroshiOda@root.or.jp> wrote:

> Why the class std::type_info is designed to be prevent copying?
> I read 'The C++ programing language 3rd edi.'. And in section 15.4.4, RTTI
> is described. I would like to use such a kind of map as map< type_info, ...
> >, so I've first created the helper class as followings.
>
> class my_type_info {
> private :
>     const type_info* info ;
> public :
>     my_type_info() : info( 0 ) {}
>     my_type_info( const type_info& sorc ) : info( &sorc ) {}
>     my_type_info( const my_type_info& sorc ) : info( sorc.info ) {}
>     my_type_info& operator =( const my_type_info& sorc ) { info = sorc.info
> ;
>     }
>     bool operator ==( const my_type_info& another ) {
>         return *info == *another.info ;
>     }
>     bool operator <( const my_type_info& another ) {
>         return info->before( *another.info ) ;
>     }
>     bool operator !=( .....
>     bool operator >( .....
>     .....
> } ;
>
> Now map< my_type_info, ... > is well-defined. But I'm not sure which we may
> assume the return value of typeid() refers to something of temporary object
> or global static object. If it is temporary object, the design of the class
> my_type_info is bad. But Stroustrup's description of p.415 seems to say that
> type_info objects are global objects. Can we assume so? No example there
> bind the type_info object in any const references nor const pointers.
>
> Secondly, for safety I decide to design my map to be the form map< const
> char*, ... > where const char* is a string pointer got by
> typeid(...).name(). This is just as Stroustrup's example. Here I assume that
> C-strings got by typeid(...).name() will never go. Again, can we assume so?
>
> Thanks to your help.

I believe that your design is safe.  The standard says:

1 The result of a typeid expression is an lvalue of  static  type  const
  std::type_info (_lib.type.info_) and dynamic type const std::type_info
  or const name where name is an  implementation-defined  class  derived
  from   std::type_info   which  preserves  the  behavior  described  in
  _lib.type.info_.9) The lifetime of  the  object  referred  to  by  the
  lvalue extends to the end of the program.  Whether or not the destruc-
  tor is called for the type_info object at the end of  the  program  is
  unspecified.

The comment about the lifetime of the object, I believe, guarantees that
info will always be pointing to a valid type_info (as long as it starts
out that way).

-Howard


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

HiroshiOda  <HiroshiOda@root.or.jp> writes:

> Why the class std::type_info is designed to be prevent copying?

Because implementations are free to internally subclass
std::type_info.

> Now map< my_type_info, ... > is well-defined. But I'm not sure which we may
> assume the return value of typeid() refers to something of temporary object
> or global static object.

[expr.typeid]/1 says the lifetime of an type_info object returned by a
typeid expression extends to the end of the program.

> Here I assume that C-strings got by typeid(...).name() will never
> go. Again, can we assume so?

Yes, but have in mind that an implementation is free to always return
an empty string.  type_infos, OTOH, have a direct correspondence with
actual types, and they are even totally ordered by the member function
before.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]