4 ms·

Precompiled headers are a workaround when you can't modularize your project / headers files. But to use them you commit to the wrong way, including everything t

Precompiled headers are a workaround when you can't modularize your project / headers files. But to use them you commit to the wrong way, including everything the same way everywhere.... what you should do is include only minimal stuff from the headers, and prefer to include most dependencies only in implementation.

MaxBarraclough 6y ago
So things would be better if Boost.Signals2 weren't header-only? Makes sense.
quietbritishjim 6y ago
> Precompiled headers are a workaround when you can't modularize your project / headers files. This is technically true but misleading - the whole nature of C++ means that you can't modularize your project / headers in a way that avoids transitively including lots of headers. There's two reasons for this: * Lots of Boost (and other library) types are vocabulary types - that's often the whole point of using them in the first place. If my class has a public method that returns a boost::optional<T> or boost::flat_map<K, V> then there's no way to avoid transitively including the relevant Boost headers in my header files. * Lots of Boost stuff is templated so the implementation has to go in the header, which means the transitive dependencies on other parts of Boost have to be included in the header, even they're only used in the implementation of the Boost class that you're directly use. The heavy templating is a result of the previous point - vocabulary types often need to be templated in order to be useful in many different situations.
- pjmlp 6y ago
  Which is why many companies shy away from Boost and from libraries that do clever template meta-programming.
  - quietbritishjim 6y ago
    Indeed, but it's just ignorance driving that. You end up with three choices: * Use libraries like Boost and waste developer time waiting for compilation. * Avoid libraries like Boost and waste developer time re-implementing functionality (but then you have the same problem anyway) or suffering from not having that functionality available to them. * Use libraries like Boost and spend a small one-time developer cost turning on precompiled header files in your build system.
    - deleted 6y ago
      [deleted]
    - mmm_grayons 6y ago
      Boost is a pain to compile, sure, but a bit of a necessary evil for anything C++. Threadrippers are dirt cheap compared to developer time and compilation is embarrassingly parallel. Just by devs 32-core boxes and be done with it.
      - pjmlp 6y ago
        Except that on the projects I have been consulting, the last time I actually coded on a desktop was around 2006. And most customers nowadays just have IT throw a VM to externals. You're not getting Threadrippers from these kind of companies.
- Rexxar 6y ago
  You just have to use forward declaration headers in you headers. For your two examples : -> flat_map: https://www.boost.org/doc/libs/1_67_0/boost/container/container_fwd.hpp https://www.boost.org/doc/libs/1_67_0/boost/container/contai... -> optional: https://www.boost.org/doc/libs/1_67_0/boost/optional/optional_fwd.hpp https://www.boost.org/doc/libs/1_67_0/boost/optional/optiona...
  - quietbritishjim 6y ago
    That's true, but it creates an annoying extra burden on anyone that calls those functions to include the full-fat library header themselves. Since they might simply write `auto x = my_obj.returns_optional()`, it might not even be that obvious they need to add that header. Plus, of course, once they have added that header to their file, that header is included in their file, if you see what I mean, so it may not actually save compilation time while still adding coding effort. Really, I think that technique is only useful if you're only referring to those types (a) in private functions, and (b) by reference or pointer. By the time it's a public function, you have a responsibility to include the full library header in your header file.

MaxBarraclough 6y ago

So things would be better if Boost.Signals2 weren't header-only? Makes sense.

quietbritishjim 6y ago

> Precompiled headers are a workaround when you can't modularize your project / headers files. This is technically true but misleading - the whole nature of C++ means that you can't modularize your project / headers in a way that avoids transitively including lots of headers. There's two reasons for this: * Lots of Boost (and other library) types are vocabulary types - that's often the whole point of using them in the first place. If my class has a public method that returns a boost::optional<T> or boost::flat_map<K, V> then there's no way to avoid transitively including the relevant Boost headers in my header files. * Lots of Boost stuff is templated so the implementation has to go in the header, which means the transitive dependencies on other parts of Boost have to be included in the header, even they're only used in the implementation of the Boost class that you're directly use. The heavy templating is a result of the previous point - vocabulary types often need to be templated in order to be useful in many different situations.

pjmlp 6y ago
Which is why many companies shy away from Boost and from libraries that do clever template meta-programming.
- quietbritishjim 6y ago
  Indeed, but it's just ignorance driving that. You end up with three choices: * Use libraries like Boost and waste developer time waiting for compilation. * Avoid libraries like Boost and waste developer time re-implementing functionality (but then you have the same problem anyway) or suffering from not having that functionality available to them. * Use libraries like Boost and spend a small one-time developer cost turning on precompiled header files in your build system.
  - deleted 6y ago
    [deleted]
  - mmm_grayons 6y ago
    Boost is a pain to compile, sure, but a bit of a necessary evil for anything C++. Threadrippers are dirt cheap compared to developer time and compilation is embarrassingly parallel. Just by devs 32-core boxes and be done with it.
    - pjmlp 6y ago
      Except that on the projects I have been consulting, the last time I actually coded on a desktop was around 2006. And most customers nowadays just have IT throw a VM to externals. You're not getting Threadrippers from these kind of companies.
Rexxar 6y ago
You just have to use forward declaration headers in you headers. For your two examples : -> flat_map: https://www.boost.org/doc/libs/1_67_0/boost/container/container_fwd.hpp https://www.boost.org/doc/libs/1_67_0/boost/container/contai... -> optional: https://www.boost.org/doc/libs/1_67_0/boost/optional/optional_fwd.hpp https://www.boost.org/doc/libs/1_67_0/boost/optional/optiona...
- quietbritishjim 6y ago
  That's true, but it creates an annoying extra burden on anyone that calls those functions to include the full-fat library header themselves. Since they might simply write `auto x = my_obj.returns_optional()`, it might not even be that obvious they need to add that header. Plus, of course, once they have added that header to their file, that header is included in their file, if you see what I mean, so it may not actually save compilation time while still adding coding effort. Really, I think that technique is only useful if you're only referring to those types (a) in private functions, and (b) by reference or pointer. By the time it's a public function, you have a responsibility to include the full library header in your header file.