May 2007 - Boost - lists.boost.org

Proposed addition to the iterator library for iterating over all tuples.
by Alex Mendes da Costa 19 Jun '09

19 Jun '09

Hi folks: I quite often have to write code to do the following: Given N sequences, generate all the N-tuples s.t. the i'th element in each tuple is drawn from the i'th sequence. For example, if sequence S1 is { 1, 2, 3 } and sequence S2 is { 10, 20 }, I need to generate these tuples: (1, 10), (2, 10), (1, 20), (2, 20). I think this problem could be solved elegantly with a iterator similar to zip_iterator. I have some questions: (1) Is there already a way to do this in boost? (2) If not, would this be a worthwhile addition to the iterator library? (3) If so, could I contribute code for this, or must the existing library owners write it? (4) If so, how would I go about getting my code added? Most of the docs seem to be about submitting entire libraries, rather than extensions to existing libraries. Thanks, Alex

4 18

[fusion] list/detail/at_impl.hpp, Suggest recrusive elem_at_c instead of recursive apply
by Larry Evans 24 Oct '07

24 Oct '07

In boost/fusion/.../list/detail/at_impl.hpp the apply is recursive; however, the only reason for the recursion is to "find the right element type". The other reason for apply is the same as that of the apply in.../vector/detail/at_impl.hpp. "find the right element type" in vector's at_impl is done with mpl::at. The similarity between list and vector at_impl would be more apparent if: template <typename Sequence, int N> struct elem_at_c { typedef typename mpl::eval_if< mpl::bool_<N == 0> , mpl::identity<typename Sequence::car_type> , elem_at_c<typename Sequence::cdr_type, N-1> >::type type; }; were used to find the right element type. Then the frist part of list::at_impl::apply would be: template <typename Sequence, typename N> struct apply { typedef elem_at_c<Sequence, N::value> element; typedef typename mpl::eval_if< is_const<Sequence> , detail::cref_result<element> , detail::ref_result<element> >::type type; which is very similar to the counterpart in vector: template <typename Sequence, typename N> struct apply { typedef mpl::at<typename Sequence::types, N> element; typedef typename mpl::eval_if< is_const<Sequence> , detail::cref_result<element> , detail::ref_result<element> >::type type;

2 3

Variable Preprocess Metaprogramming?
by Atry 20 Sep '07

20 Sep '07

