6 ms·

Headers allow you to ship a binary without the full source code. If you want to build a linux kernel module you don't need all of the linux sources, just the he

Headers allow you to ship a binary without the full source code. If you want to build a linux kernel module you don't need all of the linux sources, just the headers.

fermienrico 8y ago
In principle you're right, but the notion that header file exposes just the "interface" is completely false. Class definition, private variables and functions, etc. are all exposed in header file. Header files are not a way to only expose the interface. You give up a lot more in C++. I've never had to deal with pesky header files until I started developing C and it immediately struct me as a royal pain in the ass. Even after couple of years of developing C/C++, I find the whole concept of header files archaic. Include preprocessor directive literally copy pastes stuff with no intelligence what-so-ever. The user is now burdened to ensure #includes are guarded to what I call a patchy half-baked hacked up solution - #IFDEF/#DEFINE/#ENDIF and #pragma in C++. It should be handled automatically by the compiler/preprocessor or IDE and I believe it is now being addressed in the C++17/20 spec with the advent of "modules". This thing should have been written up way back in 1989.
- jlarocco 8y ago
  > In principle you're right, but the notion that header file exposes just the "interface" is completely false. Sorry, but it is not "completely false". Doing it properly requires a carefully designed interface to hide internal data structures, and splitting out the end user headers from the internal headers, but it works. > I've never had to deal with pesky header files until I started developing C and it immediately struct me as a royal pain in the ass. It's like saying, "I've never had to deal with pesky .py files until I started developing Python."
  - fermienrico 8y ago
    How do you compare .py files with .h files? I am confused as to how you are drawing this analogy.
    - jlarocco 8y ago
      I mean header files are C and C++ source files, so saying you didn't have to deal with them until using C and C++ is a tautology. Likewise, you won't have to deal with .py files until you're using Python.
  - fnrslvr 8y ago
    > Doing it properly requires a carefully designed interface to hide internal data structures, and splitting out the end user headers from the internal headers, but it works. Out of curiosity, how? (If pointers or other mechanisms for memory indirection are allowed then it's pretty easy, so let's agree to ban those.) Not a rhetorical question, despite the parenthetical.
    - jlarocco 8y ago
      > Out of curiosity, how? (If pointers or other mechanisms for memory indirection are allowed then it's pretty easy, so let's agree to ban those.) Here's one popular way to do it in C++: https://en.cppreference.com/w/cpp/language/pimpl https://en.cppreference.com/w/cpp/language/pimpl I guess my tongue in cheek response to your parenthetical would be to ban the use of hidden internal data structures ;-)
    - creatornator 8y ago
      You can split "secret" data structures into another header, and them simply not give that secret header to the customer. If you give the binary and a header with some structures missing, the user can still use whatever you did give them.
    - cbuq 8y ago
      For global or namespace functions you can hide the implementation in the .cpp file. Doing the same with objects require pointers to hide the details of any private members. A common pattern is called Pointer to IMPLemenation (PIMPL). Not sure why we need to exclude pointers? In c++14 this is very much simplified with the use of unique pointers. std::unique_ptr<Foo> make_foo(...);
      - fnrslvr 8y ago
        Because I want full encapsulation without giving up by-value semantics. I want my clients to be able to take objects of some opaque record type that I've defined, and put them entirely on the stack, or in some contiguous block of memory entirely of their making, without ever getting to know the constituent fields of the record. I want it all, I want to have my cake and eat it too. When the parent (er, great grandparent?) says their parent is wrong to deny that headers only reveal the interface, I think it's a little disingenuous to base that on an unrevealed assumption that PImpl is in play. PImpl is basically the the idiom that begot Java. One reason I might opt for C++ over Java, is a desire for finer control over the location of memory -- but it's important for me to know that to actually get that, I'll probably have to sacrifice information hiding. It's a trade-off. Yes, on some level it's better to have the option to make that trade-off, but the product here is "encapsulation or value semantics", not "encapsulation and value semantics". Mind, I'm not a C++ developer. Maybe these days link-time heroic optimization makes the "right" decisions and collapses these kinds of indirections in all the sorts of situations you'd want it to. I write a lot more Java, and my understanding is that HotSpot gets up to a lot of heroics pertaining to this stuff these days -- I've noticed HotSpot will churn through a workload involving processing a collection of records far more quickly if you can arrange for it to stream through an array, even if you'd expect the records to be scattered randomly throughout memory.
