- Boost - lists.preview.boost.org

Re: [boost] [compute] Review period starts today December 15, 2014, ends on December 24, 2014
by Kyle Lutz 28 Dec '14

28 Dec '14

On Fri, Dec 19, 2014 at 1:07 PM, Thomas M <firespot71(a)gmail.com> wrote: > Dear all, > >> Review of the Compute library starts today > > Having spent the last 3 years on a larger-scale C++ project utilizing OpenCL > as main computing engine, without doubt a C++ GPGPU library is worthwhile. > My evaluation was based on studying the full docs, tutorial examples, > creating own (simple) applications, and inspecting selected implementation > details. Thanks for the review! I've addressed your comments in-line below: > I liked most the portable STL-like algorithms; combined with fairly > straightforward on-the-fly specifications of kernel functions (including > lambda expression support) GPGPU utilization becomes much more accessible > for every-day C++ programs. The design of this library part is rather clean > and aligns well with the C++ standard customs. I have checked a handful of > function interfaces and they correspond to the C++ STL variants. > > However I have also encountered a number of issues, of which I consider most > severe the overall library's design/aim: > > Khronos Group already provides (since years) a C++ bindings API itself > (https://www.khronos.org/registry/cl/specs/opencl-cplusplus-1.2.pdf) > Frankly the Khronos API is not an example of a clean, modern C++, but it > provides very fine-grained operations control (which can be crucial for > effective GPGPU performance), is developed (althouth a bit lagged) with > OpenCL itself, and covered in every elaborate OpenCL textbook. It is thus > IMHO the current de-facto C++ OpenCL wrapper standard. The proposed boost > library's parts core & utility (heavy in total!) seem to do just the same > interface-wise, yet lack some important features e.g. detailed control flow > (blocking / event setting), image classes, or deviate in subtle signature > details making it really difficult to grasp which does exactly what / > behaves differently. A boost library should not start from scratch but > integrate with and extend the Khronos API, both at C and C++ bindings level > (e.g. providing the STL-like algorithms to them in straightforward to use > manners). Programmers can thus rely on established practices (personally I > wouldn't switch away from the Khronos C++ API as main underlying workhorse!) > yet benefit from the extended functionality provided by the boost library. Can you give examples of where the OpenCL wrapper types in Boost.Compute are lacking? I am aware of the issue with image classes. While they do exist in Boost.Compute, their APIs are just not documented yet (though there are quite a few examples/tests which demonstrate their usage). I'll work on this. One particular issue that makes me hesitant is the lack of OpenCL 2.0 support in the "official" C++ bindings. The OpenCL 2.0 specification was released over a year ago (November 2013). The first public OpenCL 2.0 implementation was released by Intel three months ago (September 2014, followed closely by an AMD implementation). Boost.Compute had OpenCL 2.0 support implemented a week later. As of today (over a year since the specification was released), there is still no support for OpenCL 2.0 in the Khronos C++ OpenCL wrapper. I don't think it would be prudent to restrict Boost.Compute to a subset of the OpenCL API merely because of shortcomings in the "official" C++ wrapper. Other issues include lack of support for move-semantics (as well as various other C++11 features) and differing object sizes for wrapped types versus the OpenCL C API types (e.g. "sizeof(cl::Device) != sizeof(cl_device_id)" which prevents the ability to pass arrays of wrapped object types directly to C APIs). Overall I think implementing our own wrapper directly based on the C API reduces overall complexity (no workarounds for bugs/shortcomings in the C++ wrapper layer), allows us to fix bugs and issue updates quickly, and provides a more consistent and, IMHO, better API for OpenCL. Also, as they both just wrap the underlying OpenCL C API, interoperating between Boost.Compute wrapper types and the Khronos C++ wrapper types is trivial. If there are specific issues with the wrappers in Boost.Compute please submit a bug report [1]. > On the other hand to those rather new to OpenCL a simplified, less > error-prone design would be beneficial; equally this can raise the > productivity of everyone. The current design/implementation follows the > typical OpenCL execution model incl. some of its caveats (see tutorial > "Transforming Data"): explicitly copying input data to the device, executing > kernel(s), and then copying the output back to the host. Frequently however > the whole emphasis is on the kernel invocation (run an algorithm on the > data), rendering the copying an implementation detail that's "done because > it must be done" but otherwise makes code longer and comprises an error > source if forgotten. I have put much consideration into this and ultimately I don't feel it is right for the data-copying to be made implicit and hidden away from the user. I prefer the API which makes the memory copying operations and the host-device synchronization points explicit. These "under-the-hood" copy operations can be major sources of under-performing GPU-based applications and I don't think insulating the programmer from them makes the situation better. In any case, there is a simplified, high-level API available in Boost.Compute which allows kernels to directly operate on host memory. See the mapped_view class [2]. > I hence wonder if the following overall design would be more appropriate > (this is by no means a request to doing it this way, I just try to bring in > alternative perspectives): > > 1) build on top the Khronos C / C++ bindings API, i.e. use that as base > instead of the own core + utilities parts > 2) offering a high-level interface for algorithm execution that exposes > users to as little OpenCL internals as possible while giving the algorithms > lots of flexibility > 3) offering a high-level interface that auto-connects STL-containers with > OpenCL memory objects, implemented based on standard C++ / Khronos API > classes. > 4) offering a high-level interface that applies the algorithms directly to > objects of the Khronos C / C++ API. > > > The first point is rather obvious. To me the proposed library parts core + > utility appear as just another C++ wrapper, and unless this is done in > extremely (!!!) well manner (i.e. offering every functionality the Khronos > API does, yet making it clean from scratch, aligning it with Standard C++, > extending it by essential features etc., ensuring a rock-solid quality > control for reliability etc.; I'd set the bar really high here) I see no > reason to do it. If people are forced to use the proposed library core > wrapper just to gain access to the other functionality (and there is good > other functionality in there !) then I think there is a serious risk that a > considerable number of people simply turn away altogether. Well I would question the premise that the Khronos C++ wrapper is done in an "extremely well manner" and has "rock-solid quality" ;-). Could you let me know what parts of the core wrapper API fail to meet your bar for quality? > With respect to the second point I suppose something like that is doable: > > // BEGIN > > compute::gpgpu_engine gpgpuEngine; // default initialization links it to a > default device etc. > > // create vector, fill with data - ordinary C++ > std::vector<float> vec(10000); > std::generate(vec.begin(), vec.end(), rand); > > compute::transform(vec.begin(), > vec.end(), > vec.begin(), > compute::sqrt<float>(), > gpgpuEngine); > > std::cout << vec[0]; // results are already on the host > > // END > > So an instance of gpgpu_engine (or whatever name) gets setup once and can, > if needed, become customized for its behaviour (devices used, execution > policies etc.). This engine can then internally (hidden to the user, like a > std::vector manages it's memory) manage buffers, and when transform now gets > invoked it: > -) copies the data to one of its buffers (create one if none available) > -) run the kernel > -) copies the data to the host side container (keep buffer for reuse later) > > This would bring several advantages: > -) the code becomes very similar to ordinary C++ code -> short-handed, less > error-prone > -) buffers can be recycled among multiple algorithm calls (e.g. the engine > can cache a small number of buffers immediately available for future calls) > -) more efficient OpenCL runtime utilization (performance) because the whole > operation sequence has been abstracted: e.g. the input copy operation can be > enqueued in a non-blocking fashion, so the data transfer to the device and > the boost.compute kernel preparation can occur concurrently; equally while > the kernel runs the copy-back-to-host command can already become enqueued. > -) gpgpu_engine can encapsulate a number of policies that control its > behaviour (providing sensible default-configurations but allowing > fine-grained control if desired), e.g.: error handling (e.g. throwing > exception vs. setting some plain-odd OpenCL error codes); device to execute > on (if multiple available); copying back to the host in non-blocking manner > (like copy_async); to allow the selection of a 'smart' execution path (for > example if the input data do not warrant the overhead of a GPU call [e.g. if > they are too small or do not well fit GPU computation problems] defer the > call a plain STL-algorithm call or use OpenCL's built-in native C++ calling > threading functionality); etc. It would be beneficial if those options can > become temporarily overwritten (something like the boost::ios_..._saver > classes come to mind). > > > With respect to the third point I am thinking of something along the lines > of: > > template <class T, ... policies etc for both std::vector and cl::Buffer> > class vector_buffer > { > > private: > std::vector<T,...> vec; > cl::Buffer buf; > }; > > the class ensures that the std::vector and the buffer are automatically > synchronized whenever changes must become transparent (i.e. access). > Obviously this requires some thought if get functions grant access to the > plain std::vector / cl_mem/cl::Buffer; however for the present > implementation I also don't see what would stop me from hijacking a cl_mem > from a compute::vector and modify the buffer arbitrarily outside the > compute::vector class. These are definitely ideas I've thought about and these kinds of tools could all be built upon the current API. I've played around with basically a "kernel functor" abstraction which provides a class with the regular C++ "operator()(Args...)" function which stores internally an OpenCL kernel along with a command queue and any buffers it needs. This would then provide a simple, pure C++ interface for executing functions on the GPU that looks just like a normal C++ function call. I'd be very interested in pursing this more. > For 4) I am thinking of overloads for the algorithm to +- directly accept > Khronos C / C++ objects. Some really light-weight adapters adding e.g. > required type + size data could do the trick. This is fairly trivial. I have a patch in the works which would allow the Khronos C++ types to be passed anywhere that Boost.Compute wrapper types are used to make this all virtually transparent to the user. > In general I'd find it useful that all of a host object, a device object and > something linking a host with a device object can be an input / output of an > algorithm, and the implementation takes care of automatic data transfer. So > if the input refers to a host object the implementation automatically copies > the data to the device, if the output is a host object it also automatically > copies the result to it etc. See my response above, I'm not a huge fan of these automatic data transfer abstractions. However, I could be in favor of offering this functionality in a higher-level API. > A final but probably very important design consideration: > I wonder if boost needs a OpenCL-computing library, or a general > parallelization library. Presently the GPGPU world is already split too much > between CUDA and OpenCL as main players (hardware vendors doing their parts > ...), and technology is really rapidly moving (APUs etc.). > As Hartmut has already pointed out one approach could be to use the current > proposal as foundation for a parallelization implementation: cut it down to > the essentials of that and hide as much OpenCL implementation details as > possible. > A completely different approach could be to try coming up with a unifying > parallelization framework that supports multiple backends (OpenCL, CUDA, > others). Obviously this would be a tremendous amount of work (and getting > that API right is probably extremely difficult - the last thing we'd need is > just another restricted API causing more splitting) but in the long run > could be the more rewarding solution. I think developing a unifying parallel framework which can intelligently dispatch algorithms to multiple back-ends is outside the scope of Boost.Compute (and seemingly much more in the remit of the proposed C++ Parallelism TS). I think OpenCL is more than sufficient for running code efficiently across a variety of parallel hardware including GPUs, multi-core CPUs, FPGAs and various other accelerators which is why I chose it to build Boost.Compute on top of (along with it being cross-platform and an open-standard). > Implementation details: > > I have checked the implementation only briefly, mostly only when questions > arose for a few functions. Overall it looks ok and organized, yet I have > encountered some issues. > > 1) type safety [major issue - must be fixed before acceptance]: > Type safety is not a strength of OpenCL, and this is reflected at parts in > the implementation when it fails to add a proper conversion/protection > layer. Using compute::reduce it was embarrassingly easy to produce rubbish > results through the following code (modifying the provided tutorial code) : > > // BEGIN > > compute::device device = compute::system::default_device(); > compute::context context(device); > compute::command_queue queue(context, device); > > // generate random data on the host - type is float > std::vector<float> host_vector(10000); > std::generate(host_vector.begin(), host_vector.end(), rand); > > // create a vector on the device > compute::vector<float> device_vector(host_vector.size(), context); > > // transfer data from the host to the device > compute::copy(host_vector.begin(), host_vector.end(), device_vector.begin(), > queue); > > double reduction_result = 0.0; // result is of type double > compute::reduce(device_vector.begin(), device_vector.end(), > &reduction_result, queue); > std::cout << "result: " << reduction_result<< std::endl; > > // END > > The input data is of type float while the result shall be stored in a > double. This fails miserably under the current implementation because after > the reduction has completed the final value stored in device memory gets > copied merely byte-wise to the target variable (using a plain type-ignorant > clEnqueueReadBuffer), reading simply the 4 bytes from a float into an 8 byte > double (4/8 on my PC machine). I suppose reversing types (double as input, > float as output) will be even more spectacular because 4 superfluous bytes > simply overwrite the stack. > > The same affects a plain compute::copy, for example if above the > device_vector is of type double: > > // BEGIN > > // generate random data on the host - type is float > std::vector<float> host_vector(10000); > std::generate(host_vector.begin(), host_vector.end(), rand); > > // create a vector on the device - type is double > compute::vector<double> device_vector(host_vector.size(), context); > > // transfer data from the host to the device > compute::copy(host_vector.begin(), host_vector.end(), device_vector.begin(), > queue); > > // END > > it equally makes pang because the data are just copied byte-wise. > > The library must provide a strict type-safety for all algorithms / data > structures, where (in order of preference that comes to mind): > a) convert properly to target type if possible (above surely applicable) > b) issue compile-time error if conversions not possible > c) last fallback: throw a proper exception at runtime Thanks for providing these tests cases. I'll work on improving type-checking and error-reporting. If possible, could you submit these as bug reports to the issue tracker [1]? > 2) when inspecting the code flow in above copy operation I missed a debug > mode check that for a copy operation the output range can hold that many > elements; something like a safe iterator returned by device_vector.begin() > -> a good implementation should throw an organized error instead of just > overwriting memory. This is a very good idea. I'll work on adding more assertions to verify these sorts of pre-conditions for the algorithms. > 3) for float/double input containers compute::accumulate falls back to a > plain serial reduction, making element-wise additions (which is really slow > on a GPU). This is because can_accumulate_with_reduce returns false as it is > not defined for integral types. Is there a technical reason why it cannot > work for floating types? How many algorithms are affected by a possible > fallback to a plain serial execution order? Because floating-point addition is not associative. Doing this would lead to accumulate() producing different results on the device versus the host. If the user is willing to trade performance for accuracy, they can call the reduce() algorithm directly. However, I don't think Boost.Compute should make this call universally and thus it is left up to the user to decide. I think this is documented in the accumulate() function, I'll look into making it more clear. > 4) for types not supported under both OpenCL and C++ (e.g. long double, > bool, half) more specific error messages would be useful. Noted, I'll work on producing better error messages for unsupported types/operations. > Note: above are listed only issues which I have encountered during my few > trials; there's no claim whatsoever for complete coverage > > > Performance: > > I have not really tested performance so I cannot say much on it. > At times I spotted what appears as unnecessary OpenCL runtime overhead (e.g. > blocking commands, resetting kernel arguments upon each invocation) but I am > not familiar enough with the implementation to judge if this really just > redundant. If you find any unnecessary blocking/synchronization please report it to the bug tracker [1] and we'll get it fixed. > Invoking the OpenCL compiler always takes considerable time for any OpenCL > program. The library compiles kernels on demand when encountered to execute; > while this is technically reasonable I am not sure in how far it is clear to > everyone (foremost end-users of programs) that e.g. a simply accumulate of > 100 ints may take several seconds to execute in total on first invocation > simply because the kernel compilation takes that time. I guess this > considerable penalty also somewhat discourages from using the library to > create a number of kernels on the fly. True, the run-time compilation model provided by OpenCL does have some associated overhead. There a few techniques in Boost.Compute which help mitigate this. The first is a run-time program cache which keeps built versions of commonly used kernels ready so that the compilation cost is only payed once per application run (see the program_cache class [3]). The other is support for offline-caching of program binaries. This is enabled by defining "BOOST_COMPUTE_USE_OFFLINE_CACHE" and causes Boost.Compute to cache binaries for programs so that they are only compiled once the very first time they are run on the system. I'll work on documenting the compilation-overhead issues as well as the caching functionality better. > I would find it very useful if smart algorithms dispatch the algorithm to a > plain C++ algorithm if it's really predictable that a GPU execution will > just waste time (I have elaborated on this above). It's fairly trivial to > have data/algorithm combinations that are better not executed on the GPU, > being able to rely on some auto-mechanism would relief programmers. I disagree, I think the call on whether to execute the algorithm on the host or on an accelerator (with its associated overhead) should be left up to the user (or potentially a higher-level API built on top of Boost.Compute). While I agree that this would a useful feature, I just don't think Boost.Compute is the right place for that logic to live. > Answers to reviewer questions: > > 1. What is your evaluation of the design? > > See comments above > > > 2. What is your evaluation of the implementation? > > See comments above > > > 3. Documentation: > > Overall I find the documentation well written and structured. As minor > issues at times it could be more explicit / elaborate (e.g. for > compute::vector a short description is provided, but for several other > containers there is none; what are the accepted types for predicates in the > algorithms etc.). Will do. > The installation page misses that (on Windows) the OpenCL headers must be > explicitly included (it leaves the impression that the library would do it > on it's own). Hmm, the Boost.Compute headers do "#include <CL/cl.h>" where it is required. Does this not work correctly for you? If possible, could you report a bug for this with a bit more information? > The performance page should include more details with respect to overhead > and specifically "unintuitive" ones such as kernel compilation time. > Recommendations can be given when a problem is / is not suitable for GPU > execution. It is unclear if the provided measurements refer to float or > double; measurements for both should be provided. Will do. > 4. Overall usefulness of the library > > I find the portable STL-ish algorithms (+ their supplements) useful. With > respect to the core + utilities parts I think unnecessary competition with > existent wrappers is introduced. > > > 5. Did you try to use the library? > > I used MSVC 12 and had no problems installing it and running a few little > programs. > > > 6. How much effort did you put into your evaluation? > > I read the documentation, ran tutorial code and created a few example > programs on my own (I did not run any of the pre-packaged examples). When > questions arose I took close looks at the implementation (thus I focused > more on in-depth analyses of selected components instead of testing overall > into breadth). > > > 7. Are you knowledgeable about the problem domain? > > I consider myself knowledgeable of the problem domain. > > > 8. The core question: Do you think the library should be accepted as a Boost > library? > > Generally speaking yes but I recommend a major revision before acceptance is > reconsidered. My greatest concern revolves around the overall design aim. I > don't like the idea of competing with the Khronos API for general wrapping; > I'd prefer a more light-weight library with the STL-ish algorithms (or other > things) at the core, adding to what is already out there. The library needs > to find its own niche, minimizing overlap and elaborating on it's > novelty/strengths. The implementation must become more robust, presently it > is ways too trivial to break things. Thanks again for the review! There are lots of good ideas raised here. Let me know if you have any other feedback or if I can explain anything further/more clearly. -kyle [1] https://github.com/kylelutz/compute/issues [2] http://kylelutz.github.io/compute/boost/compute/mapped_view.html [3] http://kylelutz.github.io/compute/boost/compute/program_cache.html

7 16

[block_ptr] Region Based Memory Managment
by Phil Bouchard 27 Dec '14

27 Dec '14

Greetings Boost, I was talking to Filip Pizlo from the Webkit community and he pointed out that block_ptr is what we call a Region Based Memory Manager: http://en.wikipedia.org/wiki/Region-based_memory_management If we consider the worse case scenario, the sets (regions) can be unified to create a really big set. So to make block_ptr hybrid we could add a "garbage collection layer" to detect cycles inside a set that is not yet destructed. This function could be called explicitly whenever some memory usage quota is reached. It's very easy to implement. There is no other way to efficiently manage memory. Regards, -Phil

1 2

[test] Applying outstanding pull requests to develop and schedule merge of develop to master
by Jamie Allsop 26 Dec '14

26 Dec '14

Some time ago (more than 2 years) I submitted a set of four complimentary patches for Boost.Test of which one was partially applied. The tickets are: * Test Units (Cases and Suites) in Boost.Test do not capture __FILE__ and __LINE__ at declaration point making it impossible to provide source file linking using external test management tools https://svn.boost.org/trac/boost/ticket/7410 (modified patch applied) * Boost.Test, since boost 1.48 is using the deprecated Boost.Timer class - it should be updated to use the new class https://svn.boost.org/trac/boost/ticket/7397 https://github.com/boostorg/test/pull/15 * Detailed test status is not available in the Boost.Test log (status, assertions, passed) and so live test case status cannot be tracked https://svn.boost.org/trac/boost/ticket/7417 https://github.com/boostorg/test/pull/16 * Support multiple calls to framework::init() allowing wrappers to support running tests using test tools in full systems https://svn.boost.org/trac/boost/ticket/7419 https://github.com/boostorg/test/pull/17 I've updated and resubmitted patches on more than one occasion and also variously created patches against (the now) develop and master so I can actually apply them for myself for each new boost version. Now, the reason for my post is two-fold. First - I'd like to see these patches applied. They cause no user impacts and simply (a) fix broken functionality and (b) *significantly* improve the usefulness of Boost.Test. I am more than happy to help with maintaining Boost.Test since we rely on it heavily and I believe, on the whole it is a good library. Second - it is about time we formulated a schedule for merging develop into master for Boost.Test. Otherwise all the patches in the world are simply pointless. The patches I've submitted, like others will never see the light of day even if they are applied because develop is very different than master and it looks like a merge may never happen. It should be noted that for my patches I have a completely different set that I apply to an actual Boost release because of the large differences between the two branches. To recap - it is time to start actively shepherding patches into Boost.Test develop, but more importantly, it is time we started looking at a schedule for merging Boost.Test develop to master. The longer it is left the worse the impact will be. A lot of good work has been done on develop - the longer it stays there the more people will move away from Boost.Test in their own code and it will only have relevance to Boost libraries themselves. Jamie

3 6

[Test] Command line option --list_content
by Andreas Noll 26 Dec '14

26 Dec '14

Hi everyone, Within our company we heavily use Boost.Test. We use Visual Studio and have written an Visual Studio extension to show all test suites and test cases of a given test executable. This allows our developers to run all tests or only parts of them. This is necessary because we have some lengthy running tests - one could say they are more integration tests than unit tests. What we have to do currently is patching the Boost.Test code to add a command line switch to output a test executable's contents to stdout. The output shows the hierarchy of test suites and test cases and is consumed by our Visual Studio extension. As I have recognized, our patch seems to cover the same functionality as the --list_content switch that already exists in the trunk version of Boost.Test. We would really appreciate that --list_content becomes part of the official boost releases to make our patch obsolete. My questions: 1. What are the reason(s) why-list_content is not (yet) added to the release? Is there any schedule for its release? 2. Is there any way how we can help with that issue? I'm new to the community but maybe there is something our team or me can do to get the feature released. Best regards, Andreas Noll

2 1

[compute] kernels as strings impairs readability and maintainability
by Mathias Gaunard 25 Dec '14

25 Dec '14

Hi, While reading through the code of Boost.Compute to see what it does and how it does it, I often found that the approach used by the library of putting all OpenCL kernels inside of strings was an annoying limitation and made it quite difficult to reason with them, much less debug or maintain them. This has a negative effect on the effort needed to contribute to the library. Has separate compilation been considered? Put the OpenCL code into .cl files, and let the build system do whatever is needed to transform them into a form that can be executed. This would also make it easier to eventually provide a CUDA backend.

7 12

[core] [addressof.hpp] [addressof_test2.cpp] ISO C++ says that these are ambiguous
by Sergey Sprogis 25 Dec '14

25 Dec '14

It looks like he following code fragment from boost/core/addressof.hpp (latest trunk version) violates ISO C++ overloading rules: template<class T> struct addressof_impl { static BOOST_FORCEINLINE T * f( T & v, long ) { return reinterpret_cast<T*>( &const_cast<char&>(reinterpret_cast<const volatile char &>(v))); } static BOOST_FORCEINLINE T * f( T * v, int ) { return v; } }; As a result, libs/core/test/addressof_test2.cpp fails to compile with Oracle Studio 12.4 C++ compiler while gcc-4.8.2 produces just warning here. It's easy to reproduce that behavior of both compilers with 26 lines test case listed below: gcc -c t.cc t.cc:7:33: warning: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: [enabled by default] return addressof_impl<T>::f(v,0); ^ CC -c t.cc "t.cc", line 7: Error: Overloading ambiguity between "static addressof_impl<convertible2>::f(convertible2&, long)" and "static addressof_impl<convertible2>::f(convertible2*, int)". t.cc ==================================== template<class T> struct addressof_impl{ static T *f(T &v,long){} static T *f(T *v,int){} }; template<class T> T *addressof(T &v){ return addressof_impl<T>::f(v,0); } template<class T> void scalar_test(T* =0){ T *px=new T(); T &x =*px; (addressof(x)==px)? 1 : 0; } class convertible{ public: convertible(int=0){} }; class convertible2{ public: convertible2(int=0){} operator convertible2 *()const{ return 0; } }; void foo(){ scalar_test<convertible>(); scalar_test<convertible2>(); } ============================== It would be nice if boost/core/addressof.hpp file will be changed somehow to fit the proper ISO C++ requirements. Sergey

3 2

[compute] Some questions
by Andrey Semashev 23 Dec '14

23 Dec '14

Hi, I have no experience with OpenCL or GPU computing in general, so bear with me if my questions sound silly. I have a few questions regarding Boost.Compute: 1. When you define a kernel (e.g. with the BOOST_COMPUTE_FUNCTION macro), is this kernel supposed to be in C? Can it reference global (namespace scope) objects and other functions? Other kernels? 2. When is the kernel compiled and uploaded to the device? Is it possible to cache and reuse the compiled kernel? 3. Why is the library not thread-safe by default? I'd say, we're long past single-threaded systems now, and having to always define the config macro is a nuisance. 4. Is it possible to upload the data to process to the device's local memroy from a user-provided buffer, without copying it to boost::compute::vector? Same for downloading. What I'd like to do is move some of data processing to the GPU while the rest is performed on the CPU (possibly with other libraries), and avoid excessive copying. 5. Is it possible to pass buffers in the device-local memory between different processes (on the CPU) without downloading/uploading data to/from the CPU memory? 6. Is it possible to discover device capabilities? E.g. the amount of local memory (total/used/free), execution units, vendor and device name? Thanks.

3 4

[compute] Review period extended till December 30 + sum up
by Antony Polukhin 23 Dec '14

23 Dec '14

Hi, Review period of Compute library extended till December 30. Some notes and answers to them that were pointed out during review so far: * Some of the algorithms could be tuned for a specific hardware - Library author is working on a auto-tuning solution and improves existing algos * Why OpenCL C API used instead of C++ API? - C++ API had issues, C API allows a bit more control. No C++ API for OpenCL 2.0 * API is not N4105 compatible, library is not N*** compatible - This could be easily fixed by a library that will use Compute as a backend * Some of the algorithms return futures while other work with command queues - This is because of the OpenCL design + async chains/futures would be probably added later * Not all the types of the Khronos API are supported - A few types are not documented yet, there's a patch in the works which would allow the Khronos C++ types to be passed into Compute algorithms * A few type related errors could be detected at compile time - This will be fixed, more asserts would be added to runtime only checkable places. Report issues to the tracker https://github.com/kylelutz/compute/issues * On small data sets CPU algorithm would work faster than a GPGPU. How about implicitly dispatching algo on CPU in those cases? - The call on whether to execute the algorithm should be left up to the user. While library author agrees that this would be a useful feature, he just don't think Compute is the right place for that logic. * How about providing way to do chains of async operations - This is a big task that will be solved some day. * How about providing Boost.ASIO like error handling via throw and error_code - Implementing an approach like ASIO's wouldn't be that difficult. Thanks to all the reviewers for spending their time and providing useful comments so far! -- Best regards, Antony Polukhin

1 0

[compute] Define user functions using lambda expressions
by Asbjørn 22 Dec '14

22 Dec '14

Hi, I'm probably missing something obvious, but how would I go about making a custom function using a lambda expression? Say I want to declare some function "sqr" which returns "_1 * _1", and then use this in a transform() lambda expression, ie transform(..., 2.0 * sqr(_1) - 3.0 * _1 + 5.0, ...); to evaluate 2x^2 - 3x + 5. If I try to use BOOST_COMPUTE_FUNCTION() I can't use the resulting function in a lambda expression it seems. Cheers - Asbjørn

2 2

[compute] some comments
by Mathias Gaunard 22 Dec '14

22 Dec '14

Hi, I do not know if I'll be doing a full review, but I have some comments from having skimmed through the code and documentation. From a quick glance, from all the algorithms that are supported, quite a few are not easy to implement with the OpenCL programming model efficiently. I think the documentation should say more about the implementation strategies of each algorithm, its complexity and how much it is parallelized.

2 1

[icl] insert_iterator and elements
by Jeff Flinn 22 Dec '14

22 Dec '14

interval_set has overloaded insert methods for both intervals and elements. Is there a reason there insert iterator lacks this ability. The line in the code below *itr = 4; fails to compile. This could be made to compile by: - adding an implicit constructor 'interval( const element& )' for the underlying (discrete) intervals, initializing to [element, element+1), or [element, element]. - adding an overloaded operator=( const element& ) - adding an element_insert_iterator class I've encountered 2 domains now where I need to construct an interval_set<int> from a range of ints. The most natural ways to accomplish this (for me) are: boost::copy( ints, inserter(int_interval_set) ); or boost::copy_range<int_interval_set>( ints ); Of course I can transform the incoming ints, but this seems a common enough usage pattern for the library to provide. Especially since the lack of this facility is asymmetric to the insert overloads of interval_set. #include <iostream> #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS #include <boost/icl/interval_set.hpp> #include <boost/range/algorithm/copy.hpp> int main() { typedef boost::icl::interval_set<int> IdSet; typedef IdSet::interval_type IdInterval; IdSet ids; ids.insert(3); boost::icl::insert_iterator<IdSet> itr(ids, ids.end()); *itr = IdInterval(1,2); //*itr = 4; //compile error no viable operator = boost::copy(ids, std::ostream_iterator<IdInterval>(std::cout)); std::cout << "\n"; return 0; }

1 0

[compute] review
by Pavan Yalamanchili 22 Dec '14

22 Dec '14

*Design and Implementation* The library provides an STL-like library for OpenCL devices. Although there are other libraries offering similar behavior, Boost.Compute is the most complete and the most generalized. The directory structure is well organized and easy to dig through to understand the implementation or debug an issue. Others have pointed out the existence of the OpenCL C++ wrapper and the fact that Compute library does not use it. Here are a few reasons why I think the author was *right* in his design decisions. - The C++ wrapper begins to look similar to the original OpenCL C interface once you start using it in a generalized fashion. - cl.hpp is monolithic (single file 12k+ LOC) and is not modular enough to only include the parts that you need. - Compute and cl.hpp have two different goals. The biggest selling point of Compute is the set of algorithms it supports not its C++ wrapper around OpenCL. Having said that, I think the Compute library might be better off with an additional interface that accepts the OpenCL-C++ wrapped objects. *Documentation* The documentation is comprehensive and the API is documented well. There are a few improvements that can be done. For example, the reference is at the bottom of the TOC and is hard to see immediately. The API reference in the TOC can also be expanded out a bit more to show the general categories of algorithms that are supported. *Potential Usefulness* It is fairly easy to transition from applications using vector algorithms in STL to Compute. The wide availability of OpenCL devices makes the library useful to a large user base. *Domain Knowledge* I am a developer of the ArrayFire library[1]. I am the lead engineer of a company that specializes in this domain. I consider myself to be fairly knowledgeable in this domain. *Experience with the library* ArrayFire depends on Boost.Compute for a few algorithms in our OpenCL backend. We explicitly and implicitly (via ArrayFire) test Boost.Compute on a variety of hardware / compilers / operating systems. Compilers and Operating systems we use: - gcc 4.8, 4.9 on various Linux distributions - clang 3.4 on OSX - Visual Studio 2013 on Windows. We have found some bugs through our usage that have been mostly resolved by the author or by patches sent by us. *Conclusion* The experience overall has been fairly positive. But there are certainly *some* rough edges that need resolving. An issue that will plague any OpenCL library is the performance portability across various devices. It would be nice if the author can talk about how he plans to eventually address this issue. Overall, Boost.Compute will be a great addition to Boost. But before it is accepted the following issues need to be addressed. - The tests need to be a bit more comprehensive. - Due to the general nature of OpenCL, there needs to be a list of "officially supported" devices. - Make sure all the tests are passing on the supported devices. *Links* [1] https://github.com/arrayfire/arrayfire

2 1

A Google Summer of Code Proposal(Boost C++)
by Mudit Sharma 22 Dec '14

22 Dec '14

Respected Sir, I have been studying the Boost C++ libraries.I see that there isn't any library for game development in Boost C++. I propose a new library for game development for Boost C++ under which I propose to use the pygame library of python.Make a Boost C++ analogue for pygame library of python.. *I would like to know if this can be taken as a GSoC'15 project?* Thanking You Mudit Sharma (Student,Pursuing Electronics And Communication Engg. At Delhi Technological University,Delhi,INDIA)

5 5

IDE for developing Boost
by Jens Müller 20 Dec '14

20 Dec '14

Hi, I am looking for recommendations for developing Boost, especially code in the graph library. At work, most developers (not for Boost, for some commercial software), most developers are using Eclipse. This works quite fine as soon as it has properly auto-discovered include paths etc. But before fiddling around with Eclipse to get all the settings right, I'd wanted to to ask for your recommendations. And maybe there are already settings available to make it "just work", at least initially. Cheers, Jens

16 22

[Phoenix] [Bug Fix] A fix for boost::bind compatiblity now on test.
by Fletcher, John P 20 Dec '14

20 Dec '14

For a long time there have been problems with some of the tests for Boost Phoenix compatibility with Boost Bind. These have shown up with recent compilers, gcc 4.9.0 and Clang 3.5 and 3.6. I have discovered that the problems were caused by incorrect overload resolution where some cases were being wrongly allocated. I have just uploaded a patch to develop which passes all tests with gcc 4.9.0 and I hope fixes this problem. The solution involves the use of boost::lazy_disable_if to reject the wrong functions from the overload set and allow them when they are needed. Tests affected are: bind_member_function_tests, bind_mf2_test, bind_test I have not traced a bug report which directly relates to this. I hope this helps. Please reply if there are any problems. Best wishes for the season. John Fletcher

1 0

pygame in boost C++
by Mudit Sharma 20 Dec '14

20 Dec '14

I have been studying the Boost C++ libraries.I see that there isn't any library for game development in Boost C++. I propose a new library for game development for Boost C++ under which I propose to use the pygame library of python.Make a Boost C++ analogue for pygame library of python.. *I would like to know if this can be taken as a GSoC'15 project?* Thanking You Mudit Sharma

1 0

Questions to help me determine export classification of Boost libraries
by Ben Fritz 20 Dec '14

20 Dec '14

Hello, list! One of the contractors I'm working with has delivered code to us that pulls in a few boost libraries. In order to release this code to our customer, I need to determine the Export Control Classification Number (ECCN) of the boost libraries. I see in the archives that someone has asked for the ECCN directly without success ( http://lists.boost.org/boost-users/2008/01/33241.php) so I'm currently trying to use a questionnaire put together by some of the export experts within my company to figure this out. If there is an ECCN already listed somewhere, please point me to it, otherwise I'll continue. I'm interested specifically in version 1.56.0 of the boost libraries. However, since I don't see any major additions or deletions in the 1.57.0 release notes, I assume the answers will apply to both versions. Apparently the export classification is primarily based on two things: 1. Does the library have anything specifically designed for military use? I'm assuming the answer to this is "no". Please correct me if I'm wrong. 2. Does the library include any strong encryption? This includes symmetric or asymmetric encryption with certain key lengths, cryptanalytic functions, intrusion detection, quantum cryptography, "reduce information-bearing signals" (not sure what that is), and other cryptographic technology. I looked through the list of libraries documented here: html/index.html <http://www.boost.org/doc/libs/1_57_0/libs/algorithm/doc/html/index.html> http://www.boost.org/doc/libs/?view=categorized >From the description of each library, I was mainly concerned with Boost.Algorithm, Boost.Asio, and Boost.Uuid. >From the documentation of Boost.Algorithm at http://www.boost.org/doc/libs/1_57_0/libs/algorithm/doc/ <http://www.boost.org/doc/libs/1_57_0/libs/algorithm/doc/html/index.html>, it looks like there is no encryption technology in the library. Can someone confirm? Boost.Asio contains some SSL interfaces, which undoubtedly contains encryption technology. However, according to http://www.boost.org/doc/libs/1_57_0/doc/html/boost_asio/overview/ssl.html these interfaces require OpenSSL to be used. Does this mean that the Boost.Asio library itself does not contain encryption, it only provides an interface to another library which does the encryption? I.e., is it a true statement, that Boost.Asio contains no encryption technology in either its source code or in the compiled binary, and that in order to use encryption I would need to link in a separate library? Boost.Uuid contains some cryptographic hash features. However, I understand that a cryptographic hash cannot by itself provide any message encryption, so I do not believe this should qualify. Is there anything I'm missing here? Does Boost.Uuid contain other technology that might qualify? Please also let me know if I missed any encryption in other Boost libraries, as I only looked at the library descriptions, and am not familiar with any of the library functionality. -- Ben Fritz

6 8

[RPC] Compile-time reflection for RPC and mocking
by Peter Bindels 19 Dec '14

19 Dec '14

Hi all, I've searched through the Boost mailing list history to find related emails and the last I found was from January where Oleg Labutin and Hartmut Kaiser discussed compile-time reflection in the context of RPC mechanisms. Based on Hartmut's speech last Saturday introducing HPX and explaining a bit about async/future/promise I tried to implement a simple RPC mechanism that uses then to decouple work and the result I have so far is very promising. I have a simple interface with a call that returns a future, and the caller does not distinguish between calling the actual object and calling on a proxy, as both return a future<T>. It does what the discussion mentions - serialize the name of the interface and function, as well as the arguments (basically the mangled name of the interface function) to ensure there are no mismatches. I would like to take this oppurtunity to propose two things: - I can work on this idea to work it out into a full RPC mechanism, to be proposed for Boost.RPC, if there is enough interest. Currently it uses macros to generate and wrap functions, and a simple serializer that serializes in the same way that Protobuf and Thrift also serialize. - Given a compile-time reflection method, the entire proxy class and dispatch class can be auto-generated from the interface class - the full code for registering an interface with the RPC mechanism would collapse to RPC::Register<T>(); To do so, it would need two language additions. It needs access to a compile-time iterator over functions and traits about the argument types, return type, name and whether it is a virtual function. For the prototype this can be manually generated for an interface to show it works. Additionally, it would need to be able to use such a definition to instantiate a virtual function from a base class - basically, hooking up an std::function<X> to a virtual function X directly. I think this is well-implementable (probably reusing most code from lambdas for the link code), but I don't know whether that's true. On the second note, I also proposed a Mock library a few years ago. This basically fell flat on the code that I suggested being very unsafe and using many hackish methods to mock functions. Using the compile-time reflection proposed for the second bullet I would be able to replace the entire hackishness from that with 100% compliant code, with only one minor regression in functionality. That should make it Boost-OK at least from a language standards perspective. Any ideas? Reactions on RPC or Mocking? Best regards, Peter Bindels

8 15

file_descriptor::read() docs?
by Olaf van der Spek 19 Dec '14

19 Dec '14

Hi, Where is file_descriptor::read() documented? Shouldn't it be at http://www.boost.org/doc/libs/1_57_0/libs/iostreams/doc/classes/file_descri… ? -- Olaf

2 3

[compute] Request to extend the review period till 30 December
by Antony Polukhin 19 Dec '14

19 Dec '14

Hi, Now, when the review of Compute library is going on, it seems that 10 days is not enough. Some of the Boost developers are on a vacations or do not have much free time right now. I've got a few personal requests to extend the review period. Library author agrees to extended review. 30 of December seems like a reasonable date for the last review day to both of us. Do the review wizards agree for extended review? -- Best regards, Antony Polukhin

2 1

[inteprocess] static analyzer results
by Gaetano Mendola 19 Dec '14

19 Dec '14

We have upgraded to use boost 1.55 and our static analyzer is telling us: interprocess/detail/win32_api.hpp: ~1145 if if(!SetSecurityDescriptorDacl(&sd, true, 0, false)) takes the true branch then sa.nLenght, sa.lpSecurityDescriptor, sa.bInheritHandle result in not initialized members. interprocess/sync/spin/recursive_mutex.hpp: CTOR at 71 leaves the m_s not initialized interprocess/mapped_region.hpp: ~341 boost::uintmax_t(mapping_size - (offset - page_offset)) > boost::uintmax_t( std::size_t(-1))) is always false