As we known, there is a preprocess metaprogramming library in boost, but it is not flexible enough. we are unable to define an custom preprocess loop(something like #for or #while ?), and we are also unable to use recursion. I have an idea to do that, C/C++ allows recursion of #include, so we can put the codes we want to evaluate repeatedly to a head, and include itself depends on a preprocess condition. But if we wrote code below, we would meet a error of macro redefinition. /**** foo.hpp ****/ #if FOO < 10 // do something with I # define FOO FOO + 1 # include "foo.hpp" #endif /**** foo.hpp ****/ /**** bar.hpp ****/ #define FOO 0 #include "foo.hpp" /**** bar.hpp ****/ The problem is that an macro must not depends on itself. Thus, to change a preprocess variant, I use a bit of #if to transfer value of a macro to some temporary macro. see my code below: /**** begin_set_value.hpp ****/ #if (BOOST_VPP_VALUE & (1 << 0)) == 0 #define BOOST_VPP_TEMPORARY_BIT_0 0 #else #define BOOST_VPP_TEMPORARY_BIT_0 1 #endif #if (BOOST_VPP_VALUE & (1 << 1)) == 0 #define BOOST_VPP_TEMPORARY_BIT_1 0 #else #define BOOST_VPP_TEMPORARY_BIT_1 1 #endif /* ... */ #if (BOOST_VPP_VALUE & (1 << 30)) == 0 #define BOOST_VPP_TEMPORARY_BIT_30 0 #else #define BOOST_VPP_TEMPORARY_BIT_30 1 #endif #if (BOOST_VPP_VALUE & (1 << 31)) == 0 #define BOOST_VPP_TEMPORARY_BIT_31 0 #else #define BOOST_VPP_TEMPORARY_BIT_31 1 #endif #undef BOOST_VPP_VALUE #define BOOST_VPP_VALUE \ (BOOST_VPP_TEMPORARY_BIT_0 << 0 ) \ + (BOOST_VPP_TEMPORARY_BIT_1 << 1 ) \ + (BOOST_VPP_TEMPORARY_BIT_2 << 2 ) \ + (BOOST_VPP_TEMPORARY_BIT_3 << 3 ) \ /* ... */ \ + (BOOST_VPP_TEMPORARY_BIT_29 << 29 ) \ + (BOOST_VPP_TEMPORARY_BIT_30 << 30 ) \ + (BOOST_VPP_TEMPORARY_BIT_31 << 31 ) \ /*BOOST_VPP_VALUE*/ /**** begin_set_value.hpp ****/ Now, the BOOST_VPP_VALUE is depends on some of BOOST_VPP_TEMPORARY_BIT_n, and can be used to change the former macro: #define FOO 0 #define BOOST_VPP_VALUE FOO #include "begin_set_value.hpp" #undef FOO #define FOO (BOOST_VPP_VALUE + 1) But, FOO depends on BOOST_VPP_TEMPORARY_BIT_ns, and can not be change again, the solution is that A must a variant depends on some other BIT_n definition instead of directly depends on BOOST_VPP_VALUE. Actually, I implements an variant stack to allocate and release these variant. I think the concept of variable preprocess is useful, if Boost.Typeof or Boost.Bind use that, these code they need would be less than copying same codes. I have upload a sample on vault, file name is variable_preprocess.zip. http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=P… http://boost-consulting.com/vault/index.php?action=downloadfile&filename=va… All code is validated by wave, thank you for your attention.

6 12

[BGL] Tools for planar graph testing/embedding/drawing in the vault
by Aaron Windsor 21 Aug '07

21 Aug '07

Hi all, I've implemented a small suite of tools for dealing with planar graphs and would like to add it to the BGL. The core of this suite is built around the recent Boyer-Myrvold algorithm for planarity testing/embedding. (see http://www.emis.de/journals/JGAA/accepted/2004/BoyerMyrvold2004.8.3.pdf) A graph is planar if it can be drawn in two-dimensional space with no edge crossings. A graph is non-planar exactly when it contains a subgraph that is an expansion of one of two special subgraphs, called "Kuratowski subgraphs." This face makes it possible not only to detect that a graph is non-planar, but to prove it's non-planar by isolating one of these subgraphs. In addition to the obvious applications to graph-drawing, planar graphs are often simpler to deal with in optimization problems, and many problems that are NP-complete (most likely requiring exponential time to solve) have efficient algorithms or better approximation guarantees for the special case of planar graphs. The functions I've implemented allow one to: - Test a graph for planarity. - Embed a planar graph in the plane. - Find and verify a minimal Kuratowski subgraph in a non-planar graph. - Create a straight-line drawing of a planar graph (a mapping of vertices to points in the plane such that all edges can be drawn with straight line segments). - Traverse the faces of a planar graph using generic visitor event points in the spirit of the BGL depth-first and breadth-first search algorithms. With appropriate visitors, this traversal can be used to count the faces of a planar graph, triangulate a planar graph, or find a dual of a planar graph, among other things. With a few caveats about the efficiency of vertex index maps, etc. all of the functions above run in linear time with respect to the number of vertices in the graph, which is optimal. I've put two sets of files in the vault under Home/Algorithms/graph: the first is called planar_graphs.zip (also planar_graphs.tar.gz) and contains the .hpp files, the documentation, and the examples. The second is called planar_graph_testing.zip (also planar_graph_testing.tar.gz) and contains over 1000 test graphs and a small program that can be compiled to give an example of how these planar graph tools can be used. I'd appreciate any comments! Regards, Aaron

5 18

[Ann] Variadic Templates
by Doug Gregor 20 Aug '07

20 Aug '07

Hello Fellow Boosters, I have just completed implementing support for "Variadic Templates" in GCC. Variadic templates are C++ templates that can accept any number of "extra" template arguments, just like a function that uses C-style varargs (with "...") can accept any number of extra arguments. Unlike C varags, however, variadic templates work both for class templates and function templates, and are completely type-safe. Why do variadic templates matter for Boost? For one thing, they will allow us to eliminate the use of preprocessor metaprogramming in many, many places throughout the library. This can simplify our library implementations drastically, and eliminate those annoying "caps" on the number of arguments one can use (ever tried to use bind () with 11 arguments?). Beyond that, variadic templates are just plain fun, and there are undoubtedly a great number of metaprogramming applications. Here are a few teasers to illustrate what variadic templates can do: We can implement an MPL-like type vector with one line of code: template<typename... Types> struct vector { }; The "ellipsis" means that we can pack any number of arguments into the "template parameter pack" called Types. Of course, we can do the same for MPL's vector_c: template<typename T, T... Values> struct vector_c { }; Unimpressed? Here's an implementation of tuple that accepts any number of element types: template<typename... Values> class tuple; template<> class tuple<> { }; template<typename Head, typename... Tail> class tuple<Head, Tail...> : private tuple<Tail...> { protected: Head m_head; }; We're using recursion to build up the tuple. The ellipsis operator works with partial specializations, too, packing together "extra" arguments at the end. Of course, all of this would be useless if we couldn't write some of the other tuple operations, like operator==: inline bool operator==(const tuple<>&, const tuple<>&) { return true; } template<typename T, typename... TTail, typename U, typename... UTail> bool operator==(const tuple<T, TTail...>& t, const tuple<U, UTail...>& u) { return t.head() == u.head() && t.tail() == u.tail(); } Variadic function templates can accept any number of function arguments, so we can now (finally!) implement a type-safe printf() without mangling the tried-and-true printf() syntax or restricting ourselves to POD types: void printf(const char* s) { while (*s) { if (*s == '%' && *++s != '%') throw std::runtime_error("invalid format string: missing arguments"); std::cout << *s++; } } template<typename T, typename... Args> void printf(const char* s, const T& value, const Args&... args) { while (*s) { if (*s == '%' && *++s != '%') { std::cout << value; return printf(++s, args...); } std::cout << *s++; throw std::runtime_error("extra arguments provided to printf"); } I've also built prototypes of of Function and Bind, among other things. The Bind example is especially interesting, and worth a read (see below) Interested? There is more information and a complete implementation in GCC available at: http://www.generic-programming.org/~dgregor/cpp/variadic- templates.html I've written two documents describing variadic templates in more detail: http://www.generic-programming.org/~dgregor/cpp/brief-intro.pdf : A brief introduction to variadic templates, that walks through the printf() implementation. http://www.generic-programming.org/~dgregor/cpp/variadic- templates.pdf : A complete proposal to introduce variadic templates into C++0x. This contains annotated versions of the tuple, function, and bind prototypes along with a detailed description of the capabilities of variadic templates. The GCC implementation is complete, supporting all of the features described in the proposal. I've used it for proof-of-concept implementations of several libraries. In the (near) future, I hope to introduce variadic templates support into the "official" GCC, but I need your help! Are variadic templates worthwhile? Will they help us build better, cleaner Boost libraries in the future? Should we bring variadic templates to the C++ committee, to enable better implementations of TR1 components and eliminate the need for much of the preprocessor metaprogramming we do today? Feedback is greatly appreciated. Cheers Doug Gregor Open Systems Lab @ Indiana University

20 39

Boost building with CMake
by Bill Hoffman 17 Aug '07

17 Aug '07

Hi, I noticed the "boost development process / scope" thread on your list. A CMake user posted a link to your discussion. There is significant interest in the CMake community to help boost transition to CMake. Several people on the CMake list have volunteered to help, and Kitware is willing to put about 2 man weeks of effort into the conversion. I think that CMake has all the features to do what you need at this point, but if any bugs or issues are discovered during the process, we can fix them and/or provide work-arounds for the issues. I realize you have not yet decided on moving to CMake, but I thought I would put out this offer so that you could consider "free" support as one of the benefits you will receive from the port to CMake. I can see this happening in two ways. One would be for a CMake developer to create initial cmake files for boost, and get the basics working. Then, the work would be turned over to the Boost community. The other way would be to have a boost developer create the build files with help and support from the CMake community. Either way works for me. Of course, no one will want to do anything unless there is a commitment to actually use CMake. I will stay on this list while you decide, and answer any questions about CMake that may come up. Thanks, and I look forward to working with the boost community in the future. -Bill

47 194

Submission to "Who's Using Boost?"
by Seweryn Habdank-Wojewódzki 09 Aug '07

09 Aug '07

Hi! I am using Boost library in Open Source library for Kohonen Neural Networks construction and training. I would like (if possible) join to famous list of Open Source users of the Boost library :-). * The name of the Application/Product/Service. Kohonen Neural Network Library (KNNL) * The name of the company (where appropriate). --- Personal initiative --- Authors: * Seweryn Habdank-Wojewódzki * Janusz Rybarski * A paragraph describing the Application/Product/Service. Kohonen neural network library is a set of classes and functions for design, train and use Kohonen networks (self organizing maps). * Any information you can provide about which parts of Boost you used, along with any comments you may have on how Boost helped your product development. KNNL Library requirements: * Boost Library ver. 1.33. o Core of library needs: + boost::bind, + boost::function, + boost::type_traits o Demonstration program uses: + boost::program_options * URLs to your companies home page, and the home page of the Application/Product/Service if there is one. http://knnl.sourceforge.net/ Best regards. -- |\/\/| Seweryn Habdank-Wojewódzki \/\/

2 1

[extension]
by Stephan Diederich 16 Jul '07

16 Jul '07

Hi, I've some questions regarding boost.extension which I think is currently prepared to review by Mariano Gabriel Consoni as one of the SoC Projects. We want to use a plugin loading mechanism in one of our projects and have some ideas currently not included in the boost.extensions library. - Some kind of versioning of interfaces and implementations. The idea is to give an interface (whose implementation is loaded as an extension) a version, which can be later compared to the version of the loaded implementation. As one of boost.extension's goal is NOT to modify a class-header to make it loadable, this should possibly be an optional feature. Another option would be to give non versioned interfaces always version 0 or 1. - It would be nice, if the plugin-loader provides functionality to "switch" the interface of an instance of an implementation. IIRC, the zone object knows, which interfaces are implemented by a loadable class. (when the dll is loaded, the export-function registers all the possible interfaces of one class to the zone). With that information it should be possible to determine if a given instance of a loaded class can be casted to another interface. (I think that casting has to be done in the loaded extension, as this is the only place where the layout it known. ) Are there any plans to include above mentioned functionality in boost.extension? Thanks in advance, Stephan

3 8

Review Request: Boost Exception
by Emil Dotchevski 07 Jul '07

07 Jul '07

I believe the proposed Boost Exception library is now mature enough for formal review. Please read the documentation at: http://www.revergestudios.com/boost-exception/boost-exception.htm Here is a direct link to the source code, boost build jamfiles and tests. Tested with MSVC 7.1, MSVC 8.0, GCC 3.4.4, and Comeau C++ 4.3.8: http://www.revergestudios.com/boost-exception/boost-exception.zip Regards, Emil Dotchevski

7 21

[fusion] Illegal partial specialization error.
by Michael Marcin 06 Jul '07

06 Jul '07

If I include <boost/fusion/support/tag_of.hpp> my compiler (derived from Metrowerks 9.4) gives me several errors claiming illegal partial specializations. It looks like it's partially specializing forward declarations of the tag_of structure. I don't know if that's allowed (from the error I assume probably not) but it certainly seems to be pointless to me. Are these perhaps supposed to be more than declarations? Thanks, Michael Marcin

7 17

Interest in a static-sized version of cvalarray
by Michael Tegtmeyer 06 Jul '07

06 Jul '07

Some time ago I posted a message to this list about interest in a static-sized version of cvalarray. I'll include the original message for reference. I received some emails stating that there was interest. The implementation has been in the sandbox for some time now. I'd like to guage interest again to determine if it is worth working to add to boost. The implementation has not been boostified because it is in active use here where I work (autotool land) so if there is interest, some additional work needs to be done to absorb the boost framework. The implementation is complete without any known bugs. There is only one header but you can go though the normal ./configure, make, make install to put it somewhere. Tests can be run using 'make check' and documentation is in the doc directory. Of additional interest since my previous post: the implementation will now automaticallty unroll all numeric ops at compile time (subject to the compiler) up to a predefined array size. My original post: Hello, I am trying to guage interest in a fixed sized version of valarray. I frequently found myself using small(-ish) compile-time known sized numeric arrays that don't justify the overhead of operator new in std::valarray but needed the math interface that valarray provided. I wrote a static-sized version of valarray for this purpose. It is modeled after std::valarray and implements about 90% of valarray's interface (obviously resizing is not included, neither is gslice due to the result not being known at compile time). Examples of it's use are: float _v[10] = {...}; size_t _i[5] = {...}; cvalarray<float,10> v1(_v); cvalarray<float,5> v2 = v1[cslice<0,5,2>()]; v1[cslice<0,3,3>()] = 0.0f; cvalarray<size_t,5> ind(_i); cvalarray<float,5> cvalB = v1[ind]; v2 *= (v2 + v1) / 2.0; //all of the usual math ops I have a complete implementation that models std::valarray in every possible way (with compile-time known limitations) including expression-template support for the numeric ops. My testing indicates a decent performance increase over gcc4's valarray for small number of elements <1000. If anyone has any interest, I'll put together some docs and throw it in the sandbox. Mike Tegtmeyer

7 23

[BGL] Adapter from bidirectional to undirected graph
by Benoit 05 Jul '07

05 Jul '07

Hello everyone, I have been using the BGL for quite some time with both directed and bidirectional graphs (with adjacency_list). Sometimes i need to use these graphs in algorithms as if they were undirected... AFAICT, this is currently not possible because out_edges() exists in all cases, but don't do the same... The obvious solution consists in writing a dedicated adapter used for translating a bidirectional graph into a directed one at least for out_edges(), and optionally for other stuff (internal properties, vertex and edge descriptors?) to make this subtle change as transparent as possible. Can you think of another way ? Is there already such an adapter somewhere (i have unsuccessfully tried to find one...) ? In case it didn't exist, would anyone else be interested to have one ? Benoît PS : I'd like to thank the authors of the BGL, it's a pleasure to work with it everyday !

3 2

[Boost-bugs] [ boost-Support Requests-1707948 ] Assertion failed in token_iterator.hpp
by SourceForge.net 03 Jul '07

03 Jul '07

Support Requests item #1707948, was opened at 2007-04-26 03:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1707948&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion failed in token_iterator.hpp Initial Comment: Using BOOST.1.33.1 with Borland C++. I've suddenly got a Message Box saying: Assertion failed: valid_, file ...boost/token_iterator.hpp, line 52 Line 52 in token_iterator.hpp is: assert(valid_); in void increment(){}. Could anybody give me a clue as to what might be going on and why it has suddenly started happening, please? With thanks in anticipation, Paul Collins (paul(a)screen.subtitling.com) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1707948&group_… ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

[math toolkit]
by Leopoldo Peralta 02 Jul '07

02 Jul '07

This Fatal Error occurs when trying to compile a MSVC 2003 (SP1) project using the proposed Math Toolkit: C:\boost_1_34_0_beta\boost_1_34_0\boost\math\special_functions\log1p.hpp(195 ): error C2785: 'tools::promote_args<T>::type boost::math::log1p(T)' and 'double boost::math::log1p(double)' have different return types Any fix to this error? Leopoldo Peralta

2 8

Any interest in an "opaque iterator" library?
by lists＠mr-edd.co.uk 29 Jun '07

29 Jun '07

Hi folks, I've been working on an "opaque iterator" library that is designed to do for iterators what the pimpl idiom does for classes in general. A motivating example and some experimental code can be found here: http://www.mr-edd.co.uk/?p=36 Before I take it further I'd like to know if there's any interest in having such a library within the boost collection so I can start refactoring it in the rough direction needed for formal review. Thanks, Edd

5 8

[ptr_container] feature request: BOOST_PTR_CONTAINER_NO_SERIALIZATION
by Sebastian Ramacher 25 Jun '07

25 Jun '07

As of version 1.34, Boost.PtrContainer supports serialization as defined by Boost.Serialization. Now I'd like to propose a switch to disable this feature. The attached patch adds checks if BOOST_PTR_CONTAINER_NO_SERIALZATION is defined around the serialization related code blocks and enables/disables serialization support. It's not that I don't like serialization support but on a Debian system you have to install libboost-serialization-dev and libboost-serialization1.34.0 just to use Boost.PtrContainer. The patch was created against CVS HEAD but I'd gladly provide a patch against 1.34 if it finds any interest. Regards, Sebastian Index: ptr_array.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/ptr_container/ptr_array.hpp,v retrieving revision 1.9 diff -u -r1.9 ptr_array.hpp --- ptr_array.hpp 16 Feb 2006 23:38:36 -0000 1.9 +++ ptr_array.hpp 28 May 2007 13:35:29 -0000 @@ -190,6 +190,7 @@ return this->c_private()[idx] == 0; } +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION public: // serialization template< class Archive > @@ -214,7 +215,7 @@ } BOOST_SERIALIZATION_SPLIT_MEMBER() - +#endif }; ////////////////////////////////////////////////////////////////////////////// Index: ptr_map_adapter.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/ptr_container/ptr_map_adapter.hpp,v retrieving revision 1.26 diff -u -r1.26 ptr_map_adapter.hpp --- ptr_map_adapter.hpp 8 Mar 2006 23:16:00 -0000 1.26 +++ ptr_map_adapter.hpp 28 May 2007 13:36:09 -0000 @@ -291,6 +291,7 @@ return replace( where, x.release() ); } +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION public: // serialization template< class Archive > @@ -305,6 +306,7 @@ ar & ptr_container_detail::serialize_as_const( i->second ); } } +#endif }; } // ptr_container_detail @@ -472,6 +474,7 @@ return transfer( from.begin(), from.end(), from ); } +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION public: // serialization template< class Archive > @@ -493,7 +496,7 @@ } BOOST_SERIALIZATION_SPLIT_MEMBER() - +#endif }; ///////////////////////////////////////////////////////////////////////// @@ -647,6 +650,7 @@ BOOST_ASSERT( from.empty() ); } +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION public: // serialization template< class Archive > @@ -668,7 +672,7 @@ } BOOST_SERIALIZATION_SPLIT_MEMBER() - +#endif }; template< class I, class F, class S > Index: ptr_vector.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/ptr_container/ptr_vector.hpp,v retrieving revision 1.10 diff -u -r1.10 ptr_vector.hpp --- ptr_vector.hpp 18 Feb 2006 01:41:14 -0000 1.10 +++ ptr_vector.hpp 28 May 2007 13:35:09 -0000 @@ -53,6 +53,7 @@ this->c_private().reserve( n ); } +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION public: // serialization template< class Archive > @@ -66,7 +67,7 @@ } BOOST_SERIALIZATION_SPLIT_MEMBER() - +#endif }; ////////////////////////////////////////////////////////////////////////////// Index: detail/reversible_ptr_container.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/ptr_container/detail/reversible_ptr_container.hpp,v retrieving revision 1.24 diff -u -r1.24 reversible_ptr_container.hpp --- detail/reversible_ptr_container.hpp 6 Mar 2006 20:09:50 -0000 1.24 +++ detail/reversible_ptr_container.hpp 28 May 2007 13:35:10 -0000 @@ -35,7 +35,11 @@ #include <boost/utility/enable_if.hpp> #include <boost/type_traits/is_pointer.hpp> #include <boost/type_traits/is_integral.hpp> + +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION #include <boost/serialization/split_member.hpp> +#endif + #include <algorithm> #include <exception> #include <memory> @@ -46,12 +50,13 @@ namespace ptr_container_detail { - +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION template< class T > inline T const& serialize_as_const( T const& r ) { return r; } +#endif template< class CloneAllocator > struct clone_deleter @@ -545,6 +550,7 @@ return replace( idx, x.release() ); } +#ifndef BOOST_PTR_CONTAINER_NO_SERIALIZATION // // serialization // @@ -602,7 +608,7 @@ } BOOST_SERIALIZATION_SPLIT_MEMBER() - +#endif }; // 'reversible_ptr_container'

