g++ 2.95 typeinfo::name()

g++ 2.95 typeinfo::name()

[Kellogg, Oliver]

Hi,

Is it correct that the typeinfo::name() method of g++-2.95 
returns a number, i.e. the length of following characters, 
prefixed to the actual name?

// This program:

#include <typeinfo>
#include <string>
#include <iostream>

class myclass {
  public:
    int i;
};

int main ()
{
  string s;
  myclass m;

  s = typeid (m).name ();
  cout << s.c_str () << endl;

  return 0;
}

// produces:
//    7myclass

FYI, other C++ compilers, e.g. Rational C++ 3.0.0b, 
return the name but without the length prefix.

Thanks,

Oliver M. Kellogg
-- oliver dot kellogg at vs dot dasa dot de

Re: g++ 2.95 typeinfo::name()

[Alexandre Oliva]

On Jan 22, 2001, "Kellogg, Oliver" <Oliver.Kellogg@vs.dasa.de> wrote:

> Is it correct that the typeinfo::name() method of g++-2.95 
> returns a number, i.e. the length of following characters, 
> prefixed to the actual name?

Yep.  It would also be correct if it just returned an empty string for
all types.

GCC chooses to return the mangled type name, because it is unique and
relatively compact, instead of returning a printable canonicalized
type name.  But this might be changed at any time, and you probably
shouldn't rely on it.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: g++ 2.95 typeinfo::name()

[rssh]

On 22 Jan 2001, Alexandre Oliva wrote:

> On Jan 22, 2001, "Kellogg, Oliver" <Oliver.Kellogg@vs.dasa.de> wrote:
> 
> > Is it correct that the typeinfo::name() method of g++-2.95 
> > returns a number, i.e. the length of following characters, 
> > prefixed to the actual name?
> 
> Yep.  It would also be correct if it just returned an empty string for
> all types.

 No.   must be true:

 typeof(x)==typeof(y)  <=> typeof(x).name equal typeof(y).name()


> 
> GCC chooses to return the mangled type name, because it is unique and
> relatively compact, instead of returning a printable canonicalized
> type name.  But this might be changed at any time, and you probably
> shouldn't rely on it.
> 
> -- 
> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
> CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
> Free Software Evangelist    *Please* write to mailing lists, not to me
> 

Re: g++ 2.95 typeinfo::name()

[Alexandre Oliva]

On Jan 22, 2001, <rssh@gvinpin.grad.kiev.ua> wrote:

> On 22 Jan 2001, Alexandre Oliva wrote:

>> Yep.  It would also be correct if it just returned an empty string for
>> all types.

>  No.   must be true:

>  typeof(x)==typeof(y)  <=> typeof(x).name equal typeof(y).name()

Nope.  All the standard says is that the result of type_info::name()
is an implementation-defined null-terminated byte string.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: g++ 2.95 typeinfo::name()

[Gabriel Dos Reis]

<rssh@gvinpin.grad.kiev.ua> writes:

| On 22 Jan 2001, Alexandre Oliva wrote:
| 
| > On Jan 22, 2001, "Kellogg, Oliver" <Oliver.Kellogg@vs.dasa.de> wrote:
| > 
| > > Is it correct that the typeinfo::name() method of g++-2.95 
| > > returns a number, i.e. the length of following characters, 
| > > prefixed to the actual name?
| > 
| > Yep.  It would also be correct if it just returned an empty string for
| > all types.
| 
|  No.   must be true:
| 
|  typeof(x)==typeof(y)  <=> typeof(x).name equal typeof(y).name()

There is nothing named typeof in C++, so what?

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

RE: g++ 2.95 typeinfo::name()

[Mike Stump]

> From: dewar@gnat.com
> To: dewar@gnat.com, dvv@egcs.dvv.ru, jcast@ou.edu, mrs@windriver.com
> Cc: gcc@gcc.gnu.org
> Date: Tue, 23 Jan 2001 09:41:16 -0500 (EST)

> The qsort example misses my point. I am all if favor of doing useful
> things, but the argument that the standard requires doing "useful"
> things, or "deterministic" things is confused.

