- Boost - lists.preview.boost.org

[Boost.AFIO] Formal Review
by Joel FALCOU 02 Sep '15

02 Sep '15

> 1. Should Boost.AFIO be accepted into Boost? The topic of asynchronous file operation is very very important and quite critical in our days. Boost needs such a library but I fear *current* AFO is not there yet. I vote NO for its inclusion in Boost in its current form. > 2. What is your evaluation of the design? I think the intent are goods but there's some icky parts. The use of future and other asynchronous element in the API cudl be made more clear and easy. Thomas Heller made a compelling lsit of gotcha that shoudl be followed. Currently i had to fight against my habit of writing future absed code to get the stuff working. > 3. What is your evaluation of the implementation? Next to small scale issues like mammoth headers and liberal use of allocation in the implementation of some functions, I think the main culprit is to simplify the implementation by splitting the ABI stable part into another component. Also, the way asynchronous cmponents are used internally hould be aligned with the required fix on the public API. > 4. What is your evaluation of the documentation? The documentation is hard to follow and some 'simple example' are clearly not that simple. This should be the second major point of improvement. > 5. What is your evaluation of the potential usefulness of the library? THis kind of library is very useful and as I said, we need one with proper design and implementation. > 6. Did you try to use the library? Played around with the examle and the doc. > 7. How much effort did you put into your evaluation? Roughly 10-12 hours > 8. Are you knowledgeable about the problem domain? Not with async file I/O but I have a fair amount of experience in asynchronous computation and parallel programming in general. As a concluding note, I *really* want Niall to keep going on making AFIO the reference async file I/O library. Just take the needed time to reflect on the afformentionned PAI and implementation issues and remember that there is no rush to get there.

3 3

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

[atomic] Generalized read-modify-write operation
by Andrey Semashev 02 Sep '15

02 Sep '15