4 10

proto::tag naming convention
by Maurizio Vitale 22 Jun '07

22 Jun '07

What is the rationale for not having proto::tags match the corresponding mpl metafunctions? For instance mpl has plus and proto has add (but unary_plus). Since people will often mix the two, it would be nice to have the same name. (I basically have to look them up everytime I use one of them) If the intention was to make them different so that they can be mixed without namespace qualification I think they're not different enough. Given divide and divides, which is proto's and which is mpl's? Clearly one gets used to these things, but maybe it is something to consider before finalizing proto for inclusion in boost. regards Maurizio

7 25

Concurrent async requests
by Владислав Чернышов 08 Jun '07

08 Jun '07

Hi! If I do something like this can I be sure that async requests will run concurrently? boost::asio::io_service io_service; client c(io_service, argv[1], argv[2]); client c1(io_service, argv[1], argv[2]); boost::thread tr1(boost::bind(&boost::asio::io_service::run, &io_service)); io_service.run(); tr1.join(); The client class is a class from boost.asio example. Vlad

2 3

[multi_index] use cases for iterator_to()
by "JOAQUIN LOPEZ MU?Z" 08 Jun '07

08 Jun '07

Hello, More than a year ago a request was made for Boost.MultiIndx to provide the ability to get an iterator to an element x from x alone: iterator iterator_to(const value_type& x); I can provide this functionality in constant time, and the internal implementation is trivial, but I got thinking about the potential use cases for such capability and cannot come up with something convincing. Do you see usefulness in having iterator_to()? Can you describe a potential usage scenario? At first blush, seems like this is at least as useful as the homonym functionality in Boost.Intrusive, but if you think about the obvious scenarios applying to B.I, it turns out they do not immediately translate to B.MI. Thank you! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 6

binary_iostreams library
by Ares Lagae 07 Jun '07

07 Jun '07

I have developed a small library for binary I/O, called binary_iostreams, and I am using it in several of my own projects. I was wondering if there is interest for such a binary_iostreams library? The binary_iostreams is a small library, very similar to the iostreams library. Compared to iostreams, the unformatted I/O operators remain, and the formatted I/O operators now do binary I/O. This makes the binary_iostreams library easy to use for anyone acquainted with the iostreams library. The binary_iostreams library allows to set the endianness of the output stream. Together with <cstdint>, this allows for portable binary I/O, although binary_iostreams does not claim to be a full blown serialization library. Direct link to a motivating example: http://www.cs.kuleuven.ac.be/~ares/binary_iostreams/test.cpp The library: http://www.cs.kuleuven.ac.be/~ares/binary_iostreams/binary_iostreams-0.1.ta… The documentation: http://www.cs.kuleuven.ac.be/~ares/binary_iostreams/doc/html Best regards, -- Ares Lagae Computer Graphics Research Group, Katholieke Universiteit Leuven http://www.cs.kuleuven.be/~ares/

10 23

SVN repo structure... [was: Subversion structure in KDE]
by Rene Rivera 05 Jun '07

05 Jun '07

Ping... Any comments on this? It would be nice if people voice some comments on this subject now. Instead of later when we would have to move a bunch of directories around. -------- Original Message -------- Subject: Re: [boost] Subversion structure in KDE Date: Sun, 27 May 2007 17:54:20 -0500 From: Rene Rivera <grafikrobot(a)gmail.com> Henrik Sundberg wrote: > KDE is also a large project with separate subprojects. I thought it > might be a good idea to look at their structure. [snip] > Here is the repository: http://websvn.kde.org/ [snip] > How about a trunk with the two subdirectories Boost and Sandbox? The > Boost directory would contain libraries that are to be part of the > next official Boost release, and the Sandbox other libraries. If I'm understanding you, and the KDE docs, correctly, what you want is something like(**): [boost-svn] boost stable (full boost tree here) devel (full boost tree here) branches my_branch (full boost tree here) cmake_a (full boost tree here) cmake_b (full boost tree here) tags boost_1_33_1 (full boost tree here) boost_1_34_0 (full boost tree here) sandbox devel xml (partial boost tree here) explore (partial boost tree here) branches xml_b0 (partial boost tree here) explore_b0 (partial boost tree here) tags xml_for_review (partial boost tree here) explore_for_review (partial boost tree here) That seems like a reasonable arrangement to me. It has the beauty of being easy to explain, and it's not too far off from what we have now. The one drawback I can see is that one common case, of updating boost/stable and boost/devel can't be done in one go. But I think that's a reasonable aspect to give up (not that we had it in the first place) since hopefully working with both at the same time will be an infrequent task. (**) I'm ignoring the website tree because it's not the same kind of beast. Since it only has to deal with two versions, and doesn't need tags. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

12 21

GSoC: "Boost.Extension and Reflection" library [plugin]
by Janek Kozicki 04 Jun '07

04 Jun '07

The link from http://code.google.com/soc/boost/about.html states: Title: Boost.Extension and Reflection Student: Mariano Gabriel Consoni Mentor: Hartmut Kaiser "The project that I propose is centered in adding to Boost a library that allows the programmer to include extensions/plugins. Additionally this will be the start point to implement reflection concepts. [...]" I want to ask what is the progress with this library? I remember from GSoC 2006 conclusions that we all agreed that the progress during SoC should be advertised on boost mailing list to encourage participation from other people (especially looking at code during its evolution). I'm not even sure if SoC has already started, or will it start next month? Anyway I want to point out that I'm particularly curious about the progress in this area. PS: why this wiki webpage for GSoC 2007 is wiped out? http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summe… -- Janek Kozicki |

6 13

[soc 07] SoC 2007 Projects
by Jeff Garland 04 Jun '07

04 Jun '07

Hi All - I'm happy to announce that Boost will be mentoring 9 Google SoC projects this year. They are: Title Student Mentor ----------------------------------------------------------------------------- User-friendly graphs and their measures Andrew Sutton Jeremy Siek FastCGi and SCGI-compatible CGI library Darren Garvey Christopher M Kohlhoff Boost 'Big Integer' proposal Arseny Kapoulkine Jeff Garland Signal Network library Stjepan Rajko Douglas Gregor Evolutionary Computation Library Aaron Garrett Jaakko Järvi Application to extend Boost regex with recursive matching, named sub-expressions, and automata-based matching Hugh Wimberly John Maddock Visualization Of Arrays And STL Containers Jacob R>Voytko Joaquín L. Muñoz Boost.Extension and Reflection Mariano G. Consoni Hartmut Kaiser A Generic Geometric Library Huseyin Akcan Herve Bronnimann You can find the abstracts of these projects online here: http://code.google.com/soc/boost/about.html As with last year, there were many worthy students and projects that ultimately were not selected. So, for all the students that were not selected realize that the competition for a very few slots was immense. My main advice for students that might want to try again next year is to start participating now -- it really helps to hang out on the list, submit patches, and work on ideas well in advance of SoC. I'd like to thank the mentoring team that evaluated the ~220 applications we received this year. It takes a huge effort to go thru these, read, rank, clarify and give feedback. Note that in addition to the mentors above Andreas Huber, Rene Rivera, and Daniel Wallin all helped with evaluations. For those coming to BoostCon I'll be giving a presentation on Friday about Boost and SoC: http://www.boostcon.com/program/sessions#garland-summer-of-code And, if you aren't coming to BoostCon, well, you should ;-) http://www.boostcon.com/registration Jeff

5 5

noncopyable EBO problem?
by Gmane 04 Jun '07

04 Jun '07

Hi, as sparent(a)adobe.com pointed out in <http://svn.boost.org/trac/boost/ticket/979>, the EBO is not possible in some cases. I fixed the operators library, but now I wonder if we should fix boost::noncopyable as well. Consider: class A : boost::noncopyable {}; class B : boost::noncopyable { A a; }; now sizeof(B)==2 instead of the expected 1. To fix it, we have to change the interface (or at least allow an alternative interface). Example with the interface I'd like to suggest: class A : boost::noncopyable_<A> {}; class B : boost::noncopyable_<B> { A a; }; now sizeof(B)==1, as expected. The crucial point of such a change is IMHO the interface. Breaking noncopyable is bad, so I'd like to add noncopyable_<T> and make noncopyable a typedef to noncopyable_<void>. This should provide backwards compatibility and provides users with a better, but less brief alternative in case they need the additional EBO opportunity. Comments? Since it's so damn short, here's the suggested implementation: namespace boost { namespace noncopyable_impl // prevent unintended ADL { template< typename > class noncopyable_ { protected: noncopyable_() {} ~noncopyable_() {} private: noncopyable_( const noncopyable_& ); const noncopyable_& operator=( const noncopyable_& ); }; typedef noncopyable_<void> noncopyable; } using namespace noncopyable_impl; } Regards, Daniel

5 6

[1.34.1][pool] Open Issues
by Thomas Witt 04 Jun '07

04 Jun '07

There are two open tickets for pool in 1.34.1. http://svn.boost.org/trac/boost/ticket/284 http://svn.boost.org/trac/boost/ticket/991 Any takers? Thomas -- Thomas Witt witt(a)acm.org

4 5

[BoostCon] Presentation material
by Michael Marcin 03 Jun '07

03 Jun '07

Unfortunately I wasn't able to attend Boost Con this year. Is there any materials from the presentations? Videos, white papers, power points? Thanks, Michael Marcin

4 4

typo in boost header: date_time/time_defs.hpp
by Sunil Rao 02 Jun '07

02 Jun '07

Hello, I'm writing to report a small typo a colleague of mine has discovered in the time_defs.hpp header in the date_time library. [Apologies if this is a known issue: I wasn't able to find any specific reference to this in any of the list archives.] http://boost.org/boost/date_time/time_defs.hpp The specific issue is in the time_resolutions enum: "hundredth" is misspelt as "hundreth". Hope this helps -sunil

2 1

[regex] empty expression issue
by impulse9 02 Jun '07

02 Jun '07

Hi All, I've just started to use boost::regex I met with the following incompatibility with Perl regular expressions: It is impossible to use empty expressions, neither alone nor inside of another regex statement. Sample code: #include <iostream> #include <boost/regex.hpp> void check_regexp(const char * text) { try { boost::regex e("(\\d+)\\s*(kbit|)"); boost::cmatch what; if (boost::regex_match(text, what, e)) { std::string item1(what[1].first, what[1].second); std::string item2(what[2].first, what[2].second); std::cout << "matched. " << std::endl << "Value : " << item1 << std::endl << "Units : " << item2 << std::endl << std::endl; } } catch (boost::regex_error & e) { std::cout << "ERROR: " << e.what() << std::endl; } } int main(int argc, char** argv) { check_regexp("96 kbit"); } Program output: ERROR: Empty expression Such regular expressions are quite legal in Perl (e.g. /(Ann|Bob|)/) One possible (quick-n-dirty) workaround for this is to replace boost::regex e("(\\d+)\\s*(kbit|)"); with boost::regex e("(\\d+)\\s*(kbit|.{0})"); Program output would be: matched. Value : 96 Units : kbit Would it be considered as an issue for further improvement? Thank you. -- impulse9

3 4

[guid] - review results?
by Janek Kozicki 01 Jun '07

01 Jun '07

Hello Hartmut, Sorry about being pushy a bit, I'm just curious about the review results. I'd submit a review if I weren't moving from one country to another and defending my PhD during that week, sorry for that ;) -- Janek Kozicki |

13 26

#1013 and 1.34.1
by Vladimir Prus 31 May '07

31 May '07

Would it be possible to apply patch from http://svn.boost.org/trac/boost/ticket/1013 to 1.34.1? This issue has prevented a user from building Boost.Python, and the fix is as safe as possible -- it only changes signatures of two methods so that more than one include path can be passed. - Volodya

2 1

Re: [boost] boost::final similar to boost::noncopyable
by Costin Calisov 31 May '07

31 May '07

Ok, good to know that, but, I'm still curious what is wrong with my code. Why is it passing a compiler and why is failing on the other? "Gennadiy Rozental" <gennadiy.rozental(a)thomson.com> wrote in message news:f3hcjq$4i6$1@sea.gmane.org... > > AFAIK there is no standard compliant way to implement final. At least not > until C++09. > > Gennadiy

