From 572712fac8ab4e3aa5db694c9279eecb46dc61b8 Mon Sep 17 00:00:00 2001 From: Steven Watanabe Date: Thu, 7 Apr 2011 00:38:05 +0000 Subject: [PATCH] Fix annoying markup problems. [SVN r71065] --- factory/doc/factory.qbk | 24 +++++++++-------- factory/doc/html/index.html | 53 ++++++++++++++++++++++++------------- 2 files changed, 47 insertions(+), 30 deletions(-) diff --git a/factory/doc/factory.qbk b/factory/doc/factory.qbk index cac614b..2f92f69 100644 --- a/factory/doc/factory.qbk +++ b/factory/doc/factory.qbk @@ -23,15 +23,17 @@ [def __boost_function__ [@http://www.boost.org/doc/html/function.html Boost.Function]] [def __boost__function__ [@http://www.boost.org/doc/html/function.html `boost::function`]] +[def __smart_pointer__ [@http://www.boost.org/libs/smart_ptr/index.html Smart Pointer]] [def __smart_pointers__ [@http://www.boost.org/libs/smart_ptr/index.html Smart Pointers]] [def __boost__shared_ptr__ [@http://www.boost.org/libs/smart_ptr/shared_ptr.htm `boost::shared_ptr`]] [def __std__map__ [@http://www.sgi.com/tech/stl/map.html `std::map`]] [def __std__string__ [@http://www.sgi.com/tech/stl/string.html `std::string`]] +[def __allocator__ [@http://www.sgi.com/tech/stl/concepts/allocator.html Allocator]] [def __std_allocator__ [@http://www.sgi.com/tech/stl/concepts/allocator.html Allocator]] [def __std_allocators__ [@http://www.sgi.com/tech/stl/concepts/allocator.html Allocators]] -[def __boost__ptr_map__ [@http://www.boost.org/libs/ptr_container/doc/ptr_map.html `__boost__ptr_map__`]] +[def __boost__ptr_map__ [@http://www.boost.org/libs/ptr_container/doc/ptr_map.html `boost::ptr_map`]] [def __boost__factory__ `boost::factory`] [def __boost__value_factory__ `boost::value_factory`] @@ -117,16 +119,16 @@ lots of boilerplate code. In other words there is too much code to express a rather simple intention. We could use templates to get rid of some of it but the approach remains inflexible: - o We may want a factory that takes some arguments that are forwarded to - the constructor, - o we will probably want to use smart pointers, - o we may want several member functions to create different kinds of - objects, - o we might not necessarily need a polymorphic base class for the objects, - o as we will see, we do not need a factory base class at all, - o we might want to just call the constructor - without `new` to create - an object on the stack, and - o finally we might want to use customized memory management. +* We may want a factory that takes some arguments that are forwarded to + the constructor, +* we will probably want to use smart pointers, +* we may want several member functions to create different kinds of + objects, +* we might not necessarily need a polymorphic base class for the objects, +* as we will see, we do not need a factory base class at all, +* we might want to just call the constructor - without `new` to create + an object on the stack, and +* finally we might want to use customized memory management. Experience has shown that using function objects and generic Boost components for their composition, Design Patterns that describe callback mechasisms diff --git a/factory/doc/html/index.html b/factory/doc/html/index.html index 2f14b71..9b9542a 100644 --- a/factory/doc/html/index.html +++ b/factory/doc/html/index.html @@ -26,7 +26,7 @@

Copyright © 2007, 2008 Tobias Schwinger

-

+

Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)

@@ -103,7 +103,7 @@ int main() { - __boost__ptr_map__<std::string,a_factory> factories; + boost::ptr_map<std::string,a_factory> factories; // [...] @@ -125,17 +125,31 @@ a rather simple intention. We could use templates to get rid of some of it but the approach remains inflexible:

-
o We may want a factory that takes some arguments that are forwarded to
-  the constructor,
-o we will probably want to use smart pointers,
-o we may want several member functions to create different kinds of
-  objects,
-o we might not necessarily need a polymorphic base class for the objects,
-o as we will see, we do not need a factory base class at all, 
-o we might want to just call the constructor - without `new` to create
-  an object on the stack, and
-o finally we might want to use customized memory management.
-
+
    +
  • + We may want a factory that takes some arguments that are forwarded to the + constructor, +
    • +
  • + we will probably want to use smart pointers, +
    • +
  • + we may want several member functions to create different kinds of objects, +
    • +
  • + we might not necessarily need a polymorphic base class for the objects, +
    • +
  • + as we will see, we do not need a factory base class at all, +
    • +
  • + we might want to just call the constructor - without new + to create an object on the stack, and +
    • +
  • + finally we might want to use customized memory management. +
    • +

Experience has shown that using function objects and generic Boost components for their composition, Design Patterns that describe callback mechasisms (typically @@ -401,12 +415,13 @@ yields the pointee type.

- If an _allocator_ is given, it is used - for memory allocation and the placement form of the new - operator is used to construct the object. A function object that calls the - destructor and deallocates the memory with a copy of the Allocator is used - for the second constructor argument of Pointer - (thus it must be a _smart_pointer_ + If an Allocator + is given, it is used for memory allocation and the placement form of the + new operator is used to construct + the object. A function object that calls the destructor and deallocates the + memory with a copy of the Allocator is used for the second constructor argument + of Pointer (thus it must + be a Smart Pointer that provides a suitable constructor, such as boost::shared_ptr).