-1

I am a .net developer. I am use to data types such as: chars, strings, booleans, integers, longs and decimals.

I have university experience with c++ years ago and i learning about the windows api in my spare time.

There are lots more data types with the windows api and i now understand the reason for this. However, if you wanted to use a 32 bit data type then could you use any 32 bit data type or are you restricted to the 32 bit data type that meets your specific requirements?

w0051977
  • 15,099
  • 32
  • 152
  • 329
  • All of the winapi "extra data types" are eventually core C++ data types. – Hatted Rooster Sep 27 '14 at 08:37
  • If you rely on anything having 32 bit, then you should use a type that explicitly expresses this, e.g. [U]INT32 from win32 or [u]int32_t from C99. Chances are that both will refer to the same underlying fundamental type (like e.g. long). – Ulrich Eckhardt Sep 27 '14 at 08:38

2 Answers2

0

At the "bottom" of the compiler, there are only a small number of actual data types - it depends a little on the actual compiler implementation how those are described, but for example LLVM has

  • i1 which represents bool
  • i8 which represents char
  • i16 which represents short
  • i32 which represents int (and sometimes long)
  • i64 which represents long long (and sometimes long)

The LLVM compiler also understands pointers as a separate thing.

Signed and unsigned types are only relevant when performing some operations, so at the base layer, the compiler doesn't differentiate them except for when it does operations where it matters - mainly less than/greater than are affected by signed/unsigned.

Which one do you choose? It really depends. Do you want a guaranteed size always (good for file formats, protocols and API functionality) - if so, use uint32_t or int32_t from with #include <cstdint>. If you just want something that "is bigger than short", then use int (assuming we know that we're never going to compile this on a system with 16-bit integers!) - int is defined as "a type that is natural to the machine, and will be fast", which is not guaranteed to be the case of int32_t (it IS the same thing on all existing Windows platforms, but it's not certain to be the case in the future and/or on other platforms)

If you want code that is portable, it may make sense to do your own typedef, e.g. 

typedef uint32_t count_type;

That way, if you ever need to change that type, you only need to change it in one place.

Windows has its own definitions, largely because there wasn't any strict types defined at the time, so they had to make up their own - and of course, once you have introduced a name for a type, it's going to break a lot of code if you remove that name, just because there is another name that does the same thing - at the same time, the standard requires the new types, so they are also defined.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
0

There are lots more data types with the windows api and i now understand the reason for this.

Which is?

For most programming tasks, the data types in the Windows API usually just complicate things and gain you nothing. They are not additional types but typedefs, i.e. different names for the same (fundamental) type. This is not type-safe. For example, UINT32 is a typedef for unsigned int. Which means the following works:

void f(UINT32 x);
// ...
unsigned int i;
f(i); // no compiler error even though you used the "wrong" type

However, if you wanted to use a 32 bit data type then could you use any 32 bit data type or are you restricted to the 32 bit data type that meets your specific requirements?

First of all, you should ask yourself if the requirement of using precisely 32 bits is not just an artificial one. I mention this because people often bring up such requirements for supposed performance gains, or because they want to be "closer" to the machine and do not trust their compiler and environment to generate optimal binaries; both of which are very questionable assumptions.

The rule in C++ is, if you have no good reason to do so otherwise, just use int for numbers.

The second thing to consider is whether you require the type to have at least 32 bits. If so, the C++ standard makes several guarantees about minimum widths. As you can see, unsigned long is an example of a type guaranteed to have at least 32 bits.

If you need a completely fixed width, consider the new C++11 data types.

In any case, if you are actually performing bit operations, then use unsigned types. This is one of the "good reasons" mentioned above. Unsigned should be avoided for about anything else due its broken integer arithmetics, but is the best choice for bit operations as far as primitive types are concerned. And finally, since you are using C++, why not use std::bitset? It is a more high-level construct for bit operations and may considerably speed up your work and increase the robustness of your code.

Christian Hackl
  • 27,051
  • 3
  • 32
  • 62
  • Some of the data types in windows date back to the days of MSDOS, and are in common with the assembler types: BYTE, WORD, DWORD, QWORD. There is a lot of legacy stuff for [Windows types](http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx) – rcgldr Sep 27 '14 at 09:44
  • @rcgldr: Yes, but I would hope that maintaining MSDOS legacy code was not a common programming task in the grand scheme of things (I may be too optimistic there :)). – Christian Hackl Sep 27 '14 at 09:53
  • Christian Hackl - by MSDOS, I only meant that's how far back it goes, mostly the assembler types (which are still the types with the current versions of masm.exe / ml.exe). At most of the companies I've worked for, the preference was for unsigned types unless signed was really needed (such as math oriented stuff as opposed to looping, shifting). An example is a preference of using size_t (an unsigned type) for indexing types. – rcgldr Sep 27 '14 at 11:15
  • @rcgldr: Using unsigned types does not prevent negative values but makes it harder to detect them. Your companies' guidelines were questionable and should have been changed. See http://stackoverflow.com/questions/10168079/why-is-size-t-unsigned (also for references to Stroustrup and Meyers). – Christian Hackl Sep 27 '14 at 11:38