- Boost - lists.preview.boost.org

[graph] fails to complile on Cygwin
by Bernd Prager 27 Jul '12

27 Jul '12

Hi, I'm having trouble compiling Boost 1.51 on Cygwin 1.7.15, g++ (GCC) 4.5.3. It fails with: gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi/read_graphviz_new.o In file included from ./boost/proto/transform/when.hpp:25:0, from ./boost/proto/matches.hpp:43, from ./boost/proto/core.hpp:22, from ./boost/xpressive/regex_primitives.hpp:28, from ./boost/xpressive/xpressive_static.hpp:24, from ./boost/graph/graphviz.hpp:34, from libs\graph\src\read_graphviz_new.cpp:50: ./boost/proto/transform/env.hpp: In member function ‘boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::result_type boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::operator()(boost::proto::detail::arg<T>) const’: ./boost/proto/transform/env.hpp:330:36: error: ‘data’ is not a member of ‘boost::proto’ "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -DBOOST_ALL_NO_LIB=1 -DBOOST_GRAPH_DYN_LINK=1 -DBOOST_HAS_ICU=1 -DNDEBUG -I"." -I"/usr/include" -I"libs/graph/src" -c -o "bin.v2\libs\graph\build\gcc-4.5.3\release\threading-multi\read_graphviz_new.o" "libs\graph\src\read_graphviz_new.cpp" ...failed gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi/read_graphviz_new.o... gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi/graphml.o In file included from ./boost/proto/transform/when.hpp:25:0, from ./boost/proto/matches.hpp:43, from ./boost/proto/core.hpp:22, from ./boost/xpressive/regex_primitives.hpp:28, from ./boost/xpressive/xpressive_static.hpp:24, from ./boost/graph/graphviz.hpp:34, from ./boost/graph/graphml.hpp:20, from libs\graph\src\graphml.cpp:17: ./boost/proto/transform/env.hpp: In member function ‘boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::result_type boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::operator()(boost::proto::detail::arg<T>) const’: ./boost/proto/transform/env.hpp:330:36: error: ‘data’ is not a member of ‘boost::proto’ "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -DBOOST_ALL_NO_LIB=1 -DBOOST_GRAPH_DYN_LINK=1 -DBOOST_HAS_ICU=1 -DNDEBUG -I"." -I"/usr/include" -I"libs/graph/src" -c -o "bin.v2\libs\graph\build\gcc-4.5.3\release\threading-multi\graphml.o" "libs\graph\src\graphml.cpp" ...failed gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi/graphml.o... ...skipped <pbin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi>cygboost_graph.dll for lack of <pbin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi>read_graphviz_new.o... ...skipped <pbin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi>libboost_graph.dll.a for lack of <pbin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi>read_graphviz_new.o... ...skipped <p/usr/local/bin>cygboost_graph.dll for lack of <pbin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi>cygboost_graph.dll... ...skipped <p/usr/local/lib>libboost_graph.dll.a for lack of <pbin.v2/libs/graph/build/gcc-4.5.3/release/threading-multi>libboost_graph.dll.a... gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi/read_graphviz_new.o In file included from ./boost/proto/transform/when.hpp:25:0, from ./boost/proto/matches.hpp:43, from ./boost/proto/core.hpp:22, from ./boost/xpressive/regex_primitives.hpp:28, from ./boost/xpressive/xpressive_static.hpp:24, from ./boost/graph/graphviz.hpp:34, from libs\graph\src\read_graphviz_new.cpp:50: ./boost/proto/transform/env.hpp: In member function ‘boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::result_type boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::operator()(boost::proto::detail::arg<T>) const’: ./boost/proto/transform/env.hpp:330:36: error: ‘data’ is not a member of ‘boost::proto’ "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -DBOOST_ALL_NO_LIB=1 -DBOOST_HAS_ICU=1 -DNDEBUG -I"." -I"/usr/include" -I"libs/graph/src" -c -o "bin.v2\libs\graph\build\gcc-4.5.3\release\link-static\threading-multi\read_graphviz_new.o" "libs\graph\src\read_graphviz_new.cpp" ...failed gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi/read_graphviz_new.o... gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi/graphml.o In file included from ./boost/proto/transform/when.hpp:25:0, from ./boost/proto/matches.hpp:43, from ./boost/proto/core.hpp:22, from ./boost/xpressive/regex_primitives.hpp:28, from ./boost/xpressive/xpressive_static.hpp:24, from ./boost/graph/graphviz.hpp:34, from ./boost/graph/graphml.hpp:20, from libs\graph\src\graphml.cpp:17: ./boost/proto/transform/env.hpp: In member function ‘boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::result_type boost::proto::functional::env_var<boost::proto::envns_::data_type>::impl<Env, true>::operator()(boost::proto::detail::arg<T>) const’: ./boost/proto/transform/env.hpp:330:36: error: ‘data’ is not a member of ‘boost::proto’ "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -DBOOST_ALL_NO_LIB=1 -DBOOST_HAS_ICU=1 -DNDEBUG -I"." -I"/usr/include" -I"libs/graph/src" -c -o "bin.v2\libs\graph\build\gcc-4.5.3\release\link-static\threading-multi\graphml.o" "libs\graph\src\graphml.cpp" ...failed gcc.compile.c++ bin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi/graphml.o... ...skipped <pbin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi>libboost_graph.a(clean) for lack of <pbin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi>read_graphviz_new.o... ...skipped <pbin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi>libboost_graph.a for lack of <pbin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi>read_graphviz_new.o... ...skipped <p/usr/local/lib>libboost_graph.a for lack of <pbin.v2/libs/graph/build/gcc-4.5.3/release/link-static/threading-multi>libboost_graph.a...