I don't recall seeing that argument being made, perhaps you can quote
where you thought that was being made.  I think the argument was, `It
seems to me that there has to be some kind of deterministic behavior'
and `Nothing wrong with documenting it. More than that - if you make
this behavior deterministic beyond the scope of the standard, you
really want to not just document it, but also to put considerable
effort into making the compiler detect uses of this determinism and
warn the user about all detected attempts. Then it will be real user
support'

> If you want to argue from the standard,

We aren't.

> If you want to argue on the basis of what is useful, regardless of
> the standard, then that's fine too.

Ok.  No point in arguing, we are in violent agreement.

> In fact I assume that a typical qsort is quadratic in the worst case,
> though hopefully not in the average case.

I was talking about all cases, not worst case.

> I am not clear what the standard has to say about qsort if anything,
> so I would have to look that up.

The one I was reading didn't prohibit one that was quadratic in all
cases.  You mileage, I mean, standard, mary vary.

> I think there is merit in being absolutely clear on what the standard
> does and does not require.

I don't see any disagreement in what the standard says.  Is there any,
was there ever any?

RE: g++ 2.95 typeinfo::name()

[dewar]

The qsort example misses my point. I am all if favor of doing useful
things, but the argument that the standard requires doing "useful"
things, or "deterministic" things is confused. If you want to argue
from the standard, fine, but then you must do it properly.

If you want to argue on the basis of what is useful, regardless of
the standard, then that's fine too.

In fact I assume that a typical qsort is quadratic in the worst case,
though hopefully not in the average case. I am not clear what the
standard has to say about qsort if anything, so I would have to look
that up.

I think there is merit in being absolutely clear on what the standard
does and does not require.

This is particularly relevant when it comes to optimization issues.

Many users may find it unuseful for the optimizer to do things that
are allowed by the standard, but in practice unexpected, e.g. a fair
number of C programs assume wrap semantics for signed integer
arithmetic, and an optimizer that propagated unexpected information
from knowing that integer arithmetic will never overflow might be
considered "unuseful" by some.

So all I was saying here is that it is important to be very clear
on whether you are arguing from the standard or not. And in particular,
if you *are* arguing from the standard, then

a) there is no concept of preferring a "useful" behavior on undefined
or implementation defined actions, that is outside the scope of the standard.

b) there is no concept of preferring a "deterministic" behavior on undefined
or implementation defined actions, that is outside the scope of the standard.

I *do* agree that the mere fact that something is allowed by the standard
is not an argument *for* doing it!

RE: g++ 2.95 typeinfo::name()

[Mike Stump]

> From: dewar@gnat.com
> To: dvv@egcs.dvv.ru, jcast@ou.edu
> Cc: gcc@gcc.gnu.org
> Date: Tue, 23 Jan 2001 00:57:50 -0500 (EST)

> Where do you deduce that the semantics must be deterministic?

Blink.

This is silly.  It is as silly as saying that a qsort function that
was quadratic wasn't buggy.  If you want to argue your point, explain
to all of us why an implementation that offered a qsort function that
was quadratic would not be buggy.  It is silly because it is a waste
of time; there isn't a proposal on the table to break name().

Re: g++ 2.95 typeinfo::name()

[Mike Stump]

> From: dewar@gnat.com
> To: jbuck@racerx.synopsys.com, mrs@windriver.com
> Cc: Oliver.Kellogg@vs.dasa.de, aoliva@redhat.com, gcc@gcc.gnu.org,
>         gdr@codesourcery.com, rssh@gvinpin.grad.kiev.ua
> Date: Tue, 23 Jan 2001 00:51:11 -0500 (EST)

> Taking out a useful implementation and replacing it by a useless one
> would be a regression.

> Nope, and nope.

In the first case, yes the expectation is that implementors will vend
implementations with as much quality as they can stand to offer,
honest.

If the second case, if what you said were the case than a qsort
function that takes quadratic time would not be a regression.  I dare
you to try and perpetrate that on users and get away with it.  Go try
it, you will discover Joe is right and that you are wrong.

> who is to judge what is useful and not useful,

The maintainer acting on some sort of behalf of the users working in
conjunction with other implementors, and more loosely with other users
of other implementations.  This is as it has always been, and will
always be.

> I don't think we can simply say that the standard says that impl
> defined things must do what Joe thinks is useful :-)