3 7

[iterator] Proposal to add is_const_iterator trait
by Andrey Semashev 31 May '07

31 May '07

Hello, Quite often I find myself writing an is_const_iterator trait which looks like this: //! A helper traits to check if an iterator is const template< typename ItT > struct is_const_iterator : public is_const< typename remove_reference< typename iterator_reference< ItT >::type >::type > { }; Maybe it is worth adding to Boost.Iterators library? Or maybe there already is something like that? -- Best regards, Andrey mailto:andysem@mail.ru

4 21

svn.boost.org password reset
by Vladimir Prus 31 May '07

31 May '07

Is there any way to reset one's password at svn.boost.org? There's no such button in the interface anywere. Thanks, Volodya

2 2

Re: [boost] binary_iostreams library
by bwood 31 May '07

31 May '07

Jeremy Maitin-Shepard writes: >These seem to be good ideas. I agree that C++ is in need of a new I/O >system built on proper abstractions. It is kind of perplexing how this area remains slow to change. http://lists.boost.org/Archives/boost/2006/04/103692.php <snip> >As a side note, in doing so it is >important to be extremely cautious with the use of template >meta-programming, as horrendous compile-times are a real barrier >to the use of certain libraries. In some cases it goes beyond compile-times to poor run-times -- www.seventy7.homelinux.net/comparison.html The sizes of executables built with B.Ser compared to those with an external code generator provide the first clue that the obese aren't going to be able to survive a foot race. Brian Wood Ebenezer Enterprises

1 0

date_time iterator missing operators
by Andrew Webber 31 May '07

31 May '07

I recently set out to evaluate boost::date_time for use in a large commercial project. I was extremely impressed with the large feature-set and the obvious depth of thought put into the library. However, I was a little upset about some small features missing from day_iterator, month_iterator, and year_iterator. Specifically, I wished for equality, inequality, post-increment and post-decrement operators. The inequality operator in particular would add the ability to use this group of iterators with many of the standard algorithms such as std::copy. I'm very new to the boost developers mailing list, so please forgive me and inform me if I'm breaking protocol in some way here. I went ahead and implemented the missing iterator operators. Interestingly, because the design of the iterators, the equality and inequality operators work between different types of iterators (day, month or year). I've also added some demo code to test out the new features. It's definitely not a unit test, but at least you can see that the operators are working. I've successfully compiled the new boost::date_time code and demo code under Visual Studio .NET 2003. If I have time, I will also test the code on gcc 3.4 and gcc 4.0. Here is a patch file of the changes to boost/date_time/date_iterator.hpp: Index: C:/My Documents/Code/Code Library/Boost/include/boost-1_34/boost/date_time/date_iterator.hpp =================================================================== --- C:/My Documents/Code/Code Library/Boost/include/boost-1_34/boost/date_time/date_iterator.hpp (revision 592) +++ C:/My Documents/Code/Code Library/Boost/include/boost-1_34/boost/date_time/date_iterator.hpp (working copy) @@ -51,6 +51,14 @@ current_ = current_ + get_neg_offset(current_); return *this; } + bool operator==(const date_itr_base& rhs) + { + return (current_ == rhs.current_); + } + bool operator!=(const date_itr_base& rhs) + { + return !(*this == rhs); + } virtual duration_type get_offset(const date_type& current) const=0; virtual duration_type get_neg_offset(const date_type& current) const=0; date_type operator*() {return current_;}; @@ -81,6 +89,20 @@ date_itr_base<date_type>(d), of_(factor) {} + using date_itr_base<date_type>::operator++; + const date_itr operator++(int) + { + date_itr temp(*this); + ++*this; + return *temp; + } + using date_itr_base<date_type>::operator--; + const date_itr operator--(int) + { + date_itr temp(*this); + --*this; + return *temp; + } private: virtual duration_type get_offset(const date_type& current) const { Here is the test code: void date_time_example() { boost::gregorian::date today(boost::gregorian::day_clock::universal_day()); boost::gregorian::day_iterator day1(today); boost::gregorian::day_iterator day2(today + boost::gregorian::days(10)); boost::gregorian::month_iterator month1(today); if(day1 == day2) { std::cout << "day1 and day2 equal\n\n"; } else { std::cout << "day1 and day2 not equal\n"; } if(day1 == month1) { std::cout << "day iterator == month iterator\n"; } ++month1; if(day1 != month1) { std::cout << "now day iterator != month iterator\n"; } std::cout << "\n"; boost::gregorian::day_iterator day3(day1); std::cout << "day3 and day2 not equal\n"; std::cout << *day3 << " "; std::cout << *day2 << "\n"; day3 = day2++; std::cout << "day3 and day2 after day2 postincrement\n"; std::cout << *day3 << " "; std::cout << *day2 << "\n"; day3 = day2--; std::cout << "day3 and day2 after day2 postdecrement\n"; std::cout << *day3 << " "; std::cout << *day2 << "\n\n"; std::cout << "Now std::copy works because of != operator\n"; std::copy(day1, day2, std::ostream_iterator<boost::gregorian::date>(std::cout, "\n")); } Is this something that may be considered for inclusion in the date_time library? Regards, Andy Webber

2 2

[cvs] Conflict between Boost.Graph and Boost.String_algo
by Dean Michael Berris 31 May '07

31 May '07

Hi Everyone, It seems like there's a problem with the following include sequence: #include <boost/graph/adjacency_list.hpp> #include <boost/graph/graph_utility.hpp> #include <boost/graph/visitors.hpp> #include <boost/graph/breadth_first_search.hpp> #include <boost/algorithm/string.hpp> GCC 4.1.2 complains that boost::contains and boost::all is already defined. The compiler complains that boost/boost/algorithm/predicate.hpp is trying to define 'contains' and 'all' which apparently is already defined somewhere in the Boost.Graph headers. I would submit a patch, but I didn't know whether to touch Boost.Graph or String Algorightms and how. (Using latest CVS checkout May 30) HTH -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459

3 4

Boost inspection notification (2007-05-31/RC_1_34_0) *LC*
by Rene Rivera 31 May '07

31 May '07

