- Boost - lists.boost.org

boost_1_59_0 build failures
by Karen Shaeffer 24 Sep '15

24 Sep '15

Hello, I downloaded boost_1_59_0 and built the whole set of libraries. gcc --version gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 ./b2 install warning: No toolsets are configured. warning: Configuring default toolset "gcc". warning: If the default is wrong, your build may not work correctly. warning: Use the "toolset=xxxxx" option to override our guess. warning: For more configuration options, please consult warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html Performing configuration checks - 32-bit : no (cached) - 64-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : yes (cached) - lockfree boost::atomic_flag : yes (cached) - has_icu builds : yes (cached) warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : yes (cached) - iconv (libc) : yes (cached) - icu : yes (cached) - compiler-supports-visibility : yes (cached) - compiler-supports-ssse3 : yes (cached) - compiler-supports-avx2 : yes (cached) - gcc visibility : yes (cached) - long double support : yes (cached) warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - zlib : yes (cached) Component configuration: - atomic : building - chrono : building - container : building - context : building - coroutine : building - coroutine2 : building - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - timer : building - wave : building ...patience... ...patience... ...patience... ...patience... ...patience... ...patience... ...found 34509 targets... ...updating 8 targets... gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi/bzip2.o libs/iostreams/src/bzip2.cpp:20:56: fatal error: bzlib.h: No such file or directory #include "bzlib.h" // Julian Seward's "bzip.h" header. ^ compilation terminated. "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o "bin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi/bzip2.o" "libs/iostreams/src/bzip2.cpp" ...failed gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi/bzip2.o... ...skipped <pbin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi>libboost_iostreams.a(clean) for lack of <pbin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi>bzip2.o... ...skipped <pbin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi>libboost_iostreams.a for lack of <pbin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi>bzip2.o... ...skipped <p/usr/local/lib>libboost_iostreams.a for lack of <pbin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi>libboost_iostreams.a... gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi/bzip2.o libs/iostreams/src/bzip2.cpp:20:56: fatal error: bzlib.h: No such file or directory #include "bzlib.h" // Julian Seward's "bzip.h" header. ^ compilation terminated. "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_DYN_LINK=1 -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o "bin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi/bzip2.o" "libs/iostreams/src/bzip2.cpp" ...failed gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi/bzip2.o... ...skipped <pbin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi>libboost_iostreams.so.1.59.0 for lack of <pbin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi>bzip2.o... ...skipped <p/usr/local/lib>libboost_iostreams.so.1.59.0 for lack of <pbin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi>libboost_iostreams.so.1.59.0... ...skipped <p/usr/local/lib>libboost_iostreams.so for lack of <p/usr/local/lib>libboost_iostreams.so.1.59.0... ...failed updating 2 targets... ...skipped 6 targets... Is that expected? thanks, Karen -- Karen Shaeffer Be aware: If you see an obstacle in your path, Neuralscape Services that obstacle is your path. Zen proverb

2 1

Fwd: [sort][container] Challenge for sorting experts, an improved stable sort
by Francisco José Tapia 23 Sep '15

23 Sep '15

