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

> James Kuyper wrote:
>> Excersize: guess why they didn't say that chars are unsigned.

> Because unsigned beats signed, and they didn't want the presence of a
> char value somewhere in an expression to force all calculations to be
> unsigned.

Nope, unsigned char promotes to int.

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

James Kanze (james-albert.kanze@vx.cit.alcatel.fr) wrote:
: jpotter@falcon.lhup.edu (John Potter) writes:

: |>  "Paul D. DeRocco" <strip_these_words_pderocco@ix.netcom.com> wrote:

: |>  : Frankly, I don't know why they just didn't say that chars are signed,
: |>  : dammit, and be done with it.

: |>  I have heard the same thing said about chars are unsigned.

: |>  Originally it was your way

: If originally just refers to the very first PDP-11 compiler for C, then
: you are right.  However, the language definition has allowed both from
: the start, and the second machine to get a C compiler (Interdata 8/32)
: had unsigned plain char's.  This would be sometime in the early
: seventies, before C escaped from AT&T, even, and long before ANSI or ISO
: even thought about standardizing it.  So unless you happened to be a
: close collaborator of Kernighan and Richie in the early days, the
: signedness of char has always been implementation defined.

Yes, thank you for the history lesson.  A day without learning something
is wasted.

My impression of pre ISO was that we had char which was signed and
unsigned char.  As you note it was really char which was unspecified
and unsigned char.

I still have a compiler which says "Sorry not implemented, ignored" to
signed anything.  Of course, that is cfront, and the underlying C
implementation uses plain char is unsigned giving three ways to write
unsigned char.

You made my day,
John
---
[ 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                             ]

In article <33685015.38C@ix.netcom.com>, "Paul D. DeRocco"
<strip_these_words_pderocco@ix.netcom.com> wrote:

>
>Frankly, I don't know why they just didn't say that chars are signed,
>dammit, and be done with it.

Because chars should be UNSIGNED. Most or all of the standard c library treats
chars as unsigned (see the standard).  Shouldn't the language be the same?

I agree that they should SET the type of char.
--
Darron Shaffer
Darron.Shaffer@beasys.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                             ]

James Kuyper wrote:

> Excersize: guess why they didn't say that chars are unsigned.

Because unsigned beats signed, and they didn't want the presence of a
char value somewhere in an expression to force all calculations to be
unsigned.

Perhaps this wouldn't have been an issue if they called it something
other than char, like "tiny". Then, we would have no qualms about "tiny"
being signed, and having the type of a character literal be "unsigned
tiny", and the type of a string literal be "unsigned tiny*". Oh, well...

--

Ciao,
Paul

(Please send e-mail to mailto:pderocco@ix.netcom.com instead of the
return address, which has been altered to foil junk mail senders.)
---
[ 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
]

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

|>  Frankly, I don't know why they just didn't say that chars are signed,
|>  dammit, and be done with it.

Because they have to be unsigned in order to be usable with the
functions/macros defined in ctype:-).

There was some discussion of this in the standards committee, in fact.
There was never any question of the C++ standard changing the status
quo, or course; this point would be the job of the C committee.  But
given that signed characters just don't work, I was curious as to why
the C standards committee didn't require the unsigned.

Basically, there were just too many programs out there that used plain
char for small signed integers (remember, there was no "signed char"
before ISO).  Such programs aren't (and never were) portable, but not
all programs have to be.  Requiring implementations to change the
signedness of plain char would have had the effect of breaking these
programs.

It's also worth noting that on some machines (including the PDP-11),
making a char unsigned entails significant run-time overhead.

I might point out that I don't agree with the above reasons; I
personally think that plain char should be required to be unsigned.  I'm
just pointing out the reasons given to me.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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
]

jpotter@falcon.lhup.edu (John Potter) writes:

|>  "Paul D. DeRocco" <strip_these_words_pderocco@ix.netcom.com> wrote:
|>
|>  : Frankly, I don't know why they just didn't say that chars are signed,
|>  : dammit, and be done with it.
|>
|>  I have heard the same thing said about chars are unsigned.
|>
|>  Originally it was your way

If originally just refers to the very first PDP-11 compiler for C, then
you are right.  However, the language definition has allowed both from
the start, and the second machine to get a C compiler (Interdata 8/32)
had unsigned plain char's.  This would be sometime in the early
seventies, before C escaped from AT&T, even, and long before ANSI or ISO
even thought about standardizing it.  So unless you happened to be a
close collaborator of Kernighan and Richie in the early days, the
signedness of char has always been implementation defined.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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
]

Paul D. DeRocco wrote:
...
> Frankly, I don't know why they just didn't say that chars are signed,
> dammit, and be done with it.

Because there are too many machines where unsigned characters have a
faster, simpler implementation than signed characters, and there is too
much legacy code for such machines that would need to be rewritten if
the C standard didn't allow an implementation that made 'char' unsigned.
Typically, you can count on new implementations for a given machine to
make the same sign choice, for the same reason.

Excersize: guess why they didn't say that chars are unsigned.
---
[ 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                             ]

Paul D. DeRocco wrote:
>
> Christopher Eltschka wrote:
> >
> > Well, if you store a char(*)(int,int) to disk, you probably can't even
> > use it with another program compiled on the *same* compiler - there
> > is probably no such function at this address. Depending on the platform,
> > you even might not be able to use this program in *another* invocation
> > of the *same* executable (because it might have been loaded into
> > a different address)! So, this needs not really be standardized.
> > What might make a difference is storing of the plain char itself.
> > But I guess this is not such a big problem - the letter will still
> > be the same, even if one program takes its numerical value as 192 and
> > the other as -64, as the bit-pattern on disk will be exactly the same.
>
> True, but I can imagine a situation where it might still be an issue.
> Suppose a program builds association lists (e.g., STL maps or multimaps)
> that associate the name strings returned by type_info::name() with
> pointers to functions, and then calls these functions based on names
> received from other programs, under the assumption that they'll do
> something "standard" described by their interface. This is a situation
> where one program may request the calling of a function that returns a
> char, under the assumption that it's signed, and another system may
> carry it out, producing a char that's unsigned.
>

Ok, I see the point, although a return value of char would be harmless
as well (the char would be sent to the first system as bit pattern, and
therefore would be interpreted correctly on the first system's side.
Where it would matter, would be with more than one argument of type
char, where ordering is important (i.e. it differs if c1<c2 or
c2<c1). But for this type of functions it's a better idea to use
explicitly signed or unsigned chars anyway.)

> A minor point, admittedly, but it is one more obscure case in which the
> lack of standardization can be troublesome.
>
> Frankly, I don't know why they just didn't say that chars are signed,
> dammit, and be done with it.

I guess, it's because there are too many people who would prefer that
chars are unsigned, dammit, and be done with it:-)

The problem arises from the double-use of char as character and as
number. For example, it doesn't make sense to say "'A' is greater
than zero". It makes sense to do some ordering between characters
(f. ex. 'A'<'B'), but only for helping in algorithms (f. ex. looping
through the chars, using as index [where unsigned chars are better],
etc.). If you need an "external" order, you usually need to define
it yourself anyway (f. ex. 'A'<'Z'<'a' is not acceptable in
dictionaries).
---
[ 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                             ]

James Kanze wrote:
>
> Have you ever tried instantiating an STL container over a reference?  I
> don't think it can be done.  (On the other hand, although I'm pretty
> sure that it is also the intent that it not be supported, I don't know
> off-hand any wording in the draft which says this.)

You're right, you'd have to use a pointer.

--

Ciao,
Paul

(Please send e-mail to mailto:pderocco@ix.netcom.com instead of the
return address, which has been altered to foil junk mail senders.)
---
[ 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
]

bparker@gil.com.au (Brian Parker) wrote:

>This was my original thought, to use pointers to type_info in a map,
>but the converse to the above is true- less is guaranteed to give a
>total ordering for pointers and so before() is not helpful here, and
>the address of type_info is not guaranteed to be unique and so can't
>be used as a key in map<>.
>
...
>
>chris@alofi.etca.fr (Christian Millour) wrote:
>>the following snippet is uncompiled and I don't have cd2 handy. It should
>>get you started though.
[ code elided ... ]
>
>Aha! this solves the problem- don't use type_info directly but use a
>wrapper class.

That is not necessary (although perhaps it is cleaner -- just a matter
of style):

  // Specialized less<> class for typeinfo pointers.
  // Note: this only works if your compiler supports partial
  // class template specialization:
  template <>
  class less<typeinfo*>
  {
  public:
    bool operator()(const typeinfo* a, const typeinfo* b)
    {
      return a->before(*b);
    }
  };

  class myTypeData { ... };

  map<const typeinfo*, myTypeData, less<typeinfo*> > myTypeAssociation;

Disclaimers:
1. I might have the partial-specialization syntax wrong.
2. I'm not sure if the use of const typeinfo in the last line is correct
3. This code is untested.
4. Everything in this post might be wrong.

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ 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
]

Paul D. DeRocco wrote:
>
> James Kanze wrote:
> >
> > There are always three char types, but the standard requires
> > type_info::name to be a plain char (neither the signed or unsigned
> > char).  Whether plain char is signed or unsigned is implementation
> > defined, but I really don't see where this would make a difference.
>
> I think you misunderstood me. I wasn't talking about the type returned
> by type_info::name, which is "const char*". I was talking about the
> string returned when the type is a char, or containing char somewhere in
> it. Two compilers may return a name such as "char(*)(int,int)" for some
> function pointer type, but the meaning of the return value may be
> different for the two compilers, even if they are for the same physical
> machine with the same word size.
>

Well, if you store a char(*)(int,int) to disk, you probably can't even
use it with another program compiled on the *same* compiler - there
is probably no such function at this address. Depending on the platform,
you even might not be able to use this program in *another* invocation
of the *same* executable (because it might have been loaded into
a different address)! So, this needs not really be standardized.
What might make a difference is storing of the plain char itself.
But I guess this is not such a big problem - the letter will still
be the same, even if one program takes its numerical value as 192 and
the other as -64, as the bit-pattern on disk will be exactly the same.

[...]

> > |>  2) Some machines need additional modifiers, especially on pointers
> > |>  (e.g., __near and __far), and a type_info::name() that left these out
> > |>  for the sake of compatibility with other machines would be pretty
> > |>  useless.
> >
> > These don't exist in C++, and an implementation which required the
> > programmer to be aware of them would not be conforming.  At any rate, I
> > fail to see how they would affect the external representation, which is
> > all that would have been standardized anyway.
>
> Because on such machines "char __far*" and "char __near*" really really
> are two different types, and you _can't_ call them both "char*" and have
> everything work.

Again, this is not a problem for persistence, as pointers in files
make no sense anyway. And if you need an uniform name (as *should* be
mandated for typeinfo::name for "normal"/class/template types), you'd
just dereference and add your own "pointer tag".
---
[ 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
]

Christopher Eltschka wrote:
>
> Well, if you store a char(*)(int,int) to disk, you probably can't even
> use it with another program compiled on the *same* compiler - there
> is probably no such function at this address. Depending on the platform,
> you even might not be able to use this program in *another* invocation
> of the *same* executable (because it might have been loaded into
> a different address)! So, this needs not really be standardized.
> What might make a difference is storing of the plain char itself.
> But I guess this is not such a big problem - the letter will still
> be the same, even if one program takes its numerical value as 192 and
> the other as -64, as the bit-pattern on disk will be exactly the same.

True, but I can imagine a situation where it might still be an issue.
Suppose a program builds association lists (e.g., STL maps or multimaps)
that associate the name strings returned by type_info::name() with
pointers to functions, and then calls these functions based on names
received from other programs, under the assumption that they'll do
something "standard" described by their interface. This is a situation
where one program may request the calling of a function that returns a
char, under the assumption that it's signed, and another system may
carry it out, producing a char that's unsigned.

A minor point, admittedly, but it is one more obscure case in which the
lack of standardization can be troublesome.

Frankly, I don't know why they just didn't say that chars are signed,
dammit, and be done with it.

--

Ciao,
Paul

(Please send e-mail to mailto:pderocco@ix.netcom.com instead of the
return address, which has been altered to foil junk mail senders.)
---
[ 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
]

"Paul D. DeRocco" <strip_these_words_pderocco@ix.netcom.com> wrote:

: Frankly, I don't know why they just didn't say that chars are signed,
: dammit, and be done with it.

I have heard the same thing said about chars are unsigned.

Originally it was your way and there was no need for a "signed"
reserved word.  After all, it only applies to char anyway.  Such are
compromises from which standards become.

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