1 0

[compute] review
by Sebastian Schaetz 17 Dec '14

17 Dec '14

Hi, Here is my review of Boost.Compute: 1. What is your evaluation of the design? The library is based upon OpenCL, a cross-platform cross-device open standard that abstracts access to and provides a programming model for many-core vector co-processors such as GPUs. These co-processors are usually referred to as "devices". The library provides a wrapper layer around the OpenCL C interface. It skips the standard OpenCL C++ wrapper which I don't consider a problem because except for destructors there is no added value in using this wrapper. In my opinion Khronos should adopt Boost.Compute as their C++ layer for OpenCL. Boost.Compute provides compatibility with the OpenCL C interface through conversion operators that decay Boost.Compute types to their OpenCL C equivalents. This can be quite useful. On top of this wrapper Boost.Compute exhibits 3 core components: * types to interact with and issue commands to devices: these follow OpenCL concepts but are not necessary if defaults are used * means of managing memory (allocate, copy) on devices: this component contains also asynchronous operations which I consider essential in a library that deals with co-processors * a collection of parallel primitives and meta-functions with an STL interface: this components contains powerful iterators to combine containers and algorithms to implement more complex algorithms in an efficient manner One thing I'm not clear about is how asynchrony is handled. Command queues are exposed, issuing commands to different queues is a way to express concurrency. At the same time copy_async returns a future which is another way of exposing concurrency. It is out of the scope of Boost.Compute to solve the challenges of asynchronous/concurrent operations because it is a different and difficult topic not yet solved for C++ in general either, but at least the documentation should be more explicit about which commands are executed when, which commands are synchronous, which are asynchronous and what is the role of the command_queue in this regard. 2. What is your evaluation of the implementation? I did not evaluate the implementation in detail but looked at a few of the tricks Boost.Compute uses to generate kernels. The implementation of this part of the library is good and instructive. 3. What is your evaluation of the documentation? Boost.Compute documentation is of excellent quality. The recent addition of performance data is helpful. I could not find any documentation about fancy iterators, this should probably be added. Also, it would be great if the my questions regarding asynchrony/concurrency could be addressed in the documentation. 4. What is your evaluation of the potential usefulness of the library? Boost.Compute is extremely useful. With this library a developer familiar with the STL can utilize the processing power of GPUs without any knowledge of vector co-processor programming. The documentation shows that for large vector sizes, some Boost.Compute algorithms outperform the STL by an order of magnitude. 5. Did you try to use the library? With what compiler? Did you have any problems? I tried the unit-tests on a 8x GeForce Titan system without any problems and on a ARM Mali GPU with some unit tests failing. I'll be working with the library author to fix tcomp.lib.boost.develhe problems in these unit tests. I used gcc 4.8.2 for the tests on both GeForce and Mali. 6. How much effort did you put into your evaluation? A glance? Aquick reading? In-depth study? I reviewed the library a few months ago in-depth and reread the documentation for this review as well as ran some unit tests. 7. Are you knowledgeable about the problem domain? My job involves working with both CUDA and OpenCL. Furthermore I am the author of the Aura library [0] a similar, albeit lower level library for accelerator programming. 8. Do you think the library should be accepted as a Boost library? I think the library should be accepted into Boost. The interface is simple and easy to understand for non-experts and the benefits of using this library can be significant. I'd like to add that Boost.Compute represents one level of abstraction for accelerator programming. I'd like the Boost community to keep an open mind when it comes to different levels of abstraction, either lower (i.e. my Aura library) or higher (i.e. VexCL). Libraries with different levels of abstraction can coexist, be compatible with one another or could even build upon one another. Best Regards, Sebastian Schaetz [0] https://github.com/sschaetz/aura

2 1

File Handle and FILE* wrappers?
by Olaf van der Spek 16 Dec '14

16 Dec '14

Hi, Would there be any interest in wrappers for file handles / descriptors and FILE*? Sometimes one needs native handles or FILE* for interoperability or special features like memory mapped IO, but standard C++ doesn't provide convenient RAII friendly wrappers for these. The idea seems trivial yet quite useful. I'm aware of <boost/iostreams/device/file_descriptor.hpp> but it seems to be too high-level. I've put a simple start for FILE* at https://code.google.com/p/xbt/source/browse/trunk/xbt/misc/xbt/cfile.h What do you think? Also posted at https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Q4RdFSZg… -- Olaf

8 21

[utility] What happened to OptionalPointee/compare_pointees?
by Mostafa 16 Dec '14

16 Dec '14

1) OptionalPointee/compare_pointees reside here: libs/utility/OptionalPointee.html, but there's no way to navigate to it from here: libs/utility/ or here: libs/utility/utility.htm 2) IMO, compare_pointees should have stand alone documentation, and be grouped with pointee and indirect_reference. 3) pointee and indirect_reference are not iterator specific, therefore they shouldn't reside under iterator's documentation. IMO, compare_pointees, pointee and indirect_reference should all reside under a pointee utilities section. Thanks.

1 1

Spam ticket
by Barend Gehrels 15 Dec '14

15 Dec '14

Hi, This is not a spam-ticket but an annoying spam-comment in a long closed ticket. How can we handle this? Can the user of this comment (Smithg358) be blocked? Thanks, Barend -------- Original message -------- Onderwerp: Re: [Boost C++ Libraries] #6019: Convex hull and Area, combined, sometimes give wrong result Datum: Sat, 13 Dec 2014 23:23:53 -0000 Van: Boost C++ Libraries <noreply(a)lists.boost.org> CC: boost-bugs(a)lists.boost.org #6019: Convex hull and Area, combined, sometimes give wrong result ------------------------------------------+------------------------------ Reporter: Crispin Cooper <cooperch@…> | Owner: barendgehrels Type: Library Submissions | Status: reopened Milestone: Website 1.X | Component: xpressive Version: Boost.Build-M3 | Severity: Not Applicable Resolution: | Keywords: convex hull area ------------------------------------------+------------------------------ Changes (by Smithg358): * status: closed => reopened * severity: Problem => Not Applicable * type: Bugs => Library Submissions * component: geometry => xpressive * version: Boost 1.47.0 => Boost.Build-M3 * milestone: To Be Determined => Website 1.X * resolution: fixed => Comment: Your goal is to breed all the different dragons available to you ddgkbecefcfgddbk -- Ticket URL: <https://svn.boost.org/trac/boost/ticket/6019#comment:7> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.

2 2

[safe_numerics] questioning the basic idea
by Andrzej Krzemienski 15 Dec '14

15 Dec '14

Hi, I was going through the Safe Numerics library in Boost Library Incubator, and I realized I disagree with the basic idea it is built on. I wanted to rise my concerns here. If I were to summarize in one sentence what this library is, I would say: a drop-in replacement for type int that checks for overflow in run-time and throws an exception if it finds one. Did I get it right? The remainder of this post is based on this interpretation. If so, I am not sure if this idea is a good one and worth promoting in Boost. BTW this is one of my criteria for letting a library into Boost: whether it promotes worthy ideas. I agree with the statement that a program should be UB-free. But I do not think that the approach of letting the programmer do what he did before, having the library or some run-time tool check for potential UB, and throwing an exception instead makes the program any better (or safer). It is just hiding the symptoms but not curing the disease. The programmer should not plant the UB in the first place - I agree. But this is different than first doing the mess and then having the run-time clean it up for you. I know it works for many people, in a number of languages, and it may even be considered a practical solution, but (by inclusion into Boost) I wouldn't like to be sending the message "this is how you are suppose to code". I try to recall how I use type int. I do not think I ever use it for anything that would be close to "numeric" as I know the term from math. Use Case 1 (an index): for (size_t i = 0, I = v.size(); i != I; ++i) { if (i != 0) str += ","; str += v[i]; } There doesn't appear to be a good reason to wrap it into safe<int> here, even though the incrementation could possibly overflow. Plus, it would kill my performance. Use Case 2 (using reasonably small range): I used an int to represent a square on a chessboard. There is only 64 squares, so I couldn't possibly overflow, on whatever platform. And even if there exists a platform where 64 doesn't fit into an int, I would not use safe<int> there. I would rather go for something like double_int. If I were to use some numeric computations on integers and I perceived any risk that I may overflow, I would not be satisfied with having the computations stop because of an exception. I would rather use a bigger type (BigInt?). I do not think int is even meant to be used in numerical computations. I believe it is supposed to be a building block for building more useful types like BigInt. One good usage example I can think of is this. After a while of trying to chase a bug I comae up with a hypothesis that my int could be overflowing. I temporarily replace it with safe<int> and put a break point in function overflow() to trap it and support my hypothesis. I would probably use a configurable typedef then: #ifndef NDEBUG typedef safe<int> int_t; #else typedef int int_t; #endif But is this the intent? But perhaps it is just my narrow perspective. Can you give me a real-life example where substituting safe<int> for int has merit and is not controversial? I do not mean the code, just a story. Regards, &rzej

6 12

[endian] Heads up: breaking name changes coming
by Beman Dawes 15 Dec '14

15 Dec '14

Boost.Endian develop branch is about to have major changes merged in as part of the preparation for a mini-review. AFAICR, the breaking changes are limited to header, class, and function name changes, but there are a lot of hopefully non-breaking changes so I could easily be wrong about that. If you are currently using Boost.Endian develop branch, you will need to change your code accordingly. It would make sense to wait a few days until the mini-review merge is complete and any fixes required by regression test failures are fixed. Thanks for your patience, --Beman

1 0

Re: [boost] List of C++ 11 only Boost libraries and their status?
by Dave Gomboc 14 Dec '14

14 Dec '14

On Sat, Dec 13, 2014 at 08:37 AM, Rogerio dos Santos <rogerio.santos.main(a)gmail.com> wrote: > > On Sat, Dec 13, 2014 at 8:27 AM, Nat Goodspeed <nat(a)lindenlab.com> wrote: >> >> I'm just contradicting the assumption that those who must work with >> old compilers aren't doing any new development, or have no interest in >> new libraries. >> > > To add to this point, I would like to mention that even new developments > trends might require support to old or limited compilers. E.g.: IoT, real > time projects, industrial HMIs and mobile applications. > > Roger Indeed. I work on embedded, real-time industrial control systems in a field where certain specifications (unfortunately, IMO) severely restrict the platform choices available. In many cases, the systems developed must be built using pre-C++98 compiler technology. While that is a problem I am attempting to address, I suspect it is going to take at least another year to do so, and I am confident that at least one of the platforms will probably never support multi-threading even if its vendor does end up improving or replacing its toolchain (and I have no iron-clad guarantee from the vendor that the toolchain will actually be improved or replaced, though I have a reasonable hope). None of the above constraints imply that the libraries developed by Boost are not of use for these systems, or that we are not interested in using Boost libraries to the extent that it is possible to do so. I think it is possible to structure compatibility code so that it doesn't egregiously interfere with future development. I always get nervous when Steve posts asking to hack away the support for a few more of the older toolchains. While I fully appreciate that his end-goal is well-intentioned, there's still important code out there relying upon some of those pre-C++98 workarounds that can still benefit from the fixes and new libraries introduced into new versions of Boost. Consequently, I'm much in favour of allowing Boost library maintainers who wish to retain support for older compilers the latitude to do so. Dave

2 1

List of C++ 11 only Boost libraries and their status?
by Niall Douglas 13 Dec '14

13 Dec '14

For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list: * Boost.Spirit X3 ETA to Boost review: unknown, last commit was June 2014. * Boost.Proto 0x ETA to Boost review: unknown, last commit was Oct 2013. * Boost.Hana ETA to Boost review: Summer 2015, last commit was today. * Boost.AFIO ETA to Boost review: Already in review queue, last commit was two days ago. * Boost.BindLib ETA to Boost review: Q1 2015, last commit was two days ago. * Boost.Spinlock ETA to Boost review: Q2 2015, last commit was four days ago. * Boost.KernelAlloc ETA to Boost review: Q1 2015, last commit was today. * Boost.Expected ETA to Boost review: no later than Summer 2015 probably much earlier, last commit was two weeks ago. * Boost.CRUX ETA to Boost review: hopefully by end of 2015, last commit was three days ago. I have to admit surprise at how long the list I have collected already is. Are there any other C++ 11 only Boost libraries I am missing, or have I got the ETAs wrong? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

24 49

New Feature, MathString.
by Jakub trzciński 13 Dec '14

13 Dec '14

Hi. My name is Jacob and i am new here.i have idea for new feature in boost. Actually i write a little library whitch name MathString. As you see by name the library will be calcule Row's from string. But it's not all. I was write a interface which add own Mathematical functions for row and variables. If you accept my idea i will send whole code. Code for example MathString test("sqrt(x,2)"); test.LinkFunction(&sqrt,"sqrt"); test.pushVariable("x",4); cout<<test.getResluts(); This code will be return 2 (as you know root with level 2 of 4 equals 2)

3 2

C++ Concept-based tag dispatching using the Tick library
by pfultz2 13 Dec '14

13 Dec '14

Hello Everyone, For those interested. I added support for tag dispatching in the Tick. The reason it wasn't added earlier was concern over specialization. So now as a simple example, the `advance` function could be implemented like this: TICK_TRAIT(is_incrementable) { template<class T> auto requires_(T&& x) -> tick::valid< decltype(x++), decltype(++x) >; }; TICK_TRAIT(is_decrementable, is_incrementable<_>) { template<class T> auto requires_(T&& x) -> tick::valid< decltype(x--), decltype(--x) >; }; TICK_TRAIT(is_advanceable, is_decrementable<_>) { template<class T, class Number> auto requires_(T&& x, Number n) -> tick::valid< decltype(x += n) >; }; template<class Iterator> void advance_impl(Iterator& it, int n, tick::tag<is_advanceable>) { it += n; } template<class Iterator> void advance_impl(Iterator& it, int n, tick::tag<is_decrementable>) { if (n > 0) while (n--) ++it; else { n *= -1; while (n--) --it; } } template<class Iterator> void advance_impl(Iterator& it, int n, tick::tag<is_incrementable>) { while (n--) ++it; } template<class Iterator> void advance(Iterator& it, int n) { advance_impl(it, n, tick::most_refined<is_advanceable<Iterator>>()); } Now, specialization is still supported in a sane way. As an example, say there was an iterator called `foo_iterator` that fulfilled the type requirements for `is_incrementable`, `is_decrementable`, and `is_advanceable`, but it had an incorrect `+=` operator on it(perhaps it crahsed at runtime). So `is_advanceable` can be specialized to prevent this problem: template<> struct is_advanceable<foo_iterator> : std::false_type {}; Even though it is specialized to false, it can still dispatch to `tag<is_decrementable>` and `tag<is_incrementable>` tags. You can read more about it here: http://pfultz2.github.io/Tick/doc/html/tag/ Any feedback is appreciated. Thanks, Paul Fultz II -- View this message in context: http://boost.2283326.n4.nabble.com/C-Concept-based-tag-dispatching-using-th… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Duration of formal reviews
by Vladimir Prus 12 Dec '14

12 Dec '14

Some time ago we had a poll about formal reviews problems: https://plus.google.com/u/0/+VladimirPrus/posts/5spgjicc3fv The majority said that ten days are not enough. Of course, it's not very statistically significant, but that's the only data we've got, and we have a rather sparse schedule. How about trying two weeks for a formal review? Thanks, -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

4 3

Is Boost.Xpressive's sregex::compile() thread-safe for an object only used in that thread?
by Chambers, Matthew 12 Dec '14

12 Dec '14

I have a case where I am compiling a dynamic regex based on client code input, and it works except for when I run my multi-threaded unit test 100-1000 times. When I run it with 1 thread, it never fails. When I run it with 2 or 4 threads it fails at this rare frequency. Except on my build server, where it seems to fail most of the time, which is how I learned about the issue to begin with. It's not crashing though, it's just very rarely returning the wrong results, and not always in the same place in the unit test. So I'm trying to understand Xpressive's thread safety. I understand it as far as not using a regex object in multiple threads until it's finished compiling and not sharing a match_results across threads, but what about compiling different regex objects for each thread: if two threads are compiling two different regexes (or even the same const regex string but from different threads, which is possible with my test code), is that ok? I'm seeing this failure on MSVC 12 but I think I also got it with VC10, just not as reliably on the build server (but the build server had to be upgraded to Windows 2012 to install VC12, so maybe that OS change had an effect as well). Thanks, -Matt

2 2

[coroutine] x86 msvc11 stack corruption
by Tobias Loew 12 Dec '14

12 Dec '14

Hi, I use Boost 1.55 uni-directional coroutines to build an x86 MSVC11 application. I have a simple pull-type (boost::coroutines::coroutine<void>::pull_type) that under certain reproducable conditions destroys the stack after returning from the coroutine. Here is the corrupted stack as shown by VS2012 > ebs2000.exe!CScriptMainFrame::DoRun(CPascalEditorDoc * 0x00000000, int 0x00000000, int 0x00000000) Line 3372 C++ ebs2000.exe!CScriptMainFrame::OnDebugStepover() Line 4916 C++ mfc110u.dll!_AfxDispatchCmdMsg(CCmdTarget *, unsigned int, int, void (void) *, void *, unsigned int, AFX_CMDHANDLERINFO *) C++ 00000002() Unknown [Frames below may be incorrect and/or missing] mfc110u.dll!CCmdTarget::OnCmdMsg(unsigned int, int 0x00000000, void *, AFX_CMDHANDLERINFO *) Line 364 C++ mfc110u.dll!CWnd::OnCommand(unsigned int 0x00018263, long 0x00000000) Line 2785 C++ mfc110u.dll!CFrameWnd::OnCommand(unsigned int 0x00018263, long 0x00000000) Line 389 C++ ... This only happens in windows x86 32-bit release-builds when the coroutine finishes upon a user-action that also includes a windows WM_SETFOCUS message on my menu-bar. If at least one of the following is true, the stack-corruption does NOT happen: - debug-build - x64 build - using a different pull-type, e.g. enum status_enum{...}; boost::coroutines::coroutine<status_enum>::pull_type - not returning form the coroutine, but pushing just before the end of the coroutine and swapping the pull-type-variable with a default constructed "not-a-coroutine" Even though I have a lot of workarounds, I still would like to know, why this happens. regards Tobias PS: I had to recompile ml /safeseh /c make_i386_ms_pe_masm.asm ml /safeseh /c jump_i386_ms_pe_masm.asm to get SAFESEH-libraries. -- View this message in context: http://boost.2283326.n4.nabble.com/coroutine-x86-msvc11-stack-corruption-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[review] Last day for formal review for Sort library
by Edward Diener 12 Dec '14

12 Dec '14

