|
|
Boost-Commit : |
Subject: [Boost-commit] svn:boost r60042 - in sandbox/tokenmap/libs/tokenmap/doc: . html html/tokenmap
From: sl_at_[hidden]
Date: 2010-03-01 12:19:49
Author: sl_
Date: 2010-03-01 12:19:48 EST (Mon, 01 Mar 2010)
New Revision: 60042
URL: http://svn.boost.org/trac/boost/changeset/60042
Log:
fixed few typos
Text files modified:
sandbox/tokenmap/libs/tokenmap/doc/html/index.html | 4 ++--
sandbox/tokenmap/libs/tokenmap/doc/html/tokenmap/examples_.html | 2 +-
sandbox/tokenmap/libs/tokenmap/doc/html/tokenmap/rationale_.html | 16 ++++++++--------
sandbox/tokenmap/libs/tokenmap/doc/html/tokenmap/reference.html | 10 +++++-----
sandbox/tokenmap/libs/tokenmap/doc/tokenmap.qbk | 11 ++++++-----
5 files changed, 22 insertions(+), 21 deletions(-)
Modified: sandbox/tokenmap/libs/tokenmap/doc/html/index.html
==============================================================================
--- sandbox/tokenmap/libs/tokenmap/doc/html/index.html (original)
+++ sandbox/tokenmap/libs/tokenmap/doc/html/index.html 2010-03-01 12:19:48 EST (Mon, 01 Mar 2010)
@@ -27,7 +27,7 @@
</h3></div></div>
<div><p class="copyright">Copyright © 2009 Slawomir Lisznianski</p></div>
<div><div class="legalnotice">
-<a name="id428334"></a><p>
+<a name="id579434"></a><p>
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)
</p>
@@ -66,7 +66,7 @@
</div>
</div>
<table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr>
-<td align="left"><p><small>Last revised: February 23, 2010 at 00:32:22 GMT</small></p></td>
+<td align="left"><p><small>Last revised: March 01, 2010 at 17:19:09 GMT</small></p></td>
<td align="right"><div class="copyright-footer"></div></td>
</tr></table>
<hr>
Modified: sandbox/tokenmap/libs/tokenmap/doc/html/tokenmap/examples_.html
==============================================================================
--- sandbox/tokenmap/libs/tokenmap/doc/html/tokenmap/examples_.html (original)
+++ sandbox/tokenmap/libs/tokenmap/doc/html/tokenmap/examples_.html 2010-03-01 12:19:48 EST (Mon, 01 Mar 2010)
@@ -32,7 +32,7 @@
them:
</p>
<div class="table">
-<a name="id438587"></a><p class="title"><b>Table 1.1. Tutorial examples</b></p>
+<a name="id589687"></a><p class="title"><b>Table 1.1. Tutorial examples</b></p>
<div class="table-contents"><table class="table" summary="Tutorial examples">
<colgroup>
<col>
Modified: sandbox/tokenmap/libs/tokenmap/doc/html/tokenmap/rationale_.html
==============================================================================
--- sandbox/tokenmap/libs/tokenmap/doc/html/tokenmap/rationale_.html (original)
+++ sandbox/tokenmap/libs/tokenmap/doc/html/tokenmap/rationale_.html 2010-03-01 12:19:48 EST (Mon, 01 Mar 2010)
@@ -37,16 +37,16 @@
</p>
<p>
Another example is that of an API of a library. Consider a shared library which
- internally manages resources on behave of its users. As an API author, you
- may wish not to share certain implementation details, such as pointers or iterators,
- with users yet you would like to efficiently dispatch API calls. When you use
- <code class="computeroutput"><span class="identifier">tokenmap</span></code>-generated keys, you
- are not sharing any such implementation details, ensuring users cannot corrupt
- your internally managed state.
+ internally manages resources on behalf of its users. As an API author, you
+ probably don't want to expose certain implementation details, such as pointers
+ or iterators with your callers, yet you would like to efficiently handle their
+ calls. When you use <code class="computeroutput"><span class="identifier">tokenmap</span></code>-generated
+ keys, you are not sharing any implementation details, so it's harder for the
+ users of the library to corrupt the internally managed state.
</p>
<p>
- Additionally, since we're not dereferencing tokens, unlike pointers, it is
- perfectly OK for them to outlive the mapped-to-objects without the usual consequences
+ Additionally, unlike pointers, we're not dereferencing tokens, so it is perfectly
+ OK for them to outlive the mapped-to-objects without the usual consequences
of accessing stale pointers.
</p>
</div>
Modified: sandbox/tokenmap/libs/tokenmap/doc/html/tokenmap/reference.html
==============================================================================
--- sandbox/tokenmap/libs/tokenmap/doc/html/tokenmap/reference.html (original)
+++ sandbox/tokenmap/libs/tokenmap/doc/html/tokenmap/reference.html 2010-03-01 12:19:48 EST (Mon, 01 Mar 2010)
@@ -27,7 +27,7 @@
<a name="tokenmap.reference"></a><a class="link" href="reference.html" title="Reference">Reference</a>
</h2></div></div></div>
<a name="tokenmap.reference.headers"></a><h4>
-<a name="id437582"></a>
+<a name="id588682"></a>
<a class="link" href="reference.html#tokenmap.reference.headers">Headers</a>
</h4>
<p>
@@ -36,7 +36,7 @@
to boost namespace.
</p>
<a name="tokenmap.reference.synopsis"></a><h4>
-<a name="id437609"></a>
+<a name="id588709"></a>
<a class="link" href="reference.html#tokenmap.reference.synopsis">Synopsis</a>
</h4>
<pre class="programlisting"><span class="keyword">namespace</span> <span class="identifier">boost</span> <span class="special">{</span>
@@ -83,15 +83,15 @@
</span><span class="special">}</span> <span class="comment">// namespace boost
</span></pre>
<a name="tokenmap.reference.class_template_tokenmap"></a><h4>
-<a name="id438196"></a>
+<a name="id589296"></a>
<a class="link" href="reference.html#tokenmap.reference.class_template_tokenmap">Class template tokenmap</a>
</h4>
<a name="tokenmap.reference.nested_types"></a><h4>
-<a name="id438211"></a>
+<a name="id589311"></a>
<a class="link" href="reference.html#tokenmap.reference.nested_types">Nested types</a>
</h4>
<a name="tokenmap.reference.constructors__copy_and_assignment"></a><h4>
-<a name="id438226"></a>
+<a name="id589326"></a>
<a class="link" href="reference.html#tokenmap.reference.constructors__copy_and_assignment">Constructors,
copy and assignment</a>
</h4>
Modified: sandbox/tokenmap/libs/tokenmap/doc/tokenmap.qbk
==============================================================================
--- sandbox/tokenmap/libs/tokenmap/doc/tokenmap.qbk (original)
+++ sandbox/tokenmap/libs/tokenmap/doc/tokenmap.qbk 2010-03-01 12:19:48 EST (Mon, 01 Mar 2010)
@@ -256,12 +256,13 @@
performance and requires users to come up with sufficiently hard to guess random keys.
Another example is that of an API of a library. Consider a shared library which internally manages
-resources on behave of its users. As an API author, you may wish not to share certain
-implementation details, such as pointers or iterators, with users yet you would
-like to efficiently dispatch API calls. When you use `tokenmap`-generated keys, you are not sharing
-any such implementation details, ensuring users cannot corrupt your internally managed state.
+resources on behalf of its users. As an API author, you probably don't want to expose certain
+implementation details, such as pointers or iterators with your callers, yet you would
+like to efficiently handle their calls. When you use `tokenmap`-generated keys, you are not sharing
+any implementation details, so it's harder for the users of the library to corrupt the internally
+managed state.
-Additionally, since we're not dereferencing tokens, unlike pointers, it is perfectly OK for them
+Additionally, unlike pointers, we're not dereferencing tokens, so it is perfectly OK for them
to outlive the mapped-to-objects without the usual consequences of accessing stale pointers.
[endsect]
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk