diff options
Diffstat (limited to 'libs/fusion/todo.txt')
-rw-r--r-- | libs/fusion/todo.txt | 185 |
1 files changed, 0 insertions, 185 deletions
diff --git a/libs/fusion/todo.txt b/libs/fusion/todo.txt deleted file mode 100644 index 2add4cc891..0000000000 --- a/libs/fusion/todo.txt +++ /dev/null @@ -1,185 +0,0 @@ -=============================================================================== -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. - |