2

I'm interested in the motivation - what was the motivation in C/C++ to have the interface separated from the imlpementation by header files and why didn't the authors of other languages borrow the concept and use it in other(newer) languages? Does it mean that this concept is bad?

EDIT: I'm NOT asking why c/c++ use header files - I'm asking WHY didn't this concept remain in newer languages like Java etc.

Novellizator
  • 13,633
  • 9
  • 43
  • 65
  • 1
    So how do you propose that C, back in the 70's and 80's when the language was being deisgned, "borrowed concepts from newer languages"? ;) – jalf Jun 23 '13 at 09:06
  • C# and Java use the compiled code to achieve the same thing as the headers do in C/C++. They just do it without duplicating a bunch of definitions into a separate file. – Anya Shenanigans Jun 23 '13 at 09:09
  • 1
    @Petesh yeah, and WHY don't they duplicate? – Novellizator Jun 23 '13 at 09:10
  • @Novellizator To quote [ongle's answer](http://stackoverflow.com/a/1306019/952648), which itself quotes [Wikipedia](http://en.wikipedia.org/wiki/Header_file): "Newer compiled languages (such as Java, C#) do not use forward declarations; identifiers are recognized automatically from source files and read directly from dynamic library symbols. This means header files are not needed." – tom Jun 23 '13 at 09:13
  • 1
    @Novellizator because they don't have to, and the designers of these languages had a lot of experience with C/C++ and knew that *another copy* of the interface is just a bad idea if you already have one. – Anya Shenanigans Jun 23 '13 at 09:15
  • 2
    @Novellizator *why* would a language choose to use header files? What would they gain by doing so? – jalf Jun 23 '13 at 09:21

2 Answers2

10

When the C language was designed computers had very few resources, and it was important to keep the processing time and memory usage to a minimum. A design that would enable a compiler to read the source file and compile it "on the fly", in a single pass, with minimal resource usage, was preferred to designs that made the compiler either do multiple passes over the source code or construct a large data structure in memory before emitting compiled code. Header files enable compiling in a single pass: they give you a way to declare and use a symbol while its definition may come later in the source code, or it may even be in a different file or external library.

The design for newer languages such as C# and Java considered programmer convenience more important than optimizing the compiler's resource usage. Also many modern C compilers already use multiple passes because it's impossible to apply many code optimizations in a single pass; using a single-pass design for new languages has little benefit nowadays.

Header files also have other benefits: they allow you to separate interface from implementation, so that the header file serves as an API documentation without exposing implementation details.

Joni
  • 108,737
  • 14
  • 143
  • 193
  • Interesting that you say C is a one pass language. Many C definitions required 2 passes. Pascal (and Ada since it is an offspring) can be read in a single pass (although Ada 95 has one exception.) – Alexis Wilke Jun 23 '13 at 09:35
  • Don't the parts that require two compiler passes in C have a limited scope? – Joni Jun 23 '13 at 13:14
  • 1
    There are differences between C and C++, but in C you can, for example, define a function without a return type. `int` is used as the default. You may get a warning in C, but it is legal (C++ assumes such but generates an error.) If you look at the parser, to achieve just that one feat, it has to do extraordinary things which I think are very complicated and that happens for each function. Also, when you reach the end of a syntactical structure (often a } or ;) you need to determine what was just defined because it is likely necessary as soon as you parse the next entry. – Alexis Wilke Jun 27 '13 at 02:31
  • Now... in C++ you declare functions in a class in the order you want. That makes it even more complicated and most certainly forces you to read the class, but not really the blocks (anything between { and } in the class is just "stored") once the whole class is read, then you start working on the blocks, including sub-classes, sub-structures, etc. Otherwise you have no clue what to do with the identifiers you find in the functions. – Alexis Wilke Jun 27 '13 at 02:31
-1

I'm not sure this is an appropriate question for Stackoverflow, but:

When I am writing a class, I appreciate the clarity of haveing a separate .h and .cpp file. This benefits me in several ways:

1: When others have to use my class, they only need to read the .h file - there is no code internal to the class's methods to confuse them - this function is called like so, here's the commenting that explains what it does, you don't need to know the rest.

2: When I have to review my code, having separate .h and .cpp allows me to compare/contrast. If I have a half-baked method in .cpp that I ended up not needing, there will be a mismatch between the two files. As such, I can use the clearer .h file which is easier to review to see whether I've managed to do something wrong in the .cpp file.

shieldfoss
  • 886
  • 2
  • 12
  • 22
  • 3
    You are wrong. The .h file contains *every private member variable the class contains*. It shows you *all* the private member functions by name and signature, even if their body isn't there. It does not separate the interface from the implementation. Having a mechanism for separating the interface from the implementation is nice, and sometimes, on a good day, the .h/.cpp separation can *kind* of look like it achieves that. But it doesn't really, not cleanly. Other languages do, but C++ does not. So face it, it is not something to "appreciate", and it does not benefit you. – jalf Jun 23 '13 at 09:08
  • 3
    It is a clunky hack that originated in the 70's when C was being designed, because back then, computers were too slow and had too little memory for processing anything more complicated at compile-time. If these languages had been designed today, they would have had *proper* separation of the interface from the implementation. But they don't. – jalf Jun 23 '13 at 09:10
  • Did I say the .h file didn't contain every private member variable? EDIT: Wait, I can see what I wrote that might make you think so. I will edit my answer to be more precise. – shieldfoss Jun 23 '13 at 09:12
  • 2
    you said that there is no code "internal to the class" to confuse readers of the .h file. And that is how it *should* be, and that is how it is in a modern, well-designed language. But C++ is not there, and it's dishonest to pretend it is. For now, we're stuck with the .h/.cpp separation, so hey, let's make the best of it. But let us not for a moment pretend that it lets us separate implementation and interface, or anything like that. It contains not just all the private members of the class, but also all inline and template functions - of which modern C++ code has a lot. – jalf Jun 23 '13 at 09:16
  • On the second part, you're also wrong, because if there is a mismatch, it is only rarely *detected* by the compiler. You can declare functions in the header without defining them in the .cpp file, and that's just fine with the compiler. Or you can define a function in .cpp without having a declaration in .h, and the compiler has no problem with that either. It doesn't enforce consistency between the two files, so it makes your reviewing job *harder*, not easier. – jalf Jun 23 '13 at 09:20
  • Yup, you're right - I had a misstatement in my first writeup. It has now been edited. EDIT On the second part: The compiler doesn't detect the mismatch, *I* do. I work on very small embedded systems. My answer may not be generalizable to everybody else. – shieldfoss Jun 23 '13 at 09:25