Storage Sizes and Other Useful Properties: Windows, C++, and C Variable Types

• Download Windows_and_C___Data_Type_Tables.ZIP - 124.2 KB

Introduction

About ten years ago, I created a simple chart that listed the basic properties, including storage requirements, of the most common basic (discrete) data types likely to be encountered in Windows programming. About a year and a half ago, I created a greatly expanded chart, along with charts focused on data types encountered in C and C++ programming.

Background

In day to day programming, it is occasionally handy to be able to look up the basic properties of some type that you use infrequently, such as, for example, that a LANGID (Language ID) is a WORD, a 16 bit unsigned integer, while a LCID (Locale Identifier) is a DWORD, a 32 bit unsigned integer. Furthermore, having every primitive type you are likely to need organized into one chart, alphabetized by name (e. g., LANGID), with a named workbook scoped range defined over them makes child’s play of creating dead accurate structure definitions, complete with offsets, to document their organization and size, and as an invaluable debugging aid.

Using the Charts

I chose my section title intentionally, because there is no “code” in this article, only a Microsoft Excel workbook, Windows_and_C++_Data_Type_Tables.XLSX, and a companion Microsoft Word document, Windows_and_C++_Data_Type_Tables_Security.DOCX, which contains the passwords the protect the worksheets against accidental changes. Though you may never need them, you should have them, just in case.

Figure 1 shows the upper left corner of the Windows Data Types worksheet, while Figure 2 shows the part that I use most often. 

Figure 1 shows the upper left corner of the Windows Data Types worksheet, a comprehensive index of details about discrete (primitive) data types defined in the Windows SDK headers..

Figure 2 is the far right edge of the Windows Data Types worksheet shown in Figure 1, which is the part that I use most often.

Just above the detail columns shown in Figure 2 is a small chart that bears explanation. Above, I hinted that there is a named range defined over this table, and this chart is your quick guide to writing VLOOKUP formulas against it. Combined with the True/False values in columns AG and AH, such lookups populate columns AI, AJ, and AR based on the values set in input validated cells AI3 through AI5. Though the top two settings apply as well to the CRT, I learned, the hard way, that you must define _UNICODE to get a wide character call into the CRT library.

Pay particular attention to the three unprotected cells (the cells with a green background) shown at close range in Figure 3. These input validated cells let you specify which of the preprocessor symbols that affect memory sizes of objects are set for your build. These settings affect the values shown in columns 37 through 39, though mostly the latter two. For pointer types, column 39 shows the value in 38, otherwise, the value from column 37 appears; hence, it is identified as the value occupied by a structure member of that type.

Figure 3 is a close-up of a three-celled area where you can indicate which of several preprocessor symbols are defined in your build; these determine the memory sizes shown in the chart below. This example shows the settings fora Win32 Unicode build.

Table 1 describes the key ranges defined over various parts of the workbook. Range Windows_Data_Types is especially useful because you can use it along with the numbers in row 5 of the worksheet to build a formula to look up the memory required to store a variable of a specific type or a pointer to such a variable. Column AB (number 36), labeled Prefix, contains my Hungarian notation prefixes; if you use different prefixes, you may input your own, and use this column to generate correctly prefixed Hungarian variable names.

Figure 4 is worksheet OPENFILENAME_NT4A, a demonstration of how you can leverage the data in the Windows Data Types worksheet to map the memory requirements and layout of a data structure.

Figure 4 is an example of how you can map the layout of a structure in memory; please feel free to use this as a starting point for your own worksheets, since you may as well take full advantage of the work I already put into it. I chose the OPENFILENAME_NT4A structure, defined in commdlg.h, because it includes a variety of items, and is sufficiently big that you probably don’t want to work out an offset by counting members. This structure contains one member, lpfnHook, that isn’t a primitive type, and a couple of pointer types. However, cell D24 shows the typedef, also in commdlg.h, from which I deduced that it is a UINT_PTR, which is one.

The Hungarian variable names worksheet is left for the enterprising reader, but there is more than enough information in this article and the workbook that you should be able to do so quickly and easily.

You are on your own to explore the other worksheets, and I shall be happy to entertain questions in the discussion threads that attach themselves to the article.

Points of Interest

The workbook included with this article sports two new columns that further simplify its use in constructing memory maps of data structures, along with the sample structure worksheet. I plan to overwrite my original with this improved version for use going forward.

History

Wednesday, 28 June 2016, submitted for publication.