v3 flag enabled
Log In
Log In

Post for Waigtal

Headers

Header files are the place where a library comes into contact with user code and other libraries. To co-exist peacefully and productively, headers must be "good neighbors".

Boost Standards

Here are the standards for boost headers. Many of these are also reasonable guidelines for general use.

  • Header filenames should have a .hpp (lowercase) extension.

  • Unless multiple inclusion is intended, wrap the header in #ifndef guards. Use a naming convention that minimizes the chance of clashes with macro names from other’s code. The https://www.boost.org/doc/contributor-guide/design-guide/headers.html#sample">Sample uses the Boost convention of all uppercase letters, with the header name prefixed by the namespace name, followed by the relative path, and suffixed with HPP, separated by underscores. Refer also to the https://www.boost.org/doc/contributor-guide/design-guide/headers.html#example-guards">Example Guards.

  • Wrap the header contents in a namespace to prevent global namespace pollution. The namespace approach to pollution control is strongly preferred to older approaches such as adding funny prefixes to global names. Libraries which are designed to work well with other Boost libraries should be placed in namespace boost.

  • Make sure that a translation unit, consisting of just the contents of the header file, will compile successfully.

  • Place the header file in a sub-directory to prevent conflict with identically named header files in other libraries. The parent directory is added to the compiler’s include search path. Then both your code and user code specifies the sub-directory in #include directives. Thus the header https://www.boost.org/doc/contributor-guide/design-guide/headers.html#sample">Sample would be included by #include <boost/furball.hpp>. Including from the current file directory using #include "furball.hpp" syntax is discouraged.

  • The preferred ordering for class definitions is public members, protected members, and finally private members.

  • Include the boost/config.hpp if there is a need to deal with compiler or platform configuration issues.

Sample

//  Boost general library furball.hpp header file ---------------------------//

//  (C) Copyright <Your Name> 2023. Permission to copy, use, modify, sell and
//  distribute this software is granted provided this copyright notice appears
//  in all copies. This software is provided "as is" without express or implied
//  warranty, and with no claim as to its suitability for any purpose.

//  See https://www.boost.org/ for latest version.

#ifndef BOOST_FURBALL_HPP
#define BOOST_FURBALL_HPP

namespace boost {

//  Furball class declaration  -----------------------------------------------//

  class furball
  {
    public:
      void throw_up();
    protected:
      double duration();
    private:
      int whatever;
  };  // furball

} // namespace

#endif  // include guard

Example Guards

Many libraries will include a large number of .hpp header files in a tree structure of folders. Taking https://www.boost.org/libs/beast">Boost.Beast as an example. The header guard code is:

#ifndef BOOST_BEAST_HPP
#define BOOST_BEAST_HPP

The subfolder beast includes several more headers, including Core.hpp, which has the header guard:

#ifndef BOOST_BEAST_CORE_HPP
#define BOOST_BEAST_CORE_HPP

In the beast\core subfolder there is the async_base.hpp header file. Its' guard is:

#ifndef BOOST_BEAST_CORE_ASYNC_BASE_HPP
#define BOOST_BEAST_CORE_ASYNC_BASE_HPP

And in the beast\core\impl subfolder there is another header named async_base.hpp, this time with the guard:

#ifndef BOOST_BEAST_CORE_IMPL_ASYNC_BASE_HPP
#define BOOST_BEAST_CORE_IMPL_ASYNC_BASE_HPP

Refer to https://github.com/boostorg/beast/tree/c316c6bd3571991aeac65f0fc35fca9067bc7906/include/boost">beast/include/boost to view the full hierarchy of folders and headers for this library.

Coding Style

The alert reader will have noticed that the https://www.boost.org/doc/contributor-guide/design-guide/headers.html#sample">Sample header employs a certain coding style for indentation, positioning braces, commenting ending braces, and similar formatting issues. These stylistic issues are viewed as personal preferences and are not part of the Boost Header Policy.

Next Post

  • Design Best Practices
    #Algorithm
    Guidelines are presented as recommendations drawn from prior experience with Boost library submissions. Emphasis is placed on clarity and correctness before optimization, while adherence to ISO Standard C++ and use of the Standard Library are encouraged. Source files are required to begin with descriptive comments, licensing information, and a reference to the library’s Boost webpage, and to follow conservative formatting such as fixed‑width fonts, spaces instead of tabs, and an 80‑character line limit. Naming conventions mirror those of the C++ Standard Library, using lowercase words separated by underscores, uppercase macro prefixes, and descriptive identifiers. Consistency is advocated through matching library names, directory structures, header locations, and namespaces, with singular nouns preferred and the library name capitalized within the Boost namespace.
  • Algorithm
    #Algorithm
    An algorithm is defined as a finite sequence of mathematically rigorous logical instructions used to solve a class of specific problems or to perform a computation. It is employed as a specification for calculations and data processing. Conditionals may be incorporated to divert execution along various routes, enabling automated decision‑making and automated reasoning. In contrast, a heuristic is described as an approach that solves problems without well‑defined correct or optimal results. Heuristics are often applied in contexts such as social‑media recommender systems, where no truly correct recommendation exists. The distinction between algorithms and heuristics is therefore highlighted by the presence or absence of guaranteed optimal outcomes. Both concepts are considered fundamental to mathematics and computer science.