Today is the last day for the formal review of the Sort library by Steven Ross, which started November 10. We have had some great discussions and reviews so far and I would like to thank everybody involved, but as always we need more formal reviews. If you need any delay for your review after today, please contact me at 'eldiener at tropicsoft dot com' and I will take your review into account if given within a reasonable period of time after today. About the Sort library ================== The Sort library is a library which implements hybrid sorting algorithms based on a Spreadsort ( http://en.wikipedia.org/wiki/Spreadsort ), of which the author of the library, Steven Ross, is the inventor. The algorithm provides a sort that is faster than O(n*log(n)). The library provides a generic implementation of high-speed sorting algorithms that outperform those in the C++ standard in both average and worst case performance. These algorithms only work on random access iterators. They are hybrids using both radix and comparison-based sorting, specialized to sorting common data types, such as integers, floats, and strings. These algorithms are encoded in a generic fashion and accept functors, enabling them to sort any object that can be processed like these basic data types. Where to get it =============== The library is available on github at https://github.com/spreadsort/sort. The library is in modular Boost format and can be cloned to libs/sort under your local modular boost directory. I have provided as the review manager online documentation at: http://eldiener.github.io/sort Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[sort]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 'eldiener at tropicsoft dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - 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. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome.

6 11

Help test MSVC 14 CTP compiler
by Andrzej Krzemienski 11 Dec '14

11 Dec '14

Hi Everyone, I am trying to determine the root cause of the failure in one of Boost.Optional regression tests. Namely: http://www.boost.org/development/tests/develop/developer/output/teeks99-08f… Could anyone with the access to MSVC 14 CTP compiler check if the following code compiles? // BEGIN CODE #include <boost/static_assert.hpp> #include <boost/type_traits/is_nothrow_move_assignable.hpp> struct NothrowCtor { NothrowCtor(NothrowCtor&&) BOOST_NOEXCEPT_IF(true) {}; void operator=(NothrowCtor&&) BOOST_NOEXCEPT_IF(false) {}; }; BOOST_STATIC_ASSERT(!::boost::is_nothrow_move_assignable<NothrowCtor>::value); int main() {} // END CODE Regards, &rzej

5 13

Use of boost in safety critical work
by Andrew Marlow 11 Dec '14

11 Dec '14

Hello fellow boosters, I am currently considering a job which involves embedded safety critical. It is for a neonatal ventilator so the safety critical aspect really is critical rather than just 'jolly important'. The company says the development will be in C++ but they have not even heard of boost, let alone use it. They introduced me to a new acronym, well new to me anyway: SOUP. It stands for Software of Unknown Pedigree. They classify boost as SOUP. I have used boost before in embedded work but I have never done safety critical work before so I don't know how widely boost is used there. Can anyone who *has* worked on safety critical stuff comment please? -- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk

16 26

Re: [boost] [asio] Is Boost.Asio ported for Windows Runtime?
by Moshe Rubin 11 Dec '14

11 Dec '14

Hi Rob, The reason I posted an Asio-related question to this forum is because the Asio mailing list is all but dead. In October there were three (3) posts in all, in November zero posts, and this December only one post - mine. Sounds dead to me. Moshe >> On December 9, 2014 3:11:32 AM EST, Moshe Rubin <moshe(a)hyperlync.com> wrote: >> [snip] >>Can the Boost.Asio maintainer, or anyone else, verify if Boost.Asio can >>be built as-is for WinRT, or does it need to be ported? > I added "[asio]" to the subject to help attract the right audience, but you probably want the Asio mailing list for such a question: http://think-async.com/Asio/MailingList.

2 1

Re: [boost] Boost 1.57 hot-out-of-Git fails to compile for Windows Phone
by Moshe Rubin 11 Dec '14

11 Dec '14

Oliver, I forgot to mention that stack_traits.cpp has a typo: it should include: #include <boost/context/stack_context.hpp> rather than #include <boost/econtext/stack_context.hpp> (note the extra 'e') Moshe -------------------- > > I'm currently attempting to port libraries for Windows Phone 8.1 and have not started concentrating on the units tests (of course. Can you please educate me on how to run the boost.context units tests? > > compile the code in directory <boost>/libs/context/test and execute the binaries on WindowsPhone, please (remove untested.cpp in > build/Jamfile.v2) Oliver, I was able to compile and run the context test as a regular Windows app (i.e., not Windows Phone). Here are the results I got: C:\Private\Dev\3rdParty\Boost\boost_1.57-Port-for-WP81\boost\bin.v2\libs\context\test\test_context.test\msvc-12.0\debug\link-static\threading-multi>test_context.exe Running 9 test cases... f1: entered *** No errors detected Detected memory leaks! Dumping objects -> {478} normal block at 0x00530470, 65536 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {477} normal block at 0x00520440, 65536 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {473} normal block at 0x0051E3B0, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {469} normal block at 0x0050E320, 65536 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {465} normal block at 0x0050C290, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {461} normal block at 0x0050A200, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {457} normal block at 0x00508170, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {453} normal block at 0x005060E0, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {449} normal block at 0x005040B0, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {445} normal block at 0x00502080, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD Object dump complete. C:\Private\Dev\3rdParty\Boost\boost_1.57-Port-for-WP81\boost\bin.v2\libs\context\test\test_context.test\msvc-12.0\debug\link-static\threading-multi> It is not clear to me how to compile and run the context test on a Windows Phone. Windows Phone does not run regular executables, so a GUI client app would need to be written. It is not clear to me how to run the test for Windows Phone (I doubt the Boost.Test framework supports a Windows Phone interface). Please advise Moshe

1 0

Re: [boost] Boost 1.57 hot-out-of-Git fails to compile for Windows Phone
by Moshe Rubin 11 Dec '14

11 Dec '14

> > I'm currently attempting to port libraries for Windows Phone 8.1 and have not started concentrating on the units tests (of course. Can you please educate me on how to run the boost.context units tests? > > compile the code in directory <boost>/libs/context/test and execute the binaries on WindowsPhone, please (remove untested.cpp in > build/Jamfile.v2) Oliver, I was able to compile and run the context test as a regular Windows app (i.e., not Windows Phone). Here are the results I got: C:\Private\Dev\3rdParty\Boost\boost_1.57-Port-for-WP81\boost\bin.v2\libs\context\test\test_context.test\msvc-12.0\debug\link-static\threading-multi>test_context.exe Running 9 test cases... f1: entered *** No errors detected Detected memory leaks! Dumping objects -> {478} normal block at 0x00530470, 65536 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {477} normal block at 0x00520440, 65536 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {473} normal block at 0x0051E3B0, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {469} normal block at 0x0050E320, 65536 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {465} normal block at 0x0050C290, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {461} normal block at 0x0050A200, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {457} normal block at 0x00508170, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {453} normal block at 0x005060E0, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {449} normal block at 0x005040B0, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {445} normal block at 0x00502080, 8192 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD Object dump complete. C:\Private\Dev\3rdParty\Boost\boost_1.57-Port-for-WP81\boost\bin.v2\libs\context\test\test_context.test\msvc-12.0\debug\link-static\threading-multi> It is not clear to me how to compile and run the context test on a Windows Phone. Windows Phone does not run regular executables, so a GUI client app would need to be written. It is not clear to me how to run the test for Windows Phone (I doubt the Boost.Test framework supports a Windows Phone interface). Please advise Moshe

2 1

Re: [boost] Develop Tests Failing Again
by Tom Kent 11 Dec '14

11 Dec '14

On Mon, Dec 8, 2014 at 1:04 PM, Tom Kent <lists(a)teeks99.com> wrote: > It looks like my windows and linux tests have been failing since last > saturday, around 4pm pacific time. > > The end of results/bjam.log is as follows: > boost-test(RUN) "serialization/test_helper_support_xml_warchive" : > "libs/serialization/test/test_ > helper_support.cpp" > error: at D:/local/teeks99-08/a/boost_bb/src/kernel\modules.jam:107 > error: Unable to find file or target named > error: 'test_interrupts.cpp' > error: referred to from project at > error: '../libs/serialization/test' > > Tom > Apparently it is fixed now. Anyone know what happened, I didn't see any messages about it. Tom

2 1

Re: [boost] [Boost-build] Boost 1.57 hot-out-of-Git fails to compile for Windows Phone
by Jürgen Hunold 10 Dec '14

10 Dec '14

Hi Volodya, Am Freitag, 5. Dezember 2014, 11:19:25 schrieb Vladimir Prus: > On 12/04/2014 09:37 PM, Jürgen Hunold wrote: > > Since sometime last week, Boost.Context depends on Boost.System. > > Unfortunately, Boost.Context has to explicitly calculate the > > <address-model> and <architecture> properties in order to select the > > assembler needed, as those properties have no default value (yet). > > It so happens that Boost.System is once requested without those properties > > and a second time with them. And the <layout> rule is asked to build both > > target with the same effective name in stage/lib. => clash. > > > > So explicitly specifying the properties leads to the right solution. > > > > I cross-mail this to the Boost.Build list to see if someone has a > > solution. > > It would seem I'd have to make architecture and address-model always set, > possibly by lifting current boost.context code for same to the top level? > At least I don't see any other plausible soluton. Me neither. And I think this is not the only configuration code that needs uplifting. We have some duplicated configuration code for ICU and zlib. The main difficulty is the question of sensible default feature values for <address-model> and <architecture>. Especially for Windows with its path length limitations. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

1 0

Review request for Compute
by Antony Polukhin 10 Dec '14

10 Dec '14

Hi, Please add the the Compute library to the review schedule. Compute is a GPU/parallel-computing library for C++ based on OpenCL. Author: Kyle Lutz Source code: https://github.com/kylelutz/compute Documentation: http://kylelutz.github.io/compute/ Review Manager: Antony Polukhin Approximate review date: end of November - December 2014 -- Best regards, Antony Polukhin

2 2

Re: [boost] Boost 1.57 hot-out-of-Git fails to compile for Windows Phone
by Moshe Rubin 10 Dec '14

10 Dec '14

Oliver, I'm currently attempting to port libraries for Windows Phone 8.1 and have not started concentrating on the units tests (of course. Can you please educate me on how to run the boost.context units tests? Moshe > Hello Moshe, > could you tell me if boost.context passes its unit-tests on > Windows-Phone, please? > thx, > Oliver > > 2014-12-09 9:40 GMT+01:00 Moshe Rubin <moshe(a)hyperlync.com<mailto:moshe@hyperlync.com>>: > > A belated "thank you" to Juergen Hunold and Oliver Kowalke for their help in solving the problem. Indeed, when "address-model=32" was added to the command line it solved the problem and enabled me to build all the Windows Phone ARM libraries in one fell swoop. > > > > Thanks very much, > > > > Moshe

2 1

[iterators] Missing typedefs in v1.57
by news.gmane.org 10 Dec '14

10 Dec '14

I posted this a week ago in the user mailing list but it went unnoticed. Perhaps this developers' list is a better place to post it. The typedefs for difference_type and reference used to be in scope for classes derived from iterator_facade. Since v1.57 they have to be declared thus: typedef typename iterator_facade_::difference_type difference_type; typedef typename iterator_facade_::reference reference; This seems out of place for a class that was designed to reduce boiler plate code. However, if the change was intentional, please document it. Thanks, Keith MacDonald

3 5

[documentation] Are SVG's in documentation viable now?
by John Maddock 10 Dec '14

10 Dec '14

Folks I need your opinions, Since it's inception, Boost.Math has used PNG versions of equations and graphs even though scalable SVG versions have been available. Unfortunately, a variety of issues have prevented their use. Fortunately, the logjam now appears to have cleared, and use of SVG's appears viable. So... I wonder if I can get folks to point their browsers at http://jzmaddock.github.io/doctest/html/svg_test/equations.html and let me know if there are any issues? One that I'm aware of, is that the equations reference Window's specific fonts, but so far in my tests this appears not to be an issue. Many thanks, John. PS, I'm aware of MathJax and similar solutions for equations - but these generate so many security warnings on IE when used in local docs (not on a server), that it's a non-starter for now. Besides, we have the SVG's already, and it's a one line change to make use of them ;-)

13 22

Re: [boost] [RPC] Compile-time reflection for RPC and mocking
by Brian Wood 09 Dec '14

09 Dec '14

Peter Bindels writes: > Based on Hartmut's speech last Saturday introducing HPX and explaining a > bit about async/future/promise I tried to implement a simple RPC mechanism > that uses then to decouple work and the result I have so far is very > promising. I have a simple interface with a call that returns a future, and > the caller does not distinguish between calling the actual object and > calling on a proxy, as both return a future<T>. It does what the discussion > mentions - serialize the name of the interface and function, as well as the > arguments (basically the mangled name of the interface function) to ensure > there are no mismatches. I tend to agree with Bjorn's post about messaging middleware. For some reason, thinking in terms of messages is easier for me. For example, rather than serializing the name of the interface and function, I include a message id, which is often one byte. -- Brian Ebenezer Enterprises - So far G-d has helped us. http://webEbenezer.net

2 1

[container] locking for compact map
by Vicente J. Botet Escriba 09 Dec '14

09 Dec '14

Hi, I'm locking for a map<std::size_t, T> implemented as array<optional<T>, N>. When the key is on the range 0..N-1 and the map is dense enough, the advantages are * the whole data is much more compact, avoiding allocations and deallocations, and should reduce the cash misses. * the access insertion/removal/get is direct O(k) instead of O(logN). The liabilities, are the same as array. * iterating is not O(k), but O(N) (When the number of elements is not too high or when there is no too much holes, this should not be a problem) * The move constructor is not noexcept. An implementation using vector<optional<T>> should avoid this last issue. You could ask your self why I don't use directly array<optional<T>> or vector<optional<T>>. The answer is that I don't want the user manage the holes. I'm aware of/flat_(multi)map/set/ associative containers. The difference here is that as the key is the position on the array which make things perform even better for this particular case. Is there something similar in Boost already that I'm missing? Do you see other liabilities I have missed? Best, Vicente

2 4

Boost People section largely outdated
by Joaquin M Lopez Munoz 09 Dec '14

09 Dec '14

Hi, It is a pity that the Boost People section: http://www.boost.org/users/people.html is so outdated: many people there are no longer around, and, more importantly, many (most) current contributors are not listed. This is is a reminder for people to get themselves on that page! Instructions at http://www.boost.org/development/submissions.html#People Best Joaquín M López Muñoz Telefónica

3 2

[asio] introspecting boost::asio::detail::epoll_reactor::run
by Isidor Zeuner 09 Dec '14

09 Dec '14

Hi all, I am investigating a livelock in a running process inside boost::asio::detail::epoll_reactor::run and I was wondering if someone was in this situation before and may have some tools (gdb scripts?) handy which can be used to get a list of currently pending tasks inside the epoll reactor. Thanks in advance! Best regards, Isidor

1 0

Re: [boost] Boost 1.57 hot-out-of-Git fails to compile for Windows Phone
by Moshe Rubin 09 Dec '14

09 Dec '14

A belated "thank you" to Juergen Hunold and Oliver Kowalke for their help in solving the problem. Indeed, when "address-model=32" was added to the command line it solved the problem and enabled me to build all the Windows Phone ARM libraries in one fell swoop. Thanks very much, Moshe

2 1

boost::filesystem changes since version 1.55.0
by Armin Pies 09 Dec '14

09 Dec '14

I have tried to upgrade our software from using boost 1.55.0 to 1.57.0. Now we're getting unexpected exceptions in our code using filesystem::recursive_directory_iterator. Checking http://www.boost.org/users/history/version_1_56_0.html or http://www.boost.org/users/history/version_1_57_0.html there are no changes concerning boost::filesystem. Is there somebody who can tell me what has been changed in boost::filesystem, versions 1.56 and 1.57, and what impact it has on existing code or what I have to adapt to fix our software? Regards, Armin Pies

4 5

Re: [boost] boost::filesystem changes since version 1.55.0
by Armin Pies 09 Dec '14

09 Dec '14

Obviously the operator++ of the recursive_directory_iterator throws exceptions now, which it did not before 1.56. I have changed our code using the increment(system::error_code& ec) method to ignore the unexpected exceptions. Regards, Armin

2 2

Is Boost.Asio ported for Windows Runtime?
by Moshe Rubin 09 Dec '14

09 Dec '14

Boost.Asio is a headers-only library which makes use of Boost's 'system' library. Since the 'system' library has been ported to Windows Runtime (aka WinRT) by Steven Gates of Microsoft, I assumed that Boost.Asio should therefore work as-is for WinRT. When I wrote to Steven asking him to verify that Boost.Asio will work today for WinRT he answered: <quote> "I don't know if Boost.Asio works with the Windows Runtime. I would guess it doesn't entirely, but since it is a header file only library it might work depending on the features used. My recommendation would be to run the Windows App Cert Kit and if you didn't pull in any banned APIs then you might be good. When I look in the history of the Boost.Asio Github repository I can see the maintainer at least started some work for the Windows Runtime. I recommend you reach out to him or post of the Boost mailing forums to see." </quote> Can the Boost.Asio maintainer, or anyone else, verify if Boost.Asio can be built as-is for WinRT, or does it need to be ported? Thanks in advance, Moshe Rubin

2 1

Do we need BoostBook?
by Vladimir Prus 09 Dec '14

09 Dec '14

Hi, I've noticed that Boost.Build documentation, created with BoostBook, explicitly sets a small, and IMO unreadable, font, so I went to fix that, and some other things, as shown at: http://goo.gl/VWYh2P However, after a few easy tweaks, I'm stuck at the fact that BoostBook/DocBook produces fairly old-fashioned HTML. For example, the Boost logo at top is actually a table, and the "tip" block is also a table, which makes tweaking the layout with CSS quite a bit more complex. Also, some of the conceptually trivial things, like putting some front matter in index.html, appear to require XSLT customization. As heretic as it sounds, do we get any benefits from BoostBook? It's a complex vocabulary, with complex toolchain, and while PDF generation sounded nice 10 years ago, printing HTML into PDF is a viable option these days - and nobody would want to print entire Boost documentation anyway? Thoughts? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

12 33

[RFC][Patch][Boost.context] Allowing alternative context switch API
by microcai 09 Dec '14

09 Dec '14

Hi Oliver Kowalke, and others last weak, I report a bug that boost.context causes LoadLibrary to fail. And Oliver Kowalke response that might be because boost.context didn't swap all TIB parts. Allowing alternative context switch API other than reverse-engineered boost.context might solve the problem. So I speed some time to write the patch. users that wish to use Win32 API shoul define BOOST_COROUTINE_USE_FIBER then users should be responsibe to make sure all threads that might call coroutine must be converted to fiber first. since IsThreadAFIber() is not available on some windows platform. if the user can make 100% sure that the platform he/she wish to support has IsThreadAFIber(), then define BOOST_COROUTINE_USE_IS_THREAD_A_FIBER and boost.coroutine will take care of converting to fiber and converting back to thread. Best regards. --- >From 11668b6641c877a4ea154d51ad2171483eced921 Mon Sep 17 00:00:00 2001 From: microcai <microcaicai(a)gmail.com> Date: Sat, 6 Dec 2014 15:50:46 +0800 Subject: [PATCH] allow Win32 Fiber as alternative context switch API windows has some undocumented TIB parts, as boost.context can't keep 100% compatibility with all windows versions, and coroutine is essential to many building blocks. It has to be stable, to allowing alternative context switch API can be more use full. --- .../boost/coroutine/detail/coroutine_context.hpp | 11 ++++ .../coroutine/detail/pull_coroutine_object.hpp | 9 ++++ .../coroutine/detail/push_coroutine_object.hpp | 9 ++++ include/boost/coroutine/stack_allocator.hpp | 5 ++ .../coroutine/windows/null_stack_allocator.hpp | 53 +++++++++++++++++++ src/detail/coroutine_context.cpp | 60 ++++++++++++++++++++-- 6 files changed, 142 insertions(+), 5 deletions(-) create mode 100644 include/boost/coroutine/windows/null_stack_allocator.hpp diff --git a/include/boost/coroutine/detail/coroutine_context.hpp b/include/boost/coroutine/detail/coroutine_context.hpp index 6c4ebb6..f6a53e2 100644 --- a/include/boost/coroutine/detail/coroutine_context.hpp +++ b/include/boost/coroutine/detail/coroutine_context.hpp @@ -16,6 +16,9 @@ #include <boost/coroutine/detail/config.hpp> #include <boost/coroutine/stack_context.hpp> +#ifdef BOOST_COROUTINE_USE_FIBER +# include <windows.h> +#endif #ifdef BOOST_HAS_ABI_HEADERS # include BOOST_ABI_PREFIX #endif @@ -31,6 +34,12 @@ class BOOST_COROUTINES_DECL coroutine_context private: stack_context stack_ctx_; context::fcontext_t ctx_; +#ifdef BOOST_COROUTINE_USE_FIBER + void (*fn_)(intptr_t); + intptr_t param_; + LPVOID fiber_; + static VOID WINAPI fb_start_proc(LPVOID lpFiberParameter); +#endif // BOOST_COROUTINE_USE_FIBER public: typedef void( * ctx_fn)( intptr_t); @@ -51,6 +60,8 @@ public: stack_context & stack_ctx() { return stack_ctx_; } + + void destory(); }; }}} diff --git a/include/boost/coroutine/detail/pull_coroutine_object.hpp b/include/boost/coroutine/detail/pull_coroutine_object.hpp index cfe34bd..d15d94f 100644 --- a/include/boost/coroutine/detail/pull_coroutine_object.hpp +++ b/include/boost/coroutine/detail/pull_coroutine_object.hpp @@ -65,6 +65,9 @@ private: stack_context stack_ctx( obj->stack_ctx_); StackAllocator stack_alloc( obj->stack_alloc_); obj->unwind_stack(); +#ifdef BOOST_COROUTINE_USE_FIBER + obj->callee.destory(); +#endif obj->~obj_t(); stack_alloc.deallocate( stack_ctx); } @@ -153,6 +156,9 @@ private: stack_context stack_ctx( obj->stack_ctx_); StackAllocator stack_alloc( obj->stack_alloc_); obj->unwind_stack(); +#ifdef BOOST_COROUTINE_USE_FIBER + obj->callee.destory(); +#endif obj->~obj_t(); stack_alloc.deallocate( stack_ctx); } @@ -241,6 +247,9 @@ private: stack_context stack_ctx( obj->stack_ctx_); StackAllocator stack_alloc( obj->stack_alloc_); obj->unwind_stack(); +#ifdef BOOST_COROUTINE_USE_FIBER + obj->callee.destory(); +#endif obj->~obj_t(); stack_alloc.deallocate( stack_ctx); } diff --git a/include/boost/coroutine/detail/push_coroutine_object.hpp b/include/boost/coroutine/detail/push_coroutine_object.hpp index 1a39c07..b41a3b2 100644 --- a/include/boost/coroutine/detail/push_coroutine_object.hpp +++ b/include/boost/coroutine/detail/push_coroutine_object.hpp @@ -77,6 +77,9 @@ private: stack_context stack_ctx( obj->stack_ctx_); StackAllocator stack_alloc( obj->stack_alloc_); obj->unwind_stack(); +#ifdef BOOST_COROUTINE_USE_FIBER + obj->callee.destory(); +#endif obj->~obj_t(); stack_alloc.deallocate( stack_ctx); } @@ -165,6 +168,9 @@ private: stack_context stack_ctx( obj->stack_ctx_); StackAllocator stack_alloc( obj->stack_alloc_); obj->unwind_stack(); +#ifdef BOOST_COROUTINE_USE_FIBER + obj->callee.destory(); +#endif obj->~obj_t(); stack_alloc.deallocate( stack_ctx); } @@ -253,6 +259,9 @@ private: stack_context stack_ctx( obj->stack_ctx_); StackAllocator stack_alloc( obj->stack_alloc_); obj->unwind_stack(); +#ifdef BOOST_COROUTINE_USE_FIBER + obj->callee.destory(); +#endif obj->~obj_t(); stack_alloc.deallocate( stack_ctx); } diff --git a/include/boost/coroutine/stack_allocator.hpp b/include/boost/coroutine/stack_allocator.hpp index 662533e..811f352 100644 --- a/include/boost/coroutine/stack_allocator.hpp +++ b/include/boost/coroutine/stack_allocator.hpp @@ -14,6 +14,9 @@ #include <boost/context/detail/config.hpp> #include <boost/coroutine/segmented_stack_allocator.hpp> #include <boost/coroutine/standard_stack_allocator.hpp> +#if defined(BOOST_WINDOWS) +# include <boost/coroutine/windows/null_stack_allocator.hpp> +#endif #ifdef BOOST_HAS_ABI_HEADERS # include BOOST_ABI_PREFIX @@ -24,6 +27,8 @@ namespace coroutines { #if defined(BOOST_USE_SEGMENTED_STACKS) typedef segmented_stack_allocator stack_allocator; +#elif defined(BOOST_COROUTINE_USE_FIBER) +typedef null_stack_allocator stack_allocator; #else typedef standard_stack_allocator stack_allocator; #endif diff --git a/include/boost/coroutine/windows/null_stack_allocator.hpp b/include/boost/coroutine/windows/null_stack_allocator.hpp new file mode 100644 index 0000000..25f9b34 --- /dev/null +++ b/include/boost/coroutine/windows/null_stack_allocator.hpp @@ -0,0 +1,53 @@ + +// Copyright Oliver Kowalke 2009. +// Distributed under the Boost Software License, Version 1.0. +// (See accompanying file LICENSE_1_0.txt or copy at +// http://www.boost.org/LICENSE_1_0.txt) + +#ifndef BOOST_COROUTINES_NULL_STACK_ALLOCATOR_H +#define BOOST_COROUTINES_NULL_STACK_ALLOCATOR_H + +extern "C" { +#include <windows.h> +} + +#include <cmath> +#include <cstddef> +#include <new> + +#include <boost/config.hpp> + +#include <boost/coroutine/detail/config.hpp> +#include <boost/coroutine/stack_traits.hpp> + +#ifdef BOOST_HAS_ABI_HEADERS +# include BOOST_ABI_PREFIX +#endif + +namespace boost { +namespace coroutines { + +struct stack_context; + +template< typename traitsT > +struct basic_null_stack_allocator +{ + typedef traitsT traits_type; + + void allocate(stack_context & ctx, std::size_t size) + {} + + void deallocate(stack_context & ctx) + {} +}; + +typedef basic_null_stack_allocator< stack_traits > null_stack_allocator; + +} +} + +#ifdef BOOST_HAS_ABI_HEADERS +# include BOOST_ABI_SUFFIX +#endif + +#endif // BOOST_COROUTINES_NULL_STACK_ALLOCATOR_H diff --git a/src/detail/coroutine_context.cpp b/src/detail/coroutine_context.cpp index f63479e..e021281 100644 --- a/src/detail/coroutine_context.cpp +++ b/src/detail/coroutine_context.cpp @@ -28,6 +28,14 @@ void __splitstack_setcontext( void * [BOOST_COROUTINES_SEGMENTS]); namespace boost { namespace coroutines { namespace detail { +#ifdef BOOST_COROUTINE_USE_FIBER +VOID WINAPI coroutine_context::fb_start_proc(LPVOID lpFiberParameter) +{ + coroutine_context * ctx = (coroutine_context*)lpFiberParameter; + ctx->fn_(ctx->param_); + DeleteFiber(ctx->fiber_); +} +#endif coroutine_context::coroutine_context() : stack_ctx_(), @@ -35,18 +43,35 @@ coroutine_context::coroutine_context() : { #if defined(BOOST_USE_SEGMENTED_STACKS) __splitstack_getcontext( stack_ctx_.segments_ctx); +#elif defined(BOOST_COROUTINE_USE_FIBER) + fiber_ = NULL; + param_ = 0; + fn_ = 0; #endif } coroutine_context::coroutine_context( ctx_fn fn, stack_context const& stack_ctx) : - stack_ctx_( stack_ctx), - ctx_( context::make_fcontext( stack_ctx_.sp, stack_ctx_.size, fn) ) -{} + stack_ctx_( stack_ctx) +#ifndef BOOST_COROUTINE_USE_FIBER + , ctx_(context::make_fcontext( stack_ctx_.sp, stack_ctx_.size, fn) ) +#endif // !BOOST_COROUTINE_USE_FIBER +{ +#ifdef BOOST_COROUTINE_USE_FIBER + fn_ = fn; + fiber_ = CreateFiber(0, fb_start_proc, this); +#endif // BOOST_COROUTINE_USE_FIBER +} coroutine_context::coroutine_context( coroutine_context const& other) : stack_ctx_( other.stack_ctx_), ctx_( other.ctx_) -{} +{ +#ifdef BOOST_COROUTINE_USE_FIBER + real_fn = other.real_fn; + fiber_ = other.fiber_; + param_ = other.param_; +#endif // BOOST_COROUTINE_USE_FIBER +} coroutine_context & coroutine_context::operator=( coroutine_context const& other) @@ -55,7 +80,11 @@ coroutine_context::operator=( coroutine_context const& other) stack_ctx_ = other.stack_ctx_; ctx_ = other.ctx_; - +#ifdef BOOST_COROUTINE_USE_FIBER + real_fn = other.real_fn; + fiber_ = other.fiber_; + param_ = other.param_; +#endif // BOOST_COROUTINE_USE_FIBER return * this; } @@ -71,11 +100,32 @@ coroutine_context::jump( coroutine_context & other, intptr_t param, bool preserv __splitstack_setcontext( stack_ctx_.segments_ctx); return ret; +#elif BOOST_COROUTINE_USE_FIBER + other.param_ = param; +#ifdef BOOST_COROUTINE_USE_IS_THREAD_A_FIBER + if (!IsThreadAFiber()) + { + this->fiber_ = ConvertThreadToFiber(this); + SwitchToFiber(other.fiber_); + ConvertFiberToThread(); + this->fiber_ = NULL; + } + else +#endif // BOOST_COROUTINE_USE_IS_THREAD_A_FIBER + SwitchToFiber(other.fiber_); + return this->param_; #else return context::jump_fcontext( & ctx_, other.ctx_, param, preserve_fpu); #endif } +void coroutine_context::destory() +{ +#ifdef BOOST_COROUTINE_USE_FIBER + DeleteFiber(fiber_); +#endif +} + }}} #if defined(_MSC_VER) -- 2.2.0

1 1

What is the e-mail of the Boost webmaster ?
by Edward Diener 08 Dec '14

08 Dec '14

What is the e-mail of the Boost webmaster, as in "If you want to do some XXX on the Boost website, contact the Boost webmaster" ? The term "Boost webmaster" is used on the development portion of the website with no clue who that might be.

1 0

[serialization] Fwd: [Boost-testing] Develop Tests Failing Again
by Rene Rivera 08 Dec '14

08 Dec '14

---------- Forwarded message ---------- From: Tom Kent <teeks99(a)yahoo.com> Date: Mon, Dec 8, 2014 at 2:09 PM Subject: [Boost-testing] Develop Tests Failing Again To: Running Boost regression tests <boost-testing(a)lists.boost.org> It looks like my windows and linux tests have been failing since last saturday, around 4pm pacific time. The end of results/bjam.log is as follows: boost-test(RUN) "serialization/test_helper_ support_xml_warchive" : "libs/serialization/test/test_helper_support.cpp" error: at D:/local/teeks99-08/a/boost_bb/src/kernel\modules.jam:107 error: Unable to find file or target named error: 'test_interrupts.cpp' error: referred to from project at error: '../libs/serialization/test' Tom _______________________________________________ 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

[graph] Lowest common ancestor (LCA), etc.
by Jeremy Murphy 08 Dec '14

08 Dec '14

Hi, I'm working on some graph algorithms that I thought might be useful additions to Boost.Graph, such as the classic LCA and more recent lowest single common ancestor (LSCA) [1]. Is there interest in having these added? I saw there was some discussion of LCA between Cromwell Enage and others back in 2004 but I'm unaware of the outcome (in terms of proposed code, etc). Cheers. Jeremy [1] https://github.com/jeremy-murphy/graph-algorithms

1 0

How to contact test runner "trippels_gcc-5.0_c++11"
by Antony Polukhin 08 Dec '14

08 Dec '14

Hi, There's a GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64218 that would possibly require some comments from test runner. Somebody knows how to contact test runner trippels_gcc-5.0? -- Best regards, Antony Polukhin

1 0

[mpl] [build] [testing] Merge pull requests
by Andrey Semashev 08 Dec '14

08 Dec '14

Hi, There were a lot of discussions about MPL recently, and I created a few pull requests to address issues: https://github.com/boostorg/boost/pull/39 Invoke 'headers' target before building testing tools. Note that several testers are currently failing to run because of this problem. Since this affects the testing process, I'd appreciate if someone familiar with it could take a look. https://github.com/boostorg/boost/pull/38 Add MPL.Core tests to the test report. These tests are currently not run by testers. https://github.com/boostorg/mpl/pull/12 Move a misplaced header from MPL to MPL.Core to resolve circular dependency between the two. I believe the first PR is especially critical. Could someone with permissions merge these? Thanks.

13 52

[quickbook] Where to put my pictures?
by Andrzej Krzemienski 05 Dec '14

05 Dec '14

Hi Everyone, How do I put images into QuickBook documentation? The manual says I should put: [$images/img.png] But in which location am I supposed to put the picture? Currently my documentation works if I put folder "images" with my PNG image inside folder "html". But the latter folder ("html") is generated by b2: it would not be there if I haven't run b2. Assuming I only want to keep QBK sources, but no generated files, where do I put my images, so that b2 works? Regards, &rzej

1 0

Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
by Felix Uhl 05 Dec '14

05 Dec '14

David Stone wrote: >I have been bitten in the past by operator<. I was converting code that >used unsigned with a 'magic value' to represent nullness to >boost::optional<std::uint32_t>. However, the maximum value it used was >std::numeric_limits<std::uint32_t>:max(). A simple find and replace for >this magic constant (which was referred to everywhere as DWORD_NULL) with >boost::none and fixing compile errors led to some erroneous code. We had >code that assumed an 'uninitialized' std::uint32_t was greater than any >valid value. >The concept of "value not present" is not inherently less-than or >greater-than any value, but because of operator<, code compiled that >shouldn't have. I suppose this is really an argument against any operator< >overload, not just the mixed-type comparison. I don't expect this to be a >major problem for new code, but there is a lot of code out there that uses >a magic value, and that is what optional is supposed to replace. I was irritated by it at first, too, and if you think about it the comparison brakes down to a philosophical problem: If I have a pair of pants and you don’t, are my pants smaller than yours? Hard to say, but to me the most logical solution is “no”. My pants aren’t smaller than yours, and my pants aren’t larger than yours. Also, your and my logic would apply to both the operator<(optional<T>, T) and operator<(optional<T>, optional<T>), but I think we’re only talking about the latter. --- Felix Uhl

14 67

[spinlock] Spin on volatile read, NUMA fairness?
by Benedek Thaler 05 Dec '14

05 Dec '14

Hi All, Niall, 1) I was reading this Intel paper [0], and this section grabbed my attention: "One common mistake made by developers developing their own spin-wait loops is attempting to spin on an atomic instruction instead of spinning on a volatile read. Spinning on a dirty read instead of attempting to acquire a lock consumes less time and resources. This allows an application to only attempt to acquire a lock only when it is free." As I can tell by looking at the source code, spinlock spins on atomic consume. I wonder if a volatile read would produce better performance characteristic? 2) AFAIK spinlocking is not necessarily fair on a NUMA architecture. Is there something already implemented or planned in Boost.Spinlock to ensure fairness? I'm thinking of something like this: [1] Thanks, Benedek [0]: https://software.intel.com/en-us/articles/implementing-scalable-atomic-lock… [1]: http://www.google.com/patents/US7334102

6 13

[review] [sort] Sort library review manager results
by Edward Diener 05 Dec '14

05 Dec '14

This is the results from the recent review of the Sort library of Steven Ross. First I would like to thank all those who made comments during the review, whether or not they officially gave a final Yes or No vote to whether the Sort library should be accepted as a Boost library. This list includes: Niall Douglas, Julian Gonggrijp, Phil Endecott, Vladimir Prus, Mathias Gaunard, Jeremy Murphy, Peter Dimov, Robert Ramey, Adam Walling, Anthony Polukhin, Phil Endecott, Paul Bristow, Thijs (M.A.) van den Berg Dupuis Etienne, and Frank Gennari If I have missed anyone I do apologize. Secondly I would like to thank Steven Ross for patiently answering all of the review comments to the best of his ability. My tally of Yes and No votes for acceptance are: Yes votes (5) : Niall Douglas ( conditional ), Julian Gonggrijp ( conditional ), Frank Gennari, Phil Endecott, Paul Bristow. No votes (3) : Vladimir Prus, Adam Walling ( conditional ), Anthony Polukhin I believe the condtional Yes vote from Julian Gonggrijp was completely met in the discussions of issues with Steven Ross and the conditional Yes vote from Niall Douglass was almost completely met in the discussion with Steven Ross about the issues mentioned, and enough to maintain his Yes vote. I want to also mention that the conditional No vote by Adam Walling has an implied Yes vote to it if the Sort library were one among other sort implementations. Since my final decision is not entirely based on the Yes and No votes I want to adumbrate some of the major issues brought up by the review without necessarily focussing on every one of the people who brought them up initially, as well as my own reactions to them as Review Manager. 1) The first major issue was whether a library whose basic merit lies in its algorithm and its speed/space constraints needs better theoretical backing. A number of reviewers discussed this after it was brought up. I tend to agree with reviewers that while the best theoretical basis is always desirable, it is not necessary for a Boost library whose empirical evidence can be and has been measured by its implementor and can be measured by any user. Furthermore Steven Ross has provided an extensive discussion in his documentation, as well as his original paper, about the theoretical merits of his technique. While much of this discussion is probably beyond the understanding of any but sorting experts and afficionados enough of it adequately explains the basic ideas behind SpreadSort for those who understand and have knowledge of basic sorting ideas and popular sorting techniques. 2) An important issue is the need for the Sorting library to provide extensive timing charts/tables comparing SpreadSort to at least std::sort ( and possibly other popular mainstream sorts ) with both different numbers of sort keys and different initial unsorted distributions. Steven Ross has been providing these charts/tables in the 'develop' branch of the library. 3) Connected to the previous issue is that a number of reviewers asked for better documentation on the conditions in which SpreadSort will show a marked improvement in speed compared to std::sort, as well as any condition(s) where SpreadSort performs worse than std::sort. While Steven Ross has explained that generally SpreadSort will fall back to using std::sort for some cases ( low N ), I too feel that the documentation needs to be more extensive for the average user in attempting to delineate the conditions where SpreadSort works best. 4) A really important issue discussed by a number of reviewers involves the creation of a synthetic radix, where most users of sorting algorithm are used to comparison based sorting functors. While the documentation provides information on the various individual sorts, as well as examples, I also feel that a discussion in the documentation of how to use SpreadSort when sorting structs/classes with multiple keys of different types would be invaluable. In other words, what and if are the common techniques for using SpreadSort with complicated keys which, when using comparison-based sorting, can be represented fairly easily be a functor. 5) Niall Douglass brought up the issue of exception guarantees when using SpreadSort, and I concur. The documentation should be stronger specifying what happens during the sorting algorithms if an exception occurs and/or does the sorting algorithm itself ever throw any exceptions and, if so, under what conditions. Steven Ross mentioned that he is adding exception guarantee information to his docs. 6) Many reviewers did not like the idea that the library should be called Sort when it is basically implementing a single sorting algorithm called SpreadSort. Alternate suggestions are: a) The library should be called SpreadSort. b) The library can be called Sort only if other sorting algorithms are added to it. c) The library can be called Sort with the proviso that it serves as a general library for sorting algorithms potentially added to it in the future. d) The library should be part of the Boost Algorithm library. Steven Ross mentioned other potential sorting implementations as part of the Sort library, under that general name, but all providing a good deal of extra work. These included a copy-based stable sorting algorithm, an LSD radix sorting, and an OpenMP based parallel implementation. Other reviewers mentioned some of the same types of sorting implementations and a few reviewers remarked that they also have created sorting implementations of their own. While I will give my own view at the end, I would like to mention here that I strongly believe that each sorting implementation needs to be reviewed separately for acceptance into Boost and never automatically added to a general library, whether it be called Sort or Algorithm or whatever. 7) Random issues brought up in comments I will mention, which have importance but which I do not believe are absolutely intrinsic yet still might be considered. a) C++11 techniques in general and inline namespaces in particular. b) A version that can work with less than random access. c) Optimizations for small sets of data ( Steven Ross has already addressed this to an extent in the 'developer' branch of the library ). d) Possible documentation of using SpreadSort as a subsort for parallel sorting techniques and possible discusion in the docs about Spreadort and parallel sorts. e) General O() information in docs. f) SpreadSort examples hoisted directly into docs using Quickbook technique and updating the Spreadort docs to use Quickbook. Review Result: Based on the voting for acceptance or not, based on the discussions during the review period, and based on Steven Ross's responses, I have decided that Steven Ross's library should be accepted into Boost. My main reason for my decision, aside from the votes and comments and specific issues discussed, is twofold: 1) There is a general consensus that Steven Ross has an excellent understanding of sorting techniques and algorithms and will support and refine his library for the benefit of programmers. 2) The empirical tests show that SpreadSort offers an improvement over std::sort, significantly in the area of large data sets, and this could be a major benefit to programmers. I do not know if the review manager has a say in this but based on the remarks of the reviewers I would like to see the library as accepted be named 'SpreadSort' rather than just 'Sort'. I do think that Boost can have a library called 'Sort' but I agree with the general consensus that a 'Sort' library needs more than one type of sorting algorithm. I would like to see other people, who mentioned in the reviews/comments that they have their own sorting implementation, also submit their own implementations to Boost and, if this happens and they are accepted, I can see combining them with 'SpreadSort' into a general Boost sorting library called 'Sort' in the future.

10 26

Re: [boost] Boost 1.57 hot-out-of-Git fails to compile for Windows Phone
by Moshe Rubin 04 Dec '14

04 Dec '14

To simplify reproducing the problem, run "b2" rather than the more complicated "b2 toolset=msvc-12.0 ... stage", same problem occurs. Bottom line: a clean clone of Boost 1.57, with the command "b2", fails with the same error. Moshe

2 1

Boost 1.57 hot-out-of-Git fails to compile for Windows Phone
by Moshe Rubin 04 Dec '14

04 Dec '14

