March 2015 - Boost - lists.preview.boost.org

Re: [boost] [Locale] Boost.Locale cannot Run in Visual Studio 2010
by Artyom Beilis 30 Mar '15

30 Mar '15

> >I have been trying to learn Boost.Locale Module. Consider this >http://www.boost.org/doc/libs/1_55_0/libs/locale/doc/html/conversions_8cpp-… >example. The code gets successfully compiled but when I try to run it, it >gives the error > >Unhandled exception at 0x74d34b32 in LearningCPP.exe: Microsoft C++ >exception: std::bad_cast at memory location 0x00a6fa48.. > >I have attached the stack-trace of the program also. Here it is: > > [snip] > > Did anyone faced this issue when using Boost.Locale in Visual Studio 2010? > If so, how do I resolve this issue? 1. Do you use latest version of MSVC or public beta (there was facet related bug there)2. Make sure you don't mix debug and release code (which can be very likely stuff there) on both boost and its dependencies (icu if you use one) Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

2 1

[GSOC] Request for proposal review and feedback
by Divyansh Gupta 30 Mar '15

30 Mar '15

Hi BOOST, I had submitted my proposal for the enhanced vector and deque project on 17th March, but I haven't received any comments yet. It would be great if I could get some feedback on the proposal, so that I can make any necessary changes while that's allowed. Thanks a lot. Regards, Divyansh Gupta PS- Here's the link to the proposal: https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015…

1 0

[thread] Alternate future implementation and future islands.
by Giovanni Piero Deretta 29 Mar '15

29 Mar '15

[cc'ing a few of the participants of the old thread] Hi All, Back in January, there was an interesting long thread about the problem of interoperation between futures of different libraries and the ability wait for heterogeneous futures. Different solutions were discussed like standardizing the future shared state or having an unified kernel wait object. I just wanted to share my attempt on a solution on the problem. The code can be found at https://github.com/gpderetta/libtask/blob/master/future.hpp (other interesting files are shared_future.hpp event.hpp and tests/future_test.cpp). It is an implementation a subset of the current boost and std future interface. In particular it has promise, future, shared_future, future::then, wait_any, wait_all. Most important missing piece are timed waits (for lack of, ahem, time, but should be easy to implement). The implementation requires c++14 and is only lightly tested, it should be treated as a proof of concept, not production-ready code. A few key design points: * The wait strategy is not part of the future implementation (although a default is provided). future::get, future::wait, wait_all and wait_any are parametrized by the wait strategy. * The design aims to streamline and make as fast as possible future and promise at the cost of a slower shared_future (although there is room for improvement). * The wait strategy only deals with 'event' objects, which act as a bridge between the future and the promise. The event object is really my the core of my contribution; it can be thought of as the essence of future<void>::then; alternatively it can be seen as a pure user space synchronization primitive. Other features of this implementation: * Other than in the blocking strategy itself, the future and promise implementation have no sources of blocking (no mutexes, not even spin locks). * The shared state is not reference counted. To demonstrate the generality of the waiting concept, I have implemented a few waiter objects. * cv_waiter: this is simply a waiter on top of an std::mutex + cond var. * futex_waiter (linux): an atomic counter + a futex, possibly more efficient than the cv_waiter * sem_waiter (posix): a waiter implemented on top of a posix semaphore. More portable than the futex waiter and possibly more efficient than the cv_waiter * fd_waiter(linux, possibly posix): a waiter implemented on top of linux eventfd (for portability it can also be implemented on top of a pipe); you can use select with futures! * task_waiter: a completely userspace based coroutine waiter which switches to another coroutine on wait and resumes the original coroutine on signal. * scheduler_waiter: another coroutine based waiter, but on top of an userspace task scheduler. On wait switch to the next ready task, on signal enqueue the waiting task to the back of the ready queue. I know that there is a plan to reimplement a new version of boost::threads, hopefully this implementation can contribute a few ideas. HTH, -- gpd

4 18

[vmd] Updated VMD library
by Edward Diener 28 Mar '15

28 Mar '15

I have updated the VMD library which has been accepted into Boost based on the reviews and comments of others. The macro interfaces have been simplified and redesigned for easier use and the documentation has been updated to provide more examples and samples of using VMD in code. The library is currently at https://github.com/eldiener/variadic_macro_data. The latest library code is now on the 'master' branch and the code that was reviewed is on the 'Version17' branch. The VMD library is a library of variadic macros which enhance the functionality in the Boost preprocessor library ( Boost PP ). The main focus of the library is the parsing/identifying of a subset of C++ preprocessor data types and of all Boost PP data types. This allows enhanced preprocessor metaprogramming based on the type of macro input. The library has been successfully tested on gcc 4.3.0 on up, VC++ 8 on up, clang 3.3 on up, and Intel 12.1 on up. The library has been tested on Windows and Linux. Comments, questions, bug reports are welcome.

1 0

sun toolset buggy and outdated?
by John Maddock 28 Mar '15

28 Mar '15

I'm trying to test the new Oracle-solaris compiler but I'm running into Boost.Build issues. First off what looks like a bug, if I build with with b2 stdlib=native Then I *still* get stlport You can easily reproduce this on another platform with: cd libs/config/test ../../../b2 config_info toolset=sun stdlib=native -n -d2 which yields: sun.compile.c++ ..\..\..\bin.v2\libs\config\test\config_info.test\sun\debug\stdlib-sun-stlport\config_info.obj "CC" +d -library=stlport4 -g -erroff=%none -KPIC -DBOOST_ALL_NO_LIB=1 -I"..\..\.." -c -o "..\..\..\bin.v2\libs\config\test\config_info.test\sun\debug\stdlib-sun-stlport\config_info.obj" "config_info.cpp" Now for the outdated part: the oracle compiler (12.4) now supports three std lib options: 1) The default - I can't make this work in C++03 mode, but it's the only option that does work in C++11 mode (where it appears to be a recent GNU libstdc++ version). 2) STLPort - only works in C++03 mode. 3) Apache - only works in C++03 mode. So ideally we would probably have: stdlib=stlport, sets -library=stlport4 for both compile and link. stdlib=apache, sets -library=stdcxx4 for both compile and link stdlib=native, sets -std=c++11 for both compile and link. And yes I realise we're mixing up two different features here, but as they can't be mixed and matched anyway it at least gets things working. I guess the toolset should be renamed either "oracle" or "solaris" as well? If anyone has any ideas how to patch the toolset, I have a working virtual machine to test on (or you can do as I did and download a pre-build VirtualBox machine). Thanks in advance, John.