Hi Jon, If the elements in the flat associative container are sorted, you need only to sort the elements to insert and after do a fusion of the two parts. If your container admit repeated elements, you can use the std::sort, if not, you must use an stable sort , and delete the repeated. You have several algorithms for to do a stable sort. In the library we are developing (https://github.com/fjtapia/sort_parallel ) you have a smart_merge_sort, which is a very fast stable sort and use only one half of the memory used by the data, is exception safe and use the move semantics I didn't see any implementation of the stable sort algorithms without additional memory, in any library GCC, TBB, IPP … I suppose because they are slow. If you have 100 elements and want to insert 30 elements, need to resize the vector to 130 elements, the last 30 are empty. If you have other vector with the data to insert, you can use smart_merge_sort, and use as auxiliary memory the last 15 elements of the main vector. After sort, delete the repeated elements. And with the two vectors you must do a half_merge fusion , and all is done. With this method you need only the vector for to sort the elements to insert. If you want I can write a small program doing this, using the code of the library.

2 2

[sort][container] Challenge for sorting experts, an improved stable sort
by Ion Gaztañaga 23 Sep '15

23 Sep '15

Hi, I'm trying to improve insertion times for flat associative containers. In range insertions one optimization is to insert the whole range in the end of the container and sort the whole vector instead of trying a loop. An additional optimization proposed in the mailing list is to have an option to create externally the internal vector type of the flat map/set, fill it and then try to move it into the flat container. That requires sorting the moved vector (and removing duplicates if needed). I could try to use std::sort/std::stable_sort but there are some problems: -> Non-portable for C++03 compilers and Boost.Move, and Boost.Container fully supports those platforms. -> Additional O(N) temporary memory for stable sorting. Usually this means a temporary N element array, although there are algorithm to use only N/2 temporary elements. With big containers, this is a lot of memory. So I started analyzing several papers and implementations to see if a custom implementation was possible, but I felt Boost.Sort could be a good place to have that implementation and the Boost community a good place to discuss design alternatives. My initial requirements: 1) Stable sort. A non-stable sort is faster and useful for unique keys containers, but stable sort can be used initially in all flat containers until the non-stable version is implemented. 2) Externally supplied auxiliary memory with optionally no auxiliary memory at all. It seems that there are newer algorithms like Grailsort (https://github.com/Mrrl/GrailSort) or WikiSort (https://github.com/BonzaiThePenguin/WikiSort) that claim O(1) memory, even no auxiliary buffer, and key comparison and data exchanges with complexity O(n*log(n)). However I don't think those implementation correctly handle the basic exception guarantee or non-trivially copyable types. Reason: I want to avoid allocating short-lived temporary memory: if it's available I want to pass the extra capacity that flat containers' internal vector holds for future insertions. 3) Customization points (without ADL, which IMHO is not customizable enough). The sort algorithm should use a SortTraits template parameter for basic operations like "move", "swap", "initialized_move". E.g: template<class T> struct sort_traits { static? void move(T &from, T &to); static? void swap(T &l, T &r); static? void uninitialized_move(T &from, void *to); static? void destroy(T &from, void *to); }; I don't know if this trait should be stateful or not (static members). I could imagine the usefulness of a stateful implementation of sort_traits that could store a reference to an allocator so that some special "construct" version is used in some operations. Or just a version that counts the number of each operation to ease debugging. In any case, a stateless version would be enough for most cases. Reason: In Boost.Container, the idea is to use boost::move + boost::adl_move_swap in the initial implementation, maybe some destructive move implementation in a second iteration if Boost.Move implements it. In any case those operations should be customizable by the user, independently from the type to be sorted. This also avoids unnecessary dependencies in Boost.Sort. -> Dependencies: the implementation should only rely on Boost.Core, Boost.Config, maybe Boost.TypeTraits and no heavy STL dependencies (optionally). Currently Boost.Sort depends on Serialization for BOOST_STATIC_WARNING, but I think this is easily solvable, maybe this static assert utility should go to the core/utility library. Reason: Sort is a low-level algorithm that should avoid pulling unneeded dependencies to other boost libraries. * * * I don't know if other Boost libraries could benefit from this new stable_sort implementation. Maybe it's too special and I should try to write it myself in Boost.Container. I would love to hear comments and suggestions from sort experts, this might be a common need that could enrich the Boost.Sort library. Best, Ion

4 9

[regression] Tests for 'develop' not showing
by Edward Diener 23 Sep '15

23 Sep '15

Trying http://www.boost.org/development/tests/develop/developer/summary.html I get: "Error extracting file: The specified zipfile was not found."

4 4

Re: [boost] Error while building boost
by Roshan 22 Sep '15

22 Sep '15

Hi, This list is specific to the Boost.Compute library. This mail is probably meant for the main Boost mailing list. Forwarding you there. P.S. I'm not sure if the attachment is being forwarded properly, please check. On Tue, Sep 22, 2015 at 12:24 PM, <valnci89(a)gmail.com> wrote: > Hi, > > > I'm trying to install boost on my machine but its not building properly. > Attached is the output generated on running ./b2 install. > > > Commands used: > > ./bootstrap.sh --prefix=/usr/include/boost > > ./b2 install > > > Machine Info: > > OS: RHEL ppc64le > > Boost version: boost_1_59_0 > > > Let me know if any other info is required. > > > Please advice me on this issue. > > > Thanks, > > Valnci > -- Warm regards Roshan

1 0

[Container] interest in a flat_unordered_map
by Treb Connell 21 Sep '15

21 Sep '15

