OSDev.org

Posted: **Wed Jul 08, 2009 10:50 am**

Firestryke31 wrote:I do admit they could just as well have done this instead of the typedef soup:
typedef void *PVOID;
typedef void *HANDLE;
typedef void *HMENU;
typedef void *HWND;
typedef void *HINSTANCE;
typedef unsigned long DWORD;
typedef void *LPVOID;

How about this?

Code: Select all

typedef struct HMENU { } *HMENU;
typedef struct HWND { } *HWND;
typedef struct HINSTANCE { } *HINSTANCE;
etc

I think it's more readable this way, plus you can't use any void* pointer where a HMENU is expected, you would need a cast. The only issue is that C doesn't allow empty structure types, I think.

Posted: **Wed Jul 08, 2009 11:14 am**

For the function prototypes I was talking about the crappy ones where people do "void setMenu(void*, void*)" as opposed to void setMenu(void *window, void *menu)"

Also, I was under the impression that MSVC++ at least gave a warning if you used the wrong typedef. It's been a while since I last tried something like that.

I'm not saying in any way that there's not a better way to do it, I'm just saying that I've never had any problems using the typedefed versions.

Posted: **Wed Jul 08, 2009 11:43 am**

MSVC does give you a warning based on the typedef -- not on the final decoded type. But I'm with Solar and holypanl -- it's a REALLY stupid and expensive way to try to "protect yourself and others from making tiny, silly type errors in argument lists." It even causes failures in Microsoft's own Visual debugger, because even that can't figure out what the real type of a variable is, so it can't figure out how to display it.

Posted: **Wed Jul 08, 2009 11:58 am**

Hi,

I don't understand why noone has mentioned the large point of type abstraction here. These sorts of typedef are used when the type of the variable has absolutely nothing to do with its use.

What if microsoft wanted to change the type of "HWND" to a (pointer to a) structure? It could, without a problem. If it had used void* everywhere instead, its options would be more limited.

I'm not going to deny that the tree of typedefs in the example given is horrible and atrocious; it doesn't remove the fact that information hiding is a useful tool when used well.

Cheers,

James

Posted: **Wed Jul 08, 2009 12:27 pm**

JamesM wrote:What if microsoft wanted to change the type of "HWND" to a (pointer to a) structure? It could, without a problem. If it had used void* everywhere instead, its options would be more limited.

Erm... why? In C, everything casts to and from void *...

Posted: **Wed Jul 08, 2009 1:09 pm**

Solar wrote:
JamesM wrote:What if microsoft wanted to change the type of "HWND" to a (pointer to a) structure? It could, without a problem. If it had used void* everywhere instead, its options would be more limited.
Erm... why? In C, everything casts to and from void *...

Why do you think littering the code with void*'s and casts makes code more readable?

Better example, what about if you want to change from using a pointer-sized variable to a larger or smaller type?

Posted: **Wed Jul 08, 2009 2:24 pm**

I read somewhere that linux avoids typedefs because you shouldnt hide anything about what your working with, and it can make things less portable; they seem to be greatly against it, but I think it does have alot of good uses if not over done.

here are my reasons why i think they can be good:

1. why not typedef every struct you define within your project, and have some convention designating it as a struct? such as typedef struct mystruct { blah blah.. } mystruct_t;? All defined structs end with _t. The only difference is instead of every time you use the structure, instead of typing out struct mystruct, you save a little time with mystruct_t.

2. typedefs can make things a lot more readable too. When working with page tables and directories, essentially you are using something 4 bytes long, and they can be used all the some way, but if your reading a peice of code it can help to have types like page or directory to make it a bit easier to see what your dealing with.

3. last but not least, why type unsigned int every time, when you can just have a type called u32? yea, it might be a bit less portable, but you can redefine your type for other architectures too if youd like.

Posted: **Wed Jul 08, 2009 3:15 pm**

No, that wasn't the point of the argument. The point of the whole thing we were discussing was the absolutely liberal way in which some people just define, and redefine typedefs for one type, and think it's being done in the name of readability.

Using typedefs for practical type aliasing is, of course, obviously what typedef'ing was made for.

Unnecessary things like:

Code: Select all

//the person is trying to define an array of int, that stores, say, number of inventory items in stock for a grocery store.
typedef int grocery_items;
grocery_items stock[256];

Could, if made into a habit, become a serious harbour programmers other than the original developer. While this one use of ti doesn't seem so bad (although it is illogical), multiple typedefs of this kind, and even worse, compounded typedefs (typedef'ing typedefs into other aliases) can create a hazy, murky mess that others have to tread painstakingly through.