Boost Inspection Report Run Date: 16:09:32 UTC, Thursday 31 May 2007 An inspection program <http://www.boost.org/tools/inspect/index.html> checks each file in the current Boost CVS for various problems, generating this as output. Problems detected include tabs in files, missing copyrights, broken URL's, and similar misdemeanors. Totals: 11453 files scanned 909 directories scanned (including root) 1059 problems reported Problem counts: 661 files missing Boost license info or having wrong reference text 398 files missing copyright notice Summary: any (1) archive (1) build (68) concept_check (22) conversion (5) doc (1) filesystem (2) function (1) graph (1) inspect (1) integer (9) lambda (10) libs (6) logic (2) math (1) more (13) mpl (417) multi_array (13) numeric (188) optional (1) people (4) program_options (35) property_map (15) ptr_container (8) python (14) rational (5) regex (4) regression (118) release (2) serialization (16) signals (2) smart_ptr (8) test (3) timer (1) tr1 (2) tuple (5) utility (12) variant (42) Details: *L* missing Boost license info, or wrong reference text *C* missing copyright notice |any| libs/any/doc/ any.xml: *L* |archive| boost/archive/detail/ utf8_codecvt_facet.hpp: *L* |build| tools/build/v2/build/ build-request.jam: *L* modifiers.jam: *L* tools/build/v2/doc/ Jamfile.v2: *C* *L* tools/build/v2/doc/src/ advanced.xml: *C* *L* architecture.xml: *C* *L* catalog.xml: *C* *L* extending.xml: *C* *L* faq.xml: *C* *L* fragments.xml: *C* *L* howto.xml: *C* *L* install.xml: *C* *L* recipes.xml: *C* *L* reference.xml: *C* *L* standalone.xml: *C* *L* tutorial.xml: *C* *L* userman.xml: *C* *L* tools/build/v2/example/generate/ REAME.txt: *C* *L* a.cpp: *C* *L* tools/build/v2/example/generator/ README.txt: *C* *L* soap.jam: *C* *L* tools/build/v2/example/python_modules/ python_helpers.jam: *C* *L* python_helpers.py: *C* *L* tools/build/v2/test/ abs_workdir.py: *C* *L* dependency_property.py: *L* dependency_test.py: *C* *L* direct_request_test.py: *C* *L* dll_path.py: *L* double_loading.py: *L* duplicate.py: *L* echo_args.jam: *C* *L* empty.jam: *C* *L* expansion.py: *L* explicit.py: *L* gcc_runtime.py: *L* tools/build/v2/test/project-test3/lib3/ Jamfile: *C* *L* tools/build/v2/test/ readme.txt: *C* *L* svn_tree.py: *L* tag.py: *L* test_system.html: *L* tools/build/v2/tools/ sun.jam: *L* xsltproc.jam: *L* |concept_check| libs/concept_check/ bibliography.htm: *L* concept_check.htm: *L* concept_covering.htm: *L* creating_concepts.htm: *L* libs/concept_check/doc/ Jamfile.v2: *C* *L* libs/concept_check/doc/reference/ Assignable.xml: *L* BidirectionalIterator.xml: *L* CopyConstructible.xml: *L* DefaultConstructible.xml: *L* EqualityComparable.xml: *L* ForwardIterator.xml: *L* InputIterator.xml: *L* LessThanComparable.xml: *L* OutputIterator.xml: *L* RandomAccessIterator.xml: *L* SignedInteger.xml: *L* concepts.xml: *L* libs/concept_check/ implementation.htm: *L* prog_with_concepts.htm: *L* reference.htm: *L* using_concept_check.htm: *L* |conversion| libs/conversion/ cast.htm: *L* index.html: *C* *L* lexical_cast.htm: *L* libs/conversion/test/ Jamfile.v2: *L* |doc| doc/html/ docutils.css: *L* |filesystem| libs/filesystem/doc/ tr2_proposal.html: *L* libs/filesystem/src/ utf8_codecvt_facet.hpp: *L* |function| boost/function/detail/ gen_maybe_include.pl: *L* |graph| libs/graph/doc/ lengauer_tarjan_dominator.htm: *L* |inspect| tools/inspect/build/ Jamfile.v2: *L* |integer| libs/integer/ cstdint.htm: *C* *L* libs/integer/doc/ integer_mask.html: *L* static_min_max.html: *L* libs/integer/ index.html: *C* *L* integer.htm: *L* integer_traits.html: *C* *L* |lambda| libs/lambda/doc/ Jamfile.v2: *C* *L* libs/lambda/doc/detail/ README: *C* *L* lambda_doc.xsl: *C* *L* lambda_doc_chunks.xsl: *C* *L* libs/lambda/test/ Makefile: *C* *L* |libs| libs/ expected_results.xml: *C* *L* maintainers.txt: *C* *L* platform_maintainers.txt: *C* *L* |logic| libs/logic/doc/ Jamfile.v2: *C* *L* |math| boost/math/ common_factor_rt.hpp: *L* |more| more/ error_handling.html: *L* generic_exception_safety.html: *C* *L* generic_programming.html: *L* getting_started.rst: *C* *L* moderators.html: *C* regression.html: *C* *L* report-apr-2006.html: *C* *L* report-jan-2006.html: *C* *L* |mpl| libs/mpl/doc/src/refmanual/ ASSERT.rst: *C* *L* ASSERT_MSG.rst: *C* *L* ASSERT_NOT.rst: *C* *L* ASSERT_RELATION.rst: *C* *L* AUX_LAMBDA_SUPPORT.rst: *C* *L* Acknowledgements.rst: *C* *L* Algorithms-Iteration.rst: *C* *L* Algorithms-Querying.rst: *C* *L* Algorithms-Runtime.rst: *C* *L* Algorithms-Transformation.rst: *C* *L* Algorithms.rst: *C* *L* AssociativeSequence.rst: *C* *L* BackExtensibleSequence.rst: *C* *L* BidirectionalIterator.rst: *C* *L* BidirectionalSequence.rst: *C* *L* CFG_NO_HAS_XXX.rst: *C* *L* CFG_NO_PREPROCESSED.rst: *C* *L* Categorized.rst: *C* *L* Data.rst: *C* *L* ExtensibleAssociativeSeq.rst: *C* *L* ExtensibleSequence.rst: *C* *L* ForwardIterator.rst: *C* *L* ForwardSequence.rst: *C* *L* FrontExtensibleSequence.rst: *C* *L* HAS_XXX_TRAIT_DEF.rst: *C* *L* HAS_XXX_TRAIT_NAMED_DEF.rst: *C* *L* Inserter.rst: *C* *L* IntegralConstant.rst: *C* *L* IntegralSequenceWrapper.rst: *C* *L* Iterators-Concepts.rst: *C* *L* Iterators-Metafunctions.rst: *C* *L* Iterators.rst: *C* *L* LIMIT_LIST_SIZE.rst: *C* *L* LIMIT_MAP_SIZE.rst: *C* *L* LIMIT_METAFUNCTION_ARITY.rst: *C* *L* LIMIT_SET_SIZE.rst: *C* *L* LIMIT_UNROLLING.rst: *C* *L* LIMIT_VECTOR_SIZE.rst: *C* *L* LambdaExpression.rst: *C* *L* Macros-Asserts.rst: *C* *L* Macros-Configuration.rst: *C* *L* Macros.rst: *C* *L* Metafunction.rst: *C* *L* MetafunctionClass.rst: *C* *L* Metafunctions-Arithmetic.rst: *C* *L* Metafunctions-Bitwise.rst: *C* *L* Metafunctions-Comparisons.rst: *C* *L* Metafunctions-Composition.rst: *C* *L* Metafunctions-Conditional.rst: *C* *L* Metafunctions-Invocation.rst: *C* *L* Metafunctions-Logical.rst: *C* *L* Metafunctions-Trivial.rst: *C* *L* Metafunctions-Type.rst: *C* *L* Metafunctions.rst: *C* *L* NumericMetafunction.rst: *C* *L* PlaceholderExpression.rst: *C* *L* Placeholders.rst: *C* *L* RandomAccessIterator.rst: *C* *L* RandomAccessSequence.rst: *C* *L* ReversibleAlgorithm.rst: *C* *L* Sequences-Classes.rst: *C* *L* Sequences-Concepts.rst: *C* *L* Sequences-Intrinsic.rst: *C* *L* Sequences-Views.rst: *C* *L* Sequences.rst: *C* *L* TagDispatchedMetafunction.rst: *C* *L* TrivialMetafunction.rst: *C* *L* VariadicSequence.rst: *C* *L* accumulate.rst: *C* *L* advance.rst: *C* *L* always.rst: *C* *L* and_.rst: *C* *L* apply.rst: *C* *L* apply_wrap.rst: *C* *L* arg.rst: *C* *L* at.rst: *C* *L* at_c.rst: *C* *L* back.rst: *C* *L* back_inserter.rst: *C* *L* begin.rst: *C* *L* bind.rst: *C* *L* bitand_.rst: *C* *L* bitor_.rst: *C* *L* bitxor_.rst: *C* *L* bool_.rst: *C* *L* clear.rst: *C* *L* contains.rst: *C* *L* copy.rst: *C* *L* copy_if.rst: *C* *L* count.rst: *C* *L* count_if.rst: *C* *L* deque.rst: *C* *L* deref.rst: *C* *L* distance.rst: *C* *L* divides.rst: *C* *L* empty.rst: *C* *L* empty_base.rst: *C* *L* empty_sequence.rst: *C* *L* end.rst: *C* *L* equal.rst: *C* *L* equal_to.rst: *C* *L* erase.rst: *C* *L* erase_key.rst: *C* *L* eval_if.rst: *C* *L* eval_if_c.rst: *C* *L* filter_view.rst: *C* *L* find.rst: *C* *L* find_if.rst: *C* *L* fold.rst: *C* *L* for_each.rst: *C* *L* front.rst: *C* *L* front_inserter.rst: *C* *L* greater.rst: *C* *L* greater_equal.rst: *C* *L* has_key.rst: *C* *L* identity.rst: *C* *L* if_.rst: *C* *L* if_c.rst: *C* *L* inherit.rst: *C* *L* inherit_linearly.rst: *C* *L* insert.rst: *C* *L* insert_range.rst: *C* *L* inserter_.rst: *C* *L* int_.rst: *C* *L* integral_c.rst: *C* *L* is_sequence.rst: *C* *L* iter_fold.rst: *C* *L* iter_fold_if.rst: *C* *L* iterator_category.rst: *C* *L* iterator_range.rst: *C* *L* joint_view.rst: *C* *L* key_type.rst: *C* *L* lambda.rst: *C* *L* less.rst: *C* *L* less_equal.rst: *C* *L* list.rst: *C* *L* list_c.rst: *C* *L* long_.rst: *C* *L* lower_bound.rst: *C* *L* map.rst: *C* *L* max.rst: *C* *L* max_element.rst: *C* *L* min.rst: *C* *L* min_element.rst: *C* *L* minus.rst: *C* *L* modulus.rst: *C* *L* multiplies.rst: *C* *L* negate.rst: *C* *L* next.rst: *C* *L* not_.rst: *C* *L* not_equal_to.rst: *C* *L* numeric_cast.rst: *C* *L* or_.rst: *C* *L* order.rst: *C* *L* pair.rst: *C* *L* partition.rst: *C* *L* plus.rst: *C* *L* pop_back.rst: *C* *L* pop_front.rst: *C* *L* preface.rst: *C* *L* prior.rst: *C* *L* protect.rst: *C* *L* push_back.rst: *C* *L* push_front.rst: *C* *L* quote.rst: *C* *L* range_c.rst: *C* *L* remove.rst: *C* *L* remove_if.rst: *C* *L* replace.rst: *C* *L* replace_if.rst: *C* *L* reverse.rst: *C* *L* reverse_copy.rst: *C* *L* reverse_copy_if.rst: *C* *L* reverse_fold.rst: *C* *L* reverse_iter_fold.rst: *C* *L* reverse_partition.rst: *C* *L* reverse_remove.rst: *C* *L* reverse_remove_if.rst: *C* *L* reverse_replace.rst: *C* *L* reverse_replace_if.rst: *C* *L* reverse_stable_partition.rst: *C* *L* reverse_transform.rst: *C* *L* reverse_unique.rst: *C* *L* sequence_tag.rst: *C* *L* set.rst: *C* *L* set_c.rst: *C* *L* shift_left.rst: *C* *L* shift_right.rst: *C* *L* single_view.rst: *C* *L* size.rst: *C* *L* size_t.rst: *C* *L* sizeof_.rst: *C* *L* sort.rst: *C* *L* stable_partition.rst: *C* *L* terminology.rst: *C* *L* times.rst: *C* *L* transform.rst: *C* *L* transform_view.rst: *C* *L* unique.rst: *C* *L* unpack_args.rst: *C* *L* upper_bound.rst: *C* *L* value_type.rst: *C* *L* vector.rst: *C* *L* vector_c.rst: *C* *L* void_.rst: *C* *L* zip_view.rst: *C* *L* libs/mpl/doc/ style.css: *L* libs/mpl/example/fsm/ README.txt: *C* *L* libs/mpl/test/ Jamfile.v2: *C* *L* |multi_array| libs/multi_array/doc/ iterator_categories.html: *C* *L* reference.html: *L* libs/multi_array/doc/xml/ MultiArray.xml: *C* *L* const_multi_array_ref.xml: *C* *L* multi_array.xml: *C* *L* multi_array_ref.xml: *C* *L* reference.xml: *L* libs/multi_array/test/ Jamfile.v2: *L* |numeric| boost/numeric/ublas/ banded.hpp: *L* blas.hpp: *L* boost/numeric/ublas/detail/ concepts.hpp: *L* config.hpp: *L* definitions.hpp: *L* documentation.hpp: *L* duff.hpp: *L* iterator.hpp: *L* matrix_assign.hpp: *L* raw.hpp: *L* temporary.hpp: *L* vector_assign.hpp: *L* boost/numeric/ublas/ exception.hpp: *L* expression_types.hpp: *L* functional.hpp: *L* fwd.hpp: *L* hermitian.hpp: *L* io.hpp: *L* lu.hpp: *L* matrix.hpp: *L* matrix_expression.hpp: *L* matrix_proxy.hpp: *L* matrix_sparse.hpp: *L* operation.hpp: *L* operation_blocked.hpp: *L* operation_sparse.hpp: *L* storage.hpp: *L* storage_sparse.hpp: *L* symmetric.hpp: *L* traits.hpp: *L* triangular.hpp: *L* vector.hpp: *L* vector_expression.hpp: *L* vector_of_vector.hpp: *L* vector_proxy.hpp: *L* vector_sparse.hpp: *L* libs/numeric/conversion/test/ Jamfile.v2: *C* *L* test_helpers.cpp: *C* test_helpers2.cpp: *C* test_helpers3.cpp: *C* traits_test.cpp: *C* udt_example_0.cpp: *C* udt_support_test.cpp: *C* libs/numeric/ublas/bench1/ bench1.cpp: *L* bench1.hpp: *L* bench11.cpp: *L* bench12.cpp: *L* bench13.cpp: *L* libs/numeric/ublas/bench2/ bench2.cpp: *L* bench2.hpp: *L* bench21.cpp: *L* bench22.cpp: *L* bench23.cpp: *L* libs/numeric/ublas/bench3/ bench3.cpp: *L* bench3.hpp: *L* bench31.cpp: *L* bench32.cpp: *L* bench33.cpp: *L* libs/numeric/ublas/bench4/ bench4.cpp: *L* bench41.cpp: *L* bench42.cpp: *L* bench43.cpp: *L* libs/numeric/ublas/doc/ Release_notes.txt: *C* *L* array_adaptor.htm: *C* *L* banded.htm: *L* blas.htm: *L* bounded_array.htm: *C* *L* container_concept.htm: *L* doxygen.css: *C* *L* expression_concept.htm: *L* hermitian.htm: *L* index.htm: *L* iterator_concept.htm: *L* matrix.htm: *L* matrix_expression.htm: *L* matrix_proxy.htm: *L* matrix_sparse.htm: *L* operations_overview.htm: *L* overview.htm: *L* products.htm: *L* range.htm: *C* *L* libs/numeric/ublas/doc/samples/ banded_adaptor.cpp: *L* banded_matrix.cpp: *L* bounded_array.cpp: *L* compressed_matrix.cpp: *L* compressed_vector.cpp: *L* coordinate_matrix.cpp: *L* coordinate_vector.cpp: *L* hermitian_adaptor.cpp: *L* hermitian_matrix.cpp: *L* identity_matrix.cpp: *L* map_array.cpp: *L* mapped_matrix.cpp: *L* mapped_vector.cpp: *L* matrix.cpp: *L* matrix_binary.cpp: *L* matrix_binary_scalar.cpp: *L* matrix_column.cpp: *L* matrix_column_project.cpp: *L* matrix_matrix_binary.cpp: *L* matrix_matrix_solve.cpp: *L* matrix_range.cpp: *L* matrix_range_project.cpp: *L* matrix_row.cpp: *L* matrix_row_project.cpp: *L* matrix_slice.cpp: *L* matrix_slice_project.cpp: *L* matrix_unary.cpp: *L* matrix_vector_binary.cpp: *L* matrix_vector_range.cpp: *L* matrix_vector_slice.cpp: *L* matrix_vector_solve.cpp: *L* range.cpp: *L* slice.cpp: *L* symmetric_adaptor.cpp: *L* symmetric_matrix.cpp: *L* triangular_adaptor.cpp: *L* triangular_matrix.cpp: *L* unbounded_array.cpp: *L* unit_vector.cpp: *L* vector.cpp: *L* vector_binary.cpp: *L* vector_binary_outer.cpp: *L* vector_binary_redux.cpp: *L* vector_binary_scalar.cpp: *L* vector_range.cpp: *L* vector_range_project.cpp: *L* vector_slice.cpp: *L* vector_slice_project.cpp: *L* vector_unary.cpp: *L* vector_unary_redux.cpp: *L* zero_matrix.cpp: *L* zero_vector.cpp: *L* libs/numeric/ublas/doc/ storage_concept.htm: *C* *L* storage_sparse.htm: *L* symmetric.htm: *L* triangular.htm: *L* types_overview.htm: *L* ublas.css: *C* *L* unbounded_array.htm: *C* *L* vector.htm: *L* vector_expression.htm: *L* vector_proxy.htm: *L* vector_sparse.htm: *L* libs/numeric/ublas/test/ README: *C* *L* concepts.cpp: *L* test1.cpp: *L* test1.hpp: *L* test11.cpp: *L* test12.cpp: *L* test13.cpp: *L* test2.cpp: *L* test2.hpp: *L* test21.cpp: *L* test22.cpp: *L* test23.cpp: *L* test3.cpp: *L* test3.hpp: *L* test31.cpp: *L* test32.cpp: *L* test33.cpp: *L* test4.cpp: *L* test4.hpp: *L* test42.cpp: *L* test43.cpp: *L* test5.cpp: *L* test5.hpp: *L* test52.cpp: *L* test53.cpp: *L* test6.cpp: *L* test6.hpp: *L* test62.cpp: *L* test63.cpp: *L* test7.cpp: *L* test7.hpp: *L* test71.cpp: *L* test72.cpp: *L* test73.cpp: *L* |optional| libs/optional/test/ Jamfile.v2: *L* |people| people/ paul_moore.htm: *C* *L* vesa_karvonen.htm: *C* *L* |program_options| boost/program_options/detail/ utf8_codecvt_facet.hpp: *L* libs/program_options/build/ Jamfile.v2: *C* *L* libs/program_options/doc/ Jamfile.v2: *C* *L* acknowledgements.xml: *C* *L* changes.xml: *C* *L* design.xml: *C* *L* glossary.xml: *C* *L* howto.xml: *C* *L* overview.xml: *C* *L* post_review_plan.txt: *C* *L* todo.txt: *C* *L* tutorial.xml: *C* *L* libs/program_options/example/ Jamfile.v2: *C* *L* libs/program_options/test/ Jamfile.v2: *C* *L* program_options_size_test.py: *C* *L* ucs2.txt: *C* *L* utf8.txt: *C* *L* winmain.py: *C* *L* |property_map| libs/property_map/ LvaluePropertyMap.html: *L* ReadWritePropertyMap.html: *L* ReadablePropertyMap.html: *L* WritablePropertyMap.html: *L* associative_property_map.html: *L* const_assoc_property_map.html: *L* libs/property_map/doc/ dynamic_property_map.html: *C* *L* dynamic_property_map.rst: *C* *L* libs/property_map/ example2.cpp: *L* identity_property_map.html: *L* iterator_property_map.html: *L* property_map.html: *L* vector_property_map.html: *L* |ptr_container| libs/ptr_container/doc/ default.css: *L* intro.xml: *C* *L* ptr_container.xml: *L* libs/ptr_container/test/ Jamfile.v2: *C* *L* sequence_point.cpp: *C* *L* |python| libs/python/doc/ internals.html: *L* internals.rst: *L* libs/python/doc/tutorial/doc/html/python/ embedding.html: *L* exception.html: *L* exposing.html: *L* functions.html: *L* hello.html: *L* iterators.html: *L* object.html: *L* techniques.html: *L* libs/python/test/ operators_wrapper.cpp: *C* *L* operators_wrapper.py: *C* *L* |rational| boost/ rational.hpp: *L* libs/rational/ index.html: *L* rational.html: *L* rational_example.cpp: *L* rational_test.cpp: *L* |regex| libs/regex/build/ gcc-shared.mak: *C* *L* libs/regex/example/timer/ input_script.txt: *C* *L* |regression| tools/regression/build/ Jamfile.v2: *C* *L* tools/regression/detail/ tiny_xml_test.txt: *C* *L* tools/regression/ index.htm: *C* *L* run_tests.sh: *C* *L* tools/regression/test/test-cases/general/expected/ results.xml: *C* *L* tools/regression/test/test-cases/incremental/expected/ results.xml: *C* *L* tools/regression/test/ test.bat: *C* *L* tools/regression/xsl_reports/ boostbook_report.py: *C* *L* tools/regression/xsl_reports/db/ load.py: *C* *L* test-runs.xsd: *C* *L* tools/regression/xsl_reports/ empty_expected_results.xml: *C* *L* tools/regression/xsl_reports/runner/ __init__.py: *C* *L* default.css: *L* instructions.html: *L* instructions.rst: *C* *L* tools/regression/xsl_reports/test/ common.py: *C* *L* expected_results.xml: *C* *L* generate_test_results.py: *C* *L* generate_test_results_v1.py: *C* *L* restrict_to_library.xsl: *C* *L* run_notes_regression.py: *C* *L* run_v1.py: *C* *L* tools/regression/xsl_reports/test/test-components/ test.py: *C* *L* tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/ compile-fail.xml: *C* *L* completed.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/ compile-fail.xml: *C* *L* completed.xml: *C* *L* lib.xml: *C* *L* misfire.xml: *C* *L* no-run.xml: *C* *L* run_pyd.xml: *C* *L* test-case.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/ lib.xml: *L* misfire.xml: *C* *L* no-run.xml: *C* *L* run_pyd.xml: *C* *L* test-case.xml: *L* test-driver.xsl: *C* *L* tools/regression/xsl_reports/test/test-components/test_re_match/expected/ test_re_match.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_case_status/ a.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_case_status/expected/ a.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_case_status/ test-driver.xsl: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_structure/ a.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_structure/expected/ a.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_structure/ test-driver.xsl: *C* *L* tools/regression/xsl_reports/test/ test.py: *C* *L* test_boost_wide_report.py: *C* *L* tools/regression/xsl_reports/ test_results.xsd: *C* *L* tools/regression/xsl_reports/utils/ __init__.py: *C* *L* accept_args.py: *C* *L* char_translation_table.py: *C* *L* check_existance.py: *C* *L* checked_system.py: *C* *L* libxslt.py: *C* *L* log.py: *C* *L* makedirs.py: *C* *L* send_mail.py: *C* *L* sourceforge.py: *C* *L* tar.py: *C* *L* zip.py: *C* *L* tools/regression/xsl_reports/xsl/v2/ expected_to_1_33_format.xsl: *C* *L* |release| tools/release/ utils.py: *C* *L* |serialization| libs/serialization/doc/ style.css: *C* *L* libs/serialization/example/ demo_output.txt: *C* *L* demo_save.xml: *C* *L* demofile.txt: *C* *L* libs/serialization/test/ run_archive_test.bat: *C* *L* runtest.bat: *C* *L* runtest.sh: *C* *L* libs/serialization/vc7ide/ readme.txt: *C* *L* |signals| libs/signals/doc/ tutorial.xml: *C* *L* |smart_ptr| libs/smart_ptr/ compatibility.htm: *L* scoped_array.htm: *L* scoped_ptr.htm: *L* shared_array.htm: *L* shared_ptr.htm: *L* smart_ptr.htm: *L* smarttests.htm: *L* weak_ptr.htm: *L* |test| boost/test/utils/runtime/cla/detail/ argument_value_usage.hpp: *L* libs/test/test/auto-link-test/ run_bjam.bat: *C* *L* |timer| libs/timer/ timer.htm: *L* |tr1| boost/tr1/ tuple.hpp: *C* *L* |tuple| libs/tuple/doc/ design_decisions_rationale.html: *L* tuple_advanced_interface.html: *L* tuple_users_guide.html: *L* libs/tuple/test/ README: *C* *L* |utility| boost/ shared_container_iterator.hpp: *L* libs/utility/ OptionalPointee.html: *L* call_traits.htm: *L* compressed_pair.htm: *L* enable_if.html: *L* libs/utility/test/ Jamfile.v2: *L* libs/utility/ utility.htm: *L* value_init.htm: *L* value_init_test.cpp: *C* value_init_test_fail1.cpp: *C* value_init_test_fail2.cpp: *C* value_init_test_fail3.cpp: *C* |variant| libs/variant/doc/ Jamfile.v2: *C* *L* biblio.xml: *C* *L* design.xml: *C* *L* introduction.xml: *C* *L* misc.xml: *C* *L* libs/variant/doc/reference/ apply_visitor.xml: *C* *L* bad_visit.xml: *C* *L* concepts.xml: *C* *L* get.xml: *C* *L* recursive_variant.xml: *C* *L* recursive_wrapper.xml: *C* *L* reference.xml: *C* *L* static_visitor.xml: *C* *L* variant.xml: *C* *L* variant_fwd.xml: *C* *L* visitor_ptr.xml: *C* *L* libs/variant/doc/tutorial/ advanced.xml: *C* *L* basic.xml: *C* *L* tutorial.xml: *C* *L* libs/variant/doc/ variant.xml: *L* libs/variant/ index.html: *C* *L* libs/variant/test/ Jamfile.v2: *L*

