Just my 2 cents on the subject
Pros and cons of typedefing integers
Re: Pros and cons of typedefing integers
HWND, HINSTANCE, HMODULE, HANDLE, etc gives you more information about the type and use of the variable then what void* can. This is type and use information which is better abstracted as they demonstrate what the object is used for.
Just my 2 cents on the subject
Just my 2 cents on the subject
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
Re: Pros and cons of typedefing integers
Yes, information is valuable. But you can carry that information in variable names just fine (which is what Hungarian Notation was invented for, at least before MS did bastardize it).
IMHO, typedef's are great for two things: 1) to abbreviate otherwise unwieldly type names (i.e., function pointers, or deeply nested STL types), and 2) to utterly confuse any programmer not familiar with your family of typedef's for trivial types.
Since the Win API has been that way for ages, I'd say the affected people are already familiar with it. But I would go to great lengths to avoid repeating such a mess...
IMHO, typedef's are great for two things: 1) to abbreviate otherwise unwieldly type names (i.e., function pointers, or deeply nested STL types), and 2) to utterly confuse any programmer not familiar with your family of typedef's for trivial types.
Since the Win API has been that way for ages, I'd say the affected people are already familiar with it. But I would go to great lengths to avoid repeating such a mess...
Every good solution is obvious once you've found it.
-
pcmattman
- Member
- Posts: 2566
- Joined: Sun Jan 14, 2007 9:15 pm
- Libera.chat IRC: miselin
- Location: Sydney, Australia (I come from a land down under!)
- Contact:
Re: Pros and cons of typedefing integers
The key is to not try and fit an object-oriented idea into a non-object-oriented language.But I would go to great lengths to avoid repeating such a mess...
Whilst their reasoning for not using C++ is valid, I think there's a lesson here for programmers even today.The typedefs are arranged the way they are to give some notion of inheritance to the reader... All handles are HANDLEs, an HWND is a "sub-type" of HANDLE, etc. Although it's pretty gross, there is some logic behind it.
Too many people use C because "C++ is too slow" or "I don't like C++" or even "I don't know C++" and come out with all this hacky and horrible C with typedefs all over the place to hide stuff. In C++ a HWND could easily be abstracted out in a different way - for instance, a pointer to a class Window, rather than a handle to a window. They try to fit OO programming into a non-OO language and make everything so much worse in the process.
I guess I should also mention that, at least for most Windows programming these days, you shouldn't need to even worry about this old API. It has thankfully been replaced by something much cleaner, and by something that's really OO