• Advertisement
Sign in to follow this  

Differentiating between original and typedef'd types

This topic is 4178 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Is there any way to differentiate between a basic type and a type that has been typedef'd to it? I want to write two versions of a function, one for the 'int' type, and one for the 'BOOL' type - where BOOL is defined in the windows headers via "typedef int BOOL;". Is there any way of wiring it up to work without giving the two functions different names?

Share this post


Link to post
Share on other sites
Advertisement
I suspect you can't use bool instead of BOOL due to the win api? is this correct

Share this post


Link to post
Share on other sites
No. A typedef is simply another name for an existing type, not a new type. You cannot tell it apart from the original type except by parsing the source code.

EDIT: Depending on the situtation you might be able to create your own type with implicit conversions to and from BOOL and use that instead of BOOL in your code.

Σnigma

Share this post


Link to post
Share on other sites
Rats. Thanks anyway.

Quote:
Original post by dmail
I suspect you can't use bool instead of BOOL due to the win api? is this correct
Yep. Ordinarily, converting from bool to BOOL isn't a problem, but I'm dealing with a situation involving an array of BOOLs, so conversion involves changing the stride of the array.

Share this post


Link to post
Share on other sites
Maybe somebody could answer this related question, which I have never understood.
Why on earth did microsoft decide that a BOOL which only has two values occupies a 32bit int instead of an unsigned char?

Share this post


Link to post
Share on other sites
Quote:
Original post by dmail
Maybe somebody could answer this related question, which I have never understood.
Why on earth did microsoft decide that a BOOL which only has two values occupies a 32bit int instead of an unsigned char?


I guess its all about whats faster for the CPU. 32bit CPUs work faster if things ar 32 bit-aligned, and we seem to have a lot of RAM, but never enough speed, so that could explain their decision...

Share this post


Link to post
Share on other sites
So would you exspect a BOOL to be quicker than bool?
And does a BOOL on a 64bit cpu get typedeffed as a 64bit int?

Share this post


Link to post
Share on other sites
ints are typically 32-bit even with 64-bit compilers/OS's. This is true for both Windows and Linux. It may not be true for other compilers and/or OS's.

If you look around a bit you'll see endless debates on this forum about whether or not "typedef int BOOL" is better than "typedef char BOOL" for whatever definition of "better" the poster cares about. Whether or not it actually is depends heavily on the details of the scenarios you care about.

superpig - just think of it as "typedef" being pretty much the worst name in the entire C/C++ language since it doesn't actually define a type. It defines an alias for a type.

Share this post


Link to post
Share on other sites
Quote:
Original post by dmail
Maybe somebody could answer this related question, which I have never understood.
Why on earth did microsoft decide that a BOOL which only has two values occupies a 32bit int instead of an unsigned char?


For a start, Microsoft's BOOL type has at least 3 distinct meaningful values. It's not a boolean type, it's an integral type.

Share this post


Link to post
Share on other sites
Quote:
Original post by Bregma
For a start, Microsoft's BOOL type has at least 3 distinct meaningful values. It's not a boolean type, it's an integral type.


FileNotFound?

Share this post


Link to post
Share on other sites
Ex: check the return values for GetMessage(). The return value type is a BOOL, but can be 0, -1 or some other value, with -1 and other values having different meanings.

Share this post


Link to post
Share on other sites
The Win API uses BOOL < 0 for errors. The trick is, they still evaluate to false, but carry more specific information than just 'operation failed'.

Share this post


Link to post
Share on other sites
Quote:
Original post by Deyja
The trick is, they still evaluate to false, but carry more specific information than just 'operation failed'.

You have a very odd definition of "evaluate to false".

Share this post


Link to post
Share on other sites
Well, okay, they evaluate to exactly the opposite of what I said. The point is, all the 'error values' evaluate to the same boolean value.

Share this post


Link to post
Share on other sites
It's not quite that straightforward. For example, CreateProcess() returns 0 on error, and you use GetLastError() to figure out the error type, while GetMessage() returns -1 on error, but 0 is a non-error return value. So the CreateProcess() error evaluates to boolean false, but GetMessage() error evaluates to boolean true.

Share this post


Link to post
Share on other sites
... And after all that, they have the nerve to call it 'BOOL'. I think that's the *real* WTF. :)

Share this post


Link to post
Share on other sites
Eh. It's one of the consequences of maintaining a more or less single API over many, many moons. Originally BOOL meant a boolean value, but sometimes it was used in places where it wouldn't be adequate. It happens. This is why more recent WinAPI functions use DWORD as a return type even when the return value would be interpreted as a boolean value.

edit: spelling

[Edited by - SiCrane on August 12, 2006 6:22:49 PM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement