mirror of
https://github.com/boostorg/fusion.git
synced 2025-07-24 17:47:15 +02:00
Updated changelog
removed unmaintained todo.txt [SVN r80347]
This commit is contained in:
Joel de Guzman
@ -45,5 +45,8 @@ This section summarizes significant changes to the Fusion library.
|
||||
compilation (Joel de Guzman)
|
||||
* October 8, 2011: Added adaptor for std::tuple (Joel de Guzman)
|
||||
* October 10, 2011: Made map random access (Brandon Kohn)
|
||||
* April 7, 2012: Added C++11 version of deque
|
||||
* May 19, 2012: Added BOOST_FUSION_DEFINE_STRUCT_INLINE by Nathan Ridge
|
||||
* September 1, 2012: Added move support for deque and vector
|
||||
|
||||
[endsect]
|
||||
|
||||
185
todo.txt
185
todo.txt
@ -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.
|
||||
|
||||
Reference in New Issue
Block a user