5 13

[gsoc15] Please help rank GSoC 2015 student projects
by Niall Douglas 27 Mar '15

27 Mar '15

Dear Boost Community, The Google Summer of Code 2015 proposals for Boost are in, and we would deeply appreciate the community's help in ranking the proposals according to merit before the 6th of April. To vote, the process is easy: 1. Go to this page https://www.google-melange.com/gsoc/homepage/google/gsoc2015 and click the "Log in" button under Mentors and Administrators. 2. Now click "Create Profile" on the same page. Note that even if you registered last year, you must register again in 2015. Fill in the form. Note that after submitting it drops you at "Edit Profile", which is confusing. 3. Click "My Dashboard", then "Connect with organisations". 4. Choose "Boost C++ Libraries". 5. In the message box, write this: "I am a member of the Boost community and the email(s) I normally post to boost mailing lists with is <email>" filling in the email address(es) you normally use to post to boost mailing lists. This lets us verify that you are indeed a long standing member of the Boost community. 6. Once we approve your request, you will get an email with the subject "Welcome as organisation member". You can now return to the Dashboard on the GSoC website where there will be a new item "Proposals". 7. Work your way through as many of the 33 proposals as you can. You can score them using the stars at the bottom of each proposal page, taking care to read any comments by the mentors and students if present. PLEASE try to rank some of the lowest scored proposals, every year we get a lot of people who only rank the top five and don't bother with the rest. Try to score on the priority basis of: (i) ability to write quality C++, using the programming competency test or samples of programming the student supplied. (ii) proposal quality and your best estimate of the student's understanding of how best to solve the problem at hand. Bear in mind a gifted programmer with a strong work ethic but poor English may appear to not understand the problem as well as native English speakers, this is why we have asked for examples of their programming competency. (iii) if the student came early to the mailing lists to ask for help writing the proposal (the mentors who helped them with their proposals have usually indicated this in the private comments). (iv) usefulness/appropriateness of the feature or work being proposed. Remember a good GSoC is more about getting promising new engineers into Boost and C++ than necessarily getting code to pass Boost peer review in a single summer. 8. Optional: If a proposal looks especially great to you and you feel able to mentor a student this year, please slide the "wish to mentor" button. Just because a proposal already has willing mentors does NOT mean you should not add yourself - if you can substitute for an existing mentor, that may mean we use that mentor for another proposal. As you know, Google Summer of Code is usually worth $42,000 - $48,000 to Boost each year, and a successful GSoC raises our visibility and reputation in the wider open source community. Our thanks to you in advance for taking the time to vote. Niall Douglas Boris Schäling --- Boost C++ Libraries Google Summer of Code 2015 admin https://svn.boost.org/trac/boost/wiki/SoC2015

2 1

[SmartPointers] Determine interest in a new pointer wrapper class "flex_ptr"
by Jakob Riedle 27 Mar '15

27 Mar '15

Hello Boost Community, In the last few weeks, I heavily felt the lack of boost not having a more lightweight solution to a "not-necessarily-owning" pointer-wrapper than shared_ptr. shared_ptr is quite slow in the context that I need it to work. Furthermore it always is owning, even though ownership is shared in between instances. This is unhelpful, if you have an std::list of both non-owning and owning pointers. Hence, if you do not want to use shared_ptr all over your project, or especially want to interact with C, you need a not-necessarily-owning pointer-wrapper. This is why I collected some ideas on how to improve the situation. I came up with a little class named 'flex_ptr', that can hold both strong and weak references (therefore the name 'flexible', but it can also be 'the name of whatever proves itself to be good ...'). It keeps track of whether the held pointer is strong or weak. The Class doesn't need reference counting, since an Instance either is owning, or non-owning. Ownership is transferred between Instances using the default Move/Copy behavior. By Default the Constructor takes a pointer and treats it as a weak one. This is required, since this class aims on being used only at places, that are ought to be able to but not necessarily own objects. (Excuse me for the long sentence) A flex_ptr instance holding a strong pointer is created using a static non-member method named 'make_owning_flex', which accepts an rvalue pointer. As a result, it is not required to use the class at every single pointer occurrences in the project, but only at places, where the programmer wants to allow but not force strong references. The flex_ptr class is easily integrated into existing code using unique_ and shared_ptr's: One could think of - a constructor accepting a const lvalue reference unique_ptr, creating a (flex_ptr-instance holding a) weak reference, - a constructor accepting an rvalue unique_ptr, creating a strong pointer, that is owning an object it received from unique_ptr, - as well as a constructor taking a const lvalue reference shared_ptr, creating a weak pointer. Résumé: This pattern allows outright memory management, it uses less memory than shared_ptr (because no reference counting object required), therefore is faster, allows well-defined interactions similar to unique_ptr (especially at interaction with C) and thus fills a yet unclosed gap in the boost library as well as the Standard. Since this is (only) my personal opinion, I'd like to see how people feel about this 'gap' and think about this addition in the library (however the pattern may be implemented in the end). Regards, Jakob Riedle

6 10

GSoC 2015 Boost Compute Proposal
by Aditya Avinash Atluri 27 Mar '15

27 Mar '15

