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)
|
compilation (Joel de Guzman)
|
||||||
* October 8, 2011: Added adaptor for std::tuple (Joel de Guzman)
|
* October 8, 2011: Added adaptor for std::tuple (Joel de Guzman)
|
||||||
* October 10, 2011: Made map random access (Brandon Kohn)
|
* 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]
|
[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