John Potter wrote:
>
> "Paul D. DeRocco" <strip_these_words_pderocco@ix.netcom.com> wrote:
>
> : Frankly, I don't know why they just didn't say that chars are signed,
> : dammit, and be done with it.
>
> I have heard the same thing said about chars are unsigned.
>
> Originally it was your way and there was no need for a "signed"
> reserved word.  After all, it only applies to char anyway.  Such are
> compromises from which standards become.

In general, I find unsigned chars more useful, since they usually
represent unsigned ASCII codes. However, as you point out, it makes
sense for chars to be signed, since the other built-in types are also
signed.

However, I do use the "signed" keyword in some code. In one project
which I migrated from 16-bit to 32-bit code, I used "signed" and
"unsigned" by themselves for those variables that were best left in the
natural word size of the machine.

--

Ciao,
Paul

(Please send e-mail to mailto:pderocco@ix.netcom.com instead of the
return address, which has been altered to foil junk mail senders.)
---
[ 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 wrote:
>
> The DWP does not state every non-requirement!
> (After all, there are an infinite number of possible non-requirements.)
>
> If you can't find it, then it is not a requirement.

Yes, obviously. I was merely asking if this was an _explicit_
non-requirement (since there are some of those in the proposed
standard), since it might be easier for Bill Gibbons simply to tell me
than for me to do an exhaustive search of the proposed standard.

--

Ciao,
Paul D. DeRocco

(Please send e-mail to mail:pderocco@ix.netcom.com instead of the
return address, which has been altered to foil junk mail senders.)
---
[ 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
]

Gerard Weatherby <gerardw@alum.mit.edu> writes:

|>  Brian Parker wrote:
|>  Apart from the issue of using type_info.name() in a persistence
|>  library is the need for associating additional type information with
|>  type_info via a map, for the duration of a single programme execution.
|>  It would be useful if &typeid was guaranteed to be unique for this
|>  purpose, or alternatively if there were a member function of type_info
|>  that returned a unique integer for each distinct type.
|>  ---
|>  Doesn't the typeinfo::before function provide this capability?

That is the intent.  All of the standard associative containers (map,
set) require an ordering operator (less than); for typeid, this
relationship is given by "before".  (Note that the relationship is
arbitrary; the fact that A is "before" B tells us nothing about any real
relationship between A and B.)

Just curious (and too lazy to look it up): does the standard require a
specialization of "less" for "typeinfo"?

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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
]

James Kanze <james-albert.kanze@vx.cit.alcatel.fr> wrote:

>Gerard Weatherby <gerardw@alum.mit.edu> writes:

>|>  Brian Parker wrote:
>|>  Apart from the issue of using type_info.name() in a persistence
>|>  library is the need for associating additional type information with
>|>  type_info via a map, for the duration of a single programme execution.
>|>  It would be useful if &typeid was guaranteed to be unique for this
>|>  purpose, or alternatively if there were a member function of type_info
>|>  that returned a unique integer for each distinct type.
>|>  ---
>|>  Doesn't the typeinfo::before function provide this capability?

>That is the intent.  All of the standard associative containers (map,
>set) require an ordering operator (less than); for typeid, this
>relationship is given by "before".  (Note that the relationship is
>arbitrary; the fact that A is "before" B tells us nothing about any real
>relationship between A and B.)

>Just curious (and too lazy to look it up): does the standard require a
>specialization of "less" for "typeinfo"?

I still don't see how this helps look up associated type information
using a map.

type_info has a private copy constructor and hence can't be used
directly in a map and so before() is not useful for this purpose.

Could someone please  post a CD2-compliant example of associating
additional data with type_info?

Thanks,
Brian Parker (bparker@gil.com.au)


---
[ 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 <335AC05C.3C25@ix.netcom.com>, "Paul D. DeRocco"
<strip_these_words_pderocco@ix.netcom.com> wrote:
> I was merely asking if this was an _explicit_
> non-requirement (since there are some of those in the proposed
> standard), since it might be easier for Bill Gibbons simply to tell me
> than for me to do an exhaustive search of the proposed standard.

No, it is not explicit.  Although the original papers for RTTI implied
some rules for forming type_info names, no such rules were ever added
to the working paper.

-- Bill Gibbons
   bill@gibbons.org
---
[ 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                             ]

Brian Parker <bparker@gil.com.au> wrote in article
<5jjnii$13r2@gilnt2.ipswich.gil.com.au>...
> I still don't see how this helps look up associated type information
> using a map.
>
> type_info has a private copy constructor and hence can't be used
> directly in a map and so before() is not useful for this purpose.

But it doesn't need to be used directly.  The map can use pointers to
type_info objects as keys, and
ptr->before() in the implementation of less().  This is helpful because
there is no portable way to get an ordering (or hash) relationship among
pointers.  References returned by typeid remain valid till the end of the
program, so there is no danger of the pointer becoming stale, at least not
before end-of-program cleanup.
---
[ 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                             ]

Brian Parker wrote:

> type_info has a private copy constructor and hence can't be used
> directly in a map and so before() is not useful for this purpose.

The map can use type_info& instead of type_info, can't it?

--

Ciao,
Paul

(Please send e-mail to mailto:pderocco@ix.netcom.com instead of the
return address, which has been altered to foil junk mail senders.)
---
[ 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 <5jjnii$13r2@gilnt2.ipswich.gil.com.au>, bparker@gil.com.au (Brian Parker) writes:
|> Could someone please  post a CD2-compliant example of associating
|> additional data with type_info?

the following snippet is uncompiled and I don't have cd2 handy. It should
get you started though.

#include <typeinfo>
#include <map>

class Key {
  class Nil {};
  type_info const & rep;
public:
  Key(type_info const & arg = typeid(Nil)) : rep(arg) {}
  friend bool operator < (Key const & lhs, Key const & rhs) {
    return lhs.rep.before(rhs.rep);
  }
};

typedef map<Key, int, less<Key> > Maptype;

class foo {};
class bar {};
class qux {};

int main() {
  Maptype m;
  m[typeid(foo)] = 0;
  m[typeid(bar)] = 1;
  m[typeid(qux)] = 2;
}
---
[ 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
]

"Bill Wade" <bill.wade@stoner.com> wrote:

>Brian Parker <bparker@gil.com.au> wrote in article
><5jjnii$13r2@gilnt2.ipswich.gil.com.au>...
>> I still don't see how this helps look up associated type information
>> using a map.
>>
>> type_info has a private copy constructor and hence can't be used
>> directly in a map and so before() is not useful for this purpose.

>But it doesn't need to be used directly.  The map can use pointers to
>type_info objects as keys, and
>ptr->before() in the implementation of less().  This is helpful because
>there is no portable way to get an ordering (or hash) relationship among
>pointers.  References returned by typeid remain valid till the end of the
>program, so there is no danger of the pointer becoming stale, at least not
>before end-of-program cleanup.
>---

Yes, I see now that  a specialisation of less<type_info*> would allow
a map<type_info*, X> to be used. It wouldn't matter if references to
different type_info objects where returned for the same type, as they
would compare equal using type_info::before().

Thanks,
Brian Parker (bparker@gil.com.au)
---
[ 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                             ]

"Bill Wade" <bill.wade@stoner.com> writes:

|>  Brian Parker <bparker@gil.com.au> wrote in article
|>  <5jjnii$13r2@gilnt2.ipswich.gil.com.au>...
|>  > I still don't see how this helps look up associated type information
|>  > using a map.
|>  >
|>  > type_info has a private copy constructor and hence can't be used
|>  > directly in a map and so before() is not useful for this purpose.
|>
|>  But it doesn't need to be used directly.  The map can use pointers to
|>  type_info objects as keys, and
|>  ptr->before() in the implementation of less().  This is helpful because
|>  there is no portable way to get an ordering (or hash) relationship among
|>  pointers.

This used to be true.  However, the committee has since required a
partial specialization of less for pointers, which is required to give a
complete ordering.  (How the implementation does this is not portable,
but that's not your problem, it's theirs.)  Of course, hash is still an
open question.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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
]

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

|>  Brian Parker wrote:
|>
|>  > type_info has a private copy constructor and hence can't be used
|>  > directly in a map and so before() is not useful for this purpose.
|>
|>  The map can use type_info& instead of type_info, can't it?

Have you ever tried instantiating an STL container over a reference?  I
don't think it can be done.  (On the other hand, although I'm pretty
sure that it is also the intent that it not be supported, I don't know
off-hand any wording in the draft which says this.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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
]