3 3

Building Boost 1.4.4 with mpi enabled.
by Mike Van Duzee 26 Jul '12

26 Jul '12

I am having issues building boost with mpi enabled. (Windows 7 64bit, Visual Studio 2008) - OpenMPI 1.6 was downloaded and compiled at C:\\openmpi - The following has been added to my user-config.jam: using mpi : mpicxx : <include>C:\\openmpi \\installed\\include <library-path>C:\\openmpi )\\installed\\lib : C:\\openmpi \\installed\\bin\\mpirun ; - The '--with-mpi' flag has been added to the call to bjam.exe. When I build I boost I get a number of unresolved external symbols: packed_skeleton_iarchive.obj : error LNK2001: unresolved external symbol ompi_mpi_byte packed_skeleton_oarchive.obj : error LNK2001: unresolved external symbol ompi_mpi_byte point_to_point.obj : error LNK2001: unresolved external symbol ompi_mpi_byte request.obj : error LNK2001: unresolved external symbol ompi_mpi_byte ... request.obj : error LNK2001: unresolved external symbol ompi_request_null mpi_datatype_cache.obj : error LNK2001: unresolved external symbol ompi_mpi_datatype_null bin.v2\libs\mpi\build\msvc-9.0\debug\address-model-64\threading-multi\boost_mpi-vc90-mt-gd-1_44.dll : fatal error LNK1120: 15 unresolved externals After looking at the call to link I can see that it is not linking to any of the Open MPI libs: link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /MACHINE:X64 /subsystem:console /out:"bin.v2\libs\mpi\build\msvc-9.0\debug\address-model-64\threading-multi\boost_mpi-vc90-mt-gd-1_44.dll" /IMPLIB:"bin.v2\libs\mpi\build\msvc-9.0\debug\address-model-64\threading-multi\boost_mpi-vc90-mt-gd-1_44.lib" /LIBPATH:"d:\thirdparty\msvc2008\x64\OPENMPI\1.6\installed\lib" @"bin.v2\libs\mpi\build\msvc-9.0\debug\address-model-64\threading-multi\boost_mpi-vc90-mt-gd-1_44.dll.rsp" Any help with this would be appreciated, Mike

1 0

[1.51][program_options] Changesets not merged to release
by Andrey Semashev 26 Jul '12

26 Jul '12

Hi, I've noticed that changesets 79280 and 79283 have not been merged to the release branch. The first fixes compilation with STLPort and the second one removes warnings. Both look quite harmless and have been committed to trunk for quite a while. I don't see any regressions in tests caused by these changes. Can these be merged to trunk? I can do the merge, if permitted.

3 3

BlueGo Beta 0.0.1
by Julian Amann 26 Jul '12

26 Jul '12

I build a small tool which builds boost libraries using Visual Studio 2010 x64. It can be downloaded from here: http://vertexwahn.de/ You just have to start the application and click the "Download and Build Boost 1.50.0 with Visual Studio 2010 x64" button - everything else should work automatically. The application downloads the current boost library and builds it. Julian

2 1

[iterators]: collection_keys and collection_values
by Igor Lubashev 26 Jul '12

26 Jul '12

I'd like to propose adding collection_keys and collection_values to iterators library. ======== Motivation ======== I find myself very often having to iterate over all keys or values of a map (or multimap). The best I can do is to use BOOST_FOREACH to iterate over the collection value_type pairs and then work with .first or .second. That makes for awkward and unclear code. BOOST_FOREACH( const foo_bar_map_t::value_type &foo_bar_pair, my_map ) { baz(foo_bar_pair.second); } Instead, I'd like to do something like: BOOST_FOREACH( const bar_t &bar, collection_values(my_map) ) { baz(bar); } BOOST_FOREACH( const foo_t &foo, collection_keys(my_map) ) { baz(foo); } ======== Proposal ======== Add this to iterators library as collection_iterators.hpp Thanks, - Igor #ifndef .... #define .... #include <boost/iterator/transform_iterator.hpp> namespace boost { namespace detail { template<typename CollectionT> struct key_function : public std::unary_function<const typename CollectionT::value_type&, const typename CollectionT::key_type&> { typename key_function::result_type operator()(typename key_function::argument_type p) const { return p.first; } }; template<typename CollectionT> struct value_function : public std::unary_function<const typename CollectionT::value_type&, const typename CollectionT::mapped_type&> { typename value_function::result_type operator()(typename value_function::argument_type p) const { return p.second; } }; template<typename CollectionT, typename AdapterF> class collection_adapter { const CollectionT &c; public: typedef boost::transform_iterator<AdapterF, typename CollectionT::const_iterator> const_iterator; typedef const_iterator iterator; collection_adapter(const CollectionT &c) : c(c) {} const_iterator begin() const { return boost::make_transform_iterator(c.begin(), AdapterF()); } const_iterator end() const { return boost::make_transform_iterator(c.end(), AdapterF()); } }; } // Adapter for map-like collection -> iterable keys collection template<typename CollectionT> const detail::collection_adapter<CollectionT, detail::key_function<CollectionT> > collection_keys(const CollectionT &c) { return detail::collection_adapter<CollectionT, detail::key_function<CollectionT> >(c); } // Adapter for map-like collection -> iterable values collection template<typename CollectionT> const detail::collection_adapter<CollectionT, detail::value_function<CollectionT> > collection_values(const CollectionT &c) { return detail::collection_adapter<CollectionT, detail::value_function<CollectionT> >(c); } } // namespace boost #endif // ....

2 1

