boost_mirror/utility
1
0
Fork 0
mirror of https://github.com/boostorg/utility.git synced 2025-05-08 18:34:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

Updated docs formatting.

Browse Source
This commit is contained in:
Andrey Semashev 2021-12-08 15:17:19 +03:00
parent 2b0441e95f
commit 485a160dde
11 changed files with 20 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/BOOST_BINARY.qbk
View File

@ -79,7 +79,3 @@ Contributed by Matt Calabrese.
[endsect]
[endsect]

7
doc/base_from_member.qbk
View File

@ -112,7 +112,7 @@ type does not need to concern itself with the integer.
#endif
template < typename MemberType, int UniqueID = 0 >
class __boost_base_from_member__
class __base_from_member__
{
protected:
MemberType member;
@ -322,8 +322,8 @@ type. Using `typedef`s ease mentioning the base types.
However, the fix introduces a new problem when a pointer is needed. Using the
address operator with a sub-object qualified with its class's name results in a
pointer-to-member (here, having a type of `an_int __boost_base_from_member__<an_int, 0>:: *`)
instead of a pointer to the member (having a type of `an_int *`).
pointer-to-member (here, having a type of `an_int __boost_base_from_member__<an_int, 0>::*`)
instead of a pointer to the member (having a type of `an_int*`).
The new problem is fixed by qualifying the sub-object with `this->` and is needed
just for pointers, and not for references or values.
@ -376,4 +376,3 @@ base_from_member_test.cpp].
[endsect]
[endsect]

7
doc/call_traits.qbk
View File

@ -159,7 +159,7 @@ various types.
[[From `int&`] [`int&`] [`int&`] [`const int&`] [`int&`] [All reference types]]
[[From `const int&`] [`const int&`] [`const int&`] [`const int&`] [`const int&`] [All constant reference types]]
[[From `int[3]`] [`const int*`] [`int(&)[3]`] [`const int(&)[3]`] [`const int* const`] [All array types]]
[[From `const int[3]`] [`const int*`] [`const int(&)[3]`] [`const int(&)[3]`] [`const int *const`] [All constant array types]]
[[From `const int[3]`] [`const int*`] [`const int(&)[3]`] [`const int(&)[3]`] [`const int* const`] [All constant array types]]
]
The table assumes the compiler supports partial
@ -441,8 +441,3 @@ specialisation.
[/===============]
[endsect]

8
doc/in_place_factory.qbk
View File

@ -18,7 +18,7 @@ Suppose we have a class
```
struct X
{
X ( int, _std__string_ ) ;
X ( int, __std_string__ ) ;
};
```
@ -70,7 +70,7 @@ struct C
{
C() : contained_(0) {}
C ( X const& v ) : contained_ ( new X(v) ) {}
C ( int a0, std::string a1 ) : contained_ ( new X(a0,a1) ) {}
C ( int a0, __std_string__ a1 ) : contained_ ( new X(a0,a1) ) {}
~C() { delete contained_ ; }
X* contained_ ;
};
@ -306,7 +306,3 @@ Copyright Fernando Luis Cacciola Carballal, 2004
[endsect]
[endsect]

12
doc/main.qbk
View File

@ -26,12 +26,16 @@
[category generic]
]
[template mdash[] '''&mdash; ''']
[template indexterm1[term1] '''<indexterm><primary>'''[term1]'''</primary></indexterm>''']
[template indexterm2[term1 term2] '''<indexterm><primary>'''[term1]'''</primary><secondary>'''[term2]'''</secondary></indexterm>''']
[template mdash[]'''&mdash;''']
[template ndash[]'''&ndash;''']
[template sect[]'''&sect;''']
[template hellip[]'''&hellip;''']
[template indexterm1[term1]'''<indexterm><primary>'''[term1]'''</primary></indexterm>''']
[template indexterm2[term1 term2]'''<indexterm><primary>'''[term1]'''</primary><secondary>'''[term2]'''</secondary></indexterm>''']
[template include_file[path][^<'''<ulink url="https://github.com/boostorg/utility/blob/master/include/'''[path]'''">'''[path]'''</ulink>'''>]]
[template issue[n] '''<ulink url="https://github.com/boostorg/utility/issues/'''[n]'''">#'''[n]'''</ulink>''']
[template issue[n]'''<ulink url="https://github.com/boostorg/utility/issues/'''[n]'''">#'''[n]'''</ulink>''']
[/ Named Requirements ]