Brian Parker wrote:
> I still don't see how this helps look up associated type information
> using a map.
>
> type_info has a private copy constructor and hence can't be used
> directly in a map and so before() is not useful for this purpose.
>
> Could someone please  post a CD2-compliant example of associating
> additional data with type_info?
Yea, we can do that--

#include <iostream.h>
#include <map>
#include <typeinfo>


class TypeHolder {
  public:
    TypeHolder(const typeinfo &t)
      :tinfo(t) {}
    TypeHolder(const TypeHolder &rhs)
      :tinfo(rhs.tinfo) {}
    const typeinfo & GetType( ) const { return tinfo; }
    bool operator <(const TypeHolder &rhs)
      { return tinfo.before(rhs.tinfo); }
  private:
    const typeinfo & tinfo;
};

//holds a map of type information and sizes
class Sizes {
  public:
    void AddSize(const typeinfo &,size_t);
    size_t GetSize(const typeinfo &);
  private:
    typedef std::map <TypeHolder,size_t,std::less<TypeHolder> > TypeMap;
    TypeMap typeMap;
};

template <class T>
class RegSize {
  public:
    RegSize(Sizes &sizes)
      { sizes.AddSize(typeid(T),sizeof(T)); }
};

void Sizes::AddSize(const typeinfo &t,size_t s)
{
  typeMap[TypeHolder(t)] = s;
}

size_t Sizes::GetSize(const typeinfo &t)
{
  TypeMap::iterator iter = typeMap.find(TypeHolder(t));
  if (iter == typeMap.end( ))
    return 0;
  return (*iter).second;
}

int main( )
{
  Sizes sizes;
  RegSize<int> a(sizes);
  RegSize<char> b(sizes);
  RegSize<double> c(sizes);
  RegSize<short> d(sizes);
  RegSize<Sizes> e(sizes);

  cout << "sizeof int is " << sizes.GetSize(typeid(int)) << endl;
  cout << "sizeof short is " << sizes.GetSize(typeid(short)) << endl;
  cout << "sizeof Sizes is " << sizes.GetSize(typeid(Sizes)) << endl;
}
---
[ 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
]

Thanks to all who responded to my question. My comments follow-

I, bparker@gil.com.au (Brian Parker) wrote:

>I still don't see how this helps look up associated type information
>using a map.
>type_info has a private copy constructor and hence can't be used
>directly in a map and so before() is not useful for this purpose.
>Could someone please  post a CD2-compliant example of associating
>additional data with type_info?

"Bill Wade" <bill.wade@stoner.com> wrote:

>But it doesn't need to be used directly.  The map can use pointers to
>type_info objects as keys, and
>ptr->before() in the implementation of less().  This is helpful because
>there is no portable way to get an ordering (or hash) relationship among
>pointers.  References returned by typeid remain valid till the end of the
>program, so there is no danger of the pointer becoming stale, at least not
>before end-of-program cleanup.

This was my original thought, to use pointers to type_info in a map,
but the converse to the above is true- less is guaranteed to give a
total ordering for pointers and so before() is not helpful here, and
the address of type_info is not guaranteed to be unique and so can't
be used as a key in map<>.

"Paul D. DeRocco" <strip_these_words_pderocco@ix.netcom.com> wrote:

>The map can use type_info& instead of type_info, can't it?
I don't think a key can be a reference type- it has to be default
constructable and assignable (certainly the STL in VC++ 5.0 chokes on
it).

chris@alofi.etca.fr (Christian Millour) wrote:
>the following snippet is uncompiled and I don't have cd2 handy. It should
>get you started though.

>#include <typeinfo>
>#include <map>

>class Key {
>  class Nil {};
>  type_info const & rep;
>public:
>  Key(type_info const & arg = typeid(Nil)) : rep(arg) {}
>  friend bool operator < (Key const & lhs, Key const & rhs) {
>    return lhs.rep.before(rhs.rep);
>  }
>};

>typedef map<Key, int, less<Key> > Maptype;

>class foo {};
>class bar {};
>class qux {};

>int main() {
>  Maptype m;
>  m[typeid(foo)] = 0;
>  m[typeid(bar)] = 1;
>  m[typeid(qux)] = 2;
>}

Aha! this solves the problem- don't use type_info directly but use a
wrapper class.
My only comment on the above is that to assign maps, the key needs to
be assignable, so I have changed the above code to use a pointer
instead of a reference. Also, to allow searching in vectors etc. I
have added the equality and inequality operators.