- kccqzy 8y ago
  > In principle you're right, but the notion that header file exposes just the "interface" is completely false. Class definition, private variables and functions, etc. are all exposed in header file. If you don't want to expose class internals, just use the PIMPL idiom. It's an extra indirection to protect your own abstraction, so naturally C++ decides to opt for performance by default.
  - klodolph 8y ago
    That’s an annoying workaround at best. It’s not necessary in C. It wouldn’t be necessary in C++ if you could declare incomplete class types but still declare their member functions. This would have zero performance impact and improve encapsulation.
    - jcelerier 8y ago
      > It’s not necessary in C sorry what ? most C libraries I know hide their implementations behind opaque types such as `typedef void* my_handle_t`.
      - klodolph 8y ago
        Right, I'm saying that's not necessary, you can just do this: struct my_type; struct my_type *my_type_new(void); This is more common than `typedef void*` in my experience, because it actually provides some minimal amount of type safety. You can also do this in C++ of course, but you can't use member functions this way. My real complaint here is that the Pimpl idiom in C++ is more cumbersome than a simple forward declaration and free functions, which is available in C.
- de_watcher 8y ago
  > Include preprocessor directive literally copy pastes stuff with no intelligence what-so-ever. Well, it's easy to reason about them. The thinking goes about the translation units. The real problem is that the actual interface is not enforceable: the symbols in the binaries are just names.
bunderbunder 8y ago
> Headers allow you to ship a binary without the full source code. 100% agree. That said, that doesn't mean that they're the only way to do it, or even the best way.

Headers allow you to ship a binary without the full source code. If you want to build a linux kernel module you don't need all of the linux sources, just the headers.

fermienrico 8y ago

In principle you're right, but the notion that header file exposes just the "interface" is completely false. Class definition, private variables and functions, etc. are all exposed in header file. Header files are not a way to only expose the interface. You give up a lot more in C++. I've never had to deal with pesky header files until I started developing C and it immediately struct me as a royal pain in the ass. Even after couple of years of developing C/C++, I find the whole concept of header files archaic. Include preprocessor directive literally copy pastes stuff with no intelligence what-so-ever. The user is now burdened to ensure #includes are guarded to what I call a patchy half-baked hacked up solution - #IFDEF/#DEFINE/#ENDIF and #pragma in C++. It should be handled automatically by the compiler/preprocessor or IDE and I believe it is now being addressed in the C++17/20 spec with the advent of "modules". This thing should have been written up way back in 1989.

jlarocco 8y ago
> In principle you're right, but the notion that header file exposes just the "interface" is completely false. Sorry, but it is not "completely false". Doing it properly requires a carefully designed interface to hide internal data structures, and splitting out the end user headers from the internal headers, but it works. > I've never had to deal with pesky header files until I started developing C and it immediately struct me as a royal pain in the ass. It's like saying, "I've never had to deal with pesky .py files until I started developing Python."
- fermienrico 8y ago
  How do you compare .py files with .h files? I am confused as to how you are drawing this analogy.
  - jlarocco 8y ago
    I mean header files are C and C++ source files, so saying you didn't have to deal with them until using C and C++ is a tautology. Likewise, you won't have to deal with .py files until you're using Python.
