August 2015 - Boost - lists.boost.org

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi Daryle, Any luck on your new setup? Gr, Olaf On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: > I can look at it once I've finished my new setup. > > I had to reset my computer after a partial crash years ago. I never > got around to recreating my programming setup. My computer had been > at its maximum Operating System level back then, which is now 3 > versions behind. For the past few months, I've had my sister's old > laptop, with Windows Vista, and am trying to add a programming setup > to it now. > > > On Tue, Nov 22, 2011 at 7:18 AM, Beman Dawes <bdawes(a)acm.org> wrote: >> Hi Daryle, >> >> This guy has volunteered to take over maintenance of Boost CRC. Should >> we take him up on his offer? > >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Nov 2, 2011 at 7:51 AM >> Subject: [boost] Boost CRC maintainer (Daryle Walker) missing in action? >> To: boost(a)lists.boost.org >> >> >> Hi, >> >> It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? >> >> No response to tickets from the past 3 years. What's the procedure in this case? >> >> https://svn.boost.org/trac/boost/ticket/2492 >> https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… > > -- > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT gmail DOT com -- Olaf

2 2

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

[multiprecision] uses boost::math::gcd without including the header
by Peter Dimov 04 Jan '16

04 Jan '16

include/boost/multiprecision/cpp_int/misc.hpp uses boost::math::gcd (and lcm), but does not include common_factor_rt.hpp.

2 2

[variant] Opinion on boost::safe_get<> and default boost::get<> behavior
by Antony Polukhin 18 Dec '15

18 Dec '15

Hi all, I'm in doubt and would like to hear opinions on the following issue. boost::get for boost::variant was not making any compile time checks, resulting in runtime errors where a compile time error must be: boost::variant<int, string> v(100); boost::get<bool>(&v); // returns NULL instead of compile time error boost::get<bool>(v); // throws exception on runtime instead of compile time error Now we have an implementation of compile time checked get in a separate branch at git: boost::variant<int, string> v(100); boost::safe_get<bool>(&v); // compile time error boost::safe_get<bool>(v); // compile time error boost::unsafe_get<bool>(&v); // returns NULL instead of compile time error boost::unsafe_get<bool>(v); // throws exception on runtime instead of compile time error I'm in doubt, what the default behavior of boost::get must be: * safe_get behavior is much closer to Standard Library behavior (just like std::get for tuples) and allows to avoid errors in user code * unsafe_get behavior is same as behavior of old boost::get and won't break user's code if boost::get is used in some generic contexs What's your opinion? -- Best regards, Antony Polukhin

10 13

[thread] Do we can a non backward compatible version with non-blocking futures?
by Vicente J. Botet Escriba 18 Oct '15

18 Oct '15

Hi, in Boost 1.58 I fixed some issues as the result of the async and future<T>:then() was not a blocking future as the documentation described. However the implementation is horrible and I suspect that it is subject to deadlocks. BTW, I added already some fixes on the develop branch. Sometime ago I started in a branch an implementation that don't use blocking futures [1]. Well the implementation is also horrible after making futures non-blocking, but less ;-) The problem is that now I have some issues with the executors :( Anyway, Gor has told me that with the blocking implementation he is unable to define await_suspend (using resumable functions) >It is just if .then returns a blocking future, I cannot subscribe a callback to .then in await_suspend. >await_suspend(f, cb) { > f.then(cb); >} &will block here preventing coroutine from suspending I don't know yet if he will reach to configure boost::future<T> on the non-blocking branch. My question is if the Boost community will accept (or even wants) a breaking change on a near release (when I would reach to fix the executors issues) including non-blocking futures instead of the current blocking futures. Best, Vicente [1] https://github.com/boostorg/thread/tree/feature/non_blocking_futures

3 13

[WG21 mailing] N4453 Resumable expressions
by Niall Douglas 15 Oct '15

15 Oct '15

I'm finding Chris' paper on resumable expressions instead of compiler magic created resumable functions awfully compelling: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4453.pdf I essentially proposed the same with my functionally composed constexpr basic_future design some months ago. Would anyone else like to comment on this library based instead of compiler based resumable execution? I'm not against some compiler support for resumable execution, but I am finding the await based proposal highly problematic, and Chris does an excellent job in summarising my own thoughts on what's wrong with it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 17

[AFIO] Formal review
by Jeremy Maitin-Shepard 12 Sep '15

12 Sep '15

> 1. Should Boost.AFIO be accepted into Boost? Please state all conditions for > acceptance explicity. In its current state, Boost.AFIO should NOT be accepted into Boost. However, I am confident that Niall will be able to deliver a future version of AFIO that should be accepted into Boost after another review. There is a great need for more powerful and efficient file handling functionality in C++ than is provided by iostreams and Boost.Filesystem/Filesystem TS. I appreciate the enormous complexity of trying to define a multi-platform filesystem interface, and it is clear that Niall has done a ton of very valuable research on this topic. > 2. What is your evaluation of the design? A key strength of the design is that it provides a common interface for asynchronous operations regardless of whether they are internally implemented using Windows IOCP support, async IO on FreeBSD, or regular POSIX operations via a thread pool. Another key strength is that it exposes handle-based (i.e. *at), rather than path-based APIs where possible in order to minimize race conditions, which tend to be difficult or impossible to avoid completely with file system operations. I do have a number of concerns about several aspects of the design, however: Batch API: - It is not clear what, if any, purpose the batch API serves. The significant added complexity of using it would have to be justified by a significant performance advantage, but it is not at all clear that there is even any performance advantage at all. - I suggest removing it unless there is a strong argument otherwise. File handle API: - The file handle abstraction in AFIO is very heavy weight, involving a shared_ptr to a structure containing a whole bunch of fields in addition to the native file handle, including a mutex, numerous flags, the path used to open it, a pointer to a handle to the parent directory, a chrono time_point specifying the time the file was opened, the total number of bytes read, written, and written since last fsync using this file handle. - Because file handles are at the core of AFIO, it is critical that users precisely understand what this abstraction involves, and specifically how it differs from a native file handle. - I'd be much more comfortable with a much leaner abstraction, like a unique_handle type that just contains the bare native handle, and uses unique ownership semantics. The fat handles impose both computational/memory overhead as well as mental overhead on the programmer. I understand these extra fields are probably necessary to provide various functionality, particularly emulation of behavior provided by other operating systems, but it would be nicer to be able to opt-in to such functionality and only pay for it when needed. - At the very least, if these fat file handles are kept, a very strong argument needs to be given as a rationale. (Perhaps you have found the overhead to be negligible relative to the cost of the native file handle.) - It should be possible to construct an AFIO handle from a native file descriptor. - On POSIX, AFIO should support supplying platform-specific open flags, like O_NOATIME. - I'd much prefer native_handle() to return the actual appropriate native handle type for the platform, e.g. int on POSIX, rather than a void *. I'm guessing this is done in order to support alternative dispatchers, that aren't necessarily based on OS files at all, in the future, but perhaps a better way of doing this that doesn't require casting the void* to an int, can be found. Future-based API: - I agree with Thomas Heller regarding the Future-based API: - The implicit future.then built into the API should be eliminated. Instead, API functions should take a file handle directly. - future<T> should not implicitly store a file handle. The API functions that open a file can return a future to a file_handle. API functions that don't open a new file should just return a future to the actual result. Inconsistency in how operations are defined: - Some operations are methods of the dispatcher, some are methods of the file handle, and others are free functions. - I suggest that all file system operations be free functions, and take a dispatcher as an argument. Thread-local current dispatcher: - Some operations involve an explicitly specified dispatcher, others seem to obtain it from the file handle, and others default to a thread-local dispatcher that has been set. - Given that it is extremely likely for user code to execute from multiple threads given the nature of AFIO, relying on a thread-local current dispatcher seems very error prone. - I suggest that the thread-local current dispatcher be eliminated, and that the dispatcher always be specified explicitly to any API call that requires one. Directory handle cache: - A cache of open handles to directories is kept by AFIO by default. This is particularly problematic because (as is documented) it makes reading directory entries thread-unsafe by default. If this is to be kept, a very strong rationale needs to be given, and the behavior must be changed somehow to ensure that directory reading is reliable by default. Enumerate API: - The future-based API of async_enumerate seems to be unnecessarily complicated, due to the need to specify maxitems and deal with making repeated calls, and all of the copying and memory allocation required to return a std::vector of directory_entry. I suggest instead something like passing in a std::function<bool (expected<directory_entry> const &next)> callback (possibly replacing expected by the new name for your monad type). An empty next value means end of directory has been reached. Returning true means continue listing the directory, returning false means stop listing the directory. Miscellaneous comments: - Operations including rmdir, rmfile, symlink, rmsymlink (as well as async variants) that normally would not necessarily even operate on file handles, actually return a handle_ptr. Perhaps if on some platforms a handle has to be opened, then there could be a way for the user to specify that a handle is desired. Otherwise, it would make sense to just return void or std::future<void> equivalent for async variants. - The documentation notes that on MS Windows, DOS short names are not supported. I don't have much familiarity with Windows, but if programs generally accept DOS short names when a filename is required, then AFIO should probably support these names as well. - The documentation notes: "Don't do directory enumerations from an x86 binary on a x64 Windows system. This is due to a bug in Microsoft's WOW64 syscall translation layer which Microsoft have decided is wontfix. " Given that a major purpose of AFIO is to provide a portable abstraction that works around OS limitations, AFIO needs to support directory enumeration even in this case (e.g. by detecting WOW64 and using a synchronous call via a threadpool in that case). - It is noted that to do an asynchronous stat you have to use enumerate with an appropriate glob specified, but constructing such a glob may be non-trivial if the path contains characters that are interpreted specially by the glob syntax, and impossible to do in a race-free manner. - As a general matter, it is important to provide leanest possible API that offers the most flexibility to users, in order to avoid the case that users choose not to use the library despite it offering a lot of functionality that is useful to them, because of excessive overhead or insufficiently powerful interfaces. I often forgo use of Boost Filesystem and C++ iostreams for this reason. 3. What is your evaluation of the implementation? - I understand that Niall already intends to rewrite much of the implementation, making much of the current implementation irrelevant. - As has been noted by other reviewers, there are a bunch of #if 0 blocks, many undocumented. Some seem to contain work in progress, which might better be placed in a separate branch. Some contain debugging code, in which case it might be better to replace #if 0 with #ifdef BOOST_AFIO_DEBUG_XXX where XXX specifies the particular feature being debugged. That way it is self-documenting. Some seem to contain alternate implementations. Ideally these would also be guarded by a descriptive macro, and a unit test case be defined that tests it as well to make sure it is still meaningful. Otherwise #if 0 code tends to bitrot, which admittedly is not such a great problem if it is just for debugging anyway, but I'd say it is less than optimal. - The implementation might be better split up into multiple independent files. There are various independent facilities, like secded_ecc, that could be placed in a separate file. - Although this tends to be a problem with most Boost libraries, it would be nice if the compile times could be reduced, particularly when not in header-only mode. Some libraries like Boost Spirit have an interface inherently based on template metaprogramming, such that long compile times are pretty much unavoidable, but the Boost AFIO interface seems to be mostly non-template based, which suggests that it may be possible to get pretty good compile times. > 4. What is your evaluation of the documentation? - The extensive documentation about race guarantees is extremely useful. - I appreciate the in-depth examples. - Much more design rationale is needed. - The term "filing system" is used in place of the more common "file system", leading me to wonder if there is a difference in meaning. - Every instance where there is a platform-specific #ifdef in an example should be evaluated, so that you can figure out the appropriate platform-independent abstraction that could be added to AFIO in order to move that #ifdef into the library and out of user code. - There is an attempt to document differences in behavior on different platforms, but this is not done sufficiently. For example, it is stated that async_write requires that the destination region does not go off the end of the file, but on POSIX pwrite supports this just fine as a way to extend the file. I assume that this restriction applies to Windows only. - The semantics of the Batch API are not precisely documented, nor is any rationale given for it. For instance, I understand that the operations themselves cannot happen atomically, since that is not supported by operating systems, though this is not clearly stated. It is stated: "Once a batch of input ops has been verified at the point of entry as not errored, you are guaranteed that the batch is atomically scheduled as a whole, unless a failure to allocate memory occurs." Does this means that if the *_req object involves futures, it waits for all of them to be ready before launching any of the operations in the batch? Is that the purpose of the Batch API, to do a wait_all on all of the relevant futures, then to launch each operation? This issue goes away though if the Batch API is eliminated, as seems to make sense. - It would be useful to document for each operation which underlying system calls it invokes on each platform. - Many operations other than open (e.g. rmfile) take file_flags, but it is not specified which flags are supported. - References to historical versions of AFIO (prior to the review) should be removed from the main parts of the documentation, since they only distract from the useful information. This information could be kept in a different section at the end for the extra curious. - Formatting of the "description" in the Boost Quickbook format function documentation has some problems: the lack of line breaks between the general description, other notes, and the common note about the use of NT kernel paths make it difficult to read. > 5. What is your evaluation of the potential usefulness of the library? The library is potentially extremely useful. C++ and Boost iostreams and Boost/TS Filesystem provide only very limited functionality. The C library libuv is a close competitor but seems to offer less functionality and a less convenient API. For achieving similar functionality, the status quo in C++ is to rely on platform-specific C APIs that are much more cumbersome to use. > 6. Did you try to use the library? With what compiler? Did you have any problems? I tried some very simple usage of the library with GCC 5.2.0 on Linux. There were a few warnings (variable set but not used) with -Wall that would be best eliminated. - The error messages are not ideal: for instance, in the case that there was an error opening a file, this is the result: Dynamic exception type: boost::system::system_error std::exception::what: File '/home/jbms/tmp/afio-test/test.txt' not found [Host OS Error: No such file or directory (2) in '/home/jbms/tmp/boost.afio/include/boost/afio/v2/detail/impl/afio.ipp': async_io_handle_posix:805]: No such file or directory. Op was scheduled at: 1. 0x42fb4f: ./test (+0x2fb4f) : No such file or directory Some of this is only useful when debugging AFIO, some only useful when debugging the application, and there is a lot of redundancy, for instance the actual error "No such file or directory" is shown in 3 places. Ideally there would be a way to get a simple message along the lines of "Error opening file '/home/jbms/tmp/afio-test/test.txt': No such file or directory" that could be shown directly to the user. I tried to #define BOOST_AFIO_EXCEPTION_DISABLESOURCEINFO to see if that would make the error message better, but instead that seemed to trigger a bug: Dynamic exception type: std::logic_error std::exception::what: basic_string::_S_construct null not valid - A separate issue is that attempting to read a range that is not present in a file, something that the library should handle elegantly, leads to the program aborting immediately with an error message, rather than allowing the error to be handled: FATAL EXCEPTION: Failed to read all buffers 1. 0x40f0f4: ./test (+0xf0f4) terminate called after throwing an instance of 'std::runtime_error' what(): Failed to read all buffers zsh: abort (core dumped) ./test > 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I gave the library a fairly in-depth study, spending at least 8 hours in total. I looked at the documentation fairly thoroughly, looked through parts of the implementation, and tried running a couple small programs that use the library. > 8. Are you knowledgeable about the problem domain? I have a fair amount of experience with asynchronous programming in C++, and I have pretty extensive knowledge of the file system APIs on Linux. As a final note, I'd like to thank Niall for all of the work he has done to get the library this far. A powerful, elegant, cross-platform interface for file system operations is very much needed in C++, I really do want to see (a future version of) this library in Boost and use it myself.

11 32

boost::python::make_setter(&X::y) no longer compiles
by Jonathan Wakely 02 Sep '15

02 Sep '15

This compiled with 1,58, it doesn't with 1.59: #include <boost/python.hpp> struct X { int y; }; int main() { boost::python::make_setter(&X::y); } Is this intentional? Is it documented somewhere? The examples in the docs still seem to use this form.

1 1

[afio] Formal review of Boost.AFIO
by Ahmed Charles 02 Sep '15

02 Sep '15

