In my journey to learning C, I’ve come across header files, which are used to (I’m assuming) define a prototype for the source file, as well as structure modules. This feature, in my opinion, is pointlessly not just redundant, but possibly a source for pitfall. The same information can probably be extracted from the source code, if not for the restrictions of the language specification in C.

Say, if I have a GTK project, I will have to use the preprocessor directive, that will require the use of GTK headers that look something like #include <gtk/gtk.h>, and they’re usually in the system path. How do modern languages, like Rust, Zig or Go deal with this situation, where shared libraries are used?

  • zongor [comrade/them, he/him]@hexbear.net
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    2 months ago

    The header file was not originally made for the purpose it is used for today. In previous languages (like Fortran or COBOL) they had a preprocessor which was used for defining constants and macros and the like. The preprocessor is like a glorified cut and paste machine, it can’t do any complex processing by itself. (In fact the C preprocessor is not even Turing complete although it is close)

    The reason why the headers are included at the top is also for historical reasons. In single pass compilers a file is read line by line and parsed into an Abstract Syntax Tree; the function has to be declared before it can be used but sometimes it may be declared in a different file or later in the file. So it’s convenient to put that information in the header.

    Many modern languages use compilers that take multiple passes to generate the code. They will also use internal databases for the objects and their prototypes like a v-table to store data about the program to do optimizations and the like.

    Languages like rust, zig, and go use modules where they have namespaces where specific definitions of code are declared and able to be used later. They also had a series of built in tools like dynamically managing dependencies, linking, etc.

    For most languages they also have a Foreign Function Interface which allows them to call functions written in a different languages (like C shared libraries). All of the managers you mentioned have great FFI functionality and work well with C shared libraries. You can often use C header files in these since they give the function prototype without needing to read the whole source code and find all those definitions (often if the library is proprietary you will only have access to the shared library and the header files).