CODEWITHSUNDEEP
c++windowsapitypes
LppEdd
LppEdd

Reputation: 21172

Windows programming and data types

I'm currently working on a Windows application project. I'm developing it with Windows API and I need to set few standard.

The important one:

  1. should I use Windows data types (DWORD, TCHAR, LPSTR...) or standard data types?
  2. should I use them everywhere in my code or only in some parts of it?

Thank you.

EDIT: What do you think about SAL annotation? http://msdn.microsoft.com/en-us/library/hh916382.aspx

Should I use it on the header files?

Upvotes: 0

Views: 264

Answers (2)

Joel
Joel

Reputation: 1145

Part of this question is simply opinion, but my recommendations are:

I would say yes to things like DWORD. You should not assume a specific underlying type for the Windows data types. You should only assume that if the function says it takes a DWORD, then you need to provide it a DWORD. It ensures that if Microsoft changes the underlying types then your code should still work with no to minimal changes.

A good example of this is the WPARAM and LPARAM types which have been changed a few times I think. Now they are basically defined to be "large enough to hold a pointer", which means they are different sizes between 32-bit and 64-bit Windows.

I would say no to things like LPCTSTR, because to me it is clearer to say const TCHAR* - the whole "long pointer" thing is a relic of 16-bit Windows. However, note that I said const TCHAR* and not const wchar_t*.

When it comes to using it everywhere, I would say definitely don't use it in any part of your code that needs to be portable - although you can create your own typedefs whose underlying types are Windows data types when you are compiling for Windows, such as:

typedef TickCount DWORD;

I would mostly bother with that if you are trying to use code that might have a "tick count" concept and needs to run on another operating system, but at that point you need an abstraction layer between your code and the Windows API, anyway.

Update for the edited question:

I don't have any experience with SAL myself, but it doesn't seem like a terrible idea at first glance. It makes explicit how a parameter is used without relying on documentation, and as the MSDN docs say they use it with static code analysis tools. If you have such tools that can confirm you are using the annotations correctly, it seems like an OK thing to do to me. My immediate reaction is that it does make declarations a little harder to read, but one of the toughest things about defining APIs in general is making sure the expected behaviors are well-documented and understood.

Upvotes: 2

tohava
tohava

Reputation: 5412

For values that go directly to windows API, use windows types. For values that are only used for your own internal calculations, use your own types (or something like stdint.h). For values that are used in both, use your own types and cast to windows types when needed.

Upvotes: 1

Related Questions