4 ms·

The .h could have been a compiler output, like the .so

kccqzy 9mo ago
The C language is too complicated and too flexible to allow that. If you are starting from scratch and creating a new language, this could be a design goal from the beginning.
- quuxplusone 9mo ago
  > The C language is too complicated and too flexible to allow that. I disagree. In fact, I would expect the following could be a pretty reasonable exercise in a book like "Software Tools"[1]: "Write a program to extract all the function declarations from a C header file that does not contain any macro-preprocessor directives." This requires writing a full C lexer; a parser for function declarations (but for function and struct bodies you can do simple brace-matching); and nothing else. To make this tool useful in production, you must either write a full C preprocessor, or else use a pipeline to compose your tool with `cpp` or `gcc -E`. Which is the better choice? However, I do see that the actual "Software Tools" book doesn't get as advanced as lexing/parsing; it goes only as far as the tools we today call `grep` and `sed`. I certainly agree that doing the same for C++ would require a full-blown compiler, because of context-dependent constructs like `decltype(arbitrary-expression)::x < y > (z)`; but there's nothing like that in K&R-era C, or even in C89. No, I think the only reason such a declaration-extracting tool wasn't disseminated widely at the time (say, the mid-to-late 1970s) is that the cost-benefit ratio wouldn't have been seen as very rewarding. It would automate only half the task of writing a header file: the other and more difficult half is writing the accompanying code comments, which cannot be automated. Also, programmers of that era might be more likely to start with the header file (the interface and documentation), and proceed to the implementation only afterward. [1] - K&P's "Software Tools" was originally published in 1976, with exercises in Ratfor. "Software Tools in Pascal" (1981) is here: https://archive.org/details/softwaretoolsinp00kern/ https://archive.org/details/softwaretoolsinp00kern/
  - kccqzy 9mo ago
    > Write a program to extract all the function declarations from a C header file that does not contain any macro-preprocessor directives There you go. You just threw away the most difficult part of the problem: the macros. Even a medium-sized C library can have maybe 500 lines of dense macros with ifdef/endif/define which depends on the platform, the CPU architecture, as well as user-configurable options at ./configure time. Should you evaluate the macro ifdefs or preserve them when you extract the header? It depends on each macro! And your tool would still be highly incomplete because it only handles function declarations not struct definitions, typedefs you expect the users to use. > the other and more difficult half is writing the accompanying code comments, which cannot be automated Again disagree. Newer languages have taught us that it is valuable to have two syntaxes for comments, one intended for implementation and one intended for the interface. It’s more popularly known as docstrings but you can just reuse the comment syntax and differentiate between // and /// comments for example. The hypothetical extractor tool will work no differently from a documentation extractor tool.
    - Maxatar 9mo ago
      I interpreted OP's post to say that you take a C file after the preprocessor has translated it. How you perform that preprocessing can simply be by passing the file to an existing C preprocessor, or you can implement it as well. Implementing a C preprocessor is tedious work, but it's nothing remotely complex in terms of challenging data structures, algorithms, or requiring sophisticated architecture. It's basically just ensuring your preprocessor implements all of the rules, each of which is pretty simple.
      - kccqzy 9mo ago
        And you had the same misunderstanding as OP. Because you have eliminated all macros during the preprocessor step, you can no longer have macro-based APIs, including function-like macros you expect library users to use, #ifdef blocks where you expect user code to either #define or #undef, and a primitive form of maintaining API compatibility but not ABI compatibility for many things. It’s a cute learning project for a student of computer science for sure. It’s not remotely a useful software engineering tool.
AnimalMuppet 9mo ago
Not for things like public/private, static, virtual. Not for inheritance, either.
- nextaccountic 9mo ago
  You add all those things in a single .c or .cpp source, without manual authoring of .h files (this may require language changes, maybe in C30 and C++30 or something) Then whatever is relevant to the public interface gets generated by the compiler and put in a .h file. This file is not put in the same directory of the .c file to not encourage people to put the .h file in version control.