10
doc/operators.qbk
View File

@ -1098,7 +1098,7 @@ function return value (which is another unnamed object of type
`T`). The standard doesn't generally allow the intermediate
object to be optimized away:
["3.7.2/2: Automatic storage duration: If a named automatic object has initialization or a destructor with
[:['3.7.2/2: Automatic storage duration:] If a named automatic object has initialization or a destructor with
side effects, it shall not be destroyed before the end of its block,
nor shall it be eliminated as an optimization even if it appears to be
unused, except that a class object or its copy may be eliminated as
@ -1106,14 +1106,14 @@ specified in 12.8.]
The reference to 12.8 is important for us:
["12.8/15: Copying class objects: (...) For a function with a class return type, if the expression in the
[:['12.8/15: Copying class objects:] ([hellip]) For a function with a class return type, if the expression in the
return statement is the name of a local object, and the cv-unqualified
type of the local object is the same as the function return type, an
implementation is permitted to omit creating the temporary object to
hold the function return value, even if the class copy constructor or
destructor has side effects.]
This optimization is known as the named return value optimization (NRVO),
This optimization is known as the named return value optimization ([@https://en.cppreference.com/w/cpp/language/copy_elision#Non-mandatory_elision_of_copy.2Fmove_.28since_C.2B.2B11.29_operations NRVO]),
which leads us to the following implementation for `operator+`:
```
@ -1936,7 +1936,7 @@ classes themselves have no state. For instance, the size of
above was 12-24 bytes on various compilers for the Win32 platform,
instead of the expected 8 bytes.
Strictly speaking, it was not the library's fault -- the language rules
Strictly speaking, it was not the library's fault [ndash] the language rules
allow the compiler to apply the empty base class optimization in that
situation. In principle an arbitrary number of empty base classes can be
allocated at the same offset, provided that none of them have a common
@ -1949,7 +1949,7 @@ that implementors will adopt it as a future enhancement to existing
compilers, because it would break binary compatibility between code
generated by two different versions of the same compiler. As Matt Austern
said, "One of the few times when you have the freedom to do this sort of
thing is when you are targeting a new architecture...". On the other hand,
thing is when you are targeting a new architecture[hellip]". On the other hand,
many common compilers will use the empty base optimization for single
inheritance hierarchies.

1
doc/other.qbk
View File

@ -27,4 +27,3 @@ Some utilities have been moved from Boost.Utilities to more appropriate Boost li
# [@boost:/doc/html/throw_exception/doc/html/throw_exception.html#using_boost_throw_exception throw_exception]
[endsect]

2
doc/result_of.qbk
View File

@ -419,5 +419,3 @@ Created by Doug Gregor. Contributions from Daniel Walker, Eric Niebler, Michel M
[endsect]
[endsect]

1
doc/string_view.qbk
View File

@ -207,4 +207,3 @@ Copyright 2012 Marshall Clow
[endsect]
[endsect]

3
doc/utilities.qbk
View File

@ -19,8 +19,6 @@ Please include the headers relative to individual components instead.
]
[include base_from_member.qbk]
[include BOOST_BINARY.qbk]
[include call_traits.qbk]
@ -32,4 +30,3 @@ Please include the headers relative to individual components instead.
[include value_init.qbk]
[endsect]

2
doc/value_init.qbk
View File

@ -116,7 +116,7 @@ A ['declaration] can contain an ['initializer], which specifies the
object's initial value. The initializer can be just '()', which states that
the object shall be value-initialized (but see below). However, if a ['declaration]
has no ['initializer] and it is of a non-`const`, non-`static` POD type, the
initial value is indeterminate: (see &sect;8.5, [dcl.init], for the
initial value is indeterminate: (see [sect]8.5, \[dcl.init\], for the
accurate definitions).
```