I cloned Boost 1.57 from GitHub, intending to run b2 with the appropriate options to build libraries for Windows Phone. I understand that Steven Gates's pull requests for Windows Phone have already been merged in. Running the appropriate "b2" command fails with an error message. Can you help? Here are the steps I took (I'm running MSVC 2013, so I've got all required libs etc.): (*) Clone Boost 1.57 from GitHub (*) cd to the boost folder (*) Execute "bootstrap" (*) Execute "b2 headers" (*) Execute "b2 toolset=msvc-12.0 windows-api=phone architecture=arm link=static variant=debug debug-symbols=on debug-store=database stage" I get the following output: ============================================================================= Performing configuration checks - symlinks supported : no (cached) - junctions supported : yes (cached) - hardlinks supported : yes (cached) - 32-bit : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : no - iconv (libc) : no - iconv (separate) : no - icu : no - icu (lib64) : no - message-compiler : yes - gcc visibility : no - long double support : no warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. error: Name clash for '<pstage\lib>libboost_system-vc120-mt-gd-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompabile properties: error: error: - <warnings>all error: - <address-model>32 <warnings>on error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. ============================================================================= When I examine the generated file bin.v2\project-cache.jam, I see that "set junctions" and "set hardlinks" commands are duplicated for "<windows-api>phone", where the only difference between them is "<warnings>on" and "<warnings>all", possibly causing the error messages: <snippet> set "symlinks supported-<abi>ms-<architecture>arm...-<warnings>on-<windows-api>phone" : "false" ; set "junctions supported-<abi>ms-<architecture>arm...-<warnings>on-<windows-api>phone" : "true" ; set "hardlinks supported-<abi>ms-<architecture>arm...-<warnings>on-<windows-api>phone" : "true" ; set "symlinks supported-<abi>ms-<architecture>arm...-<warnings>all-<windows-api>phone" : "false" ; set "junctions supported-<abi>ms-<architecture>arm...-<warnings>all-<windows-api>phone" : "true" ; set "hardlinks supported-<abi>ms-<architecture>arm...-<warnings>all-<windows-api>phone" : "true" ; </snippet> (1) Why are the first three statements duplicated for windows-api=phone? (2) Why does <warnings> differ between them? (3) Where in Boost.Build is this generated? (4) How can I solve the problem and move forward? Many thanks in advance, Moshe

3 2

[range] insert not returning value for associative containers without 'before' iterator
by Adam D. Walling 04 Dec '14

04 Dec '14

The modification to boost/range/algorithm_ext/insert.hpp added an insert overload which does not take a 'before' iterator, but the implementation fails to return the Container passed in as it is supposed to. This causes the compiler to fail (eg with error C4716 must return a value in MSVC). https://svn.boost.org/trac/boost/ticket/6726 Fix is to simply add 'return on': template< class Container, class Range > inline Container& insert( Container& on, const Range& from ) { BOOST_RANGE_CONCEPT_ASSERT(( ForwardRangeConcept<Container> )); BOOST_RANGE_CONCEPT_ASSERT(( SinglePassRangeConcept<Range> )); on.insert(boost::begin(from), boost::end(from)); + return on; } Admittedly I am uncertain how bugs are being tracked now; is trac still being used or something on github? Thanks, Adam D. Walling

2 1

[VC++ 14.0 preview] New failures in develop regression tests
by Beman Dawes 03 Dec '14

03 Dec '14

At my request, Tom Kent has kindly added VC++ 14.0 (toolset msvc-14.0) to his develop branch tests. See http://www.boost.org/development/tests/develop/developer/summary.html rightmost column. This compiler is available as part of the Visual Studio 2015 Preview. See http://www.visualstudio.com/en-us/downloads/visual-studio-2015-downloads-vs… Several libraries are showing new test failures. Please check out the test results to see if your library has started to fail. If it is your problem, fix it or at least create a ticket for yourself:-) If it is a Microsoft problem, consider submitting a bug report and posting a notice on the Boost list so that other developers are aware of the problem. Also post a link to the bug report on https://connect.microsoft.com Knowing the Microsoft Connect URL for the bug report lets other boosters up vote the importance of the issue. This is known to have at least some influence on the priority given the bug report, and that means faster fixes for the bugs boosters care about. Thanks, --Beman

6 9

GDB-like debugger for template metaprograms
by Abel Sinkovics 03 Dec '14

03 Dec '14

Hi, Metashell 2.0.0 has a template metaprogram debugger with a GDB-like interface (thanks to András Kucsma), which can be useful for Boost developers. It can show you how your metaprogram is executed step-by-step. You can set breakpoints, step into or over the metafunction calls and inspect the "template metaprogramming stack trace" at any point during this: the chain of recursive template instantiations that lead to that point. Here is an example: > #include <boost/mpl/transform.hpp> > #include <boost/mpl/vector_c.hpp> > #include <boost/mpl/plus.hpp> > #include <boost/mpl/lambda.hpp> > #include <boost/mpl/int.hpp> > using namespace boost::mpl; > #msh mdb transform<vector_c<int, 1, 2, 3, 4, 5>, plus<_1, int_<1>>>::type For help, type "help". Metaprogram started (mdb) rbreak ^boost::mpl::plus Breakpoint "^boost::mpl::plus" will stop the execution on 25 locations (mdb) continue Breakpoint "^boost::mpl::plus" reached boost::mpl::plus<mpl_::integral_c<int, 1>, mpl_::int_<1>, mpl_::na, mpl_::na, mpl_::na> (Memoization) (mdb) bt #0 boost::mpl::plus<mpl_::integral_c<int, 1>, mpl_::int_<1>, mpl_::na, mpl_::na, mpl_::na> (Memoization) #1 boost::mpl::quote_impl<boost::mpl::plus<mpl_::integral_c<int, 1>, mpl_::int_<1>, mpl_::na, mpl_::na, mpl_::na>, true> (TemplateInstantiation) #2 boost::mpl::quote5<plus, mpl_::void_>::apply<mpl_::integral_c<int, 1>, mpl_::int_<1>, mpl_::na, mpl_::na, mpl_::na> (TemplateInstantiation) #3 boost::mpl::apply_wrap5<boost::mpl::quote5<plus, mpl_::void_>, mpl_::integral_c<int, 1>, mpl_::int_<1>, mpl_::na, mpl_::na, mpl_::na> (TemplateInstantiation) ... #19 transform<vector_c<int, 1, 2, 3, 4, 5>, plus<_1, int_<1>>>::type You can try Metashell from your browser: http://abel.web.elte.hu/shell Or you can install it on your computer: https://github.com/sabel83/metashell#version-200 Binary installers are available for a number of Linux distributions, Windows and Mac OS X. Feedback is welcome. Regards, Ábel

7 15

Submit Changes for VxWorks
by Rogerio dos Santos 01 Dec '14

01 Dec '14

Dear Group, I am using boost on the current VxWorks platform and in order to get some of the libraries properly compiled I had to change some of the boost source code by considering certain includes when compiling for VxWorks. I would like to submit those changes however I am not aware of the procedure should I do to get those changes reviewed and properly available on the boost source control. Please can anyone let me know what should I do to submit those changes? Thanks in advance for your help. Roger.

2 1

boost::async documentation
by Aaron Levy 29 Nov '14

29 Nov '14

I did not see any explicit documentation of the boost::async template although I see some mention of it since Boost 1.53. Is there some cohesive documentation which lists: 1. The macros needed to enable the functionality if any. 2. Details of behavior and limitations. 3. Differences in behavior wrt std::async. -- Aaron Levy aaron.levy(a)yandex.com

2 1

boost.context cause strange crash on certan WIN32 API
by microcai 29 Nov '14

29 Nov '14

Hi, I was using Boost.Asio.Spawn happliy until I ported my project to windows. I got stange openssl crash. many debug days speeded and there was nothing wrong with openssl. Strange thing is, openssl didn't crash when used in normal code, unless I used them in asio stackful coroutine. Now I finnally find the root cause and make it 100% reproducible. here is the code that demostrade the crash: <code> boost::context::fcontext_t fcm,fc1; void f1(intptr_t) { HMODULE advapi = LoadLibrary(TEXT("advapi32")); // crash there FreeLibrary(advapi); boost::context::jump_fcontext(fc1, &fcm, 0); } std::thread([](){ boost::context::guarded_stack_allocator alloc; std::size_t size(8192); void* sp1(std::malloc(size)); fc1=boost::context::make_fcontext(sp1, size, f1); boost::context::jump_fcontext(&fcm, fc1, 0); }); </code> the context created in threads other that main thread, can't call certain APIs. If LoadLibrary get called by an context that created in thread, it will crash. 100% reproducible on WIN64 platform with MSVC2013. And nothing wrong on WIN32 !

2 2

[Boost.Convert] Specify input using iterators
by Marius Dobrea 28 Nov '14

28 Nov '14

Hi Vladimir, While reading the Boost.Convert documentation last night there were some questions which came to my mind: Have you considered using iterators (or ranges) to specify input? Would that be in the scope of your library? Also I note that the strtol() function returns the position of the first invalid character (endptr below): long int strtol (const char* str, char** endptr, int base); Could convert() provide the position where the conversion stopped? This would allow single pass parsing of some input data. Would a Converter callable with the following signature be useful? template<typename TypeOut, typename InputIterator> class Result { public: enum Errc { numeric_overflow, empty_range, invalid_character, ...}; // std::expected like function signatures here private: TypeOut value; int errors; InputIterator pos; }; template<typename TypeOut, typename InputIterator> void operator()(InputIterator begin, InputIterator end, Result<TypeOut, InputIterator>& result) const; Please let me know your thoughts. Thanks, Marius Dobrea

2 1

[optional] Safe optional
by Andrzej Krzemienski 28 Nov '14

28 Nov '14

Hi Everyone, I would like to run an idea through everyone in this list. There is a recurring complaint about Boost.Optional that it allows you to do "unsafe" things: 1. Inadvertent mixed comparisons between T and optional<T> 2. Unintended conversion from T to optional<T> 3. "Unchecked" access to the contained object, which causes an UB when performed on an uninitialized optional object. There are valid reasons why optional is defined the way it is defined. But at the same time the complaints above are also valid. This makes some people abandon Boost.Optional and use their own alternative. My idea is to provide another type wrapper, say safe_optional<T>, that would choose different tradeoffs: prefer "safety" to some flexibility and/or efficiency. It would probably be part of Boost.Optional library as the implementation can be reused - only the interface would be changed. One downside of this solution is that we would have two libraries for doing nearly the same thing, which could "scatter" the community. There is a value for standardizing certain things and making them universal. I would like to solicit your feedback. Regards, &rzej

18 84

Explicit conversions to a contextual target type (was [optional] operator<(optional<T>, T) -- is it wrong?)
by Vicente J. Botet Escriba 27 Nov '14

27 Nov '14

Le 26/11/14 12:00, Vladimir Batov a écrit : I have started a new thread to try to clarify what I have in my mind. >> ... I'm looking on how all these conversions can be made safer. >> ... > OK, Vicente, my most humble apologies for snipping all the stuff you typed > that flew right over my head and made me feel stupid. I have to be brutally > honest I did not understand your "idea to state explicitly that you want a > explicit conversion but don't state to what" and your "implicit explicit > conversion thing". You obviously put a lot of thought into it but I > personally did not get *what problem* exactly you are trying to solve. I > personally do not feel there is a conversion-related problem that needs > fixing... On the other hand I do not know Haskell, so it may well be that I > do not know what I am missing. :-) I just hope that other people you'll > present your idea to will be smarter than me to appreciate it. Do you have > any links to slow-pace tutorial/explanation/justification of what you are > trying to propose that I could peruse without hurry? > > I will try again, but I'm not sure I will be clearer this time :( NOTE: this has nothing to be with a library solution, not with the current C++ language, and so it could be out of the scope of this ML. Please, skip this post if you are not concerned by how other language can influence C++. Just 3 references to Haskell * http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictu… * http://en.wikibooks.org/wiki/Haskell/Understanding_monads * https://www.haskell.org/haskellwiki/Polymorphism C++ doesn't takes in account the result type of a function during overload resolution. This has its advantages and liabilities. Consider the following situation. Given void f(W<T>); template <template<class> class B, class A> B<A> make(A v) { return B<A>(v); } It seems reasonable to define a function void g(X x) { f(make<W>(x)); } Here we are conveying the context via the template class W, that is, we are explicit about the context. Consider now a system on which the overload resolution takes in account the target type. Let me use [] instead of () to wrap the function parameters and arguments for this kind of functions so that we can identify them in an easy way. First of all we need to identify the context on which the function has a sens. Let me call this construction just *context*. template <template <class> class B> * context* Builder { template <class T> B<T> make [ T v ]; }; The function 'make' has only one argument, but its result type depends on the context. void g(X x) { f( make[x] ); } The result of make[x] has no sens if we don't know what the target type is. In the expression f( make [x] ) the target of the expression make [x] is W<X> and the context would be W. So the overload that will be taken would be Builder<W>::make[X]. We need to say what Builder<W>::make[X] means, if it would even has a meaning. In order to give a meaning to this expression we need to map W as a builder * template <> context* Builder<W> { template <class T> W<T> make [ T v ] { return whatever_you_want_that_returns_w_t(c); } }; Note that in Haskell the keywords are class for context, and instance for context_map. In some way, we could say that Builder is a type-class having types as instances, and a type belong to this type-class if there is an explicit mapping. This has a lot to be with the abandoned Concept-0x proposal, which was based on signature mapping. The current C++ Concept Lite trend is to have a default mapping for those types that satisfy a set of some syntactical constraint. I think that we could build something similar to Concept-0x on top of Concept Lite, but of course without the help of the language it would be more verbose as we will need to add an indirection. There are also some similarities with the object oriented approach, but instead of having an explicit object you have an deduced context that determines the function to call using static polymorphism. This kind of polymorphism is called ad-hoc polymorphism in the literature an in particular it is used in Haskell and Rust. Another example, this time with a variable * context* ProbablyValued PV { // constructors PV make [ ValueType<PV> v ]; constexpr PV none; // accessors ... }; Ad-hoc polymorphism has its own liabilities also of course. Best, Vicente P.S. I'm not serious. Having another way to do polymorphic calls in c++ is not reasonable, or is it?

1 0

[review] Sort library review manager results
by Edward Diener 26 Nov '14

26 Nov '14

This is the results from the recent review of the Sort library of Steven Ross. First I would like to thank all those who made comments during the review, whether or not they officially gave a final Yes or No vote to whether the Sort library should be accepted as a Boost library. This list includes: Niall Douglas, Julian Gonggrijp, Phil Endecott, Vladimir Prus, Mathias Gaunard, Jeremy Murphy, Peter Dimov, Robert Ramey, Adam Walling, Anthony Polukhin, Phil Endecott, Paul Bristow, Thijs (M.A.) van den Berg Dupuis Etienne, and Frank Gennari If I have missed anyone I do apologize. Secondly I would like to thank Steven Ross for patiently answering all of the review comments to the best of his ability. My tally of Yes and No votes for acceptance are: Yes votes (5) : Niall Douglas ( conditional ), Julian Gonggrijp ( conditional ), Frank Gennari, Phil Endecott, Paul Bristow. No votes (3) : Vladimir Prus, Adam Walling ( conditional ), Anthony Polukhin I believe the condtional Yes vote from Julian Gonggrijp was completely met in the discussions of issues with Steven Ross and the conditional Yes vote from Niall Douglass was almost completely met in the discussion with Steven Ross about the issues mentioned. I want to also mention that the conditional No vote by Adam Walling has an implied Yes vote to it if the Sort library were one among other sort implementations. Since my final decision is not entirely based on the Yes and No votes I want to adumbrate some of the major issues brought up by the review without necessarily focussing on every one of the people who brought them up initially, as well as my own reactions to them as Review Manager. 1) The first major issue was whether a library whose basic merit lies in its algorithm and its speed/space constraints needs better theoretical backing. A number of reviewers discussed this after it was brought up. I tend to agree with reviewers that while the best theoretical basis is always desirable, it is not necessary for a Boost library whose empirical evidence can be and has been measured by its implementor and can be measured by any user. Furthermore Steven Ross has provided an extensive discussion in his documentation, as well as his original paper, about the theoretical merits of his technique. While much of this discussion is probably beyond the understanding of any but sorting experts and afficionados ( I am neither ) enough of it adequately explains the basic ideas behind SpreadSort for those who understand and have knowledge of basic sorting ideas and popular sorting techniques ( that's my province ). 2) An important issue is the need for the Sorting library to provide extensive timing charts/tables comparing SpreadSort to at least std::sort ( and possibly other popular mainstream sorts ) with both different numbers of sort keys and different initial unsorted distributions.

1 1

Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
by Felix Uhl 26 Nov '14

26 Nov '14

Vincente J. Botet Escriba wrote: >I hope it is clear now that I don't want to change optional but see what >the safer optional could be with the ongoing C++ proposals. Fair enough, different users want different behaviour, but how is optional not safe in any way? operator<(optional<T>, T) does not throwing any kinds of exceptions when operator<(T,T) doesn’t, does it? --- Felix Uhl

2 1

[boost config] BOOST_NO_CXX11_HDR_CODECVT question
by Robert Ramey 26 Nov '14

26 Nov '14

I'm building on Mac OS with Xcode. The following test program seems to demonstrate a problem either with config or my understanding of it. <code> #include <codecvt> #include <boost/config.hpp> #ifdef BOOST_NO_CXX11_HDR_CODECVT #pragma message "no C++ codevt support" #endif #include "../../../libs/config/test/config_info.cpp" </code> When I compile the following I get a compile time message "no C++ codevt support" which is NOT what I expect to see. This surprises me since if the message is correct, I would expect the compile would fail at that #include <codecvt> statement. When I run the program I get: Clang version 6.0 (clang-600.0.54) __cplusplus =199711L __STDC__ =1 __GNUC__ =4 __GNUC_MINOR__ =2 __GNUC_PATCHLEVEL__ =1 __GNUG__ =4 __VERSION__ ="4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54)" __REGISTER_PREFIX__ [no value] __USER_LABEL_PREFIX__ =_ __EXCEPTIONS =1 __GXX_RTTI =1 __LP64__ =1 __MACH__ =1 __APPLE__ =1 __APPLE_CC__ =6000 __STDC_HOSTED__ =1 ********************************************************************* libc++ version 1101 _LIBCPP_VERSION =1101 ********************************************************************* Detected Platform: Mac OS Type char is signed Type wchar_t is signed byte order for type short =0 8 byte order for type int =0 8 16 24 byte order for type long =0 8 16 24 32 40 48 56 sizeof(wchar_t) =4 sizeof(short) =2 sizeof(int) =4 sizeof(long) =8 sizeof(size_t) =8 sizeof(ptrdiff_t) =8 sizeof(void*) =8 sizeof(void(*)(void)) =8 sizeof(float) =4 sizeof(double) =8 sizeof(long double) =16 CHAR_BIT =8 CHAR_MAX =127 WCHAR_MAX =2147483647 SHRT_MAX =32767 INT_MAX =2147483647 LONG_MAX =9223372036854775807L LLONG_MAX =0x7fffffffffffffffLL LONG_LONG_MAX =9223372036854775807LL ULLONG_MAX =0xffffffffffffffffULL ULONG_LONG_MAX =(9223372036854775807LL*2ULL+1ULL) _POSIX_ADVISORY_INFO =(-1) _POSIX_ASYNCHRONOUS_IO =(-1) _POSIX_BARRIERS =(-1) _POSIX_CHOWN_RESTRICTED =200112L _POSIX_CLOCK_SELECTION =(-1) _POSIX_CPUTIME =(-1) _POSIX_FSYNC =200112L _POSIX_JOB_CONTROL =200112L _POSIX_MAPPED_FILES =200112L _POSIX_MEMLOCK =(-1) _POSIX_MEMLOCK_RANGE =(-1) _POSIX_MEMORY_PROTECTION =200112L _POSIX_MESSAGE_PASSING =(-1) _POSIX_MONOTONIC_CLOCK =(-1) _POSIX_NO_TRUNC =200112L _POSIX_PRIORITIZED_IO =(-1) _POSIX_PRIORITY_SCHEDULING =(-1) _POSIX_RAW_SOCKETS =(-1) _POSIX_READER_WRITER_LOCKS =200112L _POSIX_REALTIME_SIGNALS =(-1) _POSIX_REGEXP =200112L _POSIX_SAVED_IDS =200112L _POSIX_SEMAPHORES =(-1) _POSIX_SHARED_MEMORY_OBJECTS =(-1) _POSIX_SHELL =200112L _POSIX_SPAWN =(-1) _POSIX_SPIN_LOCKS =(-1) _POSIX_SPORADIC_SERVER =(-1) _POSIX_SYNCHRONIZED_IO =(-1) _POSIX_THREAD_ATTR_STACKADDR =200112L _POSIX_THREAD_ATTR_STACKSIZE =200112L _POSIX_THREAD_CPUTIME =(-1) _POSIX_THREAD_PRIO_INHERIT =(-1) _POSIX_THREAD_PRIO_PROTECT =(-1) _POSIX_THREAD_PRIORITY_SCHEDULING =(-1) _POSIX_THREAD_PROCESS_SHARED =200112L _POSIX_THREAD_SAFE_FUNCTIONS =200112L _POSIX_THREAD_SPORADIC_SERVER =(-1) _POSIX_THREADS =200112L _POSIX_TIMEOUTS =(-1) _POSIX_TIMERS =(-1) _POSIX_TRACE =(-1) _POSIX_TRACE_EVENT_FILTER =(-1) _POSIX_TRACE_INHERIT =(-1) _POSIX_TRACE_LOG =(-1) _POSIX_TYPED_MEMORY_OBJECTS =(-1) _POSIX_VDISABLE =((unsigned char)'\377') _POSIX_VERSION =200112L _POSIX2_C_BIND =200112L _POSIX2_C_DEV =200112L _POSIX2_CHAR_TERM =200112L _POSIX2_FORT_DEV =(-1) _POSIX2_FORT_RUN =200112L _POSIX2_LOCALEDEF =200112L _POSIX2_PBS =(-1) _POSIX2_PBS_ACCOUNTING =(-1) _POSIX2_PBS_CHECKPOINT =(-1) _POSIX2_PBS_LOCATE =(-1) _POSIX2_PBS_MESSAGE =(-1) _POSIX2_PBS_TRACK =(-1) _POSIX2_SW_DEV =200112L _POSIX2_UPE =200112L _POSIX2_VERSION =200112L _V6_ILP32_OFF32 =(-1) _V6_ILP32_OFFBIG =(1) _V6_LP64_OFF64 =(1) _V6_LPBIG_OFFBIG =(1) _XBS5_ILP32_OFF32 =(-1) _XBS5_ILP32_OFFBIG =(1) _XBS5_LP64_OFF64 =(1) _XBS5_LPBIG_OFFBIG =(1) _XOPEN_CRYPT =(1) _XOPEN_ENH_I18N =(1) _XOPEN_LEGACY =(-1) _XOPEN_REALTIME =(-1) _XOPEN_REALTIME_THREADS =(-1) _XOPEN_SHM =(1) _XOPEN_STREAMS =(-1) _XOPEN_UNIX =(1) _XOPEN_VERSION =600 ********************************************************************* Boost version 105700 BOOST_USER_CONFIG =<boost/config/user.hpp> BOOST_COMPILER_CONFIG ="boost/config/compiler/clang.hpp" BOOST_STDLIB_CONFIG ="boost/config/stdlib/libcpp.hpp" BOOST_PLATFORM_CONFIG ="boost/config/platform/macos.hpp" BOOST_HAS_THREADS [no value] BOOST_DEDUCED_TYPENAME =typename BOOST_HAS_DIRENT_H [no value] BOOST_HAS_EXPM1 [no value] BOOST_HAS_GETTIMEOFDAY [no value] BOOST_HAS_INT128 [no value] BOOST_HAS_LOG1P [no value] BOOST_HAS_LONG_LONG [no value] BOOST_HAS_NANOSLEEP [no value] BOOST_HAS_NL_TYPES_H [no value] BOOST_HAS_NRVO [no value] BOOST_HAS_PARTIAL_STD_ALLOCATOR [no value] BOOST_HAS_PTHREADS [no value] BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE [no value] BOOST_HAS_SCHED_YIELD [no value] BOOST_HAS_SIGACTION [no value] BOOST_HAS_STDINT_H [no value] BOOST_HAS_UNISTD_H [no value] BOOST_MSVC6_MEMBER_TEMPLATES [no value] BOOST_NO_CXX11_ADDRESSOF [no value] BOOST_NO_CXX11_ALIGNAS [no value] BOOST_NO_CXX11_ALLOCATOR [no value] BOOST_NO_CXX11_ATOMIC_SMART_PTR [no value] BOOST_NO_CXX11_AUTO_DECLARATIONS [no value] BOOST_NO_CXX11_AUTO_MULTIDECLARATIONS [no value] BOOST_NO_CXX11_CHAR16_T [no value] BOOST_NO_CXX11_CHAR32_T [no value] BOOST_NO_CXX11_CONSTEXPR [no value] BOOST_NO_CXX11_DECLTYPE [no value] BOOST_NO_CXX11_DECLTYPE_N3276 [no value] BOOST_NO_CXX11_DEFAULTED_FUNCTIONS [no value] BOOST_NO_CXX11_DELETED_FUNCTIONS [no value] BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS [no value] BOOST_NO_CXX11_FINAL [no value] BOOST_NO_CXX11_FIXED_LENGTH_VARIADIC_TEMPLATE_EXPANSION_PACKS [no value] BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS [no value] BOOST_NO_CXX11_HDR_ARRAY [no value] BOOST_NO_CXX11_HDR_ATOMIC [no value] BOOST_NO_CXX11_HDR_CHRONO [no value] BOOST_NO_CXX11_HDR_CODECVT [no value] BOOST_NO_CXX11_HDR_CONDITION_VARIABLE [no value] BOOST_NO_CXX11_HDR_FORWARD_LIST [no value] BOOST_NO_CXX11_HDR_FUNCTIONAL [no value] BOOST_NO_CXX11_HDR_FUTURE [no value] BOOST_NO_CXX11_HDR_INITIALIZER_LIST [no value] BOOST_NO_CXX11_HDR_MUTEX [no value] BOOST_NO_CXX11_HDR_RANDOM [no value] BOOST_NO_CXX11_HDR_RATIO [no value] BOOST_NO_CXX11_HDR_REGEX [no value] BOOST_NO_CXX11_HDR_SYSTEM_ERROR [no value] BOOST_NO_CXX11_HDR_THREAD [no value] BOOST_NO_CXX11_HDR_TUPLE [no value] BOOST_NO_CXX11_HDR_TYPEINDEX [no value] BOOST_NO_CXX11_HDR_TYPE_TRAITS [no value] BOOST_NO_CXX11_HDR_UNORDERED_MAP [no value] BOOST_NO_CXX11_HDR_UNORDERED_SET [no value] BOOST_NO_CXX11_INLINE_NAMESPACES [no value] BOOST_NO_CXX11_LAMBDAS [no value] BOOST_NO_CXX11_LOCAL_CLASS_TEMPLATE_PARAMETERS [no value] BOOST_NO_CXX11_NOEXCEPT [no value] BOOST_NO_CXX11_NON_PUBLIC_DEFAULTED_FUNCTIONS [no value] BOOST_NO_CXX11_NULLPTR [no value] BOOST_NO_CXX11_NUMERIC_LIMITS [no value] BOOST_NO_CXX11_RANGE_BASED_FOR [no value] BOOST_NO_CXX11_RAW_LITERALS [no value] BOOST_NO_CXX11_REF_QUALIFIERS [no value] BOOST_NO_CXX11_RVALUE_REFERENCES [no value] BOOST_NO_CXX11_SCOPED_ENUMS [no value] BOOST_NO_CXX11_SMART_PTR [no value] BOOST_NO_CXX11_STATIC_ASSERT [no value] BOOST_NO_CXX11_STD_ALIGN [no value] BOOST_NO_CXX11_TEMPLATE_ALIASES [no value] BOOST_NO_CXX11_TRAILING_RESULT_TYPES [no value] BOOST_NO_CXX11_UNICODE_LITERALS [no value] BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX [no value] BOOST_NO_CXX11_USER_DEFINED_LITERALS [no value] BOOST_NO_CXX11_VARIADIC_TEMPLATES [no value] BOOST_NO_MS_INT64_NUMERIC_LIMITS [no value] BOOST_NO_STD_MESSAGES [no value] BOOST_STD_EXTENSION_NAMESPACE =std BOOST_UNREACHABLE_RETURN(0) [no value] BOOST_CONSTEXPR [no value] BOOST_CONSTEXPR_OR_CONST =const BOOST_STATIC_CONSTEXPR =static const BOOST_NOEXCEPT [no value] BOOST_FORCEINLINE =inline __attribute__ ((__always_inline__)) BOOST_NOINLINE =__attribute__ ((__noinline__)) BOOST_FALLTHROUGH =((void)0) Program ended with exit code: 0 which also surprises me as I was under the impression that my compiler implements all of C++11 library standard Any help appreciated, Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/boost-config-BOOST-NO-CXX11-HDR-CODECVT-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 1

Template Help
by john.klein＠genovatech.com 26 Nov '14

26 Nov '14

All, I've gotten rusty over the years and decided to create an application for myself to knock some of the rust off. I've worked with projects that have used boost in the past and I'm wanting to use it as much as possible here. I'm using VS2013 with the 64bit 1.57.0 boost libraries, so I have access to the newer c++ standard. Can someone please show me how to get the following to compile? Please ignore the functionality of the code, this is just something I quickly put together to demo my issue. SafeList.h #pragma once #include <list> #include <boost/thread/mutex.hpp> template <typename dataType> using CallbackType = bool(*)(dataType); template <typename dataType> class SafeList { public: SafeList() : list(), mutex() { } ~SafeList() { boost::mutex::scoped_lock scoped_lock(mutex); } void Add(dataType data) { boost::mutex::scoped_lock scoped_lock(mutex); list.push_back(data); } void Remove(dataType data) { boost::mutex::scoped_lock scoped_lock(mutex); list.remove(data); } void IterateList(CallbackType<dataType> callback) { boost::mutex::scoped_lock scoped_lock(mutex); for (int i = 0, bool flag = true; i < list.size() && flag; i++) { flag = callback(list[0]); } } private: std::list<dataType> list; boost::mutex mutex; }; FileList.h #pragma once #include "SafeList.h" #include "File.h" #include <boost/shared_ptr.hpp> typedef boost::shared_ptr<File> FilePtr; class FileList { public: FileList(); ~FileList(); void Add(FilePtr); void ProcessList(); private: bool ProcessItem(FilePtr); SafeList<FilePtr> safeList; }; FileList.c #include "stdafx.h" #include "FileList.h" FileList::FileList() : safeList() { } FileList::~FileList() { } void FileList::Add(FilePtr filePtr) { safeList.Add(filePtr); } void FileList::ProcessList() { safeList.IterateList(this->ProcessItem); <-- This is the bad guy the compiler complains about and not sure how to resolve. } bool FileList::ProcessItem(FilePtr) { return true; } 1>------ Build started: Project: Download, Configuration: Debug x64 ------ 1> FileList.cpp 1>FileList.cpp(20): error C3867: 'FileList::ProcessItem': function call missing argument list; use '&FileList::ProcessItem' to create a pointer to member ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== Thanks, John Klein PMP(r) CSM(r) Programs/Engineer Manager Phone: (319) 378-8455 Cell: (319) 533-1476 [Description: Genova Tech NEW] www.genovatech.com<http://www.genovatech.com/> 4250 River Center Court NE Suite A Cedar Rapids, IA 52402 This message is covered by the Electronic Communication Privacy Act, 18 U.S.C. Sections 2510-2515, and is intended only for the use of the person to whom it is addressed and may contain information that is confidential. It should not be forwarded to anyone else. If you received this message and are not the addressee, you have received this message in error. Please notify the person sending the message and destroy your copy.

3 2

[optional] operator<(optional<T>, T) -- is it wrong?
by Andrzej Krzemienski 26 Nov '14

26 Nov '14

I moved this discussion from the other thread. > optional<double> Aircraft::weight() > { > if (Impl* impl = get_impl()) > return impl->compute_weight(); > else > return none; > } > > double Aircraft::max_weight() > { > return 10000.0; > } > > bool too_heavy(Aircraft& ac) > { > return ac.weight() > ac.max_weight(); > // this compiles and does the wrong thing > } > 1) When we are bringing T into the optional<T> land, we apply implicit > constructor. For example, we provide T to a function taking optional<T>. > Here, the direction of the conversion is unambiguous. Namely, T to > optional<T>. So, we apply it. > 2) When the direction of conversion is not as clear, we refuse applying it > and leave it to the user. op<(T, optional<T>) would be one such example. > > Oh, c'mon. Cheer up. Things are not as gloomy, are they. :-) Here the > subtlety (IMO) lies in how reasonable it is to add information. Namely, as > I indicated, if we bring T into the optional<T> fold, then we apply > optional<T> rules to T, i.e. apply t to optional<T> conversion. Say, we > have a mandarin and an orange. When we bring the mandarin to an orange > factory, then mandarin-to-orange "conversion" is applied and for all > purposes mandarin is a "small orange". Outside the factory, when we compare > mandarin to orange, it is not immediately clear what should be treated as > what. If we apply mandarin-to-orange "conversion", then it'll be "small > orange vs. big orange". If instead we apply orange-to-mandarin > "conversion", then it'll be "sweet mandarin vs. sour mandarin". Given the > library writer does not know, which it is, we ban it. Still not convinced? > I've spent all munition I had. :-) When you are talking about oranges and mandarins outside the context of C++, I am convinced. the problem I have is with mapping it onto C++ and the design of Optional. (1) In C++ we have the converting constructor. This appears close to what you call "bringing T into the optional<T> land", but I claim it is not the same. And the consequences of these nuance differences result in the problem in question. Perhaps the notion of "bringing T into the optional<T> land" would be better reflected by an explicit constructor, or function make_optional(). I am not saying that the converting constructor is wrong here. I am just saying that the motivation is *slightly* different than "bringing T into the optional<T> land", it is more for syntactic convenience, which is almost the same, but not same. (2) Your philosophy "when the direction of conversion is not as clear, we refuse applying it" -- there is no way to apply it within the definition of optional. We can apply it by poisoning every operation in the world that takes T or optional<T>. But that looks impractical. Back to Vicente's concern: User defining its own function > > void f(optional<T>, optional<T>); > > would need to add the following? > > void f(T, optional<T>) { BOOST_STATIC_ASSERT(); } > void f(optional<T>, T) { BOOST_STATIC_ASSERT(); } > > What if there are 3 optional parameters? We can not say to the user that > they need to program this way. > I do not think it has been addressed.

9 20

[Range] New I/O functions for ranges
by Indiana 25 Nov '14

25 Nov '14

I'm currently putting together a proposal to the standards committee about a set of range I/O functions, but i think they would make a good addition to Boost as well. They would probably fit in the Range library - i don't think they warrant a library all of their own. The stuff i wrote for the standards proposal is available at http://cpp.indi.frih.net/rangeio/ - it goes into quite a bit of detail about the interface, and links to a sample implementation. But here's the executive summary: There is a single output function - currently called "write_all" - that takes a range and, optionally, a delimiter, like this: // BEGIN CODE ///////////////////////// auto const r = std::array<int, 4>{1, 2, 3, 4}; cout << write_all(r); // prints "1234" cout << "{ " << write_all(r, ", ") << " }"; // prints "{ 1, 2, 3, 4 }" // END CODE /////////////////////////// It takes anything that works with range-for, so it works with range adaptors: // BEGIN CODE ///////////////////////// struct is_even { auto operator()(int x) const -> bool { return x % 2 == 0; } }; cout << write_all(r | reversed | filtered(is_even{})); // prints "42" // END CODE /////////////////////////// Note also that the delimiter doesn't have to be a string (there are some examples in the reference of that). Why not just use std::copy() and stream iterators? Several reasons - the most obvious of which you can see above: this syntax is much cleaner, much less error-prone, well-integrated with the existing stream I/O mechanisms, and it produces properly delimited output (unlike the delimited version of ostream_iterator). But also, stream formatting is properly handled: // BEGIN CODE ///////////////////////// auto const r = std::array<int, 3>{1, 2, 3}; std::cout.width(3); std::cout.fill('0'); // --------------------------- // The old way: using std::begin; using std::end; std::copy(begin(r), end(r), std::ostream_iterator<int>{std::cout, ", "}); // even with Boost.Range, this just reduces to: //boost::copy(r, std::ostream_iterator<int>{std::cout, ", "}); // prints: "001, 2, 3, " // --------------------------- // The new way: std::cout << write_all(r, ", "); // prints "001, 002, 003" // END CODE /////////////////////////// And of course this works as expected in chained expressions: // BEGIN CODE ///////////////////////// auto const r = array<int, 3>{1, 2, 3}; cout.width(3); cout.fill('0'); cout << '(' << setw(3) << setfill('0') << write_all(r, ',') << ')'; // prints: "(001,002,003)" // END CODE /////////////////////////// It is also possible to get more information about errors, and react better to them. If there is an error in the formatting or in the stream during an output operation using std::copy() and ostream_iterator, the algorithm will chug merrily along until it's all the way through the range even though it's no longer writing anything. You will have no way to detect where the problem occurred - did it fail after the first element was written, or *before*, or did it fail after the millionth element? If the range is begin lazy-generated, that could be particularly wasteful, or even problematic. By contrast, write_all() stops immediately when there is an error in the output stream. It is even possible get more information about the last range write operation by capturing the temporary object, like this: // BEGIN CODE ///////////////////////// auto const r = array<int, 3>{1, 2, 3}; auto p = write_all(r); cout << p; if (!cout) { cerr << "only " << p.count << " elements written\n"; cerr << "next element would have been " << *p.next << '\n'; } // END CODE /////////////////////////// On the input side, there are 7 functions: * overwrite * back_insert * front_insert * insert * back_insert_n * front_insert_n * insert_n Overwrite simply replaces the contents of a range with whatever is read from input: // BEGIN CODE ///////////////////////// auto r = array<int, 100>{}; cin >> overwrite(r); // reads up to 100 ints // END CODE /////////////////////////// The *insert functions map to the *insert_iterators in the standard library, using push_back(), push_front(), or insert(). In each case: in >> ???insert(r[, i]); is basically equivalent to: copy(istream_iterator<value_type_of_r>{in}, // use braces on the next line, or face the most vexing parse istream_iterator<value_type_of_r>{}, ???inserter(r[, i])); The *insert_n functions are for the common case where you know in advance how many elements will be read, at maximum - or for when you want to limit the amount of elements read in a single read operation. This: in >> ???insert_n(r[, i], n); is conceptually equivalent to: copy_n(istream_iterator<value_type_of_r>{in}, n, ???inserter(r[, i])); except it can handle formatting and errors properly. The reference at http://cpp.indi.frih.net/rangeio/ goes into much more detail, of course. Why add it to Boost? Because these operations (reading/writing ranges) are so common they are almost universal, and there is no standard facility that handles them easily or well. They are not *difficult* to implement, but they are far from trivial - for example, you might think write_all() is just a simple range-for loop or for_each(), and it is... up until you add error checking, the delimiter, and formatting awareness. A sample implementation already exists - it can be implemented portably in pure standard C++11. (Can it be implemented in C++03 with? Good question. It might be possible with some Boost help, but it might require dependencies on libraries other than Boost.Range. If this proposal finds approval, that's something i can look into.) Would there be any interest in adding these functions to Boost.Range?

5 13

[range][extensions] What is happening with the range extensions?
by Viktor Sehr 25 Nov '14

25 Nov '14

I really think boost range should be updated with the range extensions, what is happening with the review here? /Viktor

3 2

[range][extensions] Operator |+, isnt it possible to implement without this operator?
by Viktor Sehr 25 Nov '14

25 Nov '14

Looking at CppLinq, and C++ Streams (http://jscheiny.github.io/Streams/) it seems they both can handle lambda functions via one operator. Isn't it possible to do something like they do in range extensions? /Viktor

2 1

[Serialization] boost/strong_typedef.hpp vs. boost/serialization/strong_typedef.hpp
by Jonathan Jones 24 Nov '14

24 Nov '14

Hi folks, Does anyone know why boost/strong_typedef.hpp still exists with real content? Several years back, the version in the trunk was stubbed out: http://svn.boost.org/svn/boost/trunk/boost/strong_typedef.hpp but this change has not made it into any release. The version in serialization, however, is still being updated. Sincerely, Jonathan Jones

2 3

[dynamic_bitset] capacity(), reserve(), shrink_to_fit()
by Riccardo Marcangelo 24 Nov '14

24 Nov '14

Hi, I have implemented capacity(), reserve(), and shrink_to_fit() for dynamic_bitset. I find these useful and am surprised by their omission. I'm wondering if there is any interest in including them in Boost. Perhaps there are reasons why they're not implemented? Riccardo -- View this message in context: http://boost.2283326.n4.nabble.com/dynamic-bitset-capacity-reserve-shrink-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

Executable files in the boost tree
by Marshall Clow 24 Nov '14

24 Nov '14

Someone recently opened trac ticket #10813 (https://svn.boost.org/trac/boost/ticket/10813) with the description: > I recently updated Boost 1.57, I noticed that a few header files > "parameter.hpp" and some of those in the "parameter" directory has > permission 755 instead of normal 644. Why make these normal header files > executable? Since I built the release tarballs, I took this ticket and did some investigating. The OP is absolutely correct, these files should not have 755 perms. Unfortunately for me, I discovered: 1) These permissions were not modified during the build process, but are marked this way in git. 2) It’s not just the parameter library. I found about 1000 files marked as executable that shouldn’t be, and they were in the following libraries: asio assign bimap chrono concept_check foreach fusion gil graph iostreams lambda mpl msm numeric parameter polygon predef ptr_container python test thread type_traits typeof variant xpressive Some files (such as shell scripts, python sources, etc) *should* be marked executable, but others (.hpp files, jam files, HTML, png, etc) should not. I will deal with the libraries that are currently under the purview of the CMT (concept_check and mpl) I would appreciate if the maintainers of these libraries would clean this up before the Feb release. Also, I will be enhancing the “inspect” tool to report on these this week. — Marshall

1 0

Changes in Boost.Optional
by Dean Michael Berris 24 Nov '14

24 Nov '14

Suppose I have the following type: struct container { boost::optional<uint16_t> optional() const { return value_; } private: boost::optional<uint16_t> value_; }; struct value_wrapper { value_wrapper(const container& c) : c_(c) {} operator uint16_t () { return 1; } operator boost::optional<uint16_t>() { return c_.optional(); } private: const container& c_; }; And that I have the following function: value_wrapper value(const container& c) { return value_wrapper(c); } The following used to work in MSVC 2010: container c; // leave c.value_ alone. boost::optional<uint16_t> some_value = value(c); assert(!some_value); Now with Boost 1.56, this breaks because the constructor for some_value from a temporary optional is now marked explicit. What is the work-around for the previous behavior to be regained? All the following changes cause the assertion to fail: boost::optional<uint16_t> some_value(value(c)); assert(!some_value); // some_value's constructor will use the uint16_t conversion operator, therefore some_value == 1 boost::optional<uint16_t> some_value = static_cast<boost::optional<uint16_t> >(value(c)); assert(!some_value); // same problem as above, the temporary created will favor the uint16_t conversion operator Help? PS. For better context, see https://github.com/cpp-netlib/cpp-netlib/blob/0.11-devel/boost/network/prot…

8 26

[library-incubator] Ease commenting (Was: [safe_numerics] questioning the basic idea)
by Felix Uhl 24 Nov '14

24 Nov '14

Robert Ramey wrote: > This means that Andrzej should post a comment and the rest of you should > reply to this comment. > I realize that is is sort of pain, but, again, I would be very helpful to me > to test the idea of building and maintaining a libraries comment history in > an permanent convenient place. Have you thought about using the boost developers and users mailing list to get comments posted on bli? You could just run a script on a webserver that polls emails in the mailinglist and filters out those with a tag that contains the name of a library on the incubator in the title, which it then posts under said library as an anonymous comment, or a comment under the name of the poster, if he gives his ok in the mail (not the title) with a tag like [PostMyName] or [Name=”Pseudonym”]. The idea is to make commenting easier and less awkward by embedding it in the commenting and discussion framework boost developers and users already use, the mailing list. --- Felix Uhl

5 10

is_lexical_convertible
by endight . 24 Nov '14

24 Nov '14

Is there something like `boost::is_lexical_convertible` (like `boost::is_convertible`)?

3 2

Is there interest in a library for testing existence of a function member of class?
by 胡维 24 Nov '14

24 Nov '14

Hi, I am looking for how to test if a function member of class exist or not in compile time.I did not find a solution by google so I wrote a piece of code for it.Please let me know if it's already in boost. :) Synopsis class Bar { public: Bar(int); }; class Foo { public: Foo(int); int foo(Bar); }; // create struct 'has_foo' which is used to test function member 'foo'.HAS_FUNCTION_MEMBER(foo) int main() { assert((!has_foo<void(Bar::*)(Bar)>::value)); assert((has_foo<int(Foo::*)(Bar)>::value)); return 0; } The code is in my gisthttps://gist.github.com/wehu/1987f716074904d26cf0 The code only checks if the function is compatible with expected, but not require to be exact same. Thanks,Wei

6 11

[bli] category page blank
by Michael Caisse 24 Nov '14

24 Nov '14

I went here: http://rrsd.com/blincubator.com/listed-by-category/ which is blank. As a user, I am going to try and find libraries by category before I use their names. michael -- Michael Caisse ciere consulting ciere.com

2 2

[review] Formal review period for Sort library begins today, November 10, and ends Wednesday, November 19
by Edward Diener 23 Nov '14

23 Nov '14

The formal review of the Sort library by Steven Ross starts today, November 10 and is scheduled to continue through November 19th. About the Sort library ================== The Sort library is a library which implements hybrid sorting algorithms based on a Spreadsort ( http://en.wikipedia.org/wiki/Spreadsort ), of which the author of the library, Steven Ross, is the inventor. The algorithm provides a sort that is faster than O(n*log(n)). The library provides a generic implementation of high-speed sorting algorithms that outperform those in the C++ standard in both average and worst case performance. These algorithms only work on random access iterators. They are hybrids using both radix and comparison-based sorting, specialized to sorting common data types, such as integers, floats, and strings. These algorithms are encoded in a generic fashion and accept functors, enabling them to sort any object that can be processed like these basic data types. Where to get it =============== The library is available on github at https://github.com/spreadsort/sort. The library is in modular Boost format and can be cloned to libs/sort under your local modular boost directory. I have provided as the review manager online documentation at: http://eldiener.github.io/sort Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[sort]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 'eldiener at tropicsoft dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - 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. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome. I encourage all programmers with an interest or knowledge of sorting algorithms to be part of the review or discussion of the Sort library as your time permits.

13 41

FW:ibbeekman
by Hartmut Kaiser 22 Nov '14

22 Nov '14

http://forum.incadigital.com/iuz/zdhbcmdqmamibsfwolsdjrima.nbhjkshxjngcjxlj… Hartmut Kaiser

1 0

[Boost.DLL] Formal Review request
by Antony Polukhin 21 Nov '14

21 Nov '14

Dear Boost, Some time passed since checking interest in plugin development library and now all the requested features are implemented (self loading, getting symbol location, better docs, automatic platform-specific library decorations append, much more examples, listing library exports and so on...). While there's still some room for minor improvements, library API is stable and the library will benefit greatly from a larger user base and more feedback. So unless someone thinks the library isn't ready or would get rejected right away in its current state for reason X, I am requesting a formal review for Boost.DLL. Library location: https://github.com/apolukhin/Boost.DLL Library Docs: http://apolukhin.github.io/Boost.DLL/index.html -- Best regards, Antony Polukhin

10 40

[review] Formal review period for Sort library continuing through November 19
by Edward Diener 20 Nov '14

20 Nov '14

The formal review of the Sort library by Steven Ross, which started November 10 and is scheduled to continue through November 19th, begins its last 5 days today. We have had some great discussions and reviews so far and I would like to thank everybody involved. I would like to encourage all interested programmers, whether Boost developers or Boost users, to comment on and/or review the library. About the Sort library ================== The Sort library is a library which implements hybrid sorting algorithms based on a Spreadsort ( http://en.wikipedia.org/wiki/Spreadsort ), of which the author of the library, Steven Ross, is the inventor. The algorithm provides a sort that is faster than O(n*log(n)). The library provides a generic implementation of high-speed sorting algorithms that outperform those in the C++ standard in both average and worst case performance. These algorithms only work on random access iterators. They are hybrids using both radix and comparison-based sorting, specialized to sorting common data types, such as integers, floats, and strings. These algorithms are encoded in a generic fashion and accept functors, enabling them to sort any object that can be processed like these basic data types. Where to get it =============== The library is available on github at https://github.com/spreadsort/sort. The library is in modular Boost format and can be cloned to libs/sort under your local modular boost directory. I have provided as the review manager online documentation at: http://eldiener.github.io/sort Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[sort]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 'eldiener at tropicsoft dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - 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. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome.

6 18

[optional] How to define boost::none?
by Andrzej Krzemienski 20 Nov '14

20 Nov '14

Hi Everyone. I am puzzled with a tough development task. I wonder if anyone is able to find a good solution. I want to re-implement tag boost::none. The current implementation is using a pointer to member which allows a harmful conversion from literal 0. Try this: boost::optional<boost::rational<int>> orat = 0; // this creates a disengaged optional. I want to rewrite the definition with the following goals in mind: 1. boost::none_t is not implicitly convertible from literal 0; 2. The solution works in C++98 3. The solution is implementable in a header-only library. (defining some member variable in a CPP file is not an option. The only solution I was able to find so far is this: [code] struct none_t { enum creator_t {creator}; none_t(creator_t){} }; namespace { none_t none (none_t::creator); } [/code] It works, but I feel uncomfortable defining boost::none in every translation unit. Any better ideas are welcome. Regards, &rzej

6 14

[BGL] [push_relabel_max_flow] multigraphs ?
by Pablo Madoery 20 Nov '14

20 Nov '14

I was wondering if the push_relabel_max_flow algorithm can be used in multigraphs. I mean, can I have two vertices joined by two edges: one in a direction an the other in the opposite direction with equal capacities ( 1000 for example ). It is clear in the documentation that the reverse edge must exist for each edge in the graph, so there must be 4 edges in the case I am describing. but the question is: does the algorithm works properly for this case ?

1 0

Re: [boost] [library-incubator vs Developer's list] was Ease commenting (Was: [safe_numerics] questioning the basic idea)
by Felix Uhl 19 Nov '14

19 Nov '14

Robert Ramey wrote: >> True, but it doesn't immediately raise a discussion - a message posted >> here gets seen by quite a few people, hopefully some of whom will be >> motivated to respond. > Damn - I just can't win here! As I said in a previous post, this is the problem of the incubator, a lack of community. I know that it would be a lot of work, but your best bet is to build on the large mailing list community that already exists. > a) Boost (I believe) was conceived as a way to support C++ with expanded > libraries > which would eventually enter the standard. > b) It has largely fulfilled that purpose. Making the standard a lot bigger > will make > it every more difficult for vendors to supply a conforming implementation. > So I don't > think the standard library can grow a lot more. Thoughts like that seem to be preliminary to me. We shouldn’t stop thinking about new facilities. But I agree that boost is not the “Soon on std” it was a long time ago, and I think this is the general consensus now. > c) But C++ still needs a lot of help. It needs a lot more libraries most of > which are > too special purpose to be suitable for inclusion in the standard. And the > number of > these libraries is large - on the order of 500. This has to be the goal of > Boost 2.0 This is a huge point of discussion, but probably not suited for this thread. The future of boost is a controversial topic, though. > d) This list can't do this job > 1) 500 libraries would drown this list. I agree that this mailing list is not suited for a larger number of libraries, it is already pretty crowded. I personally like the layout of forums, the ability to subscribe to threads and have subforums for different topics. We already have sublists for larger and more widely used libraries, so that’s something. However, I don’t think the incubator would handle that number of libraries well, either. Something prepared for that scale will probably be hard to implement in wordpress. For a plan this huge, you need to form a team of highly skilled professionals that can envision, plan and execute such a project. > 2) the discussions on the list are extremely useful and should be > preserved in an easily accessible way. Again, forums do that quite nicely. > 3) There needs a way to pay for this development - boost has no way to do > this. I’m not here since a long time, but from what I could tell, boost is not based on voluntary work entirely, is it? Still, you’re probably right in the way that boost encourages high quality libraries which are above the standard of many company-internal code, and that the countless hours of work for a library that is well documented, written and tested should be compensated for. For me, just the knowledge that other programmers, probably even companies, will use my code, is quite satisfying, but I’m only writing a small header-only library, something you could still consider a hobby. > 4) This needs a lot more library writers. > i) But most programmers don't know how to prepare a boost quality > library: code, tests, documentation, etc. I don’t think boost has to nor needs to train new programmers. There are good programmers out there, and some of them may have written code for their work that could become a good boost lib, if they had time to flesh it out. > ii) Most library writer need some hope of compensation to justify the > time spent. Yes. Especially considering that boost has high standards for code quality, you can’t just submit an interesting prototype and call it a boost library. > iii) All libraries need testers, critique, feedback, etc. Boost can > only do that for libraries in review - and we can't review the candidates we > already have. And we don't have a mechanism other than this list for > dealing with this outside of the review. In a nutshell, the developer's > list can't scale the way I think it has to. As noted previously, I agree with you there. --- Felix Uhl PS: Robert, you really like writing lists of stuff, don’t you? ;-)