The C language is too complicated and too flexible to allow that. If you are starting from scratch and creating a new language, this could be a design goal from the beginning.

quuxplusone 9mo ago
> The C language is too complicated and too flexible to allow that. I disagree. In fact, I would expect the following could be a pretty reasonable exercise in a book like "Software Tools"[1]: "Write a program to extract all the function declarations from a C header file that does not contain any macro-preprocessor directives." This requires writing a full C lexer; a parser for function declarations (but for function and struct bodies you can do simple brace-matching); and nothing else. To make this tool useful in production, you must either write a full C preprocessor, or else use a pipeline to compose your tool with `cpp` or `gcc -E`. Which is the better choice? However, I do see that the actual "Software Tools" book doesn't get as advanced as lexing/parsing; it goes only as far as the tools we today call `grep` and `sed`. I certainly agree that doing the same for C++ would require a full-blown compiler, because of context-dependent constructs like `decltype(arbitrary-expression)::x < y > (z)`; but there's nothing like that in K&R-era C, or even in C89. No, I think the only reason such a declaration-extracting tool wasn't disseminated widely at the time (say, the mid-to-late 1970s) is that the cost-benefit ratio wouldn't have been seen as very rewarding. It would automate only half the task of writing a header file: the other and more difficult half is writing the accompanying code comments, which cannot be automated. Also, programmers of that era might be more likely to start with the header file (the interface and documentation), and proceed to the implementation only afterward. [1] - K&P's "Software Tools" was originally published in 1976, with exercises in Ratfor. "Software Tools in Pascal" (1981) is here: https://archive.org/details/softwaretoolsinp00kern/ https://archive.org/details/softwaretoolsinp00kern/
- kccqzy 9mo ago
  > Write a program to extract all the function declarations from a C header file that does not contain any macro-preprocessor directives There you go. You just threw away the most difficult part of the problem: the macros. Even a medium-sized C library can have maybe 500 lines of dense macros with ifdef/endif/define which depends on the platform, the CPU architecture, as well as user-configurable options at ./configure time. Should you evaluate the macro ifdefs or preserve them when you extract the header? It depends on each macro! And your tool would still be highly incomplete because it only handles function declarations not struct definitions, typedefs you expect the users to use. > the other and more difficult half is writing the accompanying code comments, which cannot be automated Again disagree. Newer languages have taught us that it is valuable to have two syntaxes for comments, one intended for implementation and one intended for the interface. It’s more popularly known as docstrings but you can just reuse the comment syntax and differentiate between // and /// comments for example. The hypothetical extractor tool will work no differently from a documentation extractor tool.
  - Maxatar 9mo ago
    I interpreted OP's post to say that you take a C file after the preprocessor has translated it. How you perform that preprocessing can simply be by passing the file to an existing C preprocessor, or you can implement it as well. Implementing a C preprocessor is tedious work, but it's nothing remotely complex in terms of challenging data structures, algorithms, or requiring sophisticated architecture. It's basically just ensuring your preprocessor implements all of the rules, each of which is pretty simple.
    - kccqzy 9mo ago
      And you had the same misunderstanding as OP. Because you have eliminated all macros during the preprocessor step, you can no longer have macro-based APIs, including function-like macros you expect library users to use, #ifdef blocks where you expect user code to either #define or #undef, and a primitive form of maintaining API compatibility but not ABI compatibility for many things. It’s a cute learning project for a student of computer science for sure. It’s not remotely a useful software engineering tool.

AnimalMuppet 9mo ago

Not for things like public/private, static, virtual. Not for inheritance, either.

nextaccountic 9mo ago
You add all those things in a single .c or .cpp source, without manual authoring of .h files (this may require language changes, maybe in C30 and C++30 or something) Then whatever is relevant to the public interface gets generated by the compiler and put in a .h file. This file is not put in the same directory of the .c file to not encourage people to put the .h file in version control.