Pros and cons of typedefing integers

[ru2aqare]

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.

[Firestryke31]

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.

[bewing]

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.

[JamesM]

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

[Solar]

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 *...

[JamesM]

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?

[yemista]

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.

[gravaera]

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.

[Combuster]

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)

[bewing]

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.

[Solar]

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?)

[Colonel Kernel]

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:

1. Win32 pre-dates the time when C++ became popular and stable enough to use for a major OS API.
2. 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.

[Creature]

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!

[Owen]

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

[tharkun]

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.