boost/website-v2-docs
2
0
Fork 0
mirror of https://github.com/boostorg/website-v2-docs.git synced 2026-01-19 04:42:17 +00:00
Code Issues Projects Releases Wiki Activity

Broken internal links fixed (#242)

Browse Source
This commit is contained in:
Peter Turcan
2024-06-06 03:04:58 -07:00
committed by GitHub
parent d49cff5b15
commit fe57779d96
3 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
contributor-guide/modules/ROOT/pages/design-guide/headers.adoc
View File

@@ -20,13 +20,13 @@ Here are the standards for boost headers. Many of these are also reasonable guid
[disc]
* 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 <<Sample Header>> 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 <<Example Header Guards>>.
* 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 <<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 <<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 <<Sample Header>> would be included by `#include <boost/furball.hpp>`. Including from the current file directory using `#include "furball.hpp"` syntax is discouraged.
* 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 <<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.
@@ -106,7 +106,7 @@ Refer to https://github.com/boostorg/beast/tree/c316c6bd3571991aeac65f0fc35fca90
=== Coding Style
The alert reader will have noticed that the <<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.
The alert reader will have noticed that the <<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.

2
contributor-guide/modules/ROOT/pages/docs/documentation-components.adoc
View File

@@ -44,7 +44,7 @@ applicable. link:#footnote1[(1)]:
[disc]
* <<Summary>>
* <<Requirements>>
* <<Detailed specifications>>
* <<Detailed Specifications>>
* <<References to the C++ Standard Library>>
* <<References to the C Standard Library>>

2
contributor-guide/modules/ROOT/pages/release-notes.adoc
View File

@@ -13,7 +13,7 @@ Writing release notes is crucial for informing users about the changes made in t
Two versions of your release notes need to be prepared: one for your library's own documentation, one for a Boost history that covers all libraries added or updated in a release.
For the former, the Boost community does not have a strict format for your libraries' version of release notes (and some libraries refer to release notes as a _change log_ or _history_). Follow the <<_release_note_checklist>>.
For the former, the Boost community does not have a strict format for your libraries' version of release notes (and some libraries refer to release notes as a _change log_ or _history_). Follow the <<Checklist>>.
For the latter, you will need to update a Boost history file with a succinct version of your completed release notes. These files do have a specified format, described in <<_update_boost_history>>.