CODEWITHSUNDEEP
c++winapi
NFRCR
NFRCR

Reputation: 5580

When using the Win32 API, which data types to use?

Standard data types or Windows data types?

I would use Windows data types to make my code consistent with the Win32 API.

On the other hand, I would use standard data types to protect from coding errors more.

  1. Using nullptr instead of NULL will guard from the bad style of passing NULL for a parameter that actually doesn't take a pointer type.
  2. Imagine a Win32 API function that for some nonsense reason takes an LPTSTR, but would actually treat it as an LPTCSTR. You have a std::string, and do (LPTSTR)(s.c_str()). All is fine until you switch to the W versions of Win32 API functions. The program compiles because casts were successful, but something bad will probably happen. If you had done (char*)(s.c_str()), the compiler would have caught this.

Using standard data types seems safer, but also feels like going to a 'wear-white' party in all black.

What should be decided here?

Upvotes: 2

Views: 1138

Answers (4)

Ben Voigt
Ben Voigt

Reputation: 283891

Windows vs C++ types is a completely orthogonal issue to Unicode-safety.

If you have std::string s, then you can do const_cast<LPSTR>(s.c_str()) just fine without sacrificing the compiler error when you compile as Unicode.

Upvotes: 1

david.pfx
david.pfx

Reputation: 10863

I agree with @fritzone as a practical solution. Mine is slightly different.

I have a strong preference for wrapping external APIs. I will write a layer of code inside which the WinApi is used, and always use Windows types within that layer. This will be the only part of the application that includes Windows.h. The API calls into those layer functions will use types that I choose and (as for @fritzone) I will explicitly cast values to WIndows types as needed. Every cast is a mistake waiting to happen.

The other advantage of layering is that it's a great place to put tracing code. The WinApi can be very chatty and hard to step through in a debugger, so I like to have tracing code for every WinApi function, that can be switched on if needed.

That's harder to do with MFC or ATL, which tend to become rather pervasive. It's been my preference across a wide variety of different external APIs.

Upvotes: 0

vlad_tepesch
vlad_tepesch

Reputation: 6925

hmm - i think the constness of the winapi is quite good. Did you have any examples?

but to your questions:

i would recommend to use the stdint types for your own stuff but when interfacing with winAPI use their types and convert to and from them to avoid difficulties about type widths and confusion what for example WORD means.

Upvotes: 1

Ferenc Deak
Ferenc Deak

Reputation: 35458

This is highly dependent on the project you are working on. Try to follow the already established coding style.

My favourite way of doing things:

  • for methods I declare I use normal data types (void*, char*, etc...) and when I call them I also use this.
  • however for every interaction I do with the Win32 API I either declare the variable to be of Win32 API style (LPVOID, LPTSTR, ...) or if I get the variable from one of my functions (which has "normal" data types), but needs to go to to a Win32 API call, I specifically typecast to the required type. Sometimes this also helps to see if I have some conflicting types.

Upvotes: 2

Related Questions