2 1

[nowide] Add C++ 11 support
by Michael Smith 19 Nov '14

19 Nov '14

This is a library I'd like to see in Boost proper. I plan to use it in a current project. One enhancement that would make it easier to work with is supporting new C++11 interfaces for the adapters it implements. Things like explicit fstream (const string& filename, ios_base::openmode mode = ios_base::in | ios_base::out); Any plans to do that? I'm happy to do the work and share it on Github.

1 0

[fit] please respond
by Andrzej Krzemienski 19 Nov '14

19 Nov '14

Hi, Encouraged by Boost Library Incubator initiative I wanted to make a review of FIT library, but I found I had some questions to Paul - the author. I send my questions also here, in case you are not subscribed for the comments in Boost Library Incubator. Please see my comment here: http://rrsd.com/blincubator.com/bi_library/fit-3/?gform_post_id=1100 Regards, &rzej

1 0

Variant and visitation (was: [optional] Safe optional)
by Nevin Liber 19 Nov '14

19 Nov '14

On 18 November 2014 15:02, Matt Calabrese <rivorus(a)gmail.com> wrote: > > > > For a while I assumed exactly that, but he actually specifically voiced > > > that he does not like visitation on variant and thinks of it as a hack. > > > It's sad :/ > > > > > > > FWIW: I think he is (a) correct, but (b) we have nothing better to > replace > > it, so we still need it. > > > > We should really start a thread about this. I'm very curious to see an > actual objective rationale both for why visitation over a closed set of > types known at compile time is in any way a "hack," It's the inversion of control that people just don't like. > along with a realistic > alternative. As I already said, I don't know of one, and having it is better than not having it. The discussion in Urbana on n4218 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4218.pdf> (variant), which didn't propose visitation, basically amounted to we don't like visitation but we need it unless something better comes along. > It really is a fundamental operation of a discriminated union. > As someone who uses variants pretty much as the "default" for run-time > polymorphism in day-to-day coding, I have never seen an actual explanation > for what someone might consider bad about variant visitation, neither from > Bjarne nor anyone else. > While I don't want to speak for Bjarne, I believe he would rather have some form of Pattern Matching <http://www.stroustrup.com/OpenPatternMatching.pdf> and possibly variant as a language feature. That being said, no one has proposed it. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

5 8

Re: [boost] [optional] Safe optional
by Felix Uhl 18 Nov '14

18 Nov '14

Matt Calabrese wrote: > I know that there are others (Eric?) who prefer to think of optional as a > container of size 0 or 1, so it could also make sense to provide an > accessor to a range. One interesting effect of this is that now > range-based-for sort of becomes a "visit if." There are probably other... > interesting uses of standard algorithms. I don’t know why, but I really like that idea; int f(optional<int> input){ int ret = 0; for(int opt : input){ ret = opt; } return ret; } It somehow seems like a really interesting Syntax, but to be honest, it doesn’t really offer any benefits, does it? You neither have any improvements on performance, nor any on code clarity. --- Felix Uhl Von: Matt Calabrese Gesendet: ‎Montag‎, ‎17‎. ‎November‎ ‎2014 ‎17‎:‎41 An: boost(a)lists.boost.org On Nov 17, 2014 1:25 AM, "Andrzej Krzemienski" <akrzemi1(a)gmail.com> wrote: > No, no exceptions. > The solution is based on the observation that there is a limited number of > things you can do with optional<T> > > optional<int> oi = ...; > > 1: > if (oi) doSomething(*oi); > else doSomethingElse(); // or nothing > > 2: > if (oi) doSomething(*oi); > else doSomething(-1); // use default value > > 3: > if (!oi) oi = (int)getIntByOtherMeans(); > doSomething(*oi); // now it is safe > > Now we simply provide a dedicated interface for each of these three usages: > > 1: > oi.use(&doSomething, &doSomethingElse); // or use lambdas > > 2: > doSomething(oi.value_or(-1)); > > 3: > doSomething(oi.value_or_eval(getIntByOtherMeans)); While I agree that we should be encouraging high order functions/visitation here, my personal experience is simply that many people do not like it. When given the choice to pass a lamda or to use an "if" or a range-based-for over high order function alternatives, programmers will generally opt for not using a lambda. The fact that Bjarne thinks visitation is somehow "bad" doesn't help. I agree that it's safer and I'd be in favor of it, but be aware that not everyone will like it. That said, I'd be in favor of this. If going with this approach, though, I'd say make optional a model of a variant and/or discriminated union concept that it and variant share, along with "expected" if it were to make it into boost (I.E. allow for apply_visitor of T and none, provide a "which"). I'd still like to see the other functions you mention as well for convenience. I know that there are others (Eric?) who prefer to think of optional as a container of size 0 or 1, so it could also make sense to provide an accessor to a range. One interesting effect of this is that now range-based-for sort of becomes a "visit if." There are probably other... interesting uses of standard algorithms. > I would rather not go that way. boost::optional is not unsafe. It is simply > something else than what some people think. Its conceptual model is more > like any value of T, plus one additional value. In this model implicit > conversions make perfect sense and are n fact desirable. I'm not sure I agree. These two templates aren't exactly complimentary in terms of the functionality that they provide, they really would just provide exactly the same functionality with the same internals. All that is different is the interface. Because of that, I say either it replaces optional or it doesn't exit as a part of boost. If people are convinced that this interface is less error prone, then it should be THE interface for optional. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[config] [VC++ 14.0 aka 2015] Removing BOOST_MSVC_ENABLE_2014_JUN_CTP macro requirement.
by Beman Dawes 18 Nov '14

18 Nov '14

As of the moment, the BOOST_MSVC_ENABLE_2014_JUN_CTP macro must be defined to eliminate a bunch of macros that should not apply to the Visual Studio 2015 Preview: BOOST_NO_CXX11_ALIGNAS [no value] BOOST_NO_CXX11_CHAR16_T [no value] BOOST_NO_CXX11_CHAR32_T [no value] BOOST_NO_CXX11_INLINE_NAMESPACES [no value] BOOST_NO_CXX11_NOEXCEPT [no value] BOOST_NO_CXX11_REF_QUALIFIERS [no value] BOOST_NO_CXX11_UNICODE_LITERALS [no value] BOOST_NO_CXX11_USER_DEFINED_LITERALS [no value] In other words, the only CXX11 macros that should be defined are: BOOST_NO_CXX11_ADDRESSOF [no value] BOOST_NO_CXX11_CONSTEXPR [no value] Unless someone objects strongly in the next few hours, I'm going to remove the need for the BOOST_MSVC_ENABLE_2014_JUN_CTP macro; it is just causing confusion at this point. --Beman

6 11

noexcept(true) for ~noncopyable?
by Olaf van der Spek 18 Nov '14

18 Nov '14

Shouldn't ~noncopyable be noexcept? I'm seeing this error: class Cconnection : public Cclient, boost::noncopyable connection.h:5:7: error: looser throw specifier for ‘virtual Cconnection::~Cconnection()’ In file included from connection.h:3:0, from connection.cpp:2: client.h:10:10: error: overriding ‘virtual Cclient::~Cclient() noexcept (true)’ https://svn.boost.org/trac/boost/ticket/10698 -- Olaf

2 3

[BGL] [push_relabel_max_flow]
by Pablo Madoery 18 Nov '14

18 Nov '14

Hello, I am having trouble using the push_relabel_max_flow algorithm when i put std::numeric_limits<double>::max() as capacity attribute in some edges. is there a maximum value that I can use as capacities. which ?. This is the example I am using : #include <iostream> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/push_relabel_max_flow.hpp> #include <boost/graph/graphviz.hpp> using namespace std; using namespace boost; struct vertexInfo { }; struct edgeInfo { double capacity; double residualCapacity; double flow; adjacency_list_traits<vecS, vecS, bidirectionalS>::edge_descriptor rev; edgeInfo() { residualCapacity = 1000; } }; typedef adjacency_list<vecS, vecS, bidirectionalS, vertexInfo, edgeInfo> Graph; typedef Graph::edge_descriptor edge_d; const char* names[] = { "SV", "L1", "L2", "L3", "L4", "ET"}; template<typename Vertex> void create_edge(Graph& g, Vertex v0, Vertex v1, double capacity) { //the algorithm requires that for each edge u-v in the graph, the edge v-u also exists Graph::edge_descriptor ep0 = (add_edge(v0, v1, g)).first; Graph::edge_descriptor ep1 = (add_edge(v1, v0, g)).first; g[ep0].capacity = capacity; g[ep0].rev = ep1; g[ep1].capacity = 0; // the capacity of v-u needs to be 0 g[ep1].rev = ep0; } int main() { Graph graph; Graph::vertex_descriptor SV = add_vertex(graph); Graph::vertex_descriptor L1 = add_vertex(graph); Graph::vertex_descriptor L2 = add_vertex(graph); Graph::vertex_descriptor L3 = add_vertex(graph); Graph::vertex_descriptor L4 = add_vertex(graph); Graph::vertex_descriptor ET = add_vertex(graph); create_edge(graph, SV, L1, std::numeric_limits<double>::max()); create_edge(graph, SV, L2, std::numeric_limits<double>::max()); create_edge(graph, SV, L3, std::numeric_limits<double>::max()); create_edge(graph, SV, L4, std::numeric_limits<double>::max()); create_edge(graph, L3, ET, 1000); create_edge(graph, L4, L3, 1000); create_edge(graph, L2, L3, 1000); create_edge(graph, L1, L2, 1000); // arcos de vuelta create_edge(graph, L3, L4, 1000); create_edge(graph, L3, L2, 1000); create_edge(graph, L2, L1, 1000); std::cout << "Max flow: " << push_relabel_max_flow(graph, SV, ET, get(&edgeInfo::capacity, graph), get(&edgeInfo::residualCapacity, graph), get(&edgeInfo::rev, graph), get(boost::vertex_index, graph)) << std::endl; graph_traits<Graph>::vertex_iterator vi, vi_end; graph_traits<Graph>::out_edge_iterator ei, ei_end; cout.precision(20); for (tie(vi, vi_end) = vertices(graph); vi!= vi_end; ++vi) { for (tie(ei, ei_end) = out_edges(*vi, graph); ei != ei_end; ++ei) { graph[*ei].flow = graph[*ei].capacity - graph[*ei].residualCapacity; if (graph[*ei].capacity > 0) { std::cout << names[*vi] << " " << names[target(*ei, graph)] << " " << (graph[*ei].capacity - graph[*ei].residualCapacity) << "/" << graph[*ei].capacity << std::endl; } } } cout<<"end"<<endl; return 0; } ----------------------------------------------------------------------------------------------------------------------------- And this is the exception: /home/madoery/boost_1_55_0/boost/graph/push_relabel_max_flow.hpp:706: typename boost::property_traits<CapacityEdgeMap>::value_type boost::push_relabel_max_flow(Graph&, typename boost::graph_traits<Graph>::vertex_descriptor, typename boost::graph_traits<Graph>::vertex_descriptor, CapacityEdgeMap, ResidualCapacityEdgeMap, ReverseEdgeMap, VertexIndexMap) [with Graph = boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, vertexInfo, edgeInfo>, CapacityEdgeMap = boost::adj_list_edge_property_map<boost::bidirectional_tag, double, double&, long unsigned int, edgeInfo, double edgeInfo::*>, ResidualCapacityEdgeMap = boost::adj_list_edge_property_map<boost::bidirectional_tag, double, double&, long unsigned int, edgeInfo, double edgeInfo::*>, ReverseEdgeMap = boost::adj_list_edge_property_map<boost::bidirectional_tag, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>&, long unsigned int, edgeInfo, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int> edgeInfo::*>, VertexIndexMap = boost::vec_adj_list_vertex_id_map<vertexInfo, long unsigned int>, typename boost::property_traits<CapacityEdgeMap>::value_type = double, typename boost::graph_traits<Graph>::vertex_descriptor = long unsigned int]: Assertion `algo.is_flow()' failed. Thank You

1 0

gdb pretty printers
by Paul Fee 18 Nov '14

18 Nov '14

Hi all, On Linux, when using GDB to debug C++ programs that use Boost, it's difficult to get human readable values from variables. e.g. == Source == boost::optional<std::string> s("hello world"); == GDB == (gdb) print s $1 = {<boost::optional_detail::optional_base<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >> = {<boost::optional_detail::optional_tag> = {<No data fields>}, m_initialized = true, m_storage = {dummy_ = {data = "(0`\000\000\000\000", aligner_ = {<No data fields>}}}}, <No data fields>} ======== A set of python pretty printers that understand the internals of some Boost objects can be found here: https://github.com/ruediger/Boost-Pretty-Printer The resulting output is more useful: == GDB == (gdb) print s $2 = boost::optional<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > is initialized = {value = "Hello world"} ========= Some distros, e.g. Fedora, CentOS have STL pretty printers working out of the box. It would be great to also have Boost pretty printers widely available via Linux distros. Since the pretty printers are tightly coupled to the objects they're printing, it would be ideal if they were included with Boost. That way both the class definitions and python printers should stay in sync. Can someone provide guidance on how to get code in the above github repo into Boost? Thanks, Paul

1 0

Boost config macros for 'override' and 'final'?
by Nat Goodspeed 17 Nov '14

17 Nov '14

I don't find in Boost 1.57 any Boost macros to mediate use of the 'override' or 'final' C++11 specifiers. Would that be a reasonable addition?

6 7

RFC/patch: compile boost on Android for platform development
by Wagner, David 17 Nov '14

17 Nov '14

Hi, We are evaluating the pros and cons of using Boost for platform development on Android. We have successfully built and run Asio's "chat" server and client examples on an Android device running Lollipop. The C++ support seems to have been greatly improved since KitKat. Even though it is still early to say that all of Boost runs ok, all the Asio unit tests passed with "*** No errors detected" except the multicast test. I've attached a patch that adds Android makefiles to relevant libraries for compiling Boost.Asio. It's a first draft and it doesn't use the git submodules. The development of this patch has been made on top of the 1.56.0 tag. Platform development on android is different than native development ("NDK", used for JNI libraries). There seem to have been several efforts made for Boost support on NDK but we haven't found any for platform development (which is aimed at device support, e.g., HAL development, native tools). Is there an interest for maintaining a set of Android makefiles on vanilla Boost ? I understand someone would need to run the regression tests on Android; is there any other such requirement ? Kind Regards, -- David Wagner Intel Corp. --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

2 2

Re: [boost] Is there interest in a library for string-convertible enums?
by Jeffrey Bush 17 Nov '14

17 Nov '14

