Can I use void* instead of LPVOID in c? Or LPVOID perform some special functionality then void*
but in the old days, way back when ...
GregS
2010-01-01 05:37:27
Anyone know the history of why this typedef was useful? I suspect it had some relationship with 16 vs 32 bit.
Todd Stout
2010-01-01 05:42:39
I haven't been a Windows programmer back then but I doubt there's so much history about it. Windows has a bunch of LPxyz data types and probably, this is provided for consistency with those names.
Mehrdad Afshari
2010-01-01 05:44:51
@Todd: Naw. The windows developers felt they had to have SHOUTing types for all the system call parameters.
wallyk
2010-01-01 05:45:28
FWIW: "LP" stands for "long pointer". It's a remnant of the horrible Hungarian notation days.
Asaph
2010-01-01 05:51:04
Back on 16-bit 8086, long (far) pointers and short (near) pointers were different: the former was a 32-bit value of segment+offset, and the latter was a 16-bit value of offset (thus could only point to within the same segment). Nowadays there's no distinction between long pointers and any other kind of pointer.
ephemient
2010-01-01 05:57:58
long vs short...16 vs 32 bit?
Todd Stout
2010-01-01 05:59:59
"long/short pointer" is misleading ("far/near" is clearer); it has nothing to do with the datum being pointed at, but rather the pointer representation. A 16-bit system with segmented addressing can access more than 2^16 bytes of address space, but anything outside of the current segment cannot be accessed without a segment prefix. x86-32 and x86-64 use flat addressing (PAE is weird and sorta gives you longer physical addresses, but virtual addresses are still 32 bits), so this is no longer relevant, but the naming was established with Win16.
ephemient
2010-01-01 06:07:17
It seems my original assertion has been unofficially confirmed.
Todd Stout
2010-01-01 06:08:10
@ephemient: IA32 architecture actually supports segmented addressing but virtually all modern operating systems initialize segment base registers to 0 and effectively make a flat address space available.
Mehrdad Afshari
2010-01-01 06:18:29
Right, it's possible use segments in 32-bit mode it but you break compatibility with every library in your environment and more :) (Of course, if you do everything yourself, you can use segments, as Google NaCl does.) x86-64 completely ignores the segment registers, huzzah.
ephemient
2010-01-01 06:42:54
+8
A:
There is no LPVOID type in C, it's a Windows thing.
And the reason those sort of things exists is so that the underlying types can change from release to release without affecting your source code.
For example, let's say early versions of Microsoft's C compiler had a 16-bit int and a 32-bit long. They could simply use:
typedef long INT32
and, voila, you have your 32-bit integer type.
Now let's go forward a few years to a time where Microsoft C uses a 32-bit int and a 64-bit long. In orfer to still have your source code function correctly, they simply change the typedef line to read:
typedef int INT32
This is in contrast to what you'd have to do if you were using long for your 32-bit integer types. You'd have to go through all your source code and ensure that you changed your own definitions.
It's much cleaner from a compatibility viewpoint (compatibility between different versions of Windows) to use Microsoft's data types.
In answer to your specific question, it's probably okay to void* instead of LPVOID provided the definition of LPVOID is not expected to change.
But I wouldn't, just in case. You never know if Microsoft may introduce some different way of handling generic pointers in future that would change the definition of LPVOID. You don't really lose anything by using Microsoft's type but you could be required to do some work in future if they change the definition and you've decided to use the underlying type.
You may not think pointers would be immune to this sort of change but, in the original 8088 days when Windows was created, there were all sorts of weirdness with pointers and memory models (tiny, small, large, huge et al) which allowed pointers to be of varying sizes even within the same environment.
paxdiablo
2010-01-01 06:07:26