I'm hoping to port a flat hash map that I've written to boost. Since boost has a flat_map I think it'd be good to have a flat_unordered_map as well, especially since there's an opportunity to be much more efficient. The one I would like to use is based on the hash map used in Lua, which is a mix of Coalesced and Robin Hood hashes. I don't think there's a name that describes it yet unfortunately, but I describe it near the end of this post. *Performance (primary reason for use):* It uses memory and cache very effectively and ends up being *very fast*. It's hard to benchmark real world situations, but in inserting, finding, erasing, and iterating over a dictionary it was up to six orders of magnitude faster than VS2013's unordered_map. This isn't a totally fair test because the cache efficiency really shines. *Standards compliance:* Differences from std::unordered_map are widely the same differences as flat_map listed here <http://www.boost.org/doc/libs/1_59_0/doc/html/container/non_standard_contai…>. Also bucket related methods no longer apply, so will be removed. *That said there's one major standards compliance issue that I'm struggling with:* The most optimal implementation of iterators for this container *does not have constant time traversal*. The implementation is a vector with elements scattered across it. To increment an iterator I continue to increment the internal vector iterator until I hit a new element. In practice elements should be scattered evenly, and will be close to one another, but in the worst case this is N-1. Additional memory or logic could be added to make this O(1), but I don't think that trade is worth it. In my applications of unordered_map I rarely iterate, and would not want to penalize insert, find, or erase to make iteration faster. I could make a new concept for this, pay the cost for making it truly O(1), or *since the common case is not O(N) would it be okay to consider these bidirectional iterators*? *Implementation details:* You can see Lua's implementation here <http://www.lua.org/source/5.3/ltable.c.html>. The applicable logic is in and below *luaH_newkey, *comments are useful. It's primarily a Coalesced hash table, but differs in collision behavior. When a new key collides with an old key, we check to see if the old key is in it's "*main position"*. The main position is the index that the key hashes to. If it's not in it's main position that means that it previously collided and was displaced. Since this is the new keys main position, we displace again the current key, and place ourselves there. This drastically decreases chain length, and improves the load factor that the hash map can optimally reach. Sorry about long post, can go into additional details upon request. Thanks, Treb

6 7

A compile-time-counter code snippet for boost
by Igor V. Chesnokov 21 Sep '15

21 Sep '15

2 1

[serialization] bug in static_warning.hpp
by Alain Miniussi 21 Sep '15

21 Sep '15

Hi, In static_warning.hpp we have the following code (which, if I trust its name, should trigger a *warning*): #define BOOST_SERIALIZATION_BSW(B, L) \ typedef boost::serialization::BOOST_SERIALIZATION_SS< \ sizeof( boost::serialization::static_warning_test< B, L > ) \ > BOOST_JOIN(STATIC_WARNING_LINE, L) BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE; #define BOOST_STATIC_WARNING(B) BOOST_SERIALIZATION_BSW(B, __LINE__) Now, since, since there is no BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE defined in boost (there used to be one in static_assert.hpp) this thing will generate a typedef of the form: typedef boost::serialization::BOOST_SERIALIZATION_SS< \ sizeof( boost::serialization::static_warning_test< B, L > ) \ > $STATIC_WARNING_LINE$L BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE; which is wrong. The MPI test are failing on that. Maybe BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE should be replaced with BOOST_ATTRIBUTE_UNUSED, but I am not sure what that macro is trying to achieve. Thks Alain

1 1

[locale] char conversion issue
by Alain Miniussi 21 Sep '15

21 Sep '15

Hi, My build is failing on message.cpp with: ../../../libs/locale/src/shared/message.cpp(439): error: invalid type conversion: "const wchar_t *" to "const char *" static_cast<char const *>(p), ^ detected during: [...] caused by code like: ================= template<typename CharType> struct hash_function { size_t operator()(message_key<CharType> const &msg) const { pj_winberger_hash::state_type state = pj_winberger_hash::initial_state; CharType const *p = msg.context(); if(*p != 0) { CharType const *e = p; while(*e) e++; state = pj_winberger_hash::update_state(state, static_cast<char const *>(p), static_cast<char const *>(e)); state = pj_winberger_hash::update_state(state,'\4'); } =================== Which looks like a legitimate error since that conversion does not seems t be covered by static_cast. This is on bot master and develop branch. The compiler is intel 16: [alainm@gurney build]$ icpc --version icpc (ICC) 16.0.0 20150815 Copyright (C) 1985-2015 Intel Corporation. All rights reserved. [alainm@gurney build]$ Regards Alain

2 1

[Compute] array support
by Fabian Bösch 19 Sep '15

19 Sep '15

Hi, I've been using Boost.Compute for some tests in the last couple of days. So far, it has proven very useful and I came to like it quite a bit. One thing I would add to it, though, is support for arrays when adapting your own classes for OpenCl through the Macro BOOST_COMPUTE_ADAPT_STRUCT. A simple overload would do the trick in my opinion: namespace boost { namespace compute { namespace detail { template<class Struct, class T> inline std::string adapt_struct_insert_member(T Struct::*, const char *name) { std::stringstream s; s << " " << type_name<T>() << " " << name << ";\n"; return s.str(); } template<class Struct, class T, int N> inline std::string adapt_struct_insert_member(T (Struct::*)[N], const char *name) { std::stringstream s; s << " " << type_name<T>() << " " << name << "[" << N << "]" << ";\n"; return s.str(); } } // end detail namespace } // end compute namespace } // end boost namespace Hope something along this lines can be added, thanks, Fabian

2 1