The formal review of the Boost.AFIO library starts, August 21st and ends on Monday August 31st. Boost.AFIO provides a portable API implementing synchronous and asynchronous race-free filesystem and scatter-gather file i/o. It requires a minimum of C++ 11. It has minimum dependencies on a Filesystem TS and a Networking TS implementation (e.g. Boost.Filesystem and Boost.ASIO). Backends are provided for the Windows NT kernel and POSIX. The utility of a portable library providing strong concurrent race guarantees about filesystem and file i/o can be seen in its tutorial where a transactional ACID key-value store is built from first principles. Boost.AFIO was brought to Boost as part of GSoC 2013 and Niall Douglas has continued to develop and improve the library since then, generating two internal implementation libraries Boost.APIBind and Boost.Monad which are expected to be separately brought for Boost review in 2016. The documentation can be found here: https://boostgsoc13.github.io/boost.afio/doc/html/afio.html The source code can be found here: https://github.com/BoostGSoC13/boost.afio/tree/boost-peer-review Online web compiler playpen can be found here: http://melpon.org/wandbox/permlink/DR8wCpu5Rl20GMdM? Please answer the following questions: 1. Should Boost.AFIO be accepted into Boost? Please state all conditions for acceptance explicity. 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. What is your evaluation of the potential usefulness of the library? 6. Did you try to use the library? With what compiler? Did you have any problems? 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 8. Are you knowledgeable about the problem domain?

30 191

[AFIO] Formal review
by Antony Polukhin 01 Sep '15

01 Sep '15

> 1. Should Boost.AFIO be accepted into Boost? This library must be in Boost, but not in it's current state. Some polishing required and some improvements. Dependent libraries must be accepted in Boost/dropped/documented and reviewed as part of AFIO. After that another review must be done. So it's NO for now. > 2. What is your evaluation of the design? NONBACTH operations seem right and good. Some simplification must be applied, by possibly removing some of the overloads and reducing amount of types visible to user (`handle_ptr`, `*_req`). BATCH operations do not seem right. They must be removed or their interface must be greatly reworked. afio::path must be hidden from user or filesystem::path must be used (I'm not 100% sure, but it looks like `\\?\` paths are OK to be in filesystem::path http://www.boost.org/doc/libs/1_59_0/libs/filesystem/doc/reference.html#lon… ). More functions for everyday use may be provided (async_copy for example) > 3. What is your evaluation of the implementation? Header files must be split into multiple smaller ones. Multiple memory allocations must be removed from library internals. Implementation must be polished. Recommendation: ABI stable part of AFIO may be moved in a separate git branch to untie the AFIO library developer's hands. In that case new version of AFIO may break the ABI without affecting users and older versions could be removed from sources. > 4. What is your evaluation of the documentation? That's one of the biggest problems of the library. Documentation is not structured and sometimes overcomplicated. Some notes for simplification: * "AFIO single page cheat sheet for the very impatient" -> "Getting started". Move table to the top of the page, replace the "Related types" column with "Boost.Filesystem sync alternative", replace numbers with checks/+/-. * Move the "Example mini-programs written using AFIO" chapter right after the "Getting started", rename chapter into "Tutorial", refactor second example to not use batch operations and to use only free standing functions. Third and fourth examples must be greatly simplified and probably split into smaller examples. * Move the content of "Step by step workshop building an AFIO-based key-value store" into the "Tutorial" after the previous examples, rename it into "Key-value store walkthrough", simplify and make shorter if possible * "Compilation" section must be somewhere around "Getting started" * Other docs must be after the "Getting Started," "Tutorial" and "Compilation" * "Reference" section must be refactored. All the overloads must be probably described and showed on a single page (all the overloads, including those that explicitly accept dispatcher) * Shorten and simplify the examples wherever possible. > 5. What is your evaluation of the potential usefulness of the library? Very very useful. > 6. Did you try to use the library? No. > 7. How much effort did you put into your evaluation? About 20 hours. > 8. Are you knowledgeable about the problem domain? I have a fair amount of experience with asynchronous programming in C++ and I have pretty extensive experience with designing interfaces for async operations. Have not dealt with async fiesystem operations before. -- Best regards, Antony Polukhin

2 1

[math] lcm errors
by Damian Vicino 31 Aug '15

31 Aug '15

Hi, I found out, lcm (RT) is silent about errors. (the bad way) Is there any way to activate them? For example, the following code: #include<iostream> #include <boost/math/common_factor.hpp> int main () { int a = 1<<30; int b = 3; int c = boost::math::lcm(a, b); std::cout << "lcm of :" << a << " & " << b << " is " << c << std::endl; return 0; } Obtains the following result: lcm of :1073741824 & 3 is 1073741824 Which is not the right answer (because it is not divisible by 3), but neither it raised an exception or returned some special value. Is there any way I can make it raise an exception? I guess I could check everywhere it as: if (c%a != 0 || c%b != 1) throw std::exception(); But probably there is something implemented that I couldn’t find in the documentation. Best regards, Damian

2 1

[asio] MSVC compiler error when compiling urdl
by Christian Henning 31 Aug '15

31 Aug '15

So URDL (https://github.com/chriskohlhoff/urdl ) is not part of boost, I know. But a nasty MSVC 2013 compiler error prevents the most simple code to compile. #define _WIN32_WINNT 0x0601 #define URDL_HEADER_ONLY 1 #define URDL_DISABLE_SSL 1 #include <urdl/istream.hpp> #include <boost/progress.hpp> #include <iostream> #include <fstream> int main(int argc, char* argv[]) { return 0; } The fix is relatively simple but it would change code is asio's handler_invoke_helpers.hpp. Basically change: using boost::asio::asio_handler_invoke; asio_handler_invoke(function, boost::asio::detail::addressof(context)); to boost::asio::asio_handler_invoke(function, boost::asio::detail::addressof(context)); I'm using VC2013. I'm using master branch of boost. Regards, Christian

2 1

Re: [boost] [afio] Formal review of Boost.AFIO
by Sebastian Theophil 31 Aug '15

31 Aug '15

-- Dr. Sebastian Theophil | stheophil(a)think-cell.com<mailto:stheophil@think-cell.com> Senior Software Engineer We are looking for C++ Developers: http://www.think-cell.com/career ________________________________ think-cell Software GmbH http://www.think-cell.com<http://www.think-cell.com/> Chausseestr. 8/E phone / fax +49 30 666473-10 / -19 10115 Berlin, Germany US phone / fax +1 800 891 8091 / +1 212 504 3039 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schödl On 27 Aug 2015, at 04:45, boost-request(a)lists.boost.org<mailto:boost-request@lists.boost.org> wrote: Ok, let's revisit the original pattern code I mentioned: EXAMPLE A: shared_future h=async_file("niall.txt"); // Perform these in any order the OS thinks best for(size_t n=0; n<100; n++) async_read(h, buffer[n], 1, n*4096); Niall, is parallel read (parallel writing maybe?) the only use-case where you want a shared_future? If I understand Thomas correctly, he doubts you need the shared_future semantics because one async operation hands down a single handle to the next continuation. Essentially something like: async_file(“niall.txt”) .async_read(buffer, length_to_read) .async_truncate(length_to_read) .async_close() Your counter example was an asynchronous *and* parallel read where you need to share the file handle (or rather the future<handle>) between parallel reads. Shouldn’t this be abstracted away in the API somehow? I can’t think of many file operations you want to do N times in parallel. Truncating a file in parallel several times doesn’t seem to make much sense :-) So why not make it: async_file(“niall.txt”) // Read 100 times asynchrnously and in parallel and provide lambda returning n-th buffer and offset: .async_parallel_read(100, [&](int nCount) { return std::make_pair(buffer[n], n*4096; }) .async_truncate(length_to_read) .async_close() The 100 reads are internally not ordered but they can only begin once the file has been opened, they consume this handle together, and only after all reads are complete can we truncate. Is this not what you’re trying to do? Regards Sebastian

3 7

[AFIO] Review (or lack of it)
by Roland Bock 31 Aug '15

31 Aug '15

Hi, I vote for "No, the library should not be accepted". I do not vote this way because the library is bad. I do so because I have no way of telling. a) There is so much going on about personal hardships (e.g. hundreds of hours of family time and 12-4am sessions and fried disks and no electricity and suspected vendettas and supposedly useless reviews). None of this has anything to do with a library review. Why mention it, even if you feel it? All of this is bound to make it hard to be impartial. b) AFIO depends on other libraries which are probably going to be proposed for boost, but are not in yet. Regardless of whether there is a precedent or not, this is far from being ideal. Judging by the discussion about "Monad", getting that library into boost is not just a mere formality. Thus, Monad implicitly IS part of the review, because if it is not accepted (which we don't know today), it will become part of AFIO. Thus, the scope of the review is not defined correctly. c) There are older versions in there. There is 1.3 and 1.4 at least (are there more?). Please choose one. Go for it. Of course, boost libraries evolve over time. There will be new versions of the interface. But starting with that kind of baggage? And asking for a review that necessarily has to cover everything that is currently available? d) The implementation of 1.4 will be replaced completely. Thus, the implementation (which I consider an important part of the review), cannot be reviewed in any way that is worth anyone's time. e) Documentation * Please drop the "using namespace XYZ" from all examples. Maybe use namespace aliases. * The "cheat-sheet" for the impatient is beyond me. I have no idea what it is trying to convey. * I would certainly prefer ONE page with planned features, not sprinkled info here and there (especially not on the cheat sheet). * Redundancy: For example, all the dir() functions share the same example, don't they? I haven't done a diff and I won't. But it makes me nervous to see the same example over and over again. Why not make one page explaining all the dir() functions and then use ONE example? Also the "Note that ..." text seems to be the same on all pages. This piles up to wonderfully large amounts of documentation, but I have no intention to reading all of that ever repeating stuff trying to find the needle in the haystack that actually contains different information. This has to be condensed. * There are deprecated functions? Again, I strongly recommend to start without the extra baggage. * The mix of history and rationale is hard to read, IMO. I'd be interested in the rationale, but not in the many steps it took to get there. * I do not get the world's simplest blob store in the STL form. It is most definitely not the simplest blob store. Not even the simplest persistent blob store. Why would I need a monad there? Why is there a writable flag (why isn't constness enough to prevent writing)? Why isn't the directory created at construction once and for all? BTW: The name validation fails to check for empty string. * https://boostgsoc13.github.io/boost.afio/doc/html/afio/quickstart/workshop/… mentions AFIO v1.40 (thats 36 numbers in the future). If the pictures are not loaded, the performance numbers in the table do not say what they are (the per sec is missing). * "The /final/ named blob store design" starts with "Caution: This section was not finished". * "The performance of and problems with this third generation design" consists of "This section was not completed in time[...]" * So basically the crucial parts of the blob store sequence are incomplete at best. f) Code (since the implementation is going to change anyway, this might all be useless): * /attic: Seriously? * I am not a big fan of #if 0 in release code * I doubt that std::cerr should be in this library's code. * I wonder why there really is a need to have your own path stuff on top of boost::filesystem. If boost::filesystem is insufficient, wouldn't it be better to contribute to that one? Haven't looked too closely, though. * I looked briefly into detail/. I would not want to look for a bug there. I have not done any detailed analysis to base this on, but: I would assume that with some refactoring (moving the platform specific parts into platform specific headers), the readability could be increased dramatically. Again: This is just a guess. In the current situation, I cannot do a formal review that would result in acceptance. I recommend to treat the current review period as a pre-review and * Do a review of Monad (or whatever it will be named) first, maybe API Bind, too, depending on whether that is going to be used in AFIO * Remove all old versions, everything deprecated and do the implementation change that is planned * Cleanup the documentation. Get it read by people with different knowledge of the problem domain. I am willing to read it as somebody who is interested but certainly not very knowledgeable. * Let the dust settle a bit * Start a new review * Even if you believe in vendettas, stay calm and answer in a matter-of-fact way. My experience with the boost list is, that there are strong voices here which have a very finely tuned sense of fairness. I did invest several hours in this review, reading the mail threads, reading the documentation, looking through some code, writing this mail. As stated above, I do consider myself interested but not very knowledgeable in the problem domain. I would like to see a library for asynchronous file IO in boost, but I don't think AFIO is ready yet. Regards, Roland

12 41

[afio] running tests
by Michael Caisse 30 Aug '15

30 Aug '15

Hi Niall - I'm trying to run the tests. I'm certain I am just doing something really silly... input is welcome! I have dropped the AFIO repo into a libs/afio directory for the super project. I ran ./b2 headers which linked in the boost/afio bits. I then go to libs/afio/test and execute "b2 release" which unfortunately results in: find: libs/afio: No such file or directory Performing configuration checks ... This is the same way I run other library tests and those are working as normal. Is there some other setup step that I'm forgetting? Thanks! michael -- Michael Caisse ciere consulting ciere.com

4 4

AFIO review response
by Hartmut Kaiser 30 Aug '15

30 Aug '15

This is my (sadly very short) AFIO review. I vote NO (to not accept) the library into Boost as I'm not able to tell whether the library is useful and fit for Boost. Reason: I tried to understand the design and rationale of the library and asked a number of questions on this list to clarify things I didn't understand. Sadly, the author decided not to answer a single of my questions (not even did he directly respond to any of my emails). I'm not able to make an educated decision on any of the review criteria without having the questions answered which I asked. The reason I send my review now is that I have to make this decision today. I'll not be able to spend any more time on this before the review period ends. So far, I have invested a couple of hours reading through the documentation, following the email threads, and thinking about the design I saw. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

12 20

[android][regression] bjam failed
by Dmitry Moskalchuk 30 Aug '15

30 Aug '15

Hello, Today I've experienced problems with Android regression tests on 'develop' ('master' is OK, and 'develop' was OK too for long time): ERROR: Bjam failed (see /home/cislave/.crystax/ci-boost/regression/android-21-armeabi-v7a-hard-develop/test/develop/regression/armeabi-v7a-hard/test/results/bjam.log for full details): - BOOST_OS_LINUX == 0 : yes - BOOST_COMP_GNUC >= 4.7.4 : no - BOOST_COMP_GNUC >= 4.3.0 : no - BOOST_COMP_GNUC >= 4.3 : no - BOOST_OS_QNX == 0 : yes - zlib : yes warn: Unable to construct ../libs/predef/test/info_as_objcpp warn: Unable to construct ../libs/predef/test/info_as_objc error: Name clash for '<p/home/cislave/.crystax/ci-boost/regression/android-21-armeabi-v7a-hard-develop/test/develop/regression/armeabi-v7a-hard/test/boost_root/bin.v2/libs/dll/test>libtest_library.so.1.59.0' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <cxxflags>-Wall -Wextra -pedantic -Wno-long-long <library>object(file-target)@57008 <library>object(file-target)@57040 <toolset-gcc:version>4.9 <toolset>gcc <xdll-path>/home/cislave/.crystax/ci-boost/regression/android-21-armeabi-v7a-hard-develop/test/develop/regression/armeabi-v7a-hard/test/results/boost/bin.v2/libs/filesystem/build/gcc-4.9/release/abi-aapcs/target-os-android/threading-multi <xdll-path>/home/cislave/.crystax/ci-boost/regression/android-21-armeabi-v7a-hard-develop/test/develop/regression/armeabi-v7a-hard/test/results/boost/bin.v2/libs/system/build/gcc-4.9/release/abi-aapcs/target-os-android/threading-multi error: - <library>object(file-target)@332654 <library>object(file-target)@332686 <toolset-clang:platform>linux <toolset-clang:version>3.6 <toolset>clang <xdll-path>/home/cislave/.crystax/ci-boost/regression/android-21-armeabi-v7a-hard-develop/test/develop/regression/armeabi-v7a-hard/test/results/boost/bin.v2/libs/filesystem/build/clang-linux-3.6/release/abi-aapcs/target-os-android/threading-multi <xdll-path>/home/cislave/.crystax/ci-boost/regression/android-21-armeabi-v7a-hard-develop/test/develop/regression/armeabi-v7a-hard/test/results/boost/bin.v2/libs/system/build/clang-linux-3.6/release/abi-aapcs/target-os-android/threading-multi error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. Does anyone know what that means and how to fix it? I suspect this is result of recent update related to Boost.Dll, but I don't know if that's error in our scripts, preparing testing environment, or error in Boost itself. -- Dmitry Moskalchuk

1 0

[Proposal] BOOST_NO_GLOBAL_FILESYSTEM_NAMESPACE
by Ed Schouten 30 Aug '15

30 Aug '15