Hi, This is my proposal. Please suggest edits. Thank you!! :) *Personal Details:* Name: Aditya Atluri University: The George Washington University Major: Computer Engineering Degree: MS Email: adityaavinash1(a)gmail.com Homepage: adityaatluri.github.io Availability: 1. 7 days a week 2. 27 April to 28 August 3. Nothing. *Background Information:* *Educational Background:* I did my undergrad from Indian Institute of Technology, Dhanbad, India. Currently, I am pursuing my Masters at The George Washington University. The courses I have taken are, High Performance Computing, Advanced Computer Micro Architecture, Computer Graphics, Advanced Topics in Computer Graphics, VLSI Design, Low Power VLSI Design, Compiler, Machine Learning. I have did lots of projects in these courses which can be seen on my website and in my bio[1]. *Programming Background and Interests:* I am researcher, I program GPUs with IRs, writing work arounds and using a specific hardware for other applications (example, implementing ray tracing on rasterizer on GPUs, using tessellators for generating procedural textures). I wrote high productive parallel programming abstractions for GPUs[2]. I presented my work at GTC 2014. For this work, NVIDIA supported me with a couple of Tesla K40s. As CUDA, OpenGL, OpenCL, Metal, Thrust are C/C++ APIs I use C++ extensively. I also create databases on GPUs which is now in deep interest from NVIDIA, Google and MapD. I worked with Mesa, Open Source graphics drivers for Linux to build ARB_shader_atomic_counters for R600 backend. I also worked at IBM software labs, where I worked majorly on Java. *Why I opted Boost?* I use boost on daily basis as a part of PyCUDA. I write work arounds which involve some of boost libraries. The next thing I am interested in Boost is its Compute library. I have used other GPU STL style libraries but, none are as good as Compute (simple and elegant). I couldn't contribute to Compute via GSOC last year due to my CPT. I don't want to lose that chance again. This time, I want to take Boost.Compute to a whole new level. I like to program anything related to GPUs, compilers, drivers, APIs. *Interest in Boost.Compute:* As I have mentioned earlier, I am all-in for anything related to GPUs. Either graphics or compute libraries. I believe in Boost.Compute that it can be a widely used API, hence I want to make it more powerful and more useful. *Previous Work:* I work on graphics drivers on regular basis. I write loads of OpenGL compute and shader code (part of my TA job and Mesa testing on local systems). I am good at using APIs, making optimizations, less memory footage. For example, increasing the number of draw calls per second without stalling CPU, writing shaders with more ALU operations than Load/Store operations. Aligning data properly to memory width size, minimizing padding done by compilers by struct unrolling (to get exact multiple of word size). These are a few of the optimizations I do every day. I am currently working on running Metal Shading Language on Intel processors (using AVX).[3] *Plans beyond SoC*: I want to extend Compute to ARM and Qualcomm devices that support both OpenCL and ARM Neon. This brings all "compute-intense" APIs under one roof. C++ 98/03 - 03 C++ 98/14 - 03 C++ STL - 4 Boost C++ Libraries - (Knowledge: 2, Usage: 2) Git: 3 I program using Visual Studio and Xcode. Using Terminal on Linux. I am good with Doxygen. *Project Proposal:* Introduction: Boost Compute library is so far the best portable STL-like C++ library for accelerated computing leveraging the underlying parallel hardware. Boost Compute works well on OpenCL compatible desktop/notebook devices. In this project, we implement Boost Compute on mobile devices. Current mobile devices doesn’t provide good STL style abstractions that are accelerated by SIMD and OpenCL. With the introduction of Metal graphics API for iOS devices, development of compute application for non-iOS and iOS devices requires knowledge multiple skill sets. With this project, we bring all compute abstractions of different mobile devices under one roof that is, Boost.Compute. Project Goals: Make C++ extensions from Objective-C. Integrate device containers to Boost.Compute front end. Make Metal API data types visible to user through Boost.Compute. Implementing BOOST_COMPUTE_FUNCTION() to run custom kernels. Most important, implementing algorithms for Boost.Compute on iOS devices using Metal Shader Language. *Implementation:* Building Boost.Compute APIs for iOS devices. - Metal graphics APIs are used as backend to create Boost.Compute APIs in conjunction with Metal Shading Language Make C++ extensions from Objective-C. - Metal is Objective-C graphics API whereas Boost.Compute is C++ compute API. Hence a bridge between these two APIs should be made to use Compute on iOS devices. Hence, we build C++ extensions from Objective-C APIs. As C++ is also used in building iOS apps, writing Boost.Compute for iOS devices makes it easier to leverage compute performance from an iOS app. Build resource management Metal API backend for Boost.Compute - Here we develop infrastructure which make "algorithms" run on the hardware. Like, creating automated CommandQueues, CommandBuffers, Resources (buffers or textures) - As Metal APIs does not have ‘context’ related API, mapping can be done to Metal command buffer API. Some OpenCL APIs which are natively available (using in Boost.Compute) are not present in Metal API, appropriate mapping from Boost.Compute to Metal API commands will be found. Integrate device containers from Metal API to Boost.Compute front end. - Boost.Compute provide vector and array containers. These should be declared in Metal and integrated to Boost. Device containers include, device vectors, initializing vectors, moving vectors, similarly for arrays, etc., and their STL type functionality (.size(), .length()) - Implementing iterators for the containers should also be done. Make Metal API data types visible to user through Boost.Compute. - Mapping Metal data types to current Boost.Compute data types, while making them consistent with current Boost.Compute APIs. Certain new data types to Metal are being added which improve the performance and decrease memory footprint. Making these visible to the programmer and building building algorithms with them is done in this section. Implement algorithms for Boost.Compute in Metal Shading Language. - This makes the biggest challenge as Metal compute shaders support two modes of execution (fast and precise modes). Algorithms written in each mode should be iterated over to judge the best performance without losing precision for speed. Testing the existing Boost.Compute code on iOS devices and debugging for errors. - With Metal emulators not being available for Xcode, hardware testing will be done[4]. *Timeline:* The timeline is straight forward, for details check Implementation section. 27 April – 25 May: Community bonding, testing the Xcode and iOS infrastructure to find any possible build problems. Build a test run environment (iOS app) to check any other hardware/software issues in deploying Metal API code to iOS device. 25 May – 10 June: Wrap C++ Metal extensions with C++, submit patches. 10 June – 25 June: Implement data types and containers for Boost from C++ Metal APIs. Make appropriate changes to the code after getting feedback from community. Submit patches. 25 June – 3 July: Review community feedback and change patches accordingly. 3 July – 3 August: Write BUILD_COMPUTE_FUNCTION() and Boost.Compute algorithms on Metal Shading Language and integrate it to Boost.Compute Metal APIs. Submit patches. 3 August – 17 August: Write tests and debug by running them on iOS test app 17 August – 28 August: Cleaning up code and review with community. Available Hardware: iPhone 4s, 6Plus, Mac Mini. Mentor: Kyle Lutz (kyle.r.lutz(a)gmail.com) *Competency:* The project I started which creates the actual Metal API, is iaMetal (Metal for Intel processors)[3]. It does not uses Metal SL, it converts Metal SL to AVX extensions. [1]. https://github.com/adityaatluri/adityaatluri.github.co/blob/master/CV.md [2]. https://github.com/urutu/Urutu [3]. https://github.com/iaMetal/iaMetal [4]. https://devforums.apple.com/message/971605#971605 -- Regards, Aditya Avinash Atluri, Graduate Student, Electrical and Computer Engineering, The George Washington University, Washington, DC.