That's right, but we can say that what gcc should do what Joe says is
useful.

This whole thread is silly.  It is silly because it is a waste of
time; we have no serious proposal to break name() to return empty
strings.

Re: g++ 2.95 typeinfo::name()

[Kellogg, Oliver]

dewar at gnat dot com wrote:

>   Some would argue that "useful
> " implementations of impl-defined stuff are inherently undesirable
> since they encourage non-portable programming, so who is to judge
> what is useful and not useful, [...]

Here is what I was trying to do.

template <class Interface>
class T {
  private:
    string _name;
  public:
    T () : _name (typeid (Interface).name ()) {}
    virtual ~T () {}
    const char *name () const { return _name.c_str (); }
    void export_to_corba_naming_service ();
};

The export method exports the _name to a CORBA naming service.
Importers have knowledge of the class name, but do not have 
knowledge of the convention used by the particular RTTI 
system for determining this name. I guess what I'm saying is 
I may not do stuff like this. Thus, the typeinfo::name() is 
useless in this particular case.

Thanks.

Oliver M. Kellogg

RE: g++ 2.95 typeinfo::name()

[dewar]

<<I'm sorry; maybe I'm missing something.  I thought the discussion was about
a *required* function with undefined semantics.  It seems to me that there
has to be some kind of deterministic behavior.  If this behavior exists,
what is wrong with documenting it?
>>

Where do you deduce that the semantics must be deterministic?

Re: g++ 2.95 typeinfo::name()

[dewar]

<<The standard only sets a minimum requirement.  When the standard says
that a feature may be implemented in an implementation-defined manner,
the assumption was that the feature be implemented in an
implementation-defined useful way, not an implementation-defined useless
way.

Taking out a useful implementation and replacing it by a useless one
would be a regression.
>>

Nope, and nope. There is no such implication in the language of the
standard, and no such requirement. Some would argue that "useful
" implementations of impl-defined stuff are inherently undesirable
since they encourage non-portable programming, so who is to judge
what is useful and not useful, I don't think we can simply say that
the standard says that impl defined things must do what Joe thinks
is useful :-)

Re: g++ 2.95 typeinfo::name()

[Dima Volodin]

On Mon, 22 Jan 2001 19:19:44 -0800 (PST), you wrote:

>And in this case, I felt it was more of the fact that enough had been
>invented in committee (this is a bad thing) and we wanted to not think
>about what additional stuff we'd have to invent to spec name() and
>that that we were sloppy in not requiring strcmp(name) iff typeid ==.
>We all _knew_ this is what we meant, no contention, which made it less
>likely that we'd spend time to clarify it.  Things were we only
>thought we knew what we meant that were sloppy (templates for example)
>got time.

It's been quite a while since the train left the station, so there's no
point in explaining yourself now.


Dima

Re: g++ 2.95 typeinfo::name()

[Mike Stump]

> From: Tim Hollebeek <tim@hollebeek.com>
> To: dvv@egcs.dvv.ru (Dima Volodin)
> Date: Mon, 22 Jan 2001 20:31:40 -0500 (EST)

> Seriously, standards writers leave things implementation-defined
> because 1. certain things legitimately are compiler or system
> dependent, and 2. standards writers trust compiler writers to chose
> reasonable implementations in these areas.

And in this case, I felt it was more of the fact that enough had been
invented in committee (this is a bad thing) and we wanted to not think
about what additional stuff we'd have to invent to spec name() and
that that we were sloppy in not requiring strcmp(name) iff typeid ==.
We all _knew_ this is what we meant, no contention, which made it less
likely that we'd spend time to clarify it.  Things were we only
thought we knew what we meant that were sloppy (templates for example)
got time.

Re: g++ 2.95 typeinfo::name()

[Gabriel Dos Reis]

Jon Cast <jcast@ou.edu> writes:

| Dima Volodin wrote:
| 
| >>And users shouldn't claim the compiler has a bug when it just
| >>implements an implementation-defined semantics the way it thinks
| >>useful for its purposes.
| 
| And compiler authors should remember that compilers exist to support users,
| not to give the maintainers something to do.

Nobody is saying the contrary.