- fnrslvr 8y ago
  > Doing it properly requires a carefully designed interface to hide internal data structures, and splitting out the end user headers from the internal headers, but it works. Out of curiosity, how? (If pointers or other mechanisms for memory indirection are allowed then it's pretty easy, so let's agree to ban those.) Not a rhetorical question, despite the parenthetical.
  - jlarocco 8y ago
    > Out of curiosity, how? (If pointers or other mechanisms for memory indirection are allowed then it's pretty easy, so let's agree to ban those.) Here's one popular way to do it in C++: https://en.cppreference.com/w/cpp/language/pimpl https://en.cppreference.com/w/cpp/language/pimpl I guess my tongue in cheek response to your parenthetical would be to ban the use of hidden internal data structures ;-)
  - creatornator 8y ago
    You can split "secret" data structures into another header, and them simply not give that secret header to the customer. If you give the binary and a header with some structures missing, the user can still use whatever you did give them.
  - cbuq 8y ago
    For global or namespace functions you can hide the implementation in the .cpp file. Doing the same with objects require pointers to hide the details of any private members. A common pattern is called Pointer to IMPLemenation (PIMPL). Not sure why we need to exclude pointers? In c++14 this is very much simplified with the use of unique pointers. std::unique_ptr<Foo> make_foo(...);
    - fnrslvr 8y ago
      Because I want full encapsulation without giving up by-value semantics. I want my clients to be able to take objects of some opaque record type that I've defined, and put them entirely on the stack, or in some contiguous block of memory entirely of their making, without ever getting to know the constituent fields of the record. I want it all, I want to have my cake and eat it too. When the parent (er, great grandparent?) says their parent is wrong to deny that headers only reveal the interface, I think it's a little disingenuous to base that on an unrevealed assumption that PImpl is in play. PImpl is basically the the idiom that begot Java. One reason I might opt for C++ over Java, is a desire for finer control over the location of memory -- but it's important for me to know that to actually get that, I'll probably have to sacrifice information hiding. It's a trade-off. Yes, on some level it's better to have the option to make that trade-off, but the product here is "encapsulation or value semantics", not "encapsulation and value semantics". Mind, I'm not a C++ developer. Maybe these days link-time heroic optimization makes the "right" decisions and collapses these kinds of indirections in all the sorts of situations you'd want it to. I write a lot more Java, and my understanding is that HotSpot gets up to a lot of heroics pertaining to this stuff these days -- I've noticed HotSpot will churn through a workload involving processing a collection of records far more quickly if you can arrange for it to stream through an array, even if you'd expect the records to be scattered randomly throughout memory.
kccqzy 8y ago
> In principle you're right, but the notion that header file exposes just the "interface" is completely false. Class definition, private variables and functions, etc. are all exposed in header file. If you don't want to expose class internals, just use the PIMPL idiom. It's an extra indirection to protect your own abstraction, so naturally C++ decides to opt for performance by default.
- klodolph 8y ago
  That’s an annoying workaround at best. It’s not necessary in C. It wouldn’t be necessary in C++ if you could declare incomplete class types but still declare their member functions. This would have zero performance impact and improve encapsulation.
  - jcelerier 8y ago
    > It’s not necessary in C sorry what ? most C libraries I know hide their implementations behind opaque types such as `typedef void* my_handle_t`.
    - klodolph 8y ago
      Right, I'm saying that's not necessary, you can just do this: struct my_type; struct my_type *my_type_new(void); This is more common than `typedef void*` in my experience, because it actually provides some minimal amount of type safety. You can also do this in C++ of course, but you can't use member functions this way. My real complaint here is that the Pimpl idiom in C++ is more cumbersome than a simple forward declaration and free functions, which is available in C.
de_watcher 8y ago
> Include preprocessor directive literally copy pastes stuff with no intelligence what-so-ever. Well, it's easy to reason about them. The thinking goes about the translation units. The real problem is that the actual interface is not enforceable: the symbols in the binaries are just names.

bunderbunder 8y ago

> Headers allow you to ship a binary without the full source code. 100% agree. That said, that doesn't mean that they're the only way to do it, or even the best way.