Re: C++ rtti hack
bji-ggcpp@ischo.com wrote:
:: On May 12, 9:16 pm, "Bo Persson" <b...@gmb.dk> wrote:
::: bji-gg...@ischo.com wrote:
:::
::::: On the contrary ... do you think it's valuable to be able to
::::: write code that simply takes a pointer to "an object" of
::::: unknown type, and is able to detect the type of that object? I
::::: think it is.
:::
::: I don't. :-)
:::
::: For polymorphic types it might be, but can most often be solved
::: by using virtual functions.
:::
::: For pointers to non-polymorhpic objects, you program shouled be
::: able to track the pointer better than "I have a pointer to some
::: object".
::
:: But I am writing a library, that takes "a pointer to some object",
:: recovers type information on that object, and then acts on it.
I would prefer if the type info was never lost, in the first place. :-)
::
:: What you are suggesting is that I take "a pointer to some object
:: that inherits from a class that is known to me". This would
:: require everyone who wanted to use my API to inherit from a
:: special base class that I define. I really don't want to require
:: this; I think it's onerous to expect developers to inherit from a
:: base class just to be able to use my API.
I wouldn't like that either! My attempt would be to use templates, to
catch
the type info where it is available. That would let you write one set of
code, for a lot of types, while still keeping the type info.
::: The idea with C++ is that you should not give up performance for
::: silly features that you don't use. The more restrictions you add
::: to the
::: details of
::: the required implementation, the less room you leave for smart
::: compilers.
:::
::: It is possible to have a C++ implementation on machines with 9 bit
::: bytes, 36
::: bit integers, using ones complement, and 72 bit floating point.
::: You don't have to have a hardware stack, and vtables are not
::: required.
::
:: I am not asking for the compiler to violate any of these things.
:: I'm just asking the compiler to always make rtti locatable for any
:: polymorphic object. I am also wishing that the C++ standard
:: required this. And I am theorizing that modern compilers always
:: *will* make rtti locatable for any polymorphic object.
::
:: I am not preventing the compiler from making code work on any
:: machine with any particular hardware features.
It is easily done, if you are not careful! I belive that the C++ committee
has been very careful to not accidentally rule out implementations on
"exotic" hardware.
Note that "exotic hardware" includes some modes of the x86 processors. They
really have a segmented architecture, that is just hidden by the most
common
operating systems (by having code, stack, and data segments overlap). By
leaving some pointer operations undefined, the committee wisely left open
the use of non-overlapping segments.
On the 36-bit architecture I referred to above, the segments are normally
not overlapping. If required to be, that would severely limit the maximum
program size.
http://www.unisys.com/products/mainframes/os__2200__mainframes/index.htm
::
::: C++ is this way, not by mistake but by design. If you want it the
::: other way round, you could go with Java.
::
:: I want what I think many other people want: a hybrid of C++ and
:: Java that takes the "best" features of C++ (portability, open
:: standardization, performance, "full control", etc) and the "best"
:: features of Java (conciseness, simplicity, regularity of syntax, a
:: reasonably complete standard library) and puts them in one
:: language.
Some of the perceived simplicity can sometimes incurr other costs. For
example, the precisely specified floating point format in Java, requires an
additional set of hardware on IBM mainframes. Very expensive!
http://www-03.ibm.com/systems/z/zaap/
Bo Persson
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]