| >And adding some "useful semantics" not defined in the standard to
| >standard features is asking for exactly this type of claims.
| 
| I'm sorry; maybe I'm missing something.  I thought the discussion was about
| a *required* function with undefined semantics.

There was no discussion about undefined semantics.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: g++ 2.95 typeinfo::name()

[Joe Buck]

> Dima, you're acting like a moron.

Even though I strongly disagree with Dima's proposals, I ask people
not to call each other morons on this list.

Re: g++ 2.95 typeinfo::name()

[Tim Hollebeek]

Dima Volodin writes ...
> 
> >And users shouldn't claim the compiler has a bug when it just
> >implements an implementation-defined semantics the way it thinks
> >useful for its purposes.
> 
> And adding some "useful semantics" not defined in the standard to
> standard features is asking for exactly this type of claims.

Dima, you're acting like a moron.

The minimum behavior mandated by the standard, x.name() returning ""
for all x, would generate tons of questions along the lines of:

1) gcc is broken on my system, x.name() always returns "" 
2) gcc implements x.name().  if it always returns the same thing, what's the point in having it?

etc ad nauseum.  What you propose would actually INCREASE the number
of false bug reports, so your argument about "asking for exactly this
sort of claim" is nonsensical.

So please shut up.

Seriously, standards writers leave things implementation-defined
because 1. certain things legitimately are compiler or system
dependent, and 2. standards writers trust compiler writers to chose
reasonable implementations in these areas.  This is perfectly natural,
as is warning about programs that depending on implementation-defined
behavior to increase portability, etc.  But sticking one's head in the
sand (or elsewhere) and stubbornly claiming implementation defined
behavior shouldn't exist is moronic.

Re: g++ 2.95 typeinfo::name()

[Dima Volodin]

On Mon, 22 Jan 2001 15:45:59 -0600, you wrote:

>Dima Volodin wrote:
>
>>>And users shouldn't claim the compiler has a bug when it just
>>>implements an implementation-defined semantics the way it thinks
>>>useful for its purposes.
>
>And compiler authors should remember that compilers exist to support users,
>not to give the maintainers something to do.
>
>>And adding some "useful semantics" not defined in the standard to
>>standard features is asking for exactly this type of claims.
>
>I'm sorry; maybe I'm missing something.  I thought the discussion was about
>a *required* function with undefined semantics.  It seems to me that there
>has to be some kind of deterministic behavior.  If this behavior exists,
>what is wrong with documenting it?

Nothing wrong with documenting it. More than that - if you make this
behavior deterministic beyond the scope of the standard, you really want
to not just document it, but also to put considerable effort into making
the compiler detect uses of this determinism and warn the user about all
detected attempts. Then it will be real user support.


Anyway, why would anyone want to compare type_info::name() strings?
What's wrong with typeid()?

>>Dima
>Jon Cast

Dima

Re: g++ 2.95 typeinfo::name()

[Mike Stump]

> To: Joe Buck <jbuck@racerx.synopsys.com>
> From: Gabriel Dos Reis <gdr@codesourcery.com>
> Date: 22 Jan 2001 21:56:18 +0100

> | Some developers seem to think that if the standard permits us to implement
> | a feature in a useless way, and we do so, that we therefore do not have
> | a bug.

> Do you think GCC current behaviour is useless?

He meant returning "" would be a good example of such a useless
behavior.  gcc doesn't do that.  This thread is now silly.  If people
want to continue it, please explain what aspect of the thread isn't
silly, and if you can find none, please continue it in private.

RE: g++ 2.95 typeinfo::name()

[Jon Cast]

Dima Volodin wrote:

>>And users shouldn't claim the compiler has a bug when it just
>>implements an implementation-defined semantics the way it thinks
>>useful for its purposes.

And compiler authors should remember that compilers exist to support users,
not to give the maintainers something to do.

>And adding some "useful semantics" not defined in the standard to
>standard features is asking for exactly this type of claims.

I'm sorry; maybe I'm missing something.  I thought the discussion was about
a *required* function with undefined semantics.  It seems to me that there
has to be some kind of deterministic behavior.  If this behavior exists,
what is wrong with documenting it?

>Dima

Jon Cast

Re: g++ 2.95 typeinfo::name()

