sebastian writes: > > I have already given you the correct answer. What did you not like > > about it? > > Nothing against your answer that's all correct and well. > What I don't like is the protection mechanism of c++ that causes > that problem and the main disadvantage, sorry, the only thing > making problems in c++. I first wanted to be sure that there is no > way - and now I know that there is no way to solve this inside c++. > > But it would be nice to see gcc making this break of ISO-C++, that > programmers can use pointers in that way. > > Maybe you don't get me (that problem) right: > > 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. > (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. > and it doesn't make sense to call (execute) a long int variable > when you wanted to initialise your new widget - over such a > pointer. So c++ has type checking of pointers to do better error > massages and protection (C deffines here ++, objective oriented > programming). Yes. One of the design goals of C++ was more type safety than C. > 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. Andrew.