Subject: [Boost-commit] svn:boost r80347 - in trunk/libs/fusion: . doc
From: joel_at_[hidden]
Date: 2012-08-31 22:12:46
Author: djowel
Date: 2012-08-31 22:12:46 EDT (Fri, 31 Aug 2012)
New Revision: 80347
URL: http://svn.boost.org/trac/boost/changeset/80347
Log:
Updated changelog
removed unmaintained todo.txt
Removed:
trunk/libs/fusion/todo.txt
Text files modified:
trunk/libs/fusion/doc/changelog.qbk | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
Modified: trunk/libs/fusion/doc/changelog.qbk
==============================================================================
--- trunk/libs/fusion/doc/changelog.qbk (original)
+++ trunk/libs/fusion/doc/changelog.qbk 2012-08-31 22:12:46 EDT (Fri, 31 Aug 2012)
@@ -45,5 +45,8 @@
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]
Deleted: trunk/libs/fusion/todo.txt
==============================================================================
--- trunk/libs/fusion/todo.txt 2012-08-31 22:12:46 EDT (Fri, 31 Aug 2012)
+++ (empty file)
@@ -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.
-