[Dima Volodin]

On 22 Jan 2001 22:00:01 +0100, you wrote:

>Jon Cast <jcast@ou.edu> writes:
>
>| Dima Volodin wrote:
>| > >The standard is irrelevant in this case.  What Oliver said must be
>| >>true, must be true, really.  Just meeting the standard is fine in many
>| >>cases, however, at times, we do want to do more than the standard.
>| 
>| >Doing that encourages writing of non-compliant and non-portable code,
>| >which is bad, really bad.
>| 
>| I hate to butt in here, being relatively new to this list, but it seems to
>| me that imposing brain-damaged restrictions is what would be bad.  I don't
>| have any problem with extensions, as long as they're clean and clearly
>| documented as such.  What I have a problem with is providing nearly useless
>| "features" because ISO doesn't provide useful semantics.  Standards are
>| great tools /for the user/.   They shouldn't get in the user's way.
>
>And users shouldn't claim the compiler has a bug when it just
>implements an implementation-defined semantics the way it thinks
>useful for its purposes.

And adding some "useful semantics" not defined in the standard to
standard features is asking for exactly this type of claims.

>-- Gaby

Dima

Re: g++ 2.95 typeinfo::name()

[Gabriel Dos Reis]

Jon Cast <jcast@ou.edu> writes:

| Dima Volodin wrote:
| > >The standard is irrelevant in this case.  What Oliver said must be
| >>true, must be true, really.  Just meeting the standard is fine in many
| >>cases, however, at times, we do want to do more than the standard.
| 
| >Doing that encourages writing of non-compliant and non-portable code,
| >which is bad, really bad.
| 
| I hate to butt in here, being relatively new to this list, but it seems to
| me that imposing brain-damaged restrictions is what would be bad.  I don't
| have any problem with extensions, as long as they're clean and clearly
| documented as such.  What I have a problem with is providing nearly useless
| "features" because ISO doesn't provide useful semantics.  Standards are
| great tools /for the user/.   They shouldn't get in the user's way.

And users shouldn't claim the compiler has a bug when it just
implements an implementation-defined semantics the way it thinks
useful for its purposes.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: g++ 2.95 typeinfo::name()

[Gabriel Dos Reis]

Joe Buck <jbuck@racerx.synopsys.com> writes:

| > > | The standard is irrelevant in this case.  What Oliver said must be
| > > | true, must be true, really.  Just meeting the standard is fine in many
| > > | cases, however, at times, we do want to do more than the standard.
| > 
| > > You're making a wish and I understand that.
| 
| Mike Stump writes:
| > No, I'm doing more than that.  I am stating a release requirement, and
| > also stating the current behavior of our compiler, and I suspect every
| > C++ compiler out there.
| > 
| > > But that doesn't make the current behaviour a bug as far as the
| > > standard is concerned.
| > 
| > I know that.  Maybe you thought I was commenting on the demangled
| > version of the name, I was not.  I was merely commenting on the
| > already implemented behavior of the compiler and Alexandre's remark.
| 
| Some developers seem to think that if the standard permits us to implement
| a feature in a useless way, and we do so, that we therefore do not have
| a bug.

Do you think GCC current behaviour is useless?

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

RE: g++ 2.95 typeinfo::name()

[Jon Cast]

Dima Volodin wrote:
> >The standard is irrelevant in this case.  What Oliver said must be
>>true, must be true, really.  Just meeting the standard is fine in many
>>cases, however, at times, we do want to do more than the standard.

>Doing that encourages writing of non-compliant and non-portable code,
>which is bad, really bad.

I hate to butt in here, being relatively new to this list, but it seems to
me that imposing brain-damaged restrictions is what would be bad.  I don't
have any problem with extensions, as long as they're clean and clearly
documented as such.  What I have a problem with is providing nearly useless
"features" because ISO doesn't provide useful semantics.  Standards are
great tools /for the user/.   They shouldn't get in the user's way.
Jon Cast

Re: g++ 2.95 typeinfo::name()

[Gabriel Dos Reis]

Mike Stump <mrs@windriver.com> writes:

[...]

| > But that doesn't make the current behaviour a bug as far as the
| > standard is concerned.
| 
| I know that.  Maybe you thought I was commenting on the demangled
| version of the name, I was not.