1 0

Boost inspection notification (2007-05-31/RC_1_34_0) *X*
by Rene Rivera 31 May '07

31 May '07

Boost Inspection Report Run Date: 16:09:25 UTC, Thursday 31 May 2007 An inspection program <http://www.boost.org/tools/inspect/index.html> checks each file in the current Boost CVS for various problems, generating this as output. Problems detected include tabs in files, missing copyrights, broken URL's, and similar misdemeanors. Totals: 11453 files scanned 909 directories scanned (including root) 193 problems reported Problem counts: 0 files with invalid line endings 0 bookmarks with invalid characters 3 invalid urls 101 broken links 21 unlinked files 22 file/directory names issues 2 files with tabs 9 violations of the Boost min/max guidelines 35 usages of unnamed namespaces in headers (including .ipp files) Summary: archive (3) bind (1) boost-root (1) build (1) date_time (1) doc (2) filesystem (33) graph (3) iostreams (2) lambda (3) math (8) more (4) mpl (4) multi_array (2) ptr_container (1) python (8) regex (1) regression (32) serialization (1) test (81) type_traits (1) Details: *R* invalid (cr only) line-ending *A* invalid bookmarks, invalid urls, broken links, unlinked files *N* file/directory names issues *T* tabs in file *M* uses of min or max that have not been protected from the min/max macros, or unallowed #undef-s *U* unnamed namespace in header |archive| boost/archive/basic_streambuf_locale_saver.hpp: *N* name exceeds 31 characters boost/archive/impl/xml_wiarchive_impl.ipp: *U* unnamed namespace at line 53 boost/archive/iterators/remove_whitespace.hpp: *U* unnamed namespace at line 57 |bind| boost/bind/placeholders.hpp: *U* unnamed namespace at line 25 |boost-root| index.htm: *A* broken link: doc/hmtl/date_time/details.html#changes |build| tools/build/v2/test/test_system.html: *A* unlinked file |date_time| libs/date_time/xmldoc/date_time_docs_howto.html: *A* unlinked file |doc| doc/html/boost_math/inverse_complex.html: *A* unlinked file doc/html/jam.html: *A* unlinked file |filesystem| libs/filesystem/doc/do-list.htm: *A* invalid URL (hardwired file): file://?/ *A* invalid URL (hardwired file): file://?/UNC/ libs/filesystem/doc/i18n.html: *A* broken link: convenience.htm#basic_recursive_directory_iterator *A* broken link: exception.htm *A* broken link: operations.htm *A* broken link: operations.htm#Do-the-right-thing *A* broken link: operations.htm#is_directory *A* broken link: operations.htm#is_file *A* broken link: operations.htm#status libs/filesystem/doc/index.htm: *A* broken link: ../build/Jamfile *A* broken link: convenience.htm *A* broken link: operations.htm#create_directory *A* broken link: operations.htm#create_hard_link *A* broken link: operations.htm#current_path *A* broken link: operations.htm#equivalent *A* broken link: operations.htm#file_size *A* broken link: operations.htm#initial_path *A* broken link: operations.htm#is_file *A* broken link: operations.htm#is_symlink *A* broken link: operations.htm#status *A* broken link: operations.htm#symlink_status *A* broken link: path.htm#Canonical *A* broken link: path.htm#Normalized *A* broken link: path.htm#default_name_check *A* broken link: path.htm#name_check_mechanism *A* broken link: path.htm#normalize *A* broken link: path.htm#operator_eq libs/filesystem/doc/portability_guide.htm: *A* broken link: path.htm#name_check_typedef libs/filesystem/doc/tr2_proposal.html: *A* invalid URL (hardwired file): file:///C|/boost/site/libs/filesystem/doc/operations.htm#complete_note |graph| boost/graph/relax.hpp: *T* libs/graph/example/file_dependencies.cpp: *M* violation of Boost min/max guidelines on line 139 libs/graph/test/serialize.cpp: *T* |iostreams| libs/iostreams/doc/concepts/multi-character.html: *A* unlinked file libs/iostreams/doc/installation.html: *A* broken link: ../../../tools/build/v1/build_system.htm |lambda| boost/lambda/core.hpp: *U* unnamed namespace at line 62 boost/lambda/detail/lambda_functors.hpp: *U* unnamed namespace at line 25 boost/lambda/exceptions.hpp: *U* unnamed namespace at line 24 |math| libs/math/test/common_factor_test.cpp: *M* violation of Boost min/max guidelines on line 146 *M* violation of Boost min/max guidelines on line 147 *M* violation of Boost min/max guidelines on line 193 *M* violation of Boost min/max guidelines on line 194 |more| more/cvs.html: *A* unlinked file more/getting_started/unix-variants.html: *A* broken link: ../../doc/html/thread/build.html#thread.build more/getting_started/windows.html: *A* broken link: ../../doc/html/thread/build.html#thread.build more/separate_compilation.html: *A* broken link: ../libs/config/test/link/test/Jamfile.v2 |mpl| boost/mpl/alias.hpp: *U* unnamed namespace at line 17 libs/mpl/doc/refmanual/for-each.html: *A* broken link: ./value-initialized.html |multi_array| boost/multi_array/base.hpp: *U* unnamed namespace at line 69 libs/multi_array/test/generative_tests.hpp: *U* unnamed namespace at line 57 |ptr_container| libs/ptr_container/doc/tutorial_example.html: *A* unlinked file |python| libs/python/doc/building.html: *A* broken link: ../index.htm libs/python/doc/tutorial/doc/html/python/hello.html: *A* broken link: ../../../../../example/tutorial/Jamrules libs/python/doc/tutorial/index.html: *A* broken link: ../../../LICENSE_1_0.txt libs/python/doc/v2/May2002.html: *A* broken link: ../../../../tools/build/v1/build_system.htm *A* broken link: ../../../../tools/build/v1/gen_aix_import_file.py libs/python/doc/v2/faq.html: *A* broken link: ../../../../tools/build/v1/build_system.htm |regex| libs/regex/performance/input.html: *A* unlinked file |regression| regression/.htaccess: *N* leading character of ".htaccess" is not alphabetic tools/regression/test/test-cases/incremental/bjam.log.1: *N* name contains more than one dot character ('.') tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/compile-fail.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/completed.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/compile-fail.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/completed.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/lib.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/misfire.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/no-run.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/run_pyd.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/test-case.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/test-case.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/test-driver.xsl: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_re_match/expected/test_re_match.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_test_case_status/explicit-failures-markup.xml.test: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ *N* name contains more than one dot character ('.') *N* name exceeds 31 characters tools/regression/xsl_reports/test/test-components/test_test_structure/explicit-failures-markup.xml.test: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ *N* name contains more than one dot character ('.') *N* name exceeds 31 characters tools/regression/xsl_reports/xsl/html/issues_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/library_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/library_user_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/make_tinyurl.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/summary_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/summary_user_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/issues_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/library_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/library_user_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/make_tinyurl.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/summary_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/summary_user_legend.html: *A* unlinked file |serialization| libs/serialization/src/basic_xml_grammar.ipp: *U* unnamed namespace at line 43 |test| boost/test/floating_point_comparison.hpp: *U* unnamed namespace at line 206 *U* unnamed namespace at line 228 boost/test/impl/cpp_main.ipp: *U* unnamed namespace at line 42 boost/test/impl/exception_safety.ipp: *U* unnamed namespace at line 400 boost/test/impl/framework.ipp: *U* unnamed namespace at line 199 boost/test/impl/plain_report_formatter.ipp: *U* unnamed namespace at line 45 boost/test/impl/progress_monitor.ipp: *U* unnamed namespace at line 38 boost/test/impl/results_collector.ipp: *U* unnamed namespace at line 106 boost/test/impl/results_reporter.ipp: *U* unnamed namespace at line 48 boost/test/impl/unit_test_log.ipp: *U* unnamed namespace at line 79 boost/test/impl/unit_test_monitor.ipp: *U* unnamed namespace at line 35 boost/test/impl/unit_test_parameters.ipp: *U* unnamed namespace at line 50 boost/test/results_collector.hpp: *U* unnamed namespace at line 40 boost/test/test_tools.hpp: *U* unnamed namespace at line 262 boost/test/utils/iterator/token_iterator.hpp: *U* unnamed namespace at line 166 boost/test/utils/named_params.hpp: *U* unnamed namespace at line 216 boost/test/utils/runtime/cla/dual_name_parameter.ipp: *U* unnamed namespace at line 43 boost/test/utils/runtime/cla/modifier.hpp: *U* unnamed namespace at line 34 boost/test/utils/runtime/env/modifier.hpp: *U* unnamed namespace at line 34 boost/test/utils/runtime/file/config_file.hpp: *U* unnamed namespace at line 169 *U* unnamed namespace at line 64 *U* unnamed namespace at line 74 boost/test/utils/runtime/file/config_file_iterator.hpp: *U* unnamed namespace at line 68 boost/test/utils/trivial_singleton.hpp: *U* unnamed namespace at line 52 *U* unnamed namespace at line 61 libs/test/build/msvc71_proj/config_file_iterator_test.vcproj: *N* name exceeds 31 characters libs/test/doc/components/prg_exec_monitor/compilation.html: *A* broken link: ../../../build/Jamfile libs/test/doc/components/prg_exec_monitor/index.html: *A* broken link: ../../../../../boost/test/cpp_main.hpp libs/test/doc/components/test_tools/index.html: *A* broken link: ../../tests/boost_check_equal_str.html libs/test/doc/components/test_tools/reference/BOOST_CHECK_CLOSE.html: *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html libs/test/doc/components/test_tools/reference/BOOST_CHECK_MESSAGE.html: *A* broken link: BOOST_MESSAGE.html libs/test/doc/components/test_tools/reference/BOOST_CHECK_SMALL.html: *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html libs/test/doc/components/test_tools/reference/tools_list.html: *A* broken link: ../../btl1.gif *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html libs/test/doc/components/utf/compilation.html: *A* broken link: ../../../build/Jamfile libs/test/doc/components/utf/components/index.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/components/test_case/abstract_interface.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/auto_register_facility.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/boost_function_tc.html: *A* broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/class_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/function_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/param_boost_function_tc.html: *A* broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/param_class_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/param_function_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/tc_template.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_log/custom_log_formatter.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_log/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_result/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_suite/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/index.html: *A* broken link: getting_started/index.html libs/test/doc/components/utf/parameters/build_info.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/catch_system_errors.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/detect_memory_leaks.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/index.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/log_format.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/log_level.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/no_result_code.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/output_format.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/random.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/report_format.html: *A* broken link: ../../../../../LICENSE_1_0.txt *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/report_level.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/show_progress.html: *A* broken link: ../../btl1.gif libs/test/doc/examples/unit_test_example1.html: *A* broken link: ../../example/unit_test_example1.cpp libs/test/doc/examples/unit_test_example2.html: *A* broken link: ../../example/unit_test_example2.cpp libs/test/doc/examples/unit_test_example3.html: *A* broken link: ../../example/unit_test_example3.cpp libs/test/doc/examples/unit_test_example4.html: *A* broken link: ../../example/unit_test_example4.cpp libs/test/doc/examples/unit_test_example5.html: *A* broken link: ../../example/unit_test_example5.cpp *A* broken link: ../../example/unit_test_example5.input libs/test/doc/tests/auto_unit_test_test.html: *A* broken link: ../../test/auto_unit_test_test.cpp libs/test/doc/tests/auto_unit_test_test_mult.html: *A* broken link: ../../test/auto_unit_test_test_mult1.cpp *A* broken link: ../../test/auto_unit_test_test_mult2.cpp libs/test/doc/tests/unit_test_suite_ex_test.html: *A* broken link: ../../test/unit_test_suite_ex_test.cpp libs/test/doc/tutorials/hello_the_testing_world.html: *A* broken link: ../../../../../LICENSE_1_0.txt *A* broken link: ../execution_monitor/index.html libs/test/doc/tutorials/new_year_resolution.html: *A* broken link: ../../../../../../LICENSE_1_0.txt |type_traits| libs/type_traits/cxx_type_traits.htm: *A* unlinked file

