From fe57779d96595d03ec7043359c847dd0faa26c8a Mon Sep 17 00:00:00 2001 From: Peter Turcan Date: Thu, 6 Jun 2024 03:04:58 -0700 Subject: [PATCH] Broken internal links fixed (#242) --- .../modules/ROOT/pages/design-guide/headers.adoc | 6 +++--- .../modules/ROOT/pages/docs/documentation-components.adoc | 2 +- contributor-guide/modules/ROOT/pages/release-notes.adoc | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/contributor-guide/modules/ROOT/pages/design-guide/headers.adoc b/contributor-guide/modules/ROOT/pages/design-guide/headers.adoc index a452346..305b62a 100644 --- a/contributor-guide/modules/ROOT/pages/design-guide/headers.adoc +++ b/contributor-guide/modules/ROOT/pages/design-guide/headers.adoc @@ -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 <> 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 <>. +* 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 <> 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 <>. * 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 <> would be included by `#include `. 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 <> would be included by `#include `. 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 <> 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 <> 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. diff --git a/contributor-guide/modules/ROOT/pages/docs/documentation-components.adoc b/contributor-guide/modules/ROOT/pages/docs/documentation-components.adoc index 022bca7..0becadb 100644 --- a/contributor-guide/modules/ROOT/pages/docs/documentation-components.adoc +++ b/contributor-guide/modules/ROOT/pages/docs/documentation-components.adoc @@ -44,7 +44,7 @@ applicable. link:#footnote1[(1)]: [disc] * <> * <> -* <> +* <> * <> * <> diff --git a/contributor-guide/modules/ROOT/pages/release-notes.adoc b/contributor-guide/modules/ROOT/pages/release-notes.adoc index c8e6a86..801c92f 100644 --- a/contributor-guide/modules/ROOT/pages/release-notes.adoc +++ b/contributor-guide/modules/ROOT/pages/release-notes.adoc @@ -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 <>. 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>>.