There's nothing wrong with the more normal approach:

Code: Select all

int stock_items[256];

But the examples you gave are all examples of the proper use of typedefs.

Posted: **Wed Jul 08, 2009 4:46 pm**

Solar wrote:
JamesM wrote:What if microsoft wanted to change the type of "HWND" to a (pointer to a) structure? It could, without a problem. If it had used void* everywhere instead, its options would be more limited.
Erm... why? In C, everything casts to and from void *...

And I thought a pointer-sized field was too small to hold a long double... (formally, the C standard says that casts between function pointers and data pointers is not guaranteed to work, but you get the point)

Posted: **Wed Jul 08, 2009 5:11 pm**

JamesM wrote:What if microsoft wanted to change the type of "HWND" to a (pointer to a) structure? It could, without a problem. If it had used void* everywhere instead, its options would be more limited.

You don't want to keep your mind (and options) so open that your brains fall out. Yes, this is exactly the sort of thinking that causes the horrifying proliferation of typedefs in the Win32 API. They kept all their options open on every single variable, setting, function call, format, and every single other damned thing. Does it make their API easy to use and readable? No, it makes it a nightmare. Options are overrated. Setting things in concrete has great benefits, too.

Posted: **Wed Jul 08, 2009 11:12 pm**

Combuster wrote:
Solar wrote:
JamesM wrote:What if microsoft wanted to change the type of "HWND" to a (pointer to a) structure?
Erm... why? In C, everything casts to and from void *...
And I thought a pointer-sized field was too small to hold a long double...

Correct. Never having used the Win32 API myself, and seeing the examples by Firestryke31, I assumed that stuff like HWND would already be pointers, in which case my statement would hold. (And who would make a handle of something as type double?)

Posted: **Thu Jul 09, 2009 10:58 am**

Creature wrote:If you ask me, Microsoft was just too lazy to create actual pointers to objects and it went like this:

Everybody talks about Microsoft like it's one big dumb coder sitting in a chair scratching its collective butt.

The real reasons Win32 doesn't use pointers to objects are twofold:

Win32 pre-dates the time when C++ became popular and stable enough to use for a major OS API.
A lot of the "objects" that those handles point to are in the kernel. Each handle is actually an index into a handle table in kernel space that in turn points to the "real" object. I know this is true of mutexes, semaphores, processes, threads, etc. I'm not so sure about GUI resources, but it's possible since a lot of the User and GDI stuff is in win32k.sys (a special kernel-mode driver).

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.

Posted: **Thu Jul 09, 2009 12:24 pm**

Colonel Kernel wrote:
Creature wrote:If you ask me, Microsoft was just too lazy to create actual pointers to objects and it went like this:
Everybody talks about Microsoft like it's one big dumb coder sitting in a chair scratching its collective butt.

The fact that we imagine it like that is already bad!

Posted: **Sun Jul 12, 2009 7:45 am**

As much as I hate MS, I'm forced to admit that most of the mess is because Win32 is rooted in Win16... which had to deal with far pointers. This is why there are LPVOID and PVOID: The first (Long Pointer to void) meant far pointer, the second near.

This doesn't make it less ugly, but at least it has reason

Posted: **Tue Aug 11, 2009 11:19 am**

ru2aqare wrote: How about this?
Code: Select all
typedef struct HMENU { } *HMENU;
typedef struct HWND { } *HWND;
typedef struct HINSTANCE { } *HINSTANCE;
etc
I think it's more readable this way, plus you can't use any void* pointer where a HMENU is expected, you would need a cast. The only issue is that C doesn't allow empty structure types, I think.

Correct me if I'm wrong but I think gcc allows empty structures. It treats them as if they have a single member of char.

OSDev.org

Pros and cons of typedefing integers

Re: Pros and cons of typedefing integers

Re: Pros and cons of typedefing integers

Re: Pros and cons of typedefing integers

Re: Pros and cons of typedefing integers

Re: Pros and cons of typedefing integers

Re: Pros and cons of typedefing integers

Re: Pros and cons of typedefing integers

Re: Pros and cons of typedefing integers

Re: Pros and cons of typedefing integers

Re: Pros and cons of typedefing integers

Re: Pros and cons of typedefing integers

Re: Pros and cons of typedefing integers

Re: Pros and cons of typedefing integers

Re: Pros and cons of typedefing integers

Re: Pros and cons of typedefing integers