Thread: Where to put our structures?

Hello,

I am a C programmer. I program micro-controllers... mainly PICs.

I have a C question about where structure definitions should reside. Most of us create a pair of files called xxx.h and xxx.c and usually put the structure's definition in the header file along with function prototypes. We then put our function implementations in the xxx.c file.

Lately I took a look at the WinUser.h file and to my surprise I have seen many strutures defined in this file. So why do they define structures in one big common header called WinUser.h when we were taught to define every structure in its own header file in respect to its associated .c file?

For example, in my project I have a header file called "UDT.h" and this header file contains two (2) structures. I also have a .c file called "UDT.c" which holds all the function implementations that manipulate the structure's data. Here is the header file:

Code:

=========================================UDT.h
typedef struct 	T_udt 	udt;

typedef struct tag_fields  
{
unsigned short LKdct__F1; 
unsigned short LKdct__F2;                    				  
unsigned short  LKdct__F3;  
unsigned short  quit_flag;                    			
unsigned short  title_msg1;  					
}Tfields; 

struct T_udt  
{ 								 
unsigned short f__pc_xchoice; 				        
unsigned short f__list_lenght; 				
unsigned short IndexesUsed;
Tfields	*fields;                     
}; 
=====================================

Now there is three (3) ways we can do this, where we can:

A) Define the two (2) structures in the same header file as done above

OR

B) Define only the "tag_fields" structure in a "Com.h" header (like the WinUser.h does) and keep the "T_udt" structure in the "UDT.h" file

OR

C) Define both structures in a "Com.h" header (like the WinUser.h does)

Which would be to most politically correct way to do this. Confused.

All feedback or help is appreciated.

rob

I think you're making a conceptual error here... WinUser is a huge library but it only contains a very small portion of the overall Windows API. If you look at other headers in the Windows API you will discover structures, variables, functions, etc. prototyped in almost all of them. The API follows the common convention of defining what's needed and what's in a specific library, although because of it's size, some libraries will have more than one associated header.

The general rule of paired files is still the best practice...

Hello CommonTater,

Yes but what if some other .c file (for example "other.c") needs the "tag_fields" structure.... Then wouldn't it be a good idea to put it in a common header "Com.h" file and have the other.c file include the "con.h" file so it can use the "tag_fields" structure !!!!!

I mean perhaps the "T_udt " structure is well in its place that is in the "UDT.h" file where it belongs since it has a close relation with the "UDT.c" implementation file. But the "tag_fields" structure should be available for re-usability for the overall project... no?

I mean mind you, this is a little shady for me...... please do get back.

Thankyou for your reply... it is very appreciated.
r

Hi guys,

MK27:

<
-if other.c has a header, and one of the prototypes includes a "tag_fields" as an argument, I would #include com.h in other.h, exactly the way I would a standard library header if required.
>

And this is exactly my case. Below is a couple of modules which use the Tag_Fields structure in different ways. What is wrong with storing the "Tag_Fields" structure in a common file (COM.h) along with many other stryctures of the like and using it as shown below. Here a quick sample.... please excuse me for I have coded this up really quickly and did not try to compile it so therefore there might by syntax errors. However, the sample below is simply there to get the idea of what we are discussing. Thanks for your comprehension!

Code:

=========================================COM.h
typedef struct tag_fields  
{
unsigned short LKdct__F1; 
unsigned short LKdct__F2;                    				  
unsigned short LKdct__F3;  
unsigned short quit_flag;                    			
unsigned short title_msg1;  					
}Tfields; 


=========================================UDT.h
#include "COM.h"

typedef struct  T_udt udt;

struct T_udt  
{ 								 
unsigned short f__pc_xchoice; 				        
unsigned short f__list_lenght; 				
unsigned short IndexesUsed;
Tfields	*fields;                     
}; 

udt* newUDT();
=========================================UDT.c
#include "UDT.h"

udt* newUDT(){
udt* pUdtObj;

pUdtObj = (udt*)malloc(sizeof(struct T_udt));
// set udt member defaults here

pDefObj->fields = (Tfields*) malloc(sizeof(struct tag_fields));
// set tag_fields members here

return pUdtObj;
}

=============================================



=========================================ABC.h
#include "COM.h"

typedef struct  T_abc abc;

struct T_abc  
{ 								 
unsigned short xxx; 				        
unsigned short yyy; 				
unsigned short IndexesUsed;
Tfields	*fields;                     
}; 

abc* newABC();

=========================================ABC.c
#include "ABC.h"

abc* newABC(){
abc* pAbcObj;

pAbcObj = (abc*)malloc(sizeof(struct T_abc));
// set udt member defaults here

pAbcObj->fields = (Tfields*) malloc(sizeof(struct tag_fields));
// set tag_fields members here

return pAbcObj;
}
=============================================


=========================================DEF.h
#include "COM.h"

typedef struct  T_def def;

struct T_def  
{ 								 
unsigned short www; 				        
unsigned short vvv; 				
Tfields	*fields;                     
}; 

def* newDEF(*Tfields pTFieldsObj);
=========================================DEF.c
#include "DEF.h"
// functions implementatios

def* newDEF(*Tfields pTFieldsObj){
def* pDefObj;

pDefObj = (def*) malloc(sizeof(struct T_def));
// do other default settings...

pDefObj->fields = pTFieldsObj;

return pDefObj;
}

// other function implementations ....
=============================================

int main()
{
udt* pUdtObj;
abc* pAbcObj;
def* pDefObj;
TFields  fields;

pUdtObj = newUDT();      // An udt object setting the members of the Tfields object *in* the new() function! 
pAbcObj = newABC();      // Another object "abc"  setting the members to the Tfields object *in* the new() function! 

//.... other code here 

fields.LKdct__F1 = 10;    
fields.LKdct__F2 = 11;
fields.LKdct__F3 = 12;
fields.quit_flag = 1;                    			
fields.title_msg1 = 100;  

pDefObj = newDEF(&fields);   // Another object "def" preseting the TFields members and then passing in the address of the TFields object! 

// ... other code

// All free operations here.....

return 0;
}

================================================

Regards
r

<
Nothing, altho if def.h and abc.h are both included in the .c file with main(), you'll have to put include guards in com.h (as per CommonTater post #5 above).
>

Yes. Absolutely. I usually include inclusion guards in all my .h files anyways for best security. Although I am not sure about this, I probably wouldn't need to if all my header files only include "COM.h"! I don't know I would have to carefully think about this.

Thanks guys!

Do not use the name com.h; most programmers with hardware experience will assume com means communications.
I have seen projects that use common.h to include all of the project headers in one file; I consider it a valid way to program.
NOTE: I would still put header guards in all the .h files.

I also use const.h, global.h or globals.h, and type.h or types.h if there is things that do not fit in a header file that matches a c/cpp file.

Note: I do not normally use an globals.c file with my globals.h; but others on this and other sites consider that bad practice.
NOTE: Most of the people consider just have global variables bad practice; but, I have found in the embedded world it is needed because of lack of stack space.

Tim S.