> > Jeffrey Bush wrote: > > > I have also offered a class for doing this as well, although it didn't > draw > > the interest that this one did. > > Here was my attempt at it with a test/example class: > > https://gist.github.com/coderforlife/6d8bac451d49dd1a0c81 > > > > > Looks good to me, and seems to be quite close to what I aim at. > > But the definition seems very user unfriendly. Is it correct that > > you always have to declare enums in the public namespace? > > --- > > Felix > Sorry for the delayed response. It does support being in a public namespace, even as a sub-class. However the definition does get uglier in sub-classes. The major problem I ran into was that the class could not be defined in a header file without getting multiple-definition or as a sub-class without running into problems. Mainly because of the constant arrays in the classes couldn't be defined in-line and in headers. Some C++11 features may help get around this. I do think that when these issues are ignored the declarations are pretty nice: BOOST_FLAGS_WITH_VALUES(MyFlags, std::uint8_t, A, 1, B, 2, AB, 3, C, 4); BOOST_FLAGS(MyDefaultFlags, AX, BX, CX, DX, EX, FX, GX, HX); namespace MyNS { BOOST_FLAGS(MyFlags, M, N, O, P, Q); } That makes 3 different enumerations, first with custom values and a custom base (uint8_t), the second with default values (powers of two) and selects the smallest base type, and the third is the same but in a non-public-namespace. All of these don't work in header files without getting multiple definitions. To avoid that problem you can do something like: // In H file: BOOST_FLAGS_DECL(MyFlags, M, N, O, P, Q); // In CPP file: BOOST_FLAGS_DEFN(MyFlags, M, N, O, P, Q); The same technique can be used to make sub-classes (as in the example file). If I remember correctly if the ability to go from string -> value and get list of values at runtime then the ugliness of the separate DECL/DEFN would be avoided. Jeff

1 0

Re: [boost] [review][sort] Formal review period for Sort library begins today, November 10, and ends Wednesday, November 19
by Niall Douglas 16 Nov '14

16 Nov '14

On 10 Nov 2014 at 0:39, Edward Diener wrote: > - What is your evaluation of the design? It's okay. I would prefer a design where there is a sorted_view which if std::copy gives an actually sorted copy. Obviously one would then specialise that scenario with a more directly optimised specialisation, and you'd also have the API presented here which looks like std::sort(). I'd also prefer to see fallback implementations for less than random iterators, right down to forward only iterators. > - What is your evaluation of the implementation? There seems to be an assumption that user supplied overloads and specialisations e.g. swap() don't throw exceptions. I think that unwise. BOOST_NOEXCEPT can test if something can throw. Explicit guarantees of what happens when something does throw needs to be in the documentation, per API. There seems to be a general lack of explicit C++ 11 support as well. In particular, I think all Boost libraries should use inline namespaces to implement ABI version management. Implementation isn't capable of dual build as standalone use without any dependency on Boost. I'd suggest my forthcoming Boost.BindLib library. > - What is your evaluation of the documentation? Lacks exception guarantees, one per API. Lacks scaling graphs near front so people can quickly evaluate usefulness compared to std::sort. I believe the author will fix this though. > - What is your evaluation of the potential usefulness of the > library? > - Did you try to use the library? With what compiler? Did you > have any problems? No. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? Glance. > - Are you knowledgeable about the problem domain? Author of a very popular open source indexing algorithm library. > And finally, every review should attempt to answer this question: > > - Do you think the library should be accepted as a Boost library? Yes with these conditions: 1. Either change its name to Boost.Spreadsort, or do a much better job at a general sort library e.g. sorted_view, more than one sort algorithm not in the STL, more than random access iterator support. 2. Exception safety is not obvious, and explicit exception guarantees need to be made and stated per API in the documentation. 3. Explicit ABI version management in C++ 11 using inline namespaces. Forthcoming Boost.BindLib can do this for you, or it can be done by hand. It would also be nice if this library were also capable of standalone build without Boost, but this is not a requirement. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 4

Re: [boost] How do I authenticate myself?
by Felix Uhl 14 Nov '14

14 Nov '14

Andrey Semashev wrote: > Note that you can have anonymous read-only access if you change the URL a little: > git://github.com/boostorg/boost.git > That should probably be mentioned in the docs. Thank you very much, that was exactly what I needed. Should've probably thought about that myself. I agree, that should be mentioned. Especially under the point "try out modular boost". --- Felix Uhl ________________________________ Von: Andrey Semashev<mailto:andrey.semashev@gmail.com> Gesendet: ‎14.‎11.‎2014 14:17 An: boost(a)lists.boost.org<mailto:boost@lists.boost.org> Betreff: Re: [boost] How do I authenticate myself? On Friday 14 November 2014 10:55:36 Felix Uhl wrote: > I want to clone the current develop branch > > to verify that a bugfix to a trac item I opened > > does actually fix the bug. > > > It seems like this information should be easy > > to find on the boost webpage or wiki, but neither > > of both explain how to authenticate myself > > when using “git clone --recursive git@ > > github.com:boostorg/boost.git modular-boost >clone.log”. > > The output of this is “Permission denied (publickey)”, > > which seems to mean to me that I need a > > ssh key the server actually knows about or that I have > > to upload my public key somehow. > > > Have I just missed something on the wiki? As Boost is hosted on GitHub, all the options it offers also work with Boost. See here: https://help.github.com/articles/which-remote-url-should-i-use/ Note that you can have anonymous read-only access if you change the URL a little: git://github.com/boostorg/boost.git That should probably be mentioned in the docs. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] How do I authenticate myself?
by Felix Uhl 14 Nov '14

14 Nov '14

Adam Wulkiewicz wrote: >FYI, instead of preparing a patch and attaching it to a bug report you >could consider working directly on the development version of a library >and propose a pull request with the fix on GitHub. The fix is not mine, I have opened a ticket, the author has written a fix and I just wanted to clone to check if the fix has fixed the issue. Thanks for the link, though, I'll make sure to check it out. --- Felix Uhl ________________________________ Von: Adam Wulkiewicz<mailto:adam.wulkiewicz@gmail.com> Gesendet: ‎14.‎11.‎2014 14:48 An: boost(a)lists.boost.org<mailto:boost@lists.boost.org> Betreff: Re: [boost] How do I authenticate myself? Andrey Semashev wrote: > On Friday 14 November 2014 10:55:36 Felix Uhl wrote: >> I want to clone the current develop branch >> >> to verify that a bugfix to a trac item I opened >> >> does actually fix the bug. >> >> >> It seems like this information should be easy >> >> to find on the boost webpage or wiki, but neither >> >> of both explain how to authenticate myself >> >> when using “git clone --recursive git@ >> >> github.com:boostorg/boost.git modular-boost >clone.log”. >> >> The output of this is “Permission denied (publickey)”, >> >> which seems to mean to me that I need a >> >> ssh key the server actually knows about or that I have >> >> to upload my public key somehow. >> >> >> Have I just missed something on the wiki? > As Boost is hosted on GitHub, all the options it offers also work with Boost. > See here: > > https://help.github.com/articles/which-remote-url-should-i-use/ > > Note that you can have anonymous read-only access if you change the URL a > little: > > git://github.com/boostorg/boost.git > > That should probably be mentioned in the docs. FYI, instead of preparing a patch and attaching it to a bug report you could consider working directly on the development version of a library and propose a pull request with the fix on GitHub. Here is a tutorial showing how this could be done: https://github.com/boostorg/geometry/wiki/Contribution-Tutorial It was made for Geometry but the procedure looks the same for any other library. Regards, Adam _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

How do I authenticate myself?
by Felix Uhl 14 Nov '14

14 Nov '14

I want to clone the current develop branch to verify that a bugfix to a trac item I opened does actually fix the bug. It seems like this information should be easy to find on the boost webpage or wiki, but neither of both explain how to authenticate myself when using “git clone --recursive git@ github.com:boostorg/boost.git modular-boost >clone.log”. The output of this is “Permission denied (publickey)”, which seems to mean to me that I need a ssh key the server actually knows about or that I have to upload my public key somehow. Have I just missed something on the wiki? --- Felix Uhl

3 2

[sort] Review of the Sort library by Steven Ross
by Edward Diener 14 Nov '14

14 Nov '14

As review manager I am forwarding this review sent to me: - What is your evaluation of the design? - What is your evaluation of the implementation? Design an implementation look good to me. Spreadsort has a clean interface and the code is readable. I tried the algorithm out a few years ago in a project at work (our product in the EDA industry) for sorting 32-bit {x,y} coordinate data cast to a 64-bit integer, and for sorting 32-bit values within scanlines. The speedup was about 1.8x that of std::sort() for ~100M values. This translated into a 10-20% overall runtime reduction in that tool, with only a few lines of code changes. - What is your evaluation of the documentation? I haven't read through the documentation in detail, but I have read through the code and the comments so I feel I understand the basics of how the sorting algorithm works. - What is your evaluation of the potential usefulness of the library? I would say this library is very useful for specific tasks involving large datasets that need to be sorted, especially in cases where the data is already partially sorted and contains many duplicate values. For example, it could be useful for EDA applications, computational geometry, some types of databases, etc. It may be a fairly narrow user base but I think it could add significant value. - Did you try to use the library? With what compiler? Did you have any problems? I built and tested spreadsort on both linux/gcc and Windows/MSVC++. I was never successful in running the tests in Cygwin. It seemed to work as expected when I tried using it inside an EDA tool and caused no problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent some hours reviewing the algorithm a few years ago, and I provided Steve with feedback to improve the code. I was mostly interested in the integer sorting aspect at that time, but did experiment with floating-point numbers as well. I read through the code again recently to familiarize myself with it. - Are you knowledgeable about the problem domain? I would say that I'm knowledgeable of applications and uses of sorting large datasets, and algorithms in general. I don't have any specific experience in developing or testing sorting algorithms. - Do you think the library should be accepted as a Boost library? Yes, I believe Steve has put in enough work to make this a well designed, tested, and documented library. There are real numbers to show the performance improvements over other sorting algorithms. If this was part of Boost, I would probably use it in our product at my company. Frank Gennari

1 0

which submodule are boost headers in?
by Robert Ramey 13 Nov '14

13 Nov '14

This is making me feel really dumb. I want to remove a header in the /boost/ directory. This has been superseded by a header of the same name in the serialization library. boost/strong_typedef.hpp I expected to find a sub-module in modular boost which I can just select, get permission to make changes and upload my change - just remove this file. But I don't find a sub-module which seems to contain this header. So I need some help. Actually the simplest would be for someone who understands this and has appropriate privileges to just do the dirty work for me and remove the file. Failing that, someone can explain the procedure for finding the file, and getting the requisite privileges. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/which-submodule-are-boost-headers-in-tp4… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[site] uBLAS documentation page link is broken
by Renato Florentino Garcia 13 Nov '14

13 Nov '14

The uBLAS documentation link[1] on Boost libs documentation page[2] is broken. The previous released version[3] is yet working nevertheless. Regards, Renato Garcia [1]: http://www.boost.org/doc/libs/release/libs/numeric/ublas/doc/index.htm [2]: http://www.boost.org/doc/libs/ [3]: http://www.boost.org/doc/libs/1_56_0/libs/numeric/ublas/doc/index.htm

2 1

[smart_ptr] explicit instantiation of boost::shared_ptr
by Petr Machata 12 Nov '14

12 Nov '14

Hi there, I got a bug report that the following code doesn't compile: #include <boost/tr1/memory.hpp> template class boost::shared_ptr<int>; int main(int, char**) {} The errors this gives under GCC 4.9 are as follows: In file included from /usr/include/boost/shared_ptr.hpp:17:0, from /usr/include/boost/tr1/memory.hpp:56, from foo3.cc:1: /usr/include/boost/smart_ptr/shared_ptr.hpp: In instantiation of 'typename boost::detail::sp_array_access<T>::type boost::shared_ptr<T>::operator[](std::ptrdiff_t) const [with T = int; typename boost::detail::sp_array_access<T>::type = void; std::ptrdiff_t = long int]': foo3.cc:2:23: required from here /usr/include/boost/smart_ptr/shared_ptr.hpp:663:22: error: return-statement with a value, in function returning 'void' [-fpermissive] return px[ i ]; This in particular is with boost 1.54. The problem is however present on master as well, where it also gives more errors relating to boost/core/demangle.hpp that I didn't look into. I went ahead to do some investigation in case the issue ends up being trivial. We can't use enable_if to disable a particular member function. Not unless it's a template. Making it a template would lead to a code like this: template <class U = T, class V = boost::disable_if <boost::is_void <boost::detail::sp_array_access< U >::type>, U>::type> boost::detail::sp_array_access< T >::type operator[] (etc. etc.); ... which is not C++98, and I don't have ideas how to C++98-ify it while also having it do what we want without breaking API. (The indirection through U may not be necessary, I'm not in fact sure, but that doesn't change anything.) One way that I can see is extracting element_type * px to a base class (say, boost::detail::sp_operator_at) that either does or does not define operator[] (which would then use the px). But that implies some amount of code motion, and not knowing what your position would be, I didn't want to blindly go ahead and start moving stuff around. So, would a patch to the effect described above be possibly acceptable? Thanks, Petr.

2 5

[Fusion] Lots of test failures on develop
by Louis Dionne 12 Nov '14

12 Nov '14

I'm getting a lot of test failures on the develop branch of Fusion on OS X. There are too many to paste the output here. Note that master is just fine. Are the unit tests being run automatically each time a pull request is merged? Louis

5 8

Boost.Build: new tutorial
by Vladimir Prus 12 Nov '14

12 Nov '14

Back in 2009, Boris Schäling wrote a Boost.Build tutorial that many deemed to be better than the tutorial in the official documentation. It took quite some time, but it's now part of Boost.Build, here: http://www.boost.org/build/tutorial.html I'd appreciate any comments. Note that previously, I planned to integrate this tutorial with the boostbook documentation. It's becoming clear that there's just no time for that, and the tutorial is added as HTML page. I haven't decided yet what to do with old tutorial in boostbook sources. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

9 14

[multi_index] Doc suggestion.
by Mostafa 11 Nov '14

11 Nov '14

Not being able to mutate elements through non-const iterators is surprising enough that I forget about it every time I use Boost.MultiIndex. Part of the reason for this is that this information is buried under section "multi_index/doc/tutorial/basics.html#seq_indices". I suggest that the following paragraph: "That is, iterators of a sequenced index (of all types of indices, actually) point to constant elements. This limitation might come as a surprise, but it is imposed by the way multi_index_containers work; if elements were allowed to be changed in this manner, we could introduce inconsistencies in other ordered indices of the multi_index_container. Element modification can nevertheless be done by means of update operations." be moved under "multi_index/doc/tutorial/basics.html#iterator_access" as a call-out.

2 5

Boost Incubator Status Report
by Robert Ramey 11 Nov '14

11 Nov '14

Felix Uhl wrote > On 28/10/2014, Rob Stewart wrote: > > >Currently, I am documenting the first version of the library to make it >>available on the Boost Library Incubator website, > > I can hear Robert yelling, "Yes!" Yes! The experience so far with the incubator is very interesting. Here are couple of observations. a) I anticipated more submissions since the process seems so easy and the bar is very low. As a practical matter the requirements boil down to having code, tests, documentation which implies some examples. There are no restrictions of format of any of these things. But if you troll the net looking for libraries very few library ideas fulfill these requirements. It turns out that fulfilling even these modest (in my view) requirements is more than many people find necessary. b) The quality of the submissions is a lot better then I had anticipated. All of them are credible, serious efforts which are worthy of serious consideration for inclusion in Boost. That's not to say that all would eventually be accepted as I have only given them a cursory examination. c) There are very few comments on the pages of the website and on the library pages. So far there is only one formal review. I'm sort of disappointed in this. It goes to our problem in getting enough reviews in general. The one review (boost compute) was from one who downloaded and tested the library, liked it, and included it in production. Of course the review was very positive. I would hope to see more of this in the future. d) To support more reviews, I have on my todo list to keep track of who invokes the download/repo links and match them up with the users email address and send out a gentle reminder that if he spent the time to look at and consider the library, he should either comment or add a formal review. I would also like to see some of the posting on this list regarding library proposals to moved to the library comments page. Another alternative would be to link from the library comment page to the developer's list thread(s) which touch upon the library. In any case, I want to see more activity in this area. Any of these require good experience with wordpress and some available time - so I don't see these happening soon. e) I would like to see a little more support from Boost Steering Committee on this effort. Specifically I would like to see the Announcement that Boost endorses the Boost Library Incubator (www.blincubator) packaged and distributed as press release so that it would show up in places like Dr Dobbs Journal. (http://www.drdobbs.com) and isocpp.org (http://isocpp.org) It is a great disappointment to me that in spite of a fair amount of effort, I've been unable to get these sites (among others) to announce the Boost endorsement of Boost Library Incubator. Finally - By next monday, I'll have in place a new facility. This is support on the library page whereby companies which have interest in a particular library will be able to contact the library author in order to offer financial sponsorship for his efforts. Companies which do this will be able to ask for special features and/or extensions, custom versions, extra support or anything they want. Authors will have the option of placing sponsors logos and links on their library pages. This will offer developers of open source the first opportunity in history to be compensated as the rock stars we are. Thanks for everyone for help so far in promoting the Boost Library Incubator. Please continue your efforts. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Incubator-Status-Report-tp4668747.… Sent from the Boost - Dev mailing list archive at Nabble.com.

12 42

Please welcome Nevin Liber as a list moderator
by Beman Dawes 11 Nov '14

11 Nov '14

Nevin has been a long-time Boost Users list moderator, C++Now participant, and C++ committee member. He has graciously agreed to help moderate the Boost developers list. Please welcome Nevin as a list moderator! --Beman

6 5

[git][flyweight] something messed up with master and develop branch
by Joaquin M Lopez Munoz 11 Nov '14

11 Nov '14

Dear Git connoiseurs: I've realized that my master and develop branches at boostorg/flwight appear collapsed: https://github.com/boostorg/flyweight/network Yet I am seemingly able to treat them separately: commit to develop, test, merge to master etc. The only weird thing is the diagram above and the fact that the commit log in master doesn't have the usual "Merge branch 'develop'" commits: https://github.com/boostorg/flyweight/commits/master Any clue what's going on? Thank you! Joaquín M López Muñoz Telefónica

4 9

[release][1.58.0] Updating master and other business.
by Daniel James 10 Nov '14

10 Nov '14

Hello all, It's almost a week since the release, so unless there are any objections I'll restart automatically updating the master branch of the super project in a day or so. I'll also tag the submodules for the last two releases. Please can someone with the appropriate Trac permissions update the milestones and versions. Finally, if anyone has any new libraries that they want to include in the next release, please let us know soon. thanks, Daniel

4 5

VC14 CTP4 Atomic don't compile with boost::chrono durations which are not TriviallyCopyable
by Klaim - Joël Lamotte 10 Nov '14

10 Nov '14

I was testing my code with VC14 and found this issue. I'm just not sure what to do about it, should I consider it a bug of Boost.Chrono or not? This complete example does not compile in VC14 CTP4: #include <atomic> #include <boost/chrono.hpp> std::atomic<boost::chrono::milliseconds> ms; // error C2338: atomic<T> requires T to be trivially copyable. Using the standard library instead works as expected: #include <atomic> #include <chrono> std::atomic<std::chrono::milliseconds> ms; // no error The compiler is correct that boost::chrono::duration is not trivially copyable (as described on cppreference.com at least) but it seems (from looking at the code) that it's mostly concept check code used in constructors definitions that trigger the problem. So I'm not sure if it should be fixed or not or what to do with this info.

2 3

Boost library incubator problem
by Edward Diener 10 Nov '14

10 Nov '14

When I go to the Boost Library Incubator at http://rrsd.com/blincubator.com/, click on the libraries listed alphabetically, and then click on any library, I get: "Not Found Apologies, but the page you requested could not be found. Perhaps searching will help."

2 5

Re: [boost] Boost Incubator Status Report
by Felix Uhl 08 Nov '14

08 Nov '14

Rob Stewart wrote: > When interviewing C++ developers, I find those using Boost libraries, at least beyond shared_ptr, are rare. > The brand is known by relatively few, and it is used, to any significant extent, by fewer still. > That implies the need to grow our ranks through some form of advertising. I came to the observation that boost is well known in more experienced circles of programmers, but, as you said, not that frequently used. As it was previously mentioned, this issue could be solved by entering collaborations with compiler distributors to include boost, or at least a subset of it in their compiler. The only reason STL is used so heavily is because it is a pseudo part of the language, bundled with every compiler, a consistent, standardised foundation to rely on. If the inclusion of boost was as simple as the inclusion of the STL, more programmers would use it. This is what boost seemed like to me after reading herb sutters books: It is a less coherent extension of STL, an idea of what the future might hold. Imagine how well boost would be known if it was bundled with MSVC and gcc. --- Felix Uhl ________________________________ Von: Rob Stewart<mailto:robertstewart@comcast.net> Gesendet: ‎08.‎11.‎2014 11:48 An: boost(a)lists.boost.org<mailto:boost@lists.boost.org> Betreff: Re: [boost] Boost Incubator Status Report On November 7, 2014 5:35:02 PM EST, Edward Diener <eldiener(a)tropicsoft.com> wrote: >On 11/7/2014 11:23 AM, Robert Ramey wrote: >> Vladimir Prus-3 wrote > > The motivation behind the >> design of the incubator is to "make participation easier" by >decoupling the >> preparation of the review from a specific 1-2 week time frame. It >was also >> specifically designed to not alter the actual Boot Review process. > >Other than lengthening the formal review process to encourage more >people to participate I do not see any means to get people more >interested in reviewing Boost libraries. That is the notion behind the incubator: allow the review period to be open indefinitely, particularly in advance of the formal review period. > As far as the incubator is >concerned I feel it is a good idea but nobody is using it to comment on >libraries. Links from the review queue to the incubator page for each library could help people discover the incubator. > As far as Boost reviews it appears that most programmers are >afraid to even make comments about a potential library in which they >may be interested. Maybe the specter of C++ experts scares them away. Maybe >they feel that they might look foolish if they make a comment which is >based on just a partial understanding of the library involved. What leads you to that conclusion? There are multiple factors that prevent my commenting on a library: * No interest in the domain * No knowledge of the domain * Too busy I realize I'm not in the "too afraid because of experts" camp you describe, but I've not commented on any of the libraries and it isn't due to fear. >Finally there is a decided problem with the lack of people willing to >be >review managers for a library. I think it would be a good idea to >establish a pool of people, with their e-mail addresses, willing to be >review managers and then when a library is on the review queue one of >the review managers would send out e-mail to all people in the pool >asking each one if he would be willing to be the review manager for a >particular library. If no one at a given time in the pool will agree, >then after some pre-established time period the process repeats itself. I've offered to be a review manager a couple of times, but the libraries never went to review or another did the job. However, the last I looked there were multiple libraries I don't feel competent to judge. Being a review manager is more than verifying that examples compile, that documentation exists, etc. One must be able to judge comments and reviews to decide between opposite views, etc. That requires domain knowledge and experience, if not expertise. There are fewer general purpose libraries on tap now. Obviously, folks have more or less time at different periods of their lives, so one can go through periods of no or little participation. There's also the real issue of changes to the industry. As one seeks interesting and lucrative or stable employment, one may target new kinds of development which can mean new languages. Thus, one may retain a more nostalgic interest in C++, but no longer be interested to invest the time needed to be a review manager. To solve those problems requires finding and engaging new blood. When interviewing C++ developers, I find those using Boost libraries, at least beyond shared_ptr, are rare. The brand is known by relatively few, and it is used, to any significant extent, by fewer still. That implies the need to grow our ranks through some form of advertising. ___ Rob (Sent from my portable computation engine) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Boost Incubator Status Report
by Felix Uhl 08 Nov '14

08 Nov '14

Robert Ramey wrote: > If you select the "Display Statistics" Button on the Safe Numerics and > display the last 60 days of activity, you can see that the library page has > 50 visits. This is not a huge number. A book on Amazon might > sell 1000 copies and get a couple of reviews (most of whom are > likely the author's relatives). So as the incubator becomes more > a "go to" place to look for libraries, the question of small number > of reviews would solve itself. (hopefully). It seems to me that the whole point that is missing from the incubator is actual usage of it. I like the concept a lot, but do you actually have any plans on how to increase the usage? Just adding features isn’t going to help as long as you haven’t reached a critical point in community size where people start spreading the word on new features. I think this is a very inherent problem to a programmers way of thinking: We envision a great platform, a great framework, a great tool, and set out to implement it, but after doing so, have no idea on how to do follow-up work: Financials, Community building and management, “marketing” or just garnering interest in your project in the first place. In short: What you want to do with the incubator is great, and if it gets going it will quite surely be a great addition to boost. But how will you get it going? --- Felix Uhl Von: Robert Ramey Gesendet: ‎Freitag‎, ‎7‎. ‎November‎ ‎2014 ‎23‎:‎57 An: boost(a)lists.boost.org Edward Diener-3 wrote > Other than lengthening the formal review process to encourage more > people to participate I do not see any means to get people more > interested in reviewing Boost libraries. As far as the incubator is > concerned I feel it is a good idea but nobody is using it to comment on > libraries. > > As far as Boost reviews it appears that most programmers are > afraid to even make comments about a potential library in which they may > be interested. Maybe the specter of C++ experts scares them away. Maybe > they feel that they might look foolish if they make a comment which is > based on just a partial understanding of the library involved. If you select the "Display Statistics" Button on the Safe Numerics and display the last 60 days of activity, you can see that the library page has 50 visits. This is not a huge number. A book on Amazon might sell 1000 copies and get a couple of reviews (most of whom are likely the author's relatives). So as the incubator becomes more a "go to" place to look for libraries, the question of small number of reviews would solve itself. (hopefully). And of course if one can make a review at the moment he's decided to use or discard the library, it's more likely that, being in a state of ecstasy or frustration, he'll display his feelings by making a review while the facts and emotion are fresh in his mind. > Finally there is a decided problem with the lack of people willing to be > review managers for a library. Again, if we had more "pre-reviews" getting a review manager would be a snap. a) a library with a large number of negative pre-reviews will likely not even be selected for review. b) a library with no reviews suggests that it's not getting enough usage to be useful so maybe it's not worth reviewing. b) a library with a large number of positive reviews - it's easy to be the review manager. c) for the rest - well, at least the manager knows what he's in for. That might make it easier. In short, I would hope if we can make the incubator a success, it will help with the shortage of review managers. If any library in the incubator ever gets enough reviews, and gets reviewed, and passes review, I intend to leave all the reviews on display indefinitely. In fact, I intend to allow anyone to post review in the future. Current boost libraries vary a lot in quality but our current setup doesn't make that visible. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Incubator-Status-Report-tp4668747p… Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

pp
by Jan Boehme 07 Nov '14

07 Nov '14

Hello, the file boost/preprocessor/config/variadics.hpp doesn't exist but is referenced in the pp docs. Regards, Jan

2 2

Re: [boost] Boost Incubator Status Report
by Felix Uhl 06 Nov '14

06 Nov '14

Gordon Woodhull wrote: > We did update the formal review process and related pages to > invite people to use the Incubator to garner feedback before their library > is ready for a formal review. [*] That’s how I found out about it, so I would say the submission to the incubator is at least encouraged by Considering that, it seems a bit weird that the incubator has so little activity. > I don't think Robert ever intended the Incubator to replace the formal review or the role of the Wizards. > Instead, IMO it is better thought of as a replacement for the unscheduled > part of the review schedule (aka the Queue), and a better way to verify > the basic requirements for submitting a library. And reviews can be > submitted and responded to before the formal review, > without getting buried in the mailing list. That’s how I understood it, but from my - admittedly sparse - experience, the mailing list is an excellent place for feedback, because it is guaranteed that quite a few people will actually get the message. When I have my library ready for submission to the incubator, how is anyone going to notice it? Are enough people subscribed to the feeds that a library gets more attention than in the mailing list, or at least attention from different groups of people? It seems like the most fundamental element of the incubator is a dedicated community that is willing to participate, to test and review. And it is clearly missing exactly that. --- Felix Uhl

2 1

Boost on Google+
by Vladimir Prus 06 Nov '14

06 Nov '14

Hi, I've created a Google+ community for Boost, and everybody is welcome to join here: https://plus.google.com/communities/106814259809358442744 I don't have any great plan here, but a lot of tech people are active on G+, so why not? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

1 0

Boost.Build 2014.10
by Vladimir Prus 05 Nov '14

05 Nov '14

New standalone release of Boost.Build is now available from: http://boost.org/build This one is effectively the same as what is bundled in Boost C++ Libraries 1.57 release. It has been a while since previous standalone release, and I know a few people were using nightly builds to conveniently get recent fixes, which is not a perfect arrangement. Turned out that github release system is fairly easy to use, so I should be able to push releases more often in future. Thanks, -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

2 1

Master open?
by Joaquin M Lopez Munoz 05 Nov '14

05 Nov '14

Hi, Is master open again for commits targeted at Boost 1.58? Thank you, Joaquín M López Muñoz Telefónica

2 1

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 05 Nov '14

05 Nov '14

Gavin Lambert wrote: > Features that I would expect of such a library: > - support for arbitrary non-contiguous values. > - enum value to string. > - string to enum value. That's done already. > - list of all valid values, either as strings or values. > - can indicate whether a given value (string or enum) is a member of > the enumeration. Easy, will do. > - can round-trip (enum -> string -> enum) values that are not members > of the enumeration; of course (string -> enum -> string) is not feasible > for non-members. What would a conversion from an enum that is not a member to a string look like? Should it just be converted to the string representation of the underlying type like “7”? Or something like “MyEnum::7”? Or would the string representation solve a term with bitwise OR like so: “one|two|four”? The latter would be very interesting for bitwise flag enums. > - can specify a custom string value that the enum value generates (not > just the BOOST_PP_STRINGIZE). Yeah I will implement that. Not sure why one would want it, it does nothing but induce confusion in my eyes, but I’m not the one to tell you what to do. > Features that would be nice, but not necessarily expected: > - enum to string and back for "bitwise flag" style enums (eg. CSV names). Not sure what you mean by that, because the regular string conversions work for those just as fine. Do you mean what I wrote above with the OR connected values in a string representation? > - some mapping to std::bitset or similar. That would be interesting! I’ve added it to the feature list, but it will probably take some time . > - can specify multiple string values that map to the same enum value. Hm. I’m not sure if I’d want that, or how that could even be implemented. If somebody wanted non-casesensitive behaviour, it would be better to use a std::string with custom char_traits, and that’s something I’ll definitely offer. > - can specify different conversion tables for the same enum type (for > use in different contexts, eg. serialisation vs. user output). I thought about that, too. I already give the option to choose between std::maps and a linear search for lookups, but I would really like to give the client more options. Those were good suggestions, thank you very much! You’ve given me quite some things to work on, but now I’ve got a pretty decent feature list. --- Felix Uhl Von: Gavin Lambert Gesendet: ‎Mittwoch‎, ‎29‎. ‎Oktober‎ ‎2014 ‎00‎:‎57 An: boost(a)lists.boost.org On 29/10/2014 00:09, Felix Uhl wrote: > So far, the only way to convert an enumeration value to a string is > a lot of boilerplate code consisting of switch case statements for > every single possible value of the enum. Not the only way. The method I use is to create a lookup table via a little macro magic. Granted that I'm then doing a linear scan through the table (whereas a switch statement could be more efficient, or knowledge that the enum is contiguous and could therefore do an index lookup), but having a table allows for other useful queries, and I wanted something that could be defined statically. As a side-benefit (that undoubtedly will horrify some people), the way the code was implemented also allows it to act as a string-to-member-pointer lookup table, which can be quite handy for typed property bags and the like with a string lookup key. > What features would you want from such a library? Features that I would expect of such a library: - support for arbitrary non-contiguous values. - enum value to string. - string to enum value. - list of all valid values, either as strings or values. - can indicate whether a given value (string or enum) is a member of the enumeration. - can round-trip (enum -> string -> enum) values that are not members of the enumeration; of course (string -> enum -> string) is not feasible for non-members. - can specify a custom string value that the enum value generates (not just the BOOST_PP_STRINGIZE). Features that would be nice, but not necessarily expected: - enum to string and back for "bitwise flag" style enums (eg. CSV names). - some mapping to std::bitset or similar. - can specify multiple string values that map to the same enum value. - can specify different conversion tables for the same enum type (for use in different contexts, eg. serialisation vs. user output). _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

Fit: C++ function utility library
by pfultz2 05 Nov '14

05 Nov '14

Hi, I developed a library called Fit, that provides a lot of utilites for dealing with function objects, here: https://github.com/pfultz2/Fit First, it provides a mechanism to construct function objects at compile time using lambdas, for example: const constexpr auto sum = FIT_STATIC_LAMBDA(auto x, auto y) { return x + y; }; Secondly, it provides lots of adaptors to provide "enhancements" to the function. For example, we could make the sum function pipable: const constexpr auto sum = pipable(FIT_STATIC_LAMBDA(auto x, auto y) { return x + y; }); Then call it like this: auto three = 1 | sum(2); Or we could make it an infix operator: const constexpr auto sum = infix(FIT_STATIC_LAMBDA(auto x, auto y) { return x + y; }); And then use it like this: auto three = 1 <sum> 2; Also, it provides the basic partial application and function composition: auto add_1 = partial(sum)(1); auto add_2 = compose(add_1, add_1); auto four = add_2(1); Now, the greatest benifit is being to do better overloading and even recursive functions using lambdas. So, for example, if we wanted to write a more sophisticated `print` function that iterated over ranges and fusion sequences recursively, and printed it all out, we can write this using the Fit library: // Some helpers for template constraints #define REQUIRES(...) typename std::enable_if<(decltype(__VA_ARGS__)()), int>::type = 0 template<template<class...> class Trait, class... Ts> constexpr auto trait(Ts&&...) { return std::integral_constant<bool, Trait<std::remove_reference_t<Ts>...>::value>(); } const constexpr auto print = fix(conditional( // Overload for strings FIT_STATIC_LAMBDA(auto, const std::string& x) { std::cout << x << std::endl; }, // Overload for fusion sequences FIT_STATIC_LAMBDA(auto self, const auto& seq, REQUIRES(trait<boost::fusion::traits::is_sequence>(seq))) { boost::fusion::for_each(seq, self); }, // Overload for ranges FIT_STATIC_LAMBDA(auto self, const auto& range, REQUIRES(trait<boost::has_range_const_iterator>(range))) { for(const auto& x:range) self(x); }, // Overload for anything else FIT_STATIC_LAMBDA(auto, const auto& x) { std::cout << x << std::endl; } )); The documentation for it can be found here: http://pfultz2.github.io/Fit/doc/html/ Any feedback would be appreciated. Also, I don't know if there would be any interest in incorporating this into boost. Thanks, Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Fit-C-function-utility-library-tp4668629… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 5

