- Boost - lists.preview.boost.org

Problems building Boost libraries for Windows Store when C++/CX is involved
by Mikael Olenfalk 04 Jan '16

04 Jan '16

Hi, I am working on porting the boost libraries we depend on to winrt, most porting is rather straightforward (basically switch from win32 apis which are 20 years old to apis which are 15 years old :D ). However I have hit a bit of a problem when compiling Boost.Log. Boost.Log depends on Boost.Asio which uses C++/CX to call some of the newer Store APIs (Windows::Networking and friends). When I build I get these errors: compile-c-c++ ..\..\..\bin.v2\libs\log\build\msvc-14.0\debug\log-api-winnt\threading-multi\windows-api-store\dump_ssse3.obj dump_ssse3.cpp ..\..\..\libs\log\src\dump_ssse3.cpp: fatal error C1107: could not find assembly 'platform.winmd': please specify the assembly search path using /AI or by setting the LIBPATH environment variable call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86 store >nul cl /Zm800 /ZW /EHsc -nologo @"..\..\..\bin.v2\libs\log\build\msvc-14.0\debug\log-api-winnt\threading-multi\windows-api-store\dump_ssse3.obj.rsp" (As you can see I have monkey-patched msvc.jam to append the "store" argument to vcvarsall.bat - to no avail :( -- the monkey-patch is here if you want to look at it: https://github.com/mauve/build/commits/universal-windows-boost-1.59.0 ) The @response file looks like this: "..\..\..\libs\log\src\dump_ssse3.cpp" -Fo"..\..\..\bin.v2\libs\log\build\msvc-14.0\debug\log-api-winnt\threading-multi\windows-api-store\dump_ssse3.obj" -TP /Z7 /Od /Ob0 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t /wd4675 /EHs /arch:SSE2 /bigobj /wd4003 /wd4456 /wd4459 /wd4503 -c -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_DLL -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_USE_DLL=1 -DDATE_TIME_INLINE -DWINAPI_FAMILY=WINAPI_FAMILY_APP -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_WIN32_WINNT=0x0603 "-I..\..\.." Regards, Mikael

4 10

Generic type inferencer function?
by Nat Goodspeed 04 Jan '16

04 Jan '16

Our code has any number of instances of this pattern: template <typename T, typename U> class SomeTemplate { SomeTemplate(const T& t, const U& u); ... }; template <typename T, typename U> SomeTemplate<T, U> make_SomeTemplate(const T& t, const U& u) { return SomeTemplate<T, U>(t, u); } Am I overlooking a generic boost::make<something>() of this general form? template <template<typename...> class CLASS_TEMPLATE, typename... ARGS> CLASS_TEMPLATE<ARGS...> make(ARGS && ... args) { return CLASS_TEMPLATE<ARGS...>(std::forward<ARGS>(args)...); } If that doesn't already exist... would it be useful to add (a less naive version) somewhere?

10 18

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

04 Jan '16

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

2 2

Potential contribution scenarios?
by Miguel Coimbra 04 Jan '16

04 Jan '16

Dear Community, This is my first post, apologies if I am breaking any rule with this. I've wanted to learn and improve my C++ skills for some time now. Learning more about Boost's usage and contributing to it has been on my mind. As a Ph.D student (Instituto Superior Técnico, Portugal), I became aware of Boost's participation in Google's Summer of Code and read up on some of Boost's past projects. Two ideas of GSoC2015 in particular caught my attention: - Concurrent Hash Tables - Mentor: Niall Douglas - Boost Document Library development - Mentor: Antony Polukhin I have been looking for direct contacts to learn about some of these ideas (Niall Douglas and Antony Polukhin, respectively) from 2015's Google Summer of Code to find out more, but was unsuccessful so far. While the first idea was not put into practice, the second one was undertaken (by Anurag Ghosh if I am not mistaken). Would anyone be able to point me in a direction to learn more about the state of work on these two ideas (specially the Document Library) and (if possible) if they are available for me to pick up and look into ways of contributing? Perhaps querying the mentors of those ideas for feedback? Thank you very much for your time, Kind regards, Miguel E. Coimbra

2 1

How to start Contributing !
by Yuvraj Singh 03 Jan '16

03 Jan '16

I am new to boost C++ libraries. I want to contribute to org and Participate in GSOC'2016 can someone please guide me through it. I have looked through the page https://svn.boost.org/trac/boost/wiki/SoC2016 . Can someone please help me about *C++ programming aptitude test *mentioned on the page. How and when it is organised and what type of questions are asked ?. *Thanks !*

2 1

Status of the CMake-ification
by Louis Dionne 02 Jan '16

02 Jan '16

Dear Boost, I'd like to inquire about the status of the CMake-ification of Boost that had been started a while ago. AFAICT, the effort is completely stopped now; is this correct? Also, I'd like to poll the community to gauge interest in the rebirth of such an effort. __I'm not proposing myself to work on such a rebirth__, but I'm just curious to know what the community thinks about it. I, for one, would love to see it happen. Regards, Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Status-of-the-CMake-ification-tp4681599.… Sent from the Boost - Dev mailing list archive at Nabble.com.

14 25

[winapi] [thread] Conflicting declarations on MinGW
by Antony Polukhin 01 Jan '16

01 Jan '16

Hi, Some of the Boost.DLL tests produce following warnings: ../boost/thread/win32/thread_primitives.hpp:175:83: warning: declaration of 'void* boost::detail::win32::GetModuleHandleA(const char*)' with C language linkage ../boost/detail/winapi/dll.hpp:47:1: warning: conflicts with previous declaration 'HINSTANCE__* GetModuleHandleA(boost::detail::winapi::LPCSTR_)' ../boost/thread/win32/thread_primitives.hpp:195:94: warning: declaration of 'int (__attribute__((__stdcall__)) * boost::detail::win32::GetProcAddress(void*, const char*))()' with C language linkage ../boost/detail/winapi/dll.hpp:82:1: warning: conflicts with previous declaration 'int (__attribute__((__stdcall__)) * GetProcAddress(boost::detail::winapi::HMODULE_, boost::detail::winapi::LPCSTR_))()' Andrey, Vicente what's the best way to resolve such issues? -- Best regards, Antony Polukhin

5 12

[qvm] deduce_xx traits wouldn't introduce ODR issues.
by Vicente J. Botet Escriba 31 Dec '15

31 Dec '15

Hi, I wonder if the deduce_xx traits wouldn't introduce ODR issues. Remember the TBoost.Conversion library where conversion between two types was customizable. The fact that deduce_xx traits have two types would promote ODR as there is no one type that is expected to do the customization. I believe that changing the default to something depending on the first argument will be better than using the specific qvm type as result. If this is not enough, you could add symbolic operations taken the result type as parameter, e.g. if a+b is not something specified by A, the user could use sum<C>(a,b) Forget my comment if there is no ODR issue. Best, Vicente

7 33

[dll] ready for master branch. Please merge
by Antony Polukhin 29 Dec '15

29 Dec '15

Hi, Boost.DLL is ready to appear in next release of Boost. Please, merge the DLL related changes into the master branch of boostorg/boost (changes for the develop branch were merged here: https://github.com/boostorg/boost/pull/94) Thanks! -- Best regards, Antony Polukhin

2 2

[qvm] Today is the last day of QVM formal review extended period
by Adam Wulkiewicz 23 Dec '15

23 Dec '15

Dear Boost Community! Today is the last day of the extended period of QVM library formal review. Since now we received 4 reviews. I encourage you to send more, there is still some time left. I'd like to thank all of you who have sent reviews as well as those who have taken part in the discussions. I'm going to wait for additional reviews a few days in case someone wanted to send one after the end of the review period. Does any of you plan to do it? Regards, Adam

1 0

Broken Link
by Mudit Sharma 23 Dec '15

23 Dec '15

All, The boost.python link provided on this page is broken: http://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html (See Boost.Python in section 3) Can anyone fix this? Thanks M

2 1

[autoindex] Default building with an Index
by Edward Diener 22 Dec '15

22 Dec '15

The documentation for VMD supports building with an index but I had not made this the default situation. This is my mistake. Can I assume the official build of the docs for a release supports building with an index via autoindex ? If so I will change the jamfile to support this as the default for the future and assume any end-user wishing to regenerate the docs has autoindex support also as part of the distribution as long as my jamfile is setup correctly for autoindex.

2 1

[doc] Releases 1.59 and 1.60 missing some tools documentation
by Edward Diener 22 Dec '15

22 Dec '15

In the 1.60 release, and I also just noticed in at least the 1.59 release also, the documentation links to the Release and Regression tools go to an invalid URL. Also while the documentation link to Boost.Build goes to a general explanation page the subsequent documentation link to Documentation goes to an invalid URL. Is this what we want, and that the end-user should have to "build" the documentation ? It seems doubtful, considering what a trial it often is for developers themselves to build the documentation given the tools available to do so. I think that this needs to be corrected in upcoming releases.

1 0

[regression] run.py merge option
by Antony Polukhin 22 Dec '15

22 Dec '15

Hi, How hard would it be to add a --merge option to run.py? Motivation: I'm experimenting with running all the regression tests on TravisCI https://github.com/apolukhin/boost_indirect_testing. Unfortunately, it has some hard limits, so a task can not work more than 2 hours. I've ended up splitting all the Boost tests by libraries and running tests on per library basis. Unfortunately, when the test results are send to server, only one library result is displayed in resulting matrix (search http://www.boost.org/development/tests/develop/developer/summary.html for indirect_travisci_tests) So I'd like to get a --merge option, that will allow merge of all the results by tester_name+revision. For example if results for 'geometry' and 'any' are sent with tester name `indirect_travisci_tests` and revision 74f85d, then show them in a single column. This may be also useful for those test runners that run tests on embedded or emulated devices (running all the Boost tests on emulated MIPS device may take a few weeks; running the tests on multiple emulated MIPS devices will speed up things) -- Best regards, Antony Polukhin

1 0

Software Freedom Conservancy Support
by Jon Kalb 22 Dec '15

22 Dec '15

This is not a technical message, but instead focuses on Boost Administration. Software Freedom Conservancy in a Financial Fight for its Life Software Freedom Conservancy, the non-profit home of Boost is facing an existential threat. Historically, Conservancy has been funded by corporate donations. This works great when it works, but a management shake-up, change in priorities, or a bad quarter at a large donor can derail the organization¹s programs. It has become obvious that Conservancy must move to a Supporter-driven funding model, where individuals who believe in Conservancy¹s mission of supporting open source projects, such as Boost, make a personal commitment to support that effort. Conservancy's fundraiser, found at https://sfconservancy.org/supporter/, is centered around asking individuals who care about the work that Conservancy does to donate $120/year, or just $10/month, to support the organization. Conservancy seeks about 2,500 Supporters to continue its current work, and 750 Supporters to continue a ³bare minimum² of services to its projects. What does this mean to Boost? Boost receives a myriad of important services (see https://sfconservancy.org/members/services/ ) from Conservancy. We¹ve relied on Conservancy since 2007 to provide them. Here are some of the things that Conservancy does for Boost that are in the ³bare minimum² category: * Dealing with all the financial and contractual details regarding our annual C++ Now conference. It was BoostCon that brought Boost and Conservancy together. C++Now 2016 will the the tenth annual BoostCon and it is a tribute to what we¹ve accomplished working together. * Handle our Google Summer of Code payments and travel, including handling all financial transactions with Google to receive and then disperse the money. * Coordinating travel reimbursements for Boost contributors (both developers and students) to attend conferences. * Receiving and tracking all donations to Boost. * Keeping the non-profit status for us so that we don't have to form our own org and file our own paperwork. As the Chair of the Boost Steering Committee, I cannot overstate how important this is to our existence as an organization. Here are some of the services Boost has received in the wider category: * Dealing with questions from the community (including license-governing bodies like OSI) about Boost's license. * Discussing the issue of copyright governance and contributions with large corporations who want their employees to contribute to Boost but need legal assurances or have questions relating to Boost's license or contribution policies. * Reviewing and handling licensing terms of third-party software that relate to Boost in some way, and giving us feedback and answers about issues related to it. * General legal consulting on issues that we run into as an open source non-profit. As you can see, Boost really relies on the important work of Conservancy. Support from Boost Boost, like all of Conservancy¹s projects, contributes 10% of our revenue to Conservancy¹s general fund. (The other 90% is maintained and administered by Conservancy at the direction of the Boost Steering Committee to advance the Boost project.) But that 10% of revenue from all Conservancy¹s member projects doesn¹t add up to enough to even employee one full time person, let alone the already overworked staff of three that Conservancy has. Donors must make up the difference. When Conservancy launched its fundraising effort, I sent out a request to past BoostCon/C++Now attendees asking for support and I¹m proud and delighted to say that a number of Boost community members have already stepped up. One told me that her company will be matching her support. Boost is one of Conservancy¹s oldest and largest projects, so it is right that Boost community members make up a fair proportion of its supporters. I encourage you to choose Conservancy as one of your charitable gifts this holiday season. (Conservancy is a 501(c)(3) charity incorporated in New York, and donations are typically deductible on U.S. taxes.) Please visit: https://sfconservancy.org/supporter/ If you are able to join the others from the Boost community that are making this gift, please let me know. I¹d like to personally thank you. Jon Kalb Chair, Boost Steering Committee

1 0

Becoming Maintainer of the Iterator Library
by Nathan Wilson 21 Dec '15

21 Dec '15

Hi all, There was talk on the mailing list a few months back, and was apparently discussed at CppCon in September, about becoming a Library Maintainer. This was pertaining to Libraries which are either being maintained by the CMT, or as Edward Diener mentioned, Libraries which aren't in the CMT's hands but the current maintainer(s) don't have time to devote to maintaining the particular library. That said, after having discussed it with a few people outside the mailing list, I would like to volunteer to become a Maintainer of Boost's Iterator Library. I have not been active on Boost's mailing list, but have participated in the C++ Standardization Process with the paper Delimited Iterators (http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4257.html) which will be in the Library Technical Specification 2. I have also submitted/committed some Patches in Clang as well. I just wanted to mention those couple of things as a point of reference so this didn't seem entirely random. Anyway, I'd be really excited to help contribute and help Boost by becoming a Maintainer of the Iterator Library. I do have some concern about compiling on various versions of Windows/OSX though. I have a Windows 8.1 machine and could obviously use Visual Studio, but I'm not too sure about verification of older Windows/OSX versions. On Linux I can certainly create VMs for various distros. If anyone has some best practices or advice about handling different OS distros/versions, that would be great. Please let me know if there are any questions. Thank you, Nathan

3 4

[smart_ptr] Moving cast for unique_ptr
by Karolin Varner 21 Dec '15

21 Dec '15

Hi all! There is the family of boost pointer cast (boost::static_pointer_cast, boost::dynamic_pointer_cast, ...) that allow a developer to write generic code by casting pointers regardless of whether they are some smart pointer (e.g. shared_ptr) or plain pointers. However, those functions have not been implemented for unique_ptr, because they create a copy of their pointer and unique_pointers can not be copied. In my case I still needed to cast some unique_ptr and since it's ok to move unique_ptrs I wrote a function that does exactly that. The code is below – Comments are very, very welcome. It works for my case, but I am sure it is not as generic and safe as it should be ;) . Specifically, for a library, it should be made to work on any kind of smart/plain pointer. Not just unique_ptr. Is there any interest to include a boost::static_moving_pointer_cast and the other types of casts in boost? Best, Karolin /// Dynamic cast a unique_ptr. /// /// This function shall move the pointer in in_ptr, into /// a new unique_pointer of the desire type, dynamic_casting /// it in the process. /// In given pointer shall contain a NULL pointer afterwards. /// /// If unsuccessful, function shall throw an error and leave /// in_ptr unmodified. /// /// This behaviour contrasts a bit with the behaviour of the /// normal dynamic_cast: /// 1. dynamic_cast copies objects, this moves them since /// unique_pointers can not be copied. /// 2. dynamic_cast returns a NULL pointer if the pointer to /// cast is of an incomplete type, this throws /// incomplete_cast instead, to ease error handling. /// /// @tparam T The type to convert to (as non-pointer) /// @tparam F The type to convert from (as non-pointer) /// @param in_ptr The unique_ptr to cast /// @return in_ptr, cast to the desired type template<typename T, typename F> std::unique_ptr<T> dynamic_moving_pointer_cast(std::unique_ptr<F> &in_ptr) { // Exception safety: If The dynamic cast throws an error, // or of we throw incomplete_cast, in_ptr will still be // unmodified T *plain_out_ptr = dynamic_cast<F*>(in_ptr.get()); if (plain_out_ptr == NULL && in_ptr.get() != NULL) throw incomplete_cast(); // Exception safety: Both operations are noexcept in_ptr.release(); return std::unique_ptr<T>(plain_out_ptr); }

6 11

safe::map
by Karen Pease 21 Dec '15

21 Dec '15

Hi everyone - I'm new to boost-devel, and am a bit intimidated ;) I recently finished a project and I don't know if the boost community would have any interest in it, whether it's really "boost material" or not: https://github.com/KarenRei/safe-map The page goes into more detail, but the short of it is: after searching and a long conversation on StackExchange, I discovered that while there are threadsafe ordered-map containers out there, the threadsafety was a bit weak. For example, if you have Thread A iterating across the map and Thread B thread just happens to delete an element as A is passing by, A's iterator becomes invalidated and the program crashes - even in a supposedly "threadsafe" map. For the type of multithreaded cache that I needed, I needed a structure that had the thread safety level of a filesystem - you know, where multiple processes can have file descriptors open at a time and one process might even potentially delete a file that another is accessing, without leading to a system crash. And that's basically what I implemented: safe::map, which not only ensures that basic operations on the container itself are threadsafe, but that everything you do with the iterators - even deleting elements out of the map that other iterators are pointing to - is also threadsafe. It does this by implementing reference counting on the elements in the map and flagging elements for deletion rather than deleting them immediately. A more detailed description of usage, performance, implementation, use cases, etc is on the project page. The project comes with a test suite which launches a number of threads that endlessly randomly tweak and iterate around the map with every function available to them. Does this sound like something that might be useful in boost (after whatever changes would be required)? If there's no interest, no harm done :) - kv, Karen

3 2

[Travis] All boostorg builds stalled?
by Louis Dionne 20 Dec '15

20 Dec '15

Hi, All of Hana's builds are currently stalled [1]. It has been like this for 2 or 3 days. I tried contacting Travis' support, but they are in vacation until January 4th. It also seems like the builds for Predef have been stalled for a while [2]. Perhaps other libraries are also touched. Strangely, builds for non-Boost repositories are not stalled, since I can build personal projects just fine. Does anyone know what might be happening? Louis [1]: https://travis-ci.org/boostorg/hana/builds [2]: https://travis-ci.org/boostorg/predef/builds/97532851

2 2

[gsoc]Seeking Guidance
by Ibrahim Dalal 20 Dec '15

20 Dec '15

Hi I am a sophomore, majoring in Computer Science. I am also a GSoC'16 aspirant. Its the first time I would be contributing to an open source project. Can someone please guide to a small project/patch suitable for a beginner? I have familiarity with C++ programming language along with basic understanding of C and Python. Also have some elementary knowledge of Git. Thanks

3 2

Boost 1.60.0 has been released
by Marshall Clow 18 Dec '15

18 Dec '15

Release 1.60.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 one new library and numerous enhancements and bug fixes for existing libraries. New Libraries * VMD: Variadic Macro Data library, from Edward Diener For details, including download links, see http://www.boost.org/users/news/version_1.60.0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.60.0/ Tom Kent has made pre-built windows binaries, and they are available at: https://sourceforge.net/projects/boost/files/boost-binaries/1.60.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

2 1

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

18 Dec '15

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

10 13

[QVM] Boost.QVM formal review is ongoing
by Adam Wulkiewicz 18 Dec '15

18 Dec '15

Dear Boost community, It seems that there are some problems with gmane.org related to handling of messages sent to many mailing lists at once. Therefore I'm reposting the information about the formal review. I appologize those of you who recieve this message for the second time. The formal review of Emil Dotchevski's QVM library begined on 7th Dec and it ends on 16th Dec. Boost QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size with the emphasis on 2, 3 and 4-dimensional operations needed in graphics, video games and simulation applications. While it provides its own quaternion, matrix and vector types, it is designed to work primarily with user-defined types through user specializations of the q_traits, v_traits and m_traits templates. QVM's source code is available on Github: https://github.com/zajo/boost-qvm Full documentation is also viewable on Github: http://zajo.github.io/boost-qvm/ We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? More information about the review process can be found here: http://www.boost.org/community/reviews.html We await your feedback! Best regards, Adam Wulkiewicz

4 6

[qvm] Formal review for QVM
by Adam Wulkiewicz 18 Dec '15

18 Dec '15

Dear Boost community, The formal review of Emil Dotchevski's QVM library begins on 7th Dec and ends on 16th Dec. Boost QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size with the emphasis on 2, 3 and 4-dimensional operations needed in graphics, video games and simulation applications. While it provides its own quaternion, matrix and vector types, it is designed to work primarily with user-defined types through user specializations of the q_traits, v_traits and m_traits templates. QVM's source code is available on Github: https://github.com/zajo/boost-qvm Full documentation is also viewable on Github: http://zajo.github.io/boost-qvm/ We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? More information about the review process can be found here: http://www.boost.org/community/reviews.html We await your feedback! Best regards, Adam Wulkiewicz

6 22

QVM Review
by Phil Endecott 17 Dec '15

17 Dec '15

Dear All, This is my review of Emil Dotchevski's QVM library. Thank you to Emil for offering this code. I believe that Boost and/or the standard library would benefit from vectors and matrices. Unfortunately I don't think that this proposal is what is needed, and I feel it should not be accepted. I have previously posted my thoughts about the terseness of the identifiers used and the use of operator,; I won't repeat the details here but in summary I find the syntax not to my taste, and not suitable for "public" code. Boost should aim to promote best practice, and I think this library falls short. Now, it's not unusual to find libraries that have interfaces that we don't like. Often we'll use them anyway because the features that the libraries provide outweigh the pain of using them. Does this apply in the case of QVM? Actually since first looking I've found that it does have more functionality than I thought - for example, I've only just found that it has functions to create matrices representing rotations (but not any other affine transformations) and to compute the inverse of a matrix (but not the determinant). But there's still not enough meat here for me to think it's worth using. If this were a comprehensive matrix algebra library, or a computational geometry library, or a SIMD library, then it might be worth putting up with the syntax. But it isn't, it's just a medium-size collection of operators and functions for quaternions, vectors and matrices that many projects will already having amongst their own local utilities. What it does offer is the ability to wrap existing matrix and vector classes and use a single unified syntax for all of them. It's just a shame that the single unified syntax is not the one I want to use! It is interesting to contrast QVM with Boost.Polygon and Boost. Geometry. The similarity is that both of these also wrap existing classes (for e.g. points) by traits class specialisations. When these were reviewed we discussed extensively how support for this compromised the friendliness of the syntax, i.e. the need to write get<0>(p) rather than p.x. What we ended up with there was I think the best that we could do, and it was probably worthwhile because of the substantial core functionality of each of those libraries. In my opinion, QVM doesn't reach that threshold. To address some of the "standard questions": I've not looked at the code, only the docs; I've spent a couple of hours this time and also looked when it was first proposed; and yes I do use vectors and matrices in my own code, for various graphics and cartographic purposes. Regards, Phil.

4 7

Re: [boost] [Boost-users] Boost 1.60.0 rc1 is now available
by Marshall Clow 17 Dec '15

17 Dec '15

Thanks to everyone for testing and reporting back the problems with the RC. I have pinged Vicente about the Boost.Thread problem, and Sebastian about the Boost.PropertyTree warning supression patches. Antony is looking into the Boost.LexicalCast issue. After surveying the other release managers, none of these issues is worth holding up the release for (which would probably stretch to after the new year). We're going to "go with what we have" for the 1.60.0 release, and get these problems fixed for 1.61.0 -- Marshall

1 0

Boost 1.58 linking error with Mongo 3.2
by Ameerkhan Mohamed 17 Dec '15

17 Dec '15

Hi, I am planning to use 3.2 mongo version. Hence i built client library of mongo 3.2 with pre-built boost library of 1.58. Both libraries are built under 64 bit configuration. Lib created successfully. When i integrate this libmongoclient-s.lib with my project i faced some linking error. Some of the sample error is :: Error LNK2001 unresolved external symbol "class boost::filesystem::file_status __cdecl boost::filesystem::detail::status(class boost::filesystem::path const &,class boost::system::error_code *)" (?status@detail@filesystem@boost @@YA?AVfile_status@23@AEBVpath@23@PEAVerror_code@system@3@@Z) StoreGrid_Head Error LNK2001 unresolved external symbol "class boost::system::error_code __cdecl boost::filesystem::detail::dir_itr_close(void * &)" (?dir_itr_close@detail @filesystem@boost@@YA?AVerror_code@system@3@AEAPEAX@Z) StoreGrid_Head Guide me on this issue please. Regards, Ameerkhan M -- Thanks and Regards Ameerkhan M Software Engineer Vembu Technologies

1 0

Re: [boost] [Boost-announce] Boost 1.60.0 rc1 is now available
by Jan Mikkelsen 17 Dec '15

17 Dec '15

Hi, (Resending to avoid bouncing on the lists.) I can build the libraries on FreeBSD 10.2 with clang 3.7 and gcc 5.2 in various modes. However, with both clang 3.7 and gcc 5.2 the following program fails to compile: #define BOOST_MOVE_USE_STANDARD_LIBRARY_MOVE #include <boost/thread.hpp> int main() { } This works fine with the same compilers and boost 1.59. The difference seems to be caused a change to boost/thread/detail/thread_group.hpp to use boost::csbl::unique_ptr<> instead of std::auto_ptr<>. Diff showing the change between 1.59 and 1.60 in thread_group.hpp and the compiler error messages below. Regards, Jan Mikkelsen $ diff -u thread/detail/thread_group.hpp ../../boost-1_60/boost/thread/detail/thread_group.hpp --- thread/detail/thread_group.hpp 2015-12-17 01:08:28.000000000 +1100 +++ ../../boost-1_60/boost/thread/detail/thread_group.hpp 2015-12-17 01:20:56.000000000 +1100 @@ -6,6 +6,7 @@ // (C) Copyright 2007-9 Anthony Williams #include <list> +#include <boost/thread/csbl/memory/unique_ptr.hpp> #include <boost/thread/shared_mutex.hpp> #include <boost/thread/mutex.hpp> #include <boost/thread/lock_guard.hpp> @@ -75,7 +76,7 @@ thread* create_thread(F threadfunc) { boost::lock_guard<shared_mutex> guard(m); - std::auto_ptr<thread> new_thread(new thread(threadfunc)); + boost::csbl::unique_ptr<thread> new_thread(new thread(threadfunc)); threads.push_back(new_thread.get()); return new_thread.release(); } $ g++5 -std=c++14 -isystem /usr/local/include/boost-1_60 twio/test_thread.cpp In file included from /usr/local/include/boost-1_60/boost/thread/csbl/memory/unique_ptr.hpp:16:0, from /usr/local/include/boost-1_60/boost/thread/detail/thread_group.hpp:9, from /usr/local/include/boost-1_60/boost/thread/thread.hpp:13, from /usr/local/include/boost-1_60/boost/thread.hpp:13, from twio/test_thread.cpp:2: /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp: In constructor 'boost::movelib::unique_ptr<T, D>::unique_ptr(boost::movelib::unique_ptr<T, D>&&)': /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:530:29: error: 'move_if_not_lvalue_reference' is not a member of 'boost' : m_data(u.release(), ::boost::move_if_not_lvalue_reference<D>(u.get_deleter())) ^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:530:68: error: expected primary-expression before '>' token : m_data(u.release(), ::boost::move_if_not_lvalue_reference<D>(u.get_deleter())) ^ In file included from /usr/local/include/boost-1_60/boost/thread/csbl/memory/unique_ptr.hpp:16:0, from /usr/local/include/boost-1_60/boost/thread/detail/thread_group.hpp:9, from /usr/local/include/boost-1_60/boost/thread/thread.hpp:13, from /usr/local/include/boost-1_60/boost/thread.hpp:13, from twio/test_thread.cpp:2: /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp: In constructor 'boost::movelib::unique_ptr<T, D>::unique_ptr(boost::movelib::unique_ptr<Y, D>&&, typename boost::move_upd::enable_up_moveconv_constr<T, D, U, E>::type*)': /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:552:29: error: 'move_if_not_lvalue_reference' is not a member of 'boost' : m_data(u.release(), ::boost::move_if_not_lvalue_reference<E>(u.get_deleter())) ^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:552:68: error: expected primary-expression before '>' token : m_data(u.release(), ::boost::move_if_not_lvalue_reference<E>(u.get_deleter())) ^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp: In member function 'boost::movelib::unique_ptr<T, D>& boost::movelib::unique_ptr<T, D>::operator=(boost::movelib::unique_ptr<T, D>&&)': /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:581:26: error: 'move_if_not_lvalue_reference' is not a member of 'boost' m_data.deleter() = ::boost::move_if_not_lvalue_reference<D>(u.get_deleter()); ^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:581:65: error: expected primary-expression before '>' token m_data.deleter() = ::boost::move_if_not_lvalue_reference<D>(u.get_deleter()); ^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp: In member function 'typename boost::move_upd::enable_up_moveconv_assign<T, D, U, E, boost::movelib::unique_ptr<T, D>&>::type boost::movelib::unique_ptr<T, D>::operator=(boost::movelib::unique_ptr<Y, D>&&)': /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:603:26: error: 'move_if_not_lvalue_reference' is not a member of 'boost' m_data.deleter() = ::boost::move_if_not_lvalue_reference<E>(u.get_deleter()); ^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:603:65: error: expected primary-expression before '>' token m_data.deleter() = ::boost::move_if_not_lvalue_reference<E>(u.get_deleter()); ^ $ clang++37 -std=c++14 -isystem /usr/local/include/boost-1_60 twio/test_thread.cpp In file included from twio/test_thread.cpp:2: In file included from /usr/local/include/boost-1_60/boost/thread.hpp:13: In file included from /usr/local/include/boost-1_60/boost/thread/thread.hpp:13: In file included from /usr/local/include/boost-1_60/boost/thread/detail/thread_group.hpp:9: In file included from /usr/local/include/boost-1_60/boost/thread/csbl/memory/unique_ptr.hpp:16: /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:530:67: error: 'D' does not refer to a value : m_data(u.release(), ::boost::move_if_not_lvalue_reference<D>(u.g... ^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:353:26: note: declared here template <class T, class D = default_delete<T> > ^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:530:38: error: no member named 'move_if_not_lvalue_reference' in namespace 'boost' : m_data(u.release(), ::boost::move_if_not_lvalue_reference<D>(u.g... ~~~~~~~~~^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:552:67: error: 'E' does not refer to a value : m_data(u.release(), ::boost::move_if_not_lvalue_reference<E>(u.g... ^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:548:29: note: declared here template <class U, class E> ^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:552:38: error: no member named 'move_if_not_lvalue_reference' in namespace 'boost' : m_data(u.release(), ::boost::move_if_not_lvalue_reference<E>(u.g... ~~~~~~~~~^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:581:64: error: 'D' does not refer to a value m_data.deleter() = ::boost::move_if_not_lvalue_reference<D>(u.get_... ^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:353:26: note: declared here template <class T, class D = default_delete<T> > ^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:581:35: error: no member named 'move_if_not_lvalue_reference' in namespace 'boost' m_data.deleter() = ::boost::move_if_not_lvalue_reference<D>(u.get_... ~~~~~~~~~^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:603:64: error: 'E' does not refer to a value m_data.deleter() = ::boost::move_if_not_lvalue_reference<E>(u.get_... ^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:597:29: note: declared here template <class U, class E> ^ /usr/local/include/boost-1_60/boost/move/unique_ptr.hpp:603:35: error: no member named 'move_if_not_lvalue_reference' in namespace 'boost' m_data.deleter() = ::boost::move_if_not_lvalue_reference<E>(u.get_... ~~~~~~~~~^ 8 errors generated. > On 15 Dec 2015, at 02:54, Marshall Clow <mclow.lists(a)gmail.com <mailto:mclow.lists@gmail.com>> wrote: > > Release candidate files for 1.60.0 are available at: http://boost.cowic.de/rc/ <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_60_0_rc1.7z) = 7ce7f5a4e396484da8da6b60d4ed7661 > MD5 (boost_1_60_0_rc1.tar.bz2) = 65a840e1a0b13a558ff19eeb2c4f0cbe > MD5 (boost_1_60_0_rc1.tar.gz) = 28f58b9a33469388302110562bdf6188 > MD5 (boost_1_60_0_rc1.zip) = 0cc5b9cf9ccdf26945b225c7338b4288 > > Thanks! > > -- The release managers > > P.S. Release notes are here: http://www.boost.org/users/history/version_1_60_0.html <http://www.boost.org/users/history/version_1_60_0.html> > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce <http://lists.boost.org/mailman/listinfo.cgi/boost-announce>

1 0

QVM formal review extension request
by Adam Wulkiewicz 16 Dec '15

16 Dec '15

Dear Boost Community! The number of reviews we received so far is too small to decide wether or not QVM should be a part of Boost. Therefore I request to extend the review period by a week to 23rd Dec. I'm aware that the time of year may be busy and that we're in the middle of Boost release. I hope that the extension would allow you to find time to write a short piece of review. -----The original announcement----- The formal review of Emil Dotchevski's QVM library is ongoing. Boost QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size with the emphasis on 2, 3 and 4-dimensional operations needed in graphics, video games and simulation applications. While it provides its own quaternion, matrix and vector types, it is designed to work primarily with user-defined types through user specializations of the q_traits, v_traits and m_traits templates. QVM's source code is available on Github: https://github.com/zajo/boost-qvm Full documentation is also viewable on Github: http://zajo.github.io/boost-qvm/ We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? More information about the review process can be found here: http://www.boost.org/community/reviews.html We await your feedback! Best regards, Adam Wulkiewicz

1 0

Boost 1.60.0 rc1 is now available
by Marshall Clow 15 Dec '15

15 Dec '15

Release candidate files for 1.60.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_60_0_rc1.7z) = 7ce7f5a4e396484da8da6b60d4ed7661 MD5 (boost_1_60_0_rc1.tar.bz2) = 65a840e1a0b13a558ff19eeb2c4f0cbe MD5 (boost_1_60_0_rc1.tar.gz) = 28f58b9a33469388302110562bdf6188 MD5 (boost_1_60_0_rc1.zip) = 0cc5b9cf9ccdf26945b225c7338b4288 Thanks! -- The release managers P.S. Release notes are here: http://www.boost.org/users/history/version_1_60_0.html

4 4

Boost 1.60.0 beta 1 Release Candidate 4 available for testing
by Marshall Clow 15 Dec '15

15 Dec '15

After far too long, release candidate files for 1.60.0 beta 4 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. Changes since rc3: * Boost.Test has been updated and now builds on Visual Studio Changes since rc1: * Boost.Sprit has been updated and Boost.Log now builds. * Boost.Math has been updated and now builds. Known issues (which will not be fixed for the beta): * Errors when building Boost.TypeErasure for older versions of Visual Studio. * Boost.Test fails when building on Darwin with gcc 4.9.2 The files (and associated md5s) are: MD5 (boost_1_60_0_b1_rc4.7z) = 63530c9594b24f56e5df79d910c9daeb MD5 (boost_1_60_0_b1_rc4.tar.bz2) = 29af12a1028536219a21517e953df4eb MD5 (boost_1_60_0_b1_rc4.tar.gz) = 74df7f5eb5e32f3a92b6141af3c6f541 MD5 (boost_1_60_0_b1_rc4.zip) = 90c25c34b64eb6cc88845ec5372938d7 Thanks! -- The release managers

8 16

Fwd: Re: [Boost-users] [boost-users][QVM] Boost.QVM formal review is ongoing
by Adam Wulkiewicz 15 Dec '15

15 Dec '15

It seems that you've send a response to the boost-users list and I'm guessing Emil is not a subscriber because he haven't responded. So I'm forwarding it to the developers mailing list. -----Original Message----- I'm not qualified to give a full review of this library beyond observing: 1 It looks very useful. 2 Boost prefers clarity to curtness. The naming is much too terse making the resulting code rather 'write-only'. I'd at least go for col_mat for col_m and transpose for transp etc. (I know any changes will be a big PITA but shows that asking sooner than later is a good idea for would-be Boost library authors ;-) 3 Documentation is OK, but I'd like many more examples of every function, and some much bigger fuller real-life examples showing use too. 4 Does this mesh at all with the quaternions in Boost.Math library? FWIW Paul PS If you build the Boost inspect tool \modular-boost\tools\inspect by running its jamfile, (and making sure that it is in your PATH) then from your /doc folder you can simply call > inspect > inspect.html and view any transgressions of the Boost rules in inspect.html - and, most important, any dud links. You may get a few false positives, but you can spot these easily. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830 _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

QVM formal review update
by Adam Wulkiewicz 15 Dec '15

15 Dec '15

Dear Boost Community! We're near the end of the QVM formal review period, it ends on 16th Dec. So far 11 people participated in discussions (not taking Emil nor me into account) and 2 reviews were sent. Do anyone of you need more time to ask questions, discuss, think, familiarize with QVM before sending a review? Are there people who would like to participate but haven't found enough free time so far? Basically I'm asking if anyone thinks that a review period should be extended? We appreciate your time and effort and of course kindly ask for sending reviews whenever you're ready. <TL;DR> -----The original announcement----- The formal review of Emil Dotchevski's QVM library is ongoing, it started on 7th Dec and it ends on 16th Dec. Boost QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size with the emphasis on 2, 3 and 4-dimensional operations needed in graphics, video games and simulation applications. While it provides its own quaternion, matrix and vector types, it is designed to work primarily with user-defined types through user specializations of the q_traits, v_traits and m_traits templates. QVM's source code is available on Github: https://github.com/zajo/boost-qvm Full documentation is also viewable on Github: http://zajo.github.io/boost-qvm/ We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? More information about the review process can be found here: http://www.boost.org/community/reviews.html We await your feedback! Best regards, Adam Wulkiewicz

1 0

safe integer library -- the scope
by Andrzej Krzemienski 14 Dec '15

14 Dec '15

Hi Robert, It is great to see this library getting into Boost. It fills an important gap, but it is only after a long while that I realized that, because the introductory part of the documentation does not stress it enough, and in fact it misled me a bit. My understanding is that safe<int> represents a high level abstraction of an integral number from mathematics: unlike raw type int, which represents a set of allowed operations on the underlying processor. You could say that raw type 'int' is only needed to efficiently implement higher level abstractions, like BigInt or safe<int> -- the two only differ in trade-offs between efficiency and the range of values they can represent. I was missing this in the introduction. Instead I got a somewhat negative impression that the goal of the library is to turn any UB into throwing exceptions (and thereby prevent any UB-based static analysis from detecting programmer errors). I would like to see the library in Boost, although I must admit the other parts do not sound that compelling as safe<int>. Regards, &rzej

6 27

Query About Boost Soc2016
by Arafat Khan 14 Dec '15

14 Dec '15

Respected Sir/Mam I am Arafat Dad Khan, I am a second year undergraduate student at Indian Institute of Technology Kharagpur. I wish to contribute to the Boost Library. I have decent *knowledge of Algorithms and Data Structures *and have consistently taken part in algorithmic competitions on websites such as Codechef and Spoj(Sphere online Judge ) You can view my profiles here http://www.spoj.com/SPOJ/users/adk/ and here https://www.codechef.com/users/adkcodeme I am *looking for potential mentors for Gsoc 2016* so that i start contributing by working on a small tasks first.I want develop requirements for my proposal by doing *initial background research on the topic*, and interact with the mentors and community to help identify expectations for projects . Regards Arafat Dad Khan Indian Institute of Technology Kharagpur

1 0

Reminder - Master branch closes for release on Sunday night
by Marshall Clow 11 Dec '15

11 Dec '15

I will be making the RC for the 1.60 release Monday morning. Changes that are not merged into master before then will NOT be in the 1.60 release. -- Marshall

1 0

[qvm] Terseness of syntax etc.
by Phil Endecott 11 Dec '15

11 Dec '15

Adam Wulkiewicz wrote: > The formal review of Emil Dotchevski's QVM library begins today > on 7th Dec and ends on 16th Dec. > Full documentation is also viewable on Github: > http://zajo.github.io/boost-qvm/ Following are some comments about the docs and syntax. This is based on an earlier look at the library when it was first announced and a quick look recently to see what has changed. I've not looked at the source code or tried to use the library. I wish that the docs started with a page showing how to use the library's built-in types. Currently, the first code that is presented shows how to define traits to make a user-supplied type work with the library. This is too advanced for the first page of the tutorial. The docs should start by showing how to do some high-school vector algebra using the built-in vector and matrix types. I find most of the identifiers too short. To give just a couple of examples: "transp" is used to mean "transpose". You save typing three letters, and get confusion with transparent, transport, etc. Then look at the names of some traits classes; elsewhere we have type_traits, allocator_traits, iterator_traits etc. all spelt out in full, but in qvm we have q_traits, v_traits and m_traits. I could go on but really almost every identifier is too short for my tastes. I had a quick think about how a struct with x,y,z members could be adapted. Am I right in thinking that it would be necessary to write accessors like this inside the traits specialisation: float ir(int i, xyz_vec const & v) { switch (i) { case 0: return v.x; case 1: return v.y; case 2: return v.z; } } ? If so, do we think that a compiler would successfully optimise that when it realised that x, y and z were in contiguous memory? (I guess you could also have an array of member pointers; would that work any better?) I'm really not a fan of the old operator% and now operator, syntax. To me, (v,XY) looks like you're forming a row-vector with two elements. Is there a reason why these accessors can't be written with function syntax, i.e. XY(v) ? Or, for matrices, something like element<4,2>(m) rather than (m,A<4,2>) ? I guess that what we'd really like to be able to do is to override operator. and write v.XY. There are proposals for adding operator. to the core language. Would those proposals support what is needed here? Actually, maybe this is closer to another proposal - the unified call syntax, which would make v.XY() equivalent to XY(v). I'll be interested to see what others think about these and other aspects of the proposal. Regards, Phil.

11 26

[QVM] Help with small example
by Rajaditya Mukherjee 10 Dec '15

10 Dec '15

I am trying to run boost::qvm on my machine. I am using MS Visual Studio 2013 with Boost 1.59 as the backend. #include <boost/qvm/all.hpp> #include <iostream> class float4 { public: float4(float a, float b, float c, float d) { container[0] = a; container[1] = b; container[2] = c; container[3] = d; } float container[4]; }; namespace boost { namespace qvm { template<> struct v_traits<float4> { static int const dim = 3; typedef float scalar_type; template <int I> static inline scalar_type &w(float4 & v) { return v.container[I]; } template <int I> static inline scalar_type r(float4 const & v) { return v.container[I]; } static inline scalar_type &iw(int i, float4 &v) { return v.container[i]; } static inline scalar_type ir(int i, float4 const & v) { return v.container[i]; } }; } } int main() { float4 vec(11.0,0.0,5.0,-6.0); std::cout << boost::qvm::mag(vec); (vec,boost::qvm::A<1>) = 112.0; std::cout << boost::qvm::mag(vec); } In the line *(vec,boost::qvm::A<1>) = 112.0, *I am getting an compiler error that says error C2563: mismatch in formal parameter list error C2568: ',' : unable to resolve function overload 1> d:\dropbox\programs\boost_qvm\include\boost\qvm\v_access.hpp(79): could be 'boost::qvm::vector_access_tag<I> boost::qvm::A(void)' 1> d:\dropbox\programs\boost_qvm\include\boost\qvm\m_access.hpp(78): or 'boost::qvm::matrix_access_tag<R,C> boost::qvm::A(void)' Any help ? Maybe I am doing something stupid ? Any help by Emil or anyone else is appreciated. *Rajaditya Mukherjee * *3rd Year Graduate Student* Dept. of Computer Science and Engineering The Ohio State University Columbus, Ohio Tel :- +1-(614)-271-4439 email :- rajaditya.mukherjee(a)gmail.com <mukherjee.62(a)osu.edu>, raj(a)rajaditya.com <mukherjr(a)cse.ohio-state.edu>

3 4

Master branch is open for merging
by Marshall Clow 10 Dec '15

10 Dec '15

Thanks to everyone for their patience; the master branch is now open for merging. Remember, we're coming up to a release, so please, no breaking changes. Thanks! -- Marshall

3 4

[Property_tree] error with ptree_serialization in 1.59
by David Bernstein 10 Dec '15

10 Dec '15

Hi Everyone, This is my first post here, hopefully I’m at the right place but if not please let me know where I should go. I have a C++ class which uses boost::property_tree and also includes <boost/property_tree/ptree_serialization.hpp>. This has been working nicely until I upgraded to V1.59 today and now I’m getting the compile error below. Any help with this would be greatly appreciated! Thanks, Dave /usr/local/include/boost/property_tree/ptree_serialization.hpp:66:24: error: no type named 'library_version_type' in namespace 'boost::archive' const bsa::library_version_type library_version( ~~~~~^ /usr/local/include/boost/property_tree/ptree_serialization.hpp:69:21: error: no member named 'library_version_type' in namespace 'boost::archive' if(bsa::library_version_type(3) < library_version){ I This e-mail is covered by the Electronic Communication Privacy Act, 18 U.S.C. Section 2510-2521 and may be legally privileged. If you have received this transmission in error, please notify the original sender immediately by return e-mail or by telephone at the telephone number provided above and delete/trash the original message from your system. Thank you for your assistance. The information contained herein is confidential information provided only for the use of the individual or entity for whom it was intended. If the reader of this message received it in error, is not the intended recipient, or if an attachment is made in error, the reader is hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.

1 1

Using BOOST_AUTO_TEST_CASE_TEMPLATE but passing a list of test values too
by Paul A. Bristow 10 Dec '15

10 Dec '15

I want to test a (quite large) variety of user-defined types using Boost.Test. As a very contrived example, suppose I wanted to check numeric_limits digits for integer types I'd like to avoid a tediously long list like this BOOST_CHECK_EQUAL(std::numeric_limits<char>::digits, 8); BOOST_CHECK_EQUAL(std::numeric_limits<char>::digits, 16); BOOST_CHECK_EQUAL(std::numeric_limits<char>::digits, 32); ... and follow the example of BOOST_AUTO_TEST_CASE_TEMPLATE but allow a test value to be passed too, something like this: typedef boost::mpl::list<char, int, long> test_types; and a list of test values, perhaps like this typedef list_c<int, 8, 32, 64> test_values; (However it would be *far* more useful to be able to test strings and floats and User-defined types too). BOOST_AUTO_TEST_CASE_TEMPLATE_????(digits_test, T, test_types, test_values) { BOOST_CHECK_EQUAL(std::numeric_limits<T>::digits, test_values); } Has any Macro Guru produced a BOOST_AUTO_TEST_CASE_TEMPLATE_? that includes a list of test values? Or other suggestions. Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

1 1

[qvn] Why doesn't QVM use [] or () to access vector and matrix elements?
by Vicente J. Botet Escriba 10 Dec '15

10 Dec '15

Hi, These operators could be used for views So instead of (m, <http://zajo.github.io/boost-qvm/operator_mod_rationale.html>A42) *= 42; we could have in C++11 ref(m)(4,2) *= 42; ref(m)[4][2) *= 42; In C++98 these could be less efficient than e.g. value<4,2>(m) *= 42; Best, Vicente

2 2

Segmented Tree Sequence documentation broken
by Vicente J. Botet Escriba 09 Dec '15

09 Dec '15

Hi, the link to Segmented Tree Sequence documentation in the review schedule and the Incubator is broken. https://det.github.io/segmented_tree_seq Vicente

2 2

[shared_ptr] Clang with Microsoft CodeGen in VS 2015 Update 1
by Beman Dawes 09 Dec '15

09 Dec '15

See http://blogs.msdn.com/b/vcblog/archive/2015/12/04/introducing-clang-with-mi… I tried building the Boost.Filesystem DLL with clang/c2 using the Visual Studio solution from libs/filesystem/test/msvc. As indicated the blog post, the following changes were needed in the project's properties: Configuration Properties General Platform Toolset : Clang 3.7 with Microsoft CodeGen (v140_clang_3_7) C/C++ General Warning Level : EnableAllWarnings (-Wall) Code Generation Enable C++ Exceptions: Yes (-fexceptions) Language Enable Run-Time Type Information: Yes (-frtti) Precompiled Headers Precompiled Header: Not using Precompiled Headers The operations.cpp compile failed with the following errors: 2> operations.cpp 2> In file included from ..\..\..\src\operations.cpp:44: 2> In file included from ../../../../..\boost/filesystem/operations.hpp:25: 2> In file included from ../../../../..\boost/filesystem/path.hpp:29: 2> In file included from ../../../../..\boost/shared_ptr.hpp:17: 2> In file included from ../../../../..\boost/smart_ptr/shared_ptr.hpp:28: 2> In file included from ../../../../..\boost/smart_ptr/detail/shared_count.hpp:29: 2> In file included from ../../../../..\boost/smart_ptr/detail/sp_counted_base.hpp:45: 2>../../../../..\boost/smart_ptr/detail/sp_counted_base_clang.hpp(29,1): error : cannot mangle this C11 atomic type yet 2> inline void atomic_increment( atomic_int_least32_t * pw ) 2> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2>../../../../..\boost/smart_ptr/detail/sp_counted_base_clang.hpp(34,1): error : cannot mangle this C11 atomic type yet 2> inline boost::int_least32_t atomic_decrement( atomic_int_least32_t * pw ) 2> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2>../../../../..\boost/smart_ptr/detail/sp_counted_base_clang.hpp(39,1): error : cannot mangle this C11 atomic type yet 2> inline boost::int_least32_t atomic_conditional_increment( atomic_int_least32_t * pw ) 2> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ So it looks like the clang/c2 toolset doesn't support atomics yet. The __c2__ and __c2_version__ macros allow detection of the clang/c2 toolset, could a workaround be added to shared_ptr? I know we don't usually worry about workarounds for preview (i.e. early beta) compiler releases, but the ability to add the clang/c2 toolset to local tests for library developers working on Windows will be a big plus IMO. --Beman PS: Has anyone figured out how to invoke clang/c2 from the command line?

3 6

boost::hash - different values for the same input?
by trafdev 09 Dec '15

09 Dec '15

Hi. As per hash_range docs (http://www.boost.org/doc/libs/1_59_0/doc/html/hash/reference.html#boost.has…) "This hash function is not intended for general use, and isn't guaranteed to be equal during separate runs of a program - so please don't use it for any persistent storage or communication." As per code (http://www.boost.org/doc/libs/1_59_0/boost/functional/hash/hash.hpp) it uses hash_combine_impl which doesn't use any random, process_id etc values which might change during new process launches. At the same time, in an example describing container usage in the shared memory (http://www.boost.org/doc/libs/1_59_0/doc/html/interprocess/allocators_conta…) boost::hash is being used: typedef boost::unordered_map < KeyType , MappedType , boost::hash<KeyType> ,std::equal_to<KeyType> , ShmemAllocator> MyHashMap; My question is: is it safe to use boost::hash in a shared (persistent) storage or it's safe only for a particular (non-pointer) types? In this case, boost::hash docs should be changed to mention this exceptions, because otherwise no one could use boost::hash in a shared memory containers.

1 0

Updated 1.60 release schedule
by Marshall Clow 09 Dec '15

09 Dec '15

Since we were late on the 1.60 release, we've updated the release schedule. The master branch is currently open for bugfixes and documentation changes ONLY. The master branch will close on Sunday night (Dec 12th). We will build an RC for the 1.60 release Monday, and if all goes well, release it on Thursday, December 17th. So get those bug fixes in before Sunday! -- Marshall

1 0

[qvm] Review announcement
by Phil Endecott 09 Dec '15

09 Dec '15

Adam Wulkiewicz wrote: > The formal review of Emil Dotchevski's QVM library begins > today on 7th Dec and ends on 16th Dec. Adam sent this announcement email to the boost@, boost-users@ and boost-announce(a)lists.boost.org lists. Which seems OK, except that as I have previously noted the gmane.org website seems to get confused by such messages; this announcement will have appeared on only the announce page at gmane.org and any followups that are sent to e.g. the boost@ list will not be displayed by gmane at all. You might argue that this is a gmane.org bug, and that is true, but on the other hand we do want everyone who might be interested to know about the review, and a quick look at email headers will show that many do use the gmane.org web interface to read these lists. I've previously suggested that whatever "how to be a review manager" documentation that exists should advise that announcements should be posted separately to each list. Perhaps no such documentation exists! (I'll post some comments about the actual proposal soon.) Regards, Phil.

2 1

[LOG] formatting_ostream API change
by Andrew Hundt 09 Dec '15

09 Dec '15

I had the following code, which worked in 1.58: #include <boost/log/trivial.hpp> #include <boost/exception/all.hpp> #include <boost/algorithm/string.hpp> /// @todo move elsewhere, because it will conflict with others' implementations of outputting vectors template<typename T> inline boost::log::formatting_ostream& operator<<(boost::log:: formatting_ostream& out, std::vector<T>& v) { out << "["; size_t last = v.size() - 1; for(size_t i = 0; i < v.size(); ++i) { out << v[i]; if (i != last) out << ", "; } out << "]"; return out; } I used it to output a std::vector<float> as follows: BOOST_LOG_TRIVIAL(trace) << “Real joint angles from FRI: " << realJointPosition << "\n"; However this now seems to fail in 1.59. I’ve created a github gist with the compiler output <https://gist.github.com/ahundt/5869dbd09e889b7153c3> in case that’s helpful as well. I see that the update recently had some breaking changes, what is the new way to provide the desired functionality? Thanks for your help. Cheers! Andrew Hundt

2 3

Boost release 1.60.0 beta 1 is now available from SourceForge
by Marshall Clow 08 Dec '15

08 Dec '15

Boost release 1.60.0 beta 1 is now available from SourceForge. See http://sourceforge.net/projects/boost/files/boost/1.60.0.beta.1/ For details of what's in the release, see http://www.boost.org/users/history/version_1_60_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. Known issues: * Errors when building Boost.TypeErasure for older versions of Visual Studio. * Boost.Test fails when building on Darwin with gcc 4.9.2 The files (and associated md5s) are: MD5 (boost_1_60_0_b1.7z) = 63530c9594b24f56e5df79d910c9daeb MD5 (boost_1_60_0_b1.tar.bz2) = 29af12a1028536219a21517e953df4eb MD5 (boost_1_60_0_b1.tar.gz) = 74df7f5eb5e32f3a92b6141af3c6f541 MD5 (boost_1_60_0_b1.zip) = 90c25c34b64eb6cc88845ec5372938d7 Thanks, -- The Boost Release Team

2 1

Checking for #pragma GCC diagnostic push|pop availability
by Marshall Clow 08 Dec '15

08 Dec '15

Shane Turner wrote: > I found another issue with a bad compiler version check in > boost/interprocess/detail/config_begin.hpp before using "#pragma GCC > diagnostic push", which, for GCC, is only available at version 4.6.0 and > later. Since I'm using GCC 4.4.7, my compile fails. It looks to me like interprocess is the one that really needs fixing. [ There could be a lot of cleanup here, but that's for another time ] I will make a PR. -- Marshall I have found (in non-test code) #if defined(__GNUC__) && (__GNUC__*10000 + __GNUC_MINOR__*100 + __GNUC_PATCHLEVEL__ > 40800) type_traits/has_logical_not.hpp #if BOOST_GCC >= 40700 tuple/detail/tuple_basic.hpp #Effectively >= 40600 smart_ptr/shared_ptr.hpp smart_ptr/scoped_ptr.hpp smart_ptr/detail/shared_count.hpp #if defined(BOOST_GCC) && BOOST_GCC >= 40600 random/detail/disable_warnings.hpp random/detail/enable_warnings.hpp #if defined(__clang__) move/detail/std_ns_begin.hpp move/detail/std_ns_end.hpp #elif defined(__GNUC__) && !(defined(__INTEL_COMPILER) || defined(__ICL) || defined(__ICC) || defined(__ECC)) \ && (__GNUC__ * 100 + __GNUC_MINOR__) >= 406 log/detail/header.hpp log/detail/footer.hpp #if defined(__clang__) || (defined(__GNUC__) && !(defined(__INTEL_COMPILER) || defined(__ICL) || defined(__ICC) || defined(__ECC)) && (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6))) lexical_cast/try_lexical_convert.hpp #if defined(BOOST_GCC) && (BOOST_GCC >= 40000) interprocess/detail/config_begin.hpp interprocess/detail/config_end.hpp #Effectively >= 40600 get_pointer.hpp

2 1

[boost-users][boost-announce][QVM] Formal review begins today
by Adam Wulkiewicz 07 Dec '15

07 Dec '15

Dear Boost community, The formal review of Emil Dotchevski's QVM library begins today on 7th Dec and ends on 16th Dec. Boost QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size with the emphasis on 2, 3 and 4-dimensional operations needed in graphics, video games and simulation applications. While it provides its own quaternion, matrix and vector types, it is designed to work primarily with user-defined types through user specializations of the q_traits, v_traits and m_traits templates. QVM's source code is available on Github: https://github.com/zajo/boost-qvm Full documentation is also viewable on Github: http://zajo.github.io/boost-qvm/ We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? More information about the review process can be found here: http://www.boost.org/community/reviews.html We await your feedback! Best regards, Adam Wulkiewicz

1 0

interest in an asynchronous linear algebra library?
by Oswin Krause 07 Dec '15

07 Dec '15

Hi list, Disclaimer: What I am proposing here does not exist (yet). But it will in the near future and if there is interest i would like to give something back to the boost community. I would like to propose a new library to boost: asynchronous blas. What is it and what can I do with it? It is a linear algebra library where all computations are carried out in an asynchronous manner on GPU and CPU. Computing a matrix-matrix product does not block the current thread but instead launches a task which at some point returns with a result, allowing the main thread to continue until the result is needed. GPU and CPU tasks can be started at the same time depending on each other (e.g. a CPU computation waits until the GPU returned some needed result and vice-versa) Why is this important? Which problems does it solve? Many linear algebra libraries are target towards either a) solving a few large linear algebra problems b) solving many small similar problems This library is targeted towards the middle ground: a medium amount of decently sized problems. Here the problem is that it is often hard to use all the computing resources available as a single problem will not exhaust the device resources and there is no easy way to launch several similar tasks in parallel. This problem occurs often in GPU computing where out-of-order execution of kernels is used to fill up the device. Similarly, it is often hard to make CPU and GPU work together as GPU tasks are asynchronous while CPU tasks are often synchronous and it is not straight forward to couple both without blocking either CPU or GPU. How does it work? Expression templates similar to boost::ublas are used to create a dependency graph: which object is used in which computations and which tasks have to wait to ensure a correct outcome? a simple case would be two independent computations like matrix A=prod(B,trans(B)); matrix C=prod(trans(B),B); a normal library like ublas would wait until A is computed before C is evaluated. Instead, it can be more efficient to just add the two tasks to a list and let worker threads execute them as soon as resources are available. First the computation of A is put into the graph and A is marked as "being written to" while B is marked as "being read". When C is added to the list, it does not depend on the first computation as several tasks can read from B at the same time. So another worker thread can grab the task and execute it. If we now add the task B += prod(D,prod(C,trans(D)); the library computes it as matrix temp = prod(C,trans(D); B += prod(D,temp). temp can be computed as soon as C is computed. But B can only be computed after A and temp are computed as we can only write to B after all previous tasks using B are finished. Are you qualified? I am main contributor to https://github.com/Shark-ML/Shark/ and as part of it I forked ublas https://github.com/Shark-ML/Shark/tree/master/include/shark/LinAlg/BLAS which now uses several linear algebra libraries as possible backends (ATLAS, openBLAS...). What is the timeline? I would start developing a minimal example ASAP based on the rewrite of ublas above. I would use a minimum set of features (only dense square matrices) and basic GPU support. Opinions? Best, Oswin

8 17

[asio] Any interest in a boost::asio::mockup_serial_port ?
by Damien Buhl 07 Dec '15

07 Dec '15

Dear Boost.Asio developers, I wanted to know if there was any interest for a mockup_serial_port_service, so that one might write cross platform unit-tests of code based on serial_port. I implemented this mockup this summer for a project where the best way to unit test some modules was to act as another peer on a serial port and needed to be doable on any platform supported by asio::serial_port. I find it quite useful, because there - is no need to use separate tools like socat on linux or install virtual COM ports applications on windows. Which ease the setup of the test environment - the fake serial port doesn't pollute the system where the test is run - many test cases can be run in parallel, as there is no native ressources involved. One might use it as this : > using namespace boost::asio; > > boost::thread simulate_writing_device([](){ > io_service ios; > basic_serial_port<mockup_serial_port_service> port{ios, "my_fake_serial_port"}; > > const std::string message = "Hello"; > > for (;;) { > boost::asio::write(port, buffer(message.data(), message.size())); > boost::this_thread::sleep_for(boost::chrono::seconds(1)); > } > > }); > > boost::thread simulate_reading_device([](){ > io_service ios; > basic_serial_port<mockup_serial_port_service> port{ios, "my_fake_serial_port"}; > > for (;;) { > char message[5]; > boost::asio::read(port, buffer(message, 5)); > std::cout << "received : " << std::string(message, 5) << std::endl; > } > > }); A short documentation is available here : http://goo.gl/24JnUg And the implementation is on github in a holdall library for the moment : https://goo.gl/E7KGdn It's a library whose goal is to shrink over the time as they get merged in upstreams project. Hopefully there is interest for this mockup_serial_port, and if so I'll cleanup the code some more and make a pull-request to Boost.Asio. Cheers from Berlin where meetingcpp already ended :'-( -- Damien Buhl

2 2

[fiber] ready for next review
by Oliver Kowalke 06 Dec '15

06 Dec '15

As request, I'd like to announce that boost.fiber has addressed the requests of the last review. Especially migrating fibers between threads is supported - sub-directory 'examples' contains code demonstrating work-sharing and work-stealing. boost.fiber: github.com/olk/boost-fiber/tree/develop (branch develop) requires boost.context (branch develop) Oliver

2 22

Boost 1.60.0 beta 1 Release Candidate 2 available for testing
by Marshall Clow 04 Dec '15

04 Dec '15

Release candidate files for 1.60.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. Changes since rc1: * Boost.Sprit has been updated and Boost.Log now builds. * Boost.Math has been updated and now builds. Known issues: * Errors when building libraries for visual studio: test and type_erasure. * Boost.Test fails when building on Darwin with gcc 4.9.2 The files (and associated md5s) are: MD5 (boost_1_60_0_b1_rc2.7z) = dd38daa9378a6002fc12da0cab695511 MD5 (boost_1_60_0_b1_rc2.tar.bz2) = f3c9ffc14db3b2e55c7c5c703e69883d MD5 (boost_1_60_0_b1_rc2.tar.gz) = 89365262443cc16990b69f8e4b8b47ab MD5 (boost_1_60_0_b1_rc2.zip) = 3389bd4595a989fe95966440cbe45ca9 Thanks! -- The release managers

7 12

thread_specific crashes the application when it is in a .so file
by George Georgiev 03 Dec '15

03 Dec '15

Hi, Is there a known issue about boost::thread_specific when a global thread_specific object is in a .so file? The exact same code replacing it with thread_local boost::unique_ptr<Foo> works. By the way is there a macro that determines is thread_local supported from the compiler or not? Thanks, George

3 3

Documentation for boostbook
by Soul Studios 02 Dec '15

02 Dec '15

I've seen the existing documentation, and wasn't impressed- is there a better site for details on this? Something with at minimum, a copy of the DTD and an example .xml file? Thanks, Matt

1 0

compilation errors with ublas / cppad
by Peter Caspers 30 Nov '15

30 Nov '15

Hi, I think this has been asked before, but since I am not aware of any answer, I would like to bring up the topic again: When using CppAD::AD<double> with boost ublas, certain compilation errors show up. I attach a small example (ublas_cppad.cpp) and the (start of the) error messages I get (compilation_errors.txt, produced with boost 1.59.0, g++ 4.9.3, CppAD-20151124). The problem is in matrix_assign.hpp; when changing template<class E1, class E2, class S> BOOST_UBLAS_INLINE bool equals (const matrix_expression<E1> &e1, const matrix_expression<E2> &e2, S epsilon, S min_norm) { return norm_inf (e1 - e2) < epsilon * std::max<S> (std::max<S> (norm_inf (e1), norm_inf (e2)), min_norm); } to template<class E1, class E2, class S> BOOST_UBLAS_INLINE bool equals (const matrix_expression<E1> &e1, const matrix_expression<E2> &e2, S epsilon, S min_norm) { S tmp = norm_inf (e1 - e2); return tmp < epsilon * std::max<S> (std::max<S> (norm_inf (e1), norm_inf (e2)), min_norm); } the example code compiles without errors. Can someone point out, how this should be fixed (either on boost or CppAD side)? In general, are there requirements for a type T to cooperate with ublas matrices one should be aware of? Thank you Peter

2 3

Is master branch open for bug fixes?
by Vicente J. Botet Escriba 30 Nov '15

30 Nov '15

Hi, the calendar says that master branch is open for bug fixes, but not mail has been sent to to notify it. Could some release manager confirm that? Best, Vicente

2 2

[program_options] empty string argument
by Benedek Thaler 30 Nov '15

30 Nov '15

Hi, I have the exact same problem: http://boost.2283326.n4.nabble.com/ProgramOptions-explicit-empty-string-arg… --compression '' gave me a specified, empty compression switch value, as expected, on boost 1.58. However, on 1.59, the empty string counts against the positional arguments, and causes regressions. Also, --compression='' gives: The argument for option '--compression' should follow immediately after the equal sign. What is the recommended workaround? Is it planned to be fixed/changed? Thanks, Benedek

1 0

[Boost.LLVM] Synopsis now available
by Andy Jost 29 Nov '15

29 Nov '15

I've created a new GitHub repository for this project and uploaded a synopsis of the proposed interface. I redesigned the interface, so it differs slightly from the prototype code and examples I gave before. Please take a look and provide feedback if you can! https://github.com/andyjost/Boost.LLVM/blob/master/boost_llvm.cpp -Andy

1 0

Interest in an LLVM library?
by Andy Jost 26 Nov '15

26 Nov '15

Is there interest in an LLVM library? My motivation is to simplify the dynamic creation of functions, modules, and programs by defining an EDSL modeled after the C language. LLVM provides an API based exclusively on function calls that is verbose and difficult to use. The EDSL is more expressive and easier to use. (This may remind some people of Boost.Python and indeed these libraries are similar in motivation.) The scope of this proposal is limited. The proposed library does not compile, link, optimize, save, or load anything, for example, since the LLVM API is suitable for that. Also, it may not support obscure features, even if they seem to be within its purview, since one can always make direct calls to the LLVM API. I have written about 6500 lines of prototype code in the context of another project (a compiler for the language Curry, if anyone is interested). It is not a complete solution, but is by no means trivial, either. I'll discuss that next, but since the discussion is somewhat lengthy, let me first explain what I'm looking for by sending this. I think this EDSL would make a good Boost library. If others agree, then the next step is to review the design. I need second opinions and help from more knowledgeable people to improve the design. There are a few places in particular where I think a redesign is necessary. After that, I'm happy to implement the final library (and would gladly accept help, if anyone is interested). Now, I'll show a few examples and provide links to the prototype code. First, here's how to create a module and put it in scope: module const example_module("example"); scope _ = example_module; The scope object sets the insertion point for types, functions, and global variables. We can create a type as follows: type i32 = int_(32); i32 is a 32-bit integer. It is easy to build more complex types, e.g., i32[2] is an array type, *i32 is a pointer type, and i32(i32,i32) is a function type. An expression like i32(42) produces a constexpr. As you might guess at this point, the prototype makes heavy use of SFINAE. I've gone to a lot of effort to make this work with everything I can think of, particularly multi-dimensional arrays and initializer_lists. So, an expression like (i32[3][2])({{1,2,3},{4,5,6}}) works! (Note: i32[3][2] is the C++ type int32_t[2][3] because that's the only sensible way to interpret successive calls to operator[]). We can create a struct from a sequence of types like this: type foo = struct_("foo", {i32, *i32}); Or, we can leave out the sequence to get an opaque struct. A function prototype can be created as follows: function const f = extern_(i32(i32), "f", {"i"}); This function, f, takes an i32 (named "i") and returns an i32. The function is placed in example_module, since the code appears in its scope. There are two other linkage-specifying functions: static_ and inline_. extern_ and static_ are also used to create global variables (i.e., if the type is not a function). To define the body, we create another scope: { scope _ = f; // code for f. } To understand this, we have to discuss scopes in more depth. There are three nested levels of scope: the current module, the current function, and the current basic block. The code above sets the current function to f and the current basic block to f's entry point. Generally speaking, within a function body we write statements that generate instructions. Those instructions are inserted into the current function at the end of the current basic block. To define the body, we can declare values and operate on them. For example: value i = arg("i"); Here, "arg" is a special function that fetches the named function parameter. We can add instructions to f using operators or special methods. For example: value j = i + 1; return_(j); Branches manipulate the current basic block. Here's an if statement: label true_path, false_path; if_(i, true_path, false_path); { scope _ = true_path; // code for true. } /* else */ { scope _ = false_path; // code for false. } // new basic block here. This generates instructions to test i, take the appropriate branch, and then continue to a new basic block in the right places (which depends on whether the paths terminate with a branch instruction). It also updates the scope so that statements following if_() are inserted into the new basic block. Believe me when I say it is not trivial to do this with the LLVM API. Although it is sometimes necessary to pre-declare labels as shown above, we can usually employ C++11 lambdas to simplify the encoding: if_(i , []{ /* code for true */} , []{ /* code for false */ } ); The prototype code can be found under https://github.com/andyjost/Sprite-3/tree/master/include/sprite/backend. Also, there are many examples under https://github.com/andyjost/Sprite-3/tree/master/examples. Other parts of the Sprite-3 project are unrelated to this proposal. A good example to start with generates the Fibonacci numbers (https://github.com/andyjost/Sprite-3/blob/master/examples/fib.cpp) Here's the interesting part: // Create a new module and associate it with this lexical scope. module const fib_module("fib"); scope _ = fib_module; // Declare types. auto const char_ = types::char_(); auto const i32 = types::int_(32); auto const i64 = types::int_(64); // Declare external functions. auto const printf = extern_(i32(*char_, dots), "printf"); // Define the @fib function. auto const fib = extern_(i64(i64), "fib", {"n"}); { scope _ = fib; value n = arg("n"); if_(n <(signed_) (2), []{return_(1);}); return_(fib(n-2) + fib(n-1)); } // Define the @main function. auto const main = extern_(i32(), "main"); { scope _ = main; value const x = fib(5); printf("fib(5)=%d\n", x); return_(0); } After this code runs, fib_module contains an intermediate representation of the program. The LLVM API can be used to save that to disk, compile it to assembly, link in the C library (to get printf), or JIT compile any of the functions, among other things. Thanks to everyone who made it this far :) I'm looking forward to your feedback. -Andy

9 21

[trippels-ppc64le][math] Missing quadmath.h errors
by Andrey Semashev 24 Nov '15

24 Nov '15

Hi, I'm seeing some test failures on the trippels-powerpc64le-gcc-6.0 tester that amount to Boost.Math failing to build because the quadmath.h header is missing. http://www.boost.org/development/tests/develop/developer/output/trippels-po… I understand that gcc 6.0 is an unreleased compiler, but the error is probably not a consequence of a compiler bug. Besides, another tester, Flast-FreeBSD10-gcc-6.0.0~gnu++11, passes. Is it possible that the header is not provided for powerpc64le? Or is an optional dependency whose presence is misdetected? Is this a known problem?

3 5

[teeks99][test] Test failures on MSVC 8-11
by Andrey Semashev 23 Nov '15

23 Nov '15

Hi, I'm seeing massive Boost.Log test failures on teeks99 with MSVC versions 8 through 11. The links to the failure messages lead to Boost.Test but the console output is not helpful (shows a successful compilation of a source file [1]). I can see Boost.Test tests are also failing massively on these compilers. Could this be fixed? [1]: http://www.boost.org/development/tests/develop/developer/output/ teeks99-08d-win2012R2-64on64-boost-bin-v2-libs-log-test-attr_attribute_set- test-msvc-11-0-dbg-adrs-mdl-64-thrd-mlt.html

6 18

[Config] boost::uint32_t != std::uint32_t on some targets
by Louis Dionne 23 Nov '15

23 Nov '15

Dear Boost, I recently fell into a trap where a program wouldn't compile because of a difference between `boost::uint32_t` and `std::uint32_t`. Specifically, I was trying to cross-compile from OS X to ARM, and the following program wouldn't compile #include <boost/cstdint.hpp> #include <cstdint> #include <type_traits> static_assert(std::is_same<std::uint32_t, boost::uint32_t>::value, ""); int main() { } I was building with arm-none-eabi-g++ -I /path/to/boost -std=c++11 -c main.cpp I have asked a question on StackOverflow [1], and I now understand why the two types are not required to be the same. However, I think it is a QOI issue that those two types are not the same, since it makes interoperating between `std::uint32_t` and `boost::uin32_t` more difficult. Is there a reason for this difference, and if not would it be reasonable to ensure that `boost::uint32_t == std::uint32_t` whenever the latter is defined, i.e. in C++11 and above? Regards, Louis [1]: http://stackoverflow.com/q/33857554/627587

3 2

build and install boost subset does not install the header files
by George Georgiev 22 Nov '15

22 Nov '15

Hi, I am trying to use github boost to obtain a subset of the libraries. I found that using the following subset of modules allows me to build boost_system. git submodule update --init tools/build || exit 1 git submodule update --init tools/inspect || exit 1 git submodule update --init libs/assert || exit 1 git submodule update --init libs/config || exit 1 git submodule update --init libs/core || exit 1 git submodule update --init libs/predef || exit 1 git submodule update --init libs/system || exit 1 git submodule update --init libs/utility || exit 1 The problem is that ./b2 ... install does not copy the header files. Is this a bug that I am hitting? My commands are: ./bootstrap.sh --prefix=../../boost --includedir=../../boost/include || exit 1 PATH=$CLANGBIN:$PATH \ ./b2 \ toolset=clang \ cxxflags="-std=c++11 -stdlib=libc++ -isystem/Developer/SDKs/MacOSX10.7.sdk/usr/include" \ linkflags="-stdlib=libc++" \ install threading=multi link=static Thanks, -g

2 3

[type_traits] Is_nothrow_move_constructible fails on mngw
by Andrzej Krzemienski 21 Nov '15

21 Nov '15

Hi, It looks like is_nothrow_move_constructible (in branch develop, on testers igaztanaga-gcc-4.6c++11 and igaztanaga-gcc-4.7c++11) fails the compilation rather than returning a true-false answer. <http://www.boost.org/development/tests/develop/igaztanaga-gcc-4-7c++11.html>I filed a ticket for it: https://svn.boost.org/trac/boost/ticket/11811 Reards, &rzej

1 0

[thread] Boost threading on VMware ESXi
by Fu ji 20 Nov '15

20 Nov '15

Hello, Is there anyone who try to use boost threading on ESXi (posix like system from VMware) or try to port it? Best regards, Damian

1 0

Re: [boost] boost log memory leak? Maybe it is my wrong.
by Jefferyliangmh 16 Nov '15

16 Nov '15

Many thanks andrey.semashev's reply. I send my demo application codes in BoostDemo.rar file. "logger" is my wrapped module by win32 dll. "BoostDemo" is my MFC test application, call logger code written in CMainFrame::CMainFrame() fuction, like this : AppLogger::log("this is test message"). Memory leak display in output windows when compiled BoostDemo application. 2015-11-16 2015-11-16 Jefferyliangmh 发件人：boost-request(a)lists.boost.org 发送时间：2015-11-16 01:00 主题：Boost Digest, Vol 4908, Issue 1 收件人："boost"<boost(a)lists.boost.org> 抄送： Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/Archives/boost/ Today's Topics: 1. boost log memory leak? Maybe it is my wrong. (=?UTF-8?B?5qKB5piO6L6J?=) 2. Re: boost log memory leak? Maybe it is my wrong. (Andrey Semashev) 3. Re: checking __INTEL_COMPILER == 9999 (Blower, Melanie) 4. Re: checking __INTEL_COMPILER == 9999 (Edward Diener) ---------------------------------------------------------------------- Message: 1 Date: Sat, 14 Nov 2015 19:31:28 +0800 From: "=?UTF-8?B?5qKB5piO6L6J?="<liang_mh(a)163.com> To: "boost"<boost(a)lists.boost.org> Subject: [boost] boost log memory leak? Maybe it is my wrong. Message-ID: <220730f2.126658.15105c3ab0c.Coremail.liang_mh(a)163.com> Content-Type: text/plain; charset="UTF-8" Way I want to use win32 dynamic link library encapsulates the boost.log, the wrapper DLL in MFC MSVC 2015 calls, memory leak in output window prompt; The same library in a console program calls, no such problems. I am very depressed. Who can help me? 2015-11-14 ??? ------------------------------ Message: 2 Date: Sun, 15 Nov 2015 00:05:28 +0300 From: Andrey Semashev <andrey.semashev(a)gmail.com> To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Subject: Re: [boost] boost log memory leak? Maybe it is my wrong. Message-ID: <CAEhD+6BH=Lnw1ghLwOVarXbYGDBqoNygzcWnML+TtU7mVbB1zQ(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Sat, Nov 14, 2015 at 2:31 PM, ??? <liang_mh(a)163.com> wrote: > Way I want to use win32 dynamic link library encapsulates the boost.log, the wrapper DLL in MFC MSVC 2015 calls, memory leak in output window prompt; The same library in a console program calls, no such problems. > I am very depressed. Who can help me? If you work with Boost.Log the same way in both cases then it's likely a problem in your code and not the library. Otherwise I can't help without a minimal working code sample. ------------------------------ Message: 3 Date: Sun, 15 Nov 2015 13:05:27 +0000 From: "Blower, Melanie" <melanie.blower(a)intel.com> To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Subject: Re: [boost] checking __INTEL_COMPILER == 9999 Message-ID: <B3584E72CFEBED439A3ECA9BCE67A4EF40258FCC(a)fmsmsx116.amr.corp.intel.com> Content-Type: text/plain; charset="us-ascii" Thanks for all your suggestions and replies, I will work it on the Intel side. To Edward, at the bottom of my first message there's info about one of the failure modes. --Melanie ------------------------------ Message: 4 Date: Sun, 15 Nov 2015 10:43:25 -0500 From: Edward Diener <eldiener(a)tropicsoft.com> To: boost(a)lists.boost.org Subject: Re: [boost] checking __INTEL_COMPILER == 9999 Message-ID: <n2a971$msb$1(a)ger.gmane.org> Content-Type: text/plain; charset=windows-1252; format=flowed On 11/15/2015 8:05 AM, Blower, Melanie wrote: > Thanks for all your suggestions and replies, I will work it on the Intel side. To Edward, at the bottom of my first message there's info about one of the failure modes. Thanks, I see that now. ------------------------------ Subject: Digest Footer _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ End of Boost Digest, Vol 4908, Issue 1 **************************************

1 0

checking __INTEL_COMPILER == 9999
by Blower, Melanie 15 Nov '15

15 Nov '15

A few years ago, circa 2010, the Intel 12.x compiler was released without having a correct value for the macro __INTEL_COMPILER. It was released using the development-only version number 9999 instead of the correct value 12xx. Later on, an Intel 12.x compiler was updated to remove this problem and the version number made correct. Meanwhile, since boost needed to add some workarounds, there was code added in a couple of boost files to check for version 9999. The check for 9999 in boost causes trouble in our current development compiler in-house testing. Is it possible to have this version checking removed from the boost sources? There's no advantage to boost users, and possibly a disadvantage if someone is still using a not-updated 12.x compiler. But hopefully that is unlikely, we're currently shipping our 16.x compiler. Here's the diff, diff --git a/include/boost/config/compiler/intel.hpp b/include/boost/config/compiler/intel.hpp index 7789b94..bbbf876 100644 --- a/include/boost/config/compiler/intel.hpp +++ b/include/boost/config/compiler/intel.hpp @@ -47,11 +47,7 @@ #undef BOOST_COMPILER #if defined(__INTEL_COMPILER) -#if __INTEL_COMPILER == 9999 -# define BOOST_INTEL_CXX_VERSION 1200 // Intel bug in 12.1. -#else # define BOOST_INTEL_CXX_VERSION __INTEL_COMPILER -#endif #elif defined(__ICL) # define BOOST_INTEL_CXX_VERSION __ICL #elif defined(__ICC) @@ -93,11 +89,7 @@ #include "boost/config/compiler/common_edg.hpp" #if defined(__INTEL_COMPILER) -#if __INTEL_COMPILER == 9999 -# define BOOST_INTEL_CXX_VERSION 1200 // Intel bug in 12.1. -#else # define BOOST_INTEL_CXX_VERSION __INTEL_COMPILER -#endif #elif defined(__ICL) # define BOOST_INTEL_CXX_VERSION __ICL #elif defined(__ICC) @@ -289,7 +281,7 @@ template<> struct assert_intrinsic_wchar_t<unsigned short> {}; // (Niels Dekker, LKEB, May 2010) // Apparently Intel 12.1 (compiler version number 9999 !!) has the same issue (compiler regression). #if defined(__INTEL_COMPILER) -# if (__INTEL_COMPILER <= 1110) || (__INTEL_COMPILER == 9999) || (defined(_WIN32) && (__INTEL_COMPILER < 1600)) +# if (__INTEL_COMPILER <= 1110) || (__INTEL_COMPILER == 1210) || (defined(_WIN32) && (__INTEL_COMPILER < 1600)) # define BOOST_NO_COMPLETE_VALUE_INITIALIZATION # endif #endif Here's the other checking for 9999 that I found. Not known to cause a problem. diff --git a/include/boost/regex/v4/regex_format.hpp b/include/boost/regex/v4/regex_format.hpp index e9006a7..bf2e552 100644 --- a/include/boost/regex/v4/regex_format.hpp +++ b/include/boost/regex/v4/regex_format.hpp @@ -180,7 +180,7 @@ private: } inline int toi(ForwardIter& i, ForwardIter j, int base) { -#if defined(_MSC_VER) && defined(__INTEL_COMPILER) && ((__INTEL_COMPILER == 9999) || (__INTEL_COMPILER == 1210)) +#if defined(_MSC_VER) && defined(__INTEL_COMPILER) && (__INTEL_COMPILER == 1210) // Workaround for Intel support issue #656654. // See also https://svn.boost.org/trac/boost/ticket/6359 return toi(i, j, base, mpl::false_()); The intel.hpp check for 9999 causes this problem, among others, float128 tests from (boost_multiprecision suite) fail due to workaround in intel.hpp fo 12.1 compiler that was released with __INTEL_COMPILER == 9999 Fails like this: $ "icpc" -c -xc++ -O0 -w1 -inline-level=0 -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DSLOW_COMPILER -DTEST_FLOAT128 -I"../../.." -I"../include" -c -o "../../../bin.v2/libs/multiprecision/test/test_tanh_float128.test/intl-lnx/dbg/dbg-symbl-\ off/test_tanh.o" "test_tanh.cpp" In file included from test_tanh.cpp(53): ../../../boost/multiprecision/float128.hpp(48): error: identifier "_Quad" is undefined typedef _Quad float128_type; ^ Thanks and regards, Melanie Blower

5 6

boost log memory leak? Maybe it is my wrong.
by 梁明辉 14 Nov '15

14 Nov '15

Way I want to use win32 dynamic link library encapsulates the boost.log, the wrapper DLL in MFC MSVC 2015 calls, memory leak in output window prompt; The same library in a console program calls, no such problems. I am very depressed. Who can help me? 2015-11-14 梁明辉

2 1

Boost 1.60.0 beta 1 Release Candidate 3 available for testing
by Marshall Clow 14 Nov '15

14 Nov '15

Release candidate files for 1.60.0 beta 3 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. Changes since rc1: * Boost.Sprit has been updated and Boost.Log now builds. * Boost.Math has been updated and now builds. [ Note: The RC2 files that I posted yesterday were incorrectly produced. RC3 is identical to what RC2 should have been -- end note ] Known issues: * Errors when building libraries for visual studio: test and type_erasure. * Boost.Test fails when building on Darwin with gcc 4.9.2 The files (and associated md5s) are: MD5 (boost_1_60_0_b1_rc3.7z) = cfac18348700d0e6c1a0e4418a57e9aa MD5 (boost_1_60_0_b1_rc3.tar.bz2) = d3cb5a59e5b38555096814a6bfbcb441 MD5 (boost_1_60_0_b1_rc3.tar.gz) = db9b011547b8933454d0dfe31f7b8551 MD5 (boost_1_60_0_b1_rc3.zip) = 216c7cd0c15c096ece24d2649a272b51 Thanks! -- The release managers

3 4

Seeking advice regarding inline namespaces
by Louis Dionne 13 Nov '15

13 Nov '15

Dear community, I am seeking advice regarding the usage of inline namespaces for header-only metaprogramming libraries. I was at Eric Niebler's talk on C++11 library design back in 2014, and I understand the problem that inline namespaces solve. I also read all of this past thread [1] on the mailing list, but did not find what I was looking for. I also understand how they can be useful for a normal header-only library __that would provide guarantees about ABI compatibility__. Indeed, if the ABI of the library changes from v1 to v2, then any client C1 exposing types from v1 in its interface and trying to link with a client C2 built against v2 will get a clean link-time error instead of a runtime error. Now, my question has several aspects: (1) How can you guarantee ABI compatibility from one version of a library to the next? IIUC, ABI can be broken by merely changing the size or the layout of a type, so guaranteeing backwards ABI compatibility means freezing those things in time, right? (2) Assuming that it is unreasonable for a library L to guarantee ABI compatibility from one version to the next, would there still be a reason to use inline namespaces to version that library? (3) When using inline namespaces to version a library (at all, not necessarily for header only libraries), are there other guidelines to follow? For example, I see that Eric Niebler's range-v3 library is all stuffed in the range/v3 subdirectory. IIUC, this would allow an eventual range-v4 library to cohabit with the range-v3 library, because people explicitly state which version of the library they're including. Is this the reason behind the v3 subdirectory? Any answer or pointer to answers is appreciated. Regards, Louis [1]: http://boost.2283326.n4.nabble.com/type-traits-general-Best-practice-for-in… -- View this message in context: http://boost.2283326.n4.nabble.com/Seeking-advice-regarding-inline-namespac… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 6

Boost 1.60.0 beta 1 Release Candidates available for testing
by Marshall Clow 12 Nov '15

12 Nov '15

Release candidate files for 1.60.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. IMPORTANT NOTE: The files (and associated md5s) are: MD5 (boost_1_60_0_b1_rc1.7z) = ac6b2128d951ad688421fde2d878c2a7 MD5 (boost_1_60_0_b1_rc1.tar.bz2) = 2fc232f255f1ce8868315da207c05b6b MD5 (boost_1_60_0_b1_rc1.tar.gz) = d594e10f2761abaf957a67c6a223d2a4 MD5 (boost_1_60_0_b1_rc1.zip) = 16a2d512fca7995d5fa421d13f841b0f Thanks! -- The release managers

23 49

[property_tree iostreams smart_ptr] Warning fixes
by Joachim Faulhaber 11 Nov '15

11 Nov '15

Dear all, I have submitted pull requests for mostly warning fixes. 3 of them are still open. https://github.com/boostorg/property_tree/pull/15/files https://github.com/boostorg/iostreams/pull/19 https://github.com/boostorg/smart_ptr/pull/18 Could someone merge them in, so we have this fixed for 1.60. That would be nice. Thanx in advance Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

Re: [boost] [Boost-users] Boost 1.60.0 beta 1 Release Candidates available for testing
by Tom Kent 10 Nov '15

10 Nov '15

On Tue, Nov 10, 2015 at 12:05 AM, Raffi Enficiaud < raffi.enficiaud(a)mines-paris.org> wrote: > Le 10/11/15 00:05, Tom Kent a écrit : > >> On Mon, Nov 9, 2015 at 9:52 AM, Marshall Clow <mclow.lists(a)gmail.com >> <mailto:mclow.lists@gmail.com>> wrote: >> >> Release candidate files for 1.60.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. >> >> >> Errors when building libraries for visual studio: test and type_erasure. >> I've grabbed the repeated outputs and posted below. Full logs are at: >> >> 32-Bit: https://gist.github.com/teeks99/bed0ef4204d24677fa4e >> 64-Bit: https://gist.github.com/teeks99/6d0358817ddfe43724f7 >> >> Tom >> > > I have a fix for MSVC but some problems have also been reported for gcc4.4 > c++0x mode. I can merge the fix for MSVC to develop and/or master once > reopened. > > Raffi > Since it is preventing building of the release binaries, I think this should be merged before the beta is released. Tom

3 4

[1.60][spirit] Unmerged changes prevent compilation
by Andrey Semashev 10 Nov '15

10 Nov '15

Hi, The latest 1.60 beta RC fails to build Boost.Log because some changes in Boost.Spirit has not been merged to master. At least these patches need to be merged to master: 1. Fix the duplicate definition of strip_single_element_vector specialization: https://github.com/boostorg/spirit/commit/4d8899fdfe26237d6d983a7ac5528d00f… 2. Fix an attempt to construct an instance of none_t: https://github.com/boostorg/spirit/commit/534cf39f15ced047359ee8b6dfe434635… 3. Although it's not strictly a build breaker, this change fixes a bunch of warnings about signed/unsigned mismatch: https://github.com/boostorg/spirit/pull/140 After applying those patches to the RC Boost.Log builds successfully. These commits and the PR has been in develop for quite some time, could someone merge them to master, please?

4 7

[Range] sorted and randomized adaptors
by Mohammed El-Afifi 10 Nov '15

10 Nov '15

Hello everybody, I know this might have been raised a few times before in this mailing list, but I'd like to know if it's possible(or otherwise what would prevent) to have sorted and randomized adaptors so that I may have a sorted and randomized view of a range respectively. Something like vector<int> x; // operations to fill x x | boost::adaptors::sorted; x | boost::adaptors::randomized;// That one might also take an optional random generator as a parameter. I understand that in this case the adaptor isn't entirely lazy as the adapted(x here) must be completely consumed before producing a single element in the resulting range. I want to know however if having such adaptors may contradict any basic principles of the existing adaptors. P.S. Two other threads I found that discussed the same idea(for sorted only): - http://lists.boost.org/Archives/boost/2009/03/149247.php - http://lists.boost.org/Archives/boost/2006/05/105122.php

3 2

Seeking feedback on SegmentedTreeSeq (sequence data structure with efficient random access insert and erase)
by Chris Clearwater 09 Nov '15

09 Nov '15

Greetings, At this time I would like to solicit feedback for my library SegmentedTreeSeq. It is an implementation of a counted B+Tree that allows efficient random access insert and erase. It's an ideal data structure for an application such as a text editor. I am also seeking interested reviewers as I feel it has reached a state that is ready for formal review. Features: - Implements the union of std::vector, std::deque, and std::list interfaces. - Implements the C++11 allocator model. - Implements the full C++14 interfaces including emplacement and move semantics. - O(log n) to obtain an iterator at any position. - O(log n) insert and erase. - Amortized O(log n) iterator movement. - Strong exception guarantee for insert. - Support for incomplete types. - SCARY iterators. - Best in class performance for many operations. - Low memory overhead for data of any type. Links: - Incubator: http://rrsd.com/blincubator.com/bi_library/segmentedtreeseq-2/?gform_post_i… - Repository: https://github.com/det/segmented_tree_seq - Documentation: https://det.github.io/segmented_tree_seq Thanks, Chris

2 2

[1.60.0] Release Notes
by Daniel James 08 Nov '15

08 Nov '15

Hello everyone, If you haven't done so already, please can you add your entries to the release notes. Easiest way to do so is to create a pull request by clicking on the pencil icon at the top right of the source code at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_60_0.q… Or if you prefer you can email me. thanks, Daniel

2 1

[regression] Test results unavailable
by Andrey Semashev 07 Nov '15

07 Nov '15

Hi, Is anyone able to see develop test results? I'm seeing a blank page.

3 4

[build] How do I build for windows phone?
by John Maddock 06 Nov '15

06 Nov '15

Boost.Build evidently has options for building for windows store and windows phone. The store builds work fine for me, but the phone builds fail as there is no compiler on the command line generated: ../../../bjam config_info msvc-14.0 windows-api=phone -d2 ...found 179 targets... ...updating 5 targets... file ..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0\debug\link-static\runtime-link-static\windows-api-phone\config_info.obj.rsp "config_info.cpp" -Fo"..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0\debug\link-static\runtime-link-static\windows-api-phone\config_info.obj" -TP /Z7 /Od /Ob0 /W3 /GR /Zc:forScope /Zc:wchar_t /MTd /wd4675 /EHs -c -DBOOST_ALL_NO_LIB=1 -DWINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP -D_WIN32_WINNT=0x0602 "-I..\..\.." compile-c-c++ ..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0\debug\link-static\runtime-link-static\windows-api-phone\config_info.obj /Zm800 -nologo @"..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0\debug\link-static\runtime-link-static\windows-api-phone\config_info.obj.rsp" '/Zm800' is not recognized as an internal or external command, operable program or batch file. Any ideas what I'm doing wrong? BTW I can't find any docs mentioning these options - and it's something end users building Boost may well need? Finally a supplementary question: has anyone succeeded in running regression tests on either the store or phone platforms? If I run: /bjam config_info msvc-14.0 windows-api=store I get: testing.capture-output ..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0\debug\link-static\runtime-link-static\windows-api-store\config_info.run ====== BEGIN OUTPUT ====== Access is denied. EXIT STATUS: 5 Along with a screen message saying the app can't be run on my PC. Any ideas? Many thanks, John.

3 4

[thread] boost::future::then
by Vladimir Prus 06 Nov '15

06 Nov '15

Hi, looking through docs for some other futures implementation [1], I see this: Why not use boost::future? # At the time of writing, 1.53 (the first version with the requisite features) was brand new, not well-tested, and not available to [...] developers. It is still a bit buggy/bleeding-edge They haven't fleshed out the threading model very well yet, e.g. every single then currently spawns a new thread unless you explicitly ask it to work on this thread only, and executor support was nonexistent (and now, is still experimental). Now, 1.53 is ancient. Can anybody comment on these statements regarding boost::future::thread state in 1.59? In particular, suppose I have this: // Thread 1 boost::promise<int> pi; boost::future<int> fi = pi.get_future(); // pass pi to thread 2 somehow fi.then(....); // Thread 2 pi.set_value(100); And I want continuation to be executed in thread 1, assuming that thread 1 runs Qt event loop, allowing me to use QTimer::singleShot, or queued signal, or similar mechanism. How would I go about making boost::future do it? Has anybody done so? Thanks, Volodya

4 41

The release branch will close tonight for the 1.60 beta
by Marshall Clow 05 Nov '15

05 Nov '15

Please do not merge to the release branch after tonight until the 1.60 beta is released (scheduled for next Wednesday) unless you have specific approval from the release managers. Thank you. (There will be a chance to merge bug fixes and documentation updates after the beta) -- Marshall (and the rest of the release managers)

2 2

[config] macro for portable restrict and restrict references
by Joel FALCOU 04 Nov '15

04 Nov '15

I pushed a PR that adds the macro BOOST_RESTRICT to take place of the compielr specific __restrcict/__restrict__ keyword. It also comes with an indicator if said keyword can be applied to references. https://github.com/boostorg/config/pull/81 Comments welcome.

1 0

[String Algo] Any reason the predicates don't optimize for random access iterators?
by Nevin Liber 04 Nov '15

04 Nov '15

I was looking in boost/algorithm/string/predicate.hpp and noticed that that the predicates *starts_with, *ends_with, *contains and *equals don't optimize for random access iterators. While I haven't done any benchmarks yet, it seems like it would be faster for random access iterators to do an O(1) length check at the beginning and then while looping only check one iterator against its end instead of two. Thoughts? Nevin :-) -- Nevin ":-)" Liber <mailto:nevin@c <nevin(a)eviloverlord.com>plusplusguy.com> (847) 691-1404

2 1

[test][serialization] Fwd: [Boost-testing] regression testing failure on develop branch
by Rene Rivera 03 Nov '15

03 Nov '15

---------- Forwarded message ---------- From: Aparna Kumta <aparna.kumta(a)oracle.com> Date: Mon, Nov 2, 2015 at 2:42 PM Subject: [Boost-testing] regression testing failure on develop branch To: Running Boost regression tests <boost-testing(a)lists.boost.org> My regresion tests are failing on develop branch as follows: error: at /export/home/boost_regression_develop/boost_sparc-S2_stlport4/boost_bb/src/kernel/modules.jam:107 error: Unable to find file or target named error: 'test_boost_array.cpp' error: referred to from project at error: '../libs/serialization/test' Anyone seeing this issue? Thanks, Aparna _______________________________________________ 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

4 3

Interest in a Boost.Chrono/Date library
by Vicente J. Botet Escriba 03 Nov '15

03 Nov '15

Hi, maybe some of you have already see the Howard Hinnant presentation at CppCOn2015 [1] about his new data-v2 library [2]. My prototype of Boost.Chrono/Date library ([3] ] was based on the Howard original library, but when we want to reach the maximum of performances we need to use a specific date class for each usage. This is what Howard explains in his marvelous presentation ans his tiny date library My post here wants to know if there is interest in a library providing what H.H. date library provides in Boost. Note that his data-v2 library yet doesn't provides as much as Boost.Date provides but IMHO it is much elegant and efficient. If there is enough interest, I will request you to do a first review of the H.H. Date-V2 library. Then once we have a consensus I will make my POC Chrono/Date library ready for review. H.H. Date-V2 is under MIT license, which IIRC is compatible with the Boost license. I don't know yet if would need to add this license, as my POC [3] is already a good starting point, nevertheless, I would like to know if there could be any issues about having the source under both licenses. Best, Vicente [1] https://www.youtube.com/watch?v=tzyGjOm8AKo [2] https://github.com/HowardHinnant/date [3] https://github.com/viboes/chrono_date/commits/master First commit Nov/2011 Last-Mars2014

8 17

Math tools polynomial enhancements
by Jeremy Murphy 02 Nov '15

02 Nov '15

I was just looking at the polynomial class and thinking that it could be enhanced substantially with more operators. Presumably with division and remainder it would be a Euclidean ring and then you could even call gcd on it. I have a draft implementation ready but I wanted to check that there is interest from the maintainers. Cheers. Jeremy

9 27

[base_from_member][sun-next_cpp11] problem with variadics at base_from_member
by Joaquín M López Muñoz 02 Nov '15

02 Nov '15

Hi, In 2012, boost::base_from_member was equipped with variadics machinery to perfect-forward construction arguments to the contained member. Unfortunately, Solaris Studio 12.5 on Intel chokes on it (http://tinyurl.com/no7trgb ): "../boost/utility/base_from_member.hpp", line 137: Error: Parameter pack 'x' not expanded with '...' [...] Oddly enough, the same compiler does work fine on Sparc. May I suggest that lines 129-132 of boost/utility/base_from_member.hpp #if !defined(BOOST_NO_CXX11_RVALUE_REFERENCES) && \ !defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES) && \ !defined(BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS) && \ !(defined(__GNUC__) && (__GNUC__ == 4) && (__GNUC_MINOR__ < 4)) be added a special provision for this environment (the same way it already has for GCC 4 and prior)? #if !defined(BOOST_NO_CXX11_RVALUE_REFERENCES) && \ !defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES) && \ !defined(BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS) && \ !(defined(__GNUC__) && (__GNUC__ == 4) && (__GNUC_MINOR__ < 4)) && \ !(defined(__SUNPRO_CC) && defined(__i386) && (__SUNPRO_CC <= 0x5140)) I can't unfortunately test this myself as I don't have access to the compiler. FWIW, my interest in having this fixed is that it's seemingly the only bug preventing Oracle Solaris Studio 12.5 on Intel from supporting Boost.MultiIndex. Joaquín M López Muñoz Telefónica

3 3

[GitHub] [PR] setting default branch to 'develop'
by Michel Morin 01 Nov '15

01 Nov '15

Hi, We sometimes forget to change the base branch of PR from 'master' to 'develop', even if we know PR should be made against 'develop' branch! To prevent from accidentally making PR against master branch, it'd be nice to **set the default branch to 'develop' branch** for Boost repositories on GitHub. (Then, the default base branch of PR would be set to 'develop' branch.) To change the default branch, it takes just a few clicks on web browser: https://help.github.com/articles/setting-the-default-branch/ Thoughts? Regards, Michel P.S. Some libraries have already done this, but most of Boost libraries don't do this yet.

10 22

[Config] BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE not defined in MACOS for GCC-5
by Vicente J. Botet Escriba 29 Oct '15

29 Oct '15

Hi John, I'm having an issue with gcc-5.1 on MacOs. BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE is not defined. I see that there are things like #if __MACH__ && !defined(_MSL_USING_MSL_C) ... # if (__GNUC__ == 4) // Both gcc and intel require these. # define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE # define BOOST_HAS_NANOSLEEP # endif #else ... // BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE not defined here #endif Wondering why the GCC version must be 4 and why when _MSL_USING_MSL_C is defined these PTHREAD attributes are not defined neither. BTW, when I compile with version 4 everything works correctly. Vicente

3 3

[website] update version for Oracle Solaris Studio on the Boost website
by Aparna Kumta 29 Oct '15

29 Oct '15

The Boost1.59 page at http://www.boost.org/users/history/version_1_59_0.html under 'Compilers Tested' section, contains an entry for Sun( Oracle Solaris Studio). This needs modification for the upcoming Boost 1.60 release for which I would like to submit a PR. I looked at https://github.com/boostorg/website but not sure if this is the correct repository. Could someone please point me as to where I need to submit the PR? Thanks, Aparna

2 1

[graph] dijkstra pull request ping
by Piotr Wygocki 28 Oct '15

28 Oct '15

Dear all, this mail concerns this pull request: https://github.com/boostorg/graph/pull/13 which is currently over one year long. Maybe, the idea of the patch is unclear or needs some additional discussion. The patch solves the problem which arises when using no_init version on dijkstra algorithm and passing a custom distance_map. This algorithm is implemented as call to BFS, which is very unfortunate since it is not BFS. Maybe BFS could be seen as special case of dijkstra with custom priority queue but not the other way around. The current implementation introduces some inefficiencies, which are described in the pull request's comment. I've created very short and direct patch which makes the implementation straight forward. Additionally, the unit test is added to check mentioned efficiency gain. Are there any additional questions concerning this pull request? Could it be possibly be merged to master? Maybe, we can use a favour of the community maintenance team. Regards, Piotr Wygocki

5 20

Boost.Log 1.59.0 incompatible with MSVC option /Zc:wchar_t-
by Giel van Schijndel 28 Oct '15

28 Oct '15

Hi, I'm trying to build Boost.Log on MSVC9 (aka Visual Studio 2008) with the [/Zc:wchar_t-][1] option (necessary due to a vendor's SDK we're using). Unfortunately this fails to build. The mentioned option turns wchar_t into a typedef to unsigned short (i.e. it's not longer a distinct type). TLDR: My question _why_ is boost::log::aux::is_character_type<wchar_t> excluded when BOOST_NO_INTRINSIC_WCHAR_T is #defined? I see no harm in including it unconditionally. For some reason however, the template meta-function boost::log::aux::is_character_type<T>'s specialisation for wchar_t is guarded by !defined(BOOST_NO_INTRINSIC_WCHAR_T) [2]. This means wchar_t is _not_ regarded as a character type and prevents instantiation of the boost::log::aux::code_convert functions [3] which are _still_ used. The only reason I can see for excluding this is to prevent a _potential_ conflict with multiple specialisations for the same type (because of the typedef nature of wchar_t). But the only other specialisation that could potentially give a conflict is the one for char16_t, and that's mandated by C++11 to be a distinct type (AFAIK the only reason why wchar_t isn't always distinct type on Windows/MSVC is because they introduced the type pre-standardisation, so I see no reason why that mistake should be repeated for char16_t). For reference, the mentioned option's usage is detected in boost by this option preventing #definition of _NATIVE_WCHAR_T_DEFINED to indicate it did this. In boost/config/compiler/visualc.hpp there's the following code: > #ifndef _NATIVE_WCHAR_T_DEFINED > # define BOOST_NO_INTRINSIC_WCHAR_T > #endif [1]: https://msdn.microsoft.com/en-us/library/ms933181.aspx [2]: https://github.com/boostorg/log/blob/boost-1.59.0/include/boost/log/detail/… [3]: https://github.com/boostorg/log/blob/boost-1.59.0/include/boost/log/detail/… -- Met vriendelijke groet, With kind regards, Giel van Schijndel

2 3

boost lockfree queue.hpp - alternate implementation w/o compare_exchange
by boost＠mccart.us 28 Oct '15

28 Oct '15

Is there any interest in an alternate implementation of a lockfree queue that doesn't use compare_exchange (assuming it is correct, or can be made to be correct)? I have a multi-producer / multi-consumer implementation that generally doesn't suffer nearly as much from contention. On my hardware (an older high-end 64 bit x86 workstation) I get roughly comparable throughput with existing boost lockfree queue with 1 producer and 1 consumer. With 4 producers and 4 consumers I get about 3x throughput gain on existing boost lockfree queue. However, this implementation has a weakness, it suffers in over subscription scenarios (threads in middle of push/pop that lose their time-slice); with twice as many threads as cores its performances is comparable to boost lockfree queue (using try_push/try_pop, otherwise throughput is down the toilet), and with 4x thread/core ratio the throughput is somewhat less than boost lockfree queue. This was tested on Windows 7 x64 with Inel Xeon X5355 x 2 (2 sockets w/ 4 cores a piece) @ 2.66 Ghz and 32 GB RAM @ 667 MHz. The implementation can be found here: https://github.com/benmccart/GuarunteedMpmcQueue/blob/master/queue/queue.hpp Is the implementation correct? Can anyone spot any race conditions, or conditions under which the implementation would fail to work as expected (other than queue is full/empty or over-subscription)? ~Ben

5 14

[serialization]cannot build libboost_serialization.so.1.60.0 with Oracle Solaris Studio
by Aparna Kumta 28 Oct '15

28 Oct '15

I see the following error when compiling Boost 1.60 in develop branch with Oracle Solaris Studio development compiler with -library=stlport4. "CC" -compat=5 -library=stlport4 -temp=/tmp/bn -xO4 -mt -erroff=%none -m32 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -c -o "/export/home/sstrunk-tester/boost_regression/boost_regression_develop/boost_sparc-S2_stlport4/results/boost/bin.v2/libs/serialization/build/sun-next_stlport4/release/link-static/threading-multi/basic_text_iprimitive.o" "../libs/serialization/src/basic_text_iprimitive.cpp" "../boost/archive/basic_streambuf_locale_saver.hpp", line 75: Error: sync is not a member of std::ios . "../boost/archive/impl/basic_text_iprimitive.ipp", line 112: Where: While instantiating "boost::archive::basic_ios_locale_saver<char, std::char_traits<char>>::~basic_ios_locale_saver()". "../boost/archive/impl/basic_text_iprimitive.ipp", line 112: Where: Instantiated from boost::archive::basic_text_iprimitive<std::istream>::basic_text_iprimitive(std::istream &, bool). "../libs/serialization/src/basic_text_iprimitive.cpp", line 25: Where: Instantiated from non-template code. 1 Error(s) detected. This seems to prevent building libboost_serialization.so.1.60.0, and a recent regression after changes to the serialization library. Thanks, Aparna

3 4

[type_traits][multi_index][msvc-7.1] problems with is_const in VC 7.1
by Joaquin M López Muñoz 27 Oct '15

27 Oct '15

> Hi, Boost.MultiIndex is failing at master for VC 7.1: http://tinyurl.com/oxflkj6 .\boost\multi_index\identity.hpp(75) : error C2535: 'Type &boost::multi_index::detail::const_identity_base<Type>::operator() (const boost::reference_wrapper<Type> &) const' : member function already defined or declared the problem seemingly being with boost::is_const. The offending code looks like template<typename Type> struct const_identity_base { // produces the error above if Type is not const }; template<typename Type> struct non_const_identity_base { ... }; template<class Type> struct identity: mpl::if_c< is_const<Type>::value, detail::const_identity_base<Type>, detail::non_const_identity_base<Type> >::type { }; Boost.TypeTraits recently changed its is_const implementation to the very simple template <class T> struct is_const : public false_type {}; template <class T> struct is_const<T const> : public true_type{}; template <class T, size_t N> struct is_const<T const[N]> : public true_type{}; template <class T> struct is_const<T const[]> : public true_type{}; which relies on template partial specialization (supposedly supported by VC 7.1). Yet, seems like const_identity_base is wrongly selected for a non-const Type. Any clues about what might be going on? Thank you, Joaquín M López Muñoz Telefónica

5 15

[tools] updating sun.jam
by Aparna Kumta 27 Oct '15

27 Oct '15

I am not familiar with the syntax to update sun.jam file. In tools/build/src/tools/sun.jam, lines 153-156 contain 153: actions link.dll bind LIBRARIES 154: { 155: "$(CONFIG_COMMAND)" $(OPTIONS) -L"$(LINKPATH)" -R"$(RPATH)" -o "$(<)" -h$(<[1]:D=) -G "$(>)" "$(LIBRARIES)" -Bdynamic -l$(FINDLIBS-SA) -Bstatic -l$(FINDLIBS-ST) -B$(LINK-RUNTIME) 156: } Only if compiling with -std=c+11 or -std=c++14, I need to replace '-G' above with '-G -library=stdcpp,CrunG3' Any help on modifying this is appreciated. Thanks, Aparna

1 0

1.60 closes for major changes next Wednesday
by Vladimir Prus 27 Oct '15

27 Oct '15

1.60 is now closed for new libraries and breaking changes - please don't merge such changes for master. We'll be closed for major changes next Wednesday, Oct 28, at the end of the day. Thanks, -- Vladimir Prus http://vladimirprus.com

3 3

[vmd] Added to new release
by Edward Diener 26 Oct '15

26 Oct '15

I would like to make sure the VMD library is added to the upcoming Boost 1.60 release. Is there anything further I have to do to affect that ?

1 0

[Hana] Postponing release to 1.61.0
by Louis Dionne 24 Oct '15

24 Oct '15

Hi, Some of you might know that I have been pushing hard to deliver Hana with the next Boost release. I have even taken the (soft) engagement to do so at CppCon in last September. However, due to some time constraints, it is now clear that Hana will not be included in Boost 1.60.0, the limit for new libraries being yesterday. I hoped really hard to make it in time for Boost 1.60.0, but the closing of the release branch ~1 month before the release date got me by surprise. All in all, this is not too bad since there are still a couple issues that must be addressed, and I believe that taking more time to address them properly will be beneficial to the community in the long term. Also, while I really wanted to make Hana available to the wider community ASAP, I do not think waiting 3 more months will be very harmful. Given the current level of C++14 support in compilers, only people on Clang >= 3.5 would have been able to use Hana, and I do not think this represents such a huge amount of potential users. As a side note, given my previous announcements, some users might find it strange not to see Hana as part of 1.60.0. Hence, I wonder whether it would be possible to include a short note with a link to this message somewhere in the release notes for 1.60.0? Regards, Louis

3 4

[detail] Compilation broken in develop and some questionable ideas
by Antony Polukhin 24 Oct '15

24 Oct '15

Hi, The commit https://github.com/boostorg/detail/commit/9fcf2ae390c7c21a9b42fd40dd5c0eec1… breaks the compilation of Boost.Filesystem: D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(126): error C2487: 'do_in': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(136): error C2487: 'do_out': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(152): error C2487: 'get_octet_count': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(156): error C2487: 'get_cont_octet_out_count': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(189): error C2487: 'do_length': member of dll interface class may not be declared with dll interface According to MSDN only the whole class or class separate members could be decorated with BOOST_UTF8_DECL, not both ( https://msdn.microsoft.com/en-us/library/t72ahzw1.aspx) Now the questionable part... We could theoreticaly avoid duplication of `utf8_codecvt_facet` code in libraries and even avoid code breakage if we: * move `struct utf8_codecvt_facet` to namespace `boost::detail::utf8_codecvt_facet_namespace` * mark all it's functions as inline, even the virtual ones => `inline` will implicitly mark the stuff in `struct utf8_codecvt_facet` as weak symbols, so that multiple occurences of it will be reduced to one by linker * add the using declaration `BOOST_UTF8_BEGIN_NAMESPACE using boost::detail::utf8_codecvt_facet_namespace::utf8_codecvt_facet; BOOST_UTF8_END_NAMESPACE` => using declaration will help the existing code to find class in `BOOST_UTF8_BEGIN_NAMESPACE` defined namespaces. Questionable part number two... Is it time to move Boost.Detail module into Boost.Core/Boost.Algorithm/Boost.MPL? Main points are: * Boost.Detail is really old and many people who maintained it are inactive. Moving it into rapidly developing modules will improve it's support (maybe even docs will appear! or tests!) * Nobody knows what does `Deatil` mean in that particular case. `detail::` namespace is a namespace that user must not use. However there's some cool stuff in Detail module that must be available to users, so the name Detail is obfuscating here. -- Best regards, Antony Polukhin

5 4

Painting a bikeshed ...
by Marshall Clow 21 Oct '15

21 Oct '15

In Sean Parent's CppCon keynote last week, he went through the process of implementing an algorithm he called "sort_subrange", which takes four iterators describing two ranges, one a subset of the other, and sorts the subrange - as if you had sorted the entire range. (See https://www.youtube.com/watch?v=sWgDk-o-6ZE, starting at about 31:30). I have implemented this in Boost.Algorithm (crediting Sean) - called partition_sort. However, while I was doing this, I thought of a different algorithm; one that gathered all the elements into the subrange as if the entire range was sorted, but didn't actually do the sorting. I've implemented that one, too - but I'm having a bit of trouble coming up with a name. I've used "partition_subrange", but that not that clear. Sean has suggested "elements_in_subrange" and "elements_within_subrange". Here's the declaration: template<typename Iterator, typename Pred> void partition_subrange ( Iterator first, Iterator last, Iterator sub_first, Iterator sub_last, Pred p) /// \brief Gather the elements of the subrange [sub_first, sub_last) that is /// inside the range [first, last) as if you had sorted the entire range. Any suggestions? -- Marshall

11 18

(no subject)
by Kabir Sahni 21 Oct '15

21 Oct '15

Hello! I have recently joined the mailing list and i am willing to contribute.Can anyone guide me

2 1

[metaparse] Transferring the repository to Boostorg
by Abel Sinkovics 21 Oct '15

21 Oct '15

Hi, I'd like to transfer my Metaparse repository (https://github.com/sabel83/metaparse) to Boostorg. Based on another thread on Hana, I assume I need temporary admin rights to boostorg to be able to transfer the repository. Please give me temporary admin rights (I've posted an issue for it as well: https://github.com/boostorg/admin/issues/110) or suggest another method for the repository transfer. Thanks, Abel

2 12

[Locale] New utf-8 codecvt facet in master (replacement of boost/details/utf8_codect_facet)
by Artyom Beilis 21 Oct '15

21 Oct '15

Hello, Following previous discussion regarding utf-8 facet in boost. I merged the changes to master branch. New utf8 codecvt facet that properly handles both UTF-16 and UTF-32 encoding for wchar_t (or char16_t/char32_t) is there. The major goal is to replace existing broken (*) utf8 facet existing today in boost/details/utf8_codecvt_facet.hpp/ipp It is implemented in header only so all you need is to include #include <boost/locale/utf8_facet.hpp> And install it as usual: std::locale new_locale(std::locale(),new boost::locale::utf8_codecvt<wchar_t>()); It *does not require* a separate compilation part like the one in details Note it is implemented in terms of boost::locale::generic_codecvt template<typename CharType,typename CodecvtImpl,int CharSize=sizeof(CharType)> class generic_codecvt; That has non-trivial specialization for CharSize=2 and CharSize=4 for UTF-16 and UTF-32 wchar_t/char16_t/char32_t character handling. boost::locale::generic_codecvt provides an interface for creating a range of facets for various character encodings. For example boost.locale uses it to implement various facets: - utf8 codecvt - single byte character set like ISO-8859-* or Windows-125* - wrap ICU ucnv_* and POSIX iconv APIs to create standard codecvt facet. That is why I decided to keep the implementation withing Boost.Locale library as the place that actually deals with different encoding. ----------- Once boost 1.60 will be released I encourage every library maintainer that incorporates broken boost/details/utf8_codecvt_facet.*pp to replace one with proper one from boost.locale Note: it is HEADER ONLY part and does not require any part of compiled library. Artyom Beilis (*) Current implementation does not handle utf-16 properly and can actually produce invalid utf-8

1 0

[Hana] Transferring repository to boostorg on GitHub
by Louis Dionne 19 Oct '15

19 Oct '15

Hi, I would like to know what is required from me to transfer the Hana repository from my GitHub account to boostorg. I reckon I should be added as a member of the boostorg "organization" on GitHub? Regards, Louis

2 14

Re: [boost] [interprocess] Interprocess mutex not working / throwing exception when trying to write lock
by nav999 19 Oct '15

19 Oct '15

> Hi, > > 1. Your lockWithWriteLock and lockWithReadLock create a lock, which locks > on construction and unlocks on destruction, hence when the function > returns no lock is held on the mutex. > > 2. The fact that you put a scope here makes me think that your intention > is for the lock to be unlocked at the end of this scope (which it won't, > as it is unlocked way before, as per #1). > > { > std::cout<<"Program 1: Before first locking > -------------------------- 1 v\n"; > temp.sharedMutex->lockWithWriteLock(); > const unsigned int SLEEP_TIME_IN_SECOND = 60; > std::cout<<"Program 1: sleep for "<< SLEEP_TIME_IN_SECOND << "\n"; > sleep(SLEEP_TIME_IN_SECOND); > std::cout<<"Program 1: Finished sleeping\n"; > } > > In this case though, you would perform the wait in bold while still > holding the lock, and hence preventing the 2nd program from locking it. > Once out of the scope you destroy the object right away. > > NOTE: both the issue in #1 and #2 lead to your first program possibly > deleting the mutex before the 2nd program is done with it. Which leads to > the issue you are experiencing. > > 3. If you need to have the 1st program wait for the 2nd program to be > done, then do not use sleeps, use a condition_variable. Thanks. I didn't know the lock unlocks on destruction. I had taken a cue from a post on StackOverflow: http://stackoverflow.com/questions/12439099/interprocess-reader-writer-lock… I'm using sleep only for testing purpose. The dilemma still is, how to make the mutex visible to both processes? This thread got rejected by the admin who suggested it could be posted on the users subforum, so kindly reply to my post there to continue the discussion: http://boost.2283326.n4.nabble.com/interprocess-Interprocess-mutex-not-work… -- View this message in context: http://boost.2283326.n4.nabble.com/interprocess-Interprocess-mutex-not-work… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 1

[interprocess] How to know how much memory is taken up by an object allocated in boost interprocess shared memory?
by nav999 19 Oct '15

19 Oct '15

Re-posting, as the boost mailing list rejected the first post <http://boost.2283326.n4.nabble.com/How-to-know-how-much-memory-is-taken-up-…> mentioning that I had to add "[interprocess]" to the subject line. I have asked this question on stackoverflow <http://stackoverflow.com/questions/30642585/why-does-an-object-allocated-in…> , but got no response. For this program: #include <iostream> #include <boost/interprocess/mapped_region.hpp> #include <boost/interprocess/managed_shared_memory.hpp> #include <boost/interprocess/containers/list.hpp> #include <iostream> #define SHARED_MEMORY_NAME "SO12439099-MySharedMemory" #define DATAOUTPUT "OutputFromObject" #define INITIAL_MEM 650000 #define STATE_MATRIX_SIZE 4 using namespace std; namespace bip = boost::interprocess; class SharedObject { public: unsigned int tNumber; bool pRcvdFlag; bool sRcvdFlag; unsigned long lTimeStamp; }; typedef bip::allocator<SharedObject, bip::managed_shared_memory::segment_manager> ShmemAllocator; typedef bip::list<SharedObject, ShmemAllocator> SharedMemData; int main() { bip::managed_shared_memory* seg; SharedMemData *sharedMemOutputList; bip::shared_memory_object::remove(DATAOUTPUT); seg = new bip::managed_shared_memory(bip::create_only, DATAOUTPUT, INITIAL_MEM); const ShmemAllocator alloc_inst(seg->get_segment_manager()); sharedMemOutputList = seg->construct<SharedMemData>("TrackOutput")(alloc_inst); std::size_t beforeAllocation = seg->get_free_memory(); std::cout<<"\nBefore allocation = "<< beforeAllocation <<"\n"; SharedObject temp; sharedMemOutputList->push_back(temp); std::size_t afterAllocation = seg->get_free_memory(); std::cout<<"After allocation = "<< afterAllocation <<"\n"; std::cout<<"Difference = "<< beforeAllocation - afterAllocation <<"\n"; std::cout<<"Size of SharedObject = "<< sizeof(SharedObject) <<"\n"; std::cout<<"Size of SharedObject's temp instance = "<< sizeof(temp) <<"\n"; }//main The output is: Before allocation = 649680 After allocation = 649632 Difference = 48 Size of SharedObject = 16 Size of SharedObject's temp instance = 16 If the size of SharedObject and it's instance is 16 bytes, then how can the difference in allocation be 48? Even if padding had automatically been done, it's still too much to account for 3 times the size (for larger structures it goes to 1.33 times the size). Because of this, I'm unable to allocate and dynamically grow the shared memory reliably. If SharedObject contains a list which grows dynamically, that could add to the uncertainty of space allocation even more. How can these situations be safely handled? How can I know exactly how much of memory to allocate? -- View this message in context: http://boost.2283326.n4.nabble.com/interprocess-How-to-know-how-much-memory… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 4

Do you know of standard implementation of async() that blocks on the future-destructor?
by Vicente J. Botet Escriba 18 Oct '15

18 Oct '15

Hi, all is in the title. Best, Vicente

3 5

[Math] Help needed with FreeBSD failures
by John Maddock 18 Oct '15

18 Oct '15

Can anyone familiar with FreeBSD help me figure out what's causing a large number of runtime failures from Boost.Math, for example http://www.boost.org/development/tests/develop/developer/output/Flast-FreeB… Strangely gcc-5.1.0 is fine, but 4.8.5, 5.2.0 and 6.0 all fail. Many thanks in advance, John.

2 4

[serialization] Massive failures in develop?
by John Maddock 18 Oct '15

18 Oct '15

Local testing seems to have badly failed: http://www.boost.org/development/tests/develop/developer/serialization.html I've only looked at the msvc failures, and there's an issue in the iostream class destructor - which is to say after the archive classes have been destructed, the iostream class they were using is left in a non-sane state. Beyond that I haven't been able to get anything sensible out of the debugger (looks like memory corruption actually, but I can't be sure). Any ideas? Thanks, John.

2 6

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

18 Oct '15

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

3 13

[intrusive]: determine the hook type of intrusive::list<>?
by Oliver Kowalke 18 Oct '15

18 Oct '15

I'd like to determine the hook type of an intrusive container (intrusive::list): template< typename List > void do_link( List & lst) { static_assert(std::is_same< typename List::???, my_hook_type >::value); lst.push_back( * this); } In the documentation I didn't found a hint. Oliver

1 0

[regression] New runners for old compilers MSVC-7.1 and GCC 3.4
by Ion Gaztañaga 17 Oct '15

17 Oct '15

Hi, The last compiler update two years ago in Boost 1.55 left MSVC-7.1 and GCC 3.3 as two of the oldest supported compilers: http://www.boost.org/users/history/version_1_55_0.html I have no access to GCC 3.3 but managed to get a Mingw-based GCC 3.4. I will run regressions for for both mingw-GCC-3.4 and msvc-7.1 in master and develop branches in case anyone is interested. I plan to maintain support for them in Move, Intrusive, Container and Interprocess until we reach consensus on a new compiler update. Best, Ion

6 6

[python] Merging pull request #25
by Edward Diener 17 Oct '15

17 Oct '15

The PR is necessary so that user's of Python to not see a deprecated warning coming from the updated type_traits whenever they use Boost python. Would the maintainer of Boost Python please take a look at this simple PR so we can get this in the upcoming release. Thanks !

1 0

[Build] Specify compiler on the command line
by Louis Dionne 17 Oct '15

17 Oct '15

Hi, Still attempting to setup Boost.Build for Hana, I find myself unable to specify the compiler to be used by `b2` on the command line. The system compiler is then used by default, which does not work because I need to test on recent compilers. This can be handled by writing a project-config.jam file with the following in it: import feature ; if ! clang in [ feature.values <toolset> ] { using clang : : /path/to/clang ; } However, this is not very script-friendly, and I wonder whether there's a way to specify it on the command-line instead. Regards, Louis

4 6

[iterator][range] Synchronization on 'master'
by Edward Diener 16 Oct '15

16 Oct '15

I have pushed a number of changes to iterator from 'develop' to 'master' for the next release. A series of these changes on 'develop', by Marcel Raad, is an attempt to remove from 'iterator' the use of the deprecated headers 'boost/iterator.hpp' and 'boost/detail/iterator.hpp' in favor of using 'std::iterator' directly instead of 'boost::iterator' and 'std::iterator_traits' and 'std::distance' directly instead of 'boost::detail::iterator_traits' and 'boost::detail::distance'. Essentially these changes mean that any other library using 'iterator' classes would fail if they attempted to refer to 'boost::iterator', 'boost::detail::iterator_traits', or 'boost::detail::distance'. After I had pushed these changes to 'master' I noticed that it broke 'range' on 'master' and reverted these specific pushed commits on iterator 'master'. On 'develop' the 'range' library ( and possibly other libraries using 'iterator' ) had been changed so that it correctly used the 'std::iterator' terminology rather than the deprecated 'boost::iterator' terminology. If we are going to make this change to 'iterator' on 'master' it needs to be co-ordinated with the same set of changes for other libraries which now work with these changes on 'develop'. I noticed quite a few changes for 'range' on 'develop' which have not been pushed to 'master' for the upcoming release. I will assume that the maintainer of 'range' will want to push these changes to 'master' for the upcoming release so this is a heads up that the changes ( actually the last 'develop' commit for 'range' ) need to be co-ordinated with 'iterator' if it is done. Similarly if any other library depending on 'iterator' needs these changes on 'master' it needs to be co-ordinated with 'iterator'. I will NOT be re-pushing these changes on 'iterator' until this co-ordination is in place as I do not want to break 'master' in the interim. I am also fine with waiting until after this upcoming release to re-push these 'iterator' change to 'master' if that is what is desired by others, but any library currently depending on these changes in 'develop' must be aware of what the decision end up to be.

5 9

[serialization] Test runners being stopped
by Tom Kent 16 Oct '15

16 Oct '15

I think there is a bug in the serialization library that is breaking out of the test harness and causing window's error handling to kick in (when running on Windows, obviously). Usually when this happens the test runner application eventually (I believe) times out the test and marks it as failed. However, there are an incredible number of failures happening (since late last week) and they are bogging down the entire test run. Most of the runs I have attempted in the last week on windows have failed...the ones that have succeeded have taken ~12hrs up from the normal 3-4hrs. I was able to capture a stack trace of one of these random failures: msvcp140d.dll!00007ff9cfffb968() Unknown msvcp140d.dll!00007ff9cff73005() Unknown > test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::_Endwrite() Line 649 C++ test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::close() Line 341 C++ test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::~basic_filebuf<wchar_t,std::char_traits<wchar_t> >() Line 155 C++ test_list_ptrs_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t> >::~basic_ofstream<wchar_t,std::char_traits<wchar_t> >() Line 1068 C++ test_list_ptrs_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t> >::`vbase destructor'() C++ test_list_ptrs_text_warchive.exe!test_list() Line 65 C++ test_list_ptrs_text_warchive.exe!test_main(int __formal, char * * __formal) Line 176 C++ test_list_ptrs_text_warchive.exe!main(int argc, char * * argv) Line 203 C++ [External Code] I'd be happy to help get to the bottom of this, if you can give me any more diagnostic steps to take. We need to resolve this ASAP because it is preventing the windows test runners from producing timely results and we have a release coming up. Thanks, Tom

2 3

[test] BOOST_PP_VARIADICS is defined twice
by Andrey Semashev 16 Oct '15

16 Oct '15

Hi, For some reason Boost.Test defines the BOOST_PP_VARIADICS macro, which, I believe, is a macro defined by Boost.Preprocessor. This results in build errors as can be seen here: http://www.boost.org/development/tests/develop/developer/output/teeks99-01b… I think Boost.Test should not define BOOST_PP_VARIADICS and rely on Boost.PP for that. In any case, BOOST_PP* is not the namespace of Boost.Test.

2 4

[fusion] result_of_with_decltype is missing
by Andrey Semashev 16 Oct '15

16 Oct '15

Hi, I can see many of my tests are failing like this: http://www.boost.org/development/tests/develop/developer/output/teeks99-01b… Basically, it complains that fusion::detail::result_of_with_decltype is missing and indeed I cannot find it defined in Boost.Fusion anywhere.

1 0

Valgrind reports use of uninitialized value in any_range
by Auer, Jens 16 Oct '15

16 Oct '15

Hi, I am using an any_range of std::unique_ptr values in one of my programs. When I analyse this with valgrind, it reports many uninitialized value usages in any_range, and I cannot explain this from my code. I managed to produce a small example to reproduce this. I would like to know if that is a real issue, or if can just create a valgrind suppression rule. #include <iostream> #include <boost/range.hpp> #include <boost/range/any_range.hpp> #include <boost/range/adaptors.hpp> struct Int { Int(int i): x(i) {} int x; }; int main( int argc, char* argv[] ) { typedef boost::any_range<Int*, boost::forward_traversal_tag, Int*, std::ptrdiff_t> R; std::vector<std::unique_ptr<Int>> v; v.push_back( std::make_unique<Int>(42) ); auto f = [](std::unique_ptr<Int> const& p) {return p.get();}; R r = v | boost::adaptors::transformed(f); auto x = (*boost::begin(r))->x; std::cout << x << std::endl; return 0; } Running this, valgrind reports a "Use of uninitialized value of size 8": # g++ --version g++ (GCC) 5.2.0 # g++ -std=c++1y -o test test.cpp # valgrind --version valgrind-3.11.0 # valgrind --track-origins=yes ./test ==8119== Memcheck, a memory error detector ==8119== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==8119== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==8119== Command: ./test ==8119== ==8119== Use of uninitialised value of size 8 ==8119== at 0x4010B8: main (in /tmp/test) ==8119== Uninitialised value was created by a stack allocation ==8119== at 0x40315D: boost::range_detail::any_iterator<Int*, boost::iterators::forward_traversal_tag, Int*, long, boost::any_iterator_buffer<64ul> >::dereference() const (in /tmp/test) ==8119== 42 ==8119== ==8119== HEAP SUMMARY: ==8119== in use at exit: 72,704 bytes in 1 blocks ==8119== total heap usage: 3 allocs, 2 frees, 72,716 bytes allocated ==8119== ==8119== LEAK SUMMARY: ==8119== definitely lost: 0 bytes in 0 blocks ==8119== indirectly lost: 0 bytes in 0 blocks ==8119== possibly lost: 0 bytes in 0 blocks ==8119== still reachable: 72,704 bytes in 1 blocks ==8119== suppressed: 0 bytes in 0 blocks ==8119== Rerun with --leak-check=full to see details of leaked memory ==8119== ==8119== For counts of detected and suppressed errors, rerun with: -v ==8119== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1) Best wishes, Jens PS: I've sent this to boost-users yesterday, but I now think that boost-devel is a better match. -- Dr. Jens Auer | CGI | Software Engineer CGI Deutschland Ltd. & Co. KG Rheinstraße 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer(a)cgi.com Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail.

2 1

Beginner Request for Contributing to Boost Library
by Arafat Khan 16 Oct '15

16 Oct '15

Hi Respected Sir/ Mam, I am Arafat Dad Khan, an undergraduate student at Indian Institute of Technology, Kharagpur. I wish to contribute to the Boost Library (Specifically Graph and Data Structures). I have decent knowledge of Algorithms and Data Structures and have consistently taken part in algorithmic competitions on websites such as Codechef and Spoj(Sphere online Judge ) you can view my profile here http://www.spoj.com/SPOJ/users/adk/ I am very new to open source, And i just need someone to guide me so that i could focus on the right areas to contribute. I am very comfortable with C++ language and learning complicated algorithms is great fun to me. Can anyone please tell me the ways in which i could contribute? If this is not the right place to ask newbie questions please tell me where i could ask the my questions. Thanks Arafat Dad Khan Indian Institute of Technology Kharagpur

4 3

We need a coherent higher level parallelization story for C++ (was [thread] Is there a non-blocking future-destructor?)
by Hartmut Kaiser 16 Oct '15

16 Oct '15

Sorry for cross-posting. > Vicente J. Botet Escriba wrote: > > I have a branch > (https://github.com/boostorg/thread/tree/feature/non_blocking_futures) > that don't blocks on any future, but this will break async. FWIW, the design decision to let those (and only those) futures block on destruction which are returned from async was one of the really bad decisions made for C++11, however that's just my opinion (others agree, but yet others disagree). This flaw essentially caused us to spend many committee hours on discussions how to mitigate the situation, with proposed solutions ranging from 'leave it be as is' to as extreme as 'deprecate it now'. There seems to be a growing consensus however to develop other constructs which eventually could replace async, such as executors, etc. I'm a proponent of following that path. More generally, I strongly believe that we have to come up with a _coherent story_ for all kinds of (higher-level) parallelism in C++: task-based parallelism, asynchronous, continuation style programming, fork-join parallelism of heterogeneous tasks, simple fork-join (iteration based) parallelism, etc. All of this has to go hand in hand with a (orthogonal) vectorization story. We also need to think about integrating GPUs. The goal has to be to make parallelism in C++ independent of any external solutions such as OpenMP, OpenACC, etc. Many of the building blocks for this are already being discussed: executors and executor_traits for customizing the 'how and where' of task execution, executor parameters for grain-size control, and execution policies as the higher level facility allowing to tie everything together (see for instance HPX [7]). We (as a committee) already allow for passing execution policies as the first argument to parallel algorithms (Parallelism TS, N4505 [2]). We already have some facilities for task-based, asynchronous, and continuation style parallelism in place (Concurrency TS, N4501 [3]). We have a paper proposing task_blocks for fork-join parallelism of heterogeneous tasks (N4411 [4]). We have two competing (but converging) efforts for defining an executor concept (N4406 [5], PR0008R0 [6]). We have a (strong) proposal for simplifying continuation based programming (await, PR0057R0 [8]). We have attempts on integrating executors with existing facilities (Boost, HPX). We miss work on parallel ranges. We miss work on integrating data structures with data placement policies in conjunction with executors. We miss work on extending all of this to many-core, distributed, and high-performance computing. Etc. We (as a community) really need a higher level, over-arching approach which ties all of the above together! My plan is to work on a corresponding concept paper by the time of the committee meeting end of February 2016. Our group has outlined our current understanding and a possible approach to this here [1]. I'd like for this to be understood as a seed for a wider discussion. Needless to say, I'd very much like to collaborate on this with anybody interested in joining the effort. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu [1] http://stellar.cct.lsu.edu/pubs/executors_espm2_2015.pdf [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4505.pdf [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4501.html [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4411.pdf [5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4406.pdf [6] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0008r0.pdf [7] http://stellar-group.github.io/hpx/docs/html/hpx/manual/parallel.html [8] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0057r0.pdf

5 10

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

15 Oct '15

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

10 17

Policy for individual library versioning
by Louis Dionne 15 Oct '15

15 Oct '15

Hi, I wonder whether there is a policy for how to version individual Boost libraries. Should individual libraries follow their own versioning scheme, or should they stick to the Boost versioning scheme? For example, Hana is currently in v0.4 and following Semantic Versioning[1]. I am wondering whether I should change Hana's version to 1.60.0 when it will be released with Boost 1.60.0, and from then on follow that versioning scheme (and drop Semantic Versioning, which I'm OK with). Hence, I would bump to 1.61.0 when Boost 1.61.0 is released, and so on. The other option is to stick with my current versioning scheme and simply document the correspondence between Hana vA.B.C and Boost vX.Y.Z. Is there any agreed-upon way to handle this? Regards, Louis [1]: http://semver.org

3 4

1.60 closes for new libraries and breaking changes in a week
by Vladimir Prus 15 Oct '15

15 Oct '15

Folks, the deadline for new libraries and breaking changes for 1.60 is next Wednesday, Oct 21. Please get big changes in by that date. Thanks, Volodya

4 7

Re: [boost] [c++std-parallel-2020] Re: We need a coherent higher level parallelization story for C++ (was [thread] Is there a non-blocking future-destructor?)
by Peter Dimov 14 Oct '15

14 Oct '15

Lawrence Crowl wrote: > First, std::async and std::future have no flaws for what they were > designed to do. They were designed to provide relatively easy parallelism > for small core systems under the fork-join model. I thought that it was well established by now that std::async isn't very useful for fork-join (if at all.) First, it's required to execute each (asynchronous) task as-if in a new thread with respect to thread locals, which in practice means "in a new thread". Second, it has to allocate the future shared state. These two non-flaws kill its performance for fork-join parallelism. The first one is not related to its use of std::future, but the second one is. Given an interface of the form X x; async_result<R> r; std::async( r, [&]{ return x.f(); } ); with async_result being non-copyable and non-movable and ~async_result blocking on the async task, the task can store its result directly into r, without needing to allocate.

1 0

Re: [boost] [c++std-parallel-2020] Re: We need a coherent higher level parallelization story for C++ (was [thread] Is there a non-blocking future-destructor?)
by Peter Dimov 14 Oct '15

14 Oct '15

Lawrence Crowl wrote: > Third, extending the use of std::future beyond its design goals caused > problems. You would expect this of any system used beyond its goals. In > particular, using std::futures for anything other than std::async was a > step too far. This is absolutely backwards. Future was always intended to be used as a generic future value. Hence the name, and the existence of 'promise'. Extending it beyond these design goals in order to imbue it with a lifetime management function caused the problems.

1 0

Test Runner Crashing
by Tom Kent 12 Oct '15

12 Oct '15

Over the weekend I've seen my windows test runner completely crashed (and other OS applications crashed as well), it is preventing the runner from getting through a complete run. I don't really have any idea where it is happening, but I have seen some errors in wserialization throwing up application crashed window...could this be related? Here's the info from the window: Problem signature: Problem Event Name: APPCRASH Application Name: test_non_intrusive_text_warchive.exe Application Version: 0.0.0.0 Application Timestamp: 561b13c0 Fault Module Name: MSVCP120D.dll Fault Module Version: 12.0.21005.1 Fault Module Timestamp: 524f8411 Exception Code: c0000005 Exception Offset: 000000000007c170 OS Version: 6.3.9600.2.0.0.272.7 Locale ID: 1033 Additional Information 1: 4de6 Additional Information 2: 4de60485dd55f55c5bf1ba0ca18762f0 Additional Information 3: 57a7 Additional Information 4: 57a7ea5113dd7a4cdeb1d88e51b65649 Read our privacy statement online: http://go.microsoft.com/fwlink/?linkid=280262 If the online privacy statement is not available, please read our privacy statement offline: C:\Windows\system32\en-US\erofflps.txt Here's the Visual Studio call stack: msvcp120d.dll!00007fff81a4c170() [Frames below may be incorrect and/or missing, no symbols loaded for msvcp120d.dll] msvcp120d.dll!00007fff819d88d2() msvcp120d.dll!00007fff819d9918() msvcp120d.dll!00007fff819e1511() > test_non_intrusive_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::_Endwrite() Line 643 + 0xcf bytes C++ test_non_intrusive_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::close() Line 341 + 0xa bytes C++ test_non_intrusive_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::~basic_filebuf<wchar_t,std::char_traits<wchar_t> >() Line 156 C++ test_non_intrusive_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t> >::~basic_ofstream<wchar_t,std::char_traits<wchar_t> >() Line 1061 + 0x13 bytes C++ test_non_intrusive_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t> >::`vbase destructor'() + 0x1c bytes C++ test_non_intrusive_text_warchive.exe!save(const char * testfile) Line 143 + 0x1b bytes C++ test_non_intrusive_text_warchive.exe!test_main(int __formal, int __formal) Line 169 C++ test_non_intrusive_text_warchive.exe!main(int argc, char * * argv) Line 203 + 0xe bytes C++ test_non_intrusive_text_warchive.exe!__tmainCRTStartup() Line 626 + 0x19 bytes C test_non_intrusive_text_warchive.exe!mainCRTStartup() Line 466 C kernel32.dll!00007fff8f7013d2() ntdll.dll!00007fff91fc5454() Any ideas? Could it be possible that too many application crashes could be taking out the test runner (and other OS applications) completely? Thanks, Tom

1 0

[Hana] Integration with the regression Matrix
by Louis Dionne 12 Oct '15

12 Oct '15

Hi, With the goal of shipping Hana with the next release of Boost, I am currently trying to satisfy the requirement that Hana's testing results show up in the Boost regression matrix. One way to achieve this would be to have Travis CI upload the results on each push to master. To do so, I would need to somehow create an XML file compatible with what the regression matrix expects. That brings up a few questions: (1) Is there a way to upload the result of CMake tests to the Boost regression matrix? I suspect something like that might have already been done as part of the (unfortunately defunct) CMake effort? (2) If not, would it be difficult to implement? Any input on how to best integrate Hana's testing results with the rest of Boost's regression testing will be greatly appreciated. Also, before someone suggests using Boost.Build: I have been looking at the possibility of maintaining a separate Jamfile. However, the need to maintain two separate build systems is annoying, so I'd like to avoid it if possible. I also think that Travis-based testing could provide a better coverage for Hana than the voluntary testers given the need for cutting edge compilers, but I could be wrong. Regards, Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Hana-Integration-with-the-regression-Mat… Sent from the Boost - Dev mailing list archive at Nabble.com.

7 9

[thread] Is there a non-blocking future-destructor?
by Mikael Olenfalk 11 Oct '15

11 Oct '15

Hi, I have stumbled on a minor inconvenience when it comes to using boost::future. Below is a small example which first wraps an asio io_service as an Executor (see even further below) and then uses boost::async() to launch a simple task on the executor and tries to queue up a continuation using future::then(Ex, F): 1. the destructor of async_result does not block which is nice 2. the destructor of continuation_result does block which is a bit of an annoyance as this future I do not care about at all Is there a way to make the destructor not block? /M int main(int argc, char* argv[]) { boost::asio::io_service io_service; asio_executor executor{ io_service }; auto async_result = boost::async(executor, []() { return 42; }); // hangs: // async_result.then(executor, &g); // does not hang: auto continuation_result = async_result.then(executor, [](boost::future<int> r) { cout << r.get() << endl; }); cout << "start io_service" << endl; io_service.run(); cout << "stop io_service" << endl; return 0; } class asio_executor : public boost::executors::executor { public: asio_executor(boost::asio::io_service &ios) : _ios(ios) {} void close() override { _ios.stop(); } bool closed() override { return _ios.stopped(); } void submit(work&& w) override { // for some reason _ios.post(w); causes endless // recursion and eventually a crash _ios.post(std::move(w)); } bool try_executing_one() override { return _ios.run_one() > 0; } private: boost::asio::io_service &_ios; };

2 2

Boost.Fiber mini-review report
by Nat Goodspeed 10 Oct '15

10 Oct '15

The mini-review of Boost.Fiber by Oliver Kowalke ran from Friday September 4th through Sunday September 13th. There was lively discussion, but only two actual reviews: Agustín K-ballo Bergé: not yet (list of issues below) Niall Douglas: yes, plus suggestions (below)[0] In addition I received two "review withheld" notes: Vicente J. Botet Escriba wanted me to address the previous review point by point. That seems like a reasonable request, and I apologize, but I too have time pressures. Giovanni Piero Deretta made suggestions (synopsized below) with the statement that he will make a recommendation when he sees the library author's progress along those lines. While in theory these results might seem like a hung jury, the very paucity of formal reviews supports a cautious approach. The verdict is: not yet, with specific points as noted below. No reviewer explicitly designated specific points as being essential. (Niall Douglas explicitly designated his suggestions as post-adoption enhancements.) I have made an attempt to rank the recommendations received in descending order of importance to the community. My criteria are: Robustness: does lack of this request pose significant risk to a consuming program? API stability: could this request be considered an implementation detail, or would the change break early adopters? Demand: how many people requested the same thing? If you feel that I have misrepresented the importance of one of your points (or omitted something entirely), please respond. Ultimately, of course, the importance of any given point to the community at large will be reflected in the next mini-review. ----------------------------------------------------------------- Requests: Cross-thread fiber migration: Evidently the community strongly desires the ability to transfer a suspended fiber from one thread to another.[1] Of course there must be controls. Migration might be explicit; but if implicit, there must be a way to designate which fibers may and may not be migrated. An RAII class that temporarily disables migration would also be desirable -- for instance, to guarantee TLS consistency for some specific period. Cross-thread migration support implies a requirement to document the thread safety requirements of the customization API. Standard required timing specifications: meet (30.2.4 Timing specifications [thread.req.timing]). Adapt one or more existing test suites for thread facilities to validate the correctness of the Fiber library's synchronization constructs: e.g. from libc++, libstdc++, Boost.Thread, HPX. std::chrono support: ensure that wait_until() can accept any supported time_point specialization. (The library author asserts that this has already been fixed on the 'develop' branch.) C++11 compatibility: Agustín K-ballo Bergé volunteered to help with this point post-adoption. Paul Fultz offered fit::capture to emulate C++14 move capture. Document that this_fiber::yield() (et al.) are valid from main(), or in general from a thread function, as well as from explicitly-launched fibers. Make shared_state lock requirements explicit: for example, make mark_ready_and_notify_() accept a std::unique_lock<>& (or &&) to force its caller to provide one. Avoid holding mutex during condition_variable::notify_*() calls. (The library author asserts that this has already been fixed on the 'develop' branch.) packaged_task must not decay-copy its task arguments. Align fibers::async() signature, result description and invoke_helper implementation with std::async(). Avoid returning std::move(...). Wait list implementation: try an intrusive linked list of fiber_context objects. Avoid sleeping thread when no fibers are ready -- block on external event. Better handling of waiting tasks (decentralized wait queues?). Optimization to resume awakened fiber on the thread that awakens it. Template redundancy: eliminate duplication between specializations for T, T& and void. The future, shared_future, shared_state, promise and task_object templates were specifically cited. Leverage predicate-based condition::wait() overload internally. Nested schedulers: make schedulers be schedulable entities themselves. Improve robustness of `promise' handling in Asynchronous Callbacks documentation. Avoid overconfident remarks about it. Fix Note overstating the requirements on condition_variable::wait(). The discussion also surfaced the desirability of Grand Unified Future Theory, but it was generally agreed that this is out of scope. Put differently, it would be unreasonable to put the onus on Fiber to solve that very broad cross-library problem. Many thanks to all participants, and thanks especially to Oliver Kowalke for all his work on this library! Nat Goodspeed Boost.Fiber Review Manager ________________________________ [0] Niall Douglas snuck his review recommendation into the following mail message: http://lists.boost.org/Archives/boost/2015/09/225228.php (second to final paragraph). His suggestions were in private mail. [1] Giovanni Deretta suggests that it might be possible to allocate -- without actually running -- an actual kernel thread per fiber, simply to give each fiber its own TLS area.

2 1

Boost Library Testing - a modest proposal - was boost.test regression or behavior change (was Re: Boost.lockfree)
by Robert Ramey 10 Oct '15

10 Oct '15

I believe this whole thread started from the changes in Boost.Test such that it can no longer support testing of C++03 compatible libraries. This is totally unrelated to the testing of Boost libraries. Here is what I would like to see: a) local testing by library developers. Of course library developers need this in order to develop and maintain libraries. Currently we have this and has worked quite well for many years. Making Boost.Test require C++11+ throws a monkey wrench into things for the libraries which use it. But that's only temporary. Libraries whose developers feel they need to maintain compatibility with C++98 can move to lightweight test with relatively little effort. Developers who are concerned that the develop branch is a "soup" can easily isolate themselves from this by testing against the master branch of all the other libraries. The Boost modularization system with git has made this very simple and practicle (thank you Beman!). So - not a problem. b) Testing on other platforms. We have a system which has worked pretty well for many years. Still it has some features that I'm not crazy about. i) it doesn't scale well - as boost gets bigger the testing load gets bigger. ii) it tests the develop branch of each library against the develop branch of all the other libraries - hence we have a testing "soup" where a test might show failure but this failure might not be related to the library under test but some other library. It diminishes the utility of the test results in tracking down problems. iii) it relies on volunteer testers to select compilers/platforms to test under. So it's not exhaustive and the selection might not reflect that which people are actually using. I would like to see us encourage our users to test the libaries that they use. This system would work in the following way. a) A user downloads/builds boost. b) he decides he's going to use library X, and Y c) he runs a tool which tells him which libraries he has to test. This would be the result of a dependency analysis. We have tools which do similar dependency analysis but they would have to be slightly enhanced to distinguish between testing, deployment, etc. I don't think this would be a huge undertaking given the work that has already been done. d) he runs the local testing setup on those libraries and their dependents. e) he uploads the test results to a dashboard similar if not identical to the current one. f) we would discourage uses from just using the boost libraries without runnig they're own tests. We would do this by exhortation and by refusing to support users who have been unwilling to run and post local tests. This would give us the following: a) a scalable testing setup which could handle a Boost containing any number of libraries. b) All combinations of libraries/platforms/compilers actually being used would be those being tested and vice versa. We would have complete and efficient test coverage. c) We would have statistics on libraries being used. Something we are sorely lacking now. d) We would be encouraging better software development practices. Sometime ago someone posted that he had a problem but couldn't run the tests because "management" wouldn't allocate the time - and this was a critical human life safety app. He escaped before I could weedle out of him which company he worked. And best of all - We're almost there !!!! we'd only need to: a) enhance slightly the dependency tools we've crafted but aren't actually using. b) develop a tool to post the local results to a common dashboard c) enhance the current dashboard to accept these results. Robert Ramey

3 3

[nowide] Library Updates and Boost's broken UTF-8 codecvt facet
by Artyom Beilis 09 Oct '15

09 Oct '15

Some updated regarding boost.nowide 1. Library moved to github and its format is converted to modular boost layout: https://github.com/artyom-beilis/nowide2. Fixed unsupported std::ios::ate flag by boost::nowide::fstream3. Added some C++11 interfaces to boost::nowide::fstream4. Added integration functionality with boost::filesystem: https://github.com/artyom-beilis/nowide/blob/master/include/boost/nowide/in… And another important update is that I implemented proper utf8 to utf-16/utf-32 codecvt facet https://github.com/artyom-beilis/nowide/blob/master/include/boost/nowide/ut… It implemented as template version working with wchar_t, char16_t and char32_t. Now I explain. There is widely used utf8 codecvt facet in various parts of code: https://github.com/boostorg/detail/blob/master/include/boost/detail/utf8_co… https://github.com/boostorg/detail/blob/master/include/boost/detail/utf8_co… However it is buggy and actually broken for 3 reasons: 1. It supports UCS-2 instead of UTF-16 - i.e it does not code properly Unicode characters outside BMP i.e. code points with values abouve 0xFFFF2. It allows invalid code points in UTF-32/UCS-4 i.e. above 10FFFF or that are reserved for surrogate pairs of UTF-163. And actually allows UTF-8 sequences longer than 4 (which is wrong) As a result, for example you can't use boost::filesystem::path with characters like "𝒞" U+1D49E or may actually create wrong encodings trying to read/write filesystem objects. Independently of Boost.Nowide I would like to propose replacement of boost/detail/utf8_codecvt_facet by one thatactually takes in account proper Unicode handling. Artyom Beilis--------------CppCMS - C++ Web Framework: http://cppcms.com/CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

7 47

[Build] Test file name conflicts
by Louis Dionne 09 Oct '15

09 Oct '15

Hi, While trying to create Jamfiles for Boost.Hana's unit tests, the following situation came up. I have two unit tests in files foo/main.cpp bar/main.cpp Then, my Jamfile.v2 contains the following: import testing ; test-suite xxx : [ run foo/main.cpp ] [ run bar/main.cpp ] ; When I run `b2`, I get the following: error: No best alternative for ./main next alternative: required properties: (empty) matched next alternative: required properties: (empty) matched error: No best alternative for ./main next alternative: required properties: (empty) matched next alternative: required properties: (empty) matched I think the problem is that Boost.Build tries to create two executables named `main` in the same directory, which obviously causes a name conflict. Is there any way to avoid this, besides renaming the test files? Regards, Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Build-Test-file-name-conflicts-tp4680806… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

Boost.lockfree
by Aparna Kumta 09 Oct '15

09 Oct '15

All tests for lockfree in both master and develop branch seem to fail. Error message is "../boost/system/config.hpp", line 34: Error: #error Must not define both BOOST_SYSTEM_DYN_LINK and BOOST_SYSTEM_STATIC_LINK. See develop branch: http://www.boost.org/development/tests/develop/developer/lockfree.html See master branch: http://www.boost.org/development/tests/master/developer/lockfree.html I looked at lockfree/test/Jamfile.v2 but am not sure what change needs to be made. Any suggestions? Thanks, Aparna

17 51

[Test] breaking changes in test invocation
by Jürgen Hunold 09 Oct '15

09 Oct '15

Hi, it seems that commit c0d2d29284389a1e7f924583ff6bd59128b9436b Author: Gennadiy Rozental <rogeeff(a)gmail.com> Date: Thu Oct 1 03:38:44 2015 -0400 -- is required before extra test module arguments has at least broken my Boost.Build driven tests, as I now get: Usage: my_test-clang38 [Boost.Test argument]... -- [custom test module argument]... For detailed help on Boost.Test parameters use: my_test-clang38 --help or my_test-clang38 --help=<parameter name> for every test which has extra command line arguments. I strongly suspect this breaks some libraries in Boost itself which e.g. need to read some input files. Right now I'm lost at how to fix this in Boost.Build's testing.jam as it seems we somehow have to specify different arg sets. And how to get "--" into the commandline at all. And in the light of the ongoing c++11/03 discussion it would have been nice to issue a warning before commiting breaking and/or behavioural changes. Any ideas? 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

3 6

[Date_time] Adding Input Format Flag Parsers
by Yucheng Low 08 Oct '15

08 Oct '15

Hi, Boost date_time is missing a bunch of format flag parsers on input (%I,%l, %P, %p). Here is a proposed patch to add these format flags. Thanks, Yucheng

1 0

[regression] new runner missing in master results
by Ion Gaztañaga 08 Oct '15

08 Oct '15

Hi, Since MSVC-7.1 is (in theory) supported by Boost and we had no regressions on that platform, I've set up an old computer to do the job. I've executed regression tests several times and results appear in develop branch's result page but they are always missing in master branch. Logs indicate that executions and uploading were correct. Eg.: Runner "igaztanaga" present in develop: http://www.boost.org/development/tests/develop/developer/move.html Runner "igaztanaga" missing in develop: http://www.boost.org/development/tests/master/developer/move.html Any hint on what could be the problem? Ion

3 6

Boost.test failures in develop
by Aparna Kumta 08 Oct '15

08 Oct '15

Compiling with Oracle Solaris Studio on sparc-S2 platform with -library=stlport4, I see the following failure in the develop branch: "CC" -library=stlport4 -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_TEST_DYN_LINK=1 -DBOOST_TIMER_DYN_LINK=1 -DNDEBUG -D__typeof__=__typeof__ -I".." -c -o "/export/home/b_dev/results/boost/bin.v2/libs/test/build/sun/release/stdlib-sun-stlport/threading-multi/unit_test_parameters.o" "../libs/test/src/unit_test_parameters.cpp" "../boost/test/utils/runtime/errors.hpp", line 75: Error: Templates can only declare classes or functions. "../boost/test/utils/runtime/errors.hpp", line 86: Error: Templates can only declare classes or functions. "../boost/test/utils/runtime/errors.hpp", line 124: Error: ")" expected instead of "&&". "../boost/test/utils/runtime/errors.hpp", line 133: Error: ")" expected instead of "&&". "../boost/test/utils/named_params.hpp", line 69: Error: Unexpected type name "Rest" encountered. "../boost/test/utils/named_params.hpp", line 69: Error: Unexpected ":" found. "../boost/test/utils/named_params.hpp", line 205: Error: Unexpected type name "Rest" encountered. "../boost/test/utils/named_params.hpp", line 205: Error: operator, is not defined. "../boost/test/utils/named_params.hpp", line 205: Error: "," expected instead of ";". ... Compilation aborted, too many Error messages. It seems that the code contains rvalue reference and hence the compiler is not able to build it in C++03 mode. This seems to be a recent change preventing building of libboost_unit_test_framework.a and hence causing several tests to fail. Thanks, Aparna

12 33

git reset and force push
by Raffi Enficiaud 08 Oct '15

08 Oct '15

Hi all, Is there any policy wrt. reseting a branch master/develop and force pushing? The side question is to know if the boost git tools (the bot for submodules) can cope with those operations. Thanks, Raffi

9 38

[serialization] static_warning.hpp seems behind boost/config
by Alain Miniussi 07 Oct '15

07 Oct '15

Hi, It seems that BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE has been replaced by BOOST_ATTRIBUTE_UNUSED in boost config. But static_warning.hpp is still using the old macro on master (while it is fixed on develop). On master: #define BOOST_SERIALIZATION_BSW(B, L) \ typedef boost::serialization::BOOST_SERIALIZATION_SS< \ sizeof( boost::serialization::static_warning_test< B, L > ) \ > BOOST_JOIN(STATIC_WARNING_LINE, L) BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE; On develop: #define BOOST_SERIALIZATION_BSW(B, L) \ typedef boost::serialization::BOOST_SERIALIZATION_SS< \ sizeof( boost::serialization::static_warning_test< B, L > ) \ > BOOST_JOIN(STATIC_WARNING_LINE, L) BOOST_ATTRIBUTE_UNUSED; Could someone move the fix from develop to master to keep in synch with boost/config ? It is preventing some tests to pass in mpi. Thanks -- --- Alain

2 2

Boost.Filesystem for Universal Windows (windows-api=store)
by Mikael Olenfalk 06 Oct '15

06 Oct '15

Hi, I made a first attempt at getting Boost.Filesystem to run on the Universal Windows Platform (Windows 10). I intend to do more testing of it before it is ready to be merged but I would very much appreciate a quick and dirty review already. If somebody could take a look I would be a very happy guy. https://github.com/boostorg/filesystem/pull/18 I am working on some more libraries in the hopes that I can finish off most libs in the next couple of week, but I cannot promise anything. To compile for windows store, just add "windows-api=store" to your b2 invocation. Regards, /M

3 11

Request for review: Boost.Fit
by paul Fultz 06 Oct '15

06 Oct '15

Hi All, Boost.Fit is a header-only function utility library for C++11. It supports both gcc, clang and visual studio. More info can be found here: https://github.com/pfultz2/Fit I would like to take this time to ask for a review. Vicente Botet has mentioned he could be a review manager. So I would like to move forward in scheduling a formal review. I plan to boostify the library for the formal review. In addition, I would like to ask for an informal review at this time. If anyone has some feedback or questions, that would be greatly appreciated. Thanks, Paul

6 10

Boost.GSL?
by David Sankel 05 Oct '15

05 Oct '15

As you may or may not know, Bjarne Stroustrup, Herb Sutter, and others have announced a new set of C++ guidelines[1] and an accompanying library[2] that supports them. For many folks, it would be difficult to incorporate a new library into their organizations, but there is a strong desire to make use of the guidelines. I floated the idea of including GSL in Boost as a distribution mechanism to Bjarne and he said he doesn't have any objection to the idea in principle, although he is hesitant to having to go through an extensive review process where some of these basic structures would change. What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library? -- David Sankel [1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md [2] https://github.com/Microsoft/GSL

9 16

Re: [boost] boost.test regression or behavior change (was Re: Boost.lockfree)
by Brian Wood 04 Oct '15

04 Oct '15

Bjorn Reese writes >On 10/04/2015 12:18 PM, Gennadiy Rozental wrote: > >> Sooner rather than later we should have this discussion and setup timeline. >> IMO it had very little sense to continue to maintain c++03 workarounds. >> Boost code should be an example how modern c++ libraries should look like. >> And c++03 compatibility is directly in a way of this goal. > > You appear to have missed the many discussions on this topic. > > While Boost started out to design cutting-edge libraries, it has been > caught by its own success. Today there is a large user-base that still > uses C++03, and that are unlikely to upgrade in the foreseeable future. > > Therefore, the current consensus is that existing libraries should not > increase their standards requirements. New libraries are free to decide > their standards requirements (although it will probably be questioned > during a formal review.) > Support for that is dwindling as more projects adopt 2011 or newer versions of C++. I understand Gennadiy and Raffi's desire to discuss this issue again. C++ 2011 is required to use my software. That decision was also based on limited resources and the belief that C++ 2011 had some helpful things for on line code generation. If I had more resources, I could support C++ 2003, but at this point I'm happy to not have to support that. As time goes on, more people are using C++ 2011 or newer. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

Boost perf tests?
by Stephan T. Lavavej 03 Oct '15

03 Oct '15

Hi Boost devs, Does Boost have any runtime perf tests? We (MSVC) are looking for something that uses modern C++, which would reveal areas where our optimizer and libraries could be improved. I looked around briefly, but didn't find anything. Thanks, STL

6 6

[optional] Specializing optional to save space
by David Stone 03 Oct '15

03 Oct '15

Andrzej posted another thread about creating a new compact_optional class. The goal of this class is to make it easy to create a new optional type with a special sentinel value. This allows easy customization per instance of an optional value. This post is about the opposite approach: making it easier to specialize optional to provide special behavior for all instances of a given optional type. When I bring this up, people often compare it to the vector<bool> specialization, but this is a completely different issue. The problem of vector<bool> is that it does not actually store a bool anywhere, so it cannot return a reference to one. This would still store a T somewhere. For the rest of the discussion, I will be assuming a typical standard library implementation on a 64-bit system. Whenever I talk about specific sizes of objects, mentally insert "on most common systems". The principles apply generally. Consider the case of optional<std::string>. Using the naive implementation, this object is 8 bytes larger than std::string, due to alignment requirements. However, there are certain representations of std::string that are not actually possible. For instance, for common implementations of std::string you cannot have std::string::size() == std::numeric_limits<std::string::size_type>::max() *. We can take advantage of this if our std::string implementation stores the capacity as an integer value, rather than a pointer to the end of the storage. Therefore, we could have implementations that look something like this: class string { friend optional<string>; }; template<> class optional<std::string> { optional(none_t) { // Use friendship to just set capacity to sentinel value } explicit operator bool() const { return m_data.capacity() == std::numeric_limits<std::string::size_type>::max(); } }; optional<std::string> still stores std::string in it, so operator*() works just fine. The initialized check is still just comparing a field against a compile-time constant. This makes this purely a space optimization that cannot be detected by the user, unless they use sizeof(optional<std::string>). I believe all of this is possible today with the current specification of boost::optional (and would definitely be allowed for the proposed std::experimental::optional). However, this requires the creator of each specialization to implement the full optional interface. What's more, it is especially tricky to specialize optional for a class template when you only want to specialize on certain specializations of the class template. My use case for this is my bounded::integer library. This library lets you specify the bounds of your integer as template parameters. If your bounded::integer has a narrower range than its underlying integer, you can take advantage of this to make a more space-efficient optional. If, however, the bounded::integer min and max are equal to that of the underlying type, there is no extra space and we want the default optional implementation. With the current specialization approach, it is the responsibility of the specializer to reimplement all of optional. A better approach to easily support this space optimization is as follows: optional contains an instance of optional_storage<value_type>. optional_storage has a much narrower interface: * optional_storage() leaves it uninitialized * optional_storage(in_place_t, T && ...) constructs the value directly with the variadic arguments * emplace(T && ...) constructs an object when there may be one in existence already * reset() destroys the contained object and sets the storage to uninitialized * is_initialized() says whether the contained object is initialized. This could be replaced with explicit operator bool(); I have no preference. * value() returns a reference to the value We need both the constructor and the emplace function to allow literal optional types. This is because for the general case, emplace calls placement new, which is not allowed in a constexpr function. This solves the problem of specializers having to implement the entire interface of optional just to change how the uninitialized state is stored. However, it still does not solve the problem I mentioned earlier about allowing easy use of the default storage policy for some specializations of your own class template. To solve that, we need one more class: default_optional_storage. default_optional_storage<T> is a literal type if T is a literal type (in practice, std::is_trivially_destructible<T>::value is all you really need to test). It implements the same interface as optional_storage<T>. The default implementation of optional_storage<T> is template<typename T> struct optional_storage : default_optional_storage<T> { private: using base = default_optional_storage<T>; public: using base::base; }; This means that the optional library would have at least three classes in its public interface: * optional * optional_storage * default_optional_storage To see a working example of this (including a specialization for bounded::integer), see https://bitbucket.org/davidstone/bounded_integer/src/2defec41add2079ba023c2… https://bitbucket.org/davidstone/bounded_integer/src/2defec41add2079ba023c2… * The reason is that std::string::size_type is a typedef for std::size_t, which is equivalent in range to std::uint64_t. However, std::iterator_traits<std::string::iterator>::difference_type is std::ptrdiff_t, which is equivalent in range to std::int64_t. This means that for the largest std::string, std::distance(begin(), end()) cannot be more than std::numeric_limits<std::ptrdiff_t>::max(), which is less than std::numeric_limits<std::size_t>::max().

6 15

[type_traits] common_type errors with Oracle compiler
by Andrey Semashev 03 Oct '15

03 Oct '15

Hi, Both oracle-intel-S2-next-cpp11 and oracle-sparc-S2-next-stlport4 testers fail to compile common_type as it is being used in Boost.Chrono. This in turn affects compilation of Boost.Thread and multiple other library tests. The error can be seen here: http://www.boost.org/development/tests/develop/developer/output/oracle-inte… Just in case if the test results go down, I'm copying the error inline below. Could it be fixed? "CC" -std=c++11 -temp=/tmp/bn -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DNDEBUG -D__typeof__=__typeof__ -I".." -c -o "/export/home/sstrunk-tester/boost_regression/boost_regression_develop/boost_intel-S2_cpp11/results/boost/bin.v2/libs/atomic/test/atomicity.test/sun-next_cpp11/release/threading-multi/atomicity.o" "../libs/atomic/test/atomicity.cpp" "../boost/chrono/duration.hpp", line 405: Error: type is not a member of boost::common_type<long long, long long>. "../boost/thread/pthread/timespec.hpp", line 52: Where: While specializing "boost::common_type<boost::chrono::duration<long long, boost::ratio<1, 1000000000>>, boost::chrono::duration<long long, boost::ratio<1, 1>>>". "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from boost::chrono::operator-<Rep1, Period1, Rep2, Period2>(const duration<Rep1, Period1>&, const duration<Rep2, Period2>&). "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from non-template code. "../boost/chrono/duration.hpp", line 406: Error: A declaration does not specify a tag or an identifier. "../boost/thread/pthread/timespec.hpp", line 52: Where: While specializing "boost::common_type<boost::chrono::duration<long long, boost::ratio<1, 1000000000>>, boost::chrono::duration<long long, boost::ratio<1, 1>>>". "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from boost::chrono::operator-<Rep1, Period1, Rep2, Period2>(const duration<Rep1, Period1>&, const duration<Rep2, Period2>&). "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from non-template code. "../boost/chrono/duration.hpp", line 406: Error: Use ";" to terminate declarations. "../boost/thread/pthread/timespec.hpp", line 52: Where: While specializing "boost::common_type<boost::chrono::duration<long long, boost::ratio<1, 1000000000>>, boost::chrono::duration<long long, boost::ratio<1, 1>>>". "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from boost::chrono::operator-<Rep1, Period1, Rep2, Period2>(const duration<Rep1, Period1>&, const duration<Rep2, Period2>&). "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from non-template code. "../boost/chrono/duration.hpp", line 406: Error: "}" expected instead of ">". "../boost/thread/pthread/timespec.hpp", line 52: Where: While specializing "boost::common_type<boost::chrono::duration<long long, boost::ratio<1, 1000000000>>, boost::chrono::duration<long long, boost::ratio<1, 1>>>". "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from boost::chrono::operator-<Rep1, Period1, Rep2, Period2>(const duration<Rep1, Period1>&, const duration<Rep2, Period2>&). "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from non-template code. "../boost/thread/pthread/timespec.hpp", line 52: Error: The operation "const boost::chrono::duration<long long, boost::ratio<1, 1000000000>> - boost::chrono::duration<long long, boost::ratio<1, 1>>" is illegal. 5 Error(s) detected.

3 4

Compiler warnings after boost update
by Auer, Jens 03 Oct '15

03 Oct '15

Hi, we compile with high compiler warnings setting (-Wall, -Wpedantic), and treat compiler warnings as errors. Recently, I had to upgrade the boost library version from 1.53 to at least 1.55. Since there was no package available, I compiled it by hand from the source code. With 1.53, everything compiled fine, but with the newer version my builds now break because the boost library generates a lot of warnings, e.g. /cots/boost-1.55/include/boost/iterator/iterator_concepts.hpp: At global scope: /cots/boost-1.55/include/boost/mpl/assert.hpp:288:54: error: use of old-style cast [-Werror=old-style-cast] boost::mpl::assert_arg( (void (*) pred)0, 1 ) \ ^ /cots/boost-1.55/include/boost/mpl/assert.hpp:59:58: note: in definition of macro ‘BOOST_MPL_AUX_ASSERT_CONSTANT’ # define BOOST_MPL_AUX_ASSERT_CONSTANT(T, expr) enum { expr } /cots/boost-1.55/include/boost/range/algorithm/equal.hpp: In function ‘bool boost::range::equal(const SinglePassRange1&, const SinglePassRange2&, BinaryPredicate)’: /cots/boost-1.55/include/boost/concept/detail/general.hpp:71:20: error: typedef ‘boost_concept_check185’ locally defined but not used [-Werror=unused-local-typedefs] BOOST_PP_CAT(boost_concept_check,__LINE__) /cots/boost-1.55/include/boost/property_tree/xml_parser.hpp:52:59: required from ‘void boost::property_tree::xml_parser::read_xml(std::basic_istream<typename Ptree::key_type::value_type>&, Ptree&, int) [with Ptree = boost::property_tree::basic_ptree<std::basic_string<char>, std::basic_string<char> >; typename Ptree::key_type::value_type = char; typename Ptree::key_type::value_type = char]’ /home/auerj/MDAF/src/commons/src/crypto/KeyFileReader.cpp:43:34: required from here /cots/boost-1.55/include/boost/property_tree/detail/rapidxml.hpp:1204:33: error: zero as null pointer constant [-Werror=zero-as-null-pointer-constant] if (first_attribute()) ^ /cots/boost-1.55/include/boost/property_tree/detail/rapidxml.hpp:1204:33: error: zero as null pointer constant [-Werror=zero-as-null-pointer-constant] /cots/boost-1.55/include/boost/property_tree/detail/rapidxml.hpp:1211:45: error: zero as null pointer constant [-Werror=zero-as-null-pointer-constant] These are just some examples, there are literally hundreds of warnings. It is enough to just include ptree.hpp, but other headers have the same issue. I am wondering why this came up after the update. Is it a configuration problem during the build of the boost libraries, or is it an issue in the boost libraries? I find it hard to believe that the code quality changed so much between the versions. What is the policy of the boost project concerning compiler warnings in installation headers? I would assume that the libraries should compile without warnings on supported compilers, either because there are no issues, or because warnings are disabled in the boost headers. Best wishes, Jens -- Jens Auer | CGI | Software-Engineer CGI (Germany) GmbH & Co. KG Rheinstraße 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer(a)cgi.com<mailto:jens.auer@cgi.com> Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben<http://de.cgi.com/pflichtangaben>. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail.

10 14

[build][regression] Problems when trying to run automated regression tests for MSVC-7.1
by Ion Gaztañaga 03 Oct '15

03 Oct '15

Hi, Since Boost 1.55 minimum requirements include Visual C++ 2003. Since currently there is no regression report for this compiler, I'm trying to follow the steps detailed here and try to fill the gap: http://www.boost.org/development/running_regression_tests.html All the source code is downloaded, my user-config.jam only contains "using msvc ;" but it seems that Boost.Build continues to be broken for MSVC-7.1: <output> notice: Loading user-config configuration file 'user-config.jam' from 'C:/Users/igaztanaga'. notice: [msvc-cfg] msvc-7.1 detected, command: 'C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe' notice: will use 'C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe' for msvc, condition <toolset>msvc-7.1 C:/boost/develop/boost_bb/src/tools\msvc.jam:1072: in configure-really *** argument error * rule generate-setup-cmd ( version : command : parent : options * : cpu : global-setup : default-global-setup-options : default-setup ) * called with: ( 7.1 : C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin : C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7 : <command>C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe : i386 : : x86 : vcvars32.bat ) * missing argument global-setup C:/boost/develop/boost_bb/src/tools\msvc.jam:798:see definition of rule 'generate-setup-cmd' being called C:/boost/develop/boost_bb/src/tools\msvc.jam:201: in configure C:/boost/develop/boost_bb/src/tools\msvc.jam:153: in msvc.init C:/boost/develop/boost_bb/src/build\toolset.jam:43: in using C:\Users\igaztanaga\user-config.jam:49: in modules.load c:/boost/develop/boost_bb/src\build-system.jam:249: in load-config c:/boost/develop/boost_bb/src\build-system.jam:389: in load-configuration-files c:/boost/develop/boost_bb/src\build-system.jam:524: in load C:\boost\develop\boost_bb\src/kernel\modules.jam:295: in import C:\boost\develop\boost_bb\src/kernel/bootstrap.jam:139: in boost-build C:\boost\develop\boost_regression\boost-build.jam:57: in module scope </output> I can't figure out what's wrong in msvc.jam. Comments on that file suggest that MSVC-7.1 should be supported although it seems that since MSVC-8.0 the configuration script architecture changed. I'd be glad if any Boost.Build expert could have a look at this issue. Many thanks, Ion PS: Full output for command... python run.py --runner=igaztanaga --toolsets=msvc-7.1 --tag=develop --incremental --libraries=move --have-source > output.txt ...attached.

2 4

compact_optional -- prompting interest
by Andrzej Krzemienski 02 Oct '15

02 Oct '15

Hi Everyone, I would like to inquire if there would be an interest in Boost in another library for storing optional objects, but working under different design goals. Compact optional T has (or can have) the same sizeof as T. It uses one indicated value of T to represent the "empty" (or "singular") value. You can declare it like this: compact_optional<evp_int<int, -1>> oi; This reads: we have an optional int, with type int inside, where -1 represents the empty value. It can never have a genuine (non-empty value -1). This can be used, for instance, to wrap the std::string::npos into: compact_optional<evp_int<string::size_type, string::npos>> With the same memory layout as std::string::size_type, but with the special syntax for managing the singular value. It is not meant to be an alternative to Boost.Optional: it targets a different application space. The (single-header) implementation is at: https://github.com/akrzemi1/compact_optional The documentation is at: https://github.com/akrzemi1/compact_optional/blob/master/documentation.md For the motivation and design rationale see this article: https://akrzemi1.wordpress.com/2015/07/15/efficient-optional-values/ Any feedback is welcome. Regards, &rzej

17 43

[build] Issue with -- argument
by Gennadiy Rozental 01 Oct '15

01 Oct '15

Hi, Due to the change in Boost.Test parameter handling I needed update Boost.Test Jamfile, since I was passing baseline pattern file names as arguments to the test module. Here is snippet from my Jamfile: return [ $(test-rule) $(source_files) ../build//$(usage-variant) $(extra-libs) : -- <============= Note: I added '--' : $(pattern_file) ... Unfortunately -- disappears for some reason from command line. I found that the following works: return [ $(test-rule) $(source_files) ../build//$(usage-variant) $(extra-libs) : -- "" <============= Note "" : $(pattern_file) ... Can we fix it so that "" is not required? Is there a different workaround? Gennadiy

1 0

Re: [boost] [regression] Tests for 'develop' not showing
by Tom Kent 30 Sep '15

30 Sep '15

On Wed, Sep 23, 2015 at 8:16 AM, Tom Kent <lists(a)teeks99.com> wrote: > > On Tue, Sep 22, 2015 at 9:53 PM, Rene Rivera <grafikrobot(a)gmail.com> > wrote: >> >> > On Wed, Sep 9, 2015 at 4:35 PM Edward Diener <eldiener(a)tropicsoft.com> >>>> > wrote: >>>> > >>>> > > Trying >>>> > > >>>> http://www.boost.org/development/tests/develop/developer/summary.html I >>>> > > get: >>>> > > >>>> > > "Error extracting file: The specified zipfile was not found." >>>> > > >>>> >>>> And they are messed up again. Tom can you look into your side of this? >> When I generated the results I got the ZIP files to be 1.5GiB and 2.0GiB, >> approximately, for develop and master, respectively. Yet what I see on the >> web site now is 1.5GiB and 200MiB. Which is clearly incorrect. And it's >> precisely the shorter ZIP, i.e. master.zip, that now doesn't work. I.e >> browsing develop results works, but not browsing master results. >> > > Over the last week I've seen both the master and develop results showing > the zip error message. > > I just noticed that in the last master run, I had a segfault in the > processing: > > tomkent@eddie:~/tmp/boost_reports/boost-reports⟫ tail master.log > Reading failures markup > Reading > /home/tomkent/tmp/boost_reports/boost-reports/master/incoming/master/processed/BP > x86_64 C++11.xml > Merging expected results > Generating links pages > Reading > /home/tomkent/tmp/boost_reports/boost-reports/master/incoming/master/processed/CrystaX.NET-apilevel-19-armeabi-v7a-hard.xml > Merging expected results > Generating links pages > Reading > /home/tomkent/tmp/boost_reports/boost-reports/master/incoming/master/processed/CrystaX.NET-apilevel-19-armeabi-v7a.xml > Merging expected results > Segmentation fault (core dumped) > > I'll look into it more tonight. > Tom > It looks like running the reports (esp master) is taking much longer...up to 2hrs. I had a cron job running every hour, which corrupted things when it was kicked off a second time while the first was still running. I've made a change in the script to setup a lock file, so that only one instance will run and submitted a pull request against the regression repo. It's already running on my report generator, so hopefully the problem won't show up again. If anyone sees it please let me know. Tom

4 6

[git] Testing and Pushing updates to library
by Artyom Beilis 30 Sep '15

30 Sep '15

Hello, I'm back to Boost after my last commits were in svn and now I need to make sure I do stuff correctly in git/github. In boost-svn there were trunk for development and release for up-to date release, currently master is what "release branch" is svn was and develop is what trunk? Q: Is it correct. I have several fixes - I pushed them to master branch of Boost.Locale library. https://github.com/boostorg/locale/compare/26482aa844...ea55386441 I did same for develop (I hope correctly) Q: Is pushing changes to master it enough to get them into next boost release? I had some strange behavior of "detached Head" so I needed to create small temporary local branch and than merge it to master... Q: is it normal? Can't I commit/push directly to master without temporary branch? Testing - in svn there were regression tests for both release and trunk branches of svn... Q: What happens now with regression tests I cound't find the information in the wiki. Thanks. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

2 1

how to pass -std=c++14 to b2 while building boost libraries
by Frédéric Bron 30 Sep '15

30 Sep '15

Hi, I would like to build a c++14 version of boost libraries on my system. I have the intel compiler (15.0.3) on a x86_64 linux machine (2.6.32-279.19.1.el6.x86_64). I do the following: 1. build b2 CC="icc" CFLAGS="-O2 -DNDEBUG -xhost" CXX="icpc" CXXFLAGS="-O2 -DNDEBUG -xhost -std=c++14" AR="ar" AS="as" RANLIB="ranlib" ./bootstrap.sh --without-icu --prefix=/myusr/icc-15.0.3-c++14-release/boost --with-toolset=intel-linux 2. edit user-config.jam My user-config.jam, located in the boost source directory contains: using intel-linux : : icpc : <compilerflags>-xhost <compilerflags>-std=c++14 ; 3. run b2 ./b2 -d2 -j16 -sBZIP2_INCLUDE=/myusr/icc-15.0.3-c++14-release/bzip2/include -sBZIP2_LIBPATH=/myusr/icc-15.0.3-c++14-release/bzip2/lib -sZLIB_INCLUDE=/myusr/icc-15.0.3-c++14-release/zlib/include -sZLIB_LIBPATH=/myusr/icc-15.0.3-c++14-release/zlib/lib --layout=system --user-config=user-config.jam --without-mpi --without-python --without-context --without-coroutine link=static threading=multi runtime-link=shared target-os=linux address-model=64 variant=release install The problem I see is that the flag -std=c++14 is not passed to the compiler. For example, this is an output of b2: "icpc" -c -xc++ -w1 -inline-level=2 -O3 -ip -pthread -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/filesystem/build/intel-linux/release/link-static/threading-multi/codecvt_error_category.o" "libs/filesystem/src/codecvt_error_category.cpp" no trace of -std=c++14 flag. How can I send that flag to the compiler? Apparently, the problem is the same when using g++ 5.2.0. Frédéric

2 2

[boost.build] broken link
by Frédéric Bron 30 Sep '15

30 Sep '15

On this page: http://www.boost.org/doc/libs/1_59_0/tools/build/index.html the link to the documentation is broken: http://www.boost.org/doc/libs/1_59_0/tools/build/doc/html/index.html error message: 404 Not Found File "/home/www/live.boost.org/common/code/../../doc/archives/boost_1_59_0/tools/build/doc/html/index.html" not found. Unable to find file. Cheers, Frédéric

2 1

develop tests
by Robert Ramey 29 Sep '15

29 Sep '15

When I try to look at the tests of the develop branch at http://www.boost.org/development/tests/develop/developer/serialization.html I get an error message. Has this been resolved yet? Is there anything I have to do? Robert Ramey

1 0

Variadics bug in MSVC-12.0
by Gennadiy Rozental 29 Sep '15

29 Sep '15

Hi, While working on improving of implementation of data driven tests, I found rather annoying bug in MSVC-12.0 with variadic templates. The code seems to work fine with msvc-14.0, gcc 4.8 and clang 3.4. I did not try msvc- 13.0. Does anyone know a workaround? Example follows (try to comment on/off line: auto const& t3). Gennadiy // C++ 14 index_sequence template <std::size_t... Ns> struct index_sequence {}; template<typename IS1, typename IS2> struct merge_index_sequence; template <std::size_t... Ns1, std::size_t... Ns2> struct merge_index_sequence<index_sequence<Ns1...>, index_sequence<Ns2...>> { typedef index_sequence<Ns1..., Ns2...> type; }; template <std::size_t B, std::size_t E, typename Enabler = void> struct make_index_sequence { typedef typename merge_index_sequence< typename make_index_sequence<B, (B + E)/2>::type, typename make_index_sequence<(B + E)/2, E>::type>::type type; }; template <std::size_t B, std::size_t E> struct make_index_sequence<B, E, typename std::enable_if<E == B + 1, void>::type> { typedef index_sequence<B> type; }; template <typename... T> using index_sequence_for = typename make_index_sequence<0, sizeof...(T)>::type; ////////////////////////////////////////////////////////////////////////// template<typename T1, typename T2> struct merged_tuple { typedef std::tuple<T1,T2> type; typedef std::tuple<T1 const&,T2 const&> ref; }; template<typename T1, typename ...T> struct merged_tuple<T1, std::tuple<T...>> { typedef std::tuple<T1, T...> type; typedef std::tuple<T1 const&, T const&...> ref; }; template<typename ...T, typename T1> struct merged_tuple<std::tuple<T...>, T1> { typedef std::tuple<T..., T1> type; typedef std::tuple<T const&..., T1 const&> ref; }; template<typename ...T1, typename ...T2> struct merged_tuple<std::tuple<T1...>, std::tuple<T2...>> { typedef std::tuple<T1..., T2...> type; typedef std::tuple<T1 const&..., T2 const&...> ref; }; template<typename ...T1, typename ...T2, std::size_t ...I1, std::size_t ...I2> inline typename merged_tuple<std::tuple<T1...>, std::tuple<T2...>>::ref tuple_merge_impl( std::tuple<T1 const&...> const& a1, std::tuple<T2 const&...> const& a2, index_sequence<I1...> const& , index_sequence<I2...> const& ) { using ref_type = typename merged_tuple<std::tuple<T1...>, std::tuple<T2...>>::ref; return ref_type( std::get<I1>(a1)..., std::get<I2>(a2)... ); } template<typename ...T1, typename ...T2> inline typename merged_tuple<std::tuple<T1...>, std::tuple<T2...>>::ref tuple_merge_impl( std::tuple<T1 const&...> const& a1, std::tuple<T2 const&...> const& a2 ) { return tuple_merge_impl( a1, a2, index_sequence_for<T1...>{}, index_sequence_for<T2...>{} ); } template<typename T> inline std::tuple<T const&> as_tuple( T const& arg ) { return std::tuple<T const&>( arg ); } template<typename ...T> inline std::tuple<T...> const& as_tuple( std::tuple<T...> const& arg ) { return arg; } template<typename T1, typename T2> inline typename merged_tuple<T1, T2>::ref tuple_merge( T1 const& a1, T2 const& a2 ) { return tuple_merge_impl( as_tuple( a1 ), as_tuple( a2 ) ); } int main() { auto const& t1 = tuple_merge( 1, 2 ); auto const& t2 = tuple_merge( 3, 4 ); auto const& t3 = tuple_merge( t1, 5 ); auto const& t4 = tuple_merge( 6, t2 ); return 0; }

1 0

Boost.Test: runtime parameter framework update
by Gennadiy Rozental 29 Sep '15

29 Sep '15

Hi, Over the years there were complains about the interface and functionality of the Boost.Test Unit Test Framework(UTF)'s runtime parameters. Primarily command line arguments handling, but also documentation and few other concerns. This update addresses all these issues, introduces few new features and makes runtime parameters much more user friendly. In addition new implementation significantly simpler. Here is short summary of fixed issues and significant new features: * (new) UTF now requires all user defined arguments to follow UTF specific arguments. They are separated by "--" marker. For example: test.exe --random -- /myarg:17 * (bug) UTF now properly supports arguments with spaces. For example: test.exe --log_sink="file name.txt" * (bug) UTF now reports missing value in arguments. For example: test.exe --log_sink=, produces: Missing an argument value for the parameter log_level in the argument -- log_level= * (bug/new) UTF now reports invalid parameters. Moreover, UTF now supports hints with possible typos. For example: test.exe --colour, produces: An unrecognized parameter in the argument --colour Did you mean one of these? color_output Suggestion is shown when close (1 char distance from unambiguous parameter name) exists. * (new) UTF now report possible ambiguous parameters. For example: test.exe --log=all, produces: An ambiguous parameter name in the argument --log=all Did you mean one of these? log_format log_level log_sink * (new) UTF parameter help now accepts optional parameter name. Moreover you can actually "guess" the name by providing just unambiguous prefix. In this case it shows detailed information about requested parameter, including semantic, possible values and formats. For example: test.exe --help=list_con, produces: Parameter: list_content Lists the content of test tree - names of all test suites and test cases. Command line formats: --list_content[=<HRF|DOT>] Environment variable: BOOST_TEST_LIST_CONTENT Parameter list_content instructs the framework to list the content of the test module instead of executing the test cases. Parameter accepts optional string value indicating the format of the output. Currently the framework supports two formats: human readable format (HRF) and dot graph format (DOT). If value is omitted HRF value is assumed. The changes will be released with next release of boost. Any comments are welcome. Gennadiy

1 0

Graphical debugging extension for VS2015 (Container, Geometry, Polygon, Variant, ...)
by Adam Wulkiewicz 29 Sep '15

29 Sep '15

Hi, For some time now I've been thinking about extending the capabilities of a debugger and to visualize data in more convenient way than the raw numbers. It's obvious to me that in many cases variables could be graphically visualized, in many cases this is the "natural" representation, this would greately simplify the debugging. I haven't found anything like it so I've decided to play with the VS2015 extensions, mostly because they're easy to write. This is what I came up with (see the readme): https://github.com/awulkiew/graphical-debugging Besides adding commonly used native visualizers for types from some Boost libraries it allows to display their graphical representation. The extension support Boost.Geometry models and other types used internally in this library, Boost.Polygon models (polygon_set_data is missing) and boost::variant storing geometries. As a bonus, it's possible to watch containers of values (some STL containers as well as boost::array and contiguous containers from Boost.Container) as charts. Maybe if there were enough interest it'd be worth to extend it and/or to add to the official VS extensions gallery. I'm a Boost.Geometry developer so in the future I plan to support all of the coordinate systems supported by the library, maybe other internals and basically anything that helps me with the development. But I can imagine that variables of types from various Boost libraries could also be visualized, e.g. Polygon's voronoi diagram and internals, Math's quaternions as 3D Axis-Angle, std::complex as a point on a plane, containers of complex numbers and in general arbitrary types represented somehow as a 1D, 2D or 3D objects, CircularBuffer e.g. as a pie chart, BGL's graphs, maybe GIL's images, Interprocess' shared memory blocks?, etc. So feel free to share suggestions and contribute if you like. Regards, Adam

3 5

Trying out CLion.. Free license..
by Rene Rivera 29 Sep '15

29 Sep '15

As some of you are aware JetBrains recently release a new IDE that has some rather cool features (re: <https://www.jetbrains.com/clion/>) for C++ programmers. I am personally interested in using CLion for Boost work. In particular I'm hoping to write a CLion plug-in that integrates Boost Build into the IDE. And hence I've have taken it upon myself to arrange for Boost developers to get licenses for library authors to use, if they so wish. If you are interested in getting a CLion license and are a current Boost Library author here's what I need: * An email from you requesting that you want a license. * In that email indicate which Boost libraries you are an author, or maintainer, of. * Send the email from an account that you want me to send you the license when we get it. I want to avoid having to update email information a year from now when I need to renew the licenses. * You have until the end of this week, roughly, to send that email. I'll collect that and request the Boost licenses from JetBrains. And "pass" them out with instructions as needed. Rene. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

6 7

CLion plug-in for Boost.Build (was: Trying out CLion.. Free license..)
by Mateusz Loskot 28 Sep '15

28 Sep '15

On 28 September 2015 at 21:19, Rene Rivera <grafikrobot(a)gmail.com> wrote: > On Mon, Sep 28, 2015 at 2:14 PM, Robert Ramey <ramey(a)rrsd.com> wrote: >> On 9/28/15 11:45 AM, Rene Rivera wrote: >> >>> As some of you are aware JetBrains recently release a new IDE that has >>> some >>> rather cool features (re: <https://www.jetbrains.com/clion/>) for C++ >>> programmers. I am personally interested in using CLion for Boost work. In >>> particular I'm hoping to write a CLion plug-in that integrates Boost Build >>> into the IDE. And hence I've have taken it upon myself to arrange for >>> Boost >>> developers to get licenses for library authors to use, if they so wish. >>> >> >> Hmm - wouldn't it be easier just to use CMake. You wouldn't have to write >> any plugin. The serialization library includes CMake files for that >> library's build and test and it works quite well. >> > > IMO no.. But I know that opinions differ ;-) Some time ago, I developed basic Boost.Build plugin for Qt Creator https://github.com/mloskot/qt-creator-plugin-boostbuild/ which interacts with the b2.exe command line. At that time, I also briefely discussed some API ideas with Volodya. Later, Volodya implemented the Boost.Build API and server mode http://lists.boost.org/boost-build/2015/03/27906.php May I ask, which option are you going to choose for your plugin? Is it going to be the command line approach, the new BB API or anything else? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

[test] Regression - overloaded virtual function "boost::unit_test::test_observer::test_unit_skipped" is only partially overridden
by Vicente J. Botet Escriba 25 Sep '15

25 Sep '15

Hi, there is a regression in Boost.Test. Test output: boost/bin.v2/libs/test/build/intel-linux/release/link-static/threading-multi Rev 32fc9643eb674d60616412bb427bb6e0f0300cc0 / Thu, 24 Sep 2015 19:13:08 +0000 Compile [2015-09-24 20:55:11 UTC]: succeed "icpc" -c -xc++ -w2 -inline-level=2 -O3 -ip -pthread -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_TIMER_STATIC_LINK=1 -DNDEBUG -I".." -c -o "/boosttest/develop/results/boost/bin.v2/libs/test/build/intel-linux/release/link-static/threading-multi/test_tools.o" "../libs/test/src/test_tools.cpp" In file included from ../boost/test/impl/test_tools.ipp(19), from ../libs/test/src/test_tools.cpp(16): ../boost/test/unit_test_log.hpp(88): warning #654: overloaded virtual function "boost::unit_test::test_observer::test_unit_skipped" is only partially overridden in class "boost::unit_test::unit_test_log_t" class BOOST_TEST_DECL unit_test_log_t : public test_observer, public singleton<unit_test_log_t> { ^ remark #11074: Inlining inhibited by limit max-size remark #11074: Inlining inhibited by limit max-total-size remark #11076: To get full report use -qopt-report=4 -qopt-report-phase ipo Vicente

1 0

boost_1_59_0 build failures
by Karen Shaeffer 24 Sep '15

24 Sep '15

Hello, I downloaded boost_1_59_0 and built the whole set of libraries. gcc --version gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 ./b2 install warning: No toolsets are configured. warning: Configuring default toolset "gcc". warning: If the default is wrong, your build may not work correctly. warning: Use the "toolset=xxxxx" option to override our guess. warning: For more configuration options, please consult warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html Performing configuration checks - 32-bit : no (cached) - 64-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : yes (cached) - lockfree boost::atomic_flag : yes (cached) - has_icu builds : yes (cached) warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : yes (cached) - iconv (libc) : yes (cached) - icu : yes (cached) - compiler-supports-visibility : yes (cached) - compiler-supports-ssse3 : yes (cached) - compiler-supports-avx2 : yes (cached) - gcc visibility : yes (cached) - long double support : yes (cached) 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. - zlib : yes (cached) Component configuration: - atomic : building - chrono : building - container : building - context : building - coroutine : building - coroutine2 : building - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - timer : building - wave : building ...patience... ...patience... ...patience... ...patience... ...patience... ...patience... ...found 34509 targets... ...updating 8 targets... gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi/bzip2.o libs/iostreams/src/bzip2.cpp:20:56: fatal error: bzlib.h: No such file or directory #include "bzlib.h" // Julian Seward's "bzip.h" header. ^ compilation terminated. "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o "bin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi/bzip2.o" "libs/iostreams/src/bzip2.cpp" ...failed gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi/bzip2.o... ...skipped <pbin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi>libboost_iostreams.a(clean) for lack of <pbin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi>bzip2.o... ...skipped <pbin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi>libboost_iostreams.a for lack of <pbin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi>bzip2.o... ...skipped <p/usr/local/lib>libboost_iostreams.a for lack of <pbin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi>libboost_iostreams.a... gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi/bzip2.o libs/iostreams/src/bzip2.cpp:20:56: fatal error: bzlib.h: No such file or directory #include "bzlib.h" // Julian Seward's "bzip.h" header. ^ compilation terminated. "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_DYN_LINK=1 -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o "bin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi/bzip2.o" "libs/iostreams/src/bzip2.cpp" ...failed gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi/bzip2.o... ...skipped <pbin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi>libboost_iostreams.so.1.59.0 for lack of <pbin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi>bzip2.o... ...skipped <p/usr/local/lib>libboost_iostreams.so.1.59.0 for lack of <pbin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi>libboost_iostreams.so.1.59.0... ...skipped <p/usr/local/lib>libboost_iostreams.so for lack of <p/usr/local/lib>libboost_iostreams.so.1.59.0... ...failed updating 2 targets... ...skipped 6 targets... Is that expected? thanks, Karen -- Karen Shaeffer Be aware: If you see an obstacle in your path, Neuralscape Services that obstacle is your path. Zen proverb

2 1

Fwd: [sort][container] Challenge for sorting experts, an improved stable sort
by Francisco José Tapia 23 Sep '15

23 Sep '15

Hi Jon, If the elements in the flat associative container are sorted, you need only to sort the elements to insert and after do a fusion of the two parts. If your container admit repeated elements, you can use the std::sort, if not, you must use an stable sort , and delete the repeated. You have several algorithms for to do a stable sort. In the library we are developing (https://github.com/fjtapia/sort_parallel ) you have a smart_merge_sort, which is a very fast stable sort and use only one half of the memory used by the data, is exception safe and use the move semantics I didn't see any implementation of the stable sort algorithms without additional memory, in any library GCC, TBB, IPP … I suppose because they are slow. If you have 100 elements and want to insert 30 elements, need to resize the vector to 130 elements, the last 30 are empty. If you have other vector with the data to insert, you can use smart_merge_sort, and use as auxiliary memory the last 15 elements of the main vector. After sort, delete the repeated elements. And with the two vectors you must do a half_merge fusion , and all is done. With this method you need only the vector for to sort the elements to insert. If you want I can write a small program doing this, using the code of the library.

2 2

[sort][container] Challenge for sorting experts, an improved stable sort
by Ion Gaztañaga 23 Sep '15

23 Sep '15

Hi, I'm trying to improve insertion times for flat associative containers. In range insertions one optimization is to insert the whole range in the end of the container and sort the whole vector instead of trying a loop. An additional optimization proposed in the mailing list is to have an option to create externally the internal vector type of the flat map/set, fill it and then try to move it into the flat container. That requires sorting the moved vector (and removing duplicates if needed). I could try to use std::sort/std::stable_sort but there are some problems: -> Non-portable for C++03 compilers and Boost.Move, and Boost.Container fully supports those platforms. -> Additional O(N) temporary memory for stable sorting. Usually this means a temporary N element array, although there are algorithm to use only N/2 temporary elements. With big containers, this is a lot of memory. So I started analyzing several papers and implementations to see if a custom implementation was possible, but I felt Boost.Sort could be a good place to have that implementation and the Boost community a good place to discuss design alternatives. My initial requirements: 1) Stable sort. A non-stable sort is faster and useful for unique keys containers, but stable sort can be used initially in all flat containers until the non-stable version is implemented. 2) Externally supplied auxiliary memory with optionally no auxiliary memory at all. It seems that there are newer algorithms like Grailsort (https://github.com/Mrrl/GrailSort) or WikiSort (https://github.com/BonzaiThePenguin/WikiSort) that claim O(1) memory, even no auxiliary buffer, and key comparison and data exchanges with complexity O(n*log(n)). However I don't think those implementation correctly handle the basic exception guarantee or non-trivially copyable types. Reason: I want to avoid allocating short-lived temporary memory: if it's available I want to pass the extra capacity that flat containers' internal vector holds for future insertions. 3) Customization points (without ADL, which IMHO is not customizable enough). The sort algorithm should use a SortTraits template parameter for basic operations like "move", "swap", "initialized_move". E.g: template<class T> struct sort_traits { static? void move(T &from, T &to); static? void swap(T &l, T &r); static? void uninitialized_move(T &from, void *to); static? void destroy(T &from, void *to); }; I don't know if this trait should be stateful or not (static members). I could imagine the usefulness of a stateful implementation of sort_traits that could store a reference to an allocator so that some special "construct" version is used in some operations. Or just a version that counts the number of each operation to ease debugging. In any case, a stateless version would be enough for most cases. Reason: In Boost.Container, the idea is to use boost::move + boost::adl_move_swap in the initial implementation, maybe some destructive move implementation in a second iteration if Boost.Move implements it. In any case those operations should be customizable by the user, independently from the type to be sorted. This also avoids unnecessary dependencies in Boost.Sort. -> Dependencies: the implementation should only rely on Boost.Core, Boost.Config, maybe Boost.TypeTraits and no heavy STL dependencies (optionally). Currently Boost.Sort depends on Serialization for BOOST_STATIC_WARNING, but I think this is easily solvable, maybe this static assert utility should go to the core/utility library. Reason: Sort is a low-level algorithm that should avoid pulling unneeded dependencies to other boost libraries. * * * I don't know if other Boost libraries could benefit from this new stable_sort implementation. Maybe it's too special and I should try to write it myself in Boost.Container. I would love to hear comments and suggestions from sort experts, this might be a common need that could enrich the Boost.Sort library. Best, Ion

4 9

[regression] Tests for 'develop' not showing
by Edward Diener 23 Sep '15

23 Sep '15

Trying http://www.boost.org/development/tests/develop/developer/summary.html I get: "Error extracting file: The specified zipfile was not found."

4 4

Re: [boost] Error while building boost
by Roshan 22 Sep '15

22 Sep '15

Hi, This list is specific to the Boost.Compute library. This mail is probably meant for the main Boost mailing list. Forwarding you there. P.S. I'm not sure if the attachment is being forwarded properly, please check. On Tue, Sep 22, 2015 at 12:24 PM, <valnci89(a)gmail.com> wrote: > Hi, > > > I'm trying to install boost on my machine but its not building properly. > Attached is the output generated on running ./b2 install. > > > Commands used: > > ./bootstrap.sh --prefix=/usr/include/boost > > ./b2 install > > > Machine Info: > > OS: RHEL ppc64le > > Boost version: boost_1_59_0 > > > Let me know if any other info is required. > > > Please advice me on this issue. > > > Thanks, > > Valnci > -- Warm regards Roshan

1 0

[Container] interest in a flat_unordered_map
by Treb Connell 21 Sep '15

21 Sep '15

I'm hoping to port a flat hash map that I've written to boost. Since boost has a flat_map I think it'd be good to have a flat_unordered_map as well, especially since there's an opportunity to be much more efficient. The one I would like to use is based on the hash map used in Lua, which is a mix of Coalesced and Robin Hood hashes. I don't think there's a name that describes it yet unfortunately, but I describe it near the end of this post. *Performance (primary reason for use):* It uses memory and cache very effectively and ends up being *very fast*. It's hard to benchmark real world situations, but in inserting, finding, erasing, and iterating over a dictionary it was up to six orders of magnitude faster than VS2013's unordered_map. This isn't a totally fair test because the cache efficiency really shines. *Standards compliance:* Differences from std::unordered_map are widely the same differences as flat_map listed here <http://www.boost.org/doc/libs/1_59_0/doc/html/container/non_standard_contai…>. Also bucket related methods no longer apply, so will be removed. *That said there's one major standards compliance issue that I'm struggling with:* The most optimal implementation of iterators for this container *does not have constant time traversal*. The implementation is a vector with elements scattered across it. To increment an iterator I continue to increment the internal vector iterator until I hit a new element. In practice elements should be scattered evenly, and will be close to one another, but in the worst case this is N-1. Additional memory or logic could be added to make this O(1), but I don't think that trade is worth it. In my applications of unordered_map I rarely iterate, and would not want to penalize insert, find, or erase to make iteration faster. I could make a new concept for this, pay the cost for making it truly O(1), or *since the common case is not O(N) would it be okay to consider these bidirectional iterators*? *Implementation details:* You can see Lua's implementation here <http://www.lua.org/source/5.3/ltable.c.html>. The applicable logic is in and below *luaH_newkey, *comments are useful. It's primarily a Coalesced hash table, but differs in collision behavior. When a new key collides with an old key, we check to see if the old key is in it's "*main position"*. The main position is the index that the key hashes to. If it's not in it's main position that means that it previously collided and was displaced. Since this is the new keys main position, we displace again the current key, and place ourselves there. This drastically decreases chain length, and improves the load factor that the hash map can optimally reach. Sorry about long post, can go into additional details upon request. Thanks, Treb

6 7

A compile-time-counter code snippet for boost
by Igor V. Chesnokov 21 Sep '15

21 Sep '15

2 1

[serialization] bug in static_warning.hpp
by Alain Miniussi 21 Sep '15

21 Sep '15

Hi, In static_warning.hpp we have the following code (which, if I trust its name, should trigger a *warning*): #define BOOST_SERIALIZATION_BSW(B, L) \ typedef boost::serialization::BOOST_SERIALIZATION_SS< \ sizeof( boost::serialization::static_warning_test< B, L > ) \ > BOOST_JOIN(STATIC_WARNING_LINE, L) BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE; #define BOOST_STATIC_WARNING(B) BOOST_SERIALIZATION_BSW(B, __LINE__) Now, since, since there is no BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE defined in boost (there used to be one in static_assert.hpp) this thing will generate a typedef of the form: typedef boost::serialization::BOOST_SERIALIZATION_SS< \ sizeof( boost::serialization::static_warning_test< B, L > ) \ > $STATIC_WARNING_LINE$L BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE; which is wrong. The MPI test are failing on that. Maybe BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE should be replaced with BOOST_ATTRIBUTE_UNUSED, but I am not sure what that macro is trying to achieve. Thks Alain

1 1

[locale] char conversion issue
by Alain Miniussi 21 Sep '15

21 Sep '15

Hi, My build is failing on message.cpp with: ../../../libs/locale/src/shared/message.cpp(439): error: invalid type conversion: "const wchar_t *" to "const char *" static_cast<char const *>(p), ^ detected during: [...] caused by code like: ================= template<typename CharType> struct hash_function { size_t operator()(message_key<CharType> const &msg) const { pj_winberger_hash::state_type state = pj_winberger_hash::initial_state; CharType const *p = msg.context(); if(*p != 0) { CharType const *e = p; while(*e) e++; state = pj_winberger_hash::update_state(state, static_cast<char const *>(p), static_cast<char const *>(e)); state = pj_winberger_hash::update_state(state,'\4'); } =================== Which looks like a legitimate error since that conversion does not seems t be covered by static_cast. This is on bot master and develop branch. The compiler is intel 16: [alainm@gurney build]$ icpc --version icpc (ICC) 16.0.0 20150815 Copyright (C) 1985-2015 Intel Corporation. All rights reserved. [alainm@gurney build]$ Regards Alain

2 1

[Compute] array support
by Fabian Bösch 19 Sep '15

19 Sep '15

Hi, I've been using Boost.Compute for some tests in the last couple of days. So far, it has proven very useful and I came to like it quite a bit. One thing I would add to it, though, is support for arrays when adapting your own classes for OpenCl through the Macro BOOST_COMPUTE_ADAPT_STRUCT. A simple overload would do the trick in my opinion: namespace boost { namespace compute { namespace detail { template<class Struct, class T> inline std::string adapt_struct_insert_member(T Struct::*, const char *name) { std::stringstream s; s << " " << type_name<T>() << " " << name << ";\n"; return s.str(); } template<class Struct, class T, int N> inline std::string adapt_struct_insert_member(T (Struct::*)[N], const char *name) { std::stringstream s; s << " " << type_name<T>() << " " << name << "[" << N << "]" << ";\n"; return s.str(); } } // end detail namespace } // end compute namespace } // end boost namespace Hope something along this lines can be added, thanks, Fabian

2 1

[Coroutine] Back to the caller
by Mikhail Strelnikov 18 Sep '15

18 Sep '15

Hi, I have an issue after switching from Boost.Coroutine to Boost.Coroutine2 - nested coroutine switches to its creator - not to the caller. Here is the code - http://codepad.org/WGNs0N7F There are two coroutines (1st coroutine starts, makes some progress, then spawns 2nd coroutine. But 1st coroutine knows nothing about 2nd and does not communicate with it - main thread does). With Boost.Coroutine it works as expected and outputs: g1g1g1g1g2g1g2g1g2g1g2g1g2g1g2g1 leaving coroutine 1 g2g2g2g2 leaving coroutine 2 Here you can see that 1st coroutine exits but 2nd keeps working normally. And control from coroutines is returned back to the caller (g - caller, 1 and 2 - coroutines). But with Boost.Coroutine2 it outputs: g1g1g1g1g21g1g21g1g1g21 leaving coroutine 1 assertion failed : (false) && ("pull_coroutine is complete") Here you can see that when caller (g) calls 2nd coroutine, it does not yield back to caller, but instead switches to 1st coroutine ("g21" in output).Then it terminates on assert "pull_coroutine is complete". Is it a bug of Boost.Coroutine2? If not, how can I change this code to work equally for Boost.Coroutine and Boost.Coroutine2? Thanks! P.S. What is the reason of boost::coroutines2::coroutine<void>::pull_type not having default constructor? It is still possible to have an "empty" pull_type, but it is painful process.

2 6

Interest in algorithm for arithmetic mean of integers
by Matt Calabrese 17 Sep '15

17 Sep '15

AFAICT the only function for calculating arithmetic mean in boost is in the accumulators library and it's not really appropriate for integral types. In practice, properly calculating the mean for a range (especially a range that's only an input range but not a forward range) is surprisingly tricky to do in a way that avoids overflow and provides an exact result. I have a couple of solutions, including one that works for input ranges. Is this something that people would find useful? Is there a similar algorithm already implemented in boost that I'm not aware of? The approach I've taken yields an exact result as a mixed number and should work without overflow (assuming only that the range's size is able to be represented by its difference type). I believe the implementation that works for input ranges could theoretically be adapted to work with Boost.Accumulators, though I'm admittedly not too familiar with the library. -- -Matt Calabrese

5 10

integrating NaCl support into boost
by Konstantin Ivlev 17 Sep '15

17 Sep '15

Hi boost community, some introdution: NaCl (Google NativeClient, https://developer.chrome.com/native-client) - open-source technology authored by Google Inc. providing way to run native code inside web-browser in portable and secure manner. NaCl provides posix-like environment, and supports newlib and glibc standard libraries. currently NaCl is supported by Google Chrome web-browser, and range of applications and software libraries are ported to NaCl (include zlib, quake, etc.). how about integrating NaCl support patches into the boost main-line (trunk/master), I am talking about these NaCl ports patches from Google: https://chromium.googlesource.com/external/naclports/+/master/ports/boost (I actually have a bit more correct patches that allow to compile boost 1.59 for NaCl platforms, while Google patches are still for old version 1.55). some details about patches and which boost areas are covered by patches: - boost/config - common setup for NaCl - boost/cstdint - small change to expose boost::uintptr_t/boost::intptr_t for NaCl, similarly to how it was done to other compilers - buitin.jam and gcc.jam - introduced new os-name for NaCl, in order to properly setup threading libraries (NaCl has pthread but no rt, just like BSD) - boost/system/errorcode - oddball version of strerror_r (just like cygwin), also ENOTRECOVERABLE & EOWNERDEAD errno codes are not supported by PNaCl - boost/log/light_rw_mutex - not supported on NaCl note that boost build is incomplete - certain libraries are not (yet) ported to NaCl, because of platform-specific stuff like file/network I/O : - context - coroutine - coruutine2 - log - filesystem - test - timer - wave not sure if it's OK for start, or all boost libraries should be ported together in order to process further. I would be grateful to hear suggestion about how to process with it, e.g. which actions should I take to make it really happen. I personally suppose making boost to officially support more platforms will make boost even more popular and allow more developers to use it and port their applications to other platforms. I look forward to hearing from you soon. yours sincerely, Konstantin

4 5

Windows Phone and Visual Studio 2015
by Vladimir Prus 17 Sep '15

17 Sep '15

Folks, did anybody had success building Boost for Windows Phone using Visual Studio 2015 (aka 14.0)? We have Boost.Build code to do so, but it tries to find vcvarsphoneall.bat script, and some other similarly named scripts, that I don't seem to have anywhere, despite been able to build WP app from the IDE. Has anybody solved this? Thanks, Volodya

1 1

[predef] BOOST_ARCH_BITS_* feature request
by Antony Polukhin 16 Sep '15

16 Sep '15

Hi, It looks like for low-level programming following macro could be really useful: BOOST_ARCH_BITS_64 BOOST_ARCH_BITS_32 BOOST_ARCH_BITS_16 ? Predef also missing BOOST_ARCH_ARM_64, BOOST_ARCH_PPC_64. Boost.DLL really needs those macro for detecting bit's dependent elf/macho/pe structures layout. Is it possible to add them? -- Best regards, Antony Polukhin

4 4

Copyright-less licence references
by Gennadiy Rozental 16 Sep '15

16 Sep '15

Hi, I suggest we should drop "Copyright Joe Coder 20xx" from all our files. My reasons: * git/svn history provides much better copyright attribution. Each developer has a copyright on lines authored. As it is these copyright disclaimers are very frequently wrong. * I am never clear what this line really mean. Copyright Joe Coder 2010 - does this mean Joe has copyright up to 2010, starting 2010 or only in 2010? Should one keep updating these disclaimers every January? * For libraries which are maintained by multiple developers and/or which were moved from one maintainer to another maintainer - these disclaimers either wrong or pain to maintain. * these are just a clutter with no real value IMO we should just keep licence reference and that's it: // 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) Gennadiy

12 38

Determining interest in container with efficient random access insert and erase
by Chris Clearwater 16 Sep '15

16 Sep '15

Greetings, I have written a library with the intention of submitting it to Boost.Container. My container implements O(log n) random access insert/erase and has a strong focus on performance while supporting the interfaces of the standard library sequence types. An example application would be the character buffer of a text editor. Useful links: - Source code: https://github.com/det/segmented_tree_seq - Documentation: http://det.github.io/segmented_tree_seq/ - Benchmarks: https://github.com/det/segmented_tree_seq/tree/benchmarks Any feedback is greatly appreciated.

14 28

BOOST_PP array extension proposal
by Antoine Leblanc 14 Sep '15

14 Sep '15

Hello to all of you! A few years ago, I've developped a small extension to BOOST_PP that adds a few functions to it. Namely: * ARRAY_CAT, which concatenates two BOOST_PP arrays; * ARRAY_LOWER_BOUND, which finds the index of the lower bound of an item in a given array of numerical values; * ARRAY_SORT, which sorts the given array of numerical values; * ARRAY_SORT_U, which sorts the given array and remove duplicates. I'm not sure it'd be worth adding to BOOST_PP; but if you think it might be, I'd be happy to submit a merge request. The code is rather small and can be browsed at https://github.com/nicuveo/TOOLS_PP Any suggestion or input is welcome. Thanks for your time! -- Antoine Leblanc

6 34

1.59 release notes don't mention new property_tree::json_parser
by Jonathan Wakely 14 Sep '15

14 Sep '15

The commit logs say: TL;DR: The new parser fixes long-standing bugs and has full Unicode support, but removes non-standard extensions of the old parser, which could break code: - String concatenation: the old parser concatenated adjacent string literals like C does. - Comments: the old parser supported C and C++-style comments. JSON doesn't allow comments. Removing support for comments did break something. Unfortunately there was no sign of this in the release notes, so I had to debug it the hard way (in code that swallowed the exception from the parser - gah!) and only found the commit message once I already knew what the problem was. </rant>

4 5

[type_traits] New version in master
by John Maddock 14 Sep '15

14 Sep '15

Just a quick heads up that the new version of type_traits is now in master, if there are any issues please do shout, John.

5 7

[type_traits] New version in master
by Glen Fernandes 14 Sep '15

14 Sep '15

Hi John, Any particular reason why 'is_trivially_default_constructible' was not provided as just the functionally-equivalent of 'has_trivial_default_constructor'? Glen

2 1

b2 headers failing
by Marcel Raad 13 Sep '15

13 Sep '15

Hi, when I try "b2 headers" on a fresh checkout of the develop branch, I get the following errors: C:/boost/tools/build/src/build\feature.jam:326: in validate-feature from module feature error: unknown feature "<segmented-stacks>" C:/boost/tools/build/src/build\feature.jam:360: in expand-subfeatures-aux from module feature C:/boost/tools/build/src/build\feature.jam:425: in feature.expand-subfeatures from module feature C:/boost/tools/build/src/build\property.jam:508: in property.translate from module property C:/boost/tools/build/src/build\property-set.jam:432: in property-set.create-from-user-input from module property-set C:/boost/tools/build/src/build\property-set.jam:484: in property-set.refine-from-user-input from module property-set C:/boost/tools/build/src/build\project.jam:700: in class(a)project-attributes.set from module object(project-attributes)@369 C:/boost/tools/build/src/build\project.jam:1099: in project from module project-rules libs\coroutine2\build\Jamfile.v2:26: in modules.load from module Jamfile<C:\boost\libs\coroutine2\build> C:/boost/tools/build/src/build\project.jam:325: in load-jamfile from module project C:/boost/tools/build/src/build\project.jam:64: in load from module project C:/boost/tools/build/src/build\project.jam:89: in load-used-projects from module project C:/boost/tools/build/src/build\project.jam:75: in load from module project C:/boost/tools/build/src/build\project.jam:145: in project.find from module project C:/boost/tools/build/src\build-system.jam:535: in load from module build-system C:\boost\tools\build\src/kernel\modules.jam:295: in import from module modules C:\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build from module C:\boost\boost-build.jam:17: in module scope from module Does anyone know what's wrong here? Thanks, Marcel -- View this message in context: http://boost.2283326.n4.nabble.com/b2-headers-failing-tp4680039.html Sent from the Boost - Dev mailing list archive at Nabble.com.

1 1

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

12 Sep '15

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

11 32

Boost.Fiber mini-review September 4-13
by Nat Goodspeed 11 Sep '15

11 Sep '15

Hi all, The mini-review of Boost.Fiber by Oliver Kowalke begins today, Friday September 4th, and closes Sunday September 13th. It was reviewed in January 2014; the verdict at that time was "not in its present form." Since then Oliver has substantially improved documentation, performance, library customization and the underlying implementation, and is bringing the library back for mini-review. The substance of the library API remains the same, which is why a mini-review is appropriate. The Fiber library now requires a C++14-conforming compiler. I will monitor reviews and discussion on both the boost-users@ list and the boost@ developers' list. Please include at least "fiber" and "review" in your mail subject, e.g. by replying to this message. (Please reply to only ONE list, however.) Thank you for your interest and your feedback! ----------------------------------------------------- About the library: Boost.Fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperatively. The API contains classes and functions to manage and synchronize fibers similar to Boost.Thread. Each fiber has its own stack. A fiber can save the current execution state, including all registers and CPU flags, the instruction pointer, and the stack pointer and later restore this state. The idea is to have multiple execution paths running on a single thread using a sort of cooperative scheduling (versus threads, which are preemptively scheduled). The running fiber decides explicitly when it should yield to allow another fiber to run (context switching). Boost.Fiber internally uses execution_context from Boost.Context; the classes in this library manage, schedule and, when needed, synchronize those contexts. A context switch between threads usually costs thousands of CPU cycles on x86, compared to a fiber switch with a few hundred cycles. A fiber can only run on a single thread at any point in time. docs: http://olk.github.io/libs/fiber/doc/html/index.html git: https://github.com/olk/boost-fiber --------------------------------------------------- Please always state in your review whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - 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? Nat Goodspeed Boost.Fiber Review Manager ________________________________

11 108

[fiber] on schedulers and wakeups
by Giovanni Deretta 11 Sep '15

11 Sep '15

Hi Oliver, I'm looking at the boost.fiber scheduling customization options. I have a few comments. My first concern is that scheduler is a global (per thread) property. This makes sense, but it limits its usability in libraries, unless the library completely owns a thread. It would be nice if schedulers where schedulable entities themselves, so that they could be nested (more at the end). Also the description of the scheduler interface does not specify any thread safety requirements. I assume that at least awakened must be thread safe as the scheduling might be caused by a signal coming from another thread. Any requirements should be specified properly. This leads to two additional points. First of all, there should be a way to retrieve the scheduler associated with a fiber: I haven't looked at the source, but the association must exist internally, otherwise cross thread scheduling wouldn't work. Second, there does not seem to be a way to allow signaled fibers to run in the context of the signaling thread. This seems an important optimization.I understand this is an explicit decision as currently it is not possible to portably migrate fibers, but the option should be left to the user if he knows it is safe in their setup. Possibly require 'awakened(fiber*x)' to call x->get_scheduler()->awakened(x) if it does not support running the fiber. My preference is to add a queryable boolean flag to each schedulable entity that states whether it is allowed to move from its scheduler (this makes a difference when you have multiple nested schedulers). Among other things this would also prevent work stealing. The flag would by default be set to prevent migration of course. Now, what do nested schedulers give you? In addition to composability, you can have the equivalent of an asio strand without explicit mutual exclusion. Let say you have a bunch of fibers that all access the same resource; you do not care where they run, as long as they never run concurrently. By binding all of them to the same scheduler, the guarantee is implicit. It should be possible to implement nested schedulers by having each fiber set the current scheduler pointer if it differs and store the previous one. On a scheduling event, if the current scheduler runs out of runnables, the signal/yield code would restore the previous scheduler and try again. Of course handling priorities and non strict fifo scheduling might be more complex. Note that the multi scheduler logic need to be implemented by Boost.Fiber itself. Finally, it might be possible (but I haven't tested this) to make fibers migrable on platforms where it normally isn't safe by allocating an actual thread for each one. The thread would be stopped as soon as it has been created, but a thread control block plush TLS entries would have been allocated. The existing context switch would need to be augmented with the ability to swap the thread context pointer. HTH, -- gpd

4 23

Critical. Help required. Boost.DLL Jamfile breaks testing with multiple toolsets
by Antony Polukhin 10 Sep '15

10 Sep '15

Hi, There's a big problem with Boost.DLL's Jamfile which I do not know how to fix. Introduction Tests of Boost.DLL create multiple *.so files and install them to a specified TEST_DIR path. Tests consume that TEST_DIR path and search for *.so in there: path-constant TEST_DIR : $(BOOST_ROOT)/bin.v2/libs/dll/test ; project : source-location . : requirements ; { # our test lib for shared library tests lib test_library : test_library.cpp : <link>shared ; lib getting_started_library : ../example/getting_started_library.cpp : <link>shared ; install install-bin : test_library getting_started_library : <location>$(TEST_DIR) ; test-suite boostdll : [ run shared_library_load_test.cpp : $(TEST_DIR) : : <dependency>install-bin ] [ run shared_library_search_symbol_test.cpp : $(TEST_DIR) : : $(RDYNAMIC) <dependency>install-bin ] ; } The Problem If multiple toolsets specified, then `install-bin` target gets broken: cd libs/dll/test ../../../b2 toolset=gcc,clang error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <cxxflags>-Wall -Wextra -pedantic -Wno-long-long <library>object(file-target)@3829 <library>object(file-target)@3862 <toolset-gcc:version>4.8 <toolset>gcc <xdll-path>/home/antoshkka/boost_maintain/boost/bin.v2/libs/filesystem/build/gcc-4.8/debug/threading-multi <xdll-path>/home/antoshkka/boost_maintain/boost/bin.v2/libs/system/build/gcc-4.8/debug/threading-multi error: - <library>object(file-target)@7264 <library>object(file-target)@7296 <toolset-clang:platform>linux <toolset-clang:version>3.4 <toolset>clang <xdll-path>/home/antoshkka/boost_maintain/boost/bin.v2/libs/filesystem/build/clang-linux-3.4/debug/threading-multi <xdll-path>/home/antoshkka/boost_maintain/boost/bin.v2/libs/system/build/clang-linux-3.4/debug/threading-multi Correct fix would be to embed into TEST_DIR the names of toolset and all other configuration flags. path-constant TEST_DIR : $(BOOST_ROOT)/bin.v2/libs/dll/test/$(FLAGS)/$(TOOLSET) ; The Question How to get the $(FLAGS) and $(TOOLSET) variables? If that requires writing rules or implies some other Boost.Build magic I'd really appreciate a pull request: any nontrivial modification to Jamfile takes months to apply and test because of my poor knowledge of Boost.Build. Jamfile: https://github.com/boostorg/dll/blob/develop/test/Jamfile.v2 Boost.DLL: https://github.com/boostorg/dll This issue is critical, because it breaks regression testing (see "[boost] [android][regression] bjam failed") -- Best regards, Antony Polukhin

5 9

Find All Paths
by Tom Skora 10 Sep '15

10 Sep '15

I have a list of vertices and using unidirectional edges, create multiple start and end paths starting from a start vertex. Ex. Vertices= 1,2,3,4,5, 6 Edges = (1,2), (2,3), (2,4), (2,5), and (5, 6) I would like to put in vertex 1 and have the following lists returned: 1,2,3 and 1,2, 4 and 1,2, 5, 6 What function can I use to return those lists Thanks Sent from my iPhone

1 0

[git] Stalled submodule updates?
by Rene Rivera 09 Sep '15

09 Sep '15

I was investigating why testing is currently broken.. And narrowed it down to the tools/build subproject on develop not being up to date with the current build submodule commit. Anyone know what has gone awry with the auto-updates of the super project? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

[type_traits] Time to merge Version 2 to the master branch?
by Ion Gaztañaga 09 Sep '15

09 Sep '15

Hi, Once Boost 1.59 is out, I'd like to suggest merging TypeTraits V2 to the master branch. It's a great job that will reduce boost library dependencies. Any chance this can happen soon? Best, Ion

4 5

[container] Implemented Polymorphic Memory Resources
by Ion Gaztañaga 09 Sep '15

09 Sep '15

Hi to all, In case anyone is interested, I just committed to the develop branch the implementation of the proposal "N3916 Polymorphic Memory Resources - r2" that was included in the TS "C++ Extensions for Library Fundamentals". The library continues to support C++03 compilers. It basically introduces in namespace boost::container::pmr and the path boost/container/pmr/: - memory_resource - synchronized_pool_resource - unsynchronized_pool_resource - monotonic_buffer_resource - polymorphic_allocator - resource_adaptor - new_delete_resource / null_memory_resource / get_default_resource / set_default_resource - Aliases for all containers, using the polymorphic_allocator. As default resource, new_delete_resource and null_memory_resource are required to be globals, they are implemented in the separately compiled boost.container library that was used to implement the DLMalloc-based extended allocator. It seems that many users dislike building Boost libraries, but I felt this was the correct way to implement it. We could change or make it optionally header-only if there is demand. To avoid dependencies to some users, I made sure that memory_resource and resource_adaptor, which don't depend on the global default memory resource, can be used without linking the library. Some logic was refactored from scoped_allocator_adaptor to avoid repeating the complicated template and preprocessor machinery in the polymorphic_allocator. I hope this does not cause any problem to scoped allocator users. Any suggestion or bug report is welcome. Best, Ion

5 8

Compiling with Clang 3.7.0 from windows
by Paul A. Bristow 09 Sep '15

09 Sep '15

I've downloaded the shiny new Clang 3.7 and added this to my user-config. # 64-bit version using clang # from http://llvm.org/releases/download.html : # version 3.7.0 : # Clang compiler .exe location #"C:/LLVM/bin/clang++.exe" # OK #"C:\\Program Files (x86)\\LLVM\\bin\\clang++.exe" # OK "C:\\Program Files\\LLVM\\bin\\clang++.exe" # : # options ; If I compile a simple hello world (no Boost library calls) program using the defaults (jam (using up-to-date Boost develop branch) it fails at the link complaining c:\mingw\bin\ld.exe: unrecognised emulation mode: i386pep Supported emulations: i386pe which seems an odd message??? I:\modular-boost\libs\quickdox\example>b2 toolset=clang-3.7.0 Performing configuration checks - 32-bit : no (cached) - 64-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : yes (cached) ...found 22 targets... ...updating 4 targets... clang-linux.compile.c++.without-pth ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug\quick_auto_d ox_index.obj clang version 3.7.0 (tags/RELEASE_370/final) Target: x86_64-w64-windows-gnu Thread model: posix "C:\\Program Files\\LLVM\\bin\\clang++.exe" -cc1 -triple x86_64-w64-windows-gnu -emit-obj -mrelax-all -disable-free -main-file-name quick_auto_dox_index.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -g -dwarf-column-info -coverage-file "I:\\modular-boost\\libs\\quickdox\\example\\..\\..\\..\\bin.v2\\libs\\quickdox\\example\\quick_auto _dox_index.test\\clang-linux-3.7.0\\debug\\quick_auto_dox_index.obj" -resource-dir "C:\\Program Files\\LLVM\\bin\\..\\lib\\clang\\3.7.0" -D BOOST_ALL_NO_LIB=1 -I "..\\..\\.." -I "..\\include" -internal-isystem "c:\\mingw\\mingw32\\include\\c++" -internal-isystem "c:\\mingw\\mingw32\\include\\c++\\mingw32" -internal-isystem "c:\\mingw\\mingw32\\include\\c++\\backward" -internal-isystem "c:\\mingw\\mingw32\\include\\c++\\4.8.1" -internal-isystem "c:\\mingw\\mingw32\\include\\c++\\4.8.1\\mingw32" -internal-isystem "c:\\mingw\\mingw32\\include\\c++\\4.8.1\\backward" -internal-isystem "c:\\mingw\\include\\c++\\4.8.1" -internal-isystem "c:\\mingw\\include\\c++\\4.8.1\\mingw32" -internal-isystem "c:\\mingw\\include\\c++\\4.8.1\\backward" -internal-isystem "c:\\mingw\\lib\\gcc\\mingw32\\4.8.1\\include\\c++" -internal-isystem "c:\\mingw\\lib\\gcc\\mingw32\\4.8.1\\include\\c++\\mingw32" -internal-isystem "c:\\mingw\\lib\\gcc\\mingw32\\4.8.1\\include\\c++\\backward" -internal-isystem "C:\\Program Files\\LLVM\\bin\\..\\lib\\clang\\3.7.0\\include" -internal-isystem "c:\\mingw\\lib\\gcc\\mingw32\\4.8.1\\include" -internal-isystem "c:\\mingw\\mingw32/sys-root/mingw/include" -internal-isystem "c:\\mingw\\lib\\gcc\\mingw32\\4.8.1\\include-fixed" -internal-isystem "c:\\mingw\\mingw32\\include" -internal-isystem "c:\\mingw\\include" -O0 -Wall -fdeprecated-macro -fdebug-compilation-dir "I:\\modular-boost\\libs\\quickdox\\example" -ferror-limit 19 -fmessage-length 0 -mstackrealign -fno-use-cxa-atexit -fno-inline -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o "..\\..\\..\\bin.v2\\libs\\quickdox\\example\\quick_auto_dox_index.test\\clang-linux-3.7.0\\debug\\q uick_auto_dox_index.obj" -x c++ quick_auto_dox_index.cpp clang -cc1 version 3.7.0 based upon LLVM 3.7.0 default target x86_64-w64-windows-gnu ignoring nonexistent directory "c:\mingw\mingw32\include\c++" ignoring nonexistent directory "c:\mingw\mingw32\include\c++\mingw32" ignoring nonexistent directory "c:\mingw\mingw32\include\c++\backward" ignoring nonexistent directory "c:\mingw\mingw32\include\c++\4.8.1" ignoring nonexistent directory "c:\mingw\mingw32\include\c++\4.8.1\mingw32" ignoring nonexistent directory "c:\mingw\mingw32\include\c++\4.8.1\backward" ignoring nonexistent directory "c:\mingw\include\c++\4.8.1" ignoring nonexistent directory "c:\mingw\include\c++\4.8.1\mingw32" ignoring nonexistent directory "c:\mingw\include\c++\4.8.1\backward" ignoring nonexistent directory "c:\mingw\mingw32/sys-root/mingw/include" ignoring nonexistent directory "c:\mingw\mingw32\include" #include "..." search starts here: #include <...> search starts here: ..\..\.. ..\include c:\mingw\lib\gcc\mingw32\4.8.1\include\c++ c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\mingw32 c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\backward C:\Program Files\LLVM\bin\..\lib\clang\3.7.0\include c:\mingw\lib\gcc\mingw32\4.8.1\include c:\mingw\lib\gcc\mingw32\4.8.1\include-fixed c:\mingw\include End of search list. clang-linux.link ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug\quick_auto_d ox_index.exe c:\mingw\bin\ld.exe: unrecognised emulation mode: i386pep Supported emulations: i386pe clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation) "C:\Program Files\LLVM\bin\clang++.exe" -o "..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug\quick_auto_ dox_index.exe" -Wl,--start-group "..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug\quick_auto_ dox_index.obj" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -g -m64 ...failed clang-linux.link ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug\quick_auto_d ox_index.exe... ...skipped <p..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug>quick_auto _dox_index.run for lack of <p..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug>quick_auto _dox_index.exe... ...failed updating 1 target... ...skipped 2 targets... ...updated 1 target... If I specify address-model=32, then it runs OK - but still says "64-bit : yes (cached)" which isn't what I would expect? I:\modular-boost\libs\quickdox\example>b2 -a toolset=clang-3.7.0 address-model=32 Performing configuration checks - 32-bit : no (cached) - 64-bit : yes (cached) <<<<<<<<<<<<<<<<<<< ??????????????????? <snip> [Also example>b2 -a toolset=clang-3.7.0 address-model=64 fails to link as with no address-model specified (so default is 64 bit?)]. Suggestions? (Have I got the wrong version of mingw? I have others from ming64 - how do I specify to use those?) Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

6 26

Re: [boost] Common future base class (was Re: Boost.Fibermini-review September 4-13)
by Nat Goodspeed 07 Sep '15

07 Sep '15

On Sun, Sep 6, 2015 at 2:07 PM, Hartmut Kaiser <hartmut.kaiser(a)gmail.com> wrote: >> I've always found when_any much more interesting than when_all. Is it as >> trivial to implement with await as when_all? > Nod, I agree. However, I have not found a clever way to do that yet. On Mon, Sep 7, 2015 at 9:39 AM, Anthony Williams <anthony.ajw(a)gmail.com> wrote: > On 07/09/15 14:36, Agustín K-ballo Bergé wrote: >> On 9/7/2015 4:32 AM, Anthony Williams wrote: >>> On 03/09/15 16:47, Agustín K-ballo Bergé wrote: >>>> calling `set_value` on the same instance from different >>>> threads concurrently is expected to work, as in only one (unspecified) >>>> of them will actually make the shared state ready while all the others >>>> would throw `promise_already_satisfied`? >>> Yes, that was the intent. I've got an example that does exactly that in >>> chapter 8 of my book. >> Could you describe briefly what this example does? Is it just workers >> racing (in the good sense) to satisfy the promise? Or does serialization >> of set_xxx calls matter? > It's just workers racing to satisfy the promise. The first one to do so > sets the value, the rest get an exception. Seems like that could be the basis for a nice when_any?

2 1

Re: [boost] [Boost-users] Boost.Fiber mini-review September 4-13
by Vicente J. Botet Escriba 07 Sep '15

07 Sep '15

Le 06/09/15 02:21, Vicente J. Botet Escriba a écrit : > Le 05/09/15 16:27, Nat Goodspeed a écrit : >> On Fri, Sep 4, 2015 at 5:08 PM, Vicente J. Botet Escriba >> <vicente.botet(a)wanadoo.fr> wrote: >> >>> Le 04/09/15 20:37, Nat Goodspeed a écrit : >>>> On Fri, Sep 4, 2015 at 2:07 PM, Vicente J. Botet Escriba >>>> <vicente.botet(a)wanadoo.fr> wrote: >>>>> Please could you recall us what "not in the present form" meant as a >>>>> result >>>>> of the review and what has been done to overcome these issues? >>>> http://lists.boost.org/boost-announce/2014/01/0393.php >>>> >>>> I have not yet tried to address those point by point. >>> I don't understand then why are we doing the mini review now, before >>> you >>> check that any point has at least tried to be addressed. >> Sorry. How about these points: >> >> Performance: Oliver has not only worked to improve performance, he has >> included and documented performance tests you can run on your own >> hardware. > Great, I will check. > See below. >> Documentation: The documentation now contains several new sections >> explaining how to use the library for interesting/common use cases. >> New examples are presented and documented. > See below. >> >> API: The API has been aligned more closely with std::thread. C++14 is >> not only supported but required. Move-only callables are supported. >> Variadic parameters are supported. std::chrono is more generically >> supported. Channels now support value_pop(). fiber_group has been >> dropped. Migrating fibers between threads has been dropped. > See below. >> That said, of course, it is up to each reviewer to state for him- or >> herself whether s/he believes that the Fiber library should become >> part of Boost. In particular, regardless of what Oliver or I might >> synopsize, it is up to each previous reviewer to decide whether his >> January 2014 objections have been addressed. > To be clear, I believe that by respect to the reviewers you should > take the review summary you wrote and add a comment for each point. > > Best, > Vicente Hi again, In addition to my last request and in order to be able to write a review, I would like to know what exactly has been changed since the first review, what was expected after the review summary and what was removed, changed or added and what was the rationale. Best, Vicente

2 1

[android] New compilers: gcc-5.2 and clang-3.7
by Dmitry Moskalchuk 03 Sep '15

03 Sep '15

Hi all, We've added new compilers into CrystaX NDK recently: gcc-5.2 and clang-3.7 (old gcc-4.9 and clang-3.6 still there too). Testing results should appear on Boost regression page in a few days. Both compilers have fully passed our automatic tests, but you know, there still could be bugs, especially in such complicate projects. We're asking all maintainers of the Boost libraries look on that results and report us bugs (if any) to https://tracker.crystax.net/projects/ndk. The most important for us is catching regressions caused by new compilers compared to theirs previous versions. In case of such bugs, please don't add workarounds into Boost code; better report and let us fix them in CrystaX NDK. Thank you. -- Dmitry Moskalchuk

1 0