mirror of
https://github.com/boostorg/utility.git
synced 2025-05-08 18:34:02 +00:00
Updated docs formatting.
This commit is contained in:
parent
2b0441e95f
commit
485a160dde
@ -79,7 +79,3 @@ Contributed by Matt Calabrese.
|
|||||||
[endsect]
|
[endsect]
|
||||||
|
|
||||||
[endsect]
|
[endsect]
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
@ -112,7 +112,7 @@ type does not need to concern itself with the integer.
|
|||||||
#endif
|
#endif
|
||||||
|
|
||||||
template < typename MemberType, int UniqueID = 0 >
|
template < typename MemberType, int UniqueID = 0 >
|
||||||
class __boost_base_from_member__
|
class __base_from_member__
|
||||||
{
|
{
|
||||||
protected:
|
protected:
|
||||||
MemberType member;
|
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
|
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
|
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>:: *`)
|
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 *`).
|
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
|
The new problem is fixed by qualifying the sub-object with `this->` and is needed
|
||||||
just for pointers, and not for references or values.
|
just for pointers, and not for references or values.
|
||||||
|
|
||||||
@ -376,4 +376,3 @@ base_from_member_test.cpp].
|
|||||||
[endsect]
|
[endsect]
|
||||||
|
|
||||||
[endsect]
|
[endsect]
|
||||||
|
|
||||||
|
@ -159,7 +159,7 @@ various types.
|
|||||||
[[From `int&`] [`int&`] [`int&`] [`const int&`] [`int&`] [All reference 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 `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 `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
|
The table assumes the compiler supports partial
|
||||||
@ -441,8 +441,3 @@ specialisation.
|
|||||||
[/===============]
|
[/===============]
|
||||||
|
|
||||||
[endsect]
|
[endsect]
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
@ -18,7 +18,7 @@ Suppose we have a class
|
|||||||
```
|
```
|
||||||
struct X
|
struct X
|
||||||
{
|
{
|
||||||
X ( int, _std__string_ ) ;
|
X ( int, __std_string__ ) ;
|
||||||
};
|
};
|
||||||
```
|
```
|
||||||
|
|
||||||
@ -70,7 +70,7 @@ struct C
|
|||||||
{
|
{
|
||||||
C() : contained_(0) {}
|
C() : contained_(0) {}
|
||||||
C ( X const& v ) : contained_ ( new X(v) ) {}
|
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_ ; }
|
~C() { delete contained_ ; }
|
||||||
X* contained_ ;
|
X* contained_ ;
|
||||||
};
|
};
|
||||||
@ -306,7 +306,3 @@ Copyright Fernando Luis Cacciola Carballal, 2004
|
|||||||
|
|
||||||
[endsect]
|
[endsect]
|
||||||
[endsect]
|
[endsect]
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
12
doc/main.qbk
12
doc/main.qbk
@ -26,12 +26,16 @@
|
|||||||
[category generic]
|
[category generic]
|
||||||
]
|
]
|
||||||
|
|
||||||
[template mdash[] '''— ''']
|
[template mdash[]'''—''']
|
||||||
[template indexterm1[term1] '''<indexterm><primary>'''[term1]'''</primary></indexterm>''']
|
[template ndash[]'''–''']
|
||||||
[template indexterm2[term1 term2] '''<indexterm><primary>'''[term1]'''</primary><secondary>'''[term2]'''</secondary></indexterm>''']
|
[template sect[]'''§''']
|
||||||
|
[template 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 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 ]
|
[/ Named Requirements ]
|
||||||
|
|
||||||
|
@ -1098,7 +1098,7 @@ function return value (which is another unnamed object of type
|
|||||||
`T`). The standard doesn't generally allow the intermediate
|
`T`). The standard doesn't generally allow the intermediate
|
||||||
object to be optimized away:
|
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,
|
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
|
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
|
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:
|
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
|
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
|
type of the local object is the same as the function return type, an
|
||||||
implementation is permitted to omit creating the temporary object to
|
implementation is permitted to omit creating the temporary object to
|
||||||
hold the function return value, even if the class copy constructor or
|
hold the function return value, even if the class copy constructor or
|
||||||
destructor has side effects.]
|
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+`:
|
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,
|
above was 12-24 bytes on various compilers for the Win32 platform,
|
||||||
instead of the expected 8 bytes.
|
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
|
allow the compiler to apply the empty base class optimization in that
|
||||||
situation. In principle an arbitrary number of empty base classes can be
|
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
|
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
|
compilers, because it would break binary compatibility between code
|
||||||
generated by two different versions of the same compiler. As Matt Austern
|
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
|
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
|
many common compilers will use the empty base optimization for single
|
||||||
inheritance hierarchies.
|
inheritance hierarchies.
|
||||||
|
|
||||||
|
@ -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]
|
# [@boost:/doc/html/throw_exception/doc/html/throw_exception.html#using_boost_throw_exception throw_exception]
|
||||||
|
|
||||||
[endsect]
|
[endsect]
|
||||||
|
|
||||||
|
@ -419,5 +419,3 @@ Created by Doug Gregor. Contributions from Daniel Walker, Eric Niebler, Michel M
|
|||||||
[endsect]
|
[endsect]
|
||||||
|
|
||||||
[endsect]
|
[endsect]
|
||||||
|
|
||||||
|
|
||||||
|
@ -207,4 +207,3 @@ Copyright 2012 Marshall Clow
|
|||||||
[endsect]
|
[endsect]
|
||||||
|
|
||||||
[endsect]
|
[endsect]
|
||||||
|
|
||||||
|
@ -19,8 +19,6 @@ Please include the headers relative to individual components instead.
|
|||||||
|
|
||||||
]
|
]
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
[include base_from_member.qbk]
|
[include base_from_member.qbk]
|
||||||
[include BOOST_BINARY.qbk]
|
[include BOOST_BINARY.qbk]
|
||||||
[include call_traits.qbk]
|
[include call_traits.qbk]
|
||||||
@ -32,4 +30,3 @@ Please include the headers relative to individual components instead.
|
|||||||
[include value_init.qbk]
|
[include value_init.qbk]
|
||||||
|
|
||||||
[endsect]
|
[endsect]
|
||||||
|
|
||||||
|
@ -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
|
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]
|
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
|
has no ['initializer] and it is of a non-`const`, non-`static` POD type, the
|
||||||
initial value is indeterminate: (see §8.5, [dcl.init], for the
|
initial value is indeterminate: (see [sect]8.5, \[dcl.init\], for the
|
||||||
accurate definitions).
|
accurate definitions).
|
||||||
|
|
||||||
```
|
```
|
||||||
|
Loading…
x
Reference in New Issue
Block a user