website/docs: link broken
by Markus Werle 25 Jul '12

25 Jul '12

Hi! On http://www.boost.org/doc/libs/1_50_0/libs/scope_exit/doc/html/scope_exit/Ge… g_Started.html There is a link to http://www.boost.org/doc/libs/1_50_0/libs/scope_exit/doc/html/scope_exit/Tu… al.html which is broken. Error message is: 404 Not Found File "/home/grafik/www.boost.org/archives/live/boost_1_50_0/libs/scope_exit/doc /html/scope_exit/Tutorial.html" not found. Unable to find file. Markus

1 0

Re: [boost] Macro for BOOST_NO_NUMERIC_LIMITS_MAX_DIGITS10 or use BOOST_NO_NUMERIC_LIMITS_LOWEST
by Stewart, Robert 24 Jul '12

24 Jul '12

John Maddock wrote: > > >> is there a way to don't include all the deprecated macros? > > Whoa - interesting question. > > I don't know of one. > > > > However, all the deprecated macros are defined (I > > _believe_) in one place, in boost/config/suffix.hpp > > Making it so none of them are defined _should_ be > > straightforward. > > > >Could I suggest to define all of them in a specific > >boost/config/deprecated.hpp file, so that we can add a > >deprecated warning when the file is included. +1 > I think it's too soon for that - as things stand you would > basically be injecting that warning into every Boost header > that includes boost/config.hpp. Aren't there some that have been deprecated for long enough to get that sort of treatment? IOW, create a mechanism for complaining about the use of old names and a policy for how long old names are defined without complaint, how long with complaint, and how long before they are removed. For example, newly renamed macros might be kept in config/suffix.hpp for four releases before moving them to config/deprecated.hpp. Then, names in deprecated.hpp might remain for two releases before removing them altogether. > Besides I don't see what harm defining the old names does? If you can't ever remove the old names, then the set of names that can appear in Boost code grows uncomfortably large. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 2

[TypeErasure]
by Markus Werle 24 Jul '12

24 Jul '12

Hi Steven! I have one question: proto and spirit use _1, _2, etc. TypeErasure uses _a, _b, _c ... What was your reason to introduce yet another placeholder set? Markus

4 6

[move] Implementing operator= in terms of pass-by-value and swap
by Krzysztof Czainski 24 Jul '12

24 Jul '12

Hello, Implementing the assignment operator (that is, the copy-, move- and other assignments) in terms of pass-by-value and swap is a common idiom [1]. {{{ T operator=( T b ) { swap(*this,b); return *this; } }}} If T is copy-constructible, the above works as a copy-assign. If T is movable, the above works as a move-assign. And for anything convertible to T the above assign will work (right?). Furthermore, this will also work for movable but not copyable classes (right?). It may not be the optimal version of assignment in some cases. In rare cases it might even be incorrect - for types like std::vector, which aren't expected to free reserved memory upon assignment. But assuming swap is a cheap operation, it should be close to optimal in many if not most cases. And in cases, where RVO kicks in, it may be even better than providing separate overloads of operator= for lvalues and rvalues [2]. Boost.Move docs [3] suggest writing the separate overloads of operator=, and in C++03 move emulation the macro BOOST_COPYABLE_AND_MOVABLE(classname) provides a third overload (necessary for the emulation to work in C++03). Should the user choose to write one overload of operator= in the pass-by-value version, he needs to use a different macro, that doesn't provide the additional overload of operator=. I found such a macro: BOOST_COPYABLE_AND_MOVABLE_ALT(classname), but no docs about it. I have the following suggestions, regarding Boost.Move: 1. Providing a macro, BOOST_MOVABLE(classname), that only provides the two needed conversion operators. Or if that is the purpose of BOOST_COPYABLE_AND_MOVABLE_ALT(classname), I couldn't find docs about it. And to avoid a macro entirely, maybe it is possible to provide a CRTP base class 'movable', that would provide these? 2. Now, that there's a separate macro, defining a movable class, it may make sense to add a separate macro for making a class noncopyable. And we already have a base class for that, if one wants to avoid a macro. 3. It would be nice if the docs [3] mentioned something about the alternative of providing only one operator= passing by value. [1] http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Copy-and-swap [2] http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/ [3] http://www.boost.org/doc/libs/1_50_0/doc/html/move/implementing_movable_cla… Regards, Kris

1 0

Re: [boost] [type_erasure] [docs]contrast with boost::any
by Larry Evans 23 Jul '12

23 Jul '12

On 07/23/12 15:37, Larry Evans wrote: > On 07/18/12 00:13, Lorenzo Caminiti wrote: >> Hello all, >> >> *** The review of Steven Watanabe's proposed Boost.TypeErasure library >> begins on July 18, 2012 and ends on July 27, 2012. *** >> > The page: > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > says: > > x is approximately equivalent to a boost::any > > however, it doesn't say how te::any differs from boost::any. > > The attached shows that a boost::any can change it's > type, and, as such, is somewhat like boost::variant. > However, te::any, once it's created, cannot change > it's type, AFAICT. At least that's what the > attached code indicates when compiled with: > > #define SHOW_TE_FIXED_TYPE > A simplified version of that code (which doesn't require demangled_type_name), is attached. The attached also suggests that, when multiple placeholders are in the concept, the unary any *requires* a binding argument. This is shown by trying to compile the attachment with: #define SHOW_BINDINGS_MUST_BE_COMPLETE In contrast, the example here: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… shows no binding is needed because the only placeholder in the concept is the default, _self. HTH. -regards, Larry

1 0

[Review Request] array
by Brian Smith 23 Jul '12

23 Jul '12

