DJ Delorie wrote: >> Well, I think it's in direct conflict with the C++ standard. If "X" is >> a 32-bit pointer type, and "x" is a value of type X, "Y" is a 16-bit >> pointer type, then: >> >> (X*)(Y*)x >> >> is supposed to get you back the value of "x", but I don't see how that >> can work, in general.
I made an error in the code above; I should have said "(X)(Y)x" since I had already defined "X" and "Y" to be pointer types. > Where in the standard does it say that? [expr.reinterpret.cast] A pointer to an object can be explicitly converted to a pointer to an object of different type.13) Except that converting an rvalue of type "pointer to T1" to the type "pointer to T2" (where T1 and T2 are object types and where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value, the result of such a pointer conversion is unspecified. The "except that" sentence implies the statement above, assuming that the pointed-to type does not have stricter alignment. So, if casting a 32-bit pointer to int to a 16-bit pointer to char and back does not always yield the same value, then something has to give. Fundamentally, pointer types in C++ are compound types determined solely by the pointed-to-type; what you're doing (by adding attributes to the pointer) is adding a new operator for forming compound types. That's a language extension, so it needs to be specified. It's not enough just to tweak the back end to allow the mode attribute. >> You only need two classes of pointers if you expect people to use >> the second class in non-trivial expressions, i.e., dereference them, >> perform pointer arithmetic on them, etc. > > Like the m16c, which lets you put additional less-frequently used data > in function memory? Perhaps, a table of strings, or some CRC lookups? If you really need two classes of pointers, then, sure, you need them. All I did was ask whether or not you really need them and offer a possible solution if you *don't* need them. I am aware of "near" and "far" pointers in Borland (and other) compilers. That's good news; you may have an example to help work through the issues. That doesn't mean that there are no issues. You seem to be trying to convince me that this is a simple thing and that we should just do it and let the chips fall where they may. You might be right -- but since almost every other such change has lead to trouble, I'm not inclined to take chances. Please do the work up front to specify how this interacts with all aspects of the language. That's user documentation we need anyhow. I do think this sounds like a useful feature. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