[Spirit] Lex context and lexer states
by "Claas H. Köhler" 04 Nov '14

04 Nov '14

Hi! Reading the documentation regarding the context object passed by spirit lex I got a little confused: According to the quick ref for semantic actions, http://www.boost.org/doc/libs/1_57_0/libs/spirit/doc/html/spirit/lex/abstra… the context contains functions std::size_t get_state() const and void set_state(std::size_t state). So I presumed the state to be an object of type size_t. However, according to the reference section on lexer concepts http://www.boost.org/doc/libs/1_57_0/libs/spirit/doc/html/spirit/lex/refere… the Lexer state is specified in string form. So my question is: Do both representations exist (i.e. as string & size_t) and can be mapped to each other ? If so, how? Or do I control the desired type via a template parameter ? Are there any examples in the docs containing different lexer states, which could help me to understand the concept ? Any help would be appreciated. Regards Claas

1 0

Code review for bug no. 5702
by ullas srinivas 04 Nov '14

04 Nov '14

Hi, I have fixed bug no. 5702 Bug # 5702 : Filename isreturned within quotes instead without Description : In the reference (http://www.boost.org/doc/libs/1_47_0/libs/filesystem/v3/doc/reference.html#…) it issaid that for example the filename returned by filename() will be without thequotes: std::cout <<path("/foo/bar.txt").filename(); //outputs "bar.txt" (without the quotes) But actually I'm getting anoutput with the filename enclosed in quotes like: "bar.txt" I'm using Windows Vista. Root Cause : Thefilename within quotes are due to printing of os << delim ; statement in template <class Char, classTraits, class Alloc> std::basic_ostream<Char,Traits>& basic_string_inserter_imp(std::basic_ostream<Char, Traits>&os, std::basic_string<Char, Traits, Alloc> const& string, Char escape, Char delim) of boost\io\detail\quoted_manip.hpp Fix : I have commented/removed os << delim; statementin template <class Char, classTraits, class Alloc> std::basic_ostream<Char,Traits>& basic_string_inserter_imp(std::basic_ostream<Char, Traits>&os, std::basic_string<Char, Traits,Alloc> const & string, Char escape, Chardelim) of boost\io\detail\quoted_manip.hpp I kindly request you to please find the patch file attached and review the bug. Regards Ullas

1 0

[ANN] "The Boost C++ Libraries", 2nd edition available
by Boris Schäling 03 Nov '14

03 Nov '14

Just a quick announcement: The 2nd edition of my book "The Boost C++ Libraries" is available. - It introduces 72 Boost libraries. - It contains more than 430 examples. - The print version has about 570 pages. - There is also a Kindle, Epub and PDF version. - It's even online: <http://theboostcpplibraries.com/> A special "thank you" goes to Niall who handled this year's Google Summer of Code program so smoothly that I as a backup admin didn't need to do anything - and had enough time to work on the book. :) Boris

6 8

Boost 1.57.0 has been released
by Marshall Clow 03 Nov '14

03 Nov '14

Release 1.57.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 no new libraries and numerous enhancements and bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1.57.0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.57.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

1 0

[gci2014] Calling for Google Code In 2014 tasks and mentors
by Niall Douglas 03 Nov '14

03 Nov '14

Dear Boost, Google Code In 2014 is nearly upon us, and we need bite sized tasks and mentors! Google Code In lasts between December and mid-January and is for 13 to 17 year olds to get involved with open source projects. Tasks need to be very short, maybe only three hours or so, but correspondingly the effort required to mentor/check these is very low. If you maintain a Boost library and could do with help in fixing up any of those items you keep putting off like replicating bug reports, fixing documentation errors, or configuring Continuous Integration, now is the time! More information is on the GCI ideas page at: https://svn.boost.org/trac/boost/wiki/gci2014 ... where you can add more tasks and also sign yourself up as a mentor. We need this page ready by Saturday 8th November, so please try to get it done before then. Thanks in advance! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Re: [boost] [ANN] "The Boost C++ Libraries", 2nd edition available
by Brian Wood 01 Nov '14

01 Nov '14

On Fri, 31 Oct 2014 12:14:33 +0100, Thorsten Ottosen <tottosen(a)dezide.com> wrote: > I'm very happy to see a small chapter on ptr_container. > It's good that you compare it with container<unique_ptr<T>>. > It looks like poly_collection is left out: http://bannalia.blogspot.com.es/2014/05/fast-polymorphic-collections.html There was discussion of this container on this list back in August. > Comment 1: I would prefer examples with unique_ptr to use make_unique. > I've compared these two lines: auto req=::std::unique_ptr<cmw_request>(::new cmw_request(localbuf)); auto req=::std::make_unique<cmw_request>(localbuf); On clang 3.3, the make_unique version increases the size of an executable's text segment by 112 bytes. I think I've tried it on a newer compiler and found similar results. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

[1.57.0] Release candidates available
by Marshall Clow 01 Nov '14

01 Nov '14

[ Please disregard previous message; apparently I am brain-dead this morning. The uploaded files are correct, though. ] Release candidate files for 1.57.0 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_57_0_rc1.7z) = 17c98dd78d6180f553fbefe5a0f57d12 MD5 (./boost_1_57_0_rc1.tar.bz2) = 1be49befbdd9a5ce9def2983ba3e7b76 MD5 (./boost_1_57_0_rc1.tar.gz) = 25f9a8ac28beeb5ab84aa98510305299 MD5 (./boost_1_57_0_rc1.zip) = 5e040e578e3f0ba879da04a1e0cd55ff Thanks! -- The release managers P.S. Release notes are here: http://www.boost.org/users/history/version_1_57_0.html

1 1

Enhancing regression tests summary
by Adam Wulkiewicz 31 Oct '14

31 Oct '14

Hi, Some time ago I was writing about regression summaries enhancements, that I'd be nice to see more meaningful list of errors, etc. I asked questions, even prepared a PR for regression, to no avail. So I developed a simple program downloading summaries, test logs and saving the enhanced result. You may check it out here: https://github.com/awulkiew/summary-enhancer Regards, Adam

5 8

[regression] [develop] OSError: [Errno 2] No such file or directory: any_test.test
by Suckow, Thomas J 31 Oct '14

31 Oct '14

# Running Boost.Build tests Traceback (most recent call last): File "run.py", line 83, in <module> runner(root) File "/Boost_Regression_Develop/tools_regression_src/regression.py", line 264, in __init__ self.main() File "/Boost_Regression_Develop/tools_regression_src/regression.py", line 650, in main getattr(self,action_m)() File "/Boost_Regression_Develop/tools_regression_src/regression.py", line 615, in command_regression self.command_test() File "/Boost_Regression_Develop/tools_regression_src/regression.py", line 394, in command_test self.command_test_boost_build() File “/Boost_Regression_Develop/tools_regression_src/regression.py", line 438, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); OSError: [Errno 2] No such file or directory: ‘/Boost_Regression_Develop/results/boost/bin.v2/libs/any/test/any_test.test’ Looks like everyone but teeks is failing to build. - Thomas

3 4

[1.56.0] Release candidates available
by Marshall Clow 31 Oct '14

31 Oct '14

Release candidate files for 1.65.0 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_57_0_rc1.7z) = 17c98dd78d6180f553fbefe5a0f57d12 MD5 (./boost_1_57_0_rc1.tar.bz2) = 1be49befbdd9a5ce9def2983ba3e7b76 MD5 (./boost_1_57_0_rc1.tar.gz) = 25f9a8ac28beeb5ab84aa98510305299 MD5 (./boost_1_57_0_rc1.zip) = 5e040e578e3f0ba879da04a1e0cd55ff Thanks! -- The release managers P.S. Release notes are here: http://www.boost.org/users/history/version_1_57_0.html

1 0

[PropertyTree][variant] Reading JSON into a recursive variant.
by Arindam Mukherjee 31 Oct '14

31 Oct '14

I have a recursive variant definition that can handle JSON data. Is there a way to read JSON data using PropertyTree into a recursive JSON? Here is the variant defn. #define BOOST_VARIANT_NO_FULL_RECURSIVE_VARIANT_SUPPORT #include <boost/variant.hpp> JSONNullType {}; boost::variant<std::string, double, bool, JSONNullType> jsonToken; typedef boost::make_recursive_variant< std::string, double, JSONNullType, std::map<std::string, boost::recursive_variant_>, std::vector<boost::recursive_variant_> >::type JSONValue; Regards, Arindam

1 0

Re: [boost] Coming up on 1.57 release date - get your fixes in
by Felix Uhl 30 Oct '14

30 Oct '14

Edward Diener wrote: > Marshall Clow wrote: > > Just this morning we received a report of Boost.PP failing on VS 2013. > > It is not failing. It is just giving a warning. I don’t know for sure, but Marshall may be referring to this ticket: https://svn.boost.org/trac/boost/ticket/10686 On VS2013, VARIADICS and MSVC_VARIADICS don’t get defined despite the fact that they should, rendering some variadic macros useless. Von: Edward Diener Gesendet: ‎Donnerstag‎, ‎30‎. ‎Oktober‎ ‎2014 ‎04‎:‎10 An: boost(a)lists.boost.org On 10/29/2014 10:50 AM, Marshall Clow wrote: > We’ll be closing the master branch tomorrow (Thursday) for the 1.57.0 release. > Changes not in by then will not go into the release. > > Also, what issues in the beta have not been addressed? > >> Visual C++ 14 CTP 4 without BOOST_MSVC_ENABLE_2014_JUN_CTP: all libraries >> built successfully (but some are not usable, mostly because of missing >> noexcept) > >> >> All projects using Boost I tried (Debug 32-bit + 64-bit) compiled >> successfully with MSVC12. For MSVC14, TypeTraits 9de6a49 is missing in >> master. > > I believe that these have been merged. > >> Interprocess is broken for MinGW and there are some issues with Intrusive in GCC. I've committed fixes for both. > > I believe that this has been merged. > > Thread fixes have been merged. > > I do not know if the patches described in http://lists.boost.org/Archives/boost/2014/10/217257.php have been merged. > >> range/detail/any_iterator.hpp is broken because it expects >> postfix_increment_proxy and writable_postfix_increment_proxy to be in >> namespace boost::detail, but they are in boost::iterators::detail now. > > This does NOT appear to have been fixed > >> boost serialization is still broken(said so: http://article.gmane.org/gmane.comp.lib.boost.user/82715 ) and to date i do know no workaround to get my library to work on fx Arch Linux without telling users to rebuild with boost 1.55 (or sending them a saved package from my system…) > > I do not know what the status of this is; but there have been no commits to range/master in October. > > Just this morning we received a report of Boost.PP failing on VS 2013. It is not failing. It is just giving a warning. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[testing] Compile failures on MSVC (teeks)
by Andrey Semashev 30 Oct '14

30 Oct '14

Hi, I'm seeing weird compilation failures on Teeks (MSVC 10 and 11): http://www.boost.org/development/tests/develop/developer/output/teeks99-08c… http://www.boost.org/development/tests/develop/developer/output/teeks99-08d… The weird part is this: D:\teeks99-08\d\boost_root\boost/fusion/support/detail/result_of.hpp(32) : error C2143: syntax error : missing ',' before '...' I cannot find the boost/fusion/support/detail/result_of.hpp file in git. Am I missing something or these test machines are broken somehow?

2 1

Coming up on 1.57 release date - get your fixes in
by Marshall Clow 30 Oct '14

30 Oct '14

We’ll be closing the master branch tomorrow (Thursday) for the 1.57.0 release. Changes not in by then will not go into the release. Also, what issues in the beta have not been addressed? > Visual C++ 14 CTP 4 without BOOST_MSVC_ENABLE_2014_JUN_CTP: all libraries > built successfully (but some are not usable, mostly because of missing > noexcept) > > All projects using Boost I tried (Debug 32-bit + 64-bit) compiled > successfully with MSVC12. For MSVC14, TypeTraits 9de6a49 is missing in > master. I believe that these have been merged. > Interprocess is broken for MinGW and there are some issues with Intrusive in GCC. I've committed fixes for both. I believe that this has been merged. Thread fixes have been merged. I do not know if the patches described in http://lists.boost.org/Archives/boost/2014/10/217257.php have been merged. > range/detail/any_iterator.hpp is broken because it expects > postfix_increment_proxy and writable_postfix_increment_proxy to be in > namespace boost::detail, but they are in boost::iterators::detail now. This does NOT appear to have been fixed > boost serialization is still broken(said so: http://article.gmane.org/gmane.comp.lib.boost.user/82715 ) and to date i do know no workaround to get my library to work on fx Arch Linux without telling users to rebuild with boost 1.55 (or sending them a saved package from my system…) I do not know what the status of this is; but there have been no commits to range/master in October. Just this morning we received a report of Boost.PP failing on VS 2013. Have I missed any of the beta issues? — Marshall

7 11

[fusion] Broken compilation on MSVC (was: [testing] Compile failures on MSVC (teeks))
by Andrey Semashev 30 Oct '14

30 Oct '14

On Thu, Oct 30, 2014 at 1:28 PM, Andrey Semashev <andrey.semashev(a)gmail.com> wrote: > Hi, > > I'm seeing weird compilation failures on Teeks (MSVC 10 and 11): > > http://www.boost.org/development/tests/develop/developer/output/teeks99-08c… > > http://www.boost.org/development/tests/develop/developer/output/teeks99-08d… > > The weird part is this: > > D:\teeks99-08\d\boost_root\boost/fusion/support/detail/result_of.hpp(32) > : error C2143: syntax error : missing ',' before '...' > > I cannot find the boost/fusion/support/detail/result_of.hpp file in > git. Am I missing something or these test machines are broken somehow? Oh, sorry, I was looking at the master local branch, and it fails on develop. Anyway, the header is there and it is broken for compilers not supporting variadic templates.

1 0

Re: [boost] 1.57.0 beta 1 is now available
by Felix Uhl 30 Oct '14

30 Oct '14

Edward Diener wrote: >John Doré wrote: >> Unfortunately this gives us the warning: >> >> warning C4003: not enough actual parameters for macro 'BOOST_PP_EXPAND_I' > > It is an expected warning from Boost PP, which can be ignored. The VC++ > preprocessor is not a C++ standard conforming preprocessor so it gives > warnings when none are necessary. There is virtually nothing that can be > done against such warnings except to attempt to turn them off completely > within Boost PP code. I will look into doing this but often it is > impossible to do since VC++ often does not honor where the preprocessor > warning actually takes place when an effort is made to eliminate the > warning at that place. Does that mean the regular >#pragma warning(disable : 4003) doesn’t work for pre-processor related warnings?

1 0

1.57.0 beta 1 is now available
by Marshall Clow 30 Oct '14

30 Oct '14

Boost release 1.57.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/boost-binaries/1.57.0.beta.1/ This release contains no new libraries. For details of what's in the release, see http://www.boost.org/users/history/version_1_57_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 P.S. There are a couple of known problems with this beta: * There are problems building with MSVC 8.0 * There are some problems with range/detail/any_iterator.hpp. These will be fixed before the release.

9 10

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 30 Oct '14

30 Oct '14

Artyom Tokmakov wrote: > Have you considered X-macro trick? Yes, and I heavily dislike the syntax. I played around with it a bit and it is absolutely not feasible for this use case. My goal is a simple, intuitive and easy to use syntax. With xmacros you’d have to define an enum in a separate file, Which only makes sense for really, really large enumerations.

1 0

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 29 Oct '14

29 Oct '14

Artyom Tokmakov wrote: >In addition to various useful suggestions on the list, I would ask for >implementation to support (almost) any large number of enum elements >(enumerators) within enum declaration.: >I have ad-hoc implementation of my own which uses Boost.Proprocessor's >sequence to define enum elements. Then I can generate whatever >parser/printer/other code I want (I find that very useful). >There's a disadvantage, however: obvious limitation of max 256 >elements (at least, by default) coming from Boost.Preprocessor. And that’s where the problem lies. To enable large numbers of enum values, I’d have to find a solution without using Boost.PP. Without C++ introducing argument number based macro overloading, that is not possible, short of defining my own macro sequences for more than 256 elements, which I would like to avoid. I am still thankful that you asked for this, because it uncovered a huge implementation problem which induces enormous compilation overhead (1 minute for 48 enum values on my laptop). I will do my best to make the library comprehend large enums, but I can’t guarantee anything larger than 256. --- Felix Uhl

2 1

Is there interest in a library for string-convertible enums?
by Felix Uhl 29 Oct '14

29 Oct '14

So far, the only way to convert an enumeration value to a string is a lot of boilerplate code consisting of switch case statements for every single possible value of the enum. I’ve written a small header-only library that uses Boost.Preprocessor and templates to ease the definition of named enumerations that are convertible to and from strings. Those can also be used with the std::cin and std::cout streams naturally, while maintaining all syntactic and semantic properties, regarding initialisation, assignment, type safety and conversion to underlying types. Currently, I am documenting the first version of the library to make it available on the Boost Library Incubator website, but I wanted to get some initial feedback from the developers mailing list, too. I would be glad to extend the library to a general extension of enumeration behaviour, like changing the generation of underlying values from a continuous increment to a continuous shift left by one, effectively making the underlying values binary flags. What features would you want from such a library? Is there even a chance that such a library would get included in boost (given that it satisfied the quality requirements), or is there too little interest in this functionality?

8 7

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 29 Oct '14

29 Oct '14

Pieter wrote: > Are you aware of the earlier effort by Frank Laub? Frankly (no pun intended), I am not. It would be interesting to see how he has implemented that and what caveats his implementation has. --- Felix

1 0

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 29 Oct '14

29 Oct '14

Jeffrey Bush wrote: > I have also offered a class for doing this as well, although it didn't draw > the interest that this one did. > Here was my attempt at it with a test/example class: > https://gist.github.com/coderforlife/6d8bac451d49dd1a0c81 Looks good to me, and seems to be quite close to what I aim at. But the definition seems very user unfriendly. Is it correct that you always have to declare enums in the public namespace? --- Felix

1 0

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 29 Oct '14

29 Oct '14

Rob Stewart wrote: > You should not add features because someone on this list asked for them. > If you're not convinced of the utility of something, push back > to understand the request better. This sounds like advice I should follow. I tend to forget that I’m not writing for a specific client. Also, I noticed that the library has too much compile time overhead already, which should be fixed before introducing any additional ground-breaking features. So I’ve gone through the features suggested and ordered them by priority, perhaps the requesters of the following ones could answer my questions about them and specify why they think these features would be a good addition to the library: By Damien Buhl: - Adaptation of enums after declaration with something like BOOST_ADAPT_ENUM Is this really worth the effort? If somebody knows they want to string-convert an enum (or enum class), why would they not define it as one in the first place? Or is this about enumerations that are already defined by other libraries? Would it be ok to instead define a new enum that has the “to adapted” one as its underlying type and can thus be converted to and from it? There are implementational problems with offering both namespace independent definition of those enums and adaptability. By Gavin Lambert: - Specify custom and multiple strings In which use cases would this actually be beneficial for anyone? Could those use cases be solved by using custom char_traits or even custom string classes? - Specify different conversion tables for use in different contexts What do you exactly mean by that? Conversion to different string values? Conversion by different algorithms? Again, if you could answer those questions, it would really help evaluation. --- Felix

1 0

[gsoc] Any interest in Google Code In?
by Niall Douglas 29 Oct '14

29 Oct '14

The application period for Google Code In 2015 has opened. This is a "tiny GSoC" programme for high school students where the tasks set might take the student three to five hours each. Stuff like writing documentation, improving unit testing, duplicating bug reports, making YouTube video tutorials, blogging about or writing an essay about getting a Boost development setup ready, even refactoring small segments of code if the student is up to it. The important part is the shortness of work item, and of course that you review it and give constructive feedback. More detail is at https://developers.google.com/open-source/gci/. Some example tasks from last year are at https://developers.google.com/open-source/gci/resources/example-tasks. Is there any interest from the Boost community in mentoring such high school student work? If so, now is the time to say. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

Re: [boost] Is there interest in a library for string-convertible enums?
by Artyom Tokmakov 29 Oct '14

29 Oct '14

> What features would you want from such a library? Hello, thanks for the proposal, it's very useful! In addition to various useful suggestions on the list, I would ask for implementation to support (almost) any large number of enum elements (enumerators) within enum declaration.: I have ad-hoc implementation of my own which uses Boost.Proprocessor's sequence to define enum elements. Then I can generate whatever parser/printer/other code I want (I find that very useful). There's a disadvantage, however: obvious limitation of max 256 elements (at least, by default) coming from Boost.Preprocessor. In fact, I hit some other limitations even before that. One of them was max 'if else' statements (I used them in parser implementation. Don't judge me, it was good enough!). When I fixed that, my VC compiler started complaining about some macro processor limitations around 220 enum elements (don't have details handy). Speed of parsing/printing implementation doesn't matter for me. PS: This is my first post in this DL, sorry if I broke some rules. -- Best regards, Artem Tokmakov

1 0

Re: [boost] Is there interest in a library for string-convertible enums?
by Jeffrey Bush 29 Oct '14

29 Oct '14

> > So far, the only way to convert an enumeration value to a string is a lot > of boilerplate code consisting of switch case statements for every single > possible value of the enum. > > > I?ve written a small header-only library that uses Boost.Preprocessor and > templates to ease the definition of named enumerations that are convertible > to and from strings. Those can also be used with the std::cin and std::cout > streams naturally, while maintaining all syntactic and semantic properties, > regarding initialisation, assignment, type safety and conversion to > underlying types. > > > Currently, I am documenting the first version of the library to make it > available on the Boost Library Incubator website, but I wanted to get some > initial feedback from the developers mailing list, too. I would be glad to > extend the library to a general extension of enumeration behaviour, like > changing the generation of underlying values from a continuous increment to > a continuous shift left by one, effectively making the underlying values > binary flags. > > > What features would you want from such a library? Is there even a chance > that such a library would get included in boost (given that it satisfied > the quality requirements), or is there too little interest in this > functionality? > I have also offered a class for doing this as well, although it didn't draw the interest that this one did. Here was my attempt at it with a test/example class: https://gist.github.com/coderforlife/6d8bac451d49dd1a0c81 Supports value to string and string to value, including multiple values with | between them, meaning all combinations can be round-tripped. Supports default power-of-two values and custom values, listing all valid values (as enum types, but each is easily convertible to integral and string values), Although you cannot specify custom string names for an enum value that is not the "STRINGIZE" name, however you can choose to have multiple enum entries with the same value and different names. Jeff

1 0

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 28 Oct '14

28 Oct '14

Marcel Raad wrote: >being able to specify the underlying >type, not being implicitly convertible >to any other type, and being able to >forward-declare them. Apart from forward-declaration, that’s what I’ve implemented. I want to stay as close to the stock enum class as possible. Forward declaration is added to the feature list :) --- Felix Uhl

1 0

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 28 Oct '14

28 Oct '14

On 28/10/2014, Rob Stewart wrote: >That sounds interesting. Ease of use and compilation overhead are concerns, of course. I’ll answer your ease of use concern with example code for definition of the enum class Zott: >BOOST_ADVANCED_ENUM_DEFINE( Zott, > zero, > one, > two, > three >); And now for the mentioned “flag” values: >BOOST_ADVANCED_ENUM_DEFINE_W_SUPPLY( > TwoToThePowerOf, > ::boost::advanced_enum::supplies:shiftL1::values, > zero, > one, > two, > three >); Seems easy enough. The second one could be shortened to another macro, of course. Arbitrary values have a bit strange syntax, though: >BOOST_ADVANCED_ENUM_DEFINE_W_SUPPLY( > BOOST_ADCANCED_ENUM_ARBITRARY(4, 8, 6, 20), > four, > eight, > six, > twenty >); I’ll see what I can do about that. Conversions to and from string are done via static_cast (not sure if that’s the ideal solution), in- and output work naturally like this: >Zott myZott = Zott:one; >std::cin >> myZott; //if input is not convertible, no changes are made >std::cout << myZott; I think that's as easy as it can get :) Compilation overhead indeed needs to be considered. >What about enum classes? My mistake, with “named enums” I meant “enum classes”, but now that you say it, I should try to implement string convertible regular enums as well. Thank you for your feedback! --- Felix Uhl Von: Rob Stewart Gesendet: ‎Dienstag‎, ‎28‎. ‎Oktober‎ ‎2014 ‎22‎:‎23 An: boost(a)lists.boost.org On October 28, 2014 7:09:35 AM EDT, Felix Uhl <felix.uhl(a)outlook.de> wrote: >So far, the only way to convert an enumeration value to a string is a >lot of boilerplate code consisting of switch case statements for every >single possible value of the enum. As Niall noted, most of us have done that before. >I’ve written a small header-only library that uses Boost.Preprocessor >and templates to ease the definition of named enumerations that are >convertible to and from strings. That sounds interesting. Ease of use and compilation overhead are concerns, of course. >Currently, I am documenting the first version of the library to make it >available on the Boost Library Incubator website, I can hear Robert yelling, "Yes!" > but I wanted to get >some initial feedback from the developers mailing list, too. I would be >glad to extend the library to a general extension of enumeration >behaviour, like changing the generation of underlying values from a >continuous increment to a continuous shift left by one, effectively >making the underlying values binary flags. That would certainly be useful. What about enum classes? ___ Rob (Sent from my portable computation engine) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 28 Oct '14

28 Oct '14

On 08/10/2014, Damien Buhl wrote: >What I would like to is to have a complete adapted enum for >Boost.Fusion, this was implemented at some point in some old version of >Boost.Fusion but I cannot find it anymore. Yes, interoperability with other boost libraries is a huge point to consider, and I like the concepts of Boost.Fusion a lot. I also thought about MPL, getting the names as compile time strings could be really useful. >And before all it's important I believe that it doesn't ask the user to >write the enums with macros, but that an additional call later to >something like BOOST_ADAPT_ENUM adds the boilerplate code. >It's naturally possible to offer both choice to the user like >BOOST_FUSION_ADAPT_STRUCT / BOOST_FUSION_DEFINE_STRUCT. I don’t think it is possible to offer an ADAPT_STRUCT macro without forcing the client to either rewrite every single value of the enumeration or define the enum with another macro in the first place. The former would could become problematic when clients change what values the enum actually contains but forget to change that in the macro. I would really want to enable the most natural syntax possible, but even a flexible language like C++ has boundaries where you can’t bend it anymore. So yes, I will offer both to the user. Thanks for your feedback! Felix Uhl Von: Damien Buhl Gesendet: ‎Dienstag‎, ‎28‎. ‎Oktober‎ ‎2014 ‎22‎:‎47 An: boost(a)lists.boost.org Hi Felix, Personally I'm interested, because so far I've been always using a silly macro for this, which doesn't make much : > #ifndef SWISSARMYKNIFE_ENUMS_ADAPT_ENUM_HPP > #define SWISSARMYKNIFE_ENUMS_ADAPT_ENUM_HPP > > #include <string> > #include <ostream> > #include <boost/preprocessor/cat.hpp> > #include <boost/preprocessor/stringize.hpp> > #include <boost/preprocessor/seq/for_each.hpp> > > > #define SWISSARMYKNIFE_ADAPT_ENUM_EACH_ENUMERATION_ENTRY_C( \ > R, unused, ENUMERATION_ENTRY) \ > case ENUMERATION_ENTRY: \ > return BOOST_PP_STRINGIZE(ENUMERATION_ENTRY); \ > break; > > #define SWISSARMYKNIFE_ADAPT_ENUM(ENUM_TYPE, ENUMERATION_SEQ) \ > inline std::string to_string(const ENUM_TYPE& enum_value) { \ > switch (enum_value) { \ > BOOST_PP_SEQ_FOR_EACH( \ > SWISSARMYKNIFE_ADAPT_ENUM_EACH_ENUMERATION_ENTRY_C, \ > unused, ENUMERATION_SEQ) \ > default: \ > return BOOST_PP_STRINGIZE(ENUM_TYPE); \ > } \ > } \ > \ > inline std::ostream& operator<<(std::ostream& os, const ENUM_TYPE& value) { \ > os << to_string(value); \ > return os; \ > } > > #endif What I would like to is to have a complete adapted enum for Boost.Fusion, this was implemented at some point in some old version of Boost.Fusion but I cannot find it anymore. Because if this had the extension struct_member_name or some other better named extension, then I could print out all the possible states with some generic code like I print struct member name with "boost::fusion::for_each_member(enumValue, *this);" > #ifndef BOOST_FUSION_FOR_EACH_MEMBER_HPP > #define BOOST_FUSION_FOR_EACH_MEMBER_HPP > > #include <functional> > > #include <boost/fusion/include/adapt_struct.hpp> > > #include <boost/fusion/sequence/intrinsic/begin.hpp> > #include <boost/fusion/sequence/intrinsic/end.hpp> > #include <boost/fusion/sequence/intrinsic/front.hpp> > #include <boost/fusion/iterator/equal_to.hpp> > #include <boost/fusion/iterator/next.hpp> > #include <boost/fusion/iterator/deref.hpp> > #include <boost/fusion/iterator/distance.hpp> > #include <boost/fusion/support/category_of.hpp> > #include <boost/mpl/bool.hpp> > > namespace boost { namespace fusion { > > namespace detail { > > template <typename First, typename Last, typename F> > inline void > for_each_member_linear(First const& first, > Last const& last, > F const& f, > boost::mpl::true_) {} > > template <typename First, typename Last, typename F> > inline void > for_each_member_linear(First const& first, > Last const& last, > F const& f, > boost::mpl::false_) { > > f( > extension::struct_member_name< > typename First::seq_type, First::index::value > >::call(), > *first > ); > > for_each_member_linear( > next(first), > last, > f, > result_of::equal_to< typename result_of::next<First>::type, Last>() > ); > } > > template <typename Sequence, typename F> > inline void > for_each_member(Sequence& seq, F const& f) { > > detail::for_each_member_linear( > fusion::begin(seq), > fusion::end(seq), > f, > result_of::equal_to< > typename result_of::begin<Sequence>::type, > typename result_of::end<Sequence>::type>() > ); > } > > } > > template <typename Sequence, typename F> > inline void > for_each_member(Sequence& seq, F f) { > detail::for_each_member(seq, f); > } > > }} > > #endif And before all it's important I believe that it doesn't ask the user to write the enums with macros, but that an additional call later to something like BOOST_ADAPT_ENUM adds the boilerplate code. It's naturally possible to offer both choice to the user like BOOST_FUSION_ADAPT_STRUCT / BOOST_FUSION_DEFINE_STRUCT. Cheers, -- Damien Buhl On 10/28/2014 12:09 PM, Felix Uhl wrote: > So far, the only way to convert an enumeration value to a string is a lot of boilerplate code consisting of switch case statements for every single possible value of the enum. > > > Iâ€™ve written a small header-only library that uses Boost.Preprocessor and templates to ease the definition of named enumerations that are convertible to and from strings. Those can also be used with the std::cin and std::cout streams naturally, while maintaining all syntactic and semantic properties, regarding initialisation, assignment, type safety and conversion to underlying types. > > > Currently, I am documenting the first version of the library to make it available on the Boost Library Incubator website, but I wanted to get some initial feedback from the developers mailing list, too. I would be glad to extend the library to a general extension of enumeration behaviour, like changing the generation of underlying values from a continuous increment to a continuous shift left by one, effectively making the underlying values binary flags. > > > What features would you want from such a library? Is there even a chance that such a library would get included in boost (given that it satisfied the quality requirements), or is there too little interest in this functionality? > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[Lockfree] has_trivial_destructor and has_trivial_assign restrictions
by Dan Dillon 28 Oct '14

28 Oct '14

I've been doing some thinking about this, and to my untrained eye these restrictions do not seem to be a requirement of the lock-free structure. That is to say, they need not be atomic anyhow, so why does it matter if they are trivial or not? The question goes to making the data structures more globally useful. The more structures they can be used with, the better they are (at least in my opinion). Thanks, Dan

2 1

Custom logging backend difficulty
by Kenneth Adam Miller 28 Oct '14

28 Oct '14

So, I need malleable logging facilities, and so far I've identified boost's logging facilities as useful. I've read the docs on logging, and right now I'm having difficulty achieving what I want-basically, I have a custom backend, in order that when logging is done, it gets routed to an alternative destination - over the network namely. I extended from text_ostream_backend, and basically I'm having the following trouble: I don't understand the record_view visitation API. I'd like the ability to set formatters and what not to remain untouched, but have the final formatted result sent off else where. I can change this by sending the string received in the consume function that has to be overrode, but the values are lost in the record_view. void consume (const record_view & rec, std::string s); where I do { send(s); } for the body. What I think is necessary is just to retain the default behavior of accepting whatever formatter was specified... What is the best way to go about achieving what I want?

3 8

1.57.0 beta 1 is in a new location
by Marshall Clow 27 Oct '14

27 Oct '14

Tom Kent pointed out that I put the beta 1 files in a folder that we traditionally use for Windows binaries, so I have moved the beta files to https://sourceforge.net/projects/boost/files/boost/1.57.0.beta.1/ These are the same files as last Monday - merely in a new location. If you have already downloaded and tested the beta, thanks! - no need to do it again. — Marshall

1 0

Re: [boost] Non-allocating constexpr functional continuations-based future-promise
by Bjorn Reese 26 Oct '14

26 Oct '14