That wasn't clear from your message.  Maybe that is just me but it
seems others did understand your statement as I...

It would be desirable, for the purpose of avoiding confusion, that in
comments like yours you did make clear what you think a bug, and what
you think is a QoI the compiler should improve on...

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: g++ 2.95 typeinfo::name()

[Joe Buck]

> > | The standard is irrelevant in this case.  What Oliver said must be
> > | true, must be true, really.  Just meeting the standard is fine in many
> > | cases, however, at times, we do want to do more than the standard.
> 
> > You're making a wish and I understand that.

Mike Stump writes:
> No, I'm doing more than that.  I am stating a release requirement, and
> also stating the current behavior of our compiler, and I suspect every
> C++ compiler out there.
> 
> > But that doesn't make the current behaviour a bug as far as the
> > standard is concerned.
> 
> I know that.  Maybe you thought I was commenting on the demangled
> version of the name, I was not.  I was merely commenting on the
> already implemented behavior of the compiler and Alexandre's remark.

Some developers seem to think that if the standard permits us to implement
a feature in a useless way, and we do so, that we therefore do not have
a bug.

The standard only sets a minimum requirement.  When the standard says
that a feature may be implemented in an implementation-defined manner,
the assumption was that the feature be implemented in an
implementation-defined useful way, not an implementation-defined useless
way.

Taking out a useful implementation and replacing it by a useless one
would be a regression.

Re: g++ 2.95 typeinfo::name()

[Dima Volodin]

On Mon, 22 Jan 2001 10:31:08 -0800 (PST), you wrote:

>> To: <rssh@gvinpin.grad.kiev.ua>
>> Cc: "Kellogg, Oliver" <Oliver.Kellogg@vs.dasa.de>,
>>         "'gcc@gcc.gnu.org'" <gcc@gcc.gnu.org>
>> From: Alexandre Oliva <aoliva@redhat.com>
>> Date: 22 Jan 2001 10:58:25 -0200
>
>> On Jan 22, 2001, <rssh@gvinpin.grad.kiev.ua> wrote:
>
>> > On 22 Jan 2001, Alexandre Oliva wrote:
>
>> >> Yep.  It would also be correct if it just returned an empty string for
>> >> all types.
>
>> >  No.   must be true:
>
>> >  typeof(x)==typeof(y)  <=> typeof(x).name equal typeof(y).name()
>
>> Nope.  All the standard says is that the result of type_info::name()
>> is an implementation-defined null-terminated byte string.
>
>The standard is irrelevant in this case.  What Oliver said must be
>true, must be true, really.  Just meeting the standard is fine in many
>cases, however, at times, we do want to do more than the standard.

Doing that encourages writing of non-compliant and non-portable code,
which is bad, really bad.


Dima

Re: g++ 2.95 typeinfo::name()

[Mike Stump]

> To: Mike Stump <mrs@windriver.com>
> Cc: aoliva@redhat.com, rssh@gvinpin.grad.kiev.ua, Oliver.Kellogg@vs.dasa.de,
>         gcc@gcc.gnu.org
> From: Gabriel Dos Reis <gdr@codesourcery.com>
> Date: 22 Jan 2001 19:45:43 +0100

> | The standard is irrelevant in this case.  What Oliver said must be
> | true, must be true, really.  Just meeting the standard is fine in many
> | cases, however, at times, we do want to do more than the standard.

> You're making a wish and I understand that.

No, I'm doing more than that.  I am stating a release requirement, and
also stating the current behavior of our compiler, and I suspect every
C++ compiler out there.

> But that doesn't make the current behaviour a bug as far as the
> standard is concerned.

I know that.  Maybe you thought I was commenting on the demangled
version of the name, I was not.  I was merely commenting on the
already implemented behavior of the compiler and Alexandre's remark.

Re: g++ 2.95 typeinfo::name()

[Theodore Papadopoulo]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

mrs@windriver.com said:
>> >> Yep.  It would also be correct if it just returned an empty string
>> for
>> >> all types.

>> >  No.   must be true:

>> >  typeof(x)==typeof(y)  <=> typeof(x).name equal typeof(y).name()