Hi All, Based on the assumption that, almost no feedback is good feedback, I'd like to submit the array class for review. The requisite files are hosted at, https://github.com/BrianJSmith/Array Comment: The array class is a C++11 compatible implementation of static multidimensional arrays. Kind Regards Brian

5 12

[TypeErasure] Forward constructors and binded types
by Vicente J. Botet Escriba 23 Jul '12

23 Jul '12

Hi,, In the example from the doc typedef mpl::vector< copy_constructible<_a>, copy_constructible<_b>, copy_constructible<_c>, constructible<_a(const _b&, const _c&)> > construct; std::vector<double> vec; int i = 10; double d = 2.5; tuple<construct, _a&, _b, _c> t(vec, i, d); any<construct, _a> v(get<1>(t), get<2>(t)); I don't see which type is constructed and stored in v and how this type is given. That is I don't see how _a is binded. Could you help me? Best, Vicente

9 32

[TypeErasure] BOOST_TYPE_ERASURE_MEMBER
by Julien Nitard 23 Jul '12

23 Jul '12

Hi Steven, all BOOST_TYPE_ERASURE_MEMBER is only mentioned in the reference, it could be useful to add it to the tutorial: I guess that most user concepts will start from member functions of a given type. A sample on how to specialize it for types not having the said member function would be also welcome. Finally, why did you choose not to include the member's signature in the macro ? Isn't this giving the way for hard to find mistakes ? Regards, Julien

2 2

[website] Server problems
by Daniel James 23 Jul '12

23 Jul '12

Hello, As you might have noticed, many of the php based pages were down this morning. The cause appears to be that the directory '/home/grafik/www.boost.org/' didn't have read and execute permissions for all, so php couldn't read a file within it. I fixed it by giving read permission - nothing in that directory is private so I don't think that will be a problem. Hopefully that's okay? I don't like messing round with these things too much, as I don't know the details about the setup. Does anyone have any idea what changed to cause this issue? Maybe an upgrade or configuration change? Could it use group permissions before but can't now for some reason? Or perhaps something accidentally changed the permission on the directory? It'd be useful to understand what happened. Daniel

1 0

[spirit][phoenix] Spirit v2 conflicts with Phoenix v3
by Andrey Semashev 23 Jul '12

23 Jul '12

Hi, Recently I tried to port my code to Boost.Spirit v2 and Boost.Phoenix v3. After including the following headers: #include <boost/phoenix/core.hpp> #include <boost/spirit/include/qi_core.hpp> I got the following error: In file included from ./boost/spirit/home/phoenix/core.hpp:13:0, from ./boost/spirit/include/phoenix_core.hpp:14, from ./boost/spirit/home/support/make_component.hpp:15, from ./boost/spirit/home/support/meta_compiler.hpp:20, from ./boost/spirit/home/qi/domain.hpp:15, from ./boost/spirit/home/qi/parser.hpp:15, from ./boost/spirit/include/qi_core.hpp:16, from libs/log/src/text_file_backend.cpp:51: ./boost/spirit/home/phoenix/core/actor.hpp:46:16: error: redefinition of ‘struct boost::phoenix::detail::error_expecting_arguments’ ./boost/phoenix/core/actor.hpp:41:16: error: previous definition of ‘struct boost::phoenix::detail::error_expecting_arguments’ ./boost/spirit/home/phoenix/core/actor.hpp:65:12: error: redefinition of ‘struct boost::phoenix::actor<Expr>’ ./boost/phoenix/core/actor.hpp:161:12: error: previous definition of ‘struct boost::phoenix::actor<Expr>’ I take it the problem is that Boost.Spirit always include Phoenix v2 which causes name clashes with v3. Is this a known problem? Shouldn't Boost.Spirit include Phoenix v3 headers instead? I can see v3 redirects includes to v2 if BOOST_PHOENIX_USE_V2_OVER_V3 macro is defined (BTW, there's an error in boost/phoenix/stl.hpp: BOOST_PHOENIX_USE_V2 macro is checked instead). This happens in the release branch.

2 6

[TypeErasure]_self
by Markus Werle 23 Jul '12

23 Jul '12

Hi Steven, In [docs]/type_erasure/libs/type_erasure/doc/html/boost_typeerasure/feedback.html you ask for feedback: I would be perfectly happy with _ instead of _self. You would be in sync with the folks that wrote C# Reactive Extensions (http://msdn.microsoft.com/en-us/data/gg577611) who have the convention that _ stands for "unused", which it is here, too. To me constructible<_(const std::string&)> reads fine. Markus

2 1

[website][unordered] Patches on release notes.
by Daniel James 22 Jul '12

22 Jul '12

Hi, There's a fairly serious bug in Boost.Unordered in 1.50 so I wanted to make a patch available. I've added it to the release notes, at the top so it's quite visible, you can see it here: http://www.boost.org/users/history/version_1_50_0.html I'm emailing about this, partly to bring the patch to people's attention and partly to find out what you think of using the release notes this way. Daniel

3 4

[asio] windows::basic_stream_handle
by Daniel Larimer 22 Jul '12

22 Jul '12

Is there a reason why basic_stream_handle does not/can not implement bytes_available() or non_blocking() but can implement sync and async methods? Dan

1 0

Container docs: 404 image
by Olaf van der Spek 22 Jul '12

22 Jul '12

Hi, Page A has a link to image B which doesn't exist. A http://www.boost.org/doc/libs/1_50_0/doc/html/container/non_standard_contai… B http://www.boost.org/doc/libs/1_50_0/doc/html/images/stable_vector.png -- Olaf

1 1

