Files
boost_range/test/TODO
Thorsten Jørgen Ottosen ee8211dc0f *** empty log message ***
[SVN r23241]
2004-06-29 02:58:13 +00:00

87 lines
3.7 KiB
Plaintext

1. ok. I should add something about extending the lib + how to rely on ADL.
2. | I'd prefer "primary specialization" to "default" in the comments.
ok. Is that the correct term?
3. A "specialization" of a template is the result of instantiating
it, so the more accurate term, as given in Vandevoorde and
Josuttis, is "primary template."
5. new intro:
"When writing generic code that works with Standard Library
containers, one often finds it desirable to extend that code to
work with other types that offer enough functionality to satisfy
the needs of the generic code, but in an altered form. For
example, raw arrays are often suitable for use with generic code
that works with containers, provided a suitable adapter is used.
Likewise, null terminated strings can be treated as containers of
characters, if suitably adapted. This library provides the means
to adapt Standard Library containers, null terminated strings,
std::pairs of iterators, and raw arrays, such that the same
generic code can work with them all."
6. > | The Introduction is missing discussion of the use of namespace
> | scope functions to do what heretofore would be done via member
> | functions. Instead, the example and the sentence immediately
> | following it imply this change of syntax.
>
> Wouldn't it only duplicate stuff in the two links to CollectionCocept and ExternalConcepts?
In a sense, yes, but what I'm proposing is a much abbreviated
form:
"To allow generic code to work with objects that conform to the
ExternalCollectionConcept, this library provides a set of
namespace scope functions and <A
href="http://www.boost.org/more/generic_programming.html#type_generator">type
generators</A> that provide a standard interface for the required
functionality. Whereas one might write, "c.end()," to get the end
iterator from a Standard Library container, c, using this
library, it would be written, "boost::end(c)." This change in
syntax is necessary to make the same interface possible with the
other supported types such as null terminated strings."
7. [boost-book-style]I like colors, so perhaps use the boost-book stylesheets?
9. New range explanation:
I'd say "Iterable" if we have to use an "-able" term. 24.1/7
suggests to me that "Range" might be OK:
Most of the library's algorithmic templates that operate on data
structures have interfaces that use ranges. A range is a pair of
iterators that designate the beginning and end of the computation. A
range [i, i) is an empty range; in general, a range [i, j) refers to
the elements in the data structure starting with the one pointed to
by i and up to but not including the one pointed to by j. Range [i,
j) is valid if and only if j is reachable from i. The result of the
application of functions in the library to invalid ranges is
undefined.
10. Don't make empty part of the Range concept, but have a default
implementation begin() == end() + spccial treatment of char*,
11. documentation: table with entities before other tables
12. Example of how result_iterator is used, necessary:
when designing templated classes
template<class container> struct widget {
typedef result_iterator_of<container> iterator;
};
13. better external concepts: Thorsten Ottosen wrote:
>> The documentation that's provided I found
>> sufficient, it's just of a different style than other concept
>> documentation.
>
> ok. I don't think the definition of concepts are that much more
> elaborate. What could be
> much better is the example which could follow normal concept
> standards. Is that what you had in mind?
Yes.
14. Change example code for my_generic_replace.
15. More concepts: random-access range: which have constant
time size(); Cpm matthews latest article.