With these changes, the key class is as follows-

class type_info_key {
  class Nil {};
  type_info const * rep;
public:
  type_info_key(type_info const & arg = typeid(Nil)) : rep(&arg) {}

  friend bool operator < (type_info_key const & lhs, type_info_key
const & rhs) {
    return lhs.rep->before(*rhs.rep);
  }

  friend bool operator == (type_info_key const & lhs, type_info_key
const & rhs) {
    return *lhs.rep == *rhs.rep;
  }

  friend bool operator != (type_info_key const & lhs, type_info_key
const & rhs) {
    return *lhs.rep != *rhs.rep;
  }
};

Thanks for posting your solution (it  may make a useful addition to
the library in the next C++  revision IMHO).

,Brian Parker (bparker@gil.com.au)
---
[ 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
]

James Kanze wrote:
>
> There are always three char types, but the standard requires
> type_info::name to be a plain char (neither the signed or unsigned
> char).  Whether plain char is signed or unsigned is implementation
> defined, but I really don't see where this would make a difference.

I think you misunderstood me. I wasn't talking about the type returned
by type_info::name, which is "const char*". I was talking about the
string returned when the type is a char, or containing char somewhere in
it. Two compilers may return a name such as "char(*)(int,int)" for some
function pointer type, but the meaning of the return value may be
different for the two compilers, even if they are for the same physical
machine with the same word size.

> Matt Austin has pointed out some of the difficulties in "standardizing"
> the value.  One that he didn't mention is that standardizing the text
> doesn't really buy you much; if my implementation uses EBCDIC, and yours
> ASCII, we're still incompatible.  With the recent extention to allow
> universal character names, this becomes relevant again; ASCII is
> quasi-universal now, but I know of at least four widespread character
> codes for accented characters.

Yup. Personally, I wish the standard only allowed un-accented letters in
identifiers. After all, the language, like it or not, is based on
English in the first place. (There's no provision in the standard for
providing versions of the compiler that use "si" in place of "if", or
"pour" instead of "for".) Given that, I don't think it would be
criminally Anglocentric to require variable names to use the English
character set as well. Then, the problem reduces to translating between
EBCDIC and ASCII, which is a problem no matter what kind of text you're
reading in.

> |>  2) Some machines need additional modifiers, especially on pointers
> |>  (e.g., __near and __far), and a type_info::name() that left these out
> |>  for the sake of compatibility with other machines would be pretty
> |>  useless.
>
> These don't exist in C++, and an implementation which required the
> programmer to be aware of them would not be conforming.  At any rate, I
> fail to see how they would affect the external representation, which is
> all that would have been standardized anyway.

Because on such machines "char __far*" and "char __near*" really really
are two different types, and you _can't_ call them both "char*" and have
everything work.

--

Ciao,
Paul D. DeRocco

(Please send e-mail to mail:pderocco@ix.netcom.com instead of the
return address, which has been altered to foil junk mail senders.)
---
[ 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
]

bill@gibbons.org (Bill Gibbons) wrote:

>
>There is no requirement that type_info::name() be unique for local
>types, nor for types in unnamed namespaces.
>
>Without a uniqueness requirement, standardizing the strings is
>fairly simple.

My thoughts exactly! For 99% of the cases where consistent, portable
name strings are important (e.g. persistence), it is only necessary to
standardize the name() string for global and named-namespace classes.
The representation of pointers, unnamed-namespace objects, local
classes, etc. can remain implementation-defined for all I care (although
a minimal set of requirements might be a good idea for these, too).

A simple rule that would meet most needs would be that if X is the name
of a class defined at any scope, then typeid(X).typename() end with "X"
(not preceded by an alpha-numeric character). I can write my own
functions to remove whitespace and other extraneous stuff and to convert
the result into some portable character set (e.g. ASCII).

This rule could easily be extended to include namespaces and nesting
classes for non-local, non-unnamed-namespace classes. But even with the
simpler rule, a lot would be gained. I just wouldn't re-use persistent
class names in different scopes.

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ 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
]

Bill Gibbons wrote:
>
> There is no requirement that type_info::name() be unique for local
> types, nor for types in unnamed namespaces.

Are you just inferring that, or does the proposed standard actually say
that? I can't find it.

> Without a uniqueness requirement, standardizing the strings is
> fairly simple.  I formally proposed one possible set of rules
> (X3J16/95-0053 a.k.a. WG21/N0653) over two years ago, but the
> committee decided that this issue was outside the bounds of the
> standards process, at least for this version of the standard.

I'd like to see that proposal. If it's too long to post, e-mail it to
me, if you still have it handy.

--

Ciao,
Paul D. DeRocco

(Please send e-mail to mail:pderocco@ix.netcom.com instead of the
return address, which has been altered to foil junk mail senders.)
---
[ 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                             ]

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

>Bill Gibbons wrote:
>>
>> There is no requirement that type_info::name() be unique for local
>> types, nor for types in unnamed namespaces.
>
>Are you just inferring that, or does the proposed standard actually say
>that? I can't find it.

The DWP does not state every non-requirement!
(After all, there are an infinite number of possible non-requirements.)

If you can't find it, then it is not a requirement.

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

"Paul D. DeRocco" <strip_these_words_pderocco@ix.netcom.com> wrote:

>...
>I think you misunderstood me. I wasn't talking about the type returned
>by type_info::name, which is "const char*". I was talking about the
>string returned when the type is a char, or containing char somewhere in
>it. Two compilers may return a name such as "char(*)(int,int)" for some
>function pointer type, but the meaning of the return value may be
>different for the two compilers, even if they are for the same physical
>machine with the same word size.

The three different char types would be output as "signed char",
"unsigned char" and "char" by type_info::name() (VC++5.0 does this).
The problem of data files being portable between machines seems to me
to be a separate problem that needs to be tackled by the programmer.

>>...
>> |>  2) Some machines need additional modifiers, especially on pointers
>> |>  (e.g., __near and __far), and a type_info::name() that left these out
>> |>  for the sake of compatibility with other machines would be pretty
>> |>  useless.
>>
>> These don't exist in C++, and an implementation which required the
>> programmer to be aware of them would not be conforming.  At any rate, I
>> fail to see how they would affect the external representation, which is
>> all that would have been standardized anyway.

>Because on such machines "char __far*" and "char __near*" really really
>are two different types, and you _can't_ call them both "char*" and have
>everything work.

An implementation could output __near and __far etc. in
type_info.name() as a non-standard extension, (as indeed the keywords
near and far used to qualify pointers already are).

,Brian Parker (bparker@gil.com.au)
---
[ 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
]

bill@gibbons.org (Bill Gibbons) wrote:

>In article <fxtbu7hj59i.fsf@isolde.mti.sgi.com>, Matt Austern
><austern@isolde.mti.sgi.com> wrote:

>> Standardizing type_info::name() is harder than you might think: there
>> are lots of tricky issues that aren't immediately obvious.  Even
>> the seemingly simple requirement that unique types have unique
>> names isn't as trivial as it appears at first sight.
>>
>> One of the issues that the committee took seriously, for example,
>> was local types.  Consider the following code.
>> ...

>There is no requirement that type_info::name() be unique for local
>types, nor for types in unnamed namespaces.

>Without a uniqueness requirement, standardizing the strings is
>fairly simple.  I formally proposed one possible set of rules
>(X3J16/95-0053 a.k.a. WG21/N0653) over two years ago, but the
>committee decided that this issue was outside the bounds of the
>standards process, at least for this version of the standard.

>-- Bill Gibbons
>   bill@gibbons.org

Yes, even if local types and types in anonymous namespaces have
non-unique names, it would still be useful to standardise the output
for global types. In a persistence library, if one streamed out a
local type then one could only later read it back in where the local
type is in scope. Given this, it should be possible to code a
work-around for local types. A persistence library that only worked
with global types would still be useful anyway.

It does seem to me that specifying type_info.name() to return a fully
qualified, elaborated type-id, with no redundant spaces would not
require too much text in the draft. There are a few complications such
as pointer non-type template parameters. VC 5.0 outputs the parameter
type followed by the instantiating variable name in this case, and
uses "anonymous namespace" where types are in an unnamed namespace.

Given some standardised type_info.name() output, support for
disambiguating local and unnamed namespace types could be added at a
later stage by defining additional type_info members, such as a flag
set to true for a local type, and a function returning a
disambiguating prefix string, encoding the nested scopes and function
name etc.

Apart from the issue of using type_info.name() in a persistence
library is the need for associating additional type information with
type_info via a map, for the duration of a single programme execution.
It would be useful if &typeid was guaranteed to be unique for this
purpose, or alternatively if there were a member function of type_info
that returned a unique integer for each distinct type.

,Brian Parker (bparker@gil.com.au)
---
[ 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
]

Brian Parker wrote:
Apart from the issue of using type_info.name() in a persistence
library is the need for associating additional type information with
type_info via a map, for the duration of a single programme execution.
It would be useful if &typeid was guaranteed to be unique for this
purpose, or alternatively if there were a member function of type_info
that returned a unique integer for each distinct type.
---
Doesn't the typeinfo::before function provide this capability?
---
[ 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                             ]

Jess Holle wrote:
>
> I recently looked into writing a simple object I/O mechanism
> similar in some respects to that in MFC, but using ANSI C++'s
> RTTI rather than MFC's macros (and thereby fully supporting
> objects with multiple inheritance and templates).
>
> I ran into a seemingly impassible roadblock, however.
>  type_info::name()'s return value is implementation specific -
> guaranteed to have a consistent value only throughout a single
> execution!  In practical terms this means that any two compilers
> will not be consistent here and that occasionally a compiler's
> type_info::name() output may change from version to version.
> This renders the I/O implementations that I was considering
> completely useless.
> -- Jess Holle and Wendy Vidlak

Well, I can think of a couple of kludges to help you with this...

If you can generate a list of types that need to be recognized at
startup, you can construct a (STL) map to map the values returned
on this program invocation to the values the rest of your code
expects.
If you only need this to access the contents of a stream object,
you can prepend a dictionary to the front of the stream that
indicates what was assigned to each contained type when it was
written to the stream.  Then the sender and receiver have to agree
about what to put in the dictionary.
Neither of these solutions completely addresses the problem you
have.  However, they can allow pseudo-"serialization" of the
type_info information.   The largest implementation headache is
requiring every class that might use RTTI information in a given
application to register itself with the I/O mechanism you're
designing.  The largest design headache is creating exclusive
pools of programs that recognize eachothers' dictionaries.
  -- Eric Gindrup ! gindrup@okway.okstate.edu
---
[ 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                             ]

jessholl@netcom.com (Jess Holle) writes:

> I ran into a seemingly impassible roadblock, however.  type_info::name()'s
> return value is implementation specific - guaranteed to have a consistent
> value only throughout a single execution!  In practical terms this means
> that any two compilers will not be consistent here and that occasionally a
> compiler's type_info::name() output may change from version to version.
> This renders the I/O implementations that I was considering completely
> useless.

Standardizing type_info::name() is harder than you might think: there
are lots of tricky issues that aren't immediately obvious.  Even
the seemingly simple requirement that unique types have unique
names isn't as trivial as it appears at first sight.

One of the issues that the committee took seriously, for example,
was local types.  Consider the following code.

void f() {
  struct X {};
  ...
}

void g() {
  struct X {};
  ...
}

These two X's are two different types.  What should the values of
type_info::name() be for these two different X's, though?  And can
those values be standardized?  (For extra credit, what if f and/or g
is static, or a member of an unnamed namespace?)
---
[ 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 <Stephen.Clamage@eng.sun.com> wrote:
: The C++ Committee elected not to address persistent types at all in
: this round of the standard.

Is it planned to begin working on the next standard as soon as this
one is finished?

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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                             ]

In article 1204971548430001@10.0.2.15, jessholl@netcom.com (Jess Holle) writes:
>
>I ran into a seemingly impassible roadblock, however.  type_info::name()'s
>return value is implementation specific - guaranteed to have a consistent
>value only throughout a single execution!  ...
>
>It was my understanding that RTTI was supposed to specifically address
>issues like object I/O, ...

No, RTTI as defined in C++ does not attempt to address persistent objects.
As you discovered, it is not adequate for that purpose. Requiring a standard
format for the "name" member would not in itself solve that problem.

The C++ Committee elected not to address persistent types at all in
this round of the standard. The subject seemed quite difficult to specify
at the language standard level, and we had many other difficult subjects
(templates, exceptions, STL) which we considered higher priority.

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

Matt Austern wrote:
>
> jessholl@netcom.com (Jess Holle) writes:
>
> > I ran into a seemingly impassible roadblock, however.  type_info::name()'s
> > return value is implementation specific - guaranteed to have a consistent
> > value only throughout a single execution!  In practical terms this means
> > that any two compilers will not be consistent here and that occasionally a
> > compiler's type_info::name() output may change from version to version.
> > This renders the I/O implementations that I was considering completely
> > useless.
>
> Standardizing type_info::name() is harder than you might think: there
> are lots of tricky issues that aren't immediately obvious.  Even
> the seemingly simple requirement that unique types have unique
> names isn't as trivial as it appears at first sight.
>
> One of the issues that the committee took seriously, for example,
> was local types.  Consider the following code.
>
> void f() {
>   struct X {};
>   ...
> }
>
> void g() {
>   struct X {};
>   ...
> }
>
> These two X's are two different types.  What should the values of
> type_info::name() be for these two different X's, though?  And can
> those values be standardized?  (For extra credit, what if f and/or g
> is static, or a member of an unnamed namespace?)
The unique name most compilers use is the mangled name of the type.
All of these naming problems have to be solved for proper support
of templates and inline functions.

The name of a local class can be mangled as follows:

<host-function>+<block-number>+<class>

The <block-number> is a simple counter label that identifies
each scope in the function with a number so that if you have
two local class 'X''s, each will be safely kept distinct.
Note that this must be repeated if a local class contains
member functions that also have local classes, and so on.

Example:

void f() {
        {
            struct X {
                int x;
            } static z1 = { 1 };
        }
        {
            struct X {
                int x;
            } static z2 = { 2 };
            {
                struct X {
                    int x;
                    int f( int x ) {
                        static int s = 1;
                        struct X {
                            int x;
                        } static z3 = { 3 };
                        int t = s;
                        s = x;
                        return t;
                    }
                } static z4 = { 4 };
                z4.f( 2 );
            }
        }
}

Modern C++ compilers already handle unnamed namespaces through
generation of special "unique" scope names so this is also not
a problem when it comes to generating a good type_info::name(),
though the "unique" name has a small probability of colliding
with another "unique" name (this can be solved through the use
of repositiories that would guarantee uniqueness).

Standardizing these issues, even though there are technical
solutions, involves getting everybody to agree (at least) on
the basic information that will be encoded into type_id
which includes more than just the name().

Anthony Scian
Sybase Waterloo (formerly Watcom)
---
[ 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                             ]

Anthony Scian wrote:
 >
 > Matt Austern wrote:
 > >
 > > One of the issues that the committee took seriously, for example,
 > > was local types.  Consider the following code.
 > >
 > > void f() {
 > >   struct X {};
 > >   ...
 > > }
 > >
 > > void g() {
 > >   struct X {};
 > >   ...
 > > }
 > >
 > > These two X's are two different types.  What should the values of
 > > type_info::name() be for these two different X's, though?  And can
 > > those values be standardized?  (For extra credit, what if f and/or g
 > > is static, or a member of an unnamed namespace?)
 >
 > The name of a local class can be mangled as follows:
 >
 > <host-function>+<block-number>+<class>

At least in the Borland compiler, type_info::name returns a string
containing a valid type expression. Unfortunately, there is no valid
type expression that globally defines these types. Handling these thus
requires introducing type_info::name values that are just arbitrary
strings, and not meaningful to a C++ programmer.

--

Ciao,
Paul D. DeRocco

(Please send e-mail to mail:pderocco@ix.netcom.com instead of the
return address, which has been altered to foil junk mail senders.)
---
[ 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                             ]

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

|>  Brian Parker wrote:
|>  >
|>  > Yes, I agree that the output of type_info::name() should be
|>  > standardised, for exactly the reasons you state. I have actually sent
|>  > in a public comment with that suggestion (quoting the Hollub article
|>  > as an example) , but I don't know what the commitee's plans are in
|>  > this area.
|>  >
|>  > Even worse, by the CD2 a conforming implementation could return a null
|>  > string for type_info::name() which would mean that one could not even
|>  > use it to index a map to look up an implementation-independent string,
|>  > or other type-related information (and I don't think that taking the
|>  > address of the type_info object could be used for indexing instead
|>  > because it is also not guaranteed to be unique between types).
|>
|>  I suspect that RTTI will be an area where the standards committees will
|>  decide to to some more work, once the language has been standardized and
|>  Round Two begins. I see two difficulties with standardizing
|>  type_info::name():
|>
|>  1) The char type is allowed to be signed or unsigned. However, if it is
|>  signed, it is still not the same thing as "signed char". In other words,
|>  there are three char types, one of which is implementation dependent. So
|>  even if the names look the same, when you read data written on a
|>  different machine (even with the same char size), you may wind up
|>  interpreting it differently.

There are always three char types, but the standard requires
type_info::name to be a plain char (neither the signed or unsigned
char).  Whether plain char is signed or unsigned is implementation
defined, but I really don't see where this would make a difference.

Matt Austin has pointed out some of the difficulties in "standardizing"
the value.  One that he didn't mention is that standardizing the text
doesn't really buy you much; if my implementation uses EBCDIC, and yours
ASCII, we're still incompatible.  With the recent extention to allow
universal character names, this becomes relevant again; ASCII is
quasi-universal now, but I know of at least four widespread character
codes for accented characters.

|>  2) Some machines need additional modifiers, especially on pointers
|>  (e.g., __near and __far), and a type_info::name() that left these out
|>  for the sake of compatibility with other machines would be pretty
|>  useless.

These don't exist in C++, and an implementation which required the
programmer to be aware of them would not be conforming.  At any rate, I
fail to see how they would affect the external representation, which is
all that would have been standardized anyway.

|>  That said, it would certainly be useful if implementations were at least
|>  prohibited from inserting unnecessary whitespace, and required to insert
|>  only a single blank where whitespace is required. For instance, Borland
|>  returns names like "char *", while I can certainly imagine a different
|>  compiler returning "char*". The above rule is the simplest way to remove
|>  this needless discrepancy.

I doubt that this is enough.  There are too many different ways an
implementation can encode the names.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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                             ]

In article <fxtbu7hj59i.fsf@isolde.mti.sgi.com>, Matt Austern
<austern@isolde.mti.sgi.com> wrote:

> Standardizing type_info::name() is harder than you might think: there
> are lots of tricky issues that aren't immediately obvious.  Even
> the seemingly simple requirement that unique types have unique
> names isn't as trivial as it appears at first sight.
>
> One of the issues that the committee took seriously, for example,
> was local types.  Consider the following code.
> ...

