[Boost-commit] svn:boost r80347 - in trunk/libs/fusion: . doc

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.
-