1 0

[proto]are there 2 ways to define generators?
by Larry Evans 31 May '07

31 May '07

In: html/boost_proto/user_s_guide/extending_proto.html there's: <--------- cut here ----------- namespace boost { namespace proto { // A specialization of generate<> that causes expression in the // calculator_domain to be wrapped in the calculator<> wrapper. template< typename Expr > struct generate< calculator_domain, Expr > { typedef calculator< Expr > type; static type make( Expr const & expr ) { return type( expr ); } }; }} This instructs Proto to wrap all expressions in the calculator_domain in the calculator<> wrapper. >--------- cut here ----------- OTOH, in: libs/xpressive/proto/example/calc3.cpp there's: <--------- cut here ----------- // Tell proto how to generate expressions in the calculator_domain struct calculator_domain : proto::domain<proto::generator<calculator_expression> > {}; >--------- cut here ----------- which suggests to me that there's 2 different ways to wrap expressions in a particular domain. Is that right? If so, what are the advantages of one over the other method?

2 1

[preprocessor] repeating expressions containing multiple macros
by Stjepan Rajko 31 May '07

31 May '07

Hello, I would like to propose an extension to the Preprocessor library, based on the REPEAT, ENUM etc. family of macros, e.g., BOOST_PP_REPEAT(count, macro, data) macro which expands to: macro(z, 0, data) macro(z, 1, data) ... macro(z, count - 1, data) In working on the RPC and Signal Network libraries, I found useful being able to iterate over multiple macros simultaneously. This could be provided by a set of macros BOOST_PP_REPEAT_(C|M|MA)+ where C stands for Constant, M for Macro, and MA for Macro+Argument. For example, BOOST_PP_REPEAT_CMAMC(count, cons, macro, arg, macro2, cons2) expands to (linebreaks inserted for readability): cons macro(z, 0, arg) macro2(z, 0, BOOST_PP_EMPTY()) cons2 cons macro(z, 1, arg) macro2(z, 1, BOOST_PP_EMPTY()) cons2 ... cons macro(z, count-1, arg) macro2(z, count-1, BOOST_PP_EMPTY()) cons2 This particular macro would be implemented as #define BOOST_PP_CMAMC_MACRO(z, n, args) \ BOOST_PP_TUPLE_ELEM(5, 0, args) \ BOOST_PP_TUPLE_ELEM(5, 1, args)(z,n,BOOST_PP_TUPLE_ELEM(5, 2, args)) \ BOOST_PP_TUPLE_ELEM(5, 3, args)(z,n,BOOST_PP_EMPTY()) \ BOOST_PP_TUPLE_ELEM(5, 4, args) #define BOOST_PP_REPEAT_CMAMC(count, c1, m2, a3, m4, c5) \ BOOST_PP_REPEAT(count, BOOST_PP_CMAMC_MACRO, (c1, m2, a3, m4, c5)) As a usage example, I am finding such expansions useful in developing classes / functions in which an integer template parameter determines the number of arguments to a function/method and/or the number of local/class variables (for example, when the function signature is determined by a signature provided as a template parameter, and the function needs a local variable for each parameter). In this case, I iterate over the a template implementation using BOOST_PP_ITERATE and have a set of macros equivalent to the ones above, except they hard-code the count to BOOST_PP_ITERATION() (they are called BOOST_ARITY_* instead of BOOST_PP_*). Take as an example a function "serialize" which is templated on a function Signature, where the arguments of the function are specified by the signature. For example, std::string serialized_params; serialized_params = serialize<void(int, float, std::string)>(1, 2.5, "serialize this"); The above macros make the following implementation a little more readable than other alternatives I've come accross (what follows is adapted from working code and untested): --- first some prep work, so we have macros to iterate over: // define names a1, a2, ... #define ARITY_aN_NAME(z,n,data) \ BOOST_PP_CAT(a,BOOST_PP_INC(n)) // define names arg1_type, arg2_type, ...: #define ARITY_argN_type_NAME(z,n,data) \ BOOST_PP_CAT(BOOST_PP_CAT(arg,BOOST_PP_INC(n)),_type) // define a way to get to the type of an argument, given the signature: #define ARITY_function_traits_argN_type_NAME(z,n,signature) \ typename boost::function_traits<signature>:: \ ARITY_argN_type_NAME(z,n,BOOST_PP_EMPTY()) // just some shortcuts: #define BOOST_ARITY_ENUM_MAM(m1, a2, m3) \ BOOST_PP_ENUM_MAM(BOOST_PP_ITERATION(), m1, m2, m3) #define BOOST_ARITY_REPEAT_CMC(c1, m2, c3) \ BOOST_PP_REPEAT_CMC(BOOST_PP_ITERATION(), c1, m2, c3) ---- the following part is iterated over using BOOST_PP_ITERATE: // define a function which serializes its arguments, and the // number and type of arguments is specified by a template param: template<typename Signature> // retuns a string typename boost::enable_if_c<boost::function_traits<Signature>::arity ==BOOST_PP_ITERATION(), std::string>::type // the list of arguments is expanded through the macros: // (typename boost::function_traits<Signature>::arg1_type a1, // typename boost::function_traits<Signature>::arg2_type a2, ...) serialize(BOOST_ARITY_ENUM_MAM(ARITY_function_traits_argN_type_NAME, Signature, ARITY_aN_NAME)) { std::stringstream stream(std::ios::in | std::ios::out | std::ios::binary); boost::archive::binary_oarchive archive(stream); // archive & a1; archive & a2; ... BOOST_ARITY_REPEAT_CMC(archive &, ARITY_aN_NAME, ;) return stream.str(); } --- The BOOST_ARITY_* macros above are easily implemented using BOOST_PP_* macros, and are just one usage example. Macros of the type BOOST_PP_REPEAT_(C|M|MA)+ could probably have other applications as well. If there isn't functionality which already covers this, would there be any interest in adding the BOOST_PP_REPEAT_(C|M|MA)+ etc. macros to the preprocessor library? If so, I could write up a python script which would generate the macros for up to a reasonable number of arguments (e.g., four C, M, or MAs which would lead to 3^4 base macros plus the same number of BOOST_PP_REPEAT_*, BOOST_PP_EVAL_*, and any other macros that should be included). Regards, Stjepan

