boostorg/iterator
1
0
Fork 1
mirror of https://github.com/boostorg/iterator.git synced 2025-07-19 23:52:12 +02:00
Code Issues Packages Projects Releases Wiki Activity

Apply typo fixes from Julio M. Merino Vidal

Browse Source 
[SVN r27513]
This commit is contained in:
Rene Rivera
2005-02-27 17:28:24 +00:00
parent 1d018cc602
commit ef895f0cc7
4 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/interoperability-revisited.rst
View File

@ -67,7 +67,7 @@ Mutable m;
c == m; // ok, dispatched to Constant::equal_to c == m; // ok, dispatched to Constant::equal_to
m == c; // !! error, dispatched to Mutable::equal_to m == c; // !! error, dispatched to Mutable::equal_to
Instead the following "slightly" more complicated implementation is neccessary Instead the following "slightly" more complicated implementation is necessary
struct Mutable : Facade<Mutable> struct Mutable : Facade<Mutable>
{ {
@ -87,7 +87,7 @@ struct Constant : Tag<Constant>
Beside the fact that the code is significantly more complex to understand and to teach there is Beside the fact that the code is significantly more complex to understand and to teach there is
a major design problem lurking here. Note that in both types equal_to is a function template with a major design problem lurking here. Note that in both types equal_to is a function template with
an unconstrained argument T. This is neccessary so that further types can be made interoperable with an unconstrained argument T. This is necessary so that further types can be made interoperable with
Mutable or Constant. Would Mutable be defined as Mutable or Constant. Would Mutable be defined as
struct Mutable : Facade<Mutable> struct Mutable : Facade<Mutable>
@ -229,4 +229,4 @@ Iterator implementations using iterator_facade look exactly as if they were
a) Less burden for the user a) Less burden for the user
b) The definition (standardese) of specialized adpters might be easier b) The definition (standardese) of specialized adpters might be easier
(This has to be proved yet) (This has to be proved yet)

2
doc/pointee.html
View File

@ -63,7 +63,7 @@ determine the appropriate <tt class="literal"><span class="pre">::type</span></t
<tt class="literal"><span class="pre">Dereferenceable</span></tt>s, but it makes very good guesses (it works <tt class="literal"><span class="pre">Dereferenceable</span></tt>s, but it makes very good guesses (it works
for all pointers, standard and boost smart pointers, and for all pointers, standard and boost smart pointers, and
iterators), and when it guesses wrongly, it can be specialized as iterators), and when it guesses wrongly, it can be specialized as
neccessary:</p> necessary:</p>
<pre class="literal-block"> <pre class="literal-block">
namespace boost namespace boost
{ {

2
doc/pointee.rst
View File

@ -42,7 +42,7 @@ determine the appropriate ``::type`` reliably for all
``Dereferenceable``\ s, but it makes very good guesses (it works ``Dereferenceable``\ s, but it makes very good guesses (it works
for all pointers, standard and boost smart pointers, and for all pointers, standard and boost smart pointers, and
iterators), and when it guesses wrongly, it can be specialized as iterators), and when it guesses wrongly, it can be specialized as
neccessary:: necessary::
namespace boost namespace boost
{ {

2
include/boost/iterator/detail/config_def.hpp
View File

@ -40,7 +40,7 @@
// end up using a proxy for operator[] when we otherwise shouldn't. // end up using a proxy for operator[] when we otherwise shouldn't.
// Using reference constness gives it an extra hint that it can // Using reference constness gives it an extra hint that it can
// return the value_type from operator[] directly, but is not // return the value_type from operator[] directly, but is not
// strictly neccessary. Not sure how best to resolve this one. // strictly necessary. Not sure how best to resolve this one.
# define BOOST_ITERATOR_REF_CONSTNESS_KILLS_WRITABILITY 1 # define BOOST_ITERATOR_REF_CONSTNESS_KILLS_WRITABILITY 1