Reico GmbH wrote in message <388C3602.B6364CBB@reico.de>...
>Hi,
>
>it could be sometimes very useful to have the option of enumerating
>types:
>
>type_enum { class A, class B, class C };
>
>This would define the relational operators of the typeinfo-objects
>between the classes A, B, C (in the obvisious way).

It seems that this would require every translation unit to be translated
(compiled and linked) before execution of any translation unit begins (at
least prior to the first type.before() call).  That seems to seriously
reduce an implementation's freedom (consider interpreters and libraries
which are linked at run time).


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,

it could be sometimes very useful to have the option of enumerating
types:

type_enum { class A, class B, class C };

This would define the relational operators of the typeinfo-objects
between the classes A, B, C (in the obvisious way). The relational
operators to other types stay undefined.
Suppose you have a container, where the elements have to be sorted by
type (ie. if you have some sort of priority). By now I have to define a
virtual function getID() to do this kind of sorting (and an enumeration
of ID's).
Furthermore the difference between enumerated types could be defined as
typeid (B) - typeid (A) == 1. This would offer new ways in implementing
multiple polymorphism.


Best regards
Olaf Krzikalla

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,

> would be no implementation advantage.  In a sense the language has provided a
> mechanism like this in the RTTI feature, but that is very expensive for this
> purpose.

I don't think so. You may simply adding an integer to the
typeinfo-class. This member is set only for classes appearing in a
type_enum.
Actually I dont know, how typeid is implemented. But I suppose, for
every type a static typeinfo-object exists. That will be copied, when a
typeid-call occurs with the proper type.
A problem, which can only be solved by the linker (but it can), arises,
when a type occurs in more than one type_enum.

Best regards
Olaf Krzikalla

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Reico GmbH wrote:
> it could be sometimes very useful to have the option of enumerating
> types:
>
> type_enum { class A, class B, class C };
>
> This would define the relational operators of the typeinfo-objects
> between the classes A, B, C (in the obvisious way). The relational
> operators to other types stay undefined.
> Suppose you have a container, where the elements have to be sorted by
> type (ie. if you have some sort of priority). By now I have to define a
> virtual function getID() to do this kind of sorting (and an
> enumeration of ID's).  Furthermore the difference between enumerated
> types could be defined as typeid (B) - typeid (A) == 1. This would
> offer new ways in implementing multiple polymorphism.

1. How would the compiler determine the enumeration values of *all*
 of the classes used by a program at compile time (prior to link
 time)?

2. An approximation to your difference idea is to simply subtract the
 _vtbl values of each object.  But even this won't work for classes
 and types without _vtbl pointers.

-- David R. Tribble, david@tribble.com, http://david.tribble.com --

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

This is a multi-part message in MIME format.
--------------2602A2F196C88AE099F148F1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Reico GmbH wrote:

> it could be sometimes very useful to have the option of enumerating
> types:
>
> type_enum { class A, class B, class C };
>
> This would define the relational operators of the typeinfo-objects
> between the classes A, B, C (in the obvisious way).

The only way that the compiler could implement this is by creating a hidden
virtual member on all of the classes which you define in this way, so there
would be no implementation advantage.  In a sense the language has provided a
mechanism like this in the RTTI feature, but that is very expensive for this
purpose.

--
Jim Cobban   jcobban@magma.ca
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438


--------------2602A2F196C88AE099F148F1
Content-Type: text/x-vcard; charset=us-ascii;
 name="thesnaguy.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jim Cobban
Content-Disposition: attachment;
 filename="thesnaguy.vcf"

begin:vcard
n:Cobban;James
tel;fax:+1-613-592-9438
tel;home:+1-613-592-9438
x-mozilla-html:FALSE
url:http://www.magma.ca/~jcobban
version:2.1
email;internet:thesnaguy@hotmail.com
title:Consultant
adr;quoted-printable:;;34 Palomino Dr.=0D=0A;Kanata;ON;K2M 1M1;Canada
fn:Jim Cobban
end:vcard

--------------2602A2F196C88AE099F148F1--



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]