[preprocessor] Sequences vs. All Other Data Structures
by Paul Mensonides 22 Jul '12

22 Jul '12

Hello all. In the past, I've said several times that sequences are a superior to every other data structure when dealing with a collection of elements (tuples are better in some very specific contexts). One of those reasons is that, if a library is built for it, non-unary (or even variadic) elements are natural because the structure of the sequence itself encapsulates each element. (int)(std::pair<int, int>)(double) Another reason is that, if a library is built for it and if placemarkers ala C99/C++11 are available, there is a natural representation of the nil sequence: /**/ ...i.e. nothing. This leads to very natural appends, prepends, and joins, since these operation are simply variations on juxtaposition. s (e) (e) s s1 s2 I'll use these in the examples that follow. Another reason, which I'll demonstrate in this post, is that the very structure of sequences usually contain the potential "processing power" to process them. By "processing power," I'm referring to algorithmic steps (i.e. headroom)--which can be a finite resource in preprocessor metaprogramming. The structure of the sequence itself allows what I've called "sequential iteration." #define A(...) + B #define B(...) - A A(1)(2)(3) // + - + B (The reason that this works is because B is not invoked "within" A and vice versa.) So, to convert a sequence to a comma-separated-list, you can just do something like #define CSV(seq) CSV_A seq #define CSV_A(...) __VA_ARGS__ CSV_B #define CSV_B(...) , __VA_ARGS__ CSV_C #define CSV_C(...) , __VA_ARGS__ CSV_B CSV( (1)(2)(3) ) // 1, 2, 3 CSV_B Unfortunately, we still have to get rid of the spurious CSV_A, CSV_B, or CSV_C (depending on the length of the sequence) that comes out the end. That's easily done with concatenation. #define CSV(seq) \ CHAOS_PP_REVERSE_CAT(0, CSV_A seq) \ /**/ #define CSV_A(...) __VA_ARGS__ CSV_B #define CSV_B(...) , __VA_ARGS__ CSV_C #define CSV_C(...) , __VA_ARGS__ CSV_B #define CSV_A0 #define CSV_B0 #define CSV_C0 CSV( (1)(2)(3) ) // 1, 2, 3 The REVERSE_CAT is used here so that the commas don't have to be encoded. Essentially, it's defined as REVERSE_CAT(a, ...) => __VA_ARGS__ ## a except that it allows its arguments to expand. A regular CAT could be used, but you'd have to delay the existence of the commas. Now *if* the number of scans applied to a macro argument is guaranteed by definition of CAT (as it is with CHAOS_PP_CAT), one can do something like this #define CC CHAOS_PP_DEFER(CHAOS_PP_COMMA)() #define CSV(seq) \ CHAOS_PP_CAT(CSV_A seq, 0) \ /**/ #define CSV_A(...) __VA_ARGS__ CSV_B #define CSV_B(...) CC __VA_ARGS__ CSV_C #define CSV_C(...) CC __VA_ARGS__ CSV_B #define CSV_A0 #define CSV_B0 #define CSV_C0 CSV( (1)(2)(3) ) // 1, 2, 3 The DEFER macro used here delays the expansion of the COMMA() invocation through exactly one scan which is all that CAT applies to its argument. The CC is used here only as an abbreviation so that the example doesn't get too cluttered. This latter version is significantly more verbose, but this type of thing is sometimes unavoidable especially when dealing with unmatched parentheses rather than commas which is exactly what we'll run into next. Let's say we wanted to calculate the length of the sequence. #define LP CHAOS_PP_DEFER(CHAOS_PP_LPAREN)() #define RP CHAOS_PP_DEFER(CHAOS_PP_RPAREN)() #define SIZE(seq) \ CHAOS_PP_CAT(SIZE_A seq, 0) 0 CHAOS_PP_CAT(SIZE_C seq, 0) \ /**/ #define SIZE_A(...) CHAOS_PP_INC LP SIZE_B #define SIZE_B(...) CHAOS_PP_INC LP SIZE_A #define SIZE_A0 #define SIZE_B0 #define SIZE_C(...) RP SIZE_D #define SIZE_D(...) RP SIZE_C #define SIZE_C0 #define SIZE_D0 SIZE( (1)(2)(3) ) // CHAOS_PP_INC(CHAOS_PP_INC(CHAOS_PP_INC(0))) (As with CC above, the LP and RP macros are just sugar to avoid clutter in the example.) Essentially, we've iterated the sequence twice. The first time, we generated CHAOS_PP_INC( for each element. The second time, we generated ) for each element. However, this doesn't "finish the job" because an expression like MACRO CHAOS_PP_DEFER(CHAOS_PP_LPAREN)() ... ) causes the invocation of MACRO to be deferred through two scans, not one. This is actually a good thing in this scenario, because we don't really want CHAOS_PP_INC to be invoked "inside" CAT. To cause the evaluation, we just add another scan: #define LP CHAOS_PP_DEFER(CHAOS_PP_LPAREN)() #define RP CHAOS_PP_DEFER(CHAOS_PP_RPAREN)() #define SIZE(seq) \ SIZE_I(CHAOS_PP_CAT(SIZE_A seq, 0) 0 CHAOS_PP_CAT(SIZE_C seq, 0)) \ /**/ #define SIZE_A(...) CHAOS_PP_INC LP SIZE_B #define SIZE_B(...) CHAOS_PP_INC LP SIZE_A #define SIZE_A0 #define SIZE_B0 #define SIZE_C(...) RP SIZE_D #define SIZE_D(...) RP SIZE_C #define SIZE_C0 #define SIZE_D0 #define SIZE_I(x) x SIZE( (1)(2)(3) ) // 3 Like BOOST_PP_INC, CHAOS_PP_INC saturates at a finite value, and thus the above implementation can only "correctly" measure the length of a sequences of limited length. One could use the unlimited, but more expensive, CHAOS_PP_ARBITRARY_INC instead if necessary. Generating a closing parentheses is common, so we'll generalize it #define LP CHAOS_PP_DEFER(CHAOS_PP_LPAREN)() #define RP CHAOS_PP_DEFER(CHAOS_PP_RPAREN)() #define CLOSE(seq) CHAOS_PP_CAT(CLOSE_A seq, 0) #define CLOSE_A(...) RP CLOSE_B #define CLOSE_B(...) RP CLOSE_A #define CLOSE_A0 #define CLOSE_B0 The above then becomes #define SIZE(seq) \ SIZE_I(CHAOS_PP_CAT(SIZE_A seq, 0) 0 CLOSE(seq)) \ /**/ #define SIZE_A(...) CHAOS_PP_INC LP SIZE_B #define SIZE_B(...) CHAOS_PP_INC LP SIZE_A #define SIZE_A0 #define SIZE_B0 #define SIZE_I(x) x Now, let's do something more serious. I recently ran into a scenario where I needed to generate something for each permutation of each element of the powerset of a sequence. For the powerset: #define POWERSET(seq) \ POWERSET_1(CHAOS_PP_CAT(POWERSET_T seq, 0) CLOSE(seq)) \ /**/ #define POWERSET_1(x) x #define POWERSET_2(e, ps) \ CHAOS_PP_IIF(CHAOS_PP_SEQ_IS_CONS(ps))( \ ps CHAOS_PP_SPLIT( \ 1, \ POWERSET_5(CHAOS_PP_CAT(POWERSET_P ps, 0) e, CLOSE(ps)) \ ), \ (e)() \ ) \ /**/ #define POWERSET_3(...) POWERSET_4(__VA_ARGS__) #define POWERSET_4(seq, e, ps) e, (e seq) ps #define POWERSET_5(...) __VA_ARGS__ #define POWERSET_T(...) POWERSET_2 LP(__VA_ARGS__) CC POWERSET_F #define POWERSET_F(...) POWERSET_2 LP(__VA_ARGS__) CC POWERSET_T #define POWERSET_T0 #define POWERSET_F0 #define POWERSET_P(seq) POWERSET_3 LP seq CC POWERSET_Q #define POWERSET_Q(seq) POWERSET_3 LP seq CC POWERSET_P #define POWERSET_P0 #define POWERSET_Q0 POWERSET( (a)(b)(c) ) // ( (c) ) // ( ) // ( (b)(c) ) // ( (b) ) // ( (a)(c) ) // ( (a) ) // ( (a)(b)(c) ) // ( (a)(b) ) It important to note that this implementation is not limited by any library-defined resource. It is limited only by the amount of available compiler resources. With unlimited CPU and memory resources, this algorithm compute the powerset of a sequence of *any* length. For generating permutations, I'll use a helper algorithm which I've called "FOCUS". The job of this algorithm is to produce a sequence which isolates each element in the input sequence. For example, FOCUS((a)(b)(c)(d), ~) // ( (a)(b)(c), (d), , ~) // ( (a)(b), (c), (d), ~) // ( (a), (b), (c)(d), ~) // ( , (a), (b)(c)(d), ~) This is kind of a weird form. Essentially, for each element x in the input sequence, the algorithm produces an element in the resulting sequence of the form: ( seq-of-elements-before-x, (x), seq-of-elements-after-x, ~) #define FOCUS(seq, ...) \ CHAOS_PP_INLINE_WHEN(CHAOS_PP_SEQ_IS_CONS(seq))( \ FOCUS_1( \ (CHAOS_PP_SEQ_HEAD(seq)), \ CHAOS_PP_SEQ_TAIL(seq), \ __VA_ARGS__ ) \ ) \ /**/ #define FOCUS_1(h, t, ...) \ FOCUS_4(CHAOS_PP_CAT(FOCUS_T t, 0)(, h, t, __VA_ARGS__) CLOSE(t)) \ /**/ #define FOCUS_2(seq) FOCUS_3 seq #define FOCUS_3(l, m, r, ...) \ (l m, (CHAOS_PP_SEQ_HEAD(r)), CHAOS_PP_SEQ_TAIL(r), __VA_ARGS__) \ (l, m, r, __VA_ARGS__) \ /**/ #define FOCUS_4(x) x #define FOCUS_T(...) FOCUS_2 LP FOCUS_F #define FOCUS_F(...) FOCUS_2 LP FOCUS_T #define FOCUS_T0 #define FOCUS_F0 As with POWERSET, this implementation is unlimited WRT library resources. Finally, the permuations themselves: #define PERMUTE(seq) \ PERMUTE_3(CHAOS_PP_CAT(PERMUTE_P seq, 0) PERMUTE_1(seq,) CLOSE(seq)) \ /**/ #define PERMUTE_1(seq, pf) \ CHAOS_PP_IIF( \ CHAOS_PP_BITAND(CHAOS_PP_SEQ_IS_CONS(seq)) \ (CHAOS_PP_SEQ_IS_CONS(CHAOS_PP_SEQ_TAIL(seq))))( \ PERMUTE_2, (pf seq) CHAOS_PP_EAT \ )(FOCUS(seq, pf)) \ /**/ #define PERMUTE_1_INDIRECT() PERMUTE_1 #define PERMUTE_2(fs) CHAOS_PP_CAT(PERMUTE_T fs, 0) #define PERMUTE_3(x) x #define PERMUTE_4(x) x #define PERMUTE_T(l, m, r, pf) \ CHAOS_PP_OBSTRUCT(PERMUTE_1_INDIRECT)()(l r, pf m) PERMUTE_F \ /**/ #define PERMUTE_F(l, m, r, pf) \ CHAOS_PP_OBSTRUCT(PERMUTE_1_INDIRECT)()(l r, pf m) PERMUTE_T \ /**/ #define PERMUTE_T0 #define PERMUTE_F0 #define PERMUTE_P(...) PERMUTE_4 LP PERMUTE_Q #define PERMUTE_Q(...) PERMUTE_4 LP PERMUTE_P #define PERMUTE_P0 #define PERMUTE_Q0 PERMUTE((a)(b)(c)) // ( (c)(b)(a) ) // ( (c)(a)(b) ) // ( (b)(c)(a) ) // ( (b)(a)(c) ) // ( (a)(c)(b) ) // ( (a)(b)(c) ) Putting these together: #define A(s, seq) \ CHAOS_PP_EXPR_S(s)(CHAOS_PP_SEQ_FOR_EACH_S( \ s, B, PERMUTE(seq) \ )) \ /**/ #define B(s, seq) CHAOS_PP_SEQ_CONCAT(seq) CHAOS_PP_EXPR(CHAOS_PP_SEQ_FOR_EACH( A, POWERSET( (a)(b)(c) ) )) // c cb bc b ca ac a cba cab bca bac acb abc ba ab This generates \sum_{k=0}^n\frac{n!}{\left({n-k}\right)!} = e\int_1^\infty t^ne^{-t}\,dt = e\Gamma\left({n + 1, 1}\right) results (apologies for the LaTeX). For n = 3, as above, that's 16 results (where the 16th is empty from the nil sequence). For n = 6, that's 1957 results. For n = 7, it's 13700 results--which was enough to ICE g++ running on my VM. The moral of the story is that sequences are powerful because in many cases, an input sequence itself often contains enough "potential energy" to process it. It isn't very difficult to produce n^2, 2^n, or even n^n computational steps. I only really needed the case for n = 3, and I ultimately didn't use the above because the cost of a runtime solution acceptable and not really worth adding the above machinery (and I didn't want to take the time to add it to Chaos), but I thought I'd share it anyway. Regards, Paul Mensonides implementation... g++ -E -P -std=c++11 (or -std=c++0x) -I $CHAOS_ROOT <filename> --- #include <chaos/preprocessor/cat.h> #include <chaos/preprocessor/control/iif.h> #include <chaos/preprocessor/control/inline_when.h> #include <chaos/preprocessor/facilities/split.h> #include <chaos/preprocessor/logical/bitand.h> #include <chaos/preprocessor/punctuation/comma.h> #include <chaos/preprocessor/punctuation/paren.h> #include <chaos/preprocessor/recursion/basic.h> #include <chaos/preprocessor/recursion/expr.h> #include <chaos/preprocessor/seq/concat.h> #include <chaos/preprocessor/seq/core.h> #include <chaos/preprocessor/seq/for_each.h> #include <chaos/preprocessor/tuple/eat.h> #ifndef SEQ #define SEQ (a)(b)(c) #endif #define LP CHAOS_PP_DEFER(CHAOS_PP_LPAREN)() #define RP CHAOS_PP_DEFER(CHAOS_PP_RPAREN)() #define CC CHAOS_PP_DEFER(CHAOS_PP_COMMA)() #define CLOSE(seq) CHAOS_PP_CAT(CLOSE_T seq, 0) #define CLOSE_T(...) RP CLOSE_F #define CLOSE_F(...) RP CLOSE_T #define CLOSE_T0 #define CLOSE_F0 #define POWERSET(seq) \ POWERSET_1(CHAOS_PP_CAT(POWERSET_T seq, 0) CLOSE(seq)) \ /**/ #define POWERSET_1(x) x #define POWERSET_2(e, ps) \ CHAOS_PP_IIF(CHAOS_PP_SEQ_IS_CONS(ps))( \ ps CHAOS_PP_SPLIT( \ 1, \ POWERSET_5(CHAOS_PP_CAT(POWERSET_P ps, 0) e, CLOSE(ps)) \ ), \ (e)() \ ) \ /**/ #define POWERSET_3(...) POWERSET_4(__VA_ARGS__) #define POWERSET_4(seq, e, ps) e, (e seq) ps #define POWERSET_5(...) __VA_ARGS__ #define POWERSET_T(...) POWERSET_2 LP(__VA_ARGS__) CC POWERSET_F #define POWERSET_F(...) POWERSET_2 LP(__VA_ARGS__) CC POWERSET_T #define POWERSET_T0 #define POWERSET_F0 #define POWERSET_P(seq) POWERSET_3 LP seq CC POWERSET_Q #define POWERSET_Q(seq) POWERSET_3 LP seq CC POWERSET_P #define POWERSET_P0 #define POWERSET_Q0 // -- #define FOCUS(seq, ...) \ CHAOS_PP_INLINE_WHEN(CHAOS_PP_SEQ_IS_CONS(seq))( \ FOCUS_1( \ (CHAOS_PP_SEQ_HEAD(seq)), CHAOS_PP_SEQ_TAIL(seq), \ __VA_ARGS__ \ ) \ ) \ /**/ #define FOCUS_1(h, t, ...) \ FOCUS_4(CHAOS_PP_CAT(FOCUS_T t, 0)(, h, t, __VA_ARGS__) CLOSE(t)) \ /**/ #define FOCUS_2(seq) FOCUS_3 seq #define FOCUS_3(l, m, r, ...) \ (l m, (CHAOS_PP_SEQ_HEAD(r)), CHAOS_PP_SEQ_TAIL(r), __VA_ARGS__) \ (l, m, r, __VA_ARGS__) \ /**/ #define FOCUS_4(x) x #define FOCUS_T(...) FOCUS_2 LP FOCUS_F #define FOCUS_F(...) FOCUS_2 LP FOCUS_T #define FOCUS_T0 #define FOCUS_F0 // -- #define PERMUTE(seq) \ PERMUTE_3(CHAOS_PP_CAT(PERMUTE_P seq, 0) PERMUTE_1(seq,) CLOSE(seq)) \ /**/ #define PERMUTE_1(seq, pf) \ CHAOS_PP_IIF( \ CHAOS_PP_BITAND(CHAOS_PP_SEQ_IS_CONS(seq)) \ (CHAOS_PP_SEQ_IS_CONS(CHAOS_PP_SEQ_TAIL(seq))))( \ PERMUTE_2, (pf seq) CHAOS_PP_EAT \ )(FOCUS(seq, pf)) \ /**/ #define PERMUTE_1_INDIRECT() PERMUTE_1 #define PERMUTE_2(fs) CHAOS_PP_CAT(PERMUTE_T fs, 0) #define PERMUTE_3(x) x #define PERMUTE_4(x) x #define PERMUTE_T(l, m, r, pf) \ CHAOS_PP_OBSTRUCT(PERMUTE_1_INDIRECT)()(l r, pf m) PERMUTE_F \ /**/ #define PERMUTE_F(l, m, r, pf) \ CHAOS_PP_OBSTRUCT(PERMUTE_1_INDIRECT)()(l r, pf m) PERMUTE_T \ /**/ #define PERMUTE_T0 #define PERMUTE_F0 #define PERMUTE_P(...) PERMUTE_4 LP PERMUTE_Q #define PERMUTE_Q(...) PERMUTE_4 LP PERMUTE_P #define PERMUTE_P0 #define PERMUTE_Q0 // -- #define A(s, seq) \ CHAOS_PP_EXPR_S(s)(CHAOS_PP_SEQ_FOR_EACH_S( \ s, B, PERMUTE(seq) \ )) \ /**/ #define B(s, seq) CHAOS_PP_SEQ_CONCAT(seq) CHAOS_PP_EXPR(CHAOS_PP_SEQ_FOR_EACH( A, POWERSET(SEQ) ))

