> > Pointers are on a system IA32 32 bit pointers on IA64 64 bit pointers
> > that are of type int32 or int64 so all pointers have the same type on
> > the same system.
>
> No, that's not right. Machines have addresses, not pointers.
> Pointers are a programming language entity, not a machine property.
> OK, that's just a matter of terminology, but it's an important one.
Yes and addresses are as long as the machine needs to address: IA32 -> 4GB ->
that's 2^32 what the name says and that is what in ebx, ebp, eip, ... is
needed to define a location together with a descriptor. And because of that
you know what linux needs to address and also how long the pointers are -
that's all the same.
>
> > (That's pointers get handled in other languages, without a standard for
> > objective oriented programming)
> > But a pointer can point to whatever you want
>
> No, it can't. Not in C or C++ it can't. A pointer can only point to
> a compatible type. Anything else is undefined.
Surely not c and c++ but generally or in other languages and for the CPU (ptr)
are all pointers the same.
> > If you now have a stack holding only pointers to functions than you
> > can call this pointers over a number added to that stack pointer
> > (class) and any function can get executed like in QT. But if you
> > want to change a class in one of that positions that don't have the
> > same type than c++ can do type checking and doesn't allow that. But
> > if that types won't be the same it wouldn't matter, than an other
> > class is initialised or member is executed. So ISO-C++ could allow
> > to overwrite these style of pointers.
>
> OK, here I don't understand what you're saying.
What I wanted to say is that pointers to types should not be handled like
pointers to executable code, the other way round, pointers to types should be
handled like is and pointers to executable code should be handled more opened
to the programmer. That gcc may only controll that the arguments of functions
are identical and not the class of functions, so two different project can be
used easily together.
I did read a little now and, yes, my problem is not really a lack of c++, but
more one of the use of foreign projects like QT. If something isn't supported
in such a project you can't solve it in an easy way. You have to wait until
it get supported now like in QT-4 there is a QPointer that solves all such
problems but my app. relays on QT-3 and I wanted to work the other way round.
To handle calls as one type of pointers in gcc would be a big loss in
protection also with a special syntax or writing.
Sebastian
