- Boost-users - lists.preview.boost.org

[asio] Does ssl::stream allow multiple pending async operations?
by Phil Sean 06 Nov '17

06 Nov '17

The documentation for ssl::stream says: "Shared objects: Unsafe. The application must also ensure that all asynchronous operations are performed within the same implicit or explicit strand." Does this mean we have to wait for an async operation to finish before another is started (for read/read, read/write, and write/write)? (Async operations refer to async_read_some() and async_write_some(), not the composed operations.) If so, is the operation said to have finished when the handler is invoked or when the handler returns? That is: void handler( const boost::system::error_code& error, std::size_t bytes_transferred ) { // Does the operation finish here ... } // or here? If not, what's the difference between the async operations of ip::tcp::socket and ssl::stream then (as strand just avoids concurrency for the thread-unsafe)? I came across different views on this problem. This answer[1] suggests that simply using the same strand (ie. no concurrency) will suffice. Another one[2] says multiple pending asynchronous operations can be problematic for ssl::stream even if no concurrency occurs. Thanks. [1] https://stackoverflow.com/questions/27212123/executing-asynchronous-operati… [2] https://stackoverflow.com/questions/15352472/using-boosts-ssl-asio-code-asy…

4 5

Spirit: how to force backtracking
by Stian Zeljko Vrba 04 Nov '17

04 Nov '17

I have the following grammar rule: value = (int_ % ',') | *ascii::print; The intention is to parse either a comma-separated list of integers or a string. The rule as such fails in cases like "123ABC", which should be parsed as string. >From the description of the | operator, I would expect the parser to backtrack and try the other alternative when it sees that the first alternative does not match the input. However, I get a parse error instead (this rule is a part of a larger grammar), I guess because the first alternative matches the single integer but the rest of the grammar cannot be matched. How to rewrite the grammar to resolve this ambiguity, or force spirit to backtrack if the first alternative of 'value' cannot be matched?

3 3

[locale] how to read a local date from an istream?
by Frédéric 02 Nov '17

02 Nov '17

Hi, With boost::locale we can output a localized date: double d=...; std::cout<<boost::locale::as::date<<d; but how can I read a date from a string? std::cin>>boost::locale::as::date>>d; does not work. It stops reading at the first "/". For example, this small program #include <iostream> #include <sstream> #include <boost/locale/formatting.hpp> #include <boost/locale/generator.hpp> int main(int argc, char **argv) { boost::locale::generator gen; gen.categories(); auto loc = gen(""); double date = 5.; // default value to see if it changes std::istringstream iss("2/11/2017"); // November 1st, 2017 in French iss.imbue(loc); iss >> boost::locale::as::date >> boost::locale::as::local_time >> date; std::cout.imbue(loc); std::cout << "as_posix: " << boost::locale::as::posix << date << "\n" << "as_date: " << boost::locale::as::date << date << "\n"; return 0; } outputs as_posix: 2 as_date: 01/01/1970 instead of as_posix: 1509617233 (may be different) as_date: 02/11/2017 F

1 0

Re: [Boost-users] Many undefined references for libboost_filesystem
by mahmood n 01 Nov '17

01 Nov '17

I used another gcc version 4.5 (Ubuntu 11.04) and it works without any problem! I don’t know what is wrong with gcc-4.6. Though the problematic platform was Kubuntuu 12.04. I am know trying with Ubuntu 12.04 which uses gcc-4.6 to see if it is really a gcc problem or the platform! Sent from Mail for Windows 10 From: Alex Perry Sent: Wednesday, October 18, 2017 4:45 PM To: mahmood n Subject: RE: [Boost-users] Many undefined references for libboost_filesystem Actually one other thought (though you may well have solved this by now). Are you sure that the boost libraries you are attempting to link to are using the same abi? Ie how were they built. I only glanced at the github stuff you pointed too but I think I remember that the last commit was 5 years ago or some such – so probably wasn’t using C++11. I note you are using an old (54) version of boost whilst the current is (65) so about 5 years ago as well – but that probably supported being built with c++11.so you might need to rebuild them if they were using a different version of the C++ standard (or any abi breaking change such as 32 vs 64 bit, static runtime vs dynamically loaded etc). Under windows boost normally encodes the abi into the library name and you just automagically (using a msvc extension) link to the appropriate one. That is not the normal way on linux since gcc doesn’t have autolinking so you normally end up sticking them into a separate lib directory and swapping the -L path depending on which abi you want Again though please note this is not boost specific – is just standard C / C++ / Fortran or any obj/link based language issues with building dependencies – (and why most have swapped to using cmake rather than vanilla make to avoid the pain). A. From: Alex Perry Sent: 17 October 2017 16:14 To: 'mahmood n' <nt_mahmood(a)yahoo.com> Subject: RE: [Boost-users] Many undefined references for libboost_filesystem Dropped the rest of the boost list since I’m sure not many are interested! > I didn’t want to have another pain for “finding how the verbose variable is set in the Makefile”!!! Not hard that one… just add it to the command line when you call make make verbose=1 ….. > The libraries do exist, so why on earth it can not link :( > mahmood@vb:AES$ g++ -fPIC -L/home/mahmood/boost_1_54_0/stage/lib -lboost_filesystem -lboost_system -m64 -o /home/mahmood/gpgpu-sim_distribution/ispass2009-benchmarks/bin/release/AES obj/x86_64/release/aescuda.cpp.o obj/x86_64/release/aesCudaUtils.cpp.o obj/x86_64/release/aesHost.cu.o -L/usr/local/cuda/lib64 -L/home/mahmood/NVIDIA_GPU_Computing_SDK/C/src//../lib -L/home/mahmood/NVIDIA_GPU_Computing_SDK/C/src//../common/lib/linux -L/home/mahmood/NVIDIA_GPU_Computing_SDK/C/src//../../shared//lib -lcudart -L/usr/local/cuda/lib64 -L/home/mahmood/NVIDIA_GPU_Computing_SDK/C/src//../lib -L/home/mahmood/NVIDIA_GPU_Computing_SDK/C/src//../common/lib/linux -L/home/mahmood/NVIDIA_GPU_Computing_SDK/C/src//../../shared//lib -lcudart -lcutil_x86_64 -lshrutil_x86_64 …. Nope the computer is telling you they don’t exist on those paths as given – unfortunately the computer is more likely to be correct than you on this! You have a lot of library paths being set there – possibly you have multiple versions of boost libraries so its finding the wrong one first so you have a version conflict Possibly the simplest way is create a noddy test and play with the command line till you work out what the problem is http://rextester.com/live/JDVHT54458 That will give you similar compile errors without -lboost_filesystem -lboost_system added to the compile line. Obviously that is using clang rather than gcc which you are using but the syntax and principles are pretty much the same between any c++ compiler HTH A.

5 6

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