DJ Delorie wrote: > At the moment, there are no language issues to resolve.
No, rather, at the moment there is a class of programs which are accidentally accepted by the C++ front end and happen to do some of the things that you want. That is different from saying that the compiler supports the feature that you want. This is an undocumented extension. Note that the documentation for the mode attribute says: "This in effect lets you request an integer or floating point type according to its width." (It does not say pointer type.) It then goes on to say "and `pointer' or `__pointer__' for the mode used to represent pointers". The use of the definite article indicates that there is in fact only one mode for pointers. > The remaining problems aren't really "language issues". I'm surprised that you believe this, in view of the concrete examples I've given. I'm not sure how to convince you that there's anything non-trivial to do here, but there is. So, unfortunately, I'm stuck: all I can do is tell you that the fact that this current works at all in C++ is an accident, might go away at any point, and probably violates various assumptions in the front end. If you're willing to use integers, you'll have an easy time. If you want the more elegant language semantics of multiple pointer sizes, you'll have to take the time to read through the C++ standard and think about all the potential impact of the extension you're proposing. Or, you can decide to work on the middle end issues, try to get your patches accepted, and then come back to the front end issues later. I don't have any plans to aggressively go reject this code in the C++ front end, but I would vaguely like to clean up and specify how attributes interact with C++ in more detail, and that might result in problems for this usage. (We really need to specify how attributes interact with same-typed-ness, implicit conversions, etc.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