Hi, I was wondering is there would be interest in a generalized read-modify-write operation in Boost.Atomic. The idea is to have a atomic<T>::read_modify_write method that would take a function that would perform the modify on the atomic value. The interface could be roughly this: template< typename T > class atomic { public: // Returns the original value T read_modify_write(F modify, memory_order order = memory_order_seq_cst); }; Usage example: // Saturating increment atomic< int > a; a.read_modify_write([](int n) { return n < std::numeric_limits< int >::max() ? n + 1 : n; }); The implementation could synthesize a CAS loop around the modify function or (ideally) wrap it inside the LL/SC instructions, also in a loop. I believe, in order for this to work the modify function should meet certain requirements: 1. It must not use atomic operations (on this or other variables) or thread synchronization primitives. 2. It must not call functions that might involve context switching (e.g. syscalls, i/o). 3. It should be as small as possible and have the least possible working set (that is the number of accessed variables). 4. It must be prepared to be called multiple times. 5. It must be prepared to receive a value that has never been stored in the atomic variable. The first restriction is essential to avoid deadlocking in case of the emulated (lock-based) atomic<>. Thread synchronization primitives may possibly be using atomic ops internally, so are prohibited as well. The 2 and 3, besides just being something rational one would strive for anyway, are mostly targeted to allow to inject the function call inside the LL/SC pair. It is known that some architectures are very sensitive to what is happening between the LL and SC instructions, so accessing some memory from the modify function or switching the thread context will result in SC always failing and an infinite loop. The 5 would allow to make the first load non-atomic, which can be faster. The CAS or SC instruction will fail if the loaded value was inconsistent. I know there's probably no way to ensure that the function meets these requirements, and it is possible to get an infinite loop in runtime, so maybe always using a CAS loop would be a safer approach, even on an architecture with LL/SC instructions. My hope is that compilers will someday provide intrinsics for this and will be able to generate optimal code, when possible. Does this look interesting to anyone? Comments?

4 7

[AFIO] Formal review
by Giovanni Piero Deretta 02 Sep '15

02 Sep '15

Hi all, This is my review of boost.afio. In fact I have still more comments on the library, but this is taking already too long and I'm well past the review deadline, so I'm sending what I have. I'm hopefully going to post the second part in the next few days. 1. Should Boost.AFIO be accepted into Boost? Please state all conditions for acceptance explicitly. No, not at this time. While the library is potentially quite useful, possibly to larger niche than expected to the author, I have many issues with both the documentation and the API itself, which would need to be resolved before acceptance. To be clear, this is not a conditional acceptance. I believe a full review is warranted to verify that the issues have been addressed. The author is obviously quite experienced in this area (or at least has done a lot of research), so I strongly encourage him to resubmit the library in the future as it has the potential to be be a great contribution to boost. 2. What is your evaluation of the design? My preference, but wouldn't require for acceptance, would be to use ASIO async protocol that leaves the choice of the completion notification strategy to the user . If the library wants all async functions to return futures, it should follow the standard future idioms. First of all, having futures which claim 'standard conformance' and then carry extra hidden error payload is unacceptable. Also functions should take handlers as parameters and not futures. The user should be responsible of explicitly 'then' chaining futures. The library should follow the standard semantics for handle types (i.e. single ownership move only wrappers system handles), and similarly for the future wrappers for such handles (i.e. future<handle>, not shared_future<handle>). Other reviewers have discussed these issues better than I could, so I won't expand further. The dispatcher should probably be called filesystem because that's what it is. The overridable per thread global dispatcher is evil. Functions should take a dispatcher explicitly (or through a handle_ptr) or use a static global dispatcher that represent the global filesystem. Does the library need to distinguish between files and symlinks at open time by calling differently named functions? I'll assume that's the case, but I would like to know the rationale. File, directory, symlink functions should be verbs and called open_file, open_directory, open_symlink. They should return differently typed handles (i.e. file_handle, dir_handle, sym_handle). As an aside, the handle types should have value semantics and be movable. To help generic code, rmdir, rmfile and rmsymbol should be unified under the same function name (rm, or better delete). The parameter type can be used to select the correct overload. Functions that return handles must do so explicitly (i.e. no implicit handle payload). The library should *never* cause the program to crash because of external causes (i.e. files and dirs disappearing or truncated, external locks taken, lock forcibly removed, up to and including disk failure). It is ok to abort on a failed internal consistency check, although it would be nice if the check+abort was encapsulated in an overridable macro (BOOST_AFIO_ASSERT maybe?). It is fine and even encouraged for the check be present even in release builds. The library *must* not suppose that every other program interacting with the filesystem is using AFIO. It is fine if the library were to give some additional guarantees (for example advisory locking becomes non-advisory), but these guarantees should be properly documented. For example, writes in append should be guaranteed atomic no matter what the program doing the writes is doing. In practice, this means that afio should document in detail the implementation of each operation for each backend for each operation so that a knowledgeable user can make the necessary inferences. In practice this seems already to be mostly the case. The documentation has a huge amount of notes on how the various FS and OSs differ and what are the different guarantees. AFIO should provide a standardised set of flags describing the various capabilities and a query interface, so that the inevitable different code paths do not need to be fs name dependent or, worse, #ifdef based. A good starting point for deciding which flags to expose, are the various FS tables scattered through the docs. 3. What is your evaluation of the implementation? I haven't had a chance to do an as in depth evaluation. Additionally, files with thousands of lines do not make it easy to read the code. The git repo contains both v1 and v2 subdirectories, and I'm not sure which one is the one actually under review (the docs say 1.5, not sure which one it is)' A few comments: Overuse of shared_ptr is in my experience code smell as the unclear ownership semantics lead to bugs down the line. The amount of ifdefs is staggering. Most of them are probably necessary, but the number of options that the library can be configured with certainly doesn't help.' It depends on external non-boost libraries, which it seems (but I can't be sure because of the layer of versioning macros) inject names outside the boost::afio namespace, which it shouldn't happen. With two spinlock acquisition per move, the lightweight future/modand seems anything but lightweight. The library should really use boost::future instead of rolling its own. The author should attempt to fold possible improvements directly into boost.thread. Similarly for any necessary improvements to Boost.Asio (for the WoW issue) and Boost.Filesysterm (for boost::path). The abstraction overhead seems excessive, especially for a library suposedly IO bound. The author should at least try to mach the performance of the naive openmp implementation. BTW, nonvolatile ram based storage will be becoming mainstream within the year, so the author might need to revisit very soon the relative cost of various operations. Random suggestions (feel free to ignore these): - look into non temporal stores to help with cache pollution. - have a libnfs backend + NFS over loopback for truly asynchronous filesystem operations (performance is probably going to atrocious). - experiment with the "O_NONBLOCK disk read" patches for the linux kernel. 4. What is your evaluation of the documentation? As noted by others, the documentation does not seem to be of boost standard quality; At times it feels more like a stream of consciousness; often irrelevant or less important information is presented before more important ones. Disquss Comments do not belong in the documentation. With JS disabled, some pictures are not shown, at least in the single page docs. I'm less bothered than others about the 'try AFIO online button'. In fact it would be nice to have such a button after each example (I'm not suggesting that the author should provide it though). Any reference to not-implemented features should removed and at best moved to a separate section at the end of the documentation. A common patters is: "" AFIO implements * A * B (not implemented) * C (not implemented) * D (not implemented)"" which is, honestly, a bit ridiculous. Similarly scattering references to preivious versions of the library all over the documentation is confusing. These should go to a separate history page and/or changelog. The misuse of Terms of Art ('monad' 'precondition') seem a bit worrying. At every occurrence of the term 'filing system' my brain trips. For a while I thought it meant something subtly different from the more common 'filesystem' or 'file system'. This could be just me, so feel free to ignore this unless others complain. The documentation often references C++1z coroutines, which as far as I understand are far from being standardisation ready. It would be better if examples using boost.coroutine, boost.context or even asio.coroutine were provided. ** Intro The first paragraph is a nice introduction, but it should mention prominently that AFIO helps prevents file system races. Move the sub points of bullet 8 to top level, instead deemphatize and sythetize the performance claims under a single bullet. Before claiming performance, describle what the library can do. Reduce any reference to APIBind to a single line (something 'AFIO can be used as a standalone library thanks to APIBind', details elsewhere; also do not claim that APIBind is a boost library). Remove any references to backends from this section. Totaly remove references to unimplemented backands. Supported compilers and platforms, jenkins and uni tests etc do not belong here. Neither do links to dispatch benchmarks. You might want to mention that it is a C++11 library written as part of the GSoC. A reference to ASIO might or might not belong here (No ASIO class or concept seem to be part of the interface). Remove the Batch section from the simple example. Also the rest should stand by itself, without the comments. About the example itself: I find it surprising that you call the results using verbs and operations using names. A better naming convention would be nice. Also in general please prefer type result = op(params); to type result(op(params)); at least when op is an important operation. The initialisation syntax together with the noun based naming convention makes it harder to parse examples. ** Cheat Sheet The frist few paragraphs are interesting, but should go after the table. The table as is not useful, other than an alternate index. I would expecte something like; function name, paramenters, result, very short description. I have no idea what the other columns of the table are trying to convey. The related functionality at the end does not belong here. ** Design Introduction and Rationale In this page I would expect to find an analysis of a generic afio async operation, why a certain interface was chosen, how futures help compose operation, how an operation is implemented internally. For every choice a discussion of the design tradeoff should be presented. Unfortunately, after an interesting "why did I write this library", the chapter loses itself. The version history does not belong here unless is used to justify design choices, but other than saying that previous versions where slower, no other information is conveyed. In particular, at this point of the documentation I would expect a thorough explanation of the concept of a FS race and the minimum guarantees given by the library with respect to file system races. Additionally as the library comes with its own future implementation, a detailed explanations of why boost::futures is not sufficient should be given. As an aside, the author claims that the library is completely lock free, and it would be wait free if not for the the use of spinlocks. This does not makes any sense as the use of spinlocks also make the library *not* lock free, unless the author is using a non-standard meaning for these terms (again see previous comment about misuse of Terms of Art). ** Write Ordering Constraint The explanation on how sync behaves like a barrier and the description of scheduling ordering and dependencies is very useful, and it should be a great starting point for a formal treatment of race freedom. The description of TripleGit is completely unnecessary and should be removed. ** Compilation This section is very confusing. Let' say I want the default (whatever it is) and do not define anything. I get this: After defining your build macros of choice, making latest AFIO available to your code is as simple as: #include "boost.afio/include/boost/afio.hpp" // latest version #include "boost.afio/include/boost/v1/afio.hpp" // specific version if being used standalone or if being used as part of Boost: #include "boost/afio.hpp" // latest version #include "boost/afio/v1/afio.hpp" // specific version I have no idea what any of the above means. ** Boost AFIO Installation into Boost Why is this information not part of the previous chapter? Any reference to non boost.afio should be dropped (except possibly to a link at the end to an external non boost distribution). I understand the the external build instructions are useful for reviewers, but they shouldn't have been part of the documentation under review. ** Supported compilers not much to say here other than, assuming AFIO is accepted, the table would be static and reflect the specific released version instead of trunk. ** Example 1 All references to the macro based versioning should be dropped. I have no idea why the example datastore has to return a monad<shared_ptr<iostream> >. The shared pointer is gratuitous, and for the ""simplest interface" errors can be communicated by exceptions As defined I would expect an interface like this for the simplest store: optional<std::string> read(std::string key) void write(std::string key, std::string content) or something like this for something more complex: some_special_container_range read(std::string key) template<class Range> void write(std::string& key, const Range& range); Possibly the author has in mind something different than a key value system. ** Example 2 Because the interface is non-ideal, it is hard to evaluate the next examples. Freedom from directory renames in nice, but I wouldn't count it very high in the list of requirements for an object store. A dispatcher is introduced, without explanation of what it is. The cheat-sheet mentioned it, but it should be described in more details here. The VM shenigans required to make something like utils::file_buffer_allocator<> work can have serious and hard to pinpoint performance and scalability considerations and shouldn't be presented as a performance win uncritically. The tradeoffs should be discussed. Also read mappings can defeat the point of async IO as the application threads will be subject to blocking page faults. Both previous comments are not trying to suggest that mmap is not useful, but it shouldn't be treated as a transparent optimisation as it can have application wide consequences well outside IO code. As far as I understand boost.afio leaves the choice to the client code and never does mmap behind its back; still the examples should present best practices. The example is too long and has too many distractions. The demonstration a streambuf can be implemented on top of afio is quite interesting, but should be relegated to a separate example. ** Example 3 BOOST_MONAD_PROPAGATE, in addition to being in the wrong namespace, is not documented anywhere (at least a search in the one page doc does not lead anywhere) and seems completely unnecessary. I guess it expands to either a return or a throw. In 'The problems with this naive design', the table does not have unit of measure. The information is interesting, although, without any comparison of durability, concurrency and atomicity guarantees of any of the solution, is hard to infer anything (not that I expect much from a NoSQL db...). ** Example 4 ' Linux is different from other operating systems in that you must explicitly request metadata updates to be sent to physical storage' I'm not an expert, but I thought this was true only for ext3/4 (and only with some, albeit default, mount options) and generally considered broken even by Linus himself. If that's the case might be important to point it out so users can choose other FSs. The atomic key replacement example is nice. Should the library provide pre-made recipes for these kind of uses? In The FS table, the first few column titles should be reworded so that all checkmarks mean that a positive feature is available and 'x'es mean a lack of it. 'This is a good example of where Intel's Hyperthreading can really penalise overall performance sometimes: filing systems tend to parallelise linearly to real CPU core count only.' Why is that the case? I would expect the exact opposite in fact. Are you sure the performance bottleneck is not somewhere else (TLB invalidation, cache misses, badly sized hash lock pools)? ** Example 5 The extent based and append behaviour are great. 'Any writes we make within a 4Kb boundary is probably safe'. 'Probably safe' is not something I want to see when implementing a DB. The example is probably way too complex for a tutorial, also the fact that is incomplete makes it hard to evaluate. ** Hello World Please remove the long comments from the examples. Either make them part of the surrounding explanation or footnotes. ** A less toy example The documentation sometimes claims that AFIO is either faster than dumb stream based IO and sometimes assert that it is slower. Please pick one and stick to it. Or better, do not make any performance claims outside a benchmark page. Performance should not be the biggest claim for AFIO anyway. The example uses stl_future which is not defined anywhere in the documentation as far as I can see. when_all_p(ihs).get(); should probably be when_all_p(ihs_req).get() In general, unless I've completely misunderstood the example, all the .get() calls impose synchronisation, which means that the parallel_concatenate is not as asynchronous as possible. Also it should really schedule handle closes at the end and return a future<void>. for(auto &i : ihs) lasts.push_back(dispatcher->depends(ohresize, i)); The meaning of dispatcher->depend on this code is not obvious at all. From mailing list discussions I assume that depend(future a, bufure b) is a.then([b] { return b; }), but what's the role of the dispatcher here is opaque. Even more surprisingly, a few lines below depend is called as a free function. Also, a few lines above this line is present: when_all_p(ohresize).get(); which should impose an explicit synchronisation, making the depend superfluous. This is the implementation I would like to see: using br = boost::range; auto async_size = [](auto&& name) { return async_info(name).then(auto&& info) { return info.size(); }; }; auto open =[](auto&& name) { reutrn asyn_open(name); }; auto get = [](auto&& future) { return future.get(); }; auto always = [](auto&& x) { return [x=std::move(x)] { return x;}; }; auto unwrap = [](auto&& fr) { std::vector<typename decltype(fr)::value_type> ret; copy_to(ret, mapped(fr, get)); return ret; } template<class PathRange> std::future<std::size> asyn_concat(std::path destname, PathRange&& srcnames) { auto sizes = when_all(br::mapped(srcnames, async_size)) .then(unwrap)).share(); auto total_size = sizes .then([](auto&& range) { return br::accumulate(range.get(), 0);; }); auto srcs_range = when_all(br::mapped(srcnames, open)); auto dest = when_all(async_open(destname), total_size) .then([](auto fdest, auto size ) [] { auto dest = fdest.get(); return async_truncate(dest, size).then(always(dest)); }); return wait_all(srcs_range, dest, fbuffers) .then([](auto&& fsrcs, auto && fdest, auto&& fsizes) { auto&& sizes = fsizes.get(); std::vector<handles> srcs = unwrap(fsrcs); std::vector<std::future<> > writes; struct ctx { off_t offset = 0; ssize_t len = 0; std::vector<char> buf = std::vector<char>(1024*4); }; std::vector<ctx> ctxs; ctx.reserve(src.size()); std::size_t off = 0; auto dest = make_unique(fdest.get()); for(int i = 0; i != src.size(); ++i) { ctxs.push_back({ off, sizes[i] ); off += sizes[i]; auto& ctx = ctxs.back(); auto read = [&ctx, &s = srcs[i]] { if (ctx.len < ctx.buffer.size()) ctx.buffer.resize(ctx.len); ctx.len -= ctx.buffer.size(); return async_read(s, ctx.buffer); }; auto write = [&ctx, &dst = dest.get()] { auto off = ctx.off; ctx.off += ctx.buffer.size(); return async_write(s, off, ctx.buffer); }; auto read_write = [&ctx, read, write](auto self){ if(ctx.len) return read().then(write).then(self); return make_ready_future(); }; writes.push_back(read_write(read_write)); } return wait_all(writes).then( [ctx=std::move(ctx), dst=std::move(dst), src=std::move(src)] { return wait_all( mapped(srd, [](auto&& s) { return async_close(s); }) .then([d = async_close(dst)] { return d; })) }); }); }; Note that everything is perfectly parallel and dependencies are minimal. Most operations use unique semantics except for 'sizes' where I didn't bother to do better. The lifetimes of buffers and handles in the read/writes are admittedly subtle, but not too much. Instead of creating N futures per file, I'm creating just a single one at a time. ** (all examples) Overall the examples are nice, the progression of additional features makes sense. The code should be cleaned up to remove superflous code. Comments should be removed and the code should be discussed in the prose (possibly referencing line numbers). I suggest that the strawman interface using iostream is removed. The lookups should simply return initially optional<string>, then future<string>. future<string> (or future<vector<char> >) of course does not work well for large buffers. You could return something like future<chunk>, where chunk has the following interface: struct chunk { const char * begin(); const char * end(); std::size_t size(); // an empty chunk means we are done future<chunk> next(); // invalidates this }; but the reality is that futures are not great for lazy streams. You could look into reactive streams, but that's another can of worms. For pure read/writes I suggest an asio-like interface which uses callbacks would be optimal and readily familiar to boost users. 5. What is your evaluation of the potential usefulness of the library? I had never had a chance to look at the library in the past, and my only impressions of it came by the many references and claims made by the author in the boost mailing list. In particular I was baffled by the author's claim that the ASIO callback interface is not adequate for file IO. I could not understand how async read/writes from a file could be so significantly different from socket io. Turns out that the actual I/O part is just a small part of the library, and the async part even less. The bulk of the library is about writing roboust filesystem manipulations. In my mind, where boost.filesystem is designed as a simple interface to file system operations for script-like programs, AFIO attempts to be the goto interface for robust applications. 6. Did you try to use the library? With what compiler? Did you have any problems? I didn't trey to compile or use the library. 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? An in depth study of the documentation. I didn't keep track of the hours, probably 10 or more. 8. Are you knowledgeable about the problem domain? Asynchronous File IO? No. Race free file IO? Neither, but had to deal with these kind of issues in the past. Something like AFIO might have been useful.

2 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

Boost 1.53 Libraries for Android
by Ian Calegory 31 Jul '15

31 Jul '15

I've compiled and made available for download the Boost C++ 1.53 Libraries for Android. This enables cross platform code in C++ that uses the Boost libraries. It is especially useful for Embarcadero's FireMonkey environment in RAD Studio, where cross platform code written in C++ can run on Windows, Android, Mac OS X, and iOS. Conceivably, cross platform code can be written using the Boost libraries that can run on all of the aforementioned environments. (The other platform libraries would have to be available, of course, and RAD Studio comes with Boost pre-compiled for Windows; Boost of course is widely available for Mac OS X.) Here is my web page where the include files and .a library files (one file for each of the four main Android architectures) is available for download: http://www.mandelmania.net/boost.html Any comments welcome. logo final small 11 Ian Calegory Software Engineer <mailto:ianc102002@yahoo.com> ianc102002(a)yahoo.com <http://www.mandelmania.net/> http://www.mandelmania.net

1 0

devector feedback request
by Benedek Thaler 30 Jul '15

30 Jul '15

Dear Boost, I'm happy to announce the new devector container developed as part of the GSoC programme reached a presentable state. I invite you to take a look and ask for feedback. Main features: - every std::vector feature - front operations with amortized linear complexity - optional small buffer optimization - customizable growth policy (see the docs) - unsafe methods for the brave and performance addicts Documentation: - Intro: http://erenon.hu/container/container/non_standard_containers.html#container… - Usage: http://erenon.hu/container/container/examples.html#container.examples.devec… - API: http://erenon.hu/container/boost/container/devector.html#idp86138944 Code: - Implementation: https://github.com/erenon/container/blob/devector/include/boost/container/d… - Tests: https://github.com/erenon/container/blob/devector/test/devector_test.cpp Thanks, Benedek

6 11

[Log] Running in a separate thread
by Andrew Hundt 29 Jul '15

29 Jul '15

I really only need some of the functionality of BOOST_LOG_TRIVIAL, perhaps plus loving to a file in addition to the console. However, my only true need is that all the work (or as much as possible) must be done in a separate thread so as not to slow the current thread down. Right now when I use BOOST_LOG_TRIVIAL as is it causes latency in my network communications which have soft realtime requirements so I've had to comment all of my logs out. Is there a straightforward non-intrusive solution to having as much of the work as possible for boost.log be done in a separate thread? Thanks for your help! Cheers! Andrew Hundt

3 4

Boost.DLL formal review result
by Vladimir Prus 28 Jul '15

28 Jul '15

The Boost.DLL library is accepted. Congratulations to Antony, and thanks for everybody who reviewed the library! The votes were as follows: - Ralf Globisch - Yes - Klaim - Joël Lamotte - Yes - Niall Douglas - Yes, conditionally - John P Fletcher - Yes - Bjorn Reese - Yes - Edward Diener - Yes - Rodrigo Madera - Yes - Richard - Yes I'd like to also thank Thomas Trummer, Rob Stewart and Ion Gaztañaga for their contribution to review. The key suggestions from the review are listed below. None is critical enough to become a formal prerequisite, or require a mini-review. The library can be added when Antony feels its ready. Naming ----------- There was a concern that "DLL" might sound windows specific, and search for best terminology. This does not seem all that important, as soon as documentation introduces the terminology it uses, and is consistent. OSX support ------------------- The library was found not to work on OSX; I believe this issue was already fixed off-list with help from Rodrigo. Documentation ---------------------- Several people requested improvements. Bjorn and John, in particular, pointed out specific issues. This seems to be the post important change prior to adding the library. Dependencies on Boost and system headers ---------------------------------------------------------------- It was suggested that the library does not depend on other Boost C++ Libraries. While it might be helpful to some users, I find it logically impossible for a Boost formal review to request that dependencies on Boost libraries be removed. It was also mentioned that Boost.DLL is header-only library and includes system headers that can bring a lot of symbols and maybe macros. I don't think an actual problem was reported, though, and there is no way to avoid the problem while staying header-only. It's up to the author to consider these suggestions and do something, or don't do anything. Continuous integration -------------------------------- There was a recommendation from Niall to improve CI of the library, including static analysis, valgrind, Windows CI, showing CI status in documentation and so forth. These are good suggestions. At the same time, they are not specific to Boost.DLL, and it's not the goal of a formal review to create new generic development process requirements. Many existing libraries of indisputably high quality do not have these requested mechanisms. Therefore, the author can act on these suggestions as he sees fit. Thanks, -- Vladimir Prus http://vladimirprus.com

4 3

BGL pull requests
by Mads Jensen 27 Jul '15

27 Jul '15

Hi, There are many quite trivial pull requests on Github for BGL. Can the project responsible please have a look at them? Most of them just fix typos and add more clarity to the documentation. Thank you, -- Med venlig hilsen / Kind regards, Mads Jensen Gunnery Sergeant Hartman: What's your excuse? Private Cowboy: Sir, excuse for what, sir? Gunnery Sergeant Hartman: I'm asking the fucking questions here, private! Do you understand? -- Full Metal Jacket

6 8

[mpl] Problem with VC++14 and boost::mpl::size_t
by Edward Diener 27 Jul '15

27 Jul '15

The just released VC++14 has a problem with the boost::mpl::size_t template. After preprocessing it sees: namespace boost { namespace mpl { template< std::size_t N > struct size_t { static const std::size_t value = N; typedef size_t type; typedef std::size_t value_type; typedef integral_c_tag tag; typedef boost::mpl::size_t< static_cast<std::size_t>((value + 1)) > next; typedef boost::mpl::size_t< static_cast<std::size_t>((value - 1)) > prior; operator std::size_t() const { return static_cast<std::size_t>(this->value); } }; template< std::size_t N > std::size_t const boost::mpl::size_t< N >::value; }} and gives the error message: size_t.cpp(nnn): error C2872: 'size_t': ambiguous symbol predefined C++ types (compiler internal)(16): note: could be 'unsigned int size_t' size_t.cpp(nnn): note: or 'boost::mpl::size_t' pointing to the line after it encounters 'struct size_t' as far as I can make out ( you need to preprocess the size_t.cpp test, comment out the #line directives and run the test against the preprocessed result to see what the compiler is objecting to ). It therefore fails a number of mpl tests which all prior versions of VC++ pass. It flags this error in 5 mpl tests which use the boost::mpl::size_t integral wrapper, among which the easiest to analyze is the size_t.cpp test itself. Anybody have any idea what is going on here with the compiler, or whether it can be fixed somehow in VC++14 for the mpl code ?

9 21

[config] BOOST_NO_CXX11_HDR_CODECVT is not defined for VC14
by Andrey Semashev 27 Jul '15

27 Jul '15

Hi, I see that BOOST_NO_CXX11_HDR_CODECVT is not defined for MSVC-14, although it is known that the codecvt facets are unusable because of linkin errors: https://connect.microsoft.com/VisualStudio/feedback/details/1348277/link-er… You can also see STL mentioning DevDiv#1060849 here: http://blogs.msdn.com/b/vcblog/archive/2014/11/12/visual-studio-2015-previe… and I can see that the problem is not fixed in RTM. This also concerns std::codecvt specializations for char16_t and char32_t. Can we define the BOOST_NO_CXX11_HDR_CODECVT macro for MSVC?

3 6

[predef] Fails on Intel/win
by John Maddock 27 Jul '15

27 Jul '15

BOOST_COMP_INTEL is set to 0, which means that [ predef-require "BOOST_COMP_INTEL" ] fails. __INTEL_COMPILER is set to 1500. BOOST_COMP_INTEL is set to ( (((0)%100)*10000000) + (((0)%100)*100000) + ((0)%100000) ) Thanks, John.

6 17

__NR_eventfd syscall
by Alexey Brodkin 27 Jul '15

27 Jul '15

Hi, When building Boost for ARC architecture we're seeing this failure: --------------------->8--------------------- ./boost/asio/detail/impl/eventfd_select_interrupter.ipp: In member function 'void boost::asio::detail::eventfd_select_interrupter::open_descriptors()': ./boost/asio/detail/impl/eventfd_select_interrupter.ipp:50:50: error: '__NR_eventfd' was not declared in this scope write_descriptor_ = read_descriptor_ = syscall(__NR_eventfd, 0); --------------------->8--------------------- This happens clearly because ARC following Linux kernel's UAPI doesn't define __NR_eventfd syscall. If you look here https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/unis… you may notice that "eventfd" syscall with some others resides in "#ifdef__ARCH_WANT_SYSCALL_NO_FLAGS". And from what I may see only "score" architecture has this __ARCH_WANT_SYSCALL_NO_FLAGS defined. Most of other arches that don't use unistd.h from "include/uapi/asm-genereic" folder have "eventfd" syscall defined. For example it's true for ARM (both 32 and 64 versions). So I'd say it's not the best way to use directly a syscall that's being obsoleted in "Boost". And so real fix would be to modify Boost's "eventfd_select_interrupter::open_descriptors()" for example with use of really generic "eventfd2" or even better use libc's eventfd() call instead of direct syscall. Any thoughts what would be the best fix here? -Alexey

1 1

[ublas] [1.5.9.0b1] Merge patch for broken boost::numeric::ublas::shallow_array_adaptor since 1.58
by Hugues Malphettes 24 Jul '15

24 Jul '15

Hi everyone, Does somebody knows how to proceed to merge the patch filed here: https://svn.boost.org/trac/boost/ticket/11207 I am forced to remain on 1.57 because of this issue. At the minimum there are 4 projects affected: myself, Mark Moll who filed the issue on track and nasosi and vh4n who filed the same patch here: https://github.com/uBLAS/ublas/pull/30/files I had convinced myself that because it had been merged in github we would be good to go for 1.59. I just tested 1.59.0b1 and it has not been merged. Many thanks for your help! Hugues

1 0

Test Runner Update to vc14.0 - CTP 6
by Tom Kent 23 Jul '15

23 Jul '15

Just a heads up, I have just updated the test runner teeks99-08f-win2012R2-64on64 from vc14.0 - CTP 4 to vc14.0 - CTP 6. The change should show up in the next run of that runner in a few hours. I think some people were waiting to see if MS was fixing some things, so I thought I'd send a message letting people know these results would be available. Tom

7 22

Genetics library: Volunteers needed
by Andy Thomason 23 Jul '15

23 Jul '15

Hi All, I am recruiting users for the putative genetics library. https://github.com/andy-thomason/genetics We have a few simple examples of gene searching and I am working on a more complete aligner example and some performance improvements to the index data structure. For data, you can obtain the human genome from: ftp://ftp.ensembl.org/pub/release-81/fasta/homo_sapiens/dna/Homo_sapiens.GR… Interesting problems we would like to solve: Given a 20 character sequence with up to six errors, what is the fastest way to list all possibilities other than a brute force search (CRISPR). Can we use JNI to connect the library to Hadoop and other distributed seach systems? Can we construct a database of all known viral genomes including recombination? Can we detect variations in MHC VDJ regions within a single sample? Many other interesting puzzles are there to be found... Andy. --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com

4 4

Trouble with Boost.Test on ESXi
by William Winder 23 Jul '15

23 Jul '15

I'm using Boost.Test and Boost v1.55 to unit test an application on Windows/Linux/ESXi. The ESXi build is done on a CentOS 5.10 machine, this has been working well for the main application, but the Boost.Test binary hits an assert before running any tests: /tmp # ./MyTests Test setup error: system_error produced by: ::sigaltstack( 0, &sigstk ) != -1: Function not implemented The "Function not implemented" problem has been a recurring problem for me while making my application compatible with ESXi. My basic understanding is that ESXi implements a subset of glibc. I saw a similar issue here: http://comments.gmane.org/gmane.comp.lib.boost.testing/7782 I'm wondering how I can disable this assert and what the repercussions would be. Thanks

2 1

Re: [boost] Genetics Library:Volunteers Needed
by Mudit Sharma 23 Jul '15

23 Jul '15

Hi! I am deeply interested in volunteering for genetics library in Boost. I have sound knowledge of boost libraries. Note:This project can help me personally. Thanks! M

1 0

gcc 5.1/6.0 warnings with smart_ptr
by Gennadiy Rozental 23 Jul '15

23 Jul '15

Hi, There are bunch of warnings like these: ../boost/smart_ptr/shared_ptr.hpp:249:65: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations] Any chance we can shut these down? Maybe update toolset config? Gennadiy

1 0

[boost.test] Assertion/crash
by Philip Bennefall 23 Jul '15

23 Jul '15

Hi all, I am having an issue where boost.test is triggering an assert when I make a BOOST_REQUIRE_EQUAL check. It always gives me the same assert. I am on Windows 7 with Visual C++ 2013, compiling a 32 bit application. This error happens both with boost_1_57_0 and boost_1_58_0. The assert says: Debug Assertion Failed! Program: C:\Windows\system32\MSVCP120D.dll File: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\xstring Line: 168 Expression: string iterator + offset out of range Here's the stack: 0041ef44 0149ca07 015c08f0 015c07e0 000000a8 MSVCP120D!std::_Debug_message+0x26 0041ef60 0149ca93 00000053 0041ef80 0041efa0 my_tests!std::_String_const_iterator<std::_String_val<std::_Simple_types<char> > >::operator+=+0x77 0041ef70 0149c91e 00000053 d4f524ac 07d2cff0 my_tests!std::_String_iterator<std::_String_val<std::_Simple_types<char> > >::operator+=+0x13 0041efa0 0149be76 0041efb4 00000053 d4f524ec my_tests!std::_String_iterator<std::_String_val<std::_Simple_types<char> > >::operator++0x4e 0041efe0 0149bdf6 0041f100 07d2ef28 07d2ef7b my_tests!std::_Transform1<char *,std::_String_iterator<std::_String_val<std::_Simple_types<char> > >,char (__cdecl*)(char)>+0x46 0041f034 0149c1b1 0041f100 07d2ef28 07d2ef7b my_tests!std::_Transform1<char *,std::_String_iterator<std::_String_val<std::_Simple_types<char> > >,char (__cdecl*)(char)>+0x96 0041f0c8 0149b5bf 0041f100 07d2cff0 0041f0e0 my_tests!std::transform<std::_String_iterator<std::_String_val<std::_Simple_types<char> > >,std::_String_iterator<std::_String_val<std::_Simple_types<char> > >,char (__cdecl*)(char)>+0x191 0041f148 0149d6e2 0041f18c 00000000 015c0d18 my_tests!boost::unit_test::unit_test_log_t::operator<<+0x10f 0041f2c8 014315dc 0041f320 0041f3f4 015aa770 my_tests!boost::test_tools::tt_detail::check_impl+0x372 0041f364 01404626 00000000 0041f3f4 015aa770 my_tests!boost::test_tools::tt_detail::check_frwd<boost::test_tools::tt_detail::equal_impl_frwd,int,enum my_error_codes>+0xec 0041f458 014050af 000d7550 d4f53c34 00000000 my_tests!basic_operations::playback_decoders::pull_samples+0x146 0041f738 014053e6 015b223c 015b2234 00000000 my_tests!basic_operations::playback_decoders::iteration+0x8cf 0041f758 01405451 d4f53c70 cccccccc cccccccc my_tests!basic_operations::playback_decoders::playback_decoders_mono::test_method+0x26 0041f77c 014399d1 00000000 cccccccc 0041f7a3 my_tests!basic_operations::playback_decoders::playback_decoders_mono_invoker+0x51 0041f790 0148a54f 0041f7cf 076ecff4 00cccccc my_tests!boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (__cdecl*)(void)>+0x21 0041f7a8 01522cc5 0041f7cf 078c4ff0 076ecff0 my_tests!boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused,void (__cdecl*)(void)>::invoke+0x2f 0041f7bc 01522ce7 0041f7cf 0a66aff4 00000000 my_tests!boost::unit_test::callback0<boost::unit_test::ut_detail::unused>::operator()+0x25 0041f7d0 01522a1f 0041f7ef 0041f7f0 01522dbd my_tests!boost::unit_test::`anonymous namespace'::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> >::operator()+0x17 0041f7dc 01522dbd 0a66aff4 0a66aff0 0041f918 my_tests!boost::unit_test::ut_detail::invoker<int>::invoke<boost::unit_test::`anonymous namespace'::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >+0xf 0041f7f0 01521e31 0041f918 0a66aff0 0041f810 my_tests!boost::unit_test::ut_detail::callback0_impl_t<int,boost::unit_test::`anonymous namespace'::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke+0x1d 0041f800 01521b6e 0041f814 538d1e44 0041f87c my_tests!boost::unit_test::callback0<int>::operator()+0x21 0041f810 01521312 01620790 0041f918 d4f53370 my_tests!boost::detail::do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>,boost::unit_test::callback0<int> >+0x3e 0041f87c 01520dc4 0041f918 d4f533f0 00000000 my_tests!boost::execution_monitor::catch_signals+0xd2 0041f8fc 0152259d 0041f918 d4f53268 00000000 my_tests!boost::execution_monitor::execute+0x54 0041f964 014b6723 078c4fa8 d4f5316c 01574668 my_tests!boost::unit_test::unit_test_monitor_t::execute_and_translate+0xad 0041fa60 014a2565 078c4fa8 0041fa7c 014a259a my_tests!boost::unit_test::framework_impl::visit+0x3c3 0041fa6c 014a259a 078c4fa8 01620750 0041fb38 my_tests!boost::unit_test::traverse_test_tree+0x25 0041fa7c 014a22b2 00010040 01620750 d4f53034 my_tests!boost::unit_test::traverse_test_tree+0x2a 0041fb38 014a25b5 06258fa0 01620750 0041fc04 my_tests!boost::unit_test::traverse_test_tree+0x1e2 0041fb48 014a22b2 00000004 01620750 d4f53708 my_tests!boost::unit_test::traverse_test_tree+0x45 0041fc04 014a25b5 07388f98 01620750 0041fdc0 my_tests!boost::unit_test::traverse_test_tree+0x1e2 0041fc14 014a9ccb 00000001 01620750 d4f536cc my_tests!boost::unit_test::traverse_test_tree+0x45 0041fdc0 014b6bc3 00000001 00000001 d4f53538 my_tests!boost::unit_test::framework::run+0x5db 0041fe34 014b6d5c 013b346d 00000001 066fafb0 my_tests!boost::unit_test::unit_test_main+0xb3 0041fe4c 014996f9 00000001 066fafb0 05f44f28 my_tests!main+0x1c 0041fe9c 0149983d 0041feb0 74e4337a 7efde000 my_tests!__tmainCRTStartup+0x199 0041fea4 74e4337a 7efde000 0041fef0 773892e2 my_tests!mainCRTStartup+0xd 0041feb0 773892e2 7efde000 74959ac7 00000000 kernel32!BaseThreadInitThunk+0x12 0041fef0 773892b5 01499830 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x63 0041ff08 00000000 01499830 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x36 Does anyone have any tips for things I might try? Thanks in advance for any help on this! Kind regards, Philip Bennefall

2 1

Boost release 1.59.0 beta 1 is now available from SourceForge
by Marshall Clow 22 Jul '15

22 Jul '15

Boost release 1.59.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/boost/1.59.0.beta.1/ For details of what's in the release, see http://www.boost.org/users/history/version_1_59_0.html. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

3 3

[container] [1.59.0b1] Behavioral (runtime) breakage with flat_xxx + ordered_unique_range + non-default comparator
by Adam Merz 21 Jul '15

21 Jul '15

I've encountered a serious behavioral breakage for code using flat_xxx in conjunction with ordered_unique_range and a non-default comparator in 1.59.0b1. Here is a small repro: #include <initializer_list> #include <algorithm> #include <functional> #include <iterator> #include <iostream> #include <boost/container/flat_set.hpp> int main() { namespace bcont = boost::container; auto const p = [](auto const& desc, auto const& s) { std::cout << desc << ": "; std::copy( s.cbegin(), s.cend(), std::ostream_iterator<int>(std::cout, " ") ); std::cout << '\n'; }; auto const r = {4, 3, 2}; bcont::flat_set<int, std::greater<int>> const s{3, 2, 1}; p("orig set", s); auto s1{s}; s1.insert(r.begin(), r.end()); p("without\tordered_unique_range (expected output)", s1); auto s2{s}; s2.insert(bcont::ordered_unique_range, r.begin(), r.end()); p("with\tordered_unique_range (erroneous output)", s2); } I've worked around this locally by rerouting the ordered_unique_range codepath to the default codepath, but this seems like a showstopper for 1.59.0 as the code's behavior has broken entirely silently. Regards, Adam Merz

2 1

Python bindings for Boost.Interprocess
by Edison Gustavo Muenz 21 Jul '15

21 Jul '15

Hi all, this is my first e-mail on the list, so please be nice, I’m new here. I have this problem in which I need to communicate between two processes, one written in C++ (it’s actually a .so) and one written in python. They need to share large arrays. I’ve searched on the internet for a way to use shared-memory in python, and the only alternative I found was POSIX IPC for Python <http://semanchuk.com/philip/posix_ipc/> (which looks good, but it is *nix only). Also, I find the Boost.Interprocess library to be a joy to use, it worked for the problem I had, so I wanted to use it. Since I didn’t find python bindings for Boost.Interprocess is it desirable to have this? I started writing some code which uses a tiny part of Boost.Interprocess that is necessary to solve my problem. It is working already. I’m asking here to know what do boost experts think about this idea, if it unreasonable or if other developers already had this need. Feedback would be greatly appreciated. Thanks, Edison Gustavo Muenz

2 1

[mpl] Updated fixes on 'master'
by Edward Diener 18 Jul '15

18 Jul '15

A number of fixes in mpl, by Bruno Dutra and Deniz Bahadir, had been tested on 'develop' for quite a long time but had not been merged to 'master' for the upcoming release. The regression tests on 'develop' had shown that the fixes were working properly and I have taken the responsibility of merging them now to 'master' for the upcoming release. I will be checking the 'master' regression tests. If there are any problems I will revert this merge but I am 99.99% certain that the changes are correct, so I take full responsibility for merging. The fixes come from Trac items so I feel that correcting these bugs is important for the upcoming release else I would not have performed the merge and the push to Boost.

1 0

[string_ref] [utility] Add string_view?
by Beman Dawes 18 Jul '15

18 Jul '15

Boost has shipped string_ref since 1.53. See www.boost.org/doc/libs/1_58_0/libs/utility/doc/html/string_ref.html In the meantime, the C++ committee has shipped a final version, named string_view, in the Library Fundamentals TS. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4480.html#string.v… In addition to the name change, the interface in the TS more closely mimics the std::basic_string interface. I'd really like to see the final TS basic_string_view added to Boost so I can start using it now. Using basic_string_ref, and then later having to rename all uses, is less attractive. I suspect others may feel the same way. Because a Boost basic_string_view would be an implementation of a standard library TS class, and because basic_string_ref is already in Boost, it seems a min-review would be sufficient rather than a formal review. So what I'm proposing here is to create a basic_string_view branch of the utility repo, and start working on basic_string_view there. Once it is reasonably compliant with the TS and Boost doc requirements we would hold a mini-review and then merge the branch to develop, and once stable, to release. Comments? --Beman

6 8

Boost 1.57.0 WinCE support/maintenance
by Dennis Driesens 17 Jul '15

17 Jul '15

Hello, We're porting a software product, which uses boost 1.57.0 to Windows embedded compact 7 . In this context I have a few questions. What is the support /maintenance status of boost for Windows embedded compact 7? We patched boost 1.57.0, to make it build for WEC7. Is it possible to have these patches included in boost? Regards, Dennis Driesens Dennis Driesens * Sr. Software Engineer * PU Custom Systems * Dennis.Driesens(a)tomtom.com<mailto:Dennis.Driesens@tomtom.com> * +31 (0) 40 84 44793 office * www.tomtom.com<http://www.tomtom.com>

2 1

svn.boost.org wiki
by Stefan Seefeld 17 Jul '15

17 Jul '15

Hello, I have sent the following to the Boost documentation list, but since this is of broader relevance I have been asked to resend it here... The content of https://svn.boost.org/trac/boost/ seems rather outdated, and it has been confusing me a number of times as it wasn't clear what is and what isn't up-to-date. * There is an entire section "Quick Access to the Boost Subversion Repository". Shouldn't that be removed entirely ? * The section "Git and Modular Boost" starts with "Boost is moving...". Isn't that conversion complete (and thus, shouldn't the docs state that clearly) ? * There are other seemingly outdated bits, but there are relatively minor... What I was actually trying to figure out is how / where to indicate that for Boost.Python I would like issues to be submitted with the respective github issue tracker, rather than the old Boost Trac instance. It's still not clear how to do that (as the Boost docs are again quite monolithic in this respect, i.e. don't allow a per-library policy). So if anyone has suggestions on where / how to express that, please let me know. Thanks ! Stefan -- ...ich hab' noch einen Koffer in Berlin...

4 6

Master branch is open again - for bug fixes, doc updates, etc
by Marshall Clow 16 Jul '15

16 Jul '15

Now that we've shipped the 1.59.0 beta, the master branch is open again for updates. Please do not add new features, etc to the master until after the release. But bug fixes, documentation updates, etc are very welcome. Note that: * GCC 5.2 was released today * VS2015 should be out next week * Clang 3.7 branched for release this week Compatibility with these new compiler releases would be a good thing :-) -- Marshall

1 0

[Iterator][Type_Erasure] Conflicting declaration. (Fix is provided.)
by Deniz Bahadir 16 Jul '15

16 Jul '15

Hi there, I noticed a "conflicting declaration" error when developing a program which uses Boost.Program_Options and Boost.Type_Erasure. Further investigation showed me, that the conflict is actually between Boost.Iterator and Boost.Type_Erasure. A test-case which demonstrates this compiler-error is the following simple two-liner: #include <boost/type_erasure/iterator.hpp> #include <boost/iterator/iterator_adaptor.hpp> Clang is quite verbose and outputs the following: /tmp/boost-1_58/boost/iterator/iterator_adaptor.hpp:44:18: error: target of using declaration conflicts with declaration already in scope using iterators::use_default; ^ /tmp/boost-1_58/boost/iterator/iterator_adaptor.hpp:40:10: note: target of using declaration struct use_default; ^ /tmp/boost-1_58/boost/type_erasure/iterator.hpp:27:8: note: conflicting declaration struct use_default; ^ 1 error generated. The fix is actually quite simple and should be applied to Boost.Iterator. I already provided a pull-request [1] for this. I hope this fix can still make it into the upcoming 1.59 release of Boost. Best regards, Deniz Bahadir [1] https://github.com/boostorg/iterator/pull/15 -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Winterfeldtstr. 21 10781 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir(a)benocs.com www.benocs.com Board of Management: Michael Wolz, Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

3 2

Boost.DLL formal review is ongoing
by Vladimir Prus 16 Jul '15

16 Jul '15

The formal review of Boost.DLL library by Antony Polukhin is nearing the end of the first week. As of today, over 100 people read through the library's tutorial, suggesting quite some interest. However, no reviews were submitted yet. Please take the time to post your thoughts - even if you don't have time to do a full review, or try the library, comments on design and interfaces are still very valuable. The summary of the library features and review checklists are reproduced below. Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library provides a portable across platforms way to: - load libraries at runtime - import and export any native functions and variables - make alias names for C++ mangled functions and symbols - query libraries/objects and executables for sections and exported symbols - self loading and self querying - getting program and module location by exported symbol The documentation can be found at: http://apolukhin.github.io/Boost.DLL/index.html and the source can be obtained at: https://github.com/apolukhin/Boost.DLL Please post your reviews on the mailing list and if possible, answer the following questions: - Should the library be accepted? - How useful is it? - What's your evaluation of - Design - Implementation - Documentations - Tests - How much effort did you put into your evaluation? - Did you attempt to use the library? On what systems and compilers? Thanks, Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

16 42

[afio] AFIO review postponed till Monday
by Niall Douglas 16 Jul '15

16 Jul '15

Just a quick heads up that the AFIO review is postponed till Monday to give me more time to refactor the docs to match the final API. Some quick notes on what will be presented for review, so there are no surprises: 1. I won't have the time to rewrite the code examples into C++ 1z coroutines before the review unfortunately, so you'll get a warning sign in the docs saying that is coming. The code example this matters most to is the find regex in files example as the code is very messy (full of callback handlers) without coroutines. 2. The API presented is expected to be a final API, but the implementation will be a messy conglomeration of the existing mature dispatch engine with the new lightweight future-promises. In other words, code will compile and run, but the internal engine is going to be completely replaced eventually as I debug lightweight future-promises. As lightweight future-promises is all brand new code mostly written between 12am and 4am each night since May after a work day, I don't hugely trust it enough to present you guys with an engine based on it. Just because it passes a conformance suite doesn't mean it is without quirks - plus, I discovered some surprises in the Concurrency TS about which I'll need to get some clarifications. As I mentioned though, the user facing API will be final, as promised. And it does use monads and lightweight future-promise. 3. Minimum compilers will unfortunately be GCC 4.8, clang 3.2 and VS2015. Sorry about that, lightweight monadic future-promises substantially bumped the compiler requirements, even as it is I have several GCC 4.8 specific workarounds. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

[predef] The predef-check functionality is not working on the Android regression tests
by Edward Diener 15 Jul '15

15 Jul '15

I do not believe that predef-check is working at all on the Android regression tests. Predef itself appears to be working as far as the predef macro values. But attempting to use predef-check to set a <cxxflags> value is just not happening. I can attest that just setting a <cxxflags> value, outside of using predef-check, does work correctly on the Android regression tests. The failure is occurring on my VMD tests. But you can also see the failure on the predef tests also. Looking at the info_as_cpp test output at http://www.boost.org/development/tests/develop/developer/CrystaX-NET-apilev… you can see that BOOST_COMP_CLANG > 0 and BOOST_OS_LINUX = 0. Yet if you look at the corresponding check_value test at http://www.boost.org/development/tests/develop/developer/CrystaX-NET-apilev… you will see that the output is 'CHECK_VALUE == undefined', whereas if predef-check were actually working the output should be 'CHECK_VALUE == 1' ( or 'true' ). In all other environments predef-check is working. Maybe this failure of predef-check somehow occurs because the Android tests are a cross-compile, being done on a Unix system but targeting the Android. But for whatever reason the inability of getting predef-check to work keeps my VMD tests from adding the '-std=c++0x' option and the VMD tests all fail without that option since the variadic macro support in VMD for gcc needs C++11 support or better.

3 6

Re: [boost] [Boost-users] Boost 1_59_0_b1_rc1 is available for testing
by Marshall Clow 15 Jul '15

15 Jul '15

On Tue, Jul 14, 2015 at 9:20 PM, Gavin Lambert <gavinl(a)compacsort.com> wrote: > On 15/07/2015 14:59, Edward Diener wrote: > >> Because MPL is so central to everything it seems it is too late to get >> these fixes into 'master', have the regression tested on 'master' and >> into the upcoming release at this point. >> > > Take this with a grain of salt, since I'm not a library maintainer or > release manager, but: > > Since it's still at a beta release stage (if I'm understanding correctly), > this seems to me like the perfect time to merge bugfixes, especially ones > that have already been tested on develop. > > Part of the point of having a beta cycle is to discover these > accidentally-left-out elements and correct them. > > After we ship the beta, before the 1.59.0 release, library maintainers will have time to fix bugs that were found in the beta. -- Marshall

1 0

[foreach] use of boost_foreach_argument_dependent_lookup_hack
by Joaquin M López Muñoz 15 Jul '15

15 Jul '15

Hi, Boost.MultiIndex indices, which are not copyable, interoperate with Boost.Foreach by defining the following: template<typename SuperMeta,typename TagList> inline boost::mpl::true_* boost_foreach_is_noncopyable( boost::multi_index::detail::sequenced_index<SuperMeta,TagList>*&, boost::foreach::tag) { return 0; } Unfortunately Qt (in some configuration modes, at least), defines a macro foreach to Q_FOREACH, which produces the following problem, even if Boost.Foreach was not intended to be used: http://tinyurl.com/nq52xho My question is: would it be OK if the code above was rewritten like template<typename SuperMeta,typename TagList> inline boost::mpl::true_* boost_foreach_is_noncopyable( boost::multi_index::detail::sequenced_index<SuperMeta,TagList>*&, boost_foreach_argument_dependent_lookup_hack) { return 0; } so that "foreach" is not ever mentioned? I understand that Boost.Foreach would still not work unless the macro is not defined, but this would at least save Boost.MultiIndex, which doesn't really depend on Boost.Foreach. Thanks for your comments, Joaquín M López Muñoz Telefónica

4 12

Serializing shared_ptr fails on .template
by Jared McIntyre 15 Jul '15

15 Jul '15

I've run into an issue where VS 2013, and likely earlier versions, fail to serialize a shared_ptr because Visual Studio is choking on the use of ar.template get_helper in load() to remove ambiguity. The issue appears to replicate previous bug report here: https://svn.boost.org/trac/boost/ticket/10727 That report didn't post an example, so instead of adding a new bug, I've posted example code to that existing report. VS 2013 Boost 1.57 Jared McIntyre

3 8

[variant] Maintainer
by Antony Polukhin 15 Jul '15

15 Jul '15

Hi, I've been keeping an eye on Boost.Varinat for a few years. Since then multiple issues were closed; support for rvalues and variadic templates was added; other good things happened. Could I be promoted to an official maintainer of Variant? This will help me to react on issues faster (email notifications) which is essential. I'm also planning to add missing features from N4450 without affecting the current never-empty behaviour and without breaking existing code. -- Best regards, Antony Polukhin

27 75

Re: [boost] [Boost-users] Boost 1_59_0_b1_rc1 regression in spirit::qi
by Lee Clagett 14 Jul '15

14 Jul '15

On Tue, Jul 14, 2015 at 8:10 AM, Oswin Krause < Oswin.Krause(a)ruhr-uni-bochum.de> wrote: > Hi, > > On 2015-07-14 05:54, Marshall Clow wrote: > >> Release candidate files for 1.59.0 beta 1 are available at >> http://boost.cowic.de/rc/ [1] >> >> 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. >> > > Boost compiles fine, OS Arch Linux, x86_64. > > However, i got a regression in my software using boost::spirit::qi > > See attached the program (i guess it does not qualify minimal, but i do > not have time to trace it further), output of g++/valgrind for boost 1.58 > and for 1.59. There seems to be a signed/unsigned comparison issue and > valgrind detects a conditional jump that depends on unintialized memory. In > my code this showed up as 4 values read from the parsed file have wrong > values albeit the 200 or so other values before and after are fine. > > Best, > Oswin > > I found the issue, and issued a pull request to fix it. Joel let me know if you want a test case; a variable currently unitialized (presumably intentionally) would have to be value-initialized to make it reliably catch this particular case (and then it could suppress errors if the float is `0`). Lee

1 0

Boost.DLL Review is finished
by Vladimir Prus 14 Jul '15

14 Jul '15

Boosters, the formal review of the Boost.DLL library by Antony Polukhin is now finished. The preliminary results are as follows: The following people have provided reviews: - Ralf Globisch - Yes - Klaim - Joël Lamotte - Yes (*) - Niall Douglas - Yes, conditionally - John P Fletcher - Yes - Bjorn Reese - Yes - Edward Diener - Yes Klaim - Joël has asked that his vote is not counted until he's done trying the library for real, and there was no confirmation it's done yet. The following people have contributed, but did not provide a review - Rodrigo Madera - Thomas Trummer - Rob Stewart - Ion Gaztañaga If anybody would like to amend or clarify anything, or plans to provide additional comments during this week, please contact me off-list. I will post final review result after that. Thanks, Volodya

2 1

Boost.DLL formal review
by Vladimir Prus 14 Jul '15

14 Jul '15

The formal review of Boost.DLL library by Antony Polukhin starts today. Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library provides a portable across platforms way to: - load libraries at runtime - import and export any native functions and variables - make alias names for C++ mangled functions and symbols - query libraries/objects and executables for sections and exported symbols - self loading and self querying - getting program and module location by exported symbol The documentation can be found at: http://apolukhin.github.io/Boost.DLL/index.html and the source can be obtained at: https://github.com/apolukhin/Boost.DLL Please post your reviews on the mailing list and if possible, answer the following questions: - Should the library be accepted? - How useful is it? - What's your evaluation of - Design - Implementation - Documentations - Tests - How much effort did you put into your evaluation? - Did you attempt to use the library? On what systems and compilers? This formal review has a couple of adjustments in place: - It will run for two calendar weeks, not for 10 days, as a number of people said 10 days is too little. That said, please try to submit a review during first week, so that necessary discussion can happen conveniently. - The documentation site has Google Analytics enabled, which will allow us to see which pages and navigation paths are most useful for reviewers. No personally identifiable information will be collected. I will post the data after the review is over. Thanks, Volodya

4 6

[1.59] [locale] Merge PR to fix build failures
by Andrey Semashev 13 Jul '15

13 Jul '15

Hi, I've created this pull request [1] a while ago, but it's still not merged. The PR fixes compilation on MSVC and GCC (Ubuntu) and IMO is essential for 1.59. Could someone take a look and merge it? [1] https://github.com/boostorg/locale/pull/9

1 1

[threads] Problem with lambda and tls
by Fu ji 13 Jul '15

13 Jul '15

Hello, I have a problem when I use lambda in lambda and I want to obtain thread local storage. Here is simple example: auto late_connect = wakeup_signal_notify_to_connect.connect([this](){ auto* alias_to_this = this; this->OnInvokeUpdate(); //here I can obtain thread local storage from boost auto wakeup = wakeup_signal_ptr->connect([alias_to_this]() { alias_to_this->OnInvokeUpdate(); //here I cannot obtain thread local storage from boost } });}); Between first and second of invoke OnInvokeUpdate function there was no destructor call. Someone have idei why ? If I don't use alias for this in capture list there is the same effet. Best regards

2 2

[Boost-announce] [review] Metaparse Review Result
by Christophe Henry 13 Jul '15

13 Jul '15

Hi all, First of all, the final result. Metaparse is formally unconditionally accepted into Boost. We had 11 reviews, all "Yes" votes. 2 "No" reviews based on formality were later reversed to a "Yes". The review was lively, with a general agreement that the library is very useful, the design of high quality and the documentation great. Here are some noticeable quotes which helped me take my decision: - "thank you Abel for submitting such an amazing library. The quality of the documentation and code is wonderful and it has been a pleasure to review Metaparse." (Michael Caisse) - (Design) "Of high quality. Based on the MPL paradigm, but I don't view this as a problem." (Peter Dimov) - "Part of the role of boost is to push compilers to the limit (and sometimes beyond). This library certainly has the capabilities to do so." (Roland Bock) Worth noticing is the review of Gordon Woodhull. I myself wrote a new front-end for MSM using Metaparse, and other use cases were very welcome and Gordon managed to produce one for his compile-time graph library by the end of the review, which I found impressive (for both the reviewer and the library). Thank you for investing time in this review. Another important factor for me for acceptance is how well the author is going to maintain his library. We have too many abandoned libraries. Abel went out of his way to oblige remarks and demands made by reviewers. Long before the reviews he also had obliged my many critics and demands. He also showed himself open for experiments. All this while keeping a very calm and professional tone. This is for me a very good sign of a library which will be well-maintained. Finally, there were some repeated important comments which I see as adressed to the rest of Boost that the library is targeted towards library writers. >From Peter Dimov: > - Are you knowledgeable about the problem domain? "I'm not sure if anybody is. :-)" It all depends on us, library and potential library writers to become knowledgeable about this domain and make this library move from potentially useful to very useful. We need to use it to write more cool libraries. I notice a recurring theme where Boost would be dead or on the way to doom etc etc. Some very popular Boost libraries are now part of the Standard, and so what? We need to make new ones. Metaparse is one of them. Let's build more, using it! Yes Reviews(11): Andrzej Krzemienski Bjorn Reese Gordon Woodhull Lee Clagett Louis Dionne Michael Caisse Paul A. Bristow Peter Dimov Roland Bock Edward Diener Niall Douglas I want to thank all the reviewers who invested their time in this review and those who provided some usefuls comments. I also want to thank Abel for presenting this great library. Christophe Henry Metaparse Review Manager

3 2

Re: [boost] [Boost-users] Boost.DLL formal review is ending soon - submit your reviews
by Klaim - Joël Lamotte 12 Jul '15

12 Jul '15

On 12 July 2015 at 21:24, Edward Diener <eldiener(a)tropicsoft.com> wrote: > The name of the library seems Windows specific, since DLL is the term that > Windows uses for shared libraries. Would not Boost DLM ( for dynamic > loadable modules ) or Boost Loadable Library be clearer ? If I remember correctly, there was a long discussion about the naming of the library before the majority seemed ok with DLL because it's explicitely only about loading libraries, not "modules"(which is misleading) nor "plugins" (which would require a lot more features). The name, if my memory is correct, was not particularly thought to be about the Windows context. Other libraries also already took the other names like Boost.SharedObject so it was not an option.

1 0

[msm][eUML2][metaparse] Compile time
by Christophe Henry 12 Jul '15

12 Jul '15

Michael Caisse wrote: >> >> Boost.Msm v3 also implements a new compile-time strings based front-end >> called eUML2 to demonstrate the power of the library and the conciseness >> and expressiveness it allows. >> Please have a look at the documentation: >> >> https://htmlpreview.github.io/?https://raw.githubusercontent.com/boostorg/m… >> >> > >Christophe, this is wonderful work and a great example of the usefulness >of Metaparse. Can you comment on the compile time compared to eUML? Hi Michael, sorry, I had completely forgotten this post and saw it while preparing the review results (which will be done soon). Please allow me to answer this question, with my apologies. I added in the msm3 branch a CompareFrontEnds.cpp example. It is a simple fsm with 12 transitions. I tried with gcc-4.9 and clang-3.5, using -O2 on a i7-5960X processor, suse linux 13.2. Here are the results. eUML clang 4s g++ 5s eUML2 clang 9s g++ 14s Clang is clearly much faster than g++, with about 0.5s added compile-time per transition. With g++ it does not look so good. I already noticed that compile times of most production code at work with g++ is much higher than with clang. Regards, Christophe

2 1

[Better Enums] Maps between enums and other types
by Anton Bachin 12 Jul '15

12 Jul '15

Hello, In past exchanges on this list, several people expressed a desire for bidirectional maps on enums. I've made a simple implementation [1] that relies on constexpr functions containing a switch. The switch forces case exhaustiveness checking. This method therefore requires C++14 to be truly useful. Usage is: ENUM(Channel, int, Red, Green, Blue) constexpr const char* describe(Channel channel) { switch(channel) { case Channel::Red: return "the red channel"; case Channel::Green: return "the green channel"; case Channel::Blue: return "the blue channel"; } } constexpr auto descriptions = better_enums::make_map(describe); int main() { std::cout << descriptions.from_enum(Channel::Red) << std::endl; std::cout << descriptions.to_enum("the green channel") << std::endl; } This prints the red channel Green In principle, make_map should enumerate the function by passing every possible value of Channel, and use the results to build up some lookup data structure. I am not doing that right now because I haven't found a compile-time data structure with fast enough generation to be practical. I suppose with reflective information, there are other ways to check for exhaustiveness besides using a switch. The implementation is currently inefficient (it uses a linear scan to do the reverse mapping). There is also no support for multimaps or partial maps. I could probably support the latter easily by having the function return an option type. I am not sure multimaps are a good idea at all. The only point of them would be to do a reverse mapping from multiple values to the same enum. Interested to hear any opinions. Anton [1] http://aantron.github.io/better-enums/tutorial/Maps.html

1 0

Another Problem (was RE: [type_traits] Another big update in develop)
by Fletcher, John P 11 Jul '15

11 Jul '15

A recent change on develop is breaking something in boost function: _In file included from ../../../boost/function/function_base.hpp:22:0, from ../../../boost/function/detail/prologue.hpp:17, from ../../../boost/function.hpp:24, from ../../../boost/thread/future.hpp:52, from ../../../libs/thread/src/pthread/thread.cpp:19: ../../../boost/type_traits/has_trivial_copy.hpp:47:47: error: template argument 1 is invalid This was not there yesterday. John Fletcher

3 6

Boost.Hana
by Glen Fernandes 11 Jul '15

11 Jul '15

Dear Ron, Louis, and Boost developers, The review period for Hana has concluded. 18 reviews were submitted: - 17 votes for acceptance. (1 of these was conditional upon Hana wholly supporting a second C++ implementation however). - 1 vote for rejection; for lack of compiler support. I submit that Hana be accepted into Boost. I want to congratulate Louis: the Boost community wants Hana to become an official Boost library. Thank you again, Louis, for your work on Hana and for contributing it to Boost. I propose we require, prior to Hana's inclusion in a Boost release, only that: 1. Hana's unit tests to be integrated into Boost's regression tests. If this requires maintaining both CMakeLists.txt and .b2 files, it is still worth it. I am willing to assist with this effort (and the invitation extends to anyone in the community to also contribute to the task). For release managers, potential Hana contributors, or just the general developer community in Boost, to see Hana's test cases in http://boost.org/development/tests/master/developer/summary.html will be useful. I trust, but do not mandate before Hana is officially accepted into Boost, that: 1. All GitHub issues pertaining to implementation and documentation that were opened by Louis in response to review feedback (or by others, such as Vincente, that were approved by Louis) will be addressed eventually (as long as they remain relevant). I personally would ask for, but do not require for Hana's acceptance, that: 1. That Hana's non-reference documentation live outside of the source code. The presentation of Hana's documentation is great; it looks modern, is easy to browse. I am not a fan of the prose living inside hana.hpp though (API reference documentation is the only exception). 2. Louis to investigate further the possibility of a Hana core library if such can be achieved with zero overhead (instead of focusing that effort onto a separate library that provides only a subset of Hana's functionality). On the note of Hana's current support in existing C++ implementations: - While Hana is wholly only supported by clang at present, gcc is not far behind. Given the trend of language conformance, it is reasonable to expect Hana will be entirely supported in a future gcc release. - Hana targets the C++ standard (i.e. This isn't a case of targeting any compiler-vendor specific extensions) and any highly-contentious C++ language features within (e.g. This isn't something like a pre-C++11 library that uses 'export' that only builds with an EDG compiler). - The community now has expressed sufficient interest in both kinds of libraries being part of Boost: Highly portable libraries that target implementation-specific features, and maintain compatibility with even legacy compilers; standard conforming, modern, libraries that are free of the maintenance debt of ancient compiler support. - We need more libraries taking advantage of C++14 language features to drive vendor conformance. A standard may only be as potent as the C++ implementations that support support it, but when one (such as clang does) does, others will be more driven to follow suit when real (and highly desired) projects take advantage of it. My thanks to everyone that participated in Hana's review with a review (Edouard, John Fletcher, John Bytheway, Niall, Krzysztof, Manuel, Roland, Christophe, David Stone, David Sankel, Lorenzo, John, Paul, Zach, Kohei, Charley, Vincente, Abel) as well as discussion and bug reports. Best, Glen

7 9

[BestPracticeHandbook] Run this code online
by Krzysztof Jusiak 11 Jul '15

11 Jul '15

Hi, I've recently added a new functionality to proposed boost.di library documentation. After `try it online` the natural next step was to add `run this code` functionality like in http://en.cppreference.com/w/ or http://www.rust-lang.org/ programming language. Powered by Wandbox and CodeMirror approach, let you play with the particular example and switch between normal quick book programming listing mode and the editor/compiler mode. You can check it here: http://krzysztof-jusiak.github.io/di/cpp14/boost/libs/di/doc/html/di/exampl… Just click on `Run this code` button and you will be switched to the editor mode, where you would be able to edit the code and compile it online using the newest version of the library. Implementation details: https://github.com/krzysztof-jusiak/di/blob/cpp14/doc/js/run_this_code.js It's basically the same solution as `try it online`, just implemented in js instead. Additionally, it also takes the newest version of the library from github. Minimal html: <link rel="stylesheet" href="CodeMirror/lib/codemirror.css"> <link rel="stylesheet" href="CodeMirror/theme/zenburn.css"> <script src="CodeMirror/lib/codemirror.js"></script> <script src="CodeMirror/mode/clike/clike.js"></script> <script src="CodeMirror/addon/selection/active-line.js"></script> <script src="run_this_code.js"></script> <button class="TryItBtn" id="run_it_btn" onclick="show(' https://raw.githubusercontent.com/krzysztof-jusiak/di/cpp14/examples/hello_…)">Run this code!<\/button> <textarea style="display: none" id="code"></textarea> <textarea style="display: none" id="output"></textarea> <div id="code_listing"> //quick book programming listing here or anything else, which should be hidden when editor mode is enabled </div> Let me know, what do you think. Cheers, Kris

3 2

Using clang on Windows with mingw-64
by Edward Diener 11 Jul '15

11 Jul '15

This is just a heads up about testing with clang on Windows. The latest clang, when built from the latest source, is now capable on Windows of using the mingw-64/gcc RTL. Furthermore it is no longer necessary to have the mingw/mingw-64 implementation hardcoded or linked from c:\mingw. With the latest clang the executable will look for a mingw/mingw-64 implementation on the PATH, meaning that the if the implementation's 'bin' directory is on the PATH clang will find it and use its RTL. The ability of the latest clang to use mingw-64 means that clang can use the latest gcc-5.1 RTL on Windows. The mingw-64 implementation offers more up to date and better implementations of gcc than mingw. There is one "gotcha" I have found with this setup on Windows when using clang on Windows with gcc-4.9 on up. The gcc intrin.h implementation of mingw-64 for gcc-4.9 on up has a bug where if the gcc version is less than 4.9 a compiler error will occur. I have reported this to mingw-64 on their developer's mailing list but it has been ignored. Unfortunately clang still sets itself to gcc version 4.2.1. But a workaround solves the problem and that workaround is that when using clang you define '__MINGW_FORCE_SYS_INTRINS', which causes the bug in the mingw-64 intrin.h header file to not trigger. Previous versions of clang on Windows ( 3.4, 3.5, 3.6 ) of course still have the limitation of only working with mingw and needing the mingw implementation hardcoded at c:\mingw. But at least with the latest clang built from source this has changed as explained above. The Boost build clang toolset, which on Windows is really clang-linux, should continue to work with this latest change of clang.

2 2

[1.59] Boost 1.59 schedule?
by Joaquin M López Muñoz 09 Jul '15

09 Jul '15

Hi, The official release schedule at http://www.boost.org/development/index.html seems to indicate we're now really close to the first beta of Boost 1.59, yet I don't see much activity in the mailing list and, for instance, the release notes are almost empty now: https://github.com/boostorg/website/blob/master/feed/history/boost_1_59_0.q… Is this schedule still valid? Thank you, Joaquín M López Muñoz Telefónica

6 7

Problem cross-compiling boost.context for Raspberry Pi (2)
by Biddiscombe, John A. 09 Jul '15

09 Jul '15

Hello list, I am able to compile the full set of boost libraries on the Raspberry Pi, and I get all the libraries successfully built, including context and coroutine which I need. However, when I cross compile on an Ubuntu virtual machine setup for the job, all the libraries except context/coroutine are built. The problem seems to be that when cross compiling, the file "unsupported.cpp" is being pulled in (here is a verbose output showing flag I'm using) "/home/biddisco/pi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -D__arm__ -std=c++11 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_CONTEXT_SOURCE -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DNDEBUG -I"." -c -o "bin.v2/libs/context/build/gcc-arm/release/threading-multi/unsupported.o" "libs/context/src/unsupported.cpp" which emanates from the jamfile boost_1_58_0/libs/context/build/Jamfile.v2 where the following alias asm_context_sources : unsupported.cpp ; is in a section marked #COMBINED Now, when I build on the pi itself, this file is not being added to the build, so it seems to me that during the bootstrap phase on the pi, different flags are being used which trigger the correct behaviour of bjam my user-config.jam looks like this using gcc : : /home/biddisco/pi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++ : <compile-flags>-D__arm__ -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard ; (NB. I added -D__arm__ to see if it helps, but it does not make a difference without it). I have no knowledge of how bjam / boost.build do their things, so I do not know what to try next. It seems that I need to bootstrap the build using the flags for the pi, but built for the host so that it can generate the correct makefiles and this looks like where the problem is arising. the build process seems good apart from this wrinkle The bootstrap command I'm using is ./bootstrap.sh --with-toolset=gcc and the build appears sensible when I use ./b2 cxxflags="-D__arm__ -std=c++11 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" --layout=versioned threading=multi link=shared variant=release -j8 Performing configuration checks - 32-bit : yes - arm : yes .... etc etc Can anyone see what I'm doing wrong? (Note : With another project which depends on libpthread, I had to copy libpthread from the pi to the host and force the linker to use the pthread lib from the pi and not the host one, does bjam do something internally which might require a trick like this? - note2 - the binaries generated via this process run without error) Many thanks JB -- John Biddiscombe, email:biddisco @.at.@ cscs.ch http://www.cscs.ch/ CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 Via Trevano 131, 6900 Lugano, Switzerland | Fax: +41 (91) 610.82.82

4 17

Json read...segment by segment
by vijay.singh＠edisphere.com 07 Jul '15

07 Jul '15

Hi, I am using below code to read load Json file in boost::property_tree::ptree object. Function read_json(.) read all file content at a time. I want to know is there any way to read file content segment by segment. Thanks and regards, Vijay int _tmai3n(int argc, _TCHAR* argv[]) { try { std::stringstream ss; std::ifstream file("D:\\EdisphereComp\\kit\\1003_Kit\\1003\\Inputfiles\\AI98_Test_3.json", std::ios::binary); // Make sure we have something to read. if (!file.is_open()) { throw (std::exception("Could not open file.")); } // Copy contents "as efficiently as possible". ss << file.rdbuf(); boost::property_tree::ptree pt; boost::property_tree::read_json(ss, pt); boost::property_tree::write_json("D:\\EdisphereComp\\kit\\1003_Kit\\1003\\In putfiles\\AI98_Test_3_sprite.json", pt); } catch (boost::property_tree::json_parser_error e) { ; } //} return 0; }

4 7

Boost.Test v3 is in master
by Gennadiy Rozental 07 Jul '15

07 Jul '15

Hi, I've merged new Boost.Test into the master branch. We'll look for any regressions, but I do not expect big changes before release. Gennadiy

2 1

[test] Bug in Mingw support?
by John Maddock 07 Jul '15

07 Jul '15

The short program below passes with MSVC and GCC Linux, but fails with Mingw-x64 at runtime (the expected failures count gets ignored). This is with current develop. Any ideas? BTW the new decorator based approach does work OK, but is only supported on a tiny number of compilers as it seems to rely on the preprocessor lib using variadic macros, as opposed to Boost.Config marking them as available. Here's the program: #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES(test_main, 10000); BOOST_AUTO_TEST_CASE(test_main) { BOOST_ERROR("one"); BOOST_ERROR("two"); } Thanks, John.

3 7

Boost Graph maintenance
by Oodini 07 Jul '15

07 Jul '15

Hello, I've been working on BGL for several days, and I'll probably have to work on it for a long time. The documentation is not very clear (I suspect it is outdated on some points), and as it doesn't seem complete. Also, the official maintener, Jeremiah Willcock, hasn't commited since the end of 2013. I'd like to work on the documentation, in the first time on the organization and presentation. If I amend the text later, I will need a reviewer (my english is not good enough). What would be the process ? I havn't participated to any Boost library.

5 5

Boost.Experimental Re: [variant] Maintainer
by Gottlob Frege 07 Jul '15

07 Jul '15

On Sun, Jun 28, 2015 at 10:29 AM, Agustín K-ballo Bergé <kaballo86(a)hotmail.com> wrote: > On 6/28/2015 5:38 AM, Vicente J. Botet Escriba wrote: >> >> Le 27/06/15 21:32, Agustín K-ballo Bergé a écrit : >>> >>> On 6/27/2015 12:38 PM, Vicente J. Botet Escriba wrote: >>>> >>>> I would accept Eggs.Variant without even a review (or with a minimal >>>> review) as an experimental library as part of Boost.Variant after some >>>> minimal adaptation to fit in Boost of course. >>> >>> First of, as I have already said before, Eggs.Variant is an >>> experiment. As such it is highly unstable, and I reserve the right to >>> change things in any way I see fit, with no regards for backwards >>> compatibility, maintenance, or support. I have made these kinds of >>> changes in the past, and I have more planned for the near future. I >>> think it would be unwise to make it a part of Boost, even as an >>> experimental library, until the design has fully hatched ("Eggs", get >>> it?). >> >> Agustin, this is exactly the kind of constraints of an experimental >> library. When the design is fully hatched then it moves to non >> experimental. > > > I fail to see the point in including an experimental library that changes > its interface every month into Boost, which is released every 3 months or > so. By the time you get your hands in a release, the interface of the > library has already changed. And the library as such would only exist for a > single release. > > Who would benefit from Boost packaging old snapshots of experimental > libraries? > > Perhaps you'd wish to bring back the Sandbox > (http://www.boost.org/community/sandbox.html) which has been superseded by > standalone repositories since the move to Git. > I think we need *something* for experimental libraries. Even if it is just someone's own git repository stamped (but not endorsed) with the Boost "brand". Or a page in boost.org listing current experiments. Or... something. There are (at least) 2 needs that Boost tackles: 1. great libraries that solve problems for developers 2. great libraries that can turn into std:: libraries I think we are doing better on 1 than 2. I think 2 requires more experimentation (whereas 1 requires more stability). Yes I know 2 looks successful - just look at how much of boost is in C++11. But when each Boost library is brought to the committee, we have 2 choices: - make design changes before going into std - take as is Making design choices in a committee (and without experimenting) is not always a good idea. We are, in theory at least, suppose to standardize existing behaviour. Taking as is means we are accepting whatever was good enough to pass Boost review as *best*. Boost review is a high bar, but the std:: should be higher. It is common for the committee to hear/say "boost users have been using it this way for years". That is usually a good strong argument - we want/need implementation and usage experience. But saying "this works" doesn't mean something else could work better. Implementation/usage experience is most accurate when it says "this does NOT work", because then you have ruled out an option. When you say "this works", it doesn't rule out options that might work _better_. We are increasingly going with option 3: - put into std::experimental which delays the desired outcome of getting great libraries into the standard. I'd like some kind of experimental area that would help find the best possible libraries. What I'd _really_ like is more experimentation in _current_ Boost libraries, breaking users left and right - I'd rather break boost users than std:: users. (We have and will make breaking changes in the standard library). But I understand that current users wouldn't be too happy about breaking changes _just for experimentation's sake_. And if we lost the boost user base, boost would no longer be helpful to the standard at all. (As a reasonable example of not being afraid of breaking changes: Sean Parent's Adobe Standard Library would boldly break whenever he thought something could be made better. It didn't break just for experimenting, but he wasn't afraid to make breaking changes for the better.)

6 11

[predef] Using predef-check on 'develop' problem
by Edward Diener 06 Jul '15

06 Jul '15

In a jam file I have for a run test a predef-check which looks like: run test_variadic_macro.cpp : : : [ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ] ; When running on QNX with the gcc version greater than 4.3 I would expect that -std=c++0x would not be added as a C++ compile parameter to the run. Yet it is being added to the run. Another test confirms that BOOST_OS_QNX is indeed being set to a non-zero value. Is there a bug in predef-check ? Am I using it incorrectly ?

4 45

Testing InputIterator on the interface
by Benedek Thaler 05 Jul '15

05 Jul '15

Hi, I'd like to verify my methods accepting an input range (two iterators modelling InputIterator) do a single pass over the range at most. I'd like to have an iterator adaptor, which erases the visited element upon incrementing. So far, I found these: 1) https://github.com/boostorg/test/blob/master/include/boost/test/utils/itera… I couldn't find its documentation, and does not seem to what I want. 2) https://github.com/boostorg/container/blob/master/test/input_from_forward_i… Despite the name, still not something I want. I'm developing a Boost.Container class [0], so using container/test would be okay. Is there such a thing ready somewhere or shall I roll my own? Thanks, Benedek [0]: https://github.com/erenon/container/blob/devector/include/boost/container/d…

2 3

Re: [boost] [Boost-users] Boost.DLL formal review is ongoing
by Klaim - Joël Lamotte 04 Jul '15

04 Jul '15

On 4 July 2015 at 11:38, Antony Polukhin <antoshkka(a)gmail.com> wrote: > 2015-07-04 0:16 GMT+03:00 Klaim - Joël Lamotte <mjklaim(a)gmail.com>: >> >> >> On 3 July 2015 at 15:50, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: >>> >>> - What's your evaluation of >>> - Design >>> >> >> I consider the solutions provided to solve each usual issue with plugin >> systems to be simple >> and clear, easy to use (as long as you understand what loading plugins >> imply). >> >> Until I check in some complex cases, I think the design is very good. >> The symbol name magic might be tricky to understand sometime but it's an >> issue which is a side effect of providing >> a simple tool to manage symbole names, so it's still good. >> >> One thing I was wondering: would it be possible to provide a way to load >> shared libraries from >> raw memory? Or does the OS APIs all requires that the library have to be >> on a file sytem? >> > > Unfortunately, there's no portable way to load libraries from raw memory. > However you can always mount a filesystem that directly maps to memory (for > example Tmpfs on Linux) and store your data in there. This may look like a > big performance overhead, but actually loading a shared library takes much > time so you won't probably notice the overhead of additional create_file + > memcpy. > It's ok, the solution to write a shared library in the the filesystem before loading it is what Ihave been doing so far and it works well. I was just wondering if it was possible with memory. :) If the plugin is in an archive file, I have to extract it in a temporary directory before loading it, which is what I would like to avoid, but it seems unavoidable. > > If you're planing this feature to write interpreters\JIT compillers and > you just need a place to store end execute generated native code, then > Boost.Interprocess's memory mapped files fill probably suit you better. > Shared libraries contain a lot of headers, helper data for load and a bunch > of other stuff that would be really hard to generate. > I don't write an interpreter (I'm really just managing plugins) but I didn't know that, it seems useful in some other contexts. Thanks for the pointer.

1 0

Fwd: [Boost-users] Boost.DLL formal review is ongoing
by Antony Polukhin 04 Jul '15

04 Jul '15

2015-07-04 0:16 GMT+03:00 Klaim - Joël Lamotte <mjklaim(a)gmail.com>: > > > On 3 July 2015 at 15:50, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: >> >> - What's your evaluation of >> - Design >> > > I consider the solutions provided to solve each usual issue with plugin > systems to be simple > and clear, easy to use (as long as you understand what loading plugins > imply). > > Until I check in some complex cases, I think the design is very good. > The symbol name magic might be tricky to understand sometime but it's an > issue which is a side effect of providing > a simple tool to manage symbole names, so it's still good. > > One thing I was wondering: would it be possible to provide a way to load > shared libraries from > raw memory? Or does the OS APIs all requires that the library have to be > on a file sytem? > Unfortunately, there's no portable way to load libraries from raw memory. However you can always mount a filesystem that directly maps to memory (for example Tmpfs on Linux) and store your data in there. This may look like a big performance overhead, but actually loading a shared library takes much time so you won't probably notice the overhead of additional create_file + memcpy. If you're planing this feature to write interpreters\JIT compillers and you just need a place to store end execute generated native code, then Boost.Interprocess's memory mapped files fill probably suit you better. Shared libraries contain a lot of headers, helper data for load and a bunch of other stuff that would be really hard to generate. -- Best regards, Antony Polukhin

1 0

[next gen futures] Lightweight monad ready for inspection
by Niall Douglas 03 Jul '15

03 Jul '15

Some may remember the thread starting from http://boost.2283326.n4.nabble.com/next-gen-future-promise-What-to-cal l-the-monadic-return-type-td4676039.html and that I would firstly prepare an optimally lightweight monad<T> for review here before going on to base a next-gen lightweight future-promise on that monad<T>. I didn't expect it would take nearly four weeks to get there, but writing STL quality C++ with full conformance test suite is amazingly labourious. Anyway you can now view the design and tell me what you think. A quick overview of the design: This monad can hold a fixed variant list of empty, a type R, a lightweight error_type or a heavier exception_type at a space cost of max(20, sizeof(R)+4). Features: * Very lightweight on build times and run times up to the point of zero execution cost and just a four byte space overhead. Requires min clang 3.2, GCC 4.7 or VS2015. A quick sample of runtime overhead, min to max opcodes generated by GCC 5.1: 1 opcodes <= Value transport <= 113 opcodes 8 opcodes <= Error transport <= 119 opcodes 22 opcodes <= Exception transport <= 214 opcodes 4 opcodes <= then() <= 154 opcodes 5 opcodes <= bind() <= 44 opcodes * Just enough monad, nothing more, nothing fancy. Replicates the future API with a fair chunk of the Expected<T> API, so if you know how to use a future you already know how to use this. * Enables convenient all-noexcept mathematically verifiable close semantic design, so why bother with Rust anymore? :) * Can replace most uses of optional<T>. * Deep integration with lightweight future-promise (i.e. async monadic programming) also in this library. * Comprehensive unit testing and validation suite. * Mirrors noexcept of type R. * Type R can have no default constructor, move nor copy. * Works inside a STL container, and type R can be a STL container. * No comparison operations nor hashing is provided, deliberately to keep things simple. Documentation page: https://ci.nedprod.com/view/Boost%20Thread-Expected-Permit/job/Boost.S pinlock%20Test%20Linux%20GCC%204.8/doxygen/classboost_1_1spinlock_1_1l ightweight__futures_1_1monad.html Source code: https://github.com/ned14/boost.spinlock/blob/master/include/boost/spin lock/monad.hpp Online wandbox compiler: http://melpon.org/wandbox/permlink/cnZM5KRNpjErXrPH Any opinions or thoughts gratefully received, particularly if I have the exception safety semantics right (i.e. a throw during move or copy leaves the monad empty). Do you also like the polymorphic bind() and map() which does different things depending on the parameter type your callable takes? Do you like that by simply changing the callable's type to a rvalue reference you can move state, or is this being too clever? This monad will become the basis of lightweight future-promise which is essentially a "split monad" with the setter interface and getter interface potentially in different system threads. The then(), bind() and map() work as here but only are triggered at the point of the value being changed. This effectively makes the lightweight future a "lazy continued monad". That lightweight future-promise will then enter AFIO to replace its async_io_op type hopefully in time for the peer review this time next month. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 42

Re: [boost] Boost.DLL formal review is ongoing
by Ralf Globisch 03 Jul '15

03 Jul '15

Hi, Firstly, thanks Anthony for submitting this useful library to boost, and to Vladimir for managing the review. - Should the library be accepted? Yes. I had been meaning to test the library for some time, and with the review reminder finally made some time to do so. My vote of yes is based on my (limited) positive experience with the library, as well as having followed past related discussions on the mailing list, in which many questions are addressed. (http://lists.boost.org/Archives/boost/2014/09/216650.php) I think boost.DLL should be accepted unless someone has a serious/valid reservation as to why this library should not to be accepted. - How useful is it? Very useful. It enabled me to add a test-plugin mechanism to an existing application (Windows and Linux) in a matter of minutes. - What's your evaluation of - Design Looks good to me. Simple to use, with good integration into rest of boost (e.g. file_system). I like the fact that the library is header only and minimal effort was required to integrate plug-in like functionality into an existing application. - Implementation I'm not knowledgeable enough to comment on this. - Documentations Good, the tutorials made it fairly easy to get going and covered my common usage scenarios Code is well commented. - How much effort did you put into your evaluation? About three hours worth of effort, reading through documentation and source code, and using library to create a very simple plug-in mechanism in an existing application. Tested basic plug-in functionality on Windows and Linux. - Did you attempt to use the library? On what systems and compilers? Yes -Linux Ubuntu 14.10 with gcc 4.9.1 with boost 1.57 -Window 7 64-bit with VS 2013 community edition with boost 1.58. Initially made the mistake of not checking the boost version (which had been 1.53 and caused lots of compilation errors.) Minor typo in documentation: Just above the "Full Sources" for tutorial 4 "If we want o make a traditional" should be "If we want to make a traditional" Regards, Ralf >>> Vladimir Prus <vladimir.prus(a)gmail.com> 07/03/15 3:52 PM >>> The formal review of Boost.DLL library by Antony Polukhin is nearing the end of the first week. As of today, over 100 people read through the library's tutorial, suggesting quite some interest. However, no reviews were submitted yet. Please take the time to post your thoughts - even if you don't have time to do a full review, or try the library, comments on design and interfaces are still very valuable. The summary of the library features and review checklists are reproduced below. Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library provides a portable across platforms way to: - load libraries at runtime - import and export any native functions and variables - make alias names for C++ mangled functions and symbols - query libraries/objects and executables for sections and exported symbols - self loading and self querying - getting program and module location by exported symbol The documentation can be found at: http://apolukhin.github.io/Boost.DLL/index.html and the source can be obtained at: https://github.com/apolukhin/Boost.DLL Please post your reviews on the mailing list and if possible, answer the following questions: - Should the library be accepted? - How useful is it? - What's your evaluation of - Design - Implementation - Documentations - Tests - How much effort did you put into your evaluation? - Did you attempt to use the library? On what systems and compilers? Thanks, Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email.

1 0

Metaprogramming: parameter pack expansion/evaluation trick
by Antony Polukhin 03 Jul '15

03 Jul '15

Hi, Straight to the problem. Consider the situation, were a function accepts parameter pack and something need to be done with each argument (for example, we want to print each argument on a new line): template <typename... Args> void print(Args&&... a) { // print each a on a separate line } There's a known trick to do that: template <typename... Args> void print(Args&&... a) { (void) (int []){ 0, (std::cout << a << std::endl, 0)... }; } But the syntax is not very readable (and I always forget it and search for an example in Internet). I've tried to improve the syntax, and here's the result: template<typename... Args> void print(Args&&... a) { expand_if<Args...> { std::cout << a << '\n'... }; } Compete source could be found here: http://coliru.stacked-crooked.com/view?id=c2c59f22574671e5 Here's some more usage examples: template<typename... Args> void printer_int(Args&&... args) { expand { std::cout << std::abs(args) << std::endl..., std::cout << "Printing once again all the numbers: " << std::endl, std::cout << " Once again " << std::abs(args) << std::endl..., std::cout << "EOF Printing once again all the numbers." << std::endl }; } template<typename... Args> float sum(Args&&... args) { float res = 0; expand_if<Args...> { res += args... }; return res; } I hope this would be helpful for someone or it could be used as an argument for a proposal to extend C++ and allow simpler syntax: template<typename... Args> void print(Args&&... a) { std::cout << a << '\n'...; } P.S.: There was a nicer solution that newer required "_if<Args..>" : namespace detail { struct expand_impl final { template <class... Arg> constexpr inline expand_impl(Arg&&...) noexcept {} }; } template <class... Arg> using expand = detail::expand_impl; But unfortunately there's no way to force the compiler to evaluate expressions in constructor call from left to right. So it did not work on GCC (but work on Clang). -- Best regards, Antony Polukhin

4 4

[math][website] SVG graphics all missing?
by John Maddock 03 Jul '15

03 Jul '15

It looks like all the SVG graphics used by the Boost.Math docs are missing from the website - is this a release SNAFU? Thanks, John.

1 1

[winapi] Major changes in develop
by Andrey Semashev 02 Jul '15

02 Jul '15

Hi, I've just merged a largely reworked version of Boost.WinAPI to develop. It fixes a few bugs and also changes the implementation for better conformance with the C++ standard. Hopefully, it should fix compilation issues with clang on Windows. Another significant change is that Boost.WinAPI targets Windows Vista and later by default. As before, it is possible to explicitly select another version to target by defining BOOST_USE_WINAPI_VERSION. For example, to build Boost for Windows XP one would invoke: b2 define=BOOST_USE_WINAPI_VERSION=0x0501 If anyone has problems with this change, please let me know.

2 5

[optional] How to use optional to lazy construct obj?
by Mostafa 01 Jul '15

01 Jul '15

I'm interested in doing something along the lines of: lazy_adaptor<obj_type> lz(arg1, arg2, arg3, ...) where then lz.construct() then constructs an object of obj_type with ctor of arguments "arg1, arg2, arg3, ...". So far I have the following: (Am I on the right track?) #include <utility> #include <tuple> #include <string> #include <boost/optional/optional.hpp> template <typename... Args> struct ctor_forwarder; template <typename... Args> ctor_forwarder<Args...> make_ctor_forwarder(Args&&... args) { // Note: The "Args..." template parameter to ctor_forwarder determines how // the caller's arguments are temporarily stored. If it's an rvalue, it's // temporarily stored by value, else it's temporary stored by reference. return ctor_forwarder<Args...>(std::forward<Args>(args)...); } template <typename... Args> struct ctor_forwarder { //TODO: make ctor private. template <typename... A> explicit ctor_forwarder(A&&... args) : m_args( ::std::forward<A>(args)... ) {} /* template <typename Callable> auto forward_to(Callable && caller) -> decltype( caller(::std::forward<Args>(m_args)...) ) { return caller(::std::forward<Args>(m_args)...); } */ template <typename T> void forward_to(::boost::optional<T> & obj) { obj.emplace(::std::forward<Args>(m_args)...); } private: typedef ::std::tuple<Args...> args_t; private: args_t m_args; }; template <typename Obj, typename... Args> struct lazy_adaptor { Obj on_enter() { m_args_forwarder.forward_to(m_obj); } private: ::boost::optional<Obj> m_obj; ctor_forwarder<Args...> m_args_forwarder; }; template <typename Obj, typename... Args> lazy_adaptor<Obj, Args...> make_lazy_adaptor(Args&&... args) { return lazy_adaptor<Obj, Args...>(); } struct Sample1 { Sample1(int num, std::string str) {} }; int main() { auto df = make_ctor_forwarder(10, "Ten"); //ctor_forwarder<int, std::string> df(10, "Ten"); auto lazy_ctor = make_lazy_adaptor<Sample1>(10, "Ten"); return 0; }

1 0

Fwd: [SORT] Parallel Algorithms
by Francisco José Tapia 01 Jul '15

01 Jul '15

Hi Steven I had been revising and testing spreadsort, and the results are impressive. I have prepared the benchmarks and include spreadsort. Now the numbers are extracted from a file generated with a random number generator. In a few days I will put all in a git repository for a easy access As I had seen, you use boost::sort for to invoke to spreadsort. If you use this name, which name use for to invoke introsort? I think a good idea can be call the algorithms by their name. If we do this we have the next algorithm list : - spreadsort - spreadsort_integer - spreadsort_float - spreadsort_string - introsort - parallel_introsort - smart_merge_sort - parallel_stable_sort - sample_sort I think it's a simple and easy to understand, because with the name sort, many people think about an algorithm as introsort ( general , not specific for several data types) and not stable. What's your opinion ?

3 19

[Boost] [Hana] Formal review for Hana (Submissions closed)
by Glen Fernandes 30 Jun '15

30 Jun '15

Dear Boost community, The period for Hana review submissions has ended. The result will be announced on the list during this week. I would like to thank everyone on this list for your submission of a review: - Edouard Alligand - John P. Fletcher - Niall Douglas - Krzysztof Jusiak - Roland Bock - Vicente J. Botet Escriba - David Sankel - Zach Laine - Kohei Takahashi - Charley Bay - Bruno Dutra - Christophe Henry - David Stone - Lorenzo Caminiti - John Bytheway - Manuel Sánchez As well as the following people for your discussion during the review period: - Phil Endecott - Larry Evans - Abel SInkovics - Gavin Lambert - Jeremy Maitin-Shepard - Joel de Guzman - Edward Diener - Paul A. Bristow - Peter Dimov - Bjorn Reese - Paul Fultz II - Lee Clagett Once again, thank you to Louis for all your work on Hana and submitting it for Boost inclusion. Glen

2 1

[Circular Buffer]Could erase_begin run in constant time for trivially destructible objects?
by Pradhan Kumar 30 Jun '15

30 Jun '15

Hello everyone, The implementation of circular_buffer<T>::erase_begin(n) is tag-dispatched on is_scalar<T>, to use a constant time implementation for scalar types. For non-scalar types, it falls back to using rerase(begin(), begin()+n). Could we change this to dispatch on std::is_trivially_destructible? Examining the generated code, I see that the below loop has not been completed optimized out for a POD-type. (I am using Boost 1.58 and gcc4.9.2. The compile option was g++ -O3 -std=c++11 -g -DBOOST_CB_DISABLE_DEBUG -fno-inline to make it easier for me to understand the assembly.) do { destroy_item(m_first); increment(m_first); --m_size; } while(m_first != p); destroy_item is optimized out, as expected. However, increment has a "modulo" check and this prevents the above while loop from getting optimized to one instruction. template <class Pointer> void increment(Pointer& p) const { if (++p == m_end) p = m_buff; } Thoughts? Thanks, Pradhan

1 0

Change to guidelines for characters in C++ source files
by Beman Dawes 29 Jun '15

29 Jun '15

Since the very early days of Boost the guidelines for acceptable characters in C++ source files has been the 96 characters of C++ standard's basic source character set encoded in 7-bit ASCII. The inspect program also allowed several additional 7-bit ASCII characters that sometimes appear in comments. The rationale was to ensure that Boost code was portable to all compilers available at that time. We had gotten complaints that even a character as innocuous as a copyright sign (U+00A9) was causing compiles to fail on some compiler releases targeting Asian languages. UTF-8 support was far from universal. Times have changed: * Source files encoded in UTF-8 with a leading byte order mark (BOM) of the byte sequence 0xEF,0xBB,0xBF are supported by all C++ compilers that we are aware of, and this has been true for many years now. * As of C++11, the C++ language now includes types and literals directly supporting UTF-8, UTF-16, and UTF-32, and creating code points above 7-bit ASCII in such literals is much easier if UTF-8 source encoding is used. Even editors as dumb as Windows Notepad have supported UTF-8 with BOM for some time now. * As Boost Libraries start to incorporate C++11 Unicode related features, it becomes difficult to write test programs if limited to 7-bit ASCII. For example, incorporating the Filesystem TS into Boost.Filesystem requires test cases with UTF-8, UTF-16, and UTF-32 and that's painful under the current 7-bit ASCII guidelines. So... It looks to me like it is high time to change the Boost guideline for C++ source file encoding to 7-bit ASCII without BOM or UTF-8 with BOM, and to change the inspect program accordingly. Comments? --Beman

9 12

[thread] Change broken on Windows
by Edward Diener 29 Jun '15

29 Jun '15

The 8c974800f90dc5f644895f2d7247364710edcf76 change to thread made on June 23 broke its functionality on Windows. The changes to lines 642 and 659 of thread\include\boost\thread\win32\thread_primitives.hpp is obviously wrong. While I can fix locally easily enough this needs to be fixed on 'develop' ASAP.

3 2

merging from develop to master
by Stefan Seefeld 29 Jun '15

29 Jun '15

Hello, I'm trying to compare Boost.Python's develop branch with master, to decide how to proceed. I was naively assuming that develop would regularly be rebased so it's easy to merge patches. However, https://github.com/boostorg/python/branches/active indicates develop is "276 commits ahead". How is that possible ? How did previous maintainers keep the develop branch in sync with master ? How is this handled in other Boost libraries ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

6 6

[Hana] Formal review
by Manu343726 28 Jun '15

28 Jun '15

Here's my formal review of Hana - Whether you believe the library should be accepted into Boost Yes - Your name Manuel Sánchez - Your knowledge of the problem domain. I have been doing TMP side projects as a hobby, including my own tmp library in the same sense of Hana but metafunction based (Like Boost.MPL). - What is your evaluation of the library's: * Design Hana design and wording makes it look more like a Hakell library than a C++ one (All the functional concepts, algorithms etc). I think it's fine since Hana algorithms are about declarative data transformation. C++ needs that change in the way of thinking, but I expect some others (more conservative C++ programmers) to not accept Hana for not being too much "C++ish". About metaprogramming, wrapping types into template variables is a game changer. Some others noticed that doing type and value manipulation with the same code may be confusing since with templates there is a clear line between type manipulation code (templates) and value manipulation code (normal C++). I'm partially agree, but I prefer not to write/maintain two different libraries for exactly the same algorithms. That's the core value of Hana. * Implementation Tmp is usually ugly, but Louis does a great work at making code as clear as possible. Code is well divided and documented. * Documentation The library is documented in depth. I have mainly two issues: More references about basic concepts and navigation. Both are already covered by issues at github, so I will not dive into them here. * Tests Not looked. * Usefulness There are only a few libraries out there that provide this kind of STL-quality set of algorithms. Having those work with types and values worths it. As others said, there's a problem on current compiler support (Only recent versions of Clang). I like the idea of pushing towards compiler vendors, but it's true that since the beginning Boost libraries were designed to work on any C++ platform available. In my opinion, we should give Louis an opportunity, while giving vendors time to update their implementations. - Did you attempt to use the library? If so: * Which compiler(s) clang 3.6.1 * What was the experience? Any problems? I tried some experiments regarding type manipulation. No special issues raised out. It worked as expected. - How much effort did you put into your evaluation of the review? A few hours playing with the lib, plus a couple of hours to write the review. -- View this message in context: http://boost.2283326.n4.nabble.com/Hana-Formal-review-tp4677606.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[hana] Review
by John Bytheway 28 Jun '15

28 Jun '15

This is a somewhat perfunctory review of Hana, because I wanted to get something in before the end of the review period. I have submitted a few issues on GitHub, for minor things that need not be repeated here. Below are the things I found that might warrant more discussion. - Whether you believe the library should be accepted into Boost * Conditions for acceptance Yes it should. No specific conditions. - Your name John Bytheway - Your knowledge of the problem domain. User of TMP for years. Once wrote a source-to-source translator to help me write MPL programs because it was prohibitively difficult to write them correctly by hand. - What is your evaluation of the library's: * Design The design seems reasonable, and I like the adherence to mathematical concepts. The most difficult thing is getting the names right, and I know there's been plenty of debate on that. The name that most concerns me is Range, given that that term is already commonly used in Boost as a concept with a completely different meaning (in the Boost.Range sense). * Implementation Did not look. * Documentation Mostly very good, but of course there is always room for improvement. One particular thing I wanted to raise here is that I struggled to find enough information about Hana-convertibility (i.e. using the 'to' function). For example, I wondered if I could create a Tuple from a Range, and it seems I can. Then I wondered whether I could create a std::Array from a homogeneous Tuple, but it seems I cannot. How should I know these things? (This latter case of converting to an array is something I feel ought to be supported for easing the boundary between runtime and compile-time sequences) * Tests Did not look. * Usefulness Very, although not useful for me personally until I decide to bite the ABI-breaking bullet and recompile all my code in gcc 5.x with the new libstdc++. The biggest risk I see is MSVC support. Microsoft seem to be much more standards-gung-ho than they once were, so I hope it won't take too much longer before we see support. But I do encourage Louis to be wary of taking advantage of any new language features (e.g. a potential change in C++17 lambdas-in-unevaluated-contexts rules, or the compiler extension for compile-time string literals) lest it delay MSVC support. - Did you attempt to use the library? If so: * Which compiler(s) clang 3.6.1 * What was the experience? Any problems? I played around a bit, mostly with a view to finding out how bad the compiler errors are when things go wrong. The results were promising. I went looking for some code of mine to try porting to Hana, and got sidetracked by one difficulty. The first project I came across using Boost.Fusion was passing a lot of fusion::vectors across function interfaces, but the vector types were specific and the functions not defined in headers. Hana's tuple cannot easily be used in this way since the type is unspecified. I don't think this is a problem, because (a) that code was just poorly written and ought instead to be using adapted structs, which Hana does support, and (b) I can use Hana algorithms with Fusion's tuples anyway. - How much effort did you put into your evaluation of the review? A few hours reading and playing. Thanks very much to Louis for his effort. I look forward to being able to use Hana in the not-too-distant future, and I'll make GitHub issues for any more things I discover in my testing. John

3 6

Hana Views and References
by Joel de Guzman 27 Jun '15

27 Jun '15

Hello Louis, Mario Lang, a Spirit developer, played around with Hana and investigated on it's suitability for Spirit. His conclusion is that "Hana is really quite nice!". Then, he adds that: "However, Hana lacks a way to retrieve the members of a struct as references currently, which will pretty much kill a Hana based Spirit effort." So the question is: will Hana support references without resorting to using reference wrappers? I do appreciate the FP nature of Hana, but please be reminded that we're in C++. I also recall some discussion that Hana also does not support Fusion-like lightweight views. Is there a plan to support them? I haven't fully investigated yet what else Hana does not support that Fusion does, but at least these two important aspects of fusion come to mind. At the very least, I don't think Hana should advertize itself as a superset of Boost.Fusion. Faster runtime performance is also questionable, when lightweight views and reference members come into play. Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/

5 9

Re: [boost] [hana] Lorenzo's Formal review for Hana
by Brian Wood 27 Jun '15

27 Jun '15

Louis Dionne writes: > I'm coding against a standard, not a specific compiler. If I introduce > workarounds in Hana, the whole purpose of the library is lost. Performance, > ease of use, and most importantly hackability will be lost. > Hmm. > Quite honestly, I'd rather have my library never get into Boost than > bastardize it so it works on MSVC. If it can be made to work on MSVC > without bastardizing it, however, I'm all for it. I face similar issues and agree with your remarks here. It seems like it's easier to use MSVC and Windows than it used to be, but it's still not easy. I've recently reduced my Windows support and feel a burden lifted. -- Brian Ebenezer Enterprises - "Free at last; free at last. Thank G-d Almighty we are free at last." Martin Luther King Jr. http://webEbenezer.net

3 3

[Boost] [Hana] David Stone's formal review
by David Stone 27 Jun '15

27 Jun '15

- Whether you believe the library should be accepted into Boost Yes - Your name > David Stone > - Your knowledge of the problem domain. > Advanced > - What is your evaluation of the library's: > * Design Good. It seems like most of the library follows the naming conventions of boost and the standard library (identifiers_like_this), but there are a few exceptions. The most notable is boost::hana::IntegralConstant. Why not integral_constant? Aside from minor issues like this, I am a huge fan of the overall idea of making compile-time and run-time code the same. Ideally we would have just a single language in C++ (as opposed to plain C++, template C++, constexpr C++, macro C++, and concept C++) and a single style of programming. The design of this library follows and extends this general trend in C++ that started with constexpr. > * Implementation > Looking through the source, it seems to flow naturally. Most of the code looks essentially the same as I would have written it. It has small, self-contained functions and appropriate use of macros, comments, and static_asserts. It would be nice if your IntegralConstant provided a specialization of std::numeric_limits. This would allow it to work properly with a few libraries (two examples are my bounded::integer library and this fixed point library: https://github.com/mizvekov/fp) You could then detect type-level compile-time constants as being any integer type for which std::numeric_limits<T>::min() == std::numeric_limits<T>::max(), which would allow the interoperability to flow the other way, but I do not know if the library ever requires this information or if it just relies on the compiler to complain about things that are not constexpr. > * Documentation > Very good from some perspectives. I started using the library by trying out checking expression validity, and it followed a logical progression, covering all types of members. This naturally led to me wondering if it is possible to use the library to test for the existence of a member named `blah`, but without knowing what category of member it is (variable, function, type, or template). I am assuming that this is as simple as saying `is_valid(variable) or is_valid(function) or ...` However, I feel that the documentation is trying to serve two incompatible purposes. On the one hand, it is trying to explain the theory of type computation using terms from functional programming. On the other hand, it also trying to be a practical guide to using the library. I feel that the second goal is compromised by the first. It seems that most of the content needed for the "cut to the chase" user is present, but by having this presentation in the form of a single document dilutes it. In other words, I don't know that the documentation passes the coworker test. If I were to show it to my coworkers, I can already hear them saying "All this stuff about computational quadrants and heterogeneous algorithms is all well and good, but how do I actually use this thing?". >From the perspective of someone who has never used MPL or Fusion (I started metaprogramming in C++11 and C++14 and never found a need for them), I do not have a problem with the comparisons to the other libraries in the documentation. I know another reviewer had mentioned that as a concern, but it just reads as evaluating prior art rather than reading as assuming prior knowledge. * Tests > I have not looked at the library's tests, I just tried to use it. > * Usefulness > The lack of constexpr lambdas really hurts the library's usefulness. It is because of this hole in the language that it can be difficult to slowly move to hana. I would like to just replace the implementation of a few functions with hana implementations at first, but then my functions are no longer constexpr if I do the obvious implementation. I have to make sure to change all of my types to IntegralConstant, for instance, to get a non-constexpr value from which I can extract a constexpr value from its type. This has a larger ripple throughout than I would like for just testing out a library before committing to it. That being said, once updating your code to fit into this paradigm, it does seem to simplify things a bit. I expect that as I update my library to be more hana friendly throughout, this simplification will increase. It was a bit disheartening at first when my code size grew slightly as I wrote various shims to translate to the correct types (I had more constexpr functions returning bool, and not so much classes that derive from integral_constant), but that ended up being a temporary state until I worked through more code. I wonder if I passed a constexpr function object rather than a non-constexpr lambda if these limitations would be removed? In practice this would probably lead to more code in the intermediate step even if it did work due to the boilerplate of defining a non-lambda function object. > - Did you attempt to use the library? If so: > * Which compiler(s)? > * What was the experience? Any problems? > clang 3.6.0 The first thing I tried was to use is_valid to determine the existence of a member type. This immediately crashed clang in the parser (I haven't had time to extract the bug report yet, but I will). It didn't seem to be the library directly, especially since others have used this feature, but the combination of my library (bounded::integer) with this feature of hana seemed to interact to cause a crash. clang seemed to perform a bit better with my second test, which was to replace some enable_if with if_. > - How much effort did you put into your evaluation of the review? > > In addition to talking with Louis at C++Now, I spent a few days trying out the library.

2 1

comparing test results between master and develop
by Stefan Seefeld 26 Jun '15

26 Jun '15

Hello, I'm trying to compare the state of the develop and master branch for the Boost.Python project, to figure out whether I can merge the develop branch to master. I find that a bit difficult, though, and was wondering whether people here have any advice. Are there any tools to generate an easy-to-analyze diff ? Right now I'm visually inspecting http://www.boost.org/development/tests/master/developer/python.html and http://www.boost.org/development/tests/develop/developer/python.html, which in itself is non-trivial given the size of the table. In addition, some testers only run on develop, some only on master, creating incommensurable results. Is there a better way to do this ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

1 0

[build] msvc-14.0 toolset can't find mt.exe?
by Peter Dimov 26 Jun '15

26 Jun '15

I've installed Visual Studio 2015 RC Community, and the msvc-14.0 toolset can't find mt.exe. I have mt.exe (twice), once in the 7.1A SDK, once in the 8.1 SDK. Does anyone have an idea what's wrong?

2 1

[hana]recursive data type?
by Larry Evans 25 Jun '15

25 Jun '15

How would one define a recursive data type in hana something described by the type equation: hana_list<T> = hana::nothing | std::pair<T,hana_list<T> > where hana_list<T> is a list of T's terminated by nothing?

2 2

future/packaged_task Sean Parent design
by Vicente J. Botet Escriba 25 Jun '15

25 Jun '15

Hi, Sean Parent suggests (See [1] Better Code: Concurrency) to remove the promise and left the packaged_task serve as single provider of a future. Both are created at once using the package factory. His future library doesn't include a shared_future as the future contains a value that can be observed several times. The continuation takes the value and not the future. So a future can have several continuations. If the store type is movable only, then the future can have only one continuation. Not really strange coming from Sean, future and packaged_task are copyables :) One more thing, there is not get no wait, but a get_try that return an optional<T>. Scales better. IIUC the implementation allows to implement when_all on top of future/packaged_task. The trick is that that the packaged_task can store some context. async has always an Scheduler as parameter. Scheculers are just Copyable Callables having this signature void(void()). There is no need for function add/spawn. when_all has also a callable as argument. I find the Sean's design clean and simple (See the code [2]). What do you think of it? Do you see any issues on it? * I don't understand why when_all continuation has the futures as parameters (I suspect that this is a type on the documentation). * I would rename get_try to try_get. This function could return optional<expected<T>>. What are you missing ? * catch_error/recover that is already planed. * when_any Best, Vicente [1] https://github.com/sean-parent/sean-parent.github.io/wiki/Papers-and-Presen… [2] https://github.com/stlab/libraries/tree/develop

3 5

Using Clang compiler in place of GCC
by Paul A. Bristow 25 Jun '15

25 Jun '15

I have installed Clang 3.6.1 (along with previously used versions of GCC) downloaded from LLVM and using the clang for LLVM Windows installer on Windows 8.1 I:\modular-boost\libs\fixed_point\example>clang++ --version clang version 3.6.1 (tags/RELEASE_361/final) Target: i686-pc-windows-gnu Thread model: posix suggests that I have the compiler in place OK and it should be in my PATH (becos I asked for it to be). --debug-configuration notice: will use 'C:/LLVM/bin/clang++.exe' for clang-linux, condition <toolset>clang-linux-3.6.1 For a project, I have a jamfile starting project : requirements <include>../include # quickdox/include <include>../../.. # modular-boost root #toolset requirements. # GCC requirements. #<toolset>gcc:<cxxflags>-std=gnu++11 # If requires C++11 library. <toolset>gcc:<cxxflags>-Wno-unused-local-typedefs <toolset>gcc:<cxxflags>-Wno-missing-braces # Clang requirements. #<toolset>clang:<cxxflags>-std=c++11 # If requires C++11 library. (I also have environment BOOST_ROOT = I:\modular-boost) when I run b2 toolset=gcc all compiles and run as expected. when I run b2 toolset=clang I get messages like common.mkdir ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.6.1 common.mkdir ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.6.1\debug clang-linux.compile.c++.without-pth ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\ clang-linux-3.6.1\debug\quick_auto_dox_index.obj quick_auto_dox_index.cpp:53:10: fatal error: 'iostream' file not found (or other files like cstddef, iomanip on other projects) #include <iostream> ^ 1 error generated. "C:/LLVM/bin/clang++.exe" -c -x c++ -O0 -g -fno-inline -Wall -g -march=i686 -m32 -DBOOST_ALL_NO_L IB=1 -I"..\..\.." -I"..\include" -o "..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test \clang-linux-3.6.1\debug\quick_auto_dox_index.obj" "quick_auto_dox_index.cpp" (Full log attached). This suggests that it is not finding the system file <iostream> ... but I'm puzzled at what is missing (and why). Suggestions most welcome. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

5 11

Stupid Constexpr Lambda Trick
by Giovanni Piero Deretta 24 Jun '15

24 Jun '15

Hi All, In the last few months constexpr lambdas and their absence in the standard came up multiple times in boost-devel, expecially when discussing the Hana library. I just wanted to share a C++14 emulation of the feature. The emulation uses both the already known conditional operator trick to allow constepr function objects to be initialized from lambda expressions, plus what I think is a novel trick to allow the actual function object operator() to be constexpr. Implementation + example is here: https://github.com/gpderetta/libtask/blob/master/lambda.cpp Sorry about the macro obfuscation, I was experimenting with a 'cute' lambda interface, but the underlying idea is very simple and pretty obvious in retrospect. I haven't tested that forwarding is always correc and I probably got some cases wrong. Lambda captures and multiple statemens are doable, but are left as an exercise for the reader :) I came up with the trick when trying to implement an emulation of N3617 (Lifting overload sets into function objects). Turns out that implementing the 'quote' syntax is almost trivial in C++14 with generic lambdas, but making it constexpr reliably has so far eluded me as all implementations I have tried ICE both gcc and clang. Still the constexpr lambda emulation itself seems to work. HTH, -- gpd

2 2

Re: [boost] future/packaged_task Sean Parent designn
by Giovanni Piero Deretta 24 Jun '15

24 Jun '15

On 24 Jun 2015 10:11 am, "Niall Douglas" <s_sourceforge(a)nedprod.com> wrote: > > On 24 Jun 2015 at 1:09, Vicente J. Botet Escriba wrote: > > > Sean Parent suggests (See [1] Better Code: Concurrency) to remove the > > promise and left the packaged_task serve as single provider of a future. > > Both are created at once using the package factory. > > I was at his talk at C++ Now. > > The first thing which put me off his proposal was that he appears to > be unaware of the highly optimised and very flexible de facto task > concurrency system in C++ which has been around for years, and has > just recently been standardised. It's called ASIO. > > I also think packaged_task is overkill for creating futures. There > are some times you really do just want a promise and nothing more. There is no reason for a packaged task implementation to be more heavy weight than a promise. If the packaged task is [](T x) { return x; } then it is also semantically equivalent to promise<T>, just in a nicer interface. Bonus points it works beautifully with ASIO without any explicit support from ASIO itself. > There are even times you just want to create a future standalone, and > for that we now have make_ready_future(). > > > His future library doesn't include a shared_future as the future > > contains a value that can be observed several times. > > If I remember rightly, internally his future has a shared_ptr, which > really means he's proposing that future becomes a shared_future. I > had doubts before until that part, but that killed his proposal for > me. It's a non-starter as a practical design for my needs, but is > still useful for ideas. > His implementation uses a shared ptr, but I think you could do without by deep copying the futures and internally chaining via then. This way you only pay the cost if you actually copy. I strongly believe that 'then' and other accessors should be non const so that concurrent calls *on the same future* need not be supported. -- gpd

3 4

[hana] Formal review
by Christophe Henry 24 Jun '15

24 Jun '15

Dear all, Following is my review of Hana. - Whether you believe the library should be accepted into Boost Yes, unconditionally. Having only one compiler compiling it is not the library's fault and it should not be held against it. If possible, I'd like to have some gcc support (and a clear note of what can be used with gcc). - Your name Christophe Henry - Your knowledge of the problem domain. Good knowledge of TMP, MPL and Fusion through my authoring of MSM. No expert of C++14 - What is your evaluation of the library's: * Design Very nice and interesting. What really slapped me in the face is writing this: template <typename ...T> auto smallest = minimum(make_tuple(type<T>...), [](auto t, auto u) { return sizeof_(t) < sizeof_(u); }); Instead of with MPL: template <typename ...T> struct smallest : deref< typename min_element< vector<T...>, less<sizeof_<_1>, sizeof_<_2>> >::type > { }; Ouch! I had forgotten how hard MPL can be... However, being value-based instead of type-based turns out to be a strength but also a weakness. To test the library, I replaced some simple MPL-based implementation parts of MSM with Hana. It works, but the code is not as simple and clean as I had hoped. For example: typedef typename ::boost::mpl::fold< stt_simulated,mpl::vector0<>, ::boost::mpl::push_back< ::boost::mpl::placeholders::_1, make_row_tag< ::boost::mpl::placeholders::_2 , BaseType > > >::type type; Became: static auto fold() { return boost::hana::fold.left(stt_simulated{}, boost::mpl::vector0<>{}, [](auto vec, auto t) { return typename ::boost::mpl::push_back< decltype(vec), typename make_row_tag <typename decltype(t)::type, BaseType>::type>::type{}; }); } typedef decltype(fold()) type; I had to create object where I actually just wanted types and also a static function so I can decltype. This is because this code was written within a struct (serving as metafunction). Honestly, my win in readability is limited ;-) But my problems started earlier. The heart of MSM is the transition table: struct transition_table : mpl::vector< Row < Stopped , stop , Stopped , none , none >, ... >{} All states and events being types, using Hana would lead me to write: Row < Stopped{} , stop{} , Stopped{} , none{} , none{} > which would be a regression. I'd love to get rid of my mpl::vector but Hana won't help me there. Maybe MSM was the wrong test object. The lack of support for mpl::set reduces to a very small part the algorithms I could port to Hana. Louis seems to want to change this, which I can only welcome. In the end, I feel that using Hana with MSM would be a take all or nothing choice. With the current compiler support, it is not something I will do in the next few months. Still, the library has a nice design and potential and I will probably use it either later in other use cases (or with MSM with better support of MPL). * Implementation I had a short glance and found it very clean. I found only one thing which bugged me, the use of non fully qualified names in some places. True, many other boost libraries do the same and it brings a lot of problems (anyone who tried to include Geometry and TypeErasure in one TU will love the duplicate definition of use_default). Still, a "return true_;" is begging for conflicts. * Documentation Great! Way above Boost level. As others said, please use fully qualified names where possible. It makes it much easier to follow. * Tests Did not look. * Usefulness Very useful if you have objects in the first place, maybe less to do TMP. - Did you attempt to use the library? If so: * Which compiler(s)? Clang 3.5. * What was the experience? Any problems? I got a few compiler errors. - A static_assert "hana::fold.left(xs, state, f) requires xs to be Foldable" when forgetting to #include <boost/hana/ext/boost/mpl/vector.hpp> I had included boost/hana.hpp but it did not include all, which is annoying. - a name conflict with std::size_t, though I deserved punishment by adding a using namespace boost::hana before including other headers. - How much effort did you put into your evaluation of the review? 8 hours reading the doc and rewriting some MSM algorithms with Hana. Thank you Louis for writing this excellent library and thank you Glen for managing the review! Christophe

2 1

[hana] Lorenzo's Formal review for Hana
by Lorenzo Caminiti 24 Jun '15

24 Jun '15

Hello Glen, Louis, and all, Please find below my review of the proposed Boost.Hana library. > - Whether you believe the library should be accepted into Boost Yes, Boost.Hana should be accepted into Boost. I decided to make my acceptance vote unconditional. However, I do have some concerns and I hope these can be addressed if Hana is in fact accepted into Boost. I marked these concerns as "[CONCERN]" below. > - Your name Lorenzo Caminiti. > - Your knowledge of the problem domain. I have been using C++ Template Meta-Programming (TMP) for 10+ years now. I routinely maintain ~23,000 lines of production code that extensively uses Boost.MPL, Boost.Fusion, and a TMP-based serialization mechanism (among a number of other Boost libraries) -- compilation times are a *huge* issue with this code! > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design The library API seems reasonable, consistent, and powerful. * [CONCERN] Assertions should be renamed from ..._CHECK to ..._ASSERT (to be consistent with assert, static_assert, BOOST_STATIC_ASSERT, BOOST_MPL_ASSERT, etc.). * Is there a ..._MSG version for the assertion macros? (These should probably just variadic macros where a second optional parameter represents the error message to display in case the asserted condition if false.) * The following is very nice! auto has_toString = is_valid([](auto&& obj) -> decltype(obj.toString()) { }); I've been wanting to do the above at function scope for a long time (so I can program it within the function where I actually need it). Now with C++14 generic lambdas we finally can :) Also this is very nice! template <typename T> std::string optionalToString(T const& obj) { return if_(has_toString(obj), [](auto& x) { return x.toString(); }, [](auto& x) { return "toString not defined"; } )(obj); } Somewhat similar to my static_if (renamed call_if, after Vicente's suggestion) proposal using C++14 generic lambdas: http://boost.2283326.n4.nabble.com/static-if-Is-there-interest-in-a-static-… BTW, how would you program the following possible implementation of std::advance in Hana? template<typename Iter> struct is_random_access_iterator : std::is_same< typename std::iterator_traits<Iter>::iterator_category, std::random_access_iterator_tag > {}; template<typename Iter> struct is_bidirectional_iterator : std::is_same< typename std::iterator_traits<Iter>::iterator_category, std::bidirectional_iterator_tag > {}; template<typename Iter> struct is_input_iterator : std::is_same< typename std::iterator_traits<Iter>::iterator_category, std::input_iterator_tag > {}; template<typename Iter, typename Dist> void myadvance(Iter& i, Dist n) { Iter *p = &i; // So captures change actual pointed iterator value. call_if<is_random_access_iterator<Iter> >( std::bind([] (auto p, auto n) { *p += n; }, p, n) ).template else_if<is_bidirectional_iterator<Iter> >( std::bind([] (auto p, auto n) { if(n >= 0) while(n--) ++*p; else while(n++) --*p; }, p, n) ).template else_if<is_input_iterator<Iter> >( std::bind([] (auto p, auto n) { while(n--) ++*p; }, p, n) ).else_( std::bind([] (auto false_) { static_assert(false_, "requires at least input iterator"); }, std::false_type()) // Use constexpr value. ); } * This macro: struct Person { BOOST_HANA_DEFINE_STRUCT(Person, (std::string, name), (int, age) ); }; Will it work even if the data member types contain commas? For example, the following is supported, correct? (It should be because these can use variadic macros...) struct Person { BOOST_HANA_DEFINE_STRUCT(Person, (std::map<int, char>, name), (int, age) ); }; P.S. These sort of macros /could/ be implemented as follows if users found this syntax to be more readable (but maybe not...): struct Person { BOOST_HANA_DEFINE_STRUCT(Person, (std::map<int, char>) name, (int) age, ); }; * [CONCERN] The docs say: "Hana's design assumes that most of the time, we want to access all or almost all the elements in a sequence anyway, and hence performance is not a big argument in favor of laziness." Especially given that other well-established libraries like Fusion addressing the same problem domain have gone in favor of laziness instead... Is this a good assumption? If so, why? * [CONCERN] The docs say: "By default, Hana assumes functions to be pure. A pure function is a function that has no side-effects at all." Will this assumption limit what users will be able to do with Hana? Do MPL and Fusion relay on a similar assumption? Yes/no, why... * [CONCERN] I would prefer a descriptive name for the library instead of Hana. I am well aware that Phoenix, Spirit, Wave, etc. are examples of non-descriptive names in Boost. I consider those bad naming choices and I would not follow them. Changing the library name should only take a few days (maybe 2-5 days... especially with tools like grep and sed) so that should not be a problem. Others pointed out that there might be copyright/trademark issues with the name "Hana". The possibility to have to change such name at some point /after/ the library has been released in Boost would be a disaster for the users... such risk should be avoided. Possible names? typeval (given the library is about "TYPEs as VALuses", plus the similar, already familiar, name std::declval) meta metaval metaexpr generic (assuming Matt Calabrese is no longer planning to use this) ... * [CONCERN] Rename Map, Range, etc. to map, range, etc. (all lower case). In Boost and STL capital letters are only used for template parameters, and maybe concepts. (If it is important to distinguish that those are tags (I don't think so) then name them map_tag, range_tag, etc. but still no capital letters.) * [CONCERN] is_empty, length, and few other names should be changed to empty, size, etc. to match STL naming conventions (so I don't have to remember different names for the same thing). > * Implementation Some code can be optimized, but the author already mentioned he will look into that this summer. I did not see any specific issue otherwise. > * Documentation * [CONCERN] The documentation will be much (much!) more readable is the "hana" namespace was not stripped away. Please write hana::..., mpl::... (if not the full boost::hana::..., boost::mpl::...) in the docs. * The docs say: "Notice how we cast the result of x.member to void? This is to make sure that our detection also works for types that can't be returned from functions, like array types." auto has_member = is_valid([](auto&& x) -> decltype((void)x.member) { }); But obviously, the following (without the cast) would work too, correct? auto has_member = is_valid([](auto&& x) -> decltype(x.member, void()) { }); * I would expect the following example to use operator|| instead of or_: auto ts = filter(types, [](auto t) { return or_(is_pointer(t), is_reference(t)); }); * Performance graphs would be more readable if they always used the same color for the same entity. For example, sometimes mpl::vector is blue, other times it is orange... * Why the "Runtime performance of reverse on normal container" for fusion::vector stops at "Number of elements" = 50? > * Tests > > * Usefulness * If not for anything else, I will use this library for its SFINAE facilities. Second, I will use this library in production code for its improved compilation times (assuming these can be confirmed on MSVC). Finally, I am curious to use this library in general because it seems it will improve my meta-programming, also making easier to read. * [CONCERN] The author should be committed to support the library on GCC and MSVC once that becomes feasible, even if that requires a good deal of workarounds. For example, Boost.Preprocessor is full of MSVC workaround (because MSVC preprocessor is still not standard compliant... after 30+ years of existence of the C preprocessor). Maybe MSVC will never be 100% C++14 standard compliant... I don't know. But I do know that if this library is not ported to MSVC at some future point, I won't be able to use it in my production code. I do hope that adoption into Boost will push vendors to support C++14 constructs used by this library TMP techniques. I also hope the author is committed to do whatever it takes to make the library work on MSVC. * [CONCERN] What compiler was used to measure performance? CLang? I hope the promised performance gains (especially compile-time reductions) will be there for GCC, and especially later also for MSVC. If not, that will significantly limit my motivation on using this library in production code. TMP compilation times are largely dependant on specific compiler implementations of C++ template machinery which might vary significantly from vendor to vendor. Therefore, at the moment I only know that the library is expected to compile faster on Clang, but unfortunately that does not tell me anything about expected compilation time improvements on GCC, and even less on MSVC... > - Did you attempt to use the library? If so: > * Which compiler(s)? Clang. > * What was the experience? Any problems? Overall, pretty good experience. No specific issue to report a part from what already noted. > - How much effort did you put into your evaluation of the review? A total of about 2 days between reading docs, playing with some examples, and looking at the code a bit. My thanks to Luis for his outstanding work with this library! --Lorenzo On Wed, Jun 10, 2015 at 2:19 AM, Glen Fernandes <glen.fernandes(a)gmail.com> wrote: > Dear Boost community, > > The formal review of Louis Dionne's Hana library begins today,10th June > and ends on 24th June. > > Hana is a header-only library for C++ metaprogramming that provides > facilities for computations on both types and values. It provides a > superset of the functionality provided by Boost.MPL and Boost.Fusion > but with more expressiveness, faster compilation times, and faster (or > equal) run times. > > To dive right in to examples, please see the Quick start section of the > library's documentation: > http://ldionne.com/hana/index.html#tutorial-quickstart > > Hana makes use of C++14 language features and thus requires a C++14 > conforming compiler. It is recommended you evaluate it with clang 3.5 or > higher. > > Hana's source code is available on Github: > https://github.com/ldionne/hana > > Full documentation is also viewable on Github: > http://ldionne.github.io/hana > > To read the documentation offline: > git clone http://github.com/ldionne/hana --branch=gh-pages doc/gh-pages > > For a gentle introduction to Hana, please see: > 1. C++Now 2015: > http://ldionne.github.io/hana-cppnow-2015 (slides) > 2. C++Con 2014: > https://youtu.be/L2SktfaJPuU (video) > http://ldionne.github.io/hana-cppcon-2014 (slides) > > We encourage your participation in this review. At a minimum, kindly > state: > - Whether you believe the library should be accepted into Boost > * Conditions for acceptance > - Your name > - Your knowledge of the problem domain. > > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design > * Implementation > * Documentation > * Tests > * Usefulness > - Did you attempt to use the library? If so: > * Which compiler(s) > * What was the experience? Any problems? > - How much effort did you put into your evaluation of the review? > > We await your feedback! > > Best, > Glen > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[graph] depth_first_visit_impl
by Michael Marcin 24 Jun '15

24 Jun '15

I was doing some work with depth_first_search and came across some issues that seem surprising with the implementation. First vis.finish_edge doesn't seem to ever get called on msvc. Second changing the code to call finish_edge directly instead of through the call_finish_edge machinery seems to result in incorrect edges being finished. Third the implementation of depth_first_visit_impl pushes into a std::vector stack even for vertices with no out_edges. If I have a graph with a large number of vertices but few or no edges this seems bad. This seems to force a dependency on optional as well. Finally the loop as written should probably be a do..while since the stack will never be empty on the first test. I attached a patch that addresses the second and third issues. The tests continue to pass for me with this change.

1 0

[Hana] Formal review
by Bruno Dutra 23 Jun '15

23 Jun '15

Dear all, Following is my review of Hana. - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes, absolutely, but please read on. - Are you knowledgeable about the problem domain? I've been playing with metaprogramming as a hobby since 2011 when I first came across Boost.MPL. I experimented with a library that implements the unification algorithm at compile time using Boost.MPL for a long time, on and off, and recently I've decided giving a shot at my own implementation of a C++11 version of Boost.MPL. - What is your evaluation of the design? The design seems to be very general and abstract, based on formal mathematical concepts. I've had my dose of FP through SML and lisp, however I've never dug deep into category theory, so I won't venture into judging the way these abstract concepts were translated to C++, but all looks sound to me. I'm very fond of the way type computations are carried out by value through the use of type<> and decltype(). Such an ingenious simplicity. Once one gets it, one realizes how beautifully it merges value and type computations into one. I also like very much the design of compile time constants, their custom _c suffix and operators. To me, that is material for standardization. I would like to point out however, that from the point of view of someone who has basically solely done C++ his entire life, just like myself, Hana can look *very* unfamiliar. I understand it is mostly my fault for not properly having learnt FP before, however I believe I'm not alone among average C++ programmers, so I fear this could prevent many potential users from adopting Hana, simply because one tends to stick to things that look familiar to one. Now I'm not sure that is any easy way around this unfamiliarity. I've seen others pointing out that names could better reproduce the C++ standard library (to what I agree) and perhaps that's indeed all one could do to tighten the gap that separates Hana from mainstream C++ libraries. At any rate, I just felt I should stress this point, to make sure it is not underestimated. - What is your evaluation of the implementation? I've just briefly peeked at the code base out of curiosity and it looks pretty clean and organized. The use of global function objects however intrigues me, why not free functions? I've also found myself stumbling on variable templates. Perhaps that's just me, but really I find they make everything so cryptic. Anyways, I guess it's not Hana's fault to make arguably good use of something that is part of the language. - What is your evaluation of the documentation? I find myself blindly using the search button in hope to find whatever I'm looking for more often than I'd rather do, but perhaps it's just a matter of getting used to how the documentation is organized. One thing I'd like to see improved is the alphabetical index. I'd expect it to be thorough, but at least "is_a" is missing, so I assume a rationale exists to decide what goes there? I think it would be better to list everything exhaustively, so users may rely on the browser's find tool to explore the library. - What is your evaluation of the potential usefulness of the library? At first I was afraid Hana were too academical and abstract to be a good tool for getting down to business, but after playing with it a little bit I can see that, once one gets its design, it does make metaprogramming quite straightforward. I believe however that most users will attain to a very limited subset of functionalities in order to just get their tasks accomplished. So much so, that I'd strongly advise Hana to be split into one highly specialized tool for straightforward metaprogramming and another more abstract halve providing the more generic concepts. This could ease user experience considerably, reducing the novelty presented by Hana and thus tightening the gap I've mentioned before. - Did you try to use the library? With what compiler? Did you have any problems? Yes on Clang 3.6.1. I tried to implement the unification algorithm [1] at compile time using Hana and, though I haven't actually finished, I could see it would be straightforward. In fact I gave up on it when I found a bug which prevented the construction of optional maps, but not too long after I contacted Louis and opened an issue [2] it seems to have already been fixed on develop branch. I didn't test the fix myself though. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 4 hours reading the documentation, another 4 hours trying the library and about 2 hours to write this review. *Bruno C. O. Dutra* [1]: https://en.wikipedia.org/wiki/Unification_(computer_science) [2]: https://github.com/ldionne/hana/issues/149

3 4

[test] Re: [Boost-testing] Develop branch test runners crashing
by Rene Rivera 23 Jun '15

23 Jun '15

Please fix ASAP. On Tue, Jun 23, 2015 at 8:32 AM, Tom Kent <lists(a)teeks99.com> wrote: > Sometime between 22:30 and 03:30 last night (pacific time) all the develop > tests started crashing on windows and linux. > > The tail of results/bjam.log is: > > notice: iostreams: not using bzip2 compression > notice: iostreams: not using bzip2 compression > ..\libs\test\test\Jamfile.v2:59: in docs-example-as-test > *** argument error > * rule boost.test-self-test ( test-rule : test-suite : test-name : > usage-variant ? : pattern_file * : source_files * : extra-libs ? : > extra-options ? ) > * called with: ( : ../doc/examples : : included : : > /D:/t08/run/boost_root/libs/test/doc/examples/boost_test_bitwise.run-fail.cpp > ) > * missing argument test-rule > ..\libs\test\test\Jamfile.v2:18:see definition of rule > 'boost.test-self-test' being called > (builtin): in sequence.transform > ..\libs\test\test\Jamfile.v2:162: in modules.load > D:/t08/run/boost_bb/src/build\project.jam:325: in load-jamfile > D:/t08/run/boost_bb/src/build\project.jam:64: in load > D:/t08/run/boost_bb/src/build\project.jam:145: in project.find > D:/t08/run/boost_bb/src/build\targets.jam:452: in find-really > D:/t08/run/boost_bb/src/build\targets.jam:474: in find > D:/t08/run/boost_bb/src/build\targets.jam:305: in targets-to-build > D:/t08/run/boost_bb/src/build\targets.jam:270: in > class(a)project-target.generate > D:/t08/run/boost_bb/src\build-system.jam:707: in load > D:\t08\run\boost_bb\src/kernel\modules.jam:295: in import > D:\t08\run\boost_bb\src/kernel/bootstrap.jam:139: in boost-build > D:\t08\run\boost_root\boost-build.jam:17: in module scope > > Any thoughts? > > _______________________________________________ > Boost-Testing mailing list > Boost-Testing(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-testing > -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

Re: [boost] [test] Develop branch test runners crashing
by Andrey Semashev 23 Jun '15

23 Jun '15

On Tue, Jun 23, 2015 at 4:32 PM, Tom Kent <lists(a)teeks99.com> wrote: > Sometime between 22:30 and 03:30 last night (pacific time) all the develop > tests started crashing on windows and linux. > > The tail of results/bjam.log is: > > notice: iostreams: not using bzip2 compression > notice: iostreams: not using bzip2 compression > ..\libs\test\test\Jamfile.v2:59: in docs-example-as-test > *** argument error > * rule boost.test-self-test ( test-rule : test-suite : test-name : > usage-variant ? : pattern_file * : source_files * : extra-libs ? : > extra-options ? ) > * called with: ( : ../doc/examples : : included : : > /D:/t08/run/boost_root/libs/test/doc/examples/boost_test_bitwise.run-fail.cpp > ) > * missing argument test-rule > ..\libs\test\test\Jamfile.v2:18:see definition of rule > 'boost.test-self-test' being called > (builtin): in sequence.transform > ..\libs\test\test\Jamfile.v2:162: in modules.load > D:/t08/run/boost_bb/src/build\project.jam:325: in load-jamfile > D:/t08/run/boost_bb/src/build\project.jam:64: in load > D:/t08/run/boost_bb/src/build\project.jam:145: in project.find > D:/t08/run/boost_bb/src/build\targets.jam:452: in find-really > D:/t08/run/boost_bb/src/build\targets.jam:474: in find > D:/t08/run/boost_bb/src/build\targets.jam:305: in targets-to-build > D:/t08/run/boost_bb/src/build\targets.jam:270: in > class(a)project-target.generate > D:/t08/run/boost_bb/src\build-system.jam:707: in load > D:\t08\run\boost_bb\src/kernel\modules.jam:295: in import > D:\t08\run\boost_bb\src/kernel/bootstrap.jam:139: in boost-build > D:\t08\run\boost_root\boost-build.jam:17: in module scope > > Any thoughts? Looks like a Boost.Test issue.

1 0

Develop branch test runners crashing
by Tom Kent 23 Jun '15

23 Jun '15

Sometime between 22:30 and 03:30 last night (pacific time) all the develop tests started crashing on windows and linux. The tail of results/bjam.log is: notice: iostreams: not using bzip2 compression notice: iostreams: not using bzip2 compression ..\libs\test\test\Jamfile.v2:59: in docs-example-as-test *** argument error * rule boost.test-self-test ( test-rule : test-suite : test-name : usage-variant ? : pattern_file * : source_files * : extra-libs ? : extra-options ? ) * called with: ( : ../doc/examples : : included : : /D:/t08/run/boost_root/libs/test/doc/examples/boost_test_bitwise.run-fail.cpp ) * missing argument test-rule ..\libs\test\test\Jamfile.v2:18:see definition of rule 'boost.test-self-test' being called (builtin): in sequence.transform ..\libs\test\test\Jamfile.v2:162: in modules.load D:/t08/run/boost_bb/src/build\project.jam:325: in load-jamfile D:/t08/run/boost_bb/src/build\project.jam:64: in load D:/t08/run/boost_bb/src/build\project.jam:145: in project.find D:/t08/run/boost_bb/src/build\targets.jam:452: in find-really D:/t08/run/boost_bb/src/build\targets.jam:474: in find D:/t08/run/boost_bb/src/build\targets.jam:305: in targets-to-build D:/t08/run/boost_bb/src/build\targets.jam:270: in class(a)project-target.generate D:/t08/run/boost_bb/src\build-system.jam:707: in load D:\t08\run\boost_bb\src/kernel\modules.jam:295: in import D:\t08\run\boost_bb\src/kernel/bootstrap.jam:139: in boost-build D:\t08\run\boost_root\boost-build.jam:17: in module scope Any thoughts?

1 0

[coroutine2] Difference between coroutine and coroutine2
by Aaron Levy 23 Jun '15

23 Jun '15

Are boost::coroutines::symmetric_coroutine<> and boost::coroutines::asymmetric_coroutine<> part of the coroutine library or coroutine2 library. Besides being C++14-only, in what ways does coroutine2 differ from coroutine? -- Aaron Levy aaron.levy(a)yandex.com

5 7

[Optional] Monadic bind
by Tobias Loew 23 Jun '15

23 Jun '15

While playing around with boost::optionals I had code like the following struct A { ... int i; ... }; boost::optional a; // do something with 'a' // optional-projection to a::i boost::optional<int> a_i; if(a) a_i = a->i; which seemed quite verbose for something that's rather natural in functional languages: boost::optional is a monadic structure, which lifts a type T by extending it with a new bottom-element (represented by the empty optional<T>), thus it should also have a "bind" and a "map"-equivalent, which could be implemented for instance as as member functions of optional template<class B> auto bind(B&& binder) const -> boost::optional<typename std::decay<decltype(std::bind(binder, get())())>::type> { if(this->is_initialized()) { return std::bind(binder, get())(); } else { return boost::none; } } and template<class B> auto map(B&& f) const -> boost::optional<typename std::decay<decltype(std::bind(f, get())())>::type> { if(this->is_initialized()) { return std::bind(f, get())(); } else { return boost::none; } } where map lifts f from A->B to optional -> optional< B > and applies 'this' to it. This would allow things like boost::optional a; auto a_i = a.map(&A::i); // "optional-projection"; type of a_i is boost::optional<int> Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/Optional-Monadic-bind-tp4677431.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 7

[test] Where we are with the new version?
by Vicente J. Botet Escriba 23 Jun '15

23 Jun '15

Hi, I'm wondering if the new Boost.Test will be merged one day to the master branch. Best, Vicente

3 5

[config] 'requres' doesn't take differing -std into account
by Peter Dimov 22 Jun '15

22 Jun '15

I have, in my user-config.jam, using gcc ; feature.subfeature toolset gcc : std : cxx0x cxx11 cxx1y cxx14 : optional composite propagated ; feature.compose <toolset-gcc:std>cxx0x : <cxxflags>-std=c++0x ; feature.compose <toolset-gcc:std>cxx11 : <cxxflags>-std=c++11 ; feature.compose <toolset-gcc:std>cxx1y : <cxxflags>-std=c++1y ; feature.compose <toolset-gcc:std>cxx14 : <cxxflags>-std=c++14 ; using clang : : : <cxxflags>-Wno-variadic-macros <cxxflags>-Wno-c99-extensions ; feature.subfeature toolset clang : std : cxx0x cxx11 cxx1y cxx14 : optional composite propagated ; feature.compose <toolset-clang:std>cxx0x : <cxxflags>-std=c++0x ; feature.compose <toolset-clang:std>cxx11 : <cxxflags>-std=c++11 ; feature.compose <toolset-clang:std>cxx1y : <cxxflags>-std=c++1y ; feature.compose <toolset-clang:std>cxx14 : <cxxflags>-std=c++14 ; This allows me to use toolset=clang (without -std) and toolset=clang-cxx11 (with -std=c++11). The 'requires' rule however caches the results of the configuration check when I run with toolset=clang, and then when I rerun with toolset=clang-cxx11, it uses the cached values, which is wrong. I use something like run test.cpp : : : [ requires cxx11_variadic_templates cxx11_template_aliases cxx11_hdr_type_traits cxx11_hdr_tuple ] ;

6 16

[hana] question
by Christophe Henry 22 Jun '15

22 Jun '15

Hi Louis, I'm experimenting with hana for the review and have one question. I can fold with boost::hana::fold.left(boost::mpl::vector<...>{}...) Do you have a way to iterate on elements of a mpl::set? Thanks, Christophe

2 1

[Boost] [Hana] Formal review for Hana
by Glen Fernandes 22 Jun '15

22 Jun '15

Dear Boost community, The formal review of Louis Dionne's Hana library begins today,10th June and ends on 24th June. Hana is a header-only library for C++ metaprogramming that provides facilities for computations on both types and values. It provides a superset of the functionality provided by Boost.MPL and Boost.Fusion but with more expressiveness, faster compilation times, and faster (or equal) run times. To dive right in to examples, please see the Quick start section of the library's documentation: http://ldionne.com/hana/index.html#tutorial-quickstart Hana makes use of C++14 language features and thus requires a C++14 conforming compiler. It is recommended you evaluate it with clang 3.5 or higher. Hana's source code is available on Github: https://github.com/ldionne/hana Full documentation is also viewable on Github: http://ldionne.github.io/hana To read the documentation offline: git clone http://github.com/ldionne/hana --branch=gh-pages doc/gh-pages For a gentle introduction to Hana, please see: 1. C++Now 2015: http://ldionne.github.io/hana-cppnow-2015 (slides) 2. C++Con 2014: https://youtu.be/L2SktfaJPuU (video) http://ldionne.github.io/hana-cppcon-2014 (slides) We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? We await your feedback! Best, Glen

7 33

Re: [boost] [Hana] Formal review
by David Sankel 22 Jun '15

22 Jun '15

On Wed, Jun 10, 2015 at 3:19 AM, Glen Fernandes <glen.fernandes(a)gmail.com> wrote: > - Whether you believe the library should be accepted into Boost > * Conditions for acceptance > Yes, I think it should be accepted into Boost. The one condition is that the library works with release versions of at least two different mainstream C++ compilers. More on that later... > - Your name > David J. Sankel > - Your knowledge of the problem domain. > I've written numerous libraries that make use of Boost.MPL and Boost.Fusion. I also have quite a bit of functional programming expertise. > > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design > The core technique of combining value and type expressions is solid and makes metaprogramming easier and, as a bonus, improves compilation speeds. My one question, as I read though the implementation, is "can the core benefits of this library be achived with a simpler 'light' version of this implementation?". While I appreciate the attempt to encode a Haskell-style typeclass hierarchy, I feel like that is not the core competency of hana and should be a separate library and discussion. As it is, this is a 32k header mega library. I'd prefer several small, highly-targeted, highly-composable libraries. > * Implementation > The code itself looks to be well structured and well documented. Unfortunately hana only works with one compiler: clang. While I agree that Boost shouldn't need to support Visual C++ 6.0 anymore, I believe this is going too far in the opposite direction. The home page states that boost libraries "are intended to be widely useful, and usable across a broad spectrum of applications". I've always interpreted that statement to be in a practical rather than theoretical sense and I don't think hana meets that criteria. Many other Boost authors have made heroic efforts to meet that criteria and the reputation of Boost is due, in no small part, to those efforts. I do appreciate the argument that making use of new features encourages compiler implementers to implement then. I maintain, however, that this isn't Boost's job. Boost provides high quality libraries that the every-day Joe C++ developer can benefit from. That being my position on the issue, my acceptance vote is conditional on hana supporting at least two released versions of mainstream compilers. Given that gcc support seems pretty close, that shouldn't be hard to achieve. * Documentation > Looks good. > * Tests > I didn't evaluate these. I tried, but failed, to build the code and filed related issues. I'm assuming the problems are minor and straightforward to fix. * Usefulness > Maybe in a couple years for me. Without VS 2015 support at least, I'm going to be waiting a while. - Did you attempt to use the library? Yes. Started working through the getting started examples. > If so: > * Which compiler(s) > clang 3.6.1 > * What was the experience? Any problems? > Nothing more to add. I filed an issues for all problems encountered and they seemed minor. > - How much effort did you put into your evaluation of the review? > I attended both of Louis's talks, skimmed through the documentation, attempted to build, and read portions of the code. -- David Sankel

17 38

Attn: Volodya.. Re: [config] 'requres' doesn't take differing -std into account
by Rene Rivera 22 Jun '15

22 Jun '15

On Sun, Jun 21, 2015 at 8:11 PM, Edward Diener <eldiener(a)tropicsoft.com> wrote: > On 6/21/2015 10:19 AM, Peter Dimov wrote: > >> I have, in my user-config.jam, >> >> using gcc ; >> >> feature.subfeature toolset gcc : std : cxx0x cxx11 cxx1y cxx14 : >> optional composite propagated ; >> >> feature.compose <toolset-gcc:std>cxx0x : <cxxflags>-std=c++0x ; >> feature.compose <toolset-gcc:std>cxx11 : <cxxflags>-std=c++11 ; >> feature.compose <toolset-gcc:std>cxx1y : <cxxflags>-std=c++1y ; >> feature.compose <toolset-gcc:std>cxx14 : <cxxflags>-std=c++14 ; >> >> using clang : : : <cxxflags>-Wno-variadic-macros >> <cxxflags>-Wno-c99-extensions ; >> >> feature.subfeature toolset clang : std : cxx0x cxx11 cxx1y cxx14 : >> optional composite propagated ; >> >> feature.compose <toolset-clang:std>cxx0x : <cxxflags>-std=c++0x ; >> feature.compose <toolset-clang:std>cxx11 : <cxxflags>-std=c++11 ; >> feature.compose <toolset-clang:std>cxx1y : <cxxflags>-std=c++1y ; >> feature.compose <toolset-clang:std>cxx14 : <cxxflags>-std=c++14 ; >> >> This allows me to use toolset=clang (without -std) and >> toolset=clang-cxx11 (with -std=c++11). >> >> The 'requires' rule however caches the results of the configuration >> check when I run with toolset=clang, and then when I rerun with >> toolset=clang-cxx11, it uses the cached values, which is wrong. >> > > I believe the same problem is causing predef-check problems in the predef > library because I have seen local errors using predef-check which also says > that a previous calculation on another toolset has been cached and is being > reused, even when the toolset changes. Somehow the incorrect cached value > is being retained by Boost Build even when the toolset value changes and a > new calculation needs to be made. But like many other people I don't know > nearly enough about Boost Build to figure out what it is doing. I must confess I don't know the rationale for limiting the feature set for config checks. We have to see what Volodya says about this. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[release] policy not to add C++14 libraries
by Oliver Kowalke 21 Jun '15

21 Jun '15

Hi, I'm wondering if C++14 libraries will not be added to the boost release? Oliver

7 20

[Boost] [Hana] Announcing Hana's formal review next week (June 10th)
by Glen Fernandes 21 Jun '15

21 Jun '15

Dear Boost community, The formal review of Louis Dionne's Hana library starts Monday, 10th June and ends on 24th June. Hana is a header-only library for C++ metaprogramming that provides facilities for computations on both types and values. It provides a superset of the functionality provided by Boost.MPL and Boost.Fusion but with more expressiveness, faster compilation times, and faster (or equal) run times. To dive right in to examples, please see the Quick start section of the library's documentation: http://ldionne.com/hana/index.html#tutorial-quickstart Hana makes use of C++14 language features and thus requires a C++14 conforming compiler. It is recommended you evaluate it with clang 3.5 or higher.[1] Hana's source code is available on Github: https://github.com/ldionne/hana Full documentation is also viewable on Github: http://ldionne.github.io/hana To read the documentation offline: git clone http://github.com/ldionne/hana --branch=gh-pages doc/gh-pages For a gentle introduction to Hana, please see: 1. C++Now 2015: http://ldionne.github.io/hana-cppnow-2015 (slides) 2. C++Con 2014: https://youtu.be/L2SktfaJPuU (video) http://ldionne.github.io/hana-cppcon-2014 (slides) We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? [1] A note for Windows users: As mentioned, Hana requires a C++14 conforming compiler. If you would like to try it, a VM with Linux and clang 3.5 is a fairly painless option. Some users have also reported success with using Clang 3.5 on Windows. If you would like assistance configuring the former option, feel free to reach out to us for this. Best, Glen

12 44

needs coroutine2 a review?
by Oliver Kowalke 21 Jun '15

21 Jun '15

coroutine2 is a C++14-only library, providing cleaner code (maintainability) + it fixes some issues (moveable-only parameters). boost.coroutine will be deprecated. The conclusion of the last discussion ( http://boost.2283326.n4.nabble.com/transforming-ex-boost-lib-into-C-11-only…) was to establish coroutine2 as a separate lib beside of boost.coroutine - similar to boost.signals(2). I'm wondering if coroutine2 needs a review, even if the interface remains the same compared to boost.coroutine. Oliver

4 6

[coroutine2] search for review manager (mini-review)
by Oliver Kowalke 21 Jun '15

21 Jun '15

Hi, is there anyone wishing to help with mini review and become a review manager? coroutine2 is a C++14 implementation of boost.coroutine. github: https://github.com/boostorg/coroutine2 docu: http://olk.github.io/libs/coroutine2/doc/html/ best regardds, Oliver

2 1

[coroutine2] add to testing
by Oliver Kowalke 21 Jun '15

21 Jun '15

Hi, I'm uncertain if boost.coroutine2 (C++11-only) will be part to the 1.58 release - a git-submodule exists but not at the list for the regression tests (I've opened a pull-request to boostorg/boost). Could you tell me the status of boost.coroutine2?! thx, Oliver

2 3

[Hana] Review
by Roland Bock 20 Jun '15

20 Jun '15

Hi, Here are my review results: - Whether you believe the library should be accepted into Boost Yes. - Your name Roland Bock - Your knowledge of the problem domain. On the one hand, I do believe to have some knowledge in TMP, being the author of sqlpp11. I have made some minor contributions to early versions of Hana, discussing implementations of type sets and all/any/none. I experimented with the MPL for quite some time before the advent of C++11... On the other hand, I am almost totally blank when it comes to Haskell or Fusion. - What is your evaluation of the library's: * Design Awesome. Using template variables to turn types into objects and then treating types and values the same way in most places is very cool. * Implementation I haven't spent too much time on the implementation. I read code around hana::string and hana::all. It was nicely structured and quite readable. * Documentation Impressive already. With all the input from the reviews coming in, it will become even better. I found navigation/searching a bit awkward sometimes. Personally, I would like more cross links/tables. E.g. functions working with Set (Louis already created an issue on github for this). * Tests To be honest, I did not look at them. * Usefulness We'll see what comes out of it. Which libraries are actually going to use Hana. I'll give it a try with sqlpp11. As others have stated, it might be a bit too much even. BUT, regardless of how many projects will actually use it, Hana will force some compiler teams to go to great lengths to be able to compile the library. It might also become a benchmark in terms of compile time and the number of generated instructions. Also, Hana contains a wealth of design ideas, tricks and knowledge for anybody who needs to solve a particular compile time problem. I am sure that many library authors and other developers will benefit from this Hana being available, maintained and developed within Boost. And Hana has minimal dependencies (just a handful of headers from the standard library). Thus Hana might help to change the impression that many people have of Boost (coming from many established, older Boost libraries): Awesomely cool stuff, but dependencies from all nine levels of hell (aka, you can look, but you better not touch). To sum it up: Usefulness? Very! - Did you attempt to use the library? If so: * Which compiler(s)? clang-3.5.1 * What was the experience? Any problems? As described in an earlier mail: - I tried to use Hana's string UDL (the gcc/clang hack) but failed. Hana is not to blame here, it is rather because of shortcomings in the C++ core language. - I thought about using Hana's all/any/none, but my own versions were proven (by Louis himself) to be outstandingly fast, so no reason to switch - I thought of switching to Hana's compile time sets, but that seemed like a tough thing to do considering that I am using type sets and Hana is using value sets. Louis showed samples from Zach Laine which would make the transition easier. Actually, something like this should be part of the documentation. Maybe it might make sense to have a collection of migration examples (before/after code)? That might not sound very successful, but I think it was: While researching how I could achieve my goals I learned a lot about the library. - How much effort did you put into your evaluation of the review? Several hours of reading and some tests in combination with sqlpp11. Remark on compilers: There was some argument as to whether Boost could contain a library that can only be compiled by one compiler (actually, maybe two in this case). My personal opinion is: Yes, Boost could and should do that if the library complies with a modern version of the C++ standard. Compiler teams take pride in being able to compile boost. If they cannot compile a Boost library, they will try to accomplish that ASAP. This is going to help everyone. It is good to have libraries in Boost that challenge compilers even to the point of breaking one or the other. Trying to work around compiler bugs does not seem right for new libraries. Thanks to Louis for his library and to Glen for managing the review! Best, Roland

2 1

[Hana] Formal Review
by Krzysztof Jusiak 20 Jun '15

20 Jun '15

Hi, Please find my review below. - Whether you believe the library should be accepted into Boost Definitely YES. IMHO, one of the most complete boost proposals. - Your name Krzysztof Jusiak - Your knowledge of the problem domain. I've been using MPL and Fusion for about 6 years in commercial projects, I also have been using C++11 /C++14 template features in open source projects since they become available. I have some experience with Haskell and other functional programming languages. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design Library seems to be very well designed. Used patterns are easy to follow. There is a distinction between algorithms, data types and concepts. The approach is really easy to follow for Haskell programmers, but, on the other hand, C++ influence might be noticed as well. Seems to be very straight forward mix of approaches. * Implementation Source Code: First impression, it's a lot of it! But it's easy to follow. Helpful directory structure makes it much easier to handle. Big thanks for changing the naming as well, `snoc`, `cons` and so on, could have been hard to follow for C++ programmers. Implementation consist of a high quality source code. There are few small things, which are not as straight forward. * a lot of fwd (assume forward declaration files) files have implementation inside, which is a bit confusing * a bit annoying `#ifdef BOOST_HANA_DOXYGEN_INVOKED` all over the source code Performance: I have to admit, I really appreciate the library handled this topic. MPL/Fusion, although, very useful are really hard to introduce in commercial projects in the large scale. I do remember using Boost.MSM for a bit, but the company had to give up on it, because having a transition table with more than 200 entries wasn't easy to deal with, to say at least. Having sad that, I think Hana can still improve the compilation times. I didn't even bother to compare it to MPL or Fusion, because there is no comparison there, but with C++ template tricks there is. Compilation time: So I have written simple example to compare `Hana Map` and `C++ Tricks Map`. Please notice, I compared map with 1000 entries! Hehehe, can anyone imagine that with MPL or Fusion? Results are here: tricks_map: https://gist.github.com/krzysztof-jusiak/cb6633d6c11572c33928 0m0.095s hana_map: https://gist.github.com/krzysztof-jusiak/949d3916d84c466b80c5 0m11.105s So, Hana seems to be much slower, but still not really slow. It's not hours, just a few seconds, which IMHO, it's a huge improvement already. run-time: Haven't checked this part as deeply. Diagnostic Messages: Really popular topic recently and Hana made a huge progress with it as well. Concepts helps a lot, but, unfortunately, there is always a call stack following the error message. Sometimes, such approach is desired, but would be great not to see all Hana's internals, especially with recursive algorithms. Tested error message: https://gist.github.com/krzysztof-jusiak/bfc51747d083e140772d I also had some issue, when some include was missing. Compilation was fine, but the computation was run-time only. Would be great to somehow handle this problem. It's really tricky to understand, why it doesn't work as expected. Debugging: Guess, in this matter, there is still no much progress. I tried Hana with MetaShell and TempLight, but, although, it was way better experience, it still was hard to debug the library. What about run-time algorithms? I haven't checked how hard it is to debug them, but I suspect it will be the same story as with STL, unless some magic is happening in HANA under the hood? * Documentation Documentation is really impressive. Honestly, love the search button! Would like to see more copy/paste examples tho. I'm really inpatient sometimes and when have to find part of the example at one place and figure out includes I do get easily annoyed. Related to that, would be great to always see which file has to be included for anything which is not included by `boost/hana.hpp`. As already mentioned, would be better to use hana::... instead of having an assumption for `using namespace boost::hana`. I would also add some tutorial for less experienced users with explanations what the monad is and how functional programming concepts are applied in Hana. * Tests Impressive unit tests collection. Unfortunately, they are not that easy to follow. Approach like: // check a { } // check b { } is not the best and I would encourage to add separate tests for both cases. Would be great to have CI tests for run-time performance. I have seen charts, but the build could break when performance degradation occurred. * Usefulness With C++11/C++14/C++17 template metaprogramming become a lot easier and a a lot of stuff might be written without need of TMP library at all. However, Hana is more than that, and I find it very useful. MPL and Fusions are/were extremely helpful and Hana is a huge step forward. *Frankly speaking, I would replace `std::tuple` with `hana::tuple` straight away.* - Did you attempt to use the library? If so: * Which compiler(s) Clang 3.6/Clang 3.7 + libc++ (on linux/mac/windows) -> worked fine Tried on GCC-5.1 (on linux) without any success -> didn't link, but this issue is well known already Tried on MSVC 2015-RC (just for a sake of trying -> didn't work ;) * What was the experience? Any problems? I haven't experienced any blockers whilst trying the library. The only problem for me, is lack of support for MSVC. A lot of commercial projects requires MSVC as much as Clang/GCC. - How much effort did you put into your evaluation of the review? I have been watching/trying Hana since April last year when I started to implement C++14 version of proposed boost.di library. I tried to re-implement C++03 version using Hana, but back then, Hana was crashing very often. Therefore, I decided to use plain C++14 features instead. I also went through all the source code/documentation/examples as well as played with the library. Thanks Louis for a great library! Kris

4 6

[type_traits] Another big update in develop
by John Maddock 20 Jun '15

20 Jun '15

Just a heads up in case it causes any issues: type_traits has had another big update in develop - added several new traits is_constructible, is_assignable etc which were needed to fix bugs in other traits - and changed most of the has_nothrow and has_trivial traits to make use of these. Also added more test cases to cover the issues where these were defective before. Please do let me know if you spot any unexpected breakages. John.

3 6

[hana] some notes, not a review
by Phil Endecott 20 Jun '15

20 Jun '15

Dear All, I have just a couple of notes about Hana; this does not constitute a review: Firstly, as I understand it Hana believes that it can replace much or all of what Fusion and MPL provide with a superior alternative. If that is the case, I suggest that the docs should not start out by describing Hana with reference to those libraries. At present, it would seem that in order to understand what Hana can do for me, I need to first learn at least a little about those other libraries - and then the Hana docs tell me how it compares to them. This might not be a bad thing in the context of docs for this review, but for "end user" documentation it should stand alone. Secondly, we're moving towards a future where a lot of what previously required TMP can now be done using "regular" C++ code qualified with constexpr. I've just replaced a fair chunk of my crufty old TMP code with constexpr and it is like a breath of fresh air. Against that background, it might be worthwhile to structure your examples by showing what Hana (and TMP in general, perhaps) can do that constexpr cannot do, i.e. start with an example using constexpr and extend it to add features not possible with constexpr. Regards, Phil.

6 6

Help with the wandbox online C++ compiler REST API please
by Niall Douglas 19 Jun '15

19 Jun '15

Dear Boost, I've been trying to get Krzysztof's wandbox script turning into a generic set of reusable tools for the Best Practices Handbook (specifically some Python which will generate a standalone single header include from any library, and generic scripting which can reduce that single header include to the smallest possible representation), but I have a problem which I have failed to surmount, so any advice most gratefully received: ned@jenkins64:~/boost.afio$ ./send_to_wandbox.sh + json_wandbox send_to_wandbox.cpp afio_single_include.hpp + echo -e -n '{ "code" : ' + json_escape send_to_wandbox.cpp + cat send_to_wandbox.cpp + python -c 'import json,sys,codecs; sys.stdout.write(json.dumps(codecs.getreader("ISO-8859-1")(sys.stdin). read()))' + echo -e -n ', "codes": [ { "file": "afio_single_include.hpp", "code": ' + json_escape afio_single_include.hpp + cat afio_single_include.hpp + python -c 'import json,sys,codecs; sys.stdout.write(json.dumps(codecs.getreader("ISO-8859-1")(sys.stdin). read()))' + echo -e '}], "options": "warning,boost-1.58,c++14", "compiler": "clang-head", "save": true }' + curl -v -F json_file=(a)json_input.json http://melpon.org/wandbox/api/compile.json * Hostname was NOT found in DNS cache * Trying 49.212.130.73... * Connected to melpon.org (49.212.130.73) port 80 (#0) > POST /wandbox/api/compile.json HTTP/1.1 > User-Agent: curl/7.35.0 > Host: melpon.org > Accept: */* > Content-Length: 243073 > Expect: 100-continue > Content-Type: multipart/form-data; boundary=------------------------c58a2396982a31f8 > < HTTP/1.1 100 Continue < HTTP/1.1 500 Internal Server Error * Server nginx/1.9.0 is not blacklisted < Server: nginx/1.9.0 < Date: Thu, 18 Jun 2015 23:56:48 GMT < Content-Type: text/html; charset=utf-8 < Transfer-Encoding: chunked < Connection: keep-alive < Status: 500 Internal Server Error < X-Powered-By: CppCMS/1.0.4 * HTTP error before end of send, stop sending < <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>500 — Internal Server Error</title> </head> <body> <h1>500 — Internal Server Error</h1> </body> </html> * Closing connection 0 + [[ '' != '' ]] + echo ned@jenkins64:~/boost.afio$ Whatever I do, I get Internal Server Error from wandbox. Yet copying and pasting the files manually into the web UI works as expected. I am stumped. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 3

[Better Enums] Non-integral underlying types
by Anton Bachin 18 Jun '15

18 Jun '15

About a week ago, I generalized Better Enums somewhat to accept non-integral underlying types, with some conditions and restrictions. I’d like to ask for comments/opinions/ideas on this feature. I made a little write-up on it [1], but I will summarize here as well. The write-up is a superset of the content of this message, so don’t read the message if you click the link :) If you have a literal type “foo”, you can do: ENUM(SomeEnum, foo, A, B = 2, C = foo(…)) SomeEnum value = SomeEnum::A; switch(value) { case SomeEnum::A: // … case SomeEnum::B: // … case SomeEnum::C: // ... } The switch above can have its cases checked for exhaustiveness by the compiler. Also, “value” above behaves like a “container” for one value of type foo, whose members can be accessed using operator ->. So, basically, you can have enumerated, reasonably type-safe sets of arbitrary literal types. The catch is that you have to provide an invertible mapping from foo into some underlying integral type, which mapping is declared either by equipping foo with the right constructor and conversion operator, or specializing a traits template. I would love to make a default implementation for this mapping, but it seems like I need to achieve the effect of a reinterpret_cast at compile time, and I haven’t been able to do so. [1]: http://aantron.github.io/better-enums/GeneralUnderlyingTypes.html

1 0

Making lots of compile FAIL tests
by Paul A. Bristow 18 Jun '15

18 Jun '15

I've started to devise some tests to ensure that things that really should not compile, do in fact compile-fail. So far I've produced a few files with a single statement that should fail inside a int main(){}. But it's looking at though it will get pretty tedious pretty soon :-( (I see for example that Boost.Multiprecision has some 50-ish compile_fail items) Is there some slicker way of doing this? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

3 3

Re: [boost] [Boost-announce] [Boost] [Hana] Formal review for Hana next week (June 10th)
by Glen Fernandes 17 Jun '15

17 Jun '15

[Correction: 10th June is a Wednesdsay, not Monday.] Dear Boost community, The formal review of Louis Dionne's Hana library starts Wednesday, 10th June and ends on 24th June. Hana is a header-only library for C++ metaprogramming that provides facilities for computations on both types and values. It provides a superset of the functionality provided by Boost.MPL and Boost.Fusion but with more expressiveness, faster compilation times, and faster (or equal) run times. To dive right in to examples, please see the Quick start section of the library's documentation: http://ldionne.com/hana/index.html#tutorial-quickstart Hana makes use of C++14 language features and thus requires a C++14 conforming compiler. It is recommended you evaluate it with clang 3.5 or higher.[1] Hana's source code is available on Github: https://github.com/ldionne/hana Full documentation is also viewable on Github: http://ldionne.github.io/hana To read the documentation offline: git clone http://github.com/ldionne/hana --branch=gh-pages doc/gh-pages For a gentle introduction to Hana, please see: 1. C++Now 2015: http://ldionne.github.io/hana-cppnow-2015 (slides) 2. C++Con 2014: https://youtu.be/L2SktfaJPuU (video) http://ldionne.github.io/hana-cppcon-2014 (slides) We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? [1] A note for Windows users: As mentioned, Hana requires a C++14 conforming compiler. If you would like to try it, a VM with Linux and clang 3.5 is a fairly painless option. Some users have also reported success with using Clang 3.5 on Windows. If you would like assistance configuring the former option, feel free to reach out to us for this. Best, Glen

4 4

[Hana] Migrating sqlpp11 to Hana (hypothetically)
by Roland Bock 17 Jun '15

17 Jun '15

Hi Louis, First of all: Hats off to you, your library and the documentation! I wanted to play with Hana for quite some time now. The review certainly offers a good reason to do so :-) Here's my test project: In sqlpp11 [1], lets assume I wanted to replace my own implementations of * compile time strings * type sets * functions like any/all/none with something from Hana. _Compile__time strings:_ This one seems easy. There probably won't be a C++14 version of sqlpp11, but there will be a C++17 version, hopefully allowing me to use the string literal without relying on a non-standard compiler extension. This is what I currently have [2]: struct _alias_t { static constexpr const char _literal[] = "delta"; using _name_t = sqlpp::make_char_sequence<sizeof(_literal), _literal>; }; This is what I would like to do: struct _alias_t { using _name_t = decltype("delta"_s); }; But the whole thing is in a header. * I do not want to "using namespace ::boost::hana::literals" at top-level or in one of the namespaces in the header. * Neither one of the following lines is valid: o using _name_t = decltype(::boost::hana::operator"_s"("delta")); o using _name_t = decltype("delta"::boost::hana::literals::operator"_s"); o using _name_t = decltype("delta"::boost::hana::literals::operator""_s); Is there a valid version? Obviously, I would also be happy with something like using _name_t = decltype(ct_string("delta")); * I also cannot use the BOOST_HANA_STRING macro, btw, because that would be a lambda in a decltype... I want to gradually migrate to Hana, so I'd really like to use a type here, not a variable. But I could not even use a variable, because the following does not compile (clang-3.5.1) struct A { static constexpr auto hana_name = BOOST_HANA_STRING("cheesecake"); }; Any hints? _ _ _type sets:_ Currently I store a bunch of types in type sets to do all kinds of tests at compile time. My type set code will need some cleanup or replacement one fine day. Hana to the rescue... Er, wait a second. There is no type set, or is there? There is a set for objects (which might represent types). Replacing all those types with objects would take some time, but I could live with that, I guess. But then I would have to replace all my type_sets (which are types themselves) with static constexpr objects, which use tons of constexpr template variables. And there are other constructs which use the types I now have replaced with objects. So I would have to adjust them, too, probably turning even more types into objects. Can I be sure (given today's compilers) that all these objects stay away from the generated binary? Also, I did not find some of the methods I would expect for sets: * Create a joined set * Create an intersect set * Create a difference set * Test if two sets are disjunct * Test if A is a subset of B, no, strike that, just found it in Searchable I probably could create the methods above with just a few lines of code using the available functions. But it would be convenient to have them available, of course (or did I just miss them?). By the way, I guess it would be easy for you to compile a list of available methods for each type, e.g. Set. Such a mini-index would be quite helpful IMO. _any/all/none: _Quite a bit of code is tuned to stuff like std::is_same: a type that contains a value (true or false). My current versions of any/all/none work like that, too. If I wanted to get rid of my own versions, could I use a drop-in from hana? Or would I have to write something like template<bool... B> struct my_all { static constexpr bool value = ::boost::hana::all(::boost::hana::make_tuple(B...)); }; ? _Intermediate summary:_ * I am not sure if I could replace my current compile-time string yet * I would like to have a few more convenience methods for Set. * It seems to me like if I wanted to use Hana, I should switch to Hana-style completely. Otherwise it will just be a weird mixture. Best, Roland [1]: https://github.com/rbock/sqlpp11 [2]: https://github.com/rbock/sqlpp11/blob/master/tests/Sample.h#L14-L17

4 9

[Boost] [Hana] Announcing Hana's formal review next week (June 10th)
by Fletcher, John P 17 Jun '15

17 Jun '15

Here is my review and some comments. > We encourage your participation in this review. At a minimum, kindly > state: > - Whether you believe the library should be accepted into Boost Yes please > - Your name John Fletcher > - Your knowledge of the problem domain. I have been working for some years on functional programming in C++. This is mainly run time work, but it inevitably has involved a lot of work on compile time issues as well. I am also involved in the maintenance of Boost Phoenix. Currently I mainly work to be C++03 compatible, but have done work on C++11 variadics. I am learning from this review how some of the features of C++14 can be deployed to advantage. > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design I have not dug into the Hana code. Instead I have been attempting to adapt its code to work with some of my current examples. It seems to me to be consistent in its approach. > * Implementation I have not found any problems at all with the implementation. > * Documentation It is not always clear exactly which headers are needed for any given example from the manual. It is necessary to look at the example codes. I would like more information about some topics, e.g. monads and comonads. * Tests I have been adapting some of the tests to run with other codes. In particular I have been working with Boost Phoenix and Boost Bimap without any problems once the namespaces are adjusted. * Usefulness I think it is a very useful code for someone attempting to implement a higher level library. There are several things which can be done very easily with it and I am only scratching the surface at the moment. One example is to be able to detect a member function name() in a struct: auto has_name = hana::is_valid([](auto&& obj) -> decltype(obj.name()) { }); and then to be able to print the name if it is present, or do something sensible. // I want to output the name from name() if it is present. template <typename F> std::string print_name(F const& f) { if (has_name(f)) std::cout << "has_name(f) true : "; else std::cout << "has_name(f) false : "; return hana::if_(has_name(f), [](auto& x) { return x.name(); }, [](auto& x) { return std::string("no_name"); } )(f); } > - Did you attempt to use the library? YES > If so: > * Which compiler(s)? Clang 3.5 and 3.6 with libc++ running on Ubuntu 12.04 > * What was the experience? Any problems? No > - How much effort did you put into your evaluation of the review? I have spent some hours implementing examples and running them. John Fletcher _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

boost [fusion]: tests failing in develop branch
by Aparna Kumta 17 Jun '15

17 Jun '15

Several regression tests for develop branch fail today. http://www.boost.org/development/tests/develop/developer/output/oracle-spar… "../libs/fusion/test/algorithm/copy.cpp", line 8: Error: Could not open include file<boost/fusion/container/vector/vector.hpp>. "../libs/fusion/test/algorithm/copy.cpp", line 9: Error: Could not open include file<boost/fusion/container/list/list.hpp>. Is this known? Thanks, Aparna

2 1

Boost::Filesystem
by Amit Kumar 16 Jun '15

16 Jun '15

Hi All Is there any functionality in boost::filesystem to identify local drives on Linux box. I want something similar to windows API *GetDriveType*(). Regards Amit

2 1

Preliminary submission of Boost Synapse
by Emil Dotchevski 16 Jun '15

16 Jun '15

I've made changes to Boost Synapse (a signal programming library) in part based on feedback I received on the Boost mailing list, and I've uploaded the updated source code and documentation to github: http://zajo.github.io/boost-synapse/. There is also a new tutorial: http://zajo.github.io/boost-synapse/Tutorial.html. I welcome more feedback. Thanks, Emil Dotchevski <http://www.revergestudios.com/reblog/index.php?n=ReCode>

2 4

[config] Using SD-6 macros
by Edward Diener 16 Jun '15

16 Jun '15

I realize I may be late to the discussion, but what is the reason why Boost.config does not use the SD-6 macro functionality as the first check for all C11 and C14 related configuration options ? Is it because Boost.config feels that the few current SD-6 implementations are buggy ? As I understand SD-6 the implementation of SD-6 itself can always be checked effortlessly by an #if defined(__SOME_SD6_MACRO) before attempting to use the functionality defined by SD-6, so for the majority of compilers which do not implement SD-6 functionality yet Boost.config can always and easily fall back on its current checks. But for those compilers which do implement SD-6 ( latest clang and gcc 5.1.0 ) surely using SD-6 is easier than the many clever ways which Boost.config currently finds out how compilers and standard libraries are configured.

9 33

Re: [boost] boost [fusion]: tests failing in develop branch
by Lee Clagett 16 Jun '15

16 Jun '15

On Tue, Jun 16, 2015 at 3:57 PM, Aparna Kumta <aparna.kumta(a)oracle.com> wrote: > Several regression tests for develop branch fail today. > > > http://www.boost.org/development/tests/develop/developer/output/oracle-spar… > > "../libs/fusion/test/algorithm/copy.cpp", line 8: Error: Could not open > include file<boost/fusion/container/vector/vector.hpp>. > "../libs/fusion/test/algorithm/copy.cpp", line 9: Error: Could not open > include file<boost/fusion/container/list/list.hpp>. > > Is this known? > > > Thanks, > > Aparna > > Yes, a pull request [1] was merged that was marked as a WIP. Another pull request [2] has already been made. The new pull request re-introduces those files - they were moved in [1], and [2] adds them back with new a new header that includes the original (now moved) files. Kohei Takahashi is eventually trying to replace the pre-processor based variadics with true variadics when compilers support it [3]. Joel or Kohei would have to provide more specifics on that effort, but it will be interesting if any compilation time improvements result (hopefully!). Lee [1] https://github.com/boostorg/fusion/pull/80 [2] https://github.com/boostorg/fusion/pull/81 [3] https://github.com/boostorg/fusion/pull/57

1 0