1 1

[Report] 3 regressions on RC_1_34_0 (2007-05-31)
by Douglas Gregor 31 May '07

31 May '07

Boost Regression test failures Report time: 2007-05-31T04:00:33Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 3 failures in 2 libraries graph (2) spirit (1) |graph| graphviz_test: gcc-cygwin-3.4.4 gursoy_atun_layout_test: gcc-cygwin-3.4.4 |spirit| owi_mt_tests: gcc-cygwin-3.4.4

1 0

Defect in tools/common/time_string.hpp
by Gennaro Prota 31 May '07

31 May '07

{ Last attempt to sent this: I mailed Beman, than Rene, to no avail; then, I re-subscribed to the list, went to all the confirm-that-you-exist hassle and posted, but still the message didn't appear. Sorry but I don't know what else to do. } On Sat, 26 May 2007 13:33:14 +0200, Gennaro Prota wrote: >Hi Rene, > >I sent this to Beman a while ago but he's likely too busy with >standardization: I noticed a bug in >boost/tools/common/time_string.hpp; I copied the default argument "%X >UTC, %A %d %B %Y" from the original code by him and you can see for >yourself that "UTC" in there is quite wrong. Incredibly, this problem >has been there since the beginning, and I was so stupid as to not >check the string myself. -- Genny -- Gennaro Prota -- C++ Developer, For Hire https://sourceforge.net/projects/breeze/

1 1

Any libraries now not under the Boost Software License?
by David Abrahams 31 May '07

31 May '07

http://boost.org/more/license_info.html says: Currently, some Boost libraries have their own licenses. The hope is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ that eventually all Boost libraries will be covered by the Boost Software License. In the meantime, all libraries comply with the Boost License requirements. Is that still true now that we have Threads under the BSL? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

11 24

Interest from BoostCon
by Preston A. Elder 31 May '07

31 May '07

Hey, There was some interest in some code I had written a long time ago expressed at BoostCon - I believe I linked this before, but the location has changed. Specifically these are libraries inside of Mantra. These have not been modified in 2 years, so I wanted to know if there was any interest in them (and as such cause for me to update and submit them). If nobody is interested in them I will probably drop them, if people are interested I can look into cleaning them up and submitting. - boost::unformat - a logical reversal of boost::format (ie. scanf for boost::format): http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra… Right now this only unformats into strings, and is not extensively tested, but it DOES work. If there is interest I will enhance it to unformat int a tuple, or something else (suggestions)? - Intrusive Tracing - the ability to activate various levels/styles of code-based tracing at runtime, and by logical code 'section'. http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra… and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/core/trace… It uses macros - and I would like to expand it to more and better tracing capabilities, but what is there works and is VERY convenient. It even supports a 'transactional' mode of tracing, to avoid trace cross-talk. Tracing can be completely compiled away for production code. - Extension to program_options to allow for more robust checking of provided values. http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra… Some of this functionality has been put into program_options, but not as nice as I'd like it (at least last I looked at it). This allows you to do things like validate the value provided (must match this regex, must fall within this range, must pass this check function). It also allows for more advanced things like value mapping (user uses value of 'INFO', which gets mapped to the enum LogLevel_t::INFO or whatever). It also allows 'chained' checks. This is probably showing its age though, there have been certain enhancements to program_options that makes some of the stuff here unnecessary. - Date/Time and Duration formatting (both to and from) functions: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra… These were written before the date/time facets - but they are still useful. - Guarenteed event mechanism: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra… and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/service/ev… This handles its own thread pool (ie. minimum number of standby threads), and operates in such a way that it will guarentee an event is started EXACTLY when you want it, even if it has to spawn a new thread to do so. - In-process watchdog: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra… and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/service/wa… Relatively simple, but saves everyone else writing one :) - Various dispatching methodologies: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra… http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra… http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra… http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra… These are message queues for different purposes. Each (except OTS) is backed by a thread pool that can resize based on high/low water marks. * MessageQueue - Single queue for a pool of threads. * ITS_MessageQueue - Implements a 'queue per thread' (with a 'transport' thread) to reduce lock contention by delivering messages to a worker thread for processing in bulk (includes 'fair' queueing). * Routed_MessageQueue - Adds a key to the message, guarenteeing that only one thread can process messages for a single key at any one time. - OTS_MessageQueue - Reverses ITS_MessageQueue, made for the 'other' side, ie. multiple threads sending data to a single thread (eg. a store and forward thread or something). In this case it only has a single thread (plus a collector), and has a queue per thread that PUSH's onto it instead. - Networking Stuff: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra… and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/net Written before ASIO was accepted - probably not required anymore, but it IS a simpler approach (ie. 3 classes, thats it). Supports select, poll and epoll. - Generic Data Storage Backend: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra… and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/storage This allows you to have a common interface to your storage back end, regardless of whether its an SQL database, Berkeley DB, XML file, etc. It also allows you to CODE a query, eg: Condition<C_LessThan>("col1", 3") && (Condition<C_EqualTo>("col2", "hello") || Condition<C_EqualTo>("col2", "world")) && Condition<C_Masked>("col3", FLAG_A | FLAG_B) This will then expand to an SQL expression for SQL DB's, or apply to data rows for non-SQL DB's - ie. it will work for all data sources. Right now I plan on re-writing this anyway to support: * Cross-table/database queries, better column limits and more operations: (http://www.neuromancy.net/mantra/trac/ticket/1) * Transactions & Cursors (http://www.neuromancy.net/mantra/trac/ticket/2) * An Object-based model (http://www.neuromancy.net/mantra/trac/ticket/3) But I would like to know if there is interest for this in the boost community or more specifically, in turning it into a boost module in its own right. - Store and Forward and Disk-Overflow: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra… and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/file/saf.c… and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra… and http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/src/file/fileb… The SAF mechanism is there to implement guarenteed delivery of data, even if your application crashes. The FileBuffer provides disk-based overflow for memory-constrained situations (eg. where you have a socket, and you can get massive bursts of data to go out the socket, but cannot send it as fast as the burst - especially where you have thousands of such bursty connections). - Python bindings for some boost libraries: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/python/boost Right now I have bindings for boost::format, date_time and tribool. There was interest in these but nowhere to put them. In addition they need updating (especially date_time). I also plan on re-writing my Logging library: http://www.neuromancy.net/mantra/trac/browser/trunk/Mantra-I/include/mantra… to be MUCH more efficient and flexible with regards to adding new logging back ends and formatting (http://www.neuromancy.net/mantra/trac/ticket/4) Sorry for the length of this post. Please let me know if you think some of these things would look good with a boost:: prefix :) PreZ :) BTW - I enjoyed BoostCon immensely, thanks again to the organizers and I enjoyed meeting many of you. This is an email you can contact me at :)

6 9

[uuid] - error in function operator>>()
by Oliver.Kowalke＠qimonda.com 31 May '07

31 May '07

Hello, I get following error from uuid v8 library: /opt/boost/include/boost-1_34/boost/uuid.hpp:209: instantiated from void boost::uuid::construct(const std::basic_string<_CharT, _Traits, _Alloc>&) [with ch = char, char_traits = std::char_traits<char>, alloc = std::allocator<char>] /opt/boost/include/boost-1_34/boost/uuid.hpp:76: instantiated from here /opt/boost/include/boost-1_34/boost/uuid.hpp:468: Fehler: keine passende Funktion fr Aufruf von find(char [16], char* const&, char&) // means: function not found Oliver

1 0

lexical_cast error with double?
by Preston A. Elder 31 May '07

31 May '07

This may have been posted before, but I did not see it or the solution. This code: double d = 72.35 std::string = boost::lexical_cast<std::string>(d); Results in the string 72.3499999999999999999 However printf("%f\n", d); Results in 72.350000 Any reason for this - or more importantly, any way to fix it and prevent it happening again? PreZ :)

1 0

[assign] ptr_list_of legal?
by shunsuke 31 May '07

31 May '07

Hi, I found a snippet from <boost/assign/ptr_list_of.hpp>: template< class T > class generic_ptr_list { // ... public: template< class PtrContainer > operator std::auto_ptr<PtrContainer>() const { .. } }; IIRC, this automatic conversion doesn't work on any conforming compiler. The right way seems to make lvalue: 'operator std::auto_ptr<PtrContainer> & () const'. Regards, -- Shunsuke Sogame

2 4

Boost sandbox and Boost vault
by Edward Diener 31 May '07

31 May '07

I am confused by the use of the Boost sandbox and by the use of the Boost vault for uploading code in which others might be interested. What is the difference between these two ? Would it not be better to have a single area in which new code is uploaded ?

5 7

javascript in docs
by Gennadiy Rozental 31 May '07

31 May '07

How much javascript are we allowed in docs these days? It seems that Javascript started to appear here and there. Is there general guidelines on what is allowed? Gennadiy

6 8

Boost Soc 2006 and SubVersion
by Shams 31 May '07

31 May '07

Hi, Is there any chance of moving the SoC 2006 projects from: https://boost-consulting.com/trac/soc/browser/boost/soc https://boost-consulting.com/trac/soc/browser/boost/soc/2006 to the new SubVersion sandbox here: http://svn.boost.org/trac/boost/browser/sandbox/ Just like SoC 2007 Thanks Shams --

2 1