5 ms·

In principle I agree. An IDE should be able to automatically generate something like a header file regardless of language. But still, no IDE or tool I've seen

by tjoff 8y ago

In principle I agree. An IDE should be able to automatically generate something like a header file regardless of language. But still, no IDE or tool I've seen does this better. A header file gives you a very nice overview, and it really isn't any hassle to speak of to keep them up to date. It takes getting used to (as with everything when starting out with a new language), but before you know it you might even start to miss them in other languages.

int_19h 8y ago
Separation of module interface and module implementation is useful, but headers are a horrible way to do that. For an example of how it can be done right, look at Borland Pascal dialects (with "interface" and "implementation" section in each unit, where "interface" can be extracted if desired), or Ada, or ML.
tech_tuna 8y ago
>it really isn't any hassle to speak of to keep them up to date Dear lord, all those broken builds I've seen over the years would love to talk to you about that.
setpatchaddress 8y ago
That has not been my experience in 35 years of dealing with headers in C and C++ in large-scale software projects. Ruby, Swift, and even Python (or Pascal if we want to go way back) are significantly easier to deal with for anything sophisticated.
kazinator 8y ago
> An IDE should be able to automatically generate something like a header file regardless of language. https://www.hwaci.com/sw/mkhdr/ https://www.hwaci.com/sw/mkhdr/
pcwalton 8y ago
Header files absolutely are a hassle to keep up to date. Besides, they're a terrible experience. You have to pay attention to include order! You have to write forward declarations! You have to write include guards, in 2018! They're also bad as an overview. They may have been good in the 1980s, but nowadays a proper documentation generator gives you better formatting, search features, and cross-references. Inline documentation is particularly obnoxious in header files: I like seeing function-level documentation alongside interface and implementation, but if I put the documentation in both the .cpp and the .h file it's duplicated in two places and easily gets out of date.
- westmeal 8y ago
  Does #pragma once count as an include guard in your book?
  - jchb 8y ago
    #pragma once is not in any C++ standard, although basically all modern compilers support it. The reason it is not in the standard is that its behaviour in the presence of symlinks may differ depending on the filesystem and compiler. Is it the unique combination of filename + content that should be included once or is it the file path? etc.
    - josefx 8y ago
      > The reason it is not in the standard is that its behaviour in the presence of symlinks may differ depending on the filesystem and compiler I have the feeling that the difference matters to almost nobody and should be avoidable by the few people it actually affects. I had more issues with colliding include guards than I had with symlinks and I still end up replacing CLASSNAME_H with PROJECT_CLASSNAME_H in our own headers every now and then since the autogenerated guards are too naive.
- beached_whale 8y ago
  The order of headers mattering is very rare though and not indicitive of normal C++ code. It's rare, but not unheard of unfortunately as most C code is also available to C++.
- tjoff 8y ago
  > You have to pay attention to include order! You have to write forward declarations! You have to write include guards, in 2018! Include order is a valid complaint, the others truly are non issues. I mean, we have other more pressing issues. Such as the fact that garbage collection is still a thing in 2018. > ...but nowadays a proper documentation generator gives you better... Examples of that? > I like seeing function-level documentation alongside interface and implementation, but if I put the documentation in both the .cpp and the .h file it's duplicated in two places and easily gets out of date. This is the only thing that I dislike about header files. And it is a constant reminder how bad IDEs are at handling this.
DenisM 8y ago
> no IDE or tool I've seen does this better. Modula-2 does it better. Each module split in two files - definition and implementation. Unlike C++ header files, def files are compiled rather that inlined, so they don't have a potential to produce different result for each source file that references them. The result is 100% reliable dependency graph across all source files, no need for a makefile, and blazingly fast compilation (each def file is only parsed and compiled once).
- codesmythe 8y ago
  OCaml also does it better. Its split between .ml (implementation) and .mli (definition) files is taken directly from Modula-2 [1]. [1] https://discuss.ocaml.org/t/what-is-the-reason-of-separation-of-module-implementation-and-signatures-in-ocaml/1735/33 https://discuss.ocaml.org/t/what-is-the-reason-of-separation...
tomcam 8y ago
> But still, no IDE or tool I've seen does this better. Why aren't Delphi, Oberon, and Modula-3 immensely better? Each file is an independent module except the one with main. Then the compiler quickly figures out in one pass what all the function signatures are. The minor drawback with this is that the one-pass method requires you to pay attention to declaration order, though a two-pass method renders that approach irrelevant. The IDE has all the symbolic goodness you need, and no goddamn header files. Also it's still easier than dealing with managing the dependency graph yourself as is necessary with C file include order. I say this as a guy who enjoys C and has done way more work in C than Delphi, but give credit where it's due.
- malkia 8y ago
  I started with Apple ][ Basic, but then moved to Turbo Pascal 3.0, 4.0 and 5.0 and enjoyed quite a lot the "Unit" system. But now came the realization that it was not possible for one to do cyclic references - e.g. "Unit A" refers to symbols from "B", and vice versa... Not that it's a good idea, but "C" linkage is okay with this, and you can split things much easier, thus probably ruining things in the long term... but sometimes it can help... "Uses BGI;" and I'm done :)
  - pjmlp 8y ago
    Ah, someone did not read the Turbo Pascal manual! :) Thankfully there is Bitsavers. "Circular Unit References" chapter on the Turbo Pascal 5.0 programmer's user guide. https://archive.org/details/bitsavers_borlandturVersion5.0UsersGuide1989_14284470/page/n93 https://archive.org/details/bitsavers_borlandturVersion5.0Us...
    - malkia 8y ago
      Ha, I must've forgot about it completely! Thank you! And yes, I've never read the manual (unlike the tons of "C" books that followed). Pascal was simply thought orally, and on your own (back then), and that was the case for quite a lot of apps....