There is no requirement that type_info::name() be unique for local
types, nor for types in unnamed namespaces.

Without a uniqueness requirement, standardizing the strings is
fairly simple.  I formally proposed one possible set of rules
(X3J16/95-0053 a.k.a. WG21/N0653) over two years ago, but the
committee decided that this issue was outside the bounds of the
standards process, at least for this version of the standard.

-- Bill Gibbons
   bill@gibbons.org

--
Bill Gibbons
bill@gibbons.org
---
[ 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                             ]

jessholl@netcom.com (Jess Holle) wrote:

>I recently looked into writing a simple object I/O mechanism similar in
>some respects to that in MFC, but using ANSI C++'s RTTI rather than MFC's
>macros (and thereby fully supporting objects with multiple inheritance and
>templates).

>I ran into a seemingly impassible roadblock, however.  type_info::name()'s
>return value is implementation specific - guaranteed to have a consistent
>value only throughout a single execution!  In practical terms this means
>that any two compilers will not be consistent here and that occasionally a
>compiler's type_info::name() output may change from version to version.
>This renders the I/O implementations that I was considering completely
>useless.

>Allen Hollub wrote an MSJ article about using C++ RTTI for I/O last
>summer.  His implementation required a consistent return value from
>type_info::name() across all compilers and compiler versions upon which
>the executable was to be built.  Neither of us came up with any way to
>remove this dependency without killing the simplicity of his I/O
>mechanism.

>It was my understanding that RTTI was supposed to specifically address
>issues like object I/O, so I assume I'm missing something - or am I?  Does
>ANSI C++ RTTI address the underlying issues for typed object I/O or not?
>If so, can anyone give any pointers as to how to remove the reliance on a
>consistent return from type_info::name() without rendering the I/O
>mechanism into a monstrosity?

Yes, I agree that the output of type_info::name() should be
standardised, for exactly the reasons you state. I have actually sent
in a public comment with that suggestion (quoting the Hollub article
as an example) , but I don't know what the commitee's plans are in
this area.

Even worse, by the CD2 a conforming implementation could return a null
string for type_info::name() which would mean that one could not even
use it to index a map to look up an implementation-independent string,
or other type-related information (and I don't think that taking the
address of the type_info object could be used for indexing instead
because it is also not guaranteed to be unique between types).

,Brian Parker (bparker@gil.com.au)
---
[ 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
]

I recently looked into writing a simple object I/O mechanism similar in
some respects to that in MFC, but using ANSI C++'s RTTI rather than MFC's
macros (and thereby fully supporting objects with multiple inheritance and
templates).

I ran into a seemingly impassible roadblock, however.  type_info::name()'s
return value is implementation specific - guaranteed to have a consistent
value only throughout a single execution!  In practical terms this means
that any two compilers will not be consistent here and that occasionally a
compiler's type_info::name() output may change from version to version.
This renders the I/O implementations that I was considering completely
useless.

Allen Hollub wrote an MSJ article about using C++ RTTI for I/O last
summer.  His implementation required a consistent return value from
type_info::name() across all compilers and compiler versions upon which
the executable was to be built.  Neither of us came up with any way to
remove this dependency without killing the simplicity of his I/O
mechanism.

It was my understanding that RTTI was supposed to specifically address
issues like object I/O, so I assume I'm missing something - or am I?  Does
ANSI C++ RTTI address the underlying issues for typed object I/O or not?
If so, can anyone give any pointers as to how to remove the reliance on a
consistent return from type_info::name() without rendering the I/O
mechanism into a monstrosity?

Thanks in advance.

--
---------------------------------------------------------------------
Jess Holle and /                                   jessholl@netcom.com
Wendy Vidlak  /
Norwood, MA  /  ftp://ftp.netcom.com/pub/je/jessholl/j_and_w_www.html
---
[ 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                             ]

Brian Parker wrote:
>
> Yes, I agree that the output of type_info::name() should be
> standardised, for exactly the reasons you state. I have actually sent
> in a public comment with that suggestion (quoting the Hollub article
> as an example) , but I don't know what the commitee's plans are in
> this area.
>
> Even worse, by the CD2 a conforming implementation could return a null
> string for type_info::name() which would mean that one could not even
> use it to index a map to look up an implementation-independent string,
> or other type-related information (and I don't think that taking the
> address of the type_info object could be used for indexing instead
> because it is also not guaranteed to be unique between types).

I suspect that RTTI will be an area where the standards committees will
decide to to some more work, once the language has been standardized and
Round Two begins. I see two difficulties with standardizing
type_info::name():

1) The char type is allowed to be signed or unsigned. However, if it is
signed, it is still not the same thing as "signed char". In other words,
there are three char types, one of which is implementation dependent. So
even if the names look the same, when you read data written on a
different machine (even with the same char size), you may wind up
interpreting it differently.

2) Some machines need additional modifiers, especially on pointers
(e.g., __near and __far), and a type_info::name() that left these out
for the sake of compatibility with other machines would be pretty
useless.

That said, it would certainly be useful if implementations were at least
prohibited from inserting unnecessary whitespace, and required to insert
only a single blank where whitespace is required. For instance, Borland
returns names like "char *", while I can certainly imagine a different
compiler returning "char*". The above rule is the simplest way to remove
this needless discrepancy.

---

The other related area I'd like to see addressed in some future standard
is the ability to test type_info objects for relatedness. In particular,
I'd like to see a standard is_derived_from(type_info& parent, type_info&
child) function. It's hard to imagine an implementation of C++ that
doesn't already have a helper function that does exactly (or nearly)
this for the benefit of exception handling. Why not make it public?

The other RTTI function I'd like to see made public is the helper
function that does the work of dynamic_cast. That is, given a void
pointer and a type_info that represents the previously obtained type of
that pointer, and another type_info that represents a different desired
type, it should cast the void pointer from the original type to the new
type, or return nil if not possible. This would allow the creation of
fully polymorphic collections, by storing the type_info along with each
object, and then searching the collection using the same sort of type
matching that exception handling uses, i.e., searching with a base class
and matching a derived class.

--

Ciao,
Paul D. DeRocco

(Please send e-mail to mail:pderocco@ix.netcom.com instead of the
return address, which has been altered to foil junk mail senders.)
---
[ 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                             ]