Hi there, I'm currently in the process of porting the Boost libraries to a new platform called CloudABI. CloudABI is a POSIX-like runtime environment that is purely built on the concept of capability-based security. In a nutshell, it means that actions that have side-effects outside of a process can only be performed if the process owns a capability (a file descriptor). In other words, open() is missing, but openat() is still there. There are only local filesystem namespaces. CloudABI allows you to reduce the impact of security exploits through sandboxing, but also makes it possible to safely run untrusted third-party applications without requiring any virtualization, containers, etc. Be sure to check out the GitHub page for more details: https://github.com/NuxiNL/cloudlibc The other day I started experimenting with getting Boost working on CloudABI and I noticed that most of the Boost sources already build on CloudABI. I somewhat expected this, because Boost sources tend to be written in a loosely coupled, testable way. But still, hats off to the Boost developers! The biggest showstopper -- as expected -- is boost::filesystem, which will likely never work on CloudABI: https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/q1F0KDEBtf… But in many cases there are also classes that can optionally access the filesystem through utility functions (boost::locale::gnu_gettext, boost::program_options::parse_config_file(), etc). The reason why I'm sending this email is because I want to propose adding a new configuration option, BOOST_NO_GLOBAL_FILESYSTEM_NAMESPACE, that I can use to conditionally disable such utility functions. I've attached a patch for Boost.Config to this email. Does this approach seem reasonable? Do we like the name of this build option? Does the patch look all right? It seems as if generate.cpp also made some unnecessary changes to these files. What's up with that? Best regards, -- Ed Schouten <ed(a)nuxi.nl> Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717

1 1

Re: [boost] [afio] AFIO review postponed till Monday
by Glen Fernandes 29 Aug '15

29 Aug '15

Did the review start yesterday? Glen

18 84

Request for help in porting colony to boost from experienced container boost dev
by Soul Studios 29 Aug '15

29 Aug '15

Hi all- I require help in adapting colony to the boost framework, as colony is light on dependencies, as per the boost recommendations, whereas the boost containers are extremely dependency-heavy - which is somewhat confusing. I need somebody who has some experience with writing or editing the boost containers, to help me sort this from that, wrong practice from right practice in this area. It is, perhaps, something I could spend half a year trying to understand, but unfortunately I do not have that luxury. Whoever helps me will of course get credit for their involvement, with my gratitude. If yourself or anyone you know can help, please get them or yourself in touch. If anyone is interested, my initial port of colony to boost is at the following github repository: https://github.com/mattreecebentley/boost_colony It is an incomplete port but functional. I posted to the boost-users list about colony previously, if anyone is unsure about what it is please see the website (plflib.org) for benchmarks, overview reasoning and code- Thanks, Matt

3 16

Merging pull requests in boostorg/boost
by Antony Polukhin 28 Aug '15

28 Aug '15

Hi, Could someone review and merge the following pull request https://github.com/boostorg/boost/pull/94 ? I do hope to see Boost.DLL in next release, but that requires a lot of testing on different platforms (and that requires the pull request merged). There are also some pending Boost.Compute pull requests, please take a look at them too. -- Best regards, Antony Polukhin

1 0

Feature macro for putting things in the std namespace
by Mathias Gaunard 28 Aug '15

28 Aug '15

Hi all, I'm working on providing support in Boost for a new standard library provider, which happens to put some but not all of its symbols in the 'std' namespace. As a result, opening the 'std' namespace and forward-declaring or specializing things would not work. It seems a number of Boost libraries do this (most notably Boost.Container), with special code to deal with libc++ (since libc++ puts everything under an inline namespace). I think it would make more sense to have a BOOST_HAS_SYMBOLS_IN_STD_NAMESPACE feature macro that one could check to tell whether it is possible or not to do that. In the case of forward-declarations, the library would have to fall back to including the appropriate headers if that feature macro is not set. Is everyone on board with this? Any recommendation for the name?

4 8

Interest in adding support for the Bloomberg Standard Library
by Mathias Gaunard 28 Aug '15

28 Aug '15

Bloomberg has its own C++ standard library, BSL, which sits on top of another standard library but replaces containers with their own versions. The BSL containers are somewhat similar to Boost.Container's: they provide stateful allocators, as well as backport some C++11 extensions to C++03. Before I make all the necessary changes and do a pull request, I would like to make sure the Boost community would be ok in including support for this in Boost.Config. This library is fairly specific to one company and not used much elsewhere, despite being open-source (<https://github.com/bloomberg/bde>). We are also trying to phase out usage of this library with the 'std' namespace (it can be configured to use the 'bsl' namespace instead), but that's likely not going to happen anytime soon. As part as providing support for this in Boost, we would also be providing testers, mostly on big iron unix (AIX-powerpc, SunOS-sparc). Any interest?

3 4

Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
by Niall Douglas 28 Aug '15

28 Aug '15

On 25 Aug 2015 at 8:17, Robert Ramey wrote: > > Please answer the following questions: > > > > 1. Should Boost.AFIO be accepted into Boost? Please state all > > conditions for acceptance explicity. > > > > Provisionally, yes. > > > > Requirements: > <snip> > > This list of requirements constitutes much more than a "a few changes". > It's impossible to know what what the library would like like after > all these changes and and their repercussions were addressed. I don't > think we can realistically expect the review manager to verify that and > library with all these changes is sufficiently close the current one to > take responsibility for signing off on the final version. I read the provisional yes as meaning yes to how the library is roadmapped to look like in the future, and he recommends an additional mini-review at that point which could introduce yet another mini-review after again. In other words, he's saying fundamentally it's good, but needs a lot more work yet. Paul please do correct me if I am wrong in this interpretation. There is precedent for this: Boost.Fiber was provisionally approved here as a C++ 98 library with condition of a mini-review before entry. Boost.Fiber is now a C++ 14 library and sufficiently different from the library originally reviewed it may require a second mini-review if during its first mini-review it is felt still lacking. I think this pattern of repeated mini-reviews caused by changes to the common implementations of the C++ standard rather than the libraries themselves is going to be very common next few years. All these changes to AFIO are almost entirely driven by changes since 2012 to the various WG21 technical standards. If they hadn't changed and C++ compilers (specifically MSVC) hadn't changed, AFIO wouldn't have changed. It's very similar for Fiber, which had to be refactored in the face of substantial changes in C++ 14. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

7 16

[http] Formal review of Boost.Http
by Bjorn Reese 28 Aug '15

28 Aug '15

Dear Boost and ASIO communities. The formal review of Vinícius dos Santos Oliveira's Boost.Http library starts today, August 7th and ends on Sunday August 16th. Boost.Http is designed for various forms of modern HTTP interaction, from normal HTTP request, over HTTP chunking and pipelining, to upgrading to other web protocols like WebSocket. This library builds on top of Boost.ASIO, and follows the threading model of ASIO. The two basic building-blocks are http::socket, which is socket that talks HTTP, and http::message with contains HTTP meta-data and body information. You can use these building-blocks to build a HTTP server that fits your exact needs; for instance, an embedded HTTP server for a ReST API. Boost.Http comes with a light-weight HTTP server and a static file server. Currently, Boost.Http is limited to server-side interaction, but the design principles used extends to client-side as well. Boost.Http was originally developed as part of GSoC 2014 and Vinícius has continued to develop and improve the library since then. The documentation can be found here: http://boostgsoc14.github.io/boost.http/ The source code can be found here: https://github.com/BoostGSoC14/boost.http The source code is build using CMake, but Boost.Build is in the pipeline (already done for documentation.) Please answer the following questions: 1. Should Boost.Http be accepted into Boost? Please state all conditions for acceptance explicity. 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. What is your evaluation of the potential usefulness of the library? 6. Did you try to use the library? With what compiler? Did you have any problems? 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 8. Are you knowledgeable about the problem domain?

17 58

[http] Boost.Http review report
by Bjorn Reese 28 Aug '15

28 Aug '15

The outcome of the formal review of Boost.Http is that the library is NOT accepted for inclusion into Boost this time. Below I will first summarize the main themes running through the review, and afterwards I will make some recommendations about how to proceed from here. The following reviews were posted: - Antony Polukhin: No - Darren Cook: No - David Sankel: No - Lee Clagett: No - Niall Douglas: Yes, conditionally - Roland Bock: No - Tom Kent: No The discussions were constructive and offered much valuable feedback. There was a general consensus that Boost ought have a HTTP library, but that Boost.Http was too incomplete in its present state. Many reviewers mentioned the disconnect between their expectations and what the library offered. There were several suggestions for alternative names for the library to better reflect the feature-set it offers. Boost.Http currently only provides a server-side API, but the reviewers felt that a client-side API would be usable to more users. There was also a recurring request for Boost.Http to be a header-only library. The HTTP parser currently used is not header-only and that is the main obstacle towards a header-only Boost.Http library. Some of the discussion revolved around what level of abstraction would be appropriate for Boost.Http. The views ranged from wanting higher- level APIs all the way down to simply wanting a HTTP parser/generator and then leave all the socket and buffer management up to the user. Regarding the HTTP parser/generator, there is no reason why it cannot be a separate Boost library. However, Vinicius correctly pointed out that this is insufficient for a HTTP server framework that handles multipleback-ends (e.g. HTTP/2, FastCGI, or WebSocket). By implication it cannot handle HTTP upgrade requests either. Some reviewers also felt that HTTP/2 should be part of Boost.Http, partly because that would demonstrate the extensibility of the current design, and partly because the library would be in a stronger position to attract users if it offers more than its competitors. There was concern about whether or not the Boost.Http API can be extended to HTTP/2. The main challenge with HTTP/2 is fitting multiplexing into the API. Vinicius suggested that there should be a http::socket per multiplexed channel, so it will be transparent to the user if several of his http::sockets to the same remote endpoint are transported via the same TCP socket. This will keep the API clean when extended to HTTP/2. Boost.Http currently creates an associative array for all header fields. One reviewer explored the idea of using an incremental (push or pull) HTTP parser as part of the API to let users decide which header fields to copy and which to discard. There was a general consensus that more examples are needed, and that the tutorial should have smaller examples. The Boost.Http code base currently builds with CMake. This must be converted into Boost.Build before being integrated into the Boost code base. Several other third-party tools were suggested, but as these are not requirements for inclusion into Boost I will leave the decision to the author. As for the future, I hope that Vinicius is not too discourage by the current rejection, and that he will consider re-submitting the library at a later stage. Judging from the reviews, the following additions will make a future submission more likely to succeed: 1. Involve the community more during the development. This will both solicit earlier feedback on the design, and help to align community expectation. 2. Provide a client-side API. 3. Design higher-level APIs on top of the low-level APIs. 4. Better documentation and more examples. I also hope that people in the community will consider contributing to the library. For example, a good opportunity is to help creating the higher-level APIs. Another opportunity is to help with the (header- only, possibly incremental) HTTP parser/generator, which could be a separate library.

4 3

[trac] Adding notification for component
by Edward Diener 28 Aug '15

28 Aug '15

I have a few trac questions. Who is the trac administrator ? How does one change the default person who is assigned a trac ticket for a particular Boost library ? How does one get added as a notification for a particular Boost library activity on Trac ? How do I add vmd as a component/library in trac ?

3 3

[website] [log] Add a patch to 1.59 release notes
by Andrey Semashev 27 Aug '15

27 Aug '15

Hi, Unfortunately, Boost.Log in Boost 1.59 contained a serious bug that affected many users (I got multiple reports already): https://svn.boost.org/trac/boost/ticket/11549 There's a fix in develop, and it went through some testing (including my manual test runs): https://github.com/boostorg/log/commit/7da193fde1a9c1bc925ee980339f4df2e1a6… Is it possible to add a patch from this commit and a link to the ticket to the 1.59 release notes? PS: You can download the patch if you add ".patch" to the above link: https://github.com/boostorg/log/commit/7da193fde1a9c1bc925ee980339f4df2e1a6…

2 3

[filesystem] Relative Draft Proposal RFC
by Beman Dawes 27 Aug '15

27 Aug '15

There have been requests for a Filesystem library relative function for at least ten years. The requested functionality seems simple - given two paths with a common prefix, return the non-common suffix portion of one of the paths such that it is relative to the other path. In terms of the Filesystem library, path p("/a/b/c"); path base("/a/b"); path rel = relative(p, base); // the requested function cout << rel << endl; // outputs "c" assert(absolute(rel, base) == p); If that was all there was to it, the Filesystem library would have had a relative function years ago. Critical issues: Clashing requirements, symlinks, directory placeholders (dot, dot-dot), user-expectations, corner cases. A paper by Jamie Allsop, Additions to Filesystem supporting Relative Paths, is what broke my mental logjam. Much of [my proposal] is based directly on Jamie's analysis and proposal. The weakly_canonical function and aspects of the semantic specifications are my contributions. Mistakes, of course, are mine. The full proposal is at http://boostorg.github.io/filesystem/relative_proposal.html A preliminary implementation is available in the feature/relative2 branch of the Boost Filesystem Git repository. See github.com/boostorg/filesystem/tree/feature/relative2 The overall plan is to get feedback from boost developers, then merge to develop for boost 1.60, then propose to the C++ committee for addition to the Filesystem TS. Comments welcome. If you are one of the many people who have requested "relative" functionality, does this proposal meet your needs? If not, why? Thanks, --Beman

1 1

[iterator] Regenerating the iterator docs
by Edward Diener 26 Aug '15

26 Aug '15