1 0

[asio][android][clang-x86] cannot locate symbol "___tls_get_addr"
by Dmitry Moskalchuk 27 Mar '15

27 Mar '15

As you can see at http://www.boost.org/development/tests/master/developer/asio.html, there are many fails on Android/x86, when tests are built by clang. There was ticket filed to CrystaX NDK tracker about that: https://tracker.crystax.net/issues/912. After some research, I've found reason of fails and created pull request for Boost.Asio: https://github.com/boostorg/asio/pull/17. Shortly speaking, there is intersection of several bugs - one is inability of clang to emulate thread-local variables without support from underlying runtime (gcc can do that), and second is misconfiguration in Boost.Asio headers. I've tested locally with change from https://github.com/boostorg/asio/pull/17 and all '___tls_get_addr' errors disappeared. Now I'm waiting for that pull request to be merged into upstream, but I don't see any activity in Boost.Asio repository. Is there something wrong with my pull request? It's very simple so I wonder why it not yet merged? I'd like to see it merged to the upstream (including 'master') before 1.58 release - just because this bug cause not only Boost.Asio fails, but several others libraries too. -- Dmitry Moskalchuk

2 3

[GSoC] Proposal for uBLAS
by Ganesh Prasad 27 Mar '15

27 Mar '15

Hello everybody, Here is the final draft of my proposal for GSoC'15 and I have made it public. https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015… The same text can be found on Gist at https://gist.github.com/GnsP/72dce0ac96394f54797c Reviews are requested and welcome. Best wishes Ganesh Prasad

1 0