On 10/23/2014 11:00 PM, Niall Douglas wrote: > Given Hartmut's feedback from my previous attempt at a non-allocating > future-promise implementation, I now have a second, much more generic > demonstration prototype which is based on heterogenous sequences of > constexpr functional calls. I think this design may have huge potential. This is a very nice evolution of your previous promise-future framework. > template<class T> struct then_continuation > { > std::vector<std::function<void(T)>> _conts; > template<class U> auto then(U &&c) > { > typedef decltype(c(std::declval<T>())) result_type; > promise<result_type> p; > future<result_type> ret(p.get_future()); > // Unfortunately libstdc++'s std::function currently always tries to > copy lambda types > //_conts.emplace_back([p=std::move(p), c=std::forward<U>(c)](T > v){p.set_value(c(v));}); > _conts.push_back([p = > std::make_shared<promise<result_type>>(std::move(p)), > c=std::forward<U>(c)](T v){p->set_value(c(v));}); > return ret; > } > BOOST_CONSTEXPR T operator()(T v) const > { > for(auto &i : _conts) > i(v); > return v; > } > }; > > All this continuation does is provide a .then(callable) which stores those > callables into a std::vector and its operator() executes the previously > stored callables. Previously you defined callables as composed functions, but here you execute them sequentially. That is, then(f1).then(f2) gets executed as f1(v),f2(v) instead of f2(f1(v)). Or am I missing something?

2 1

[boost.lockfree] spsc_queue preallocated memory block
by Philip Bennefall 25 Oct '14

25 Oct '14

Hi all, I have a feature request for Boost.lockfree (spsc_queue in particular). When using the runtime sized version, could there possibly be a constructor that takes max_size as well as a T* that is then used as the memory buffer? This would remove the need for a specialized allocator if I want to quickly initialize the buffer with memory that does not come from the default std allocator. Kind regards, Philip Bennefall

2 2

Re: [boost] Applying Boost Phoenix to infinite sequence
by Aaron Levy 25 Oct '14

25 Oct '14

25.10.2014, 00:54, "Aaron Levy" <aaron.levy(a)yandex.com>: > Is there a way to use Boost Phoenix to define an infinite sequence and evaluate specific terms of it, compute partial sums, etc? I am looking for pointers to specific libraries or examples. > Indeed, what would are some examples of common programming problems that can be succinctly solved using Phoenix? Aaron.

2 1

Why is iterator_traits<unordered_map<K, M>>::pointer a detail::ptr_node type rather than value_type *?
by Alex Mohr 24 Oct '14

24 Oct '14

The iterator type looks like: template <typename NodePointer, typename Value> struct iterator : public boost::iterator< std::forward_iterator_tag, Value, std::ptrdiff_t, NodePointer, Value&> The NodePointer argument here (which is boost::unordered::detail::ptr_node<...>) becomes the iterator_traits<>::pointer type. But iterator's operator->() returns Value *: Value* operator->() const { return &node_->value(); } Why shouldn't iterator_traits<>::pointer be Value* here? This detail::ptr_node<> type seems intended to be completely internal. Thanks, Alex

3 2

Non-allocating constexpr functional continuations-based future-promise
by Niall Douglas 23 Oct '14

23 Oct '14

>

1 0

Non-allocating constexpr functional continuations-based future-promise
by Niall Douglas 23 Oct '14

23 Oct '14

Dear Boost, Given Hartmut's feedback from my previous attempt at a non-allocating future-promise implementation, I now have a second, much more generic demonstration prototype which is based on heterogenous sequences of constexpr functional calls. I think this design may have huge potential. Consider some heterogenous sequence of callables C { f1, f2, f3, f4, ... } such that fN(... f4(f3(f2(f1(Args...))))) -> R i.e. if you call the heterogenous sequence with arguments Args..., f1(args...) will be called and fed to f2() which then is fed to f3() up to fN() whose return type is R. If I understand proposed Boost.Hana correctly, these potentially constexpr sequences of heterogeneous callables are the main bridge between pure compile-time heterogeneous type sequences and doing something with them in real code as they can decay on demand into actual code when needed. And for proposed Boost.Expected, its monadic programming sequences bind(), map() and then() all functionally operate on some expected<T, E>, consuming an instance and returning new instances, so these monadic sequences are also potentially constexpr sequences of heterogenous callables. Now, what new basic_future-basic_promise will do is to allow you to insert a suspend-resume of execution into some functional sequence C, so essentially: split<idx>(C) => [ basic_promise<X>, basic_future<Y> ] ... where X is some split front part of C and Y is some back part of C. You can now execute the first part of C via the call operator: basic_promise<X>(Args...) Execution of the C0...Cn making up X occurs, but instead of continuing into Y it stores the result of Cn and makes that available to the corresponding basic_future. At some later point you can resume the execution of C: basic_future<Y>() -> R ... and thus complete the execution of the functional sequence C, returning the same value R as invoking the original functional sequence C with the same input parameters. For those who prefer to understand theory via code, here is some example C++ 14 code: // Let this be an arbitrarily long sequence of functional callables auto ct=make_continuations([](auto x){return 5+x;}, [](auto x){ return x+6;}); { // Make a future promise pair for if we called c(int) auto fp=ct.suspend_resume<1, int>(); // Execute promise fp.first(1); // Execute future b=std::move(fp.second)(); } { // Make a future promise pair for if we called c(double) auto fp=ct.suspend_resume<1, double>(); // Execute promise fp.first(1.0); // Execute future d=std::move(fp.second)(); } // b=12, d=12.0 There are a multitude of uses for this very fundamental pattern. Let us try implementing something closely resembling the Concurrency TS's dynamic continuations support .then(launch, callable). Let us define this functional continuation: template<class T> struct then_continuation { std::vector<std::function<void(T)>> _conts; template<class U> auto then(U &&c) { typedef decltype(c(std::declval<T>())) result_type; promise<result_type> p; future<result_type> ret(p.get_future()); // Unfortunately libstdc++'s std::function currently always tries to copy lambda types //_conts.emplace_back([p=std::move(p), c=std::forward<U>(c)](T v){p.set_value(c(v));}); _conts.push_back([p = std::make_shared<promise<result_type>>(std::move(p)), c=std::forward<U>(c)](T v){p->set_value(c(v));}); return ret; } BOOST_CONSTEXPR T operator()(T v) const { for(auto &i : _conts) i(v); return v; } }; All this continuation does is provide a .then(callable) which stores those callables into a std::vector and its operator() executes the previously stored callables. Now let us define a std::promise lookalike, with its main deficiencies being a total lack of exception_ptr support (one would use expected<T, E> as the transport type for that) and of course any thread safety: template<class T> class promise : public basic_promise<detail::then_continuation<T>, T, detail::then_continuation<T>> ... basic_promise takes three template parameters, the type of the front split of the continuations, the transported type between the two halves of continuations, and the type of the back split of the continuations. Here, we are defining promise as transporting a type T, and two then_continuation continuations exist before and after the transport of the type T. To our future<T> lookalike we now add this: template<class U> auto then(launch policy, U &&c) { if(policy==launch::deferred) return Base::_after.then(std::forward<U>(c)); else if(Base::_other) return Base::_other->_before.then(std::forward<U>(c)); } So, if the .then() dynamic continuation is deferred, push it into the latter then_continuation, else push it into the former. And voila, you can now do this very similar to Concurrency TS code: promise<int> p; future<int> f(p.get_future()); future<double> f2(f.then(launch(), [](int a){return a+1.0;})); p.set_value(5); return f2.get(); And you get back 6.0, as expected. However here is where things get neato. How many instructions do you think GCC 4.9 generates for this sequence? promise<int> p; future<int> f(p.get_future()); p.set_value(5); return f.get(); In traditional future-promise, that is an operation perhaps consuming thousands of CPU cycles and at least one memory allocation and deallocation. Well, this is the assembler produced by the above by GCC 4.9: _Z19test_futurepromise4v: movq $0, -88(%rsp) movq $0, -80(%rsp) movl $5, %eax movq $0, -72(%rsp) movq $0, -48(%rsp) movq $0, -40(%rsp) movq $0, -32(%rsp) movl $5, -56(%rsp) movq $0, -64(%rsp) movq $0, -24(%rsp) ret Believe it or not, this is actually bad output - there is a bug in GCC's optimiser and it should in fact be outputting a single instruction rather than writing zeros into the stack for no purpose - it seems to get confused by the double declation of a std::vector which is never used, because having just one std::vector produces the ideal output but having two produces the above. However clang 3.4's optimiser does far worse, and a bug there with how non-immediately defined types are treated causes complete expansion of code in its entirety, even if you remove all std::vector's (supplying any type not immediately declared in the same function breaks the optimiser for some unknown reason. I haven't tried clang 3.5 yet, it may be fixed). Other very interesting policy continuations which can be statically mixed into custom future promise types include calling some application specific callback without needing to indirect via a pointer to a function. This lets you combine future promise with invoking callbacks, useful for legacy code. The idea behind this suite of future-promise fundamental parts is that they can be mixed at will into bespoke future-ish promise-ish application specific future promise types. Because they all share the same foundations, a when_any() or when_all() can accept heterogenous future types - and I don't mean future<int> with future<double>, rather I mean afio::future<> with qt::future<int>, that sort of heterogenity. Another very interesting idea is combining these with signals and slots, so via custom continuations you can keep slots and fire signals in sync with future promises. This design I think shows a lot of potential. Anyway, I feel very happy with this design, and something along these lines is where I shall proceed next. The eventual intention is for these future promises to become the default Boost.Thread future promises when C++11 is available, though this will be up to a year from now. I won't be able to support future-promise custom allocators, but I certainly should be able to completely avoid memory allocation and sometimes the generation of any code at all with this design. The demonstration prototype code is at https://github.com/ned14/boost.spinlock/blob/expected_future/test_constexpr_ future_promise2.cpp for anyone interested. It needs a C++ 14 compiler, so a minimum of libstdc++ 4.9 and either GCC 4.9 or clang 3.4 or better. Comments are welcome. Niall

1 0

DTLS support in boost
by Indtiny S 22 Oct '14

22 Oct '14

Hi, Currently I am using boost for one of my cpp application ... now my application needs DTLS security support ... I currently have written using openssl APIs .. I want nowb...does boost asio has any APIs for DTLS handshake ? Rgds Indhra

1 0

[thread] linux.hpp, BOOST_HAS_PTHREAD_YIELD, BOOST_HAS_SCHED_YIELD
by Rob Conde 22 Oct '14

22 Oct '14

Reposting this here since I got no response on "users" but this list seems more appropriate: Using boost 1.55, Ubuntu 12.04, gcc 4.6 I'm building boost on linux using the lsb sdk (4.1.8) . I was getting the failure (paraphrased): pthread_yield not declared in libs/thread/src/thread.cpp 513 The documentation for pthread_yield (http://man7.org/linux/man-pages/man3/pthread_yield.3.html) says: This call is nonstandard, but present on several other systems. Use the standardized sched_yield(2)<http://man7.org/linux/man-pages/man2/sched_yield.2.html> instead. If I change boost/config/platform/linux.hpp to define BOOST_HAS_SCHED_YIELD instead of BOOST_HAS_PTHREAD_YIELD Then sched_yield is used instead and the build finishes properly. I'm posting this for two reasons: 1. To help others running into the same issue 2. To question whether linux.hpp should be updated officially as I did above 3. If not, why Thanks, Rob Conde

2 3

Help with boost spirit
by Theodore Papadopoulo 22 Oct '14

22 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry, this is probably a beginner question, but I'm stuck on it for quite some time. I'm trying to write a small string like parser in which the size of the string is first given. Some thing like: int_ >> repeat(_1)[ char_ ] But I cannot figure out the right way of doing this. The natural: const bool result = boost::spirit::qi::parse(it,str.end(),int_ >> repeat(_1)[ char_ ]); fails to compile (and I tried many variations of val, etc) with no success. If I replace _1 by 10, everything works fine. Another question is that of the associated attribute. From the documentation, I would have expected it to be: typedef std::pair<int,std::vector<unsigned char>> Attribute; but that does not work. I have managed to work around this using a second rule, using an attribute std::vector<char>(int) but then again I do not know how to pass the parameter. 10 works but _1 does not. Any help will be appreciated. Some test code is attached, compile with: g++ -g -std=c++11 -dboost_spirit_use_phoenix_v3 Test.C. Variants are in comment. Thank's in advance for any help. Theo. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlQ9GqgACgkQEr8WrU8nPV0b2gCeNFzQXwm1Uux4Eua2+jq8LcZk DW0AoKBKY9KN5kGxYoPbnxwncwFSyH3M =L0bR -----END PGP SIGNATURE-----

2 2

[1.57.0] Release Notes
by Daniel James 22 Oct '14

22 Oct '14

Hi, Sorry this is late, but if you haven't written your release notes, you should do so soon. You can create a pull request on github by clicking on the pencil icon on the toolbar on this page while logged in: https://github.com/boostorg/website/blob/master/feed/history/boost_1_57_0.q… Or if you prefer you can email me, and I'll add it for you. thanks, Daniel

3 2

Non-allocating future-promise
by Niall Douglas 21 Oct '14

21 Oct '14

Dear Boost, I have been working on non-allocating future-promise which when combined with proposed expected<T, E> (i.e. basic_promise<expected<T, E>>) will provide a close substitute to std::future/promise, except that it doesn't use an allocator and can reduce to pure constexpr when possible e.g. this code: __attribute__((noinline)) int test1() { promise<int> p; auto f(p.get_future()); p.set_value(5); return f.get(); } ... reduces to exactly: _Z5test1v: # @_Z5test1v .cfi_startproc # BB#0: # %_ZN7promiseIiJEED2Ev.exit2 movl $5, %eax ret The non-allocating future-promise is intended to be compatible with the Concurrency TS extensions (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4123.html) where futures can have continuations scheduled against them via a future.then(callable). However, this involves an unavoidable memory allocation, which while fine for dynamically assigned continuations is overkill for statically assigned continuations. There is no reason why one could not also have a method of statically adding continuations which uses type extension to store the additions. Let us say we have a template<class T, class... Continuations> class promise and that this promise also provides a .then(callable) like this: template<class F> promise<T, Continuations..., F> then(F &&c) { return promise<T, Continuations..., F>(std::move(*this), std::forward<F>(c)); } ... and therefore to statically add continuations to the future promise, one simply iterates .then(callable) on the promise like this: auto p=promise<int>().then([]).then([]) ...; auto f=p.get_future(); p.set_value(5); // executes all the continuations My first question to the Boost community is this: is there some less ugly way? I'm thinking maybe the promise's constructor could take a set of continuations, and then a make_promise(callable, callable, ...) could construct a statically continued future-promise? My second question to the Boost community is this: should static continuations be able to see the value being set? Or indeed, to modify it before it gets sent to future.get()? My thanks in advance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 6

The master branch is now open for merging
by Marshall Clow 20 Oct '14

20 Oct '14

Please limit to changes that have been implemented in develop and whose tests have cycled. We will be closing the master branch again sometime next week (for the final release two weeks from today). The following problems were noted with the RC (and, I believe, have fixes ready): * Interprocess is broken for MinGW * Visual C++ 14 CTP 4 without BOOST_MSVC_ENABLE_2014_JUN_CTP * For MSVC14, TypeTraits 9de6a49 is missing in master * Thread fixes from Vicente Still needed to do: * Can someone take a look at http://lists.boost.org/Archives/boost/2014/10/217257.php, please? * MSVC 8.0 compilation failures * range/detail/any_iterator.hpp is broken because it expects postfix_increment_proxy and writable_postfix_increment_proxy to be in namespace boost::detail, but they are in boost::iterators::detail now. * There’s a few old Random fixes that need to be looked at. (and anything else we find) Thanks to everyone who tried out the RC, and please encourage people to try the beta! — Marshall

1 0

Re: [boost] [Boost-users] 1.57.0 beta 1 release candidates available for testing
by Marshall Clow 20 Oct '14

20 Oct '14

On Oct 20, 2014, at 7:06 AM, Marcel Raad <raad(a)teamviewer.com> wrote: > Marshall Clow <mclow.lists <at> gmail.com> writes: > >> Release candidate files for 1.57.0 beta 1 are available [...] >> 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. > > range/detail/any_iterator.hpp is broken because it expects > postfix_increment_proxy and writable_postfix_increment_proxy to be in > namespace boost::detail, but they are in boost::iterators::detail now. > > Those errors are also visible in all of the type_erased_* regression tests > of range. I made an executive decision to push the beta out with this problem (and the MSVC 8.0 bugs, too), because I wanted to get a wider audience looking at the beta. Thanks for reporting this, and now let’s fix them. — Marshall

1 0

[intrusive] More features for treap?
by Phil Endecott 20 Oct '14

20 Oct '14

Dear All, I've been looking at Boost.Intrusive's treap, and finding that it doesn't quite do what I need. Here's an example: say I have data about earthquakes in the form (date, magnitude, description). I can store that in a treap with date as the key and magnitude as the priority. Now I'd like to be able to do operations like: - Find the strongest earthquake between dates A and B. - Iterate over all the earthquakes with magnitude > X in date order. - For each year (or month, or decade etc) find the strongest quake. The first two are straightforward in a treap, but the current Boost.Intrusive API doesn't (AFAICT) let me do it. (The third one is less obvious.) I have been wondering how the API could most easily be extended to support this sort of thing, and I'm coming to the conclusion that it is probably best to expose the actual tree structure so that the algorithms for these operations can be implemented explicitly by the user code. I have had similar thoughts in the past about other trees i.e. augmented trees to implement interval trees; the choice is either (a) implement these things inside Boost.Intrusive; (b) don't use Boost.Intrusive at all; (c) extend the intrusive API to expose the actual tree structure. In cases like these extensions to treap, the new operations are simple compared to the complexities of inserting and erasing elements; being able to use the existing implementations of those operations while adding other (non-mutating?) features would save a lot of work. Any thoughts anyone? (Is anyone else using treap?) Regards, Phil.

2 3

[random] Any news?
by Marco Guazzone 20 Oct '14

20 Oct '14

Hello, Do you have any news on lib mainteners? I and other have pull requests But all seems muted.

4 4

Re: [boost] [Boost-users] 1.57.0 beta 1 release candidates available for testing
by Marshall Clow 20 Oct '14

20 Oct '14

On Oct 20, 2014, at 3:52 AM, John Maddock <boost.regex(a)virgin.net> wrote: >>> For Boost.Config: >>> >>> a mostly minor update. >> >> Great, thanks! According to the feature table, auto return types >> (BOOST_NO_CXX14_RETURN_TYPE_DEDUCTION) are also supported. > > Confirmed - it passes our test case anyway, feature enabled. > >>> For TypeTraits: >>> >>> I suspect you're not going to like the latter as it basically disables >>> working versions of is_nothrow* for msvc-14. The reason is that is >>> appears that Boost.Log ends up using noexcept(non_compiling_expression) >>> which requires SFINAE expression support. >> >> I also think it's the best solution. You can also delete >> the "!::boost::is_const<T>::value" with it now. > > Done. > > Marshall - is it OK to merge these fixes after the beta is out? Absolutely. — Marshall

1 0

1.57.0 beta 1 release candidates available for testing
by Marshall Clow 20 Oct '14

20 Oct '14

Release candidate files for 1.57.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_57_0_b1_rc1.7z) = 8633fbf5ebb7eaabcb0f309c14646ae3 MD5 (boost_1_57_0_b1_rc1.tar.bz2) = 8e76f98146793f0fbd2492a9151c405b MD5 (boost_1_57_0_b1_rc1.tar.gz) = d41ff3ffb36ac84ff5bf34f799308907 MD5 (boost_1_57_0_b1_rc1.zip) = 8a844dc36284247b2e936f2120e118b2 Thanks! -- The release managers

4 4

Re: [boost] [Boost-users] 1.57.0 beta 1 release candidates available for testing
by Marshall Clow 20 Oct '14

20 Oct '14

On Oct 19, 2014, at 2:22 PM, Vicente J. Botet Escriba <vicente.botet(a)wanadoo.fr> wrote: > Le 18/10/14 00:40, Marshall Clow a écrit : >> Release candidate files for 1.57.0 beta 1 are available at >> http://boost.cowic.de/rc/ >> >> > Hi, could I merge the following to the master branch? > > https://github.com/boostorg/thread/commit/3e28ea806c412c697f134fdaacbccc9b6… > https://github.com/boostorg/thread/commit/1029fa9c5937269c9a65848972da7d8bb… > https://github.com/boostorg/thread/commit/63dd439992cbc6d62f0af442f4669121e… > > > This fixes "deferred/ready futures on variadic when_all/when_any.” Vicente — I’d appreciate if you would merge those *after* we release the beta. There will be about a week where the master branch will be open again. — Marshall (who would like to get the beta out to a wide audience sooner, rather than later)

1 0

Performance characteristics of Boost mutex
by Philip Bennefall 18 Oct '14

18 Oct '14

Hi all, I am detecting some lock contention in my application, and while reading up on this I came across the concept of lightweight mutexes versus supposedly non-lightweight mutexes. I am wondering, can Boosts non-recursive mutex implementation be considered lightweight? In boost/detail I see lightweight_mutex. Should I be using that? I need no interprocess support here, and I want the lock to be as fast as possible. If I do decide to use lightweight_mutex, is it compatible with the regular non-recursive Boost mutex so that I can use it with higher level classes like lock guard, condition variables, barriers etc? Thanks in advance for any insight. Kind regards, Philip Bennefall

3 4

Re: [boost] [asio] RFC on new reliable UDP library
by Niall Douglas 17 Oct '14

17 Oct '14

On 17 Oct 2014 at 10:54, Juan Carlos Franzoy wrote: > > A long term dream of mine is for ASIO to become the standard event > > dispatch loop for all C++ programs, so other libraries simply hook > > into ASIO's dispatch and everything interoperates cleanly without > > lots of hassle and brittle boilerplate. I also feel a grievance > > against every single library firing up their own thread pools or > > worker threads when ASIO gives you that for free. > > We tried to use ASIO as an event dispatch, but it failed to scale in > multicore machines. Currently we are experimenting using one io_service > per core and manually managing the load balance migrating sockets between > io_services. If this is on Linux, then yes I have found this too. ASIO uses std::mutex as its lock, and the spin count on pthread_mutex in glibc is too short for modern CPUs. My proposed concurrent_unordered_map, which can do safe concurrent erase, would solve the need for ASIO needing a central mutex on Linux. > Maybe ASIO has to manage only io (only io threads) and has to delegate > to an external thread pool the execution of user handlers. Although I > don't know if it is technically possible. ASIO's present design is suboptimal in many regards. It's one of my biggest qualms in the present design being standardised as-is. I may, six months from now, be able to say in considerable detail what exactly to change if things pan out. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Ticketspam
by Daniel Frey 17 Oct '14

17 Oct '14

One more to remove: <https://svn.boost.org/trac/boost/ticket/10560> Thanks, Daniel

10 18

NT² eand Boost.SIMD release 3.1
by Joel FALCOU 17 Oct '14

17 Oct '14

NT2 is a Matlab inspired, high-level API for scientific computation in C++. Boost.SIMD is a candidate library for inclusion in Boost dealing with the portable encpsulation of SIMD instructions sets. This following releases updates NT2 and Boost.SIMD libraries to version 3.1 This new release of NT2 and Boost.SIMD focused on fixing performance issues and add some new support for architecture and parallel algorithms. The main new features include: - Linear Algebra functions can now use GPGPU through the MAGMA library whenever possible. - Reduction and Scan operations now works with more shared memory back-end - Altivec support is now complete for the VMX ISA We wish to thanks Ian Masliah for his work on MAGMA, Antoine Tran Tan for the shared memory support and Pierre Esterie participation to the Altivec ISA completion. Special thanks to Tim Blenchmann and khegeman for their help and patch submisisons throughout this development. The release Changelog is here : https://github.com/MetaScale/nt2/releases/tag/3.1.0 The files can be download from : http://nt2.metascale.org/downloads/ The Documentation (in progress) is here : http://nt2.metascale.org/doc/html/index.html **Next release announcment** This release is the last C++03 compliant version of both NT2 and Boost.SIMD. The next release - 4.0 - will be C++11 only. The new minimal version of supported compilers will be : - g++ 4.6 - Microsoft Visual Studio 12 (2013) - clang 3.4 - icc 12.1 The main reason for this change is to be able to properly fix the compile-time issue that one may experience. It'll also allow us to use some C++11 feature to simplify or streamline some of the user interface. * The NT2 Team

5 7

Is there something like shared_array<T> but with iterators?
by david.hagood＠gmail.com 15 Oct '14

15 Oct '14

I am doing signal processing, and in order to avoid data copies I need something that: 1) can adopt a buffer of data (e.g. take ownership of a T*) 2) Release that buffer via an appropriate method (e.g. take a deallocator object). 3) Provide operator[] over that buffer 4) provide shared ownership semantics So far, that's shared_array<> to a T [sic] However, I need one more thing: 5) provide iterator support (begin(), end(), cbegin(), cend()) The current shared_array<> doesn't provide that - is there anything else that does?

3 2

[interprocess] BOOST_INTERPROCESS_SHARED_DIR_PATH from env variable
by Jakub Szymanski 11 Oct '14

11 Oct '14

Hi, Will it be possible to have shared_dir not hardcoded? Currently it is determine by some tricks (some involve event log parsing on windows, which fails a lot). The only practical solution for us was to use BOOST_INTERPROCESS_SHARED_DIR_PATH define. boost/interprocess/detail/shared_dir_helpers.hpp inline void get_shared_dir(std::string &shared_dir) { #if defined(BOOST_INTERPROCESS_SHARED_DIR_PATH) shared_dir = BOOST_INTERPROCESS_SHARED_DIR_PATH; #else get_shared_dir_root(shared_dir); #if defined(BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME) shared_dir += "/"; get_bootstamp(shared_dir, true); #endif #endif } That has limitations tough as it makes it very difficult to test software in isolation (it requires access to the same folder). Similarly it makes is difficult to run program of machines with different file structure. Can it be configurable by some environment variable ? cheers --jakub

2 3

[Modularization] master and develop on super project.
by Kohei Takahashi 10 Oct '14

10 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Is there any policies for merging develop into master and sending pull-request on super project (boost.git)? Before 1.56.0 release, each libraries merged develop into master, though boost.git didn't. It caused to remain some defects in master (also release archive), which are already fixed in develop branch. e.g. - - https://svn.boost.org/trac/boost/ticket/5677 - -- https://svn.boost.org/trac/boost/ticket/6946 (dup of #5677) - - https://svn.boost.org/trac/boost/ticket/10507 and more tickets might exist... The wiki[1] describes about each libraries, but about super project is still absent. [1] https://svn.boost.org/trac/boost/wiki/StartModWorkflow Thanks, Kohei Takahashi -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUN8IGAAoJEGGyPxPRp/zoW3QP/RBWJ7dcmS8TEr7SpQW97QW4 17chTXKLkqHboHxCJuswXb1rlnmBxxooFItA5kFudEu7U1x5OekPfw+oroQP7v+C CgS5eHanitjprkijvJO2SS61a/YdF/1hMJuHUWzd62hI5ZXWQvNryeJtNl0K0hFb H9EhniJltvBxjOOdvjUsd9XCPby1afi5jOCUjC3J08X6WruRuI5BhCNElVQOSxMG yzaxuLeFDy8L9CICAU8RNEkBEjY1n5rYAVnbETX1WSSoDGEHblRUTOT7JQwSuWWx 0ymdz5cHisM+QoGuLUI0BQS9mayik3vAsre68Ve/xxTHU3LaRRVvaLJIH0YrRRwX fQmyJVGtIbUIhgfmdK8mq050wNOwdzefVfGDkq/XNo+wwlwA6vS4D5gqzfthNL6S HdXI8TIJtdRUYk66vFVcL5uf3PjoW4cZpWYceq1h1EOsIfXuzpr6uO0NDhqEFD+D I3vSmGPV1eAPYpQHP7jeOePMn1EPItU0sVqLk0f6ymafyqnaPU52zhcS45VMS85Q krk+ixO5bND6IU0EgYDn7QZHrTdACDcH5UGscBmxrSUwJ4DrgB6q8mAG/Ek0lZBK /UyXOu3k+ZtrYQIu5aayIyANp6p/EKGNgT7F7/4t0WZzxleskEPzKX9XKoPJnjQ9 aZrV3aXQSRrlEeBhU4fk =KrkS -----END PGP SIGNATURE-----

1 0

[config] Need some clang testing help...
by John Maddock 09 Oct '14

09 Oct '14

Folks there are persistent bug reports relating to clang with libstdc++ not correctly detecting the std lib feature set, see https://svn.boost.org/trac/boost/ticket/7473 for a lengthy discussion on the issue, and why it's been unsolvable. Anyhow, I've just committed a tentative patch in https://github.com/boostorg/config/commit/b36566fe04a89103b7ef5569c03e3a26e… and I'd be grateful if as many folks as possible can test this with their clang/linux/libstdc++/C++11 setups as they can. It works well for me locally, but that's only one possible clang configuration. BTW the easiest way to patch your Boost version is probably to download a replacement libstdcpp2.hpp from here: https://raw.githubusercontent.com/boostorg/config/b36566fe04a89103b7ef5569c… Many thanks in advance, John.

3 8

[range] How does remove_erase() work?
by Stephan T. Lavavej 08 Oct '14

08 Oct '14

Hi, I'm updating my Uniform Container Erasure proposal [1], and I was informed that Boost.Range has a similar-ish remove_erase(). I have a very simple question about its implementation, so I can describe it accurately in my revised proposal, but I don't really want to look at erase.hpp's guts. Does remove_erase() just use the erase-remove idiom, or does it contain special cases for the vector-like family, list-like family, and map-like family? (As N4009 explained, the erase-remove idiom is suboptimal for list, and won't compile for forward_list and the map-like family.) Thanks, STL [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4009.htm

3 4

It's that time again already - Boost 1.57.0 schedule
by Marshall Clow 08 Oct '14

08 Oct '14

It’s that time again. Here’s the schedule for the upcoming 1.57 release. If you’ve got changes that you’ve been putting off making, now’s the time to get busy. * 13-Oct Last day for significant changes * 20-Oct Beta build * 27-Oct Automatic merging turned off, build an RC * 3-Nov Release Boost 1.57.0 Questions? Ask them here. — The Boost release managers. P.S. We’ll be updating the calendar on boost.org/development soon.

5 5

Update on status of C++ 11 only Boost fork/modular distro
by Niall Douglas 08 Oct '14

08 Oct '14

Dear all, You may remember me saying these past six months that I was working on the tools necessary to fork Boost into a C++ 11 only distro which also lets you use Boost libraries individually standalone without the rest of Boost. I have got a first alpha version of my clang AST based local bindings generator working, and you can see it at https://github.com/ned14/local-bind-cpp-library. This tool lets you generate a set of local namespace bindings for some implementation of some library such that your library implementation code need not care what the underlying implementation of dependent library facilities is. This way your Boost library could be using either Boost or the C++ 11 STL and you don't need to care (most of the time). Now I have the first alpha version working and generating a reasonable set of C++ 11 STL bindings (https://github.com/ned14/local-bind-cpp-library/tree/master/include/s tl11), I'll start with porting over my own Boost libraries to it, so Spinlock, Expected, non-allocating future-promise and AFIO will be the first, and with those AFIO should become capable of being completely standalone from Boost whilst still also able to compile against Boost. After that I'll try porting the entire of Boost.Thread over such that Boost.Thread no longer needs Boost. I think that would be hugely useful for people wanting to use potential C++ 17 threading functionality without needing to draw in all of Boost as a dependency, and that might greatly widen the empirical experience new threading facilities might get before the 17 standard. Once I've succeeded with that, if the present situation with Boost has not improved by then, I'll press ahead with a new Boost distro website which score ranks Boost modules according to the scoring manifest I outlined on this list some months ago, and lets you download standalone Boost distros of your choice. Obviously only libraries ported to be standalone capable would be available, so I would hope that if I can demonstrate an easy port with Boost.Thread, others may follow with their libraries. All this work occurs in my free time of a few hours per week, so progress will be slow but steady. Comments on the local namespace binding tool are welcome. Comments on the proposed C++11/14 good practice idiom of binding dependent library APIs into the local namespace are also welcome, because as far as I can tell no one here has discussed a formal set of conventions to make best use of inline namespaces for new libraries. I'll put it another way - local namespace binds are a poor man's version of Herb's proposed C++ ABI facility. As much as they aren't quite as good, they are probably good enough (relative to Herb's most recent proposal). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 7

Fusion and constexpr, C++11 support entirely broken on develop
by Mathias Gaunard 07 Oct '14

07 Oct '14

Hi folks, I recently decided to move all of my code to C++11, and I usually use the develop version of each library so that I can have the latest developments and can easily contribute. However, Fusion appears to be fundamentally broken on develop whenever C++11 is enabled with GCC. It works fine with C++03. I don't think this is a situation that should ever happen; while develop is for libraries undergoing development, it shouldn't be totally broken either. In particular, the problem is that it uses BOOST_CONSTEXPR in contexts where C++11-constexpr is invalid, but where it is valid in C++14. Should there be a separate BOOST_CONSTEXPR14 macro?

3 3

[EXTERNAL] Tickets notifications
by Adam Wulkiewicz 07 Oct '14

07 Oct '14

Hi, AFAIU the notifications about new tickets and updates are sent only to the owner of the library. This is inconvenient since many libraries are developed by a group of people, e.g. Geometry. I'm aware that anyone can get updates if he's on the Cc list but people which are curious about development aren't added to this list automatically. Ideally it would be great if any user could subscribe to get notifications for any library like it's possible on GitHub. Or maybe moving to GitHub mentioned by John in one of the other threads would be the best solution? Anyway, is it somehow possible to receive notifications as a non-owner automatically? If the answer was no, would sending notifications to the library mailing list be a reasonable solution? AFAIU this could be done by adding a "fake" owner with a mailing list email. Regards, Adam

2 1

Submodules of Boost libraries
by Mathias Gaunard 07 Oct '14

07 Oct '14

Hi folks, I'd like to ready my library for inclusion into Boost. My library is made of several modules, and I'd like to keep that into Boost. How does Boost handles multiple submodules within a library submodule?

7 11