9 42

[filesystem] C++11 range-based for statement and BOOST_FOREACH support
by Beman Dawes 21 Jul '12

21 Jul '12

Support for the C++11 range-based for statement and BOOST_FOREACH for directory_iterator and recursive_directory_iterator has been added to trunk. This clears feature requests 5896 and 6521. The range-based for has been tested against gcc 4.6, which works, and against VC++2012 RC, which ICEs the compiler. The ICE has been reported to Microsoft. If anyone gives either C++11 range-based for or BOOST_FOREACH a try, I'd appreciate hearing about any problems. Both of these are new to me, and I'm nervous about getting the enabler free functions right. Here is what usage looks like: for (directory_entry& x : directory_iterator(".")) { std::cout << " " << x.path() << "\n"; } BOOST_FOREACH(directory_entry& x, directory_iterator(".")) { std::cout << " " << x.path() << "\n"; } Thanks, --Beman

8 21

[assignment] += for containers on right side
by Jochen Wilhelmy 20 Jul '12

20 Jul '12

Hi! is it possible to make += also work for containers on right side? i.e. int a; std::vector<int> b; std::list<int> c; std::vector<int> d; d += a,b,c,d; this would be similar to strings where += at least works with one string on the right side. -Jochen

6 7

[type_traits] Is it possible to test for an explicit conversion?
by John Maddock 20 Jul '12

20 Jul '12

OK, so we don't have such a trait at present, but one of the requests from the multiprecision review was "make conversions explicit in the front end if they are in the backend". Which to do it nicely (and semi-automagically) requires a trait that tests whether A is explicitly convertible to B. Which would obviously make a useful type trait in it's own right, but.... anyone have any ideas on how such a trait could be implemented? At present it looks "impossible" to me, but I've learned never to say never ;-) Thanks, John.

2 2

Proposal: Linear map
by Amir Ansari 20 Jul '12

20 Jul '12

Hi, In my work I have repeatedly had the need to create a sorted array in which I can insert/lookup from using a key. This is like a map except that it uses an array. The contention is that in some cases, it is faster to insert/remove from a sorted array rather than traversing a tree (the underlying data structure for a map) which involves pointer de-referencing. I would like to call the class linear_map. Looking forward to feedback from everyone. Many thanks, - Amir

5 11

[array] - array_vector
by Hite, Christopher 20 Jul '12

20 Jul '12

I've a got a small utility class that is a cross between boost::array and std::vector for when I only have a compile time constant max things. This is beats to complexity of fighting with custom allocators/pools. const unsigned n=100; Thing array[n]; unsigned count=0; goes to: array_vector<Thing,100> things; It's stl compliant and should drop in anywhere you've got a vector. Like vector and unlike boost::array (or regular array) 100 Things are not constructed. Have I reinvented something in boost? Should I submit it? Also related to this. There are a class of problems where n is known only on runtime, but you still only need it in a certain scope. gcc (C99 standard) allows variable length arrays on the stack. Does anyone know if that is allowed in C++11? What would think about something like this? unsigned n=readInt(); placeholder<Thing> bufffer[n]; //variable length data on stack buffer_vector<Thing> v(buffer,n); Chris

1 0