>> Nope.  All the standard says is that the result of type_info::name()
>> is an implementation-defined null-terminated byte string.

> The standard is irrelevant in this case.  What Oliver said must be
> true, must be true, really.  Just meeting the standard is fine in many
> cases, however, at times, we do want to do more than the standard. 

Well, I interpreted that in a different way. name() can always be an 
empty string but different types get different empty strings so that 
the pointers are not equal. Everything lies in the type of equality 
used !! Thus, my belief is that Alexandre is totally right...

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------



[-- Attachment #2: pgp00000.pgp --]
[-- Type: text/plain, Size: 1390 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii


mrs@windriver.com said:
>> >> Yep.  It would also be correct if it just returned an empty string
>> for
>> >> all types.

>> >  No.   must be true:

>> >  typeof(x)==typeof(y)  <=> typeof(x).name equal typeof(y).name()

>> Nope.  All the standard says is that the result of type_info::name()
>> is an implementation-defined null-terminated byte string.

> The standard is irrelevant in this case.  What Oliver said must be
> true, must be true, really.  Just meeting the standard is fine in many
> cases, however, at times, we do want to do more than the standard. 

Well, I interpreted that in a different way. name() can always be an 
empty string but different types get different empty strings so that 
the pointers are not equal. Everything lies in the type of equality 
used !! Thus, my belief is that Alexandre is totally right...

- --------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: Exmh version 2.2 06/23/2000

iD8DBQE6bIGoIzTj8qrxOU4RAt69AKCXgBSmiM6i26krIW5GzDjMyessNACggq+4
xZWC5agWEL7rQ6vjzf3kuN0=
=ajsa
-----END PGP SIGNATURE-----

Re: g++ 2.95 typeinfo::name()

[Gabriel Dos Reis]

Mike Stump <mrs@windriver.com> writes:

| > To: <rssh@gvinpin.grad.kiev.ua>
| > Cc: "Kellogg, Oliver" <Oliver.Kellogg@vs.dasa.de>,
| >         "'gcc@gcc.gnu.org'" <gcc@gcc.gnu.org>
| > From: Alexandre Oliva <aoliva@redhat.com>
| > Date: 22 Jan 2001 10:58:25 -0200
| 
| > On Jan 22, 2001, <rssh@gvinpin.grad.kiev.ua> wrote:
| 
| > > On 22 Jan 2001, Alexandre Oliva wrote:
| 
| > >> Yep.  It would also be correct if it just returned an empty string for
| > >> all types.
| 
| > >  No.   must be true:
| 
| > >  typeof(x)==typeof(y)  <=> typeof(x).name equal typeof(y).name()
| 
| > Nope.  All the standard says is that the result of type_info::name()
| > is an implementation-defined null-terminated byte string.
| 
| The standard is irrelevant in this case.  What Oliver said must be
| true, must be true, really.  Just meeting the standard is fine in many
| cases, however, at times, we do want to do more than the standard.

You're making a wish and I understand that.  But that doesn't make the
current behaviour a bug as far as the standard is concerned.  That was
the original issue.

Sure, as far QoI is concerned there is room for improvement.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: g++ 2.95 typeinfo::name()

[Mike Stump]

> To: <rssh@gvinpin.grad.kiev.ua>
> Cc: "Kellogg, Oliver" <Oliver.Kellogg@vs.dasa.de>,
>         "'gcc@gcc.gnu.org'" <gcc@gcc.gnu.org>
> From: Alexandre Oliva <aoliva@redhat.com>
> Date: 22 Jan 2001 10:58:25 -0200

> On Jan 22, 2001, <rssh@gvinpin.grad.kiev.ua> wrote:

> > On 22 Jan 2001, Alexandre Oliva wrote:

> >> Yep.  It would also be correct if it just returned an empty string for
> >> all types.

> >  No.   must be true:

> >  typeof(x)==typeof(y)  <=> typeof(x).name equal typeof(y).name()

> Nope.  All the standard says is that the result of type_info::name()
> is an implementation-defined null-terminated byte string.

The standard is irrelevant in this case.  What Oliver said must be
true, must be true, really.  Just meeting the standard is fine in many
cases, however, at times, we do want to do more than the standard.