{"id":6037,"date":"2023-09-23T00:01:48","date_gmt":"2023-09-23T07:01:48","guid":{"rendered":"https:\/\/c-for-dummies.com\/blog\/?p=6037"},"modified":"2023-09-30T08:12:50","modified_gmt":"2023-09-30T15:12:50","slug":"memory-file-multi-module-implementation","status":"publish","type":"post","link":"https:\/\/c-for-dummies.com\/blog\/?p=6037","title":{"rendered":"Memory-File Multi-Module Implementation"},"content":{"rendered":"

At 205 lines of code in last week’s Lesson<\/a>, my memory-file project is getting larger by the day. At some point, the source code files must be broken out into separate modules, then compiled and linked separately. This is how I handle all large projects when it becomes too unwieldly to edit everything in a single file.
\n
\nIt’s up to the programmer to decide which functions dwell in which source code file. For a game I wrote, I had separate modules for initializing, a main loop, moving pieces, and recording scores. A module, or separate source code file, can exist for each function. No hard rules exist.<\/p>\n

Once you separate a single source code file into multiple modules, you should also consider writing a local header file to handle all the defines, includes, and prototypes. This step greatly improves efficiency and makes adding new functions and modules a lot easier.<\/p>\n

For the memory-file programs, I split the file from last week’s Lesson into three separate source code files:<\/p>\n

main.c<\/code> contains the main()<\/em> function only
\nmemfile.c<\/code> contains all the memory file functions
\nmemfile.h<\/code> contains the required includes, structure definition, defined constants, and all the function prototypes<\/p>\n

The main.c<\/code> and memfile.c<\/code> source code files contains the same code shown last week, just in separate files. To each I added this preprocessor directive:<\/p>\n

#include \"memfile.h\"<\/code><\/p>\n

The double quotes direct the preprocessor to look in the current directory for the file memfile.h<\/code>. This file contains material pulled from the original, long source code file, plus other necessities:<\/p>\n

\r\n#include <stdio.h>\r\n#include <stdlib.h>\r\n#include <time.h>\r\n\r\n\/* defines *\/<\/span>\r\n\r\n#define DEFAULT_SIZE 2048\r\n\r\n\/* structures *\/<\/span>\r\n\r\nstruct mem_file {\r\n    void *address;\r\n    char *name;\r\n    int size;\r\n    int offset;\r\n    char *timestamp;\r\n};\r\n\r\n\/* prototypes *\/<\/span>\r\nint mem_seek(struct mem_file *m, long position, int whence);\r\nint mem_putc(int c, struct mem_file *m);\r\nint mem_getc(struct mem_file *m);\r\nstruct mem_file *mem_open(char *fn);\r\nvoid mem_close(struct mem_file *m);<\/pre>\n
The file includes all the header files required by the other modules, shown first. Then comes the defined constant and structure used by the various functions.<\/p>\n
The last part of the file lists all function prototypes. These are the required. If you create a multi-module project and forget the prototypes, the linker pukes up a lot of errors. Therefore, setting them all in a local header file makes a ton of sense.<\/p>\n
To create the program, you must compile each module then link the object code files to create a program. In the terminal window, a single command handles the task:<\/p>\n
clang -Wall main.c makefile.c -o main<\/code><\/p>\n
I use the clang<\/em> compiler, though you can specify gcc<\/em> or whatever you use.<\/p>\n
The -Wall<\/em> switch turns on all warnings.<\/p>\n
Next come the C source code files, one after the other.<\/p>\n
The -o<\/em> switch directs clang<\/em> to send output the file name that follows, main<\/em>.<\/p>\n
At the end of the operation, and upon success, the program file main<\/em> is created.<\/p>\n
When source code files get too big, it’s efficient to split them up. Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-6037","post","type-post","status-publish","format-standard","hentry","category-main"],"_links":{"self":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/6037","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6037"}],"version-history":[{"count":5,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/6037\/revisions"}],"predecessor-version":[{"id":6061,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/6037\/revisions\/6061"}],"wp:attachment":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6037"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6037"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6037"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Things get complicated as the number of source code modules increases. Also, you often don’t need to compile source code files that haven’t been updated. To make the process more effective, you can use the make<\/em> utility to ensure that the source code files are compiled and linked as needed. I cover this utility in next week’s Lesson<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"