The arithmetic for void* is not defined, so if you need pointer arithmetic you must do it with a type other than void*. However, the void* is guaranteed to be capable of holding any address on the machine, while other types of pointers do not guarantee it. But, for practical purposes on practical platforms with practical processors you may consider that all pointers are interchangeable. This means that your code should be re-written to: int i[10]; void* p = i; int j = * (((int*)p)+1); In other words: first cast the void* to int*. On practical systems this conversion does not produce any machine instructions, so it is not really executable code. This means that performance is not an issue. After the cast the compiler treats the pointer as an int*, so the "+1" arithmetic is well defined (equivalent to "++"). It will be, in fact, equivalent to advancing the pointer to the address where the next int lies. In Win32 this will be an increment of 4 bytes. I've seen SOLARIS implementations where this same code would produce an increment of 8 bytes, to correctly handle its 8 byte int's. The code I wrote is perfectly legal ANSI, compiles and runs correctly on all platforms, and I wouldn't consider it ugly. Your original code too, except that the precedence is not correct (you increment while the pointer is still void* and at that point it has no arithmetic logic). Anyway, the second piece of code you propose should not compile. But that can be easilly fixed with "+1" instead of "++". But your reasoning changed in the second example, since you forced the cast from void* (that has no arithmetic logic) to char* (that has arithmetic logic) before incrementing, and so the increment is well defined. However, the increment amount is not correct, because sizeof(char) is 1 and not 4. The char*++ points to the next character (1 byte), instead of the next int (4 bytes). That should have resulted in a bad value for j. Didn't it? Anyway, below is a piece of code you can test. I initialized "i" to show you that "j" gets a bad value (after fixing from "++" to "+1"). Also, you can see that "k" and "m" get the correct value. As a final note, the code for all 3 integers "j", "k", and "m" as the same instruction type and count, and their efficiency is the same. Of course "j" is wrong, but the compiler doesn't know that (however, some processors may generate exceptions when integers are not aligned, which may result in crashes or slow operating system exception handling). The "ip" and "n" are not as efficient as the cas