- tjoff 8y ago
hazz99 8y ago
I quite like how Ada has "specification" files, which describes the methods (procedures, entries, functions), types and contracts for everything.

by tjoff 8y ago

int_19h 8y ago

Separation of module interface and module implementation is useful, but headers are a horrible way to do that. For an example of how it can be done right, look at Borland Pascal dialects (with "interface" and "implementation" section in each unit, where "interface" can be extracted if desired), or Ada, or ML.

tech_tuna 8y ago

>it really isn't any hassle to speak of to keep them up to date Dear lord, all those broken builds I've seen over the years would love to talk to you about that.

setpatchaddress 8y ago

That has not been my experience in 35 years of dealing with headers in C and C++ in large-scale software projects. Ruby, Swift, and even Python (or Pascal if we want to go way back) are significantly easier to deal with for anything sophisticated.

kazinator 8y ago

> An IDE should be able to automatically generate something like a header file regardless of language. https://www.hwaci.com/sw/mkhdr/ https://www.hwaci.com/sw/mkhdr/

pcwalton 8y ago

Header files absolutely are a hassle to keep up to date. Besides, they're a terrible experience. You have to pay attention to include order! You have to write forward declarations! You have to write include guards, in 2018! They're also bad as an overview. They may have been good in the 1980s, but nowadays a proper documentation generator gives you better formatting, search features, and cross-references. Inline documentation is particularly obnoxious in header files: I like seeing function-level documentation alongside interface and implementation, but if I put the documentation in both the .cpp and the .h file it's duplicated in two places and easily gets out of date.

westmeal 8y ago
Does #pragma once count as an include guard in your book?
- jchb 8y ago
  #pragma once is not in any C++ standard, although basically all modern compilers support it. The reason it is not in the standard is that its behaviour in the presence of symlinks may differ depending on the filesystem and compiler. Is it the unique combination of filename + content that should be included once or is it the file path? etc.
  - josefx 8y ago
    > The reason it is not in the standard is that its behaviour in the presence of symlinks may differ depending on the filesystem and compiler I have the feeling that the difference matters to almost nobody and should be avoidable by the few people it actually affects. I had more issues with colliding include guards than I had with symlinks and I still end up replacing CLASSNAME_H with PROJECT_CLASSNAME_H in our own headers every now and then since the autogenerated guards are too naive.
beached_whale 8y ago
The order of headers mattering is very rare though and not indicitive of normal C++ code. It's rare, but not unheard of unfortunately as most C code is also available to C++.
tjoff 8y ago
> You have to pay attention to include order! You have to write forward declarations! You have to write include guards, in 2018! Include order is a valid complaint, the others truly are non issues. I mean, we have other more pressing issues. Such as the fact that garbage collection is still a thing in 2018. > ...but nowadays a proper documentation generator gives you better... Examples of that? > I like seeing function-level documentation alongside interface and implementation, but if I put the documentation in both the .cpp and the .h file it's duplicated in two places and easily gets out of date. This is the only thing that I dislike about header files. And it is a constant reminder how bad IDEs are at handling this.

DenisM 8y ago

> no IDE or tool I've seen does this better. Modula-2 does it better. Each module split in two files - definition and implementation. Unlike C++ header files, def files are compiled rather that inlined, so they don't have a potential to produce different result for each source file that references them. The result is 100% reliable dependency graph across all source files, no need for a makefile, and blazingly fast compilation (each def file is only parsed and compiled once).

codesmythe 8y ago
OCaml also does it better. Its split between .ml (implementation) and .mli (definition) files is taken directly from Modula-2 [1]. [1] https://discuss.ocaml.org/t/what-is-the-reason-of-separation-of-module-implementation-and-signatures-in-ocaml/1735/33 https://discuss.ocaml.org/t/what-is-the-reason-of-separation...

tomcam 8y ago

> But still, no IDE or tool I've seen does this better. Why aren't Delphi, Oberon, and Modula-3 immensely better? Each file is an independent module except the one with main. Then the compiler quickly figures out in one pass what all the function signatures are. The minor drawback with this is that the one-pass method requires you to pay attention to declaration order, though a two-pass method renders that approach irrelevant. The IDE has all the symbolic goodness you need, and no goddamn header files. Also it's still easier than dealing with managing the dependency graph yourself as is necessary with C file include order. I say this as a guy who enjoys C and has done way more work in C than Delphi, but give credit where it's due.

malkia 8y ago
I started with Apple ][ Basic, but then moved to Turbo Pascal 3.0, 4.0 and 5.0 and enjoyed quite a lot the "Unit" system. But now came the realization that it was not possible for one to do cyclic references - e.g. "Unit A" refers to symbols from "B", and vice versa... Not that it's a good idea, but "C" linkage is okay with this, and you can split things much easier, thus probably ruining things in the long term... but sometimes it can help... "Uses BGI;" and I'm done :)
- pjmlp 8y ago
  Ah, someone did not read the Turbo Pascal manual! :) Thankfully there is Bitsavers. "Circular Unit References" chapter on the Turbo Pascal 5.0 programmer's user guide. https://archive.org/details/bitsavers_borlandturVersion5.0UsersGuide1989_14284470/page/n93 https://archive.org/details/bitsavers_borlandturVersion5.0Us...
  - malkia 8y ago
    Ha, I must've forgot about it completely! Thank you! And yes, I've never read the manual (unlike the tons of "C" books that followed). Pascal was simply thought orally, and on your own (back then), and that was the case for quite a lot of apps....
tjoff 8y ago

hazz99 8y ago

I quite like how Ada has "specification" files, which describes the methods (procedures, entries, functions), types and contracts for everything.