I have updated a very small portion of the iterator docs and now I need to regenerate the documentation. Evidently despite iterator having quickbook documentation the actual documentation presented to end-users is created from RST files, python scripts, and make files. But I do not see the process of regenerating the docs explained anywhere so I am wondering if anyone knows how to do it. I tried 'python generate.py' on Windows but this led to the error: > make counting_iterator.html facade-and-adaptor.html filter_iterator.html functio > n_input_iterator.html function_output_iterator.html index.html indirect_iterator > .html pointee.html iterator_adaptor.html iterator_facade.html new-iter-concepts. > html permutation_iterator.html reverse_iterator.html transform_iterator.html zip > _iterator.html iterator_archetypes.html iterator_concepts.html iterator_traits.h > tml counting_iterator.pdf facade-and-adaptor.pdf filter_iterator.pdf function_in > put_iterator.pdf function_output_iterator.pdf index.pdf indirect_iterator.pdf po > intee.pdf iterator_adaptor.pdf iterator_facade.pdf new-iter-concepts.pdf permuta > tion_iterator.pdf reverse_iterator.pdf transform_iterator.pdf zip_iterator.pdf i > terator_archetypes.pdf iterator_concepts.pdf iterator_traits.pdf > executing: 'make counting_iterator.html facade-and-adaptor.html filter_iterator > .html function_input_iterator.html function_output_iterator.html index.html indi > rect_iterator.html pointee.html iterator_adaptor.html iterator_facade.html new-i > ter-concepts.html permutation_iterator.html reverse_iterator.html transform_iter > ator.html zip_iterator.html iterator_archetypes.html iterator_concepts.html iter > ator_traits.html counting_iterator.pdf facade-and-adaptor.pdf filter_iterator.pd > f function_input_iterator.pdf function_output_iterator.pdf index.pdf indirect_it > erator.pdf pointee.pdf iterator_adaptor.pdf iterator_facade.pdf new-iter-concept > s.pdf permutation_iterator.pdf reverse_iterator.pdf transform_iterator.pdf zip_i > terator.pdf iterator_archetypes.pdf iterator_concepts.pdf iterator_traits.pdf' > make: Nothing to be done for `counting_iterator.html'. > make: Nothing to be done for `facade-and-adaptor.html'. > make: Nothing to be done for `filter_iterator.html'. > make: Nothing to be done for `function_input_iterator.html'. > make: Nothing to be done for `function_output_iterator.html'. > make: Nothing to be done for `index.html'. > make: Nothing to be done for `indirect_iterator.html'. > make: Nothing to be done for `pointee.html'. > make: Nothing to be done for `iterator_adaptor.html'. > make: Nothing to be done for `iterator_facade.html'. > make: Nothing to be done for `new-iter-concepts.html'. > make: Nothing to be done for `permutation_iterator.html'. > make: Nothing to be done for `reverse_iterator.html'. > make: Nothing to be done for `transform_iterator.html'. > make: Nothing to be done for `zip_iterator.html'. > make: Nothing to be done for `iterator_archetypes.html'. > make: Nothing to be done for `iterator_concepts.html'. > make: Nothing to be done for `iterator_traits.html'. > make: Nothing to be done for `counting_iterator.pdf'. > make: Nothing to be done for `facade-and-adaptor.pdf'. > make: Nothing to be done for `filter_iterator.pdf'. > make: *** No rule to make target `function_input_iterator.pdf'. Stop. > Traceback (most recent call last): > File "generate.py", line 30, in <module> > syscmd('make %s' % ' '.join(all)) > File "C:\Programming\VersionControl\modular-boost\libs\iterator\doc\syscmd.py" > , line 14, in syscmd > repr(s), err) > SystemError: command: 'make counting_iterator.html facade-and-adaptor.html filte > r_iterator.html function_input_iterator.html function_output_iterator.html index > .html indirect_iterator.html pointee.html iterator_adaptor.html iterator_facade. > html new-iter-concepts.html permutation_iterator.html reverse_iterator.html tran > sform_iterator.html zip_iterator.html iterator_archetypes.html iterator_concepts > .html iterator_traits.html counting_iterator.pdf facade-and-adaptor.pdf filter_i > terator.pdf function_input_iterator.pdf function_output_iterator.pdf index.pdf i > ndirect_iterator.pdf pointee.pdf iterator_adaptor.pdf iterator_facade.pdf new-it > er-concepts.pdf permutation_iterator.pdf reverse_iterator.pdf transform_iterator > .pdf zip_iterator.pdf iterator_archetypes.pdf iterator_concepts.pdf iterator_tra > its.pdf' returned 2 Is this process only successful under Linux ? I have a 'make' as the GnuWin32 package installed on Windows. But something is missing in this process.

8 24

[vmd] Adding to boost master branch
by Edward Diener 26 Aug '15

26 Aug '15

In an effort to get vmd as a submodule of the boost superproject master branch I submitted a PR against Boost on master ( https://github.com/boostorg/boost/pull/93 ). In this PR I added vmd to .gitmodules and also to the status/jamfile.v2 for testing. But looking at the Travis CI build of this a failure occurs: 0.01s$ cd status The command "cd status" exited with 0. 2.13s$ ../b2 -n -d0 error: Unable to find file or target named error: '../libs/vmd/test/' error: referred to from project at error: '.' There is most definitely a jamfile and tests at libs/vmd/test on the master branch. Is there something else I have to do to get vmd added to the master branch ?

3 5

Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
by Niall Douglas 25 Aug '15

25 Aug '15

On 25 Aug 2015 at 12:30, Robert Ramey wrote: > > There is precedent for this: Boost.Fiber was provisionally approved > > here as a C++ 98 library with condition of a mini-review before > > entry. Boost.Fiber is now a C++ 14 library and sufficiently different > > from the library originally reviewed it may require a second > > mini-review if during its first mini-review it is felt still lacking. > > This is a precedent - a bad one which I hope to avoid a repetition of in > the future. A library which is accepted should be close enough to it's > final state so that it can be finished up on the order of a couple of > months and will result in a final version which is close to what > reviewers actually reviewed. > > We can't have a library pass a review, then have the package morph into > something significantly different then have it accepted. This make the > original review a farce. I've been watching Fiber closely since we reviewed it. As far as I know, the public API has barely changed. The documentation has improved in all the areas the review recommended. Just because the internal implementation is radically different does not mean it has morphed into something significantly different. For example, Oliver is considering making boost::fiber::future<> based on my Monad/Outcome Concurrency TS custom future framework as why bother duplicating the work. If he did, even then the public API reviewed and accepted into Boost remains exactly that which was reviewed and accepted. You don't really need to know or think about Monad/Outcome for boost::fiber::future<> to work as a C++ 11 type future. > All > > these changes to AFIO are almost entirely driven by changes since > > 2012 to the various WG21 technical standards. If they hadn't changed > > and C++ compilers (specifically MSVC) hadn't changed, AFIO wouldn't > > have changed. > > > It's very similar for Fiber, which had to be refactored > > in the face of substantial changes in C++ 14. > > I seriously doubt that a package which compiles and passes tests and > reviews with C++03 cannot do these things when C++11 comes out. What > really happens is that the author sees opportunities with C++11 that he > didn't have before then starts incorporating them after the original > review. I guess this would be called feature creep or implementation > creep. In any case, it indicates that the original acceptance was > premature. I think he saw a chance to make his internal implementation code vastly simpler and easier to maintain yes. Same as me. We're going to be supporting this thing for a decade or so, it makes sense to invest in saving ourselves work. > Ultimately it hinges on what "acceptance into Boost" means. To me it's > a library ready - with a few straight forward / uncontroversial changes > which is ready to be incorporated into the boost distribution. It's not > acceptance of an idea for a library, a prototype for a library, or that > a developer is certified to add a library in the future. I agree. But I draw the line between API and design and then the internal implementation. If it's just the latter which has changed and the API and design is identical, I think a mini-review is enough. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

boost.test documentation header
by Raffi Enficiaud 25 Aug '15

25 Aug '15

Hi, Boost.test 1.59 documentation header is not the same as the other boost libraries. In particular, the green header is missing: http://www.boost.org/doc/libs/1_59_0/libs/test/doc/html/index.html vs for instance: http://www.boost.org/doc/libs/1_59_0/libs/assert/assert.html I would like to know how to include this header and what I am missing in the documentation generation. Those headers are also mentioning the latest available version of the doc. Thanks, Raffi PS.: sorry for cross-posting, but I cannot get an answer on boost-doc ML/

3 4

Boost Social Event at CppCon
by Jon Kalb 25 Aug '15

25 Aug '15

Boosters, Because a lot of Boosters are going to be attending CppCon, we¹d like to arrange a social event for Boosters/C++Now regulars. http://cppcon.org/ If you are planning to attend CppCon or even If you are just going to be in or around Bellevue, Washington between September 20th and 25 and you¹d like to join us for dinner, please let us know so we can get a count. Please send mail to: social(a)boost.org Once we settle on a date, etc, we¹ll let everyone who responded know when and where, so please let us know, even if you are a ³maybe.² I hope to see you at CppCon. Jon

1 0

Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
by Niall Douglas 25 Aug '15

25 Aug '15

On 25 Aug 2015 at 12:37, Paul A. Bristow wrote: > 1. Should Boost.AFIO be accepted into Boost? Please state all > conditions for acceptance explicity. > > Provisionally, yes. > > Requirements: > > . Major restructuring of documentation. (Not re-writing!) > > . Completion of Boost.Was_Called_Monad and APBind. > > . Creation of a TODO list. > > . Mini-review before going into a release (perhaps of all together?). > > . More documentation of examples to explain what they demonstrate. Thanks for the review Paul. I pretty much agree with all of it. This review process has been particularly useful for helping me see the documentation as others see it - I had no idea it was so confusing! - and I'm going to try raising with the Standard C++ Foundation in Seattle next month the idea of them funding professional copy writers to take passes at C++ library documentation. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Did Boost 1.59.0 change the meaning of "using python : 3.4 : ..." in user-config.jam?
by Jonathan Wakely 24 Aug '15

24 Aug '15

Hi, I'm trying to update the Fedora rawhide package to Boost 1.59.0 and the build fails with the output below (ignore the MPI warnings). We build with the following in user-config.jam: # This _adds_ extra python version. It doesn't replace whatever # python 2.X is default on the system. using python : 3.4 : /usr/bin/python3 : /usr/include/python3.4m : : : : m ; Is that comment no longer true? Did something change in Boost 1.59.0 so that that line now sets the only allowed python version? I can make the build work with the following but I'd like to understand the change: using python : 2.7 : /usr/bin/python2 : /usr/include/python2.7 : : : : ; using python : 3.4 : /usr/bin/python3 : /usr/include/python3.4m : : : : m ; Build failure: + echo ============================= build serial ================== + ./b2 -d+2 -q -j4 --without-mpi --without-graph_parallel --build-dir=serial variant=release threading=multi debug-symbols=on pch=off python=2.7 stage MPI auto-detection failed: unknown wrapper compiler mpic++ Please report this error to the Boost mailing list: http://www.boost.org You will need to manually configure MPI support. /builddir/build/BUILD/boost_1_59_0/tools/build/src/build/feature.jam:494: in feature.validate-value-string from module feature error: "2.7" is not a known value of feature <python> error: legal values: "3.4" /builddir/build/BUILD/boost_1_59_0/tools/build/src/build/property.jam:276: in validate1 from module property /builddir/build/BUILD/boost_1_59_0/tools/build/src/build/property.jam:302: in property.validate from module property /builddir/build/BUILD/boost_1_59_0/tools/build/src/build/build-request.jam:216: in convert-command-line-element from module build-request /builddir/build/BUILD/boost_1_59_0/tools/build/src/build/build-request.jam:154: in build-request.from-command-line from module build-request /builddir/build/BUILD/boost_1_59_0/tools/build/src/build-system.jam:583: in load from module build-system /builddir/build/BUILD/boost_1_59_0/tools/build/src/kernel/modules.jam:295: in import from module modules /builddir/build/BUILD/boost_1_59_0/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module /builddir/build/BUILD/boost_1_59_0/boost-build.jam:17: in module scope from module

2 8

Unicode characters in filenames
by Tom Kent 24 Aug '15

24 Aug '15

Recently there was a thread that ended up changing the boost guidelines so that Unicode characters are now allowed in C++ source files. http://lists.boost.org/Archives/boost/2015/06/223822.php However, in the 1.59 release, there was a filename that had unicode characters in it: libs\preprocessor\doc\Appendix A An Introduction to Preprocessor Metaprogramming.html. Which, HTML encoded, actually looks like: Appendix%20A%20%C2%A0%20An%20Introduction. Note the %C2%A0 character (Hex C2A0, Octal: 302240, Windows displays: ┬á)? Since this seems like a mistake, I've created a pull request for this in pre-processor. However, it begs the question: Should we support unicode codepoints for filenames in the boost distribution? I would like for this answer to be 'no' as there are still lots of tools out there that don't correctly handle unicode filenames. However, it is worth bringing up the discussion. Is there a reason we would want unicode file names? I would guess that tests uses them (especially the filesystem tests), however I would also expect that these tests generate the files on the fly, and that they aren't part of what is distributed. Thoughts? Tom Kent

5 9

"Simple C++11 metaprogramming"
by Peter Dimov 22 Aug '15

22 Aug '15

I've recently made the mistake to reread Eric Niebler's excellent "Tiny Metaprogramming Library" article http://ericniebler.com/2014/11/13/tiny-metaprogramming-library/ which of course prompted me to try to experiment with my own tiny metaprogramming library and to see how I'd go about implementing tuple_cat (a challenge Eric gives.) Ordinarily, any such experiments of mine leave no trace once I abandon them and move on, but this time I decided to at least write an article about the result, so here it is, with the hope someone might find it useful. :-) http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html

17 55

cache size runtime detection
by Joel FALCOU 22 Aug '15

22 Aug '15

We have a bunch of cross-platform CPU cache size and cache line size detection that we want to offload into boost in preparation for the first reviewable version of Boost.SIMD. It's rather smallish in term of API but the code is non-trivial. I think it's a bit broad to be in utility/core, doesn't really fit in align and IIRC there is no "general memory related" library in Boost. Questions: 1/ would there be interest to have such utility in Boost ? 2/ here should we put it ? Is Boost.Memory a viable solution or could it be hosted somewhere non-trivial ? Regards

10 25

[Polygon] trait register on derived class
by Lechuan Xue 21 Aug '15

21 Aug '15

Hi, Currently, if I have one custom geometry and a few further derived custom geometries, I need to do trait register on all of them. Like: class derived_point1 : public base_point {}; class derived_point2 : public base_point1 {}; namespace boost { namespace polygon { struct geometry_concept<base_point> { typedef point_concept type; }; struct geometry_concept<derived_point1> { typedef point_concept type; }; struct geometry_concept<derived_point2> { typedef point_concept type; }; } What I want is to register all custom geometries in one step. Like: template<typename T> struct geometry_concept<T, typename std::enable_if<std::is_base_of<base_point, T>()>::type> { typedef point_concept type; }; To do that, I need to add a dummy template type to all the trait classes to enable SFINAE. Attached is the patch (based on boost 1.57.0_1). Is this something we can consider? Thanks, Leo Xue

1 0

Transfer ownership of DLL into boostorg
by Antony Polukhin 19 Aug '15

19 Aug '15

Hi, I'd like to transfer Boost.DLL library ( https://github.com/apolukhin/Boost.DLL) into the boostorg. What's the current procedure for that? -- Best regards, Antony Polukhin

3 6

[http] Boost.Http formal review is finished
by Bjorn Reese 19 Aug '15

19 Aug '15

The formal review of Boost.Http is finished, and I would like to thank all who participated. The following reviews have been recorded: - Antony Polukhin: No - Darren Cook: No - David Sankel: No - Lee Clagett: No - Niall Douglas: Yes, conditionally - Roland Bock: No - Tom Kent: No Please let me know if I have missed any. The final review results will be posted later.

5 8

[core] Determining interest for two new classes: readonly and newtype
by Sam Kellett 19 Aug '15

19 Aug '15

Hey, I have two classes I've developed that have been used in my own projects that I think could have a place in Boost. They are outlined below. readonly<T>: This is a wrapper class for a type to replace a const-type field in a movable class. It has const access to the type so can't modify except for the move constructor and move assignment operator. This solves the problem that no fields in a movable class can be const which can cloud the intentions of a field. readonly copies the accessor patterns seen in classes such as optional and the smart pointer collection. Example: struct foo { foo() : str("hello world") {} readonly<std::string> str; }; foo f; auto g = std::move(f); static_assert(std::is_move_constructible<foo>{}, ""); std::cout << *g.str << std::endl; g.str->clear() // error: non-const method. ----- newtype<N, T> This is shamelessly ripped off from Haskell and provides strongly-typed typedefs to C++. It actually has two template parameters, one is an incomplete type that provides a unique identifier for this typedef. I've opted to use the name of the typedef with an '_t' suffix, the second is the raw type that it contains. Like readonly the underlying type can be accessed by operator*, operator-> and get() methods. Example: using age = newtype<struct age_t, int>; age a{25}; using byte = newtype<struct byte_t, int>; byte b{42}; // do something with bytes (*not* any old int). void bar(const byte); bar(a); // error: wrong type wanted 'byte' got 'age' bar(b); // okay bar(89); // error: wrong type wanted 'byte' got 'int' assert(*b == 42); Any thoughts on the design and/or their place in Boost would be much appreciated. Cheers, Sam

8 16

[build] Algorithm for setting PATH when a 'run' or 'run-fail'
by Edward Diener 18 Aug '15

18 Aug '15

What is the algorithm for setting a PATH on Windows when the 'run' or 'run-fail' rule occurs in a jamfile ? In running clang on Windows when an executable is created the PATH needs to start with the bin directory of the mingw(-64)/gcc implementation that a particular version of clang uses as its RTL when the program is compiled/linked. It appears that when the 'run' or 'run-test' rule occurs with the clang toolset on Windows that the PATH is adjusted to have the directory of the clang++ executable and not that of the corresponding mingw(-64)/gcc RTL ? Is there any solution to this from within Boost Build ?

2 5

[lclcontext] Any interest in Pythonesque "with-as" statement in C++.
by Mostafa 18 Aug '15

18 Aug '15

I think Python's concept of Context and Context Managers useful and I've adapted, to the best of my abilities, a similar concept in C++. For those not familiar with this concept, I'll quote a brief snippet from the documentation: "Simply stated, this library enables the use of the Pythonesque with-statement construct in C++. More broadly, this library seeks to formalize a generalized version of a subset of the RAII (Resource Acquisition is Initialization) idiom that, for the lack of preexisting terms, I shall refer here to as the STEP (Scope Triggered Event Processing) idiom. The STEP idiom is the commonly occurring use case where for a given block of code some user specified action(s) must execute on entry and on exit, and the failure to do so will result in some deterministic behavior." You can find the library here: https://github.com/m-w-a/WG Documentation is here: https://github.com/m-w-a/WG/tree/master/Local/Docs (In the same repository I've also redid Boost's local_function, but that the subject of another posting.) If there is enough interest from the community for such a library then I will go ahead and "Boostify" it.

3 6

[http] Formal Review
by David Sankel 17 Aug '15

17 Aug '15

> 1. Should Boost.Http be accepted into Boost? Please state all conditions for acceptance explicity. No. This library unfortunately is not complete enough to be in Boost. > 2. What is your evaluation of the design? >From my reading, the design of the low level components that are in the library seems okay. > 3. What is your evaluation of the implementation? Looks okay from what I've seen. > 4. What is your evaluation of the documentation? More tutorials for common use cases are needed. I fear, though, that the only use case of these low-level components is the writing of a higher-level one on top of it that is more widely useful. > 5. What is your evaluation of the potential usefulness of the library? In its current state, I do not find this library very useful. A Boost HTTP library should support both client side and server side. Micro-services are quite commonly used these days and only communicating one direction excludes this library from having full participation. While I very much enjoy and appreciate the exposed lower-level functionality, higher level abstractions are required to scratch the itch most developers have when they want a C++ HTTP library. I could not recommend this library over pion for this reason even though I like this library's design better. In particular, we need really good stories for: a) How to fetch the contents of a website given a URL. b) How to make a static page server. c) How to write code that handles a POST or GET request dynamically based on specified parameters. d) How to write a server that accepts file uploads. e) HTTP/2.0 f) Websockets I would also like to see instances of this library being used in production. That would give some evidence that the design works in practice. There is the argument that we should accept this into Boost now because, once it has more features, it'll be really great. I think that Boost is for libraries that are already really great. I don't see how getting more exposure to an incomplete library helps either Boost or the library, but I do see how it can do damage to the Boost name. > 6. Did you try to use the library? With what compiler? Did you have any problems? I built the library and ran the single example. I used gcc 5.2.0. I didn't run into any problems and was quite happy with this part of the review. > 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a couple hours reading through the documentation and the mailing list discussions. > 8. Are you knowledgeable about the problem domain? Yes. I'm the architect of a large C++-based web framework for the US Government. We currently use pion as our primary server and client low-level library. I've contributed some minor patches to pion. -- David Sankel

1 0

[lclfunction][local_function] Any interest in a redone version of local_function.
by Mostafa 17 Aug '15

17 Aug '15

I've made a library called lclfunction which is basically a redone version of local_function except for the following important differences: 1. This library allows the function name to be specified at and only at the top of the local function declaration. 2. This library allows local functions to maintain internal state without referencing external variables (via varset). 3. This library allows the use of globally scoped types as macro parameters, i.e., ::std::pair<..., ...>. 4. This library can handle binding array types. 5. IMHO, this library has a cleaner implementation: a) The preprocessor translator is partitioned into a front end and back end. b) A well-defined symbol table bridges the two translation layers. c) It has well-defined error-generating mechanism with a separate error pass before code generation. 6. It uses a different syntax. The main reason I did this redone library is because local_function required putting the function's name in the closing macro and that rubbed me the wrong way, my view is that it should and can be placed in the opening macro. If there is enough interest from the community I will "Boostify" it. Thanks, Mostafa

1 1

boost.org https certificate expired 4 month ago
by Jens Weller 16 Aug '15

16 Aug '15

Hello boost community, I noticed today that the https of boost.org is expired, and should have a new certificate: https://www.ssllabs.com/ssltest/analyze.html?d=boost.org thanks, Jens Weller

11 17

[http] Formal Review
by Antony Polukhin 16 Aug '15

16 Aug '15

Hi, This is my formal review for Boost.HTTP library. 1. Should Boost.Http be accepted into Boost? No. It has some big architectural issues and a lot of issues in code. 2. What is your evaluation of the design? That's the fatal problem of the library. It seems like the library attempts to get best from ASIO and cpp-netlib and unfortunately fails. Now let's get into details: * ASIO is a low level abstraction over protocol that does not take care about memory management of buffers (in most cases it's the responsibility of user to allocate and keep alive the required buffers). * cpp-netlib takes care of memory management, hides low-level stuff. Boost.Http is stuck somewhere in the middle: sometimes it allocates and extends buffers, sometimes not. Because of that the design does not seem solid. Any attempt to hide all the memory management inside the library will end in an another implementation of cpp-netlib. So it seems right to remove all the memory management from the library internals and make the library closer to ASIO. Here are my recommendations for separation of flies and dishes: * Stick to the idea that http socket must ONLY manage connection without extending the ASIO's send/receive function signatures. That means that http1.0 and http1.1 sockets must be almost a typedef for tcp/ssl socket. Http2.0 socket must be very close to SSL socket. No additional methods (like async_read_trailers or async_write_response) must be provided. * It must be a user's responsibility to provide buffers for messages. Never extend buffers in socket-related methods. * Provide helper classes that parse and generate http * Provide out-of-the-box completion conditions for async_read operation: http::completions::full, http::completions::headers, http::completions::body... Those bullets will allow to write following code (based on http://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/tutorial/tutdaytim… with minimal modifications): #include <ctime> #include <iostream> #include <string> #include <boost/bind.hpp> #include <boost/shared_ptr.hpp> #include <boost/enable_shared_from_this.hpp> #include <boost/asio.hpp> std::string make_daytime_string() { using namespace std; // For time_t, time and ctime; time_t now = time(0); return ctime(&now); } class http_connection : public boost::enable_shared_from_this<http_connection> { public: typedef boost::shared_ptr<http_connection> pointer; static pointer create(boost::asio::io_service& io_service) { return pointer(new http_connection(io_service)); } http::socket& socket() { return socket_; } void start() { message_.resize(4 * 1024); boost::asio::async_read(socket_, boost::asio::buffer(message_), http::completions::full(message_), // read until all the whole request is in `message_` boost::bind(&http_connection::handle_read, shared_from_this(), boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); } private: http_connection(boost::asio::io_service& io_service) : socket_(io_service) {} void handle_write(const boost::system::error_code& /*error*/, size_t /*bytes_transferred*/) {} void handle_read(const boost::system::error_code& error, size_t bytes_transferred) { assert(!error); // for shortness // `message_` contains the whole request, including headers and body // because http::completions::full was provided { boost::system::error_code e; http::view v(message_, e); // represent buffer as http message assert(!e); // no error occured during parsing assert(v.read_state() == http::read_state::empty); std::cerr << v.version(); // "HTTP1.1" std::cerr << v["Content-type"]; // "plain/text" std::cerr << v.body(); // string_ref("Hello! This is a body content. What time is it?") message_.clear(); // `v` is now invalid to use! } { http::generator resp(message_); // use `message_` for an output resp << make_daytime_string(); // append daytime to body resp["Content-Type"] = "plain/text"; // set some headers resp.version(http::version::HTTP_1_1); // explicitly set HTTP version resp.code(200); // "200 OK" resp.flush(); // explicitly flush to buffer. Done automatically in destructor } boost::asio::async_write(socket_, boost::asio::buffer(message_), boost::bind(&http_connection::handle_write, shared_from_this(), boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); } http::socket socket_; // manages the connection only std::string message_; }; class http_server { public: http_server(boost::asio::io_service& io_service) : acceptor_(io_service, http::endpoint(http::all_versions, tcp::v4(), 80)) { start_accept(); } private: void start_accept() { http_connection::pointer new_connection = http_connection::create(acceptor_.get_io_service()); acceptor_.async_accept(new_connection->socket(), boost::bind(&http_server::handle_accept, this, new_connection, boost::asio::placeholders::error)); } void handle_accept(http_connection::pointer new_connection, const boost::system::error_code& error) { if (!error) { if (new_connection->socket().version() == http::version::HTTP_2_0) { // do some more stuff } new_connection->start(); } start_accept(); } http::acceptor acceptor_; }; int main() { try { boost::asio::io_service io_service; http_server server(io_service); io_service.run(); } catch (std::exception& e) { std::cerr << e.what() << std::endl; } return 0; } This will also untie Boost.HTTP from ASIO. Now users could use http::generator/http::view to read/generate HTTP data. This significantly extends the use cases of your library (for example on a previous work we had our own network transfer implementation, but we'd gladly use a http parser and generator). Such code is also less intrusive: only minimal chages were required to change a tcp example into the http example. Users will appreciate that, especially in cases when ASIO is already used for HTTP. BTW, after that you could easily implement http::stream (that must be close to tcp::stream by functionality). http::stream would be a killer feature that would be widely used by utility programs (as I remember current Boost's regression testing requires it, but uses tcp::stream with a bunch of workarounds). Please, implement the HTTP2.0 protocol. There are some open source solutions that are licensed under the Boost license and are very close to full implementation of HTTP2.0. Just reuse the code and chat with the authors for better understanding of the problems. 3. What is your evaluation of the implementation? Not perfect. For example https://github.com/BoostGSoC14/boost.http/blob/master/include/boost/http/so… It seems that `std::vector<asio::const_buffer> buffers; buffers.reserve(nbuffer_pieces);` is meant to be here. There are more such places... It seems that some useful features (like custom allocators) are not supported by the library. It's better to be fixed. Some of the implementation issues are because of the library design. For example requesting multiple async operations (async_read_request+async_read_some+async_read_trailers) is performance hit. It's better to read all the data at once (just like in the example from above). 4. What is your evaluation of the documentation? First code snippet in tutorial contains mostly ASIO's stuff and almost no HTTP stuff. That's wired... If bullets from above would be implemented, then I'd rather start with parsing and generating simple http messages. Then an example with sockets could be provided. Also please do not use coroutines at least in first example. coroutines is a new feature in ASIO, many users use old Boost versions that have no coroutines and some users are not familiar with them. So if you start with coroutines user will have to go to ASIO docs and dig into coroutines to understand the very first example. Example without coroutines will be more user friendly. 5. What is your evaluation of the potential usefulness of the library? Library is very useful and required. But in current state it must not be accepted into Boost. 6. Did you try to use the library? With what compiler? Did you have any problems? Have not tryed. 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A few hours digging into docs, about 3 hours looking into the sources, about 3 hours formulising the issues and recommending solutions. 8. Are you knowledgeable about the problem domain? Not an expert, but used ASIO a lot along with cpp-netlib and some other libraries close to the proposed one. 8.3333(3) Review Please, reserve a bigger window when such complex library is proposed for review. It's hard to review it in 10 days. 8.6666(6) For Reviewers I urge other reviewers to take a look at the cpp-netlib. If you treat Boost.Http as an out-of-box solution, then cpp-netlib is more mature, user-friendly and solid. If you treat Boost.Http as a basic building block for HTTP (just like ASIO is a basic building block for networking), then it's better to stick to the ASIO's design and do not *partially* manage memory! P.S.: I hope that this library would be changed according to my recommendations and submitted for a new review. -- Best regards, Antony Polukhin

3 24

Re: [boost] [asio-users] [http] Formal review of Boost.Http
by Niall Douglas 16 Aug '15

16 Aug '15

On 7 Aug 2015 at 19:29, Vinícius dos Santos Oliveira wrote: > > I do not believe Http is ready for peer review for these reasons, and > > I personally would urge you withdraw it until you have fixed these > > issues and then come back to us. If you do not withdraw it, I will > > vote for rejection. > > Can I persuade you to review the Boost.Http design? I'd reject myself if > you find any fundamental flaw on the design and even if you're going to > reject the library because the lack of tooling (not directly related to > design or documentation, which are the most important items on any > library), it'd be useful to know what needs to be addressed on the design > before I submit again (in the case the submission is rejected). I think my earlier email was poorly phrased now I've slept on it. I made my objections seem like they were about portability, when they were really about design and intent of Http. What I should have said was this: Standalone ASIO is the reference Networking TS implementation for standardisation. Http is currently a set of extensions to Boost.ASIO specifically when it *should* be a set of extensions to the reference Networking TS implementation for C++ standardisation. This is why your current design and architecture is flawed, but luckily there isn't too much work to fix this by finishing the port of Http to the Networking TS. The Internet of Things tends to involve lots of small somewhat underpowered internet devices where C++ is likely going to play a much more important role than historically in embedded systems. The chances are that any Networking TS in C++ will be very extensively used in such IoT applications. If there were also a high quality set of extensions adding HTTP support to the Networking TS, I think your chances are good that your Http library would be seriously considered by WG21 for standardisation. *This* is why I very strongly believe that Http needs to cleave itself tightly to the Networking TS reference implementation, and not to Boost.ASIO. Moreover, if you make Http an extension of the Networking TS, you get Boost support with that for free - Http becomes dual use. > About C++03 support, it's not required for Boost acceptance, so I can add > later. I want to increase tests coverage a lot before porting code to > C++03, so I don't introduce accidental bugs in the process. As a strong advocate for C++ 11 over 03 I can understand. However, IoT developers tend to be stuck on some pretty ancient toolsets for longer than others. 03 support I think would greatly increase your potential userbase. > In the case the abstractions I need enter on the C++ standard, maybe your > APIbind will help me. I actually would advise you to choose ASIO's STL abstraction machinery over my own alternative APIBind in this instance. > But I just don't find any reference to BOOST_ASIO_HAS_STD_SYSTEM_ERROR > outside of config.hpp. Even if it was used, it is undocumented, which means > it is an implementation detail that won't be guaranteed to be there forever > (accidental behaviour versus a documented guarantee). I'm pretty sure that implementation detail won't change in a hurry. STL abstraction machinery changes as quickly as a STL does i.e. every decade or so. > > https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a7.SAFETY:S > > tronglyconsideranightlyorweeklyinputfuzzautomatedtestifyourlibraryisab > > letoacceptuntrustedinput > > That's why this first implementation uses a proven-parser that is very well > tested. The buck always stops with the top most layer, not internally used third party libraries. You NEED to fuzz test untrusted inputs when parsing HTTP. For all you know, your STL implementation could be the thing with the overflow bug, or the way in which you use it. > > * I don't understand why you cannot issue more than one async read at > > a time nor async write at a time. In something like pipelined HTTP > > that seems like a very common pattern. I smell a potential design > > flaw, and while the docs mention a "queue_socket" I can't see such a > > thing in the reference section. > > > > Too much synchronization and buffering. > > The pipeline has the following requests: > > A => B => C > > If I were to allow replies to request B, the design would be more complex, > increasing the difficult to implement alternative backends and everyone's > life. Also, the reply to request B cannot actually be sent while the reply > to request A is on hold. This means that the whole response to request B > would need buffering and if response B is a video live stream, this means > an implicit (the user cannot know) crash after an unfortunate memory > exhaustion. I couldn't claim a **lightweight** server if this excessive > buffering was to occur. I couldn't claim the project is appropriate for > embedded devices if I had chosen the buffering approach. It's a trade-off. > I should write about it in the "design choice" of the documentation. > > HTTP/2.0 does have proper multiplexing and it can be more useful to respond > several requests without "head of line blocking". Ok, let's accept that HTTP before 2.0 can't multiplex (not my experience personally, but I agree it's got big gotchas before 2.0). You need a user facing API for Http which lets user code multiplex where that is available, and not multiplex when that is not available. In other words, identical code written against Http must automatically be optimal in either connection case. You're probably going to ask how I might implement that right? I think my first guess is you need two completion handler layers and therefore two completion dispatcher reactors: the bottom layer is the same as ASIO's and uses the ASIO reactor, whilst the top layer which users of Http sees is a reactor operated by Http and is disconnected, though operated by, the ASIO reactor. > A queue socket is a concept, I don't provide one. I can look into how make > the documentation less confusing by adding a page exclusively dedicated to > explain the problem it solves. Would that work for you? It could be this queue socket concept of yours is exactly what I just proposed as two completion handler and reactor layers. In either case, I don't think queue sockets should be a concept, I think they need to be the core of your library's user facing API. If power users wish to bypass that user facing API layer for less hand holding and less latency, that should also be possible. But I think HTTP multiplexing should be assumed to be the default starting point for Http applications. Once HTTP 2.0 is more common, it will seem madness that Http's user facing API is _not_ 100% multiplexing. > * Your tutorial examples use "using namespace std;" at global level. > > That's a showstopper of bad practice, and you need to purge all of > > those. Same for "using namespace boost;" at global level. > > > > The tutorials should be as small as possible to not scary the users. > > But I can put a comment "you should avoid using namespace". Does it help? using namespace is fine at local scope. It's not fine at global scope. Replacing all global using namespace with local using namespace is all you need to do. > * Your reference section is one very long thin list. You might want > > to use more horizontal space. > > > > I'd be happy already if I knew hot to remove the TOC from the reference > page. It'd be much more clean already. Personally in AFIO I hack the CSS to make the list into columns. ASIO employs a table. There are many solutions. > * I personally found the design rationale not useful. I specifically > > want to know: > > > > 1. Why did Http choose ASIO as my base over leading competitor X > > and Y? > > 2. What sacrifices occurred due to that choice? i.e. things I'd > > love weren't the case. > > > > I assume I don't need to reply these questions during the review, given the > reviewers may already be experienced on the answers. Well ... I'm not sure that's actually the case. It's not we don't have opinions on the answers, it's whether our answers are different to your answers. You'll see this during the AFIO review later this month - I have some really weird opinions no one else shares like choosing my own custom lightweight monadic future-promise implementation over async_result. That will be the source of much criticism I'm sure. > 3. What alternatives may be better suited for the user examining > > Http for suitability and why? i.e. make your documentation useful to > > people with a problem to solve, not just a howto manual. > > > > I don't quite understand this point. What I'm really asking is for details of when before starting Http you reviewed the options available and the designs they used, and exactly why you chose the design choices in Http you did with reference and comparision to prior art. Like a literature review, but for programming libraries. Does this make sense? It's partially for us to help us understand your choices, but also to help those examining Http to see if it's useful to them to figure out the best solution to their problem (which may be to use an alternative to Http). Documentation which is useful over documentation which is reference. > * Benchmarks, especially latency ones which are important for many > > uses of HTTP are missing. I'd particularly like to know confidence > > intervals on the statistical distribution so I know worst case > > outcomes. > > > > These values will change when I replace the parser used now. Also, they can > change based on the buffer sizes and parser options, which the user is/will > be able to change. > > Nevertheless, I do want to do some serious benchmarking, specially because > it'll give me a reference point when I write my own parser and want to > compare performance speedup. I can do some poor benchmark this weekend and > show the results. That would be interesting, but don't go crazy on it. Also, please do enable the undefined behaviour sanitiser permanently including in release mode and with full stack smashing protection before running benchmarks. Anything parsing malicious input should have all those turned on where available. > I hope all the above isn't too disheartening Vinícius. > > Not at all. I think you're the second person to dedicate more time > reviewing my work and this isn't disheartening at all. Just that your > feedback is usually around tooling and not the design itself (everybody has > its preferences). That's because I like the design a lot and have little bad to say about it. I've also been subscribed to your github since the beginning, and I have been reviewing your code on and off as you wrote it. You're a talented programmer. > > Jamfile for the main library build, > > Consider this done. I won't integrate into Boost without removing CMake > first. This was already partially stated in the Bjorn's announcement (but > somehow implicit, to be fair). I have no problem at all with dual build systems if you're happy keeping both maintained. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 6

Re: [boost] [asio-users] [http] Formal review of Boost.Http
by Niall Douglas 15 Aug '15

15 Aug '15

On 13 Aug 2015 at 8:58, Vinícius dos Santos Oliveira wrote: > First of all, sorry to all members of the list about my unavailability. I > was planing to write an experimental HTTP 2.0 backend, so I could give more > confidence about how much I believe this Boost.Http core I present for > review is the right abstraction. > > Anyway, looks like I took the wrong approach. I should have answered the > easiest questions first and implement the HTTP 2.0 backend (experimental, > using existing-library and not Boost-quality) later. That's a wise move Vinícius I think. > > Where I'm really at is I think if Http is accepted you're going to > > either have to ditch it and reimplement atop the Networking TS as > > Chris folds the substantial changes WG21 will force onto ASIO into > > Boost.ASIO, or end up refactoring Http to cleave more closely to the > > Networking TS anyway. > > I'm okay with that. You may be, but I would worry about your users. Boost users expect stability and permanence. > > I think for the majority of HTTP users they just want it to work > > without surprises to a high default performance level. If you look at > > the history of the HTTP library support in Python you'll see what I > > mean - firstly, it's surprisingly easy to get a HTTP library API > > design wrong, even in a v2 refactor. And secondly that people need > > both a stupid-simple API and a more bare metal API *simultaneously* > > with HTTP, and therein lies the design gotcha. > > > > If you want a high level API, you're going to use coroutines. There is > nothing in the wild so readable as coroutines. Coroutines are **the** > solution to solve spaghetti code in asynchronous abstractions. Lambdas and > futures will never be as readable as coroutines. Anyway... God no. I would see a top level API as being synchronous, so something like python's urllib3: import requests r = requests.get('http://www.boost.org') print(r.json()) It may coroutinise but still appear to be synchronous, but that's a separate moving ball and not one Http can tackle alone. > The more I think, the more I believe how much such "middle-level" API is > underestimated. > [snip] > It's not really like Boost.Http is too low level. It's more like only the > less polemic building blocks are available now. You'll see the same main > players in a higher-level abstraction and the main difference is most > likely that you won't manage the main players yourself. Think of it as a Boost user. The average Boost user is going to see Boost.Http and think to themselves, "oh goody I can now write: import requests r = requests.get('http://www.boost.org') print(r.json()) ... in C++ and yay I've just chopped 10,000 lines of buggy hack code from my codebase." And that's exactly what I would expect too from a library called Boost.Http. What you're providing isn't that though: it's a set of low level HTTP related extensions to Boost.ASIO. From my review of your code and docs, and what you've told me, I think the ideal location for your library is within ASIO under the asio::http namespace. However, assuming Chris isn't keen to allow that as a git submodule within ASIO (he might be, I don't know), I think as a very minimum you need a name for your library which says it is a set of low level HTTP related primitives for Boost.ASIO. That name is not Boost.Http for sure. A later library you might submit could be called Boost.Http, but it would provide a daft easy API like the above for Python's urllib3. In fact, if you can achieve a more appropriate name choice, I'll change my vote from rejection to a conditional acceptance as you've done a great job in persuading me from where I was. You've impressed with me your awareness of the tradeoffs involved in a moving API environment, and though I severely personally disagree with your choice of Boost.ASIO over ASIO, I can also see that targeting a more stable API in the form of Boost.ASIO for now makes sense. How does that sound? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 1

Making the Windows binaries 'official'
by Tom Kent 15 Aug '15

15 Aug '15

<history> After the boostpro.com organization dissolved, there was never an official place to go to get pre-built binaries for the releases. Some random components were made available on the sourceforge download page and I had been hosting them on my own website (http://boost.teeks99.com) since I started building them around the release of 1.37. A couple years ago, before the release of 1.54, I asked the community if they would like my builds to be hosted on the sourceforge site, and the answer was positive: http://lists.boost.org/Archives/boost/2013/04/202460.php Since the 1.54 release, I've generally been uploading the windows binaries based on the RCs and enabling the downloads just a few minutes after the release notice goes out. </history> I would now like to propose that we make these libraries an official part of each Boost release. I don't think this entails much, just the following: 1) Have the release team coordinate with me to ensure that the binaries are ready before announcing the release. 2) Include a link to them in the release announcement. 3) Link to them from the website. It would also be good to get others who can run the scripts to perform the build, if I am someday unable to do this. The biggest hurdle here is having a (virtual) machine with all six versions of visual studio on it. Is this something the community would be in favor of? I know that many of the people on these lists don't use windows and if they do are generally capable of building the windows binaries themselves, however there is a large group out there that prefers to just get the installer for them (like they do for other projects like Qt, wxWidgets, etc). Thoughts? Tom Kent

2 2

[job] exec job-graphs in a NUMA env (was a thread pool that allows recursive calls)
by Oliver Kowalke 15 Aug '15

15 Aug '15

This library is related to the posting 'a thread pool that allows recursive calls' (http://lists.boost.org/Archives/boost/2015/06/223426.php) e.g. the library solves the many-dependent-jobs problem. boost.job is a derivative work of boost.task (which was published in 2008, the code is refactored and now split into boost.context, boost.coroutine2/boost.fiber and boost.job). boost.job provides a framework for asynchronous execution of job-graphs (a job is a small unit of code that can be executed independently and parallel, e.g. it's a fain-grained work item) of arbitrary dependency, e.g. solving the many-dependent-jobs problem (M: worker threads, N: jobs waiting for other jobs; M << N). Each (logical) processor of a dedicated processor set (configurable) gets a worker-thread assigned. Each worker-thread runs a fiber-pool (launch policy is customizable). A submitted job is always executed by a worker-fiber. While using boost.fiber jobs are scheduled cooperatively so that a job can yield to other jobs during its execution. Jobs can be synchronized via primitives like mutex's, conditions, barriers and channels (message exchange) from boost.fiber without blocking the worker-thread. Fibers provide a fast context switch. boost.job supports to inspect the NUMA topology (e.g. which logical processors are online, and which processors share L1/L2/L3 cache). This information can be used to select a appropriate processor for a job. For a fast access to job related data, boost.job provides functions and classes to allocate memory on NUMA nodes (processors of a NUMA node share cache and have a faster access to its associated memory bank than processors of other nodes.). source: https://github.com/olk/boost-job documentation: http://olk.github.io/libs/job/doc/html/

2 2

Re: [boost] Build Error VS14 + Intel 15.0 (Update 4, the latest)
by degski 15 Aug '15

15 Aug '15

Changing intel-win.jam, line 476 (boost 1.59.0 rc2) from: .iclvars-15.0-supported-vcs = "12.0 11.0 10.0 9.0" ; to: .iclvars-15.0-supported-vcs = "14.0 12.0 11.0 10.0 9.0" ; solves the problem.

2 1

Master branch is open for changes
by Marshall Clow 14 Aug '15

14 Aug '15

The release has been tagged, and library maintainers are free to merge to release again. Thanks to everyone for their cooperation. -- Marshall

1 0

Boost 1.59.0 has been released
by Marshall Clow 14 Aug '15

14 Aug '15

Release 1.59.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains two new libraries and numerous enhancements and bug fixes for existing libraries. New Libraries * Convert: An extendible and configurable type-conversion framework, from Vladimir Batov. * Coroutine2: from Oliver Kowalke For details, including download links, see http://www.boost.org/users/news/version_1.59.0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.59.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Vladimir Prus Rene Rivera Marshall Clow Eric Niebler Daniel James Beman Dawes

5 4

[filesystem] proposal: treat reparse files as regular files
by Paul Harris 14 Aug '15

14 Aug '15

Hi all, -- Proposal -- tl;dr : I propose that we treat all non-symlink "reparse_files" as "regular_files". If the boost library user wants to do something special with these plain reparse files, they should use alternative means. But typically they are supposed to be treated as regular files. This means we could drop the "reparse_file" enum, or continue to use it for a special-case whats_my_real_status() function. --- Motivation --- Windows Server 2012 uses reparse points to implement deduplification. Those files should be treated as regular files in all circumstances. Currently, they are not classed as "regular" files, so fs::copy() will skip those files, and library-user code written to list files based on official examples will ignore all dedup'd files. This is causing serious and latent problems at the user end, because deduping only happens occasionally after X days, and users cannot easily check if a file is dedup'd (they look just like regular files). --- Real life example --- Another example of reparse use is the "Symantec Enterprise Vault" (version 10), which I found running on one site. It replaces files on the server with reparse-point files. FSUTIL REPARSEPOINT QUERY filename.txt shows the contents of the reparse buffer, which is a URL to an internal HTTP server. The url points to a .asp link with a bunch of codes and dates to identify the file in the server. Copy-pasting that URL into a webbrowser allows you to directly download the file via the webbrowser, which is pretty neat I suppose. In this case, the reparsed-files in Windows Explorer all have grey X crosses on their file icon. If you "type" them (via cmd) or open them, the icon loses the grey cross and the file is no longer a reparse point file. My software refused to read the files because they were "not regular files". Once I adjusted the boost code (described below), my software saw them as regular and opened the files. The file icons lost the grey cross. SO it seems that the file server automatically downloads and replaces the files with the stored content on demand, and the file reading client program should really just treat these files as normal files. --- Short logic --- reparse files (that are not symlinks) should almost always be treated as plain files. They are a mechanism for MS file servers to store files in clever ways, but the client should not care and just read/write them as if they were normal files. This is different to all the other "other" files which can't be treated like normal files: block, character, fifo, socket, unknown So, reparse files should not be grouped with the "other" file types. They are also NOT symlinks, and should not be treated as symlinks (which would require special decisions for copying, or querying the status, or checking if the target still exists). --- What are reparse files --- I did some reading, if I understand correctly: Reparse points give drivers (on the server) a chance to get data through some other specialised means (eg query from a cluster store). They are processed by the server, not the client, so clients should treat reparse data as opaque data. EXCEPT for symlink reparse files. https://msdn.microsoft.com/en-us/library/dd541667.aspx quote:"The following reparse tags, with the exception of IO_REPARSE_TAG_SYMLINK, are processed on the server and are not processed by a client after transmission over the wire. Clients should treat associated reparse data as opaque data." It seems like the rest of the tags are used for connecting files to other types of storage (eg long term storage, cluster storage). Clients may need to do something special with SOME reparse point files, IF the client cares about how long the file read may take. https://msdn.microsoft.com/en-us/library/windows/desktop/aa365505(v=vs.85).… quote: "Most applications should take special actions for files that have been moved to long-term storage, if only to notify the user that it may take a while to retrieve the file." --- Changes required --- Option 1: change is_regular_file() to return true where type==reparse_file I don't like this option, as library-users could be checking the type directly instead of using is_regular_file(). Option 2: These functions return reparse_file: fs::file_type query_file_type(const path& p, error_code* ec) file_status status(const path& p, error_code* ec) file_status symlink_status(const path& p, error_code* ec) They should instead return regular_file instead. --- How to test with dedup files --- Creating dedup'd files is a feature only available on Windows Server 2012, I believe, although Windows XP/Vista/7/8/10 clients all can read dedup files. Here is how I created a windows server to test with (for free!) on a demo Azure cloud server. I have one working, so if anyone would like to use it for their testing, let me know. Step one: follow this blog article: http://blogs.technet.com/b/tommypatterson/p/azureservertrial.aspx once the machine was "running" I clicked Connect at the bottom. That gave me an .rdp file which in theory I could use with rdesktop, but it uses a DNS name that was only just created, so that didn't work. When you click the name of the server in the list, it shows the public IP on the right.. and the port then you can do this $ rdesktop that.ip.addr:port But only if you have the latest rdesktop AND you have set up kerberos something-something. Instead I found a windows computer and used remote desktop from there. --- Once inside, in the "Server Manager --> Dashboard" window on the screen, click "Add Roles" then go next next until "Server Roles" expand "File and Storage services" , "File and iSCSI" , and tick "Data Deduplication" Then next next etc and Install. Wait a bit... and its done. http://www.techrepublic.com/blog/data-center/configuring-windows-server-8-d… --- Continuing on that webpage... Time to enable dedup. There is a temp disk D: so lets enable there. Method 1... I did this and then went to method 2... Start PowerShell, type: "Enable-DedupVolume D:" Method 2... in that same Dashboard, hit the 4th button (File and Storage Services) Then Volumes --> Disks click Volume 1 at the top, and then right click D: at the bottom --> Configure Dedup. To try and accelerate this puppy, I set the "age to dedup" to 0 days. http://www.techrepublic.com/blog/data-center/windows-server-2012-deduplicat… --- Time to make something to dedup. We'll just duplicate the warning.txt file that exists on D: In powershell: PS> D: PS> $file = Get-Content DATALOSS_WARNING_README.txt Then, do these 2 commands a bunch of times until "big.txt" gets to say 6MB PS> Add-Content big.txt $file PS> $file = Get-Content big.txt Then use windows explorer (or other) to make a dozen copies of big.txt Copy c:\windows\explorer.exe to D: to give it something to dedup Go to D: and then copy-paste explorer.exe a dozen times. In PowerShell, type: PS> Update-DedupStatus -Volume D: PS> Start-DedupStatus -Type Optimization -Volume D: and then wait for it to finish. you can track its progress with: PS> Get-DedupJob PS> Get-DedupStatus -Volume D: --- So, once its deduped, you check. PS> FSUTIL REPARSEPOINT QUERY big.txt you should see that its a reparse point with that 0x800etc0013 code. Copy-paste big.txt to big2.txt and check it with the query, and it should tell you big2 is NOT a reparse point. NOW you have some files to test the boost library... You can't zip them up (they lose the dedup tag), you have to run boost binaries ON the computer in the sky. --- Finish --- Thanks for reading, Paul

5 30

[COre] Pull request for enable_if_type
by Joel FALCOU 13 Aug '15

13 Aug '15

Hi, I just refurbished and pushed an old patch adding the enable_if_type SFINAE utility to core. https://github.com/boostorg/core/pull/15 I tried to keep it simple and make the doc proper. This utility has been laying around various boost library and was "reinvetned" in bosot.SIMD. I think it's worth being in core so code duplication is kept to a minimum. Comments welcome

2 3

[spirit] 1.59.0 rc3: compiler warning in real_impl.hpp
by Tobias Loew 13 Aug '15

13 Aug '15

Hi, with MSVC 11, 32-bit build I get a compiler warning in boost\spirit\home\qi\numeric\detail\real_impl.hpp : 287 warning C4244: '=' : conversion from 'unsigned __int64' to 'double', possible loss of data since I usually comile with warnings-as-errors this broke my build. Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/spirit-1-59-0-rc3-compiler-warning-in-re… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

Any interest in a M:N green threading library?
by Xu Chen 13 Aug '15

13 Aug '15

Just cleanup some codes I wrote before, there is a M:N green threading library built on top of Boost.Thread and Boost.Coroutine, conceptually it works like goroutines in Go and (once existed) green threads in Rust. With some refinements, it now supports all C++11/14 threading standard, along with some extensions exist in Boost.Thread such as thread_group and chainable futures. It can be integrated with Boost.ASIO, all ASIO async functions can be used as sync ones in green threads, similar to Boost.ASIO/Boost.Coroutine integration. Also it has some facilities to communicate with foreign threads, can by used to integrate with external libs such as database drivers. The code can be found at https://github.com/windoze/boost.green_thread I don't know much about boostbook tools so the documents are kind of crippled, but I'll improve it if needed. Regards, Chen Xu

4 5

Re: [boost] [build] Problems with VC14 and MSPDB140.DLL (was: [testing][teeks] MSVC-14 errors about MSPDB140.DLL)
by Adam Merz 12 Aug '15

12 Aug '15

Andrey Semashev <andrey.semashev <at> gmail.com> writes: > > I created a Connect ticket about it: > > https://connect.microsoft.com/VisualStudio/feedback/details/1651822/incorr ect-mspdb140-dll-version-picked-in-x86-x64-cross-tools-environment > This ticket appears to be set to private; would you mind editing it to public visibility so that we may upvote it? Regards,

5 5

1.59.0 rc3 is now available
by Marshall Clow 12 Aug '15

12 Aug '15

New Release candidate files for 1.59.0 are available at: http://boost.cowic.de/rc/ RC3 should fix the problem with VC14 and MSPDB140.DLL. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (boost_1_59_0_rc3.7z) = 0a2e512844f3e30a6240f8139ee983f3 MD5 (boost_1_59_0_rc3.tar.bz2) = 6aa9a5c6a4ca1016edd0ed1178e3cb87 MD5 (boost_1_59_0_rc3.tar.gz) = 51528a0e3b33d9e10aaa311d9eb451e3 MD5 (boost_1_59_0_rc3.zip) = 08d29a2d85db3ebc8c6fdfa3a1f2b83c Thanks! -- The release managers P.S. Release notes are here: http://www.boost.org/users/history/version_1_59_0.html

3 3

[context] msvc /SAFESEH
by Jeff Flinn 12 Aug '15

12 Aug '15

I need to build my application with /SAFESEH which uses boost coroutine which uses context. I'm getting the following link errors: 1>libboost_context-vc100-mt-gd-1_53.lib(jump_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libboost_context-vc100-mt-gd-1_53.lib(make_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. I've built boost static libs with the same MSVC vesion and options (sans /SAFESEH as it's not a compile/lib option) Compiler/linker versions: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 Microsoft (R) Incremental Linker Version 10.00.40219.01 Has anyone run into this and resolved the error? Any insight is appreciated. Thanks, Jeff

3 9

[build] Overriding warning level for clang
by Edward Diener 11 Aug '15

11 Aug '15

In my user-config.jam for clang I have added: <warnings>on to the configuration section of the 'using clang' toolset. Nonetheless I still see '-Wall' on the command line when I compile. My other <cxxflags> settings which are part of the toolset are reflected by the command line. Even if I change to <warnings>off in the toolset I still see '-Wall' on the command line. Why is this not working and is there any way I can change the warning level for clang so that it is not 'Wall' on the command line ? The clang compiler is wonderful but with 'Wall' it spews out a boatload of information I normally do not need.

1 0

[build] Problems with VC14 and MSPDB140.DLL (was: [testing][teeks] MSVC-14 errors about MSPDB140.DLL)
by Andrey Semashev 11 Aug '15

11 Aug '15

On Sat, May 23, 2015 at 4:40 PM, Hartmut Kaiser <hartmut.kaiser(a)gmail.com> wrote: > >> All tests for Boost.Log (and I suspect any other built libraries) on MSVC- >> 14 >> are failing because of this error: >> >> LINK : fatal error LNK1101: incorrect MSPDB140.DLL version; recheck >> installation of this product > > My workaround was to edit the 'Path' env variable in one of the temp files > generated by bjam (b2_msvc_14.0_vcvarsall_amd64.cmd in your temp directory) > not to point to the x64 cross compiler, but to the native one. For me this > involved changing > > C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64_x86 > > To > > C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64 I encountered the same problem with VC14 RTM on my VM. This was a clean install of VC14 RTM, there were no CTPs or RCs installed on this machine. I removed the b2_msvc_14.0_vcvarsall*.cmd scripts and ran b2 with address-model=64 to build my tests so that these scripts are re-created from scratch, so it looks like there is a problem with how these scripts are generated by b2. I found 3 instances of mspdb140.dll on my system in these locations: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64 The last two are for 32 and 64-bit native compilers. The first one, I assume, is for use by IDE. The problem is that the first path is listed in b2_msvc_14.0_vcvarsall_x86_amd64.cmd in the "SET Path=..." line prior to the compiler-specific paths. Removing it from the Path solved the problem. Could Boost.Build be adjusted so that the cmd files are generated correctly in the first place?

9 25

[range] index adaptor with size_t as index_type
by Tobias Loew 10 Aug '15

10 Aug '15

>From version 1.55 to 1.56 the index_type of the index of the range index-adaptor was changed from size_t to ptr_diff which e.g. allows for negativ start values. But this has the side-effect that comparison with other size_t-values (e.g. a call to vector's size()) results in a compiler warning for comparing signed and unsigned values (on MSVC 11: warning C4018: '<' : signed/unsigned mismatch). I'm proposing a specialized version of the index adaptor, where the index_type is size_t and the start index is 0 (zero) and explicit specification of the start-value is not possible. A possible name could be "uindex". comments / critics / pros / cons are welcome Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/range-index-adaptor-with-size-t-as-index… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[python] Help with boost python build
by Andy Thomason 10 Aug '15

10 Aug '15

Hi All, I have had highly variable results with Boost.Python mostly due to linker errors or failures of Python to find DLLs. Python is not great at reporting why it fails, for example not naming failures to load dependent DLLs on Windows which does not make this a joyous experience. I have never managed to get any Boost.Python example - mine or otherwise - working on Windows and have had limited success on Linux. It is little surprise that all the examples on Stackoverflow avoid Bjam for builds. For my genetics library, I have an example that has a single source file and the Jamfile reads thus: python-extension genetics : bindings.cpp : <toolset>gcc:<cxxflags>-std=c++11 ; with: using python : 2.7 ; in ~/boost-config.jam ie. as minimal as possible. This builds well on linux (I am adding a library to the head of modular boost). When I run: python -c "import genetics" with appropriate PYTHONPATH I get a run-time symbol search error: ImportError: <...>/genetics.so: undefined symbol: _ZNK5boost6python7objects21py_function_impl_base9max_arityEv My guess would be that rather than this one symbol, Python is failing to load the shared lib: ~/modular-boost/bin.v2/libs/python/build/gcc-4.8/debug/libboost_python.so.1.59.0 As a postscript, It would be lovely if there were no static or dynamic libraries to link with when compiling with Boost.Python and a unity build would be a nice option as this would bypass linker and runtime related errors. It would probably compile faster in my long experience with such projects. Any help would be welcome. Andy. --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com

1 0

[regression tests] Adding regression tests for mingw(-64)/gcc and clang on Windows
by Edward Diener 10 Aug '15

10 Aug '15

I don't know if I am supposed to ask questions about running regression tests in this mailing list or in the Boost testing mailing list, but I will try here first. The Boost testing mailing list seems to be for actual test result problems and the like. For a long time now we have had no regression tests for mingw/gcc or clang targeting gcc on Windows. The only regression tests for Windows are for various releases of VC++. I have limited resources but I have a laptop usually sitting idle, except for occasional travel where I take it with me, and I am set up to run tests on that machine for mingw/gcc and clang on Windows. However mingw/gcc and clang have limitations when running tests in that, both relying on various mingw/gcc implementations, the path to the implementation must be added at the beginning of the PATH before running any of the tests. I have already argued with the mingw-64 people about this necessity but they are adamant that this should be the case even just to compile/link properly ( and have setup their directory structure to enforce it ), and I don't want to waste my breath further with them. Currently I have a batch file that does that for me when running tests for aany particular library, but I don't know how that can be achieved when running the regression tests unless possibly I run regression tests for only a single toolset at a time, and manipulate the PATH accodingly. But that is really time consuming since evidently all of Boost must be downloaded to the run directory each time. Is there an easy solution to this or do I have to look at run.py and try modify it accordingly ( I know Python well ) ? Also I notice on the Boost web site regression test page ( http://www.boost.org/development/running_regression_tests.html ) that the options of the regression tests are somewhat documented but none of the commands are documented. Is there further documentation about the regression test commands anywhere ?

1 0

Build Error VS14 + Intel 15.0 (Update 4, the latest)
by degski 10 Aug '15

10 Aug '15

I have encountered the following error when building boost 1.58 (and 1.59-b1): C:/boost_1_58_0/tools/build/src/tools\intel-win.jam:194: in configure-really from module intel-win error: msvc 14 not supported for intel toolset version 15.0 I'm using the following line to build boost: bjam -a -d+2 --toolset=intel-15.0-vc14 "-sINTEL_PATH=C:\Program Files (x86)\Intel\Composer XE 2015\bin\intel64" cxxflags="/O2 /Quse-intel-optimized-headers /Qstd=c++14 /Qipo /Zc:forScope /Oi /MT /EHsc /Qparallel" "-sINTEL_BASE_MSVC_TOOLSET=vc-14_0" "-sINTEL_VERSION=15" "-sZLIB_SOURCE=%HOME%\zlib-1.2.8" "-sBZIP2_SOURCE=%HOME%\bzip2-1.0.6" variant=release instruction-set=nehalem threading=multi link=static runtime-link=static --stagedir=stage64_static address-model=64 architecture=x86 --without-python --without-mpi --disable-filesystem2 stage > icc_log_stage.log The above worked fine with VS11 and Intel 15.0. The combo (VS14/ICC15) is obviously supported by (MS/Intel), and works fine in the IDE (Community Edition). I confirm the problem with bootstrap.bat, this has been around for a long time, and always had to build the 32bit version first. I ran into it as I have decided to stop building 32-bit. The obvious work-around is to build bjam seperately, not a killer for me, but might be for some. The main issue I report, is though and it would be a shame if the 1.59 release would not allow for that combo, as finally MS have released a free, non-crippled, release of their IDE with (finally, in 2015) full support for C++11... I'm happy to test some things out if necessary, I'm not capable of adressing the issue though...

1 0

Re: [boost] [asio-users] [http] Formal review of Boost.Http
by Lee Clagett 09 Aug '15

09 Aug '15

On Sat, Aug 8, 2015 at 5:16 AM, Vinícius dos Santos Oliveira < vinipsmaker(a)users.sf.net> wrote: > 2015-08-08 0:10 GMT-03:00 Lee Clagett <forum(a)leeclagett.com>: > >> FWIW it should be possible to do client and server side pipelining with >> this design right now. The reads and writes of the HTTP Socket concept >> should be (and currently are by `basic_socket`) handled independently. >> Since the notification for a write completion is based on the lower layer >> write completion, and NOT whether a HTTP response was received, multiple >> (pipelined) requests should be possible by a client. Similarly, this design >> should allow servers to handle pipelined requests in parrallel. Providing a >> framework for client or server pipelining will require more work, and >> should probably not be a part of the Socket concept. In fact - >> > > The current design **does** support pipelining. Some HTTP clients disable > pipelining because some buggy servers will get confuse. This won't happen > with Boost.Http (there are tests to ensure pipelning is working). > > What the current design does **not** support is handling pipelined > requests concurrently. When you starting read a request, the write_state[1] > will change to finished until the fully request is received, so you can't > get multiple request while you don't issue the replies. This behaviour is > explained in the ServerSocket concept[2]. > > There are just too many ways to allow HTTP concurrent pipeline that would > be transparent for the user, but all of them are heavier. If I was to allow > handling multiple concurrent HTTP pipelined requests, I'd expose user > cooperation, so the abstraction doesn't become so heavy. The user would > need to be aware if the reply for some request can already be delivered or > not. Of course this means the socket will need to remember order and attach > some id to the request messages. It can be problematic in alternative > backends because the id could be of a different type and makes it difficult > to use the same message type with different HTTP backends. What do you > think? The design would just be more complex for not much gain. HTTP/2.0 > allow real multiplexing and doesn't show this problem. > I agree that providing any pipelining framework in the library is probably unnecessary right now. However, the design should not inhibit such functionality from being added (which I do not think is a problem with this design). > I think the ServerSocket concept should be removed entirely. The >> `http::basic_socket<...>` models both concepts, so theres lots of server >> specific code in it, which seems confusing to me (is this really a "basic" >> socket?). >> > > basic_socket uses basic_ prefix just like basic_string. > I was asking whether basic_socket should NOT model the http::ServerSocket concept. I understood the naming convention, and the decision to provide the implementation as a configurable template. The problem is the lack of composability. If a different http::Socket concept is desired (someone not using ASIO, etc.), then the http::ServerSocket concept has to be re-implemented also since there is no other implementation. The obvious way is to achieve composability is to use inheritance with: `http::basic_server_socket<Socket>` where `Socket` is a http::Socket concept. Inheritance in this situation has its drawbacks, for sure (a virtual destructor should be considered). > I think standalone functions for typical client and server operations can >> be implemented as "composed" operations similar to `asio::async_write`. The >> documentation will have to be explicit on what the composed function is >> doing so that users know whether the Socket concept has outstanding reads >> or writes (and therefore cannot do certain operations until the handler is >> invoked). In fact, if there is a server operation that _cannot_ be done >> with the Socket concept, then the concept probably needs to be re-designed. >> > > About "users know whether..." seems like a bad idea if I want to deliver > multiple backends. Some implementation details should just be abstracted > away. > > http::SocketServer implementations manipulate the state of the http::Socket (and indirectly the asio::tcp::socket), making some actions unavailable after invoking those functions. For example, after invoking `async_write_response`, no writes on the http::Socket/http::ServerSocket or asio::ip::tcp::socket can occur until the callback is invoked because it calls asio::write on the asio::ip::tcp::socket directly. So unless I am incorrect, it is important for the users to know whats being manipulated (the effects). I don't understand what you mean by "if there is a server operation that > cannot be done with the Socket concept [...]". Boost.Http has two concepts, > ServerSocket and Socket. Socket concept will be useful to client-side HTTP > and that's the reason why there are two concepts. > > The http::ServerSocket concept requires a http::Socket to write its messages, but does the http::ServerSocket concept need to be a refinement of the http::Socket concept? This implies a strong relationship. The current specification looks like a http::ServerTraits concept - its specifying how a http::Socket is being used in situations specific to servers. There doesn't appear to be any additional state tracking needed for the http::ServerSocket functions, which is why I suggested standalone functions (I didn't see the FileServer section). In fact implementation can be inverted; make all of the current implementations for http::ServerSocket standalone functions, and then have the default http::ServerTraits implementation call the standalone versions of the functions. The http::ServerTraits should then take a http::Socket as an argument for each of the functions. This complete de-coupling would allow someone to independently change the behavior of any related server functions, even while using the same http::Socket object. [1] https://boostgsoc14.github.io/boost.http/reference/write_state.html > [2] "The ServerSocket object MUST prevent the user from issuing new > replies while [...]", > https://boostgsoc14.github.io/boost.http/reference/server_socket_concept.ht… > > Lee

2 3

[Utility] intuitive scoping with BOOST_WITH
by Marcel Ebmer 08 Aug '15

08 Aug '15

Hi Everyone, What if you could do std::mutex the_mutex; using Lock = std::unique_lock<std::mutex>; void f() { with(Lock{the_mutex}) { do_something(); do_other_thing(); } } *...or...* struct Pushed_matrix { Pushed_matrix() { glPushMatrix(); } ~Pushed_matrix() { glPopMatrix(); } }; void f() { with(Pushed_matrix{}) draw_something(); } At C++Now (2015), I presented this idea of mine and a macro implementation (BOOST_WITH) in a lightning talk. Since reception was good and more serious than the talk itself, I continued to work on it. I would appreciate informal review and opinions: https://github.com/maysl/BOOST_WITH Marcel

3 3

1.59.0 rc2 is now available
by Marshall Clow 08 Aug '15

08 Aug '15

Release candidate files for 1.59.0 are available at: http://boost.cowic.de/rc/ (rc1 failed a smoke test) As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (boost_1_59_0_rc2.7z) = 1854999b8d32ba89acbf4384fe55e0ab MD5 (boost_1_59_0_rc2.tar.bz2) = 1783f07dd4736ffd9fc97874ce4ef4bf MD5 (boost_1_59_0_rc2.tar.gz) = 47e6db09fd7e1265b9b7046f654e9a72 MD5 (boost_1_59_0_rc2.zip) = 9061c5bbc3399f3f220036e896c202aa Thanks! -- The release managers P.S. Release notes are here: http://www.boost.org/users/history/version_1_59_0.html

3 2

[1.59] Still unmerged changes in the super-project
by John Maddock 08 Aug '15

08 Aug '15

There are a number of unmerged changes in develop of the super-project that look like they should really be in release, in particular: * Jamroot, contains amongst other things a very old fix for Oracle C++ support, without which building with Oracle is more or less broken. In fact unmerged commits on this file go back to....wait for it... 2011 ! * bootstrap.bat has fixes for some rather embarrassing typos. * bootstrap.sh has lots of fixes, also going back to 2011. Those were the "highlights" that stood out to me, the full list with unmerged changes is: .gitmodules | 613 ++++++++++++++++++------------------ .travis.yml | 6 +- Jamroot | 32 +- boostcpp.jam | 47 +-- boostcpp.py | 459 --------------------------- bootstrap.bat | 4 +- bootstrap.sh | 24 +- doc/Jamfile.v2 | 2 - doc/src/boost.xml | 2 - libs/libraries.htm | 10 +- libs/maintainers.txt | 5 +- status/Jamfile.v2 | 4 - status/explicit-failures-markup.xml | 41 +-- tools/Jamfile.v2 | 2 +- 14 files changed, 336 insertions(+), 915 deletions Best, John.

3 2

[iostreams] Ticket #5237 - Chance to get fix applied into Boost 1.59?
by Deniz Bahadir 08 Aug '15

08 Aug '15

Hi everyone, in our application we use Boost.Iostreams with GZip functionality to write some data into gzipped output-files. Eventually we realized, that we would get corrupted output-files if no data was available that could be written to the output-file By looking for a patch we stumbled across an issue-report [1] which seems to be open for more than 4 years, although a simple fix was already provided in its comments 3,5 years ago. My question is: Can somebody apply that fix to the development branch and could it still make it into the upcoming Boost 1.59 release? Thanks, Deniz [1] https://svn.boost.org/trac/boost/ticket/5237

4 4

Getting started with Boost
by Prathamesh Dahale 08 Aug '15

08 Aug '15

Hello, I am Prathamesh Dahale, third year computer engineering student. I am interested in contributing to Boost through gsoc 2016. I know c and c++, I am familiar with c++ STL and I have very good programming skills. I participate in many online programming contests. my handle on codechef.com is 'miracle003'. I would like to utilize my skills for contributing to Boost and I am interested in doing some project with Boost in gsoc 2016. from where i should start?

2 1

Re: [boost] [asio-users] [http] Formal review of Boost.Http
by Lee Clagett 08 Aug '15

08 Aug '15

Sorry for any duplicates and top posting, but I didn't reply-all, so boost got dropped (which was probably more important). And this likely ruins some mail clients (again sorry!). On Fri, Aug 7, 2015 at 11:10 PM, Lee Clagett <forum(a)leeclagett.com> wrote: > On Fri, Aug 7, 2015 at 6:29 PM, Vinícius dos Santos Oliveira < > vinipsmaker(a)users.sf.net> wrote: > >> 2015-08-07 12:53 GMT-03:00 Niall Douglas <s_sourceforge(a)nedprod.com>: >> >>> I do not believe Http is ready for peer review for these reasons, and >>> I personally would urge you withdraw it until you have fixed these >>> issues and then come back to us. If you do not withdraw it, I will >>> vote for rejection. >>> >> ...[large snip]... >> > >>> * I don't understand why you cannot issue more than one async read at >>> a time nor async write at a time. In something like pipelined HTTP >>> that seems like a very common pattern. I smell a potential design >>> flaw, and while the docs mention a "queue_socket" I can't see such a >>> thing in the reference section. >>> >> >> Too much synchronization and buffering. >> >> The pipeline has the following requests: >> >> A => B => C >> >> If I were to allow replies to request B, the design would be more >> complex, increasing the difficult to implement alternative backends and >> everyone's life. Also, the reply to request B cannot actually be sent while >> the reply to request A is on hold. This means that the whole response to >> request B would need buffering and if response B is a video live stream, >> this means an implicit (the user cannot know) crash after an unfortunate >> memory exhaustion. I couldn't claim a **lightweight** server if this >> excessive buffering was to occur. I couldn't claim the project is >> appropriate for embedded devices if I had chosen the buffering approach. >> It's a trade-off. I should write about it in the "design choice" of the >> documentation. >> >> HTTP/2.0 does have proper multiplexing and it can be more useful to >> respond several requests without "head of line blocking". >> >> A queue socket is a concept, I don't provide one. I can look into how >> make the documentation less confusing by adding a page exclusively >> dedicated to explain the problem it solves. Would that work for you? >> >> > FWIW it should be possible to do client and server side pipelining with > this design right now. The reads and writes of the HTTP Socket concept > should be (and currently are by `basic_socket`) handled independently. > Since the notification for a write completion is based on the lower layer > write completion, and NOT whether a HTTP response was received, multiple > (pipelined) requests should be possible by a client. Similarly, this design > should allow servers to handle pipelined requests in parrallel. Providing a > framework for client or server pipelining will require more work, and > should probably not be a part of the Socket concept. In fact - > > I think the ServerSocket concept should be removed entirely. The > `http::basic_socket<...>` models both concepts, so theres lots of server > specific code in it, which seems confusing to me (is this really a "basic" > socket?). I think standalone functions for typical client and server > operations can be implemented as "composed" operations similar to > `asio::async_write`. The documentation will have to be explicit on what the > composed function is doing so that users know whether the Socket concept > has outstanding reads or writes (and therefore cannot do certain operations > until the handler is invoked). In fact, if there is a server operation that > _cannot_ be done with the Socket concept, then the concept probably needs > to be re-designed. > > Lee >

2 1

Is master open for release 1.59?
by Vicente J. Botet Escriba 08 Aug '15

08 Aug '15

Hi, I was on vacations. Is the master branch open for merge? Best, Vicente

3 4

[Property Tree] Comments in info format
by Gavin McNiff 05 Aug '15

05 Aug '15

First time posting, so hopefully no grave faux pas! I have found the Property Tree info format very useful for config files. However, the in-built comment ";" can be a little limiting. In particular, I miss not being able to comment out an entire block. To this end I have being modifying the relevant header to file to allow ; // and -- as inline comments and /* */ as a block comment. These are familiar to many users. Naturally, with every Boost release I have to re-patch this file, so I thought maybe the info format could be updated to allow comments in these styles. Since the format is not any kind of official format and adding new comment styles should not break existing files, I would hope there should be no major objections. I have taken the liberty of attaching the updated header file, as well as the adapted test file. The _gmcn suffix is just for identification purposes. The changes in the code are marked with !!! GMcN !!!. The changes pass in the built-in tests and my own usage tests. Best regards Gavin McNiff

2 2

boost::asio and I2P connection handling.
by Janusz Zradomia 05 Aug '15

05 Aug '15

Hello. I would like to extend the ASIO (in boost::asio) by adding support for new virtual protocols. For example i2p, it is similar to Tor but it works with equivalent of .onion hidden servers, and is not used to connect to "normal Internet" usually. It works like this: - the end-points, equivalent of the ip4/ip6 address, is a very long string (around 500-1000 characters, it is technically the public key of data) - the end-point address is often expressed as shorter version of the address, that is around 50 characters afair, in two possible formats (b32 and b64) - user can create new i2p listening socket for TCP-like data (for stream of bytes), or for UDP-like data (message oriented). On creation of the listening socket you can get a new own "address" as above. Or, you can on creation/before creation tell it to reuse an previously created address by providing the std::string with private key of it (that you saved previously) - user can connect to an i2p address. When connecting, he is getting a new endpoint from which he connects, or he can reuse old one by loading the private key as above. - there exists naming lookup system, that allows to convert domain-name strings like "zzz.i2p" into proper i2p address Can I add such new class of protocol on top of ASIO? Which classes I need to extend (create child class)? Where exactly would each of the listed above functions go?

1 0

[http] Formal review starts on Friday
by Bjorn Reese 05 Aug '15

05 Aug '15

This is a short notice that the formal review for the Boost.Http library starts on Friday and will last for ten days: from August 7th until August 16th. A proper announcement will be made on Friday, which will include links to the source code and the documentation to be reviewed. As a courtesy to the ASIO community we encourage your participation in the formal review as well.

2 1

[1.59] SVG's not showing up in beta
by John Maddock 05 Aug '15

05 Aug '15

SVG graphics used in documentation are still absent from the (beta) website, see for example: http://www.boost.org/doc/libs/1_59_0_b1/libs/math/doc/html/math_toolkit/sf_… I assume a script somewhere needs updating? Thanks, John.

2 2

Trying out QVM with multiple library implementations
by Andrew Hundt 05 Aug '15

05 Aug '15

I'd really like to try out QVM because I have to switch between a half dozen matrix, vector and quaternion types constantly and would prefer not to write functions for each conversion and operations between them. Examples of the formats I need to handle are: *Eigen <http://eigen.tuxfamily.org/index.php?title=Main_Page>:* Eigen::Affine3d Eigen::Quaterniond + rotation and translation versions *vrep <http://www.coppeliarobotics.com/helpFiles/en/apiFunctions.htm#simBuildMatri…>:* float[3] (vrep vector) float[4] (vrep quaternion) float[12] (vrep homogeneous transform matrix) *cisstVector <https://github.com/jhu-cisst/cisst/tree/master/cisstVector>:* vctDynamicVector <https://github.com/jhu-cisst/cisst/blob/master/cisstVector/vctDynamicVector…> vctQuaternion <https://github.com/jhu-cisst/cisst/blob/master/cisstVector/vctQuaternion.h> vctDynamicMatrix <https://github.com/jhu-cisst/cisst/blob/master/cisstVector/vctDynamicMatrix…> There are also fixed versions of the "Dynamic" objects. + rotation & translations Is there any particular concerns I need to take regarding alignment, ordering (row vs column major) etc? For example, the ordering of the quaternion data components differ between eigen and rep: // 0123 // vrep quat is ordered xyzw, // eigen quat is ordered wxyz Any advice on how to go about this would be appreciated so I can try QVM out! Cheers! Andrew Hundt

2 1

Broken links in 1.58.0 release notes
by Jonathan Wakely 04 Aug '15

04 Aug '15

At http://www.boost.org/users/history/version_1_58_0.html the release notes on the breaking change for Variant say "See get.hpp and polymorphic_get.hpp descriptions for more info" but both hyperlinks are broken.

2 1

Review Request: QVM (generic Quaternion, Vector and Matrix operations library)
by Emil Dotchevski 04 Aug '15

04 Aug '15

Boost QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Online documentation and a link to download the source code under the Boost license is available at http://www.revergestudios.com/boost-qvm/. I would like to thank Adam Wulkiewicz for volunteering to be the review manager for QVM and for his valuable initial feedback. Thanks, Emil Dotchevski

13 30

BOOST_NO_CXX11_CONSTEXPR and msvc-14.0
by Peter Dimov 04 Aug '15

04 Aug '15

I see that BOOST_NO_CXX11_CONSTEXPR is no longer being defined for msvc-14.0. Even the RTM version has spotty support for constexpr though; the techniques in my metaprogramming article, for example, don't work. One simple example that fails is #include <type_traits> template< int I > struct X { }; template<class... T> constexpr int f( T... t ) { return 1; } template< class... T > struct Y: X< f(std::is_same<T, void>::value...) > { }; Y<void, void, void> y; int main() { } Another is #include <type_traits> template< class... T > struct X { static constexpr bool v[] = { std::is_same<T, void>::value... }; }; int main() { }

15 32

[serialization] Errors when testing withe mingw-64/gcc on Windows
by Edward Diener 04 Aug '15

04 Aug '15

When running serialization tests with mingw-64/gcc on Windows I get repeated errors of the form: ..\..\../boost/archive/detail/basic_oarchive.hpp:64:5: error: function 'boost::archive::detail::helper_collection& boost::archive::detail::basic_oarchive::get_helper_collection()' definition is marked dllimport get_helper_collection(){ Is this a known problem ? Testing with VC++ does not give any errors.

2 5

Boost 1_59_0_b1_rc1 is available for testing
by Marshall Clow 02 Aug '15

02 Aug '15

Release candidate files for 1.59.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (boost_1_59_0_b1_rc1.7z) = f54a97e5ee7f8e3d04cd9af8396e30f9 MD5 (boost_1_59_0_b1_rc1.tar.bz2) = 9804305aae0c9de9f8cfc02e3de75167 MD5 (boost_1_59_0_b1_rc1.tar.gz) = e584770bd76885c123a0426d24466fe2 MD5 (boost_1_59_0_b1_rc1.zip) = ee34f223aa789a6b3f727cb9480651ed Thanks! -- The release managers

13 14

[Log, Filesystem] Build errors using B2 and Jamfiles distributed with Boost
by Norbert Wenzel 02 Aug '15

02 Aug '15

I'm a lazy guy so I try to use Boost.Build whenever I can. That way I can simply download the Boost tarball, extract it into my project's directory and use the Jamfiles distributed with Boost. Recently I switched to 1.58 and my project setup failed to build, complaining that Filesystem would be built twice with different settings* (actually it would be built one time without any specific settings and one time with a sane set for my platform). I managed to create a "simple" project setup to reproduce this error. I created a library (testlib) with a single extern C function that fills a user provided buffer with the current working directoy. This library uses Boost.Filesystem internally. Therefore the lib's Jamfile also references the Jamfile distributed with Filesystem. I created an executable (test) that calls the lib function and also uses Filesystem to get the parent directory of the current working directory (as reported by the lib function). This setup builds fine as long as I use cout to write the paths in the test exe. When I replace cout with Boost.Log (and therefore also reference the boost_log and boost_log_setup projects) this setup only builds with Boost 1.57. From 1.58 on (also tested with 1.59.b1) the project does not build because Filesystem would be built twice with different settings. Since the error can be triggered by changing the Boost version I reckon this is due to a change in one of the Jamfiles (probably Boost.Log) and not a problem of Boost.Build per se. But for reference I use Boost.Jam Version 2014.03 (the one distributed with 1.58). Since the "simple" setup consists of a few files and directories I've made it available via Github: https://github.com/norbertwenzel/boost-build-problem I've posted this here and not to Boost.Build ML since I suspect this is due to a change in one of the two libraries mentioned and not a bug or misuse in/of Boost.Build. Any help appreciated. thanks, Norbert *) The exact error message I got: error: Name clash for '<p/tmp/b2_problem/external/boost_1_58_0/bin.v2/libs/filesystem/build/gcc-5.1.0/debug>libboost_filesystem.so.1.58.0' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - none error: - <abi>sysv <binary-format>elf <log-api>generic <preserve-test-targets>on <python-debugging>off <python>2.7 <testing.execute>on <threadapi>pthread error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets.

2 3

[http] Scheduling a review for Boost.Http
by Bjorn Reese 01 Aug '15

01 Aug '15

I am about to schedule a formal review for Boost.Http (see blincubator for links.) If there are no objections I suggest that the review is held from August 17 to 30.

3 4