1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
===============================================================================
Copyright (C) 2001-2007 Joel de Guzman, Dan Marsden, Tobias Schwinger
Use, modification and distribution is subject to 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)
===============================================================================
* Document extension::struct_size, extension::struct_member and
extension::struct_assoc_member in extension section.
* Document rationale behind at and value_at and how to choose which
to use.
* Reinstate the function object algorithms
* Break all dependency cycles if there are some more
* Break the view<-->algorithm dependency cycle
* Improve extension docs
* Document sequence/convert
* Consider object equivalent of functions and algorithms (so you can do
transform(iterators, deref()) with needing to put together a wrapper for deref).
* Make algorithms work with mutable data
* Consider segmented sequence / algorithm support
* Consider utility element_ref<Seq,Member>::type thats consts and refs as appropriate
* Improved motivation section
* Expand details of view concept
* Examples, examples, examples
* look at lambda stuff
* Complete the fusion/include/ directory containing a flat list of
include files for all the modules and components.
* The error messages when e.g. the function is not set as const are difficult
to decipher. e.g. transform(s, f) <<- where f has a non-const operator()
* mpl, fusion, container type preserving operations incompatible
-- shall we consider container-type preserving variations of the
functions/algorithms?
How about making joint_view Concept preserving? This way push/pop/front/back
will return a view of the same Concept. - tosh
* map_tie is implemented. It seems not yet documented? - Dan: done now!
* multi_set, multi_map?
* why is insert_range not spelled insert_sequence ?
* Document the new fusion extension mechanisms
->iterator_facade
->sequence_facade
* David A:
Wouldn't extension be a lot easier if iterator_base and sequence_base
took (optional) 2nd arguments that specify the tag? Then you wouldn't
need that whole dance that enables tag dispatching (right?)
* David A: is_iterator isn't documented?
JDG: There is no is_iterator ;) There is is_fusion_iterator, but it should
probably be placed in detail.
* for_each takes the function object by reference to const, so you have to
const qualify operator() and make the data members mutable so you can change
them anyway.
Eric N: IMO, this is a bug in Fusion. There should be an overload of for_each
that takes a function object by non-const reference. Stateful predicates should
be supported, and Fusion should be explicit about where and when predicates
are copied, so that the state doesn't get messed up.
* Make Boost.parameters library's ArgumentPacks a conforming fusion sequence
* Optimize container performance with typeof / compiler defect typeof. In particular
improve the performance of the prototype deque implementation.
* Deque docs if we decide we like it
* Rewrite the whole extension docs section. More formal docs of extension point,
example to use the various facade types, rather than hand coding everything.
* zip optimization - Zip is rather compiler heavy, try and reduce the likelihood
of compilers like msvc7 hitting internal compiler limits
* Document the unused support added to zip for Hartmut.
* Rationalize support/unused.hpp and the ignore stuff needed for tie etc.
* Why do we need to set FUSION_MAX_VECTOR_SIZE when we set
FUSION_MAX_MAP_SIZE? Setting FUSION_MAX_MAP_SIZE should be enough.
tosh:
* Document Incrementable / Single Pass Concepts
* Provide infinity-aware default implementation for Incrementable Sequences
Thoughts: It would probably be cleaner to have infinity conceptually
orthogonal so there can be infinite Bidi/RA/Assoc Sequences.
OTOH it complicates things in way that might not be worth it...
* Implement always_view/always with repetitive_view<single_view<T> >
semantics - using repetitive_view will for this purpose will be way
too much overhead.
? Functional wrappers for intrinsics/algorithms.
* Rewrite functional benchmark
==========================================================
From the fusion review (please mark all done items):
The following comments refer to issues that the library authors should
address prior to merging the library into CVS:
* Documentation: Many of the reviewers stated that they would like to
see more tutorial documentation that demonstrates not only what the
particular constructs in Fusion do, but also how they are expected
to be used. A reasonably concise motivating example has been
requested. It has already been pointed out that Fusion is used for
some other boost libraries. A well-developed and self-contained
case study of when and how to use Fusion would be greatly
appreciated. The relationship between this library and the current
Boost.Tuple library, as well as Boost.Mpl, should be discussed. The
reference documentation is quite thorough and detailed comments
regarding them have already been addressed by the authors. However
the notion of "views" requires greater documentation. The
examples in the algorithm sections currently do little more than
demonstrate the syntax by which they can be called. Examples that
more specifically express intent would be a notable
improvement. (see for example Matt Austern's "Generic Programming
and the STL"). In general the documentation would benefit from
copy-editing.
* Several commented on the use of the name "pair" for the fusion type
that has typedefs for two types but only contains the second type.
Although the typedefs and member names are consistent with the
std::pair object, the name "pair" is confusing. The
compile-time/run-time hybrid nature of this library makes it
difficult to find perfect metaphors for constructs in the library.
In this case, it seems better to find a term for this template (and
the concept that it models) that more directly states its purpose.
The name "tag_of" would also benefit from renaming.
* The behavior of Fusion functions in the face of argument-dependent
lookup (ADL) is not well specified. This should be made
explicit in the reference documentation.
The following comments refer to issues that, while not mandatory,
deserve consideration:
* The library name "Fusion", though not arbitrary, says little about
the library's purpose. There is precedent for this within boost,
however. A name change is not mandatory for the
library's acceptance, but it would be worth while for the authors to
consider a more telling name.
Dan - I like the name Fusion, and there is precendent for less direct
library names like Spirit and Xpressive in Boost. (And Boost is not
exactly an explicit name either).
* The mechanism for extending Fusion with new containers and iterators
is complex and involves implementing a number of components,
especially regarding iterators. An adaptation layer that is
analogous to the Boost.Iterator library would be a fine addition to
Fusion.
Dan - Joel added iterator and container adapters, still to be documented
as part of the improved extension docs to be done by me.
* It would be beneficial to supply Boost.Serialization support for the
Fusion container types. I am sure, as mentioned, that the authors
of this library would accept a volunteer to implement this
functionality.
|
