- Boost-users - lists.boost.org

Boost graph library algorithms - is it possible to use previous solutions to "warm start" a new related problem
by F1E2D3 F1E2D3 29 Oct '17

29 Oct '17

Hello, I am primarily an Operations Researcher, and prior to boost, was writing my own C++ code for specific network flow problems. I am now hoping to transition to boost::graph completely for my network flow problem solution needs. However, I have one major concern. In linear programming (I use CPLEX https://www.ibm.com/us-en/marketplace/ibm-ilog-cplex as my primary linear programming (LP) solver), once a problem is solved, say a Dijkstra's shortest path problem, the solver maintains the optimal basis. Then, if some problem parameter changes, the linear program need not be solved from scratch, but the current basis is first tested for optimality for the new problem as well. An example of this would be an increase in the cost of an arc that does not feature on the optimal path from source to destination in a shortest path problem. This increase in cost does not change the optimal path, and hence, it would be wasteful to solve this problem again from scratch. Does boost::graph have this capability that LP solvers have? I posted this question first on stack overflow and am posting it here now. The question was not completely answered there. A working code and small example are provided there. I am giving the link below. https://stackoverflow.com/questions/46986312/are-boostgraph-algorithms-capa… Any help will be appreciated. Thanks.

1 0

[review][DoubleEnded] Review Results
by Thorsten Ottosen 27 Oct '17

27 Oct '17

Dear users and members of Boost, I'm happy to to announce that Benedek Thaler's Boost.DoubleEnded is /conditionally/ accepted into Boost provided that it can be integrated smoothly with Boost.Container. There are several other conditions, some major and some minor which I will outline below. For now, I would like to thank everyone that participated with reviews and comments. We didn't have that many reviews, but the reviewers did spend a lot of time both on review and the following discussions. Special thanks also goes to Benedek for his hard work. It is not too often that a GSOC code ends with something of this quality. Two of the world's expert C++ container developers used phrases like "solid" and "everything looks clean and beautiful" about the implementation, "tests look very good, corner cases and all", "The reference section is very good". Congratulations, Benedek. ============== A path forward ============== Ion has most kindly accepted the idea of merging the library into Boost.Container. This consists of A. taking selected elements from batch_deque and adding them to boost::container::deque. B. putting devector into boost.container after changes have been applied to code and documentation C. back-porting the devector code to C++03 (C) does not need to happen immediately, that is, we can have a release where devector is available in a C++11 version. Ion has also most kindly agreed to help with this process. I will help write a new introduction that focuses on the main principles of devector. We also have a number of benchmarks which we can gather and use for a small section of on that topic. I'll leave it to you and Ion to work out the details. ========================== Detailed comments devector ========================== Apart from the merging with Boost.Container, the most heard complaint was about the "fat", the non-essential parts if the interface, that could be removed. This includes -- Remove the direct support for small buffer optimization form devector. When the time comes, provide small_devector similar to the way we have vector/small_vector (there is no requirement that small_devector is provided). -- remove all of the following: - all constructors that uses reserve_only_tag, - all constructors that uses unsafe_uninitialized_tag, - void unsafe_uninitialized_resize_front(size_type); - void unsafe_uninitialized_resize_back(size_type); - unsafe_push_front(...); - unsafe_push_back(...); -- add instead - constructors that uses default_init_t like boost.container - resize versions that uses default_init_t - T& unchecked_emplace_back(...) noexcept(...) - T& unchecked_emplace_front(...) noexcept(...) At some point, I hope we can upgrade default_init_t to mean no construction for all trivially copyable types. There was a wish for more symmetry in devector and so functions that break symmetry or can appear ambiguous should be removed. This means we should remove: -- capacity() There is no need for front_capacity() and back_capacity(). We could remove reserve(), but then we can't use devector with a flat_set. Reserve() should not be an alias for reserve_back() though, but controlled by the policy. We could remove resize(), but even deque has it where it means resize_back(). I totally agree it would be ideal to remove all of reserve(),resize(),capacity(),clear(), but I see no easy way we can use devector with flat containers if we remove the first and the last. Unless we start deprecating stuff in boost::deque/boost::vector and provide new consistent alternatives, we will never get a 100% satisfactory solution. At the end of the day, we need to be pragmatic, so if deprecation is not on the table, this seems the best we can do. Since we don't want two allocations implied by calling reserve_back() and reserve_front(), you can add a mechanism for doing that. That is, you can provide -- reserve( new_capacity ); -- reserve_front( new_front_capacity ) -- reserve_back( new_back_capacity ) -- reserve( new_front_capacity, new_back_capacity ) or, since reserve() is such a weird beast, simply provide -- reserve( new_capacity ); // for flat containers -- anticipate_front( new_front_elements ) -- anticipate_back( new_back_elements ) -- anticipate( new_front_elements, new_back_elements ) to get rid of the funky -- container.reserve_front( container.size() + new_front_elements ) dance. There were suggestions for shrink_back/front_to_fit, but since we are trying to remove fat, I suggest that we wait for a use-case. There were also suggestions that clear() should be amended. As the growth (or resizing policy) mandates what clear does, we need a way to escape. The minimal change that allows that is to provide -- clear( front_free_capacity ) which gives full power to the user. You may provide clear_back() as clear(0) and clear_front() as clear(c.size()+c.front_free_capacity()+c.back_free_capacity()). Ideally, clear() would have been removed entirely like capacity()/resize(), but like reserve(), it just seems like impossible when we start using it with flat containers. Other minor comments: - drop strong exception safety guarantees and do it like boost.container - prefer to make iterator a type (should be easy with reuse from boost::container::vector - allocator should not be inherted from - make clear O(1) amortized gurantees depend on growth policy - consider calling growth policy for resizing policy - make sure SFINAE works properly with constructors - make the default growth factor 2 (as we heard from Sean Parent: no factor below 2 is empirically good) - consider renaming front_free_capacity to free_front_capacity. Rationale: "front_capacity" is a concept, noun, and "free" is the adjective. Ditto for back_free_capacity. - remove size_type from growth policy and take it from the allocator - make the allocator template argument the 2nd argument - fix remaning TODO in code - documentation should not sell devector as drop-in replacement for vector, but rather stress it is not - the allocator supports needs to be improved. I guess doing it the Boost.Container way ensures that (ask Daniel James for help) - exception-safety issues pointed out by Ion - postconditions of insert/erase needs to specify behavior to front_free_capacity/back_free_capcity - use of local containers should be avoided - rotate should be avoided - delegate range move operations to those defined in Boost.Container - make sure all functions excepting non-overlapping range uses memcpy (not just memmove). This includes: - range constructor - copy-constructor - copy-assignment - range-assignment - range insert - destructor should used std::has_trivial_destructor to avoid loop in that case to make sure all compilers optimize it away (similar for erase). There is one final puzzle and that is the growth policy. I hope we can finalize that by testing Joaquin's and Ion's suggestions over the coming weeks. ============================= Detailed comments batch_deque ============================= For deque, the comments were similar, although there was far less to discuss than for devector. All agreed that one should be able to control the segment size. - stable_insert was not needed. - segment iteration was good, but should be usable with range-based for loop. The segment iterator should return a segment type if possible, and the segment should have begin(),end(),size() members. - since boost::deque already has a resize with default_init_t, that should be sufficient to provide fast serialization load for trivial types. No need for - resize_front - resize_back - unsafe_uninitialized_resize_front - unsafe_uninitialized_resize_back - reserve - shrink_to_fit() - capacity() The following are still needed for optimal code (or code that can be known not to reallocate, or for better locality in deserialization, avoiding double initialization) - free_front_capacity; - free_back_capacity; - reserve_front - reserve_back - unchecked_emplace_front - unchecked_emplace_back Boost.Container's unit-tests should be extended with those from batch_deque where it makes sense. Since segmented iteration was somewhat faster, it should be use internally where it makes sense. In particular - copy-constructor - copy-assignment - destructor As for devector, all constructor/functions that iterate over non-overlapping ranges should use memcpy. destructor should use is_trivially_destructible to ensure it is optimized away (similar for erase). ====================== Serialization comments ====================== I suggest that the default versions just do what Boost.Serialization does, perhaps just replacing resize with resize with default_init_t. That ensures it works correctly for all archive types. It also needs to use make_nvp() so the output is identical to std::vector. We will then talk to Robert about how we can take advantage of the binary archive in a correct fashion. ====================== kind regards Thorsten, review manager

3 3

[Container] Does deque allocate memory in default constructor?
by dariomt＠gmail.com 25 Oct '17

25 Oct '17

It seems std::deque implementations are allowed to allocate in the default constructor [1] However, boost::container::deque I think does not allocate in the default constructor, but the docs are not explicit about it. I can see in the docs: *Throws*: If allocator_type's default constructor throws. Which would mean that it cannot throw due to memory exhaustion, so it cannot allocate memory. Is my reasoning right? If yes, would it be possible to make this explicit in the docs? I think it is relevant, because it might be the deciding factor for switching from std::deque to boost::container::deque (as it might be my case). Thanks! [1] https://stackoverflow.com/questions/40203494/why-does-stddeque-allocate-mem…

2 1

Fwd: Boost compilation problems
by Berkus Karchebnyy 24 Oct '17

24 Oct '17

Hello, in attempt to build boost for android with more or less reasonable strict settings (-Werror) I uncovered some bugs which I cannot report on github because these projects have Issues disabled. I will post them here in hopes they will eventually reach appropriate maintainers. == ONE: boost.containers == clang-darwin.compile.c android-build/boost/bin.v2/ libs/container/build/clang-darwin-5.0~x86/debug/address- model-32/link-static/target-os-android/threading-multi/alloc_lib.o In file included from libs/container/src/alloc_lib.c:19: libs/container/src/dlmalloc_ext_2_8_6.c:1097:8: error: variable 'ret' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes- uninitialized] if (!PREACTION(m)) { ^~~~~~~~~~~~~ libs/container/src/dlmalloc_ext_2_8_6.c:1125:11: note: uninitialized use occurs here return ret; ^~~ libs/container/src/dlmalloc_ext_2_8_6.c:1097:4: note: remove the 'if' if its condition is always true if (!PREACTION(m)) { ^~~~~~~~~~~~~~~~~~~ libs/container/src/dlmalloc_ext_2_8_6.c:1095:4: note: variable 'ret' is declared here boost_cont_malloc_stats_t ret; ^ 1 error generated. "/usr/local/opt/android-ndk/android-ndk-r16-beta1// toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++" "-DBOOST_AC_USE_PTHREADS" "-DBOOST_SP_USE_PTHREADS" "-fvisibility=hidden" "-fvisibility-inlines-hidden" "-Wno-unused-local-typedef" -x c -O0 -g -O0 -fno-inline -Wall -g --target=i686-none-linux-android --gcc-toolchain=/usr/local/opt/android-ndk/android-ndk- r16-beta1//toolchains/x86-4.9/prebuilt/darwin-x86_64 --sysroot=/usr/local/opt/android-ndk/android-ndk-r16-beta1//sysroot -isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1// sources/cxx-stl/llvm-libc++/include -isystem /usr/local/opt/android-ndk/ android-ndk-r16-beta1//sources/cxx-stl/llvm-libc++abi/include -isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1//sources/android/support/include -isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1//sysroot/usr/include -isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1// sysroot/usr/include/i686-linux-android -DANDROID -D__ANDROID_API__=21 -ffunction-sections -funwind-tables -fstack-protector-strong -fno-limit-debug-info -fPIC -no-canonical-prefixes -mstackrealign -Wa,--noexecstack -Wformat -Werror=format-security -Wall -Werror -Wshadow -march=i686 -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTAINER_STATIC_LINK=1 -D_LITTLE_ENDIAN -I"." -c -o "android-build/boost/bin.v2/ libs/container/build/clang-darwin-5.0~x86/debug/address- model-32/link-static/target-os-android/threading-multi/alloc_lib.o" "libs/container/src/alloc_lib.c" == TWO: boost.serialization and monty python == (cue Benny Hill music) clang-darwin.compile.c++ android-build/boost/bin.v2/ libs/serialization/build/clang-darwin-5.0~x86/debug/ address-model-32/link-static/target-os-android/threading- multi/polymorphic_iarchive.o In file included from libs/serialization/src/polymorphic_iarchive.cpp:20: In file included from ./boost/archive/polymorphic_iarchive.hpp:32: ./boost/archive/detail/iserializer.hpp:69:7: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined] #if ! DONT_USE_HAS_NEW_OPERATOR ^ ./boost/archive/detail/iserializer.hpp:63:12: note: expanded from macro 'DONT_USE_HAS_NEW_OPERATOR' || defined(__SUNPRO_CC) && (__SUNPRO_CC < 0x590) \ ^ ./boost/archive/detail/iserializer.hpp:212:9: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined] #if DONT_USE_HAS_NEW_OPERATOR ^ ./boost/archive/detail/iserializer.hpp:63:12: note: expanded from macro 'DONT_USE_HAS_NEW_OPERATOR' || defined(__SUNPRO_CC) && (__SUNPRO_CC < 0x590) \ ^ 2 errors generated. "/usr/local/opt/android-ndk/android-ndk-r16-beta1// toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++" "-DBOOST_AC_USE_PTHREADS" "-DBOOST_SP_USE_PTHREADS" "-fvisibility=hidden" "-fvisibility-inlines-hidden" "-Wno-unused-local-typedef" -x c++ -ftemplate-depth-255 -fvisibility=hidden -fvisibility-inlines-hidden -std=c++14 -O0 -g -O0 -fno-inline -Wall -g --target=i686-none-linux-android --gcc-toolchain=/usr/local/opt/android-ndk/android-ndk- r16-beta1//toolchains/x86-4.9/prebuilt/darwin-x86_64 --sysroot=/usr/local/opt/android-ndk/android-ndk-r16-beta1//sysroot -isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1// sources/cxx-stl/llvm-libc++/include -isystem /usr/local/opt/android-ndk/ android-ndk-r16-beta1//sources/cxx-stl/llvm-libc++abi/include -isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1//sources/android/support/include -isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1//sysroot/usr/include -isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1// sysroot/usr/include/i686-linux-android -DANDROID -D__ANDROID_API__=21 -ffunction-sections -funwind-tables -fstack-protector-strong -fno-limit-debug-info -fPIC -no-canonical-prefixes -mstackrealign -Wa,--noexecstack -Wformat -Werror=format-security -Wall -Werror -Wshadow -march=i686 -DBOOST_ALL_NO_LIB=1 -D_LITTLE_ENDIAN -I"." -c -o "android-build/boost/bin.v2/libs/serialization/build/ clang-darwin-5.0~x86/debug/address-model-32/link-static/ target-os-android/threading-multi/polymorphic_iarchive.o" "libs/serialization/src/polymorphic_iarchive.cpp" == THREE: boost.program_options == clang-darwin.compile.c++ android-build/boost/bin.v2/ libs/program_options/build/clang-darwin-5.0~x86/debug/ address-model-32/link-stati c/target-os-android/threading-multi/cmdline.o libs/program_options/src/cmdline.cpp:104:41: error: declaration shadows a field of 'boost::program_options::detail::cmdline' [-Werror ,-Wshadow] cmdline::init(const vector<string>& args) ^ ./boost/program_options/detail/cmdline.hpp:139:34: note: previous declaration is here std::vector<std::string> args; ^ libs/program_options/src/cmdline.cpp:508:48: error: declaration shadows a field of 'boost::program_options::detail::cmdline' [-Werror ,-Wshadow] cmdline::parse_long_option(vector<string>& args) ^ ./boost/program_options/detail/cmdline.hpp:139:34: note: previous declaration is here std::vector<std::string> args; ^ libs/program_options/src/cmdline.cpp:545:49: error: declaration shadows a field of 'boost::program_options::detail::cmdline' [-Werror,-Wshadow] cmdline::parse_short_option(vector<string>& args) ^ ./boost/program_options/detail/cmdline.hpp:139:34: note: previous declaration is here std::vector<std::string> args; ^ libs/program_options/src/cmdline.cpp:611:47: error: declaration shadows a field of 'boost::program_options::detail::cmdline' [-Werror,-Wshadow] cmdline::parse_dos_option(vector<string>& args) ^ ./boost/program_options/detail/cmdline.hpp:139:34: note: previous declaration is here std::vector<std::string> args; ^ libs/program_options/src/cmdline.cpp:632:58: error: declaration shadows a field of 'boost::program_options::detail::cmdline' [-Werror,-Wshadow] cmdline::parse_disguised_long_option(vector<string>& args) ^ ./boost/program_options/detail/cmdline.hpp:139:34: note: previous declaration is here std::vector<std::string> args; ^ libs/program_options/src/cmdline.cpp:663:47: error: declaration shadows a field of 'boost::program_options::detail::cmdline' [-Werror,-Wshadow] cmdline::parse_terminator(vector<string>& args) ^ ./boost/program_options/detail/cmdline.hpp:139:34: note: previous declaration is here std::vector<std::string> args; ^ libs/program_options/src/cmdline.cpp:683:55: error: declaration shadows a field of 'boost::program_options::detail::cmdline' [-Werror,-Wshadow] cmdline::handle_additional_parser(vector<string>& args) ^ ./boost/program_options/detail/cmdline.hpp:139:34: note: previous declaration is here std::vector<std::string> args; ^ 7 errors generated. "/usr/local/opt/android-ndk/android-ndk-r16-beta1// toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++" "-DBOOST_AC_USE_PTHREADS" "-DBOOST_SP_USE_PTHREADS" "-fvisibility=hidden" "-fvisibility-inlines-hidden" "-Wno-unused-local-typedef" -x c++ -std=c++14 -O0 -g -O0 -fno-inline -Wall -g --target=i686-none-linux-android --gcc-toolchain=/usr/local/opt/android-ndk/android-ndk- r16-beta1//toolchains/x86-4.9/prebuilt/darwin-x86_64 --sysroot=/usr/local/opt/android-ndk/android-ndk-r16-beta1//sysroot -isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1// sources/cxx-stl/llvm-libc++/include -isystem /usr/local/opt/android-ndk/ android-ndk-r16-beta1//sources/cxx-stl/llvm-libc++abi/include -isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1//sources/android/support/include -isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1//sysroot/usr/include -isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1// sysroot/usr/include/i686-linux-android -DANDROID -D__ANDROID_API__=21 -ffunction-sections -funwind-tables -fstack-protector-strong -fno-limit-debug-info -fPIC -no-canonical-prefixes -mstackrealign -Wa,--noexecstack -Wformat -Werror=format-security -Wall -Werror -Wshadow -march=i686 -DBOOST_ALL_NO_LIB=1 -D_LITTLE_ENDIAN -I"." -c -o "android-build/boost/bin.v2/libs/program_options/build/ clang-darwin-5.0~x86/debug/address-model-32/link-static/ target-os-android/threading-multi/cmdline.o" "libs/program_options/src/ cmdline.cpp" The entire set of compile flags and NDK version can be seen in the provided snippets. Thanks. -- Sr. Software Engineer [image: twilio] <http://www.twilio.com/?utm_source=email_signature> EMAIL berkus(a)twilio.com

1 0

Help needed in learning to use Boost.Asio
by Osman Zakir 24 Oct '17

24 Oct '17

I want to learn how to use Boost.Asio so I can then create an abstraction layer over it for HTTP and create a server and client. I need it for a web app I want to make. I know C++ isn’t a good choice for this sort of thing, but it’s still growing and getting better, so I wonder if there’s really no hope for it becoming a better choice for web development. Especially if someone were to propose a networking library for boost that also provides support for the HTTP protocol and maybe also RESTful services out of the box. Libraries in Boost have a high chance of making it into the standard, after all, so this could be a good idea. I’ve heard from many people that C++ is a waste of time, especially if one wants to get into web development and make a lot of money. Most people who want to web development are abandoning C++ in favor of languages Python that provide better support for web development. I don’t like this and I hope that C++ will also become better for the job soon so that it can pull back programmers that have left it for other languages. That’s also the reason why I want to use C++ here. I’m hoping that the Networking TS would be standardized and that the standardizing committee would also do something to make C++ overall better for the web, preferably as good as Python if possible. The difficulty of getting into and using C++ is also overly-exaggerated but it seems to be more because of C++ programmers not making their code simple and beautiful enough, so it’s also the language users’ fault. I want to try to change the negative views that people have of C++, as well. By the way, would it be a good idea to send an email asking about the future of C++, especially for web development, to Dr. Stroustrup if I can find a way to contact him? I know he’s a busy man and I’m also reluctant to this, but since he’s also on the standard-making committee, if he finds some free time to reply to my email, he should be able to tell me what to expect about C++ and its future. I’m sorry if this email got too long, though. Best regards. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

5 7

boost asio
by Sharma, Nishant 23 Oct '17

23 Oct '17

Hi, I have created an Asynchronous TCP server and client and it works fine. Since it is asynchronous, it uses API's like async_read, async_write etc.. Is it possible that the same code be used to do "synchronous" communication which results in blocking any further task in the queue unless the current i/o task is complete ? I have attached the example hereby. It has two folder for server and client.. First the server needs to be run and then the client. Best Regards, Nishant Sharma

3 5

boost fileystem issue
by Olivier Tristan 20 Oct '17

20 Oct '17

Hi Guys, I would like to bump this particular issue that is quite annoying for me. Basically it crashes as soon as you call boost::filesystem::exists in the ctor of a static variable initialized at program startup https://svn.boost.org/trac10/ticket/12987 Looks like there was a fix 4 month ago but this hasn't been pushed into the trunk yet Any idea how to push the process forward ? Thanks ! -- Olivier Tristan Research & Development www.uvi.net

2 2

Reconnecting a SSL socket correctly
by David Demelier 18 Oct '17

18 Oct '17

Hello, I'm trying to reconnect a SSL socket (using ssl::stream with tcp::socket) that has been closed only remotely. It looks like a shutdown on my client causes "stream truncated" error so I have no idea how can I connect my client socket again. I was thinking of just creating a new instance but the stream class is not copyable. Do you have any recommandations? Regards, -- David

2 1

[asio] null reference in epoll_reactor
by Phil Sean 18 Oct '17

18 Oct '17

Hi, Running the tutorial async TCP server (http://www.boost.org/doc/libs/1_65_1/doc/html/boost_asio/tutorial/tutdaytim…) or any other asynchronous operation in valgrind yields an error like this: = Syscall param epoll_pwait(sigmask) points to unaddressable byte(s) = epoll_pwait (in /usr/lib/libc-2.26.so) = boost::asio::detail::epoll_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>&) (in /.../server) = boost::asio::detail::task_io_service::do_run_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service_thread_info&, boost::system::error_code const&) (in /.../server) = boost::asio::detail::task_io_service::run(boost::system::error_code&) (in /.../server) = boost::asio::io_service::run() (in /.../server) = main (in /.../server) = Address 0x0 is not stack'd, malloc'd or (recently) free'd I suspect it's due to some recent changes because it didn't use to be an error. Boost version is 1.65.1(Arch Linux). Thank you.

2 2

git clone of boost
by Tim Burgess 18 Oct '17

18 Oct '17

Hi, Just been trying to find the address to clone boost, but was unsuccessful. Can anybody help me out please? Best wishes. Tim Burgess

2 1