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

[config] clang on Windows and BOOST_SYMBOL_EXPORT problem
by Edward Diener 15 Feb '15

15 Feb '15

I have been recently discussing a problem regarding clang on Windows on the clang developers mailing list, but without any final resolution yet. This problem affects those using clang on Windows with Boost along with exported classes. This combination occurs when testing Boost.Test but I imagine also occurs with other Boost libraries and of course could affect Boost end-users using clang on Windows. The problem does not occur with clang on Linux for reasons which shall be understood in the explanation. The bug manifests itself in such code, compiled with clang, as: #include <boost/config.hpp> #include <boost/scoped_ptr.hpp> class BOOST_SYMBOL_EXPORT AClass { boost::scoped_ptr<int> sp_pointer; }; int main() { return 0; } On Windows for clang the BOOST_SYMBOL_EXPORT becomes __declspec(dllexport) whereas on Linux it becomes __attribute__((__visibility__("default"))). Clang decides with __declspec(dllexport) or its equivalent __attribute__((dllexport)), but not with __attribute__((__visibility__("default"))), that after generating a default copy constructor and assignment operator for a class which has not defined is own, even if an object of that class is never copied or assigned, if the default copy constructor or assignment operator is invalid the compilation is in error. Since the above class has a member which is non-copyable and non-assignable we get errors from clang along the lines of: > test_clang_bug.cpp:3:1: error: field of type 'boost::scoped_ptr<int>' has private copy constructor > AClass { boost::scoped_ptr<int> sp_pointer; }; > ^ > ..\..\..\boost/smart_ptr/scoped_ptr.hpp:47:5: note: declared private here > scoped_ptr(scoped_ptr const &); > ^ > test_clang_bug.cpp:3:1: note: implicit copy constructor for 'AClass' first required here > AClass { boost::scoped_ptr<int> sp_pointer; }; > ^ > test_clang_bug.cpp:3:1: error: 'operator=' is a private member of 'boost::scoped_ptr<int>' > AClass { boost::scoped_ptr<int> sp_pointer; }; > ^ > ..\..\..\boost/smart_ptr/scoped_ptr.hpp:48:18: note: declared private here > scoped_ptr & operator=(scoped_ptr const &); > ^ > test_clang_bug.cpp:3:1: note: implicit copy assignment operator for 'AClass' first required here > AClass { boost::scoped_ptr<int> sp_pointer; }; > ^ > 2 errors generated. I have argued on the clang developers list that requiring C++ programmers to provide a default copy constructor for a class whose object is never meant to be copied or a default assignment operator for a class which is never meant to be assigned, even if that means private declarations in C++03 or deleted declarations in C++11, can never be a good idea and goes against the C++ standard. The clang answer has been that exporting classes is outside the C++ standard so the C++ standard rules do not apply in this case. Note again that having BOOST_SYMBOL_EXPORT become __attribute__((__visibility__("default"))) for clang on Windows targeting mingw/gcc fixes this problem for that compilation environment. In fact for gcc using mingw/gcc we do indeed use __attribute__((__visibility__("default"))) and that works fine with mingw/gcc in the exact same exporting situations. Similarly for VC++ compilation having BOOST_SYMBOL_EXPORT be __declspec(dllexport) works fine also. I have not yet been able to get from clang developer why exporting a class using __declspec(dllexport) or its equivalent __attribute__((dllexport)) works the way it does, but using __attribute__((__visibility__("default"))) gives no problems. The discussion still appears to be ongoing. Do we want to change BOOST_SYMBOL_EXPORT on clang with Windows targeting mingw/gcc to specify __attribute__((__visibility__("default"))) as we do with mingw/gcc ? It is a fairly simple change which I can make. I just wanted to bring this whole issue to the attention of Boost before I implement any change. I am of course still hoping tha clang changes the way it views the exporting situation and still think they are wrong.

2 5

[GSOC] Devector project
by Divyansh Gupta 15 Feb '15

15 Feb '15

Hi all, I've been following the mailing list for a few months and I wanted to know more about the Devector project idea that was being discussed last week. I couldn't find it on the 2015 ideas page so I read about it on the 2009 page and I'm really interested in doing it as a GSOC project. So then I also read the segmented iterators paper and the std::vector and std::deque references. I found an existing implementation of devector on GitHub ( https://github.com/orlp/devector/blob/master/readme.md) Some of the shortcomings of this implementation as per the 2009 ideas page: 1. Does not provide reference stability on insertion since it's just one continuous block of memory which has to be reallocated in its entirety. 2. Hence obviously does not provide option for setting chunk size or use segmented iterators. I was hoping that the devector idea is added to the 2015 ideas page with a competency test since I don't have any open source contributions besides the research projects in my institute. But I'm a quick learner and am confident that I can prove my worth through a competency test. Thus I kindly request Thorsten or Niall to please add devector to the ideas page and provide a competency test if possible. Regards, Divyansh Gupta, Sophomore Undergraduate Student, Indian Institute of Technology - Kharagpur

1 0

[PropertyTree] In-Memory Performance of Xml/Json Serialization?
by john smith 15 Feb '15

15 Feb '15

I'm personally more interested in the Xml characteristics, but I have noticed that the JSON parsing is much slower as it doesn't use rapidXml. The implementation of the JSON and XML read/write methods both use std::basic_*stream which is slow for in-memory usage. In the xml methods there also appears to be a strong assumption that "Key" is a std::string which then follows that the "Ptree::key_type::value_type" is of type char. Is there or would there be any opposition to the development of more performant write_xml() and read_xml() methods for in-memory use? These new performant overloads could either use std::string or char* directly instead of the slower stringstream classes? If the Key template argument is an std::string, the *printf* c-style methods could be used to improve performance and eliminate the locks that stringstreams uses. There is already an std::string based arg set that is used for a filename, so that would need to be overcome.

1 0

Re: [boost] GSOC 2015 : Project on Concurrent Hash Tables
by Amarnath V A 14 Feb '15

14 Feb '15

Hello Nial, I am a graduate student from India and I have spent some time looking into the boost GSoC page for last few days. And concurrent hash tables project has grabbed my attention. I would like to see if I am competent enough to contribute to the project. First of all, like you had mentioned in the mailing list to another prospective candidate, I have got the source code and compiled the unit tests. And they are passing as expected (as far as I understand). I have a few questions regarding the code base before I jump in try to complete the test. 1. As I have experience only on C++98, I am not sure what is the purpose of the move constructors. Reading up on internet gave me fair idea about move constructors in general. In our context, is there anything specific to be taken care? Could you provide few ideas of what is the expected result of the move? The important question I have is should the move rehash all the hashes? (Is that why you were mentioning about rehash()?) 2. Similarly, does the copy constructor need to just perform a deep copy of the hash table? Or should it also perform a rehashing? 3. Could you also point me to any white paper or publication that gave you how to go about with the implementation of concurrent_unordered_map? 4. Being a Linux user, I am using Ubuntu as my dev box. I have currently build the source code using gcc v4.8.2 and clang v3.4. Is this fine? Sorry if my mail ends up as a cross post. I am new to this list. And thanks for bearing with my (maybe silly) questions. Thanks, Amarnath

2 1

Re: [boost] [gsoc15] Proposal
by Ganesh Prasad 13 Feb '15

13 Feb '15

The METALISCPP project was only a starter. My idea was to implement a very minimal syntactical abstraction over the metaprogramming constructs and build a prolog like library over it. As you can see, the METALISCPP simply uses macros to hide all those long template-based codes and provide an easier and more convenient syntax. The main motivation behind it was to have a library that would handle polices, inheritance, complex dependencies and such conveniently at compile time with a logic oriented syntax. Then I started thinking about extending the idea for a complete First Order Logic Programming Library and got stuck there. If you are willing to mentor it this year, we can try to improve the performance and syntactically modify the metalog library, maybe we'll end up with something as convenient as Boost::Phoenix. Best Wishes Ganesh PS I've forked metalog and trying to figure out what useful things can be done with it in 3 months time.

2 1

Asking for boost.persistent source code
by Yichao Zhang 13 Feb '15

13 Feb '15

Hi, I ran into the boost.persistent library the other day and think it got a really neat interface, and the transactions are exactly what I had in mind when I look for a persistent library. The code is not in the sandbox, but I really would like to have a copy of it. It would be nice if the original author can drop me a tarball. Thanks in advance, Yichao

1 0

[gsoc15] Attn: We need 2015 mentors and project ideas for Boost!
by Niall Douglas 12 Feb '15

12 Feb '15

Dear Boost community, We are now within one month of the beginning of Google Summer of Code 2015! Last year's GSoC furthered the continuing success of the Boost GSoC programme with the first ever Boost funded extension to a GSoC project (that being Boost.Hana by Louis Dionne mentored by Joel Falcou, congrats to both of them on passing an exceptionally tough selection process), and over $50,000 of Google funding brought to Boost in 2014. We also sent three representatives to last year's mentor summit, including one student whose entire expenses the Boost Steering Committee very generously covered. As part of filling in our application for 2015, we must supply to Google a list of potential GSoC mentors and potential GSoC projects for summer 2015. There are a number of changes to how we design project ideas for students this year intended to improve the GSoC experience for both students and mentors, so please examine the ideas page which outlines those changes at https://svn.boost.org/trac/boost/wiki/SoC2015 and if you have any questions or concerns about those changes, please ask now rather than just before the GSoC deadline. If you think yourself able to mentor a student doing some work on Boost this summer, *please* consider adding a description of the proposed work item and your name to the list. Last year we acquired eight slots from Google and had to disappoint two mentors and students, we hope with the improved selection process we can get back to the ten annual slots we once had. If you want to know more about mentoring a Google Summer of Code funded student work before you nominate yourself, please feel free to ask on the main Boost developers mailing list boost(a)lists.boost.org. Thank you in advance for your time. Niall Douglas (Boost Google Summer of Code admin) Boris Schäling (Boost Google Summer of Code admin) --- Boost C++ Libraries Google Summer of Code 2014 admin https://svn.boost.org/trac/boost/wiki/SoC2014

7 19

[gsoc15] Proposal
by Ganesh Prasad 12 Feb '15

12 Feb '15

Now that we are rather well ahead with the phoenix library, I propose to develop a compile-time Logic Programming library for boost. I understand that a handful of months during GSoC15 are not enough for developing a complete and usable library, but the foundations of the library can be laid during this GSoC. I have some experience with writing a small compile-time library for functional programming with a LISP like syntax. That can be found at https://github.com/GnsP/GNS--META_LISCPP . Currently I am trying to identify the requirements for a decent compile-time logic library. If it could be acceptable as a GSoC project (I don't know, the idea is pretty big one for 3 months), I'll be back with an initial design of the proposed library. Best Wishes Ganesh Prasad PS I had been planning on this library since last year, I am positive that this project is feasible (though Logic programming would require non-determinism, it can be handled to some extent with template metaprogramming, I'm still working on it).

2 1

Re: [boost] [polygon] voronoi diagram in a bounding box
by Dan Chen 11 Feb '15

11 Feb '15

Hi Andrii, This helps. Thanks a lot! Dan

1 0

GitHub third-party application permissions
by Vladimir Prus 11 Feb '15

11 Feb '15

Hi, the GitHub boostorg organization is configured in a way that any application authorized by any organization member will have full access to boostorg data. Is that desirable? I've noticed accidentally, and don't know much about github permission model, but it seems that all authorized applications will have access to all repositories the user has, there does not appear a way to limit either repositories or operations. Comments? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

1 0

Cleanup of test results.
by Rene Rivera 11 Feb '15

11 Feb '15

Just an FYI for testers and authors.. I implemented some changes to the report generation that: a) Expires old results to not be shown in the results. I'm considering old to be anything past two weeks of age. This applies to all branches (i.e. develop and master). b) Filtering of master, aka release, results to only include an approved list of testers. This brings in some explicit control to what is considered the release toolsets. Which is something we used to enforce, but lost after the git transition. So it's back now. Rene. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 3

[GSoC 2015] Boost Document library development
by amitoj singh 11 Feb '15

11 Feb '15

Hello, My name is Amitoj Singh. I am pursuing B.Tech form Guru Nanak Dev Engineering college. I would like to work on Boost Document library Development. Can I have a more details on this project so that I can submit my first patch. Thanks! Regards! -- "Never repeat yourself" Amitoj singh slideshare.com/amitoj95 github.com/amitojsingh amitojsworld.wordpress.com

1 0

Re: [boost] [polygon] voronoi diagram in a bounding box
by Dan Chen 10 Feb '15

10 Feb '15

Hi Andrii, I'm implementing a Lloyd's algorithm to get a centroidal Voronoi tessellation of a box. In this algorithm, I need to get the voronoi cells in the box, and find the centroids of these cells. Thanks,Dan

2 1

[gsoc15] Google Summer of Code 2015 ideas needed before 20th Feb
by Niall Douglas 10 Feb '15

10 Feb '15

Dear Boost community, The Google Summer of Code 2015 organisation application period has begun. We need project ideas for our ideas page at https://svn.boost.org/trac/boost/wiki/SoC2015, plus anyone willing to mentor. Last year we got eight slots, the previous year seven slots. Let's try to get back to ten slots for 2015! Niall & Boris --- Boost C++ Libraries Google Summer of Code 2015 admin https://svn.boost.org/trac/boost/wiki/SoC2015

1 0

Regression testing: too many runners?
by Dmitry Moskalchuk 09 Feb '15

09 Feb '15

Guys, As you may know, I'm working on automatic regression testing of Boost on Android. I spent several weeks debugging it and now it seems to be close to the finish - i.e. we'll have soon fully automatic 24x7 regression testing with uploading all results to the Boost public FTP. As you can see, some results are already uploading on a regular basis - http://www.boost.org/development/tests/master/developer/summary.html (there are results of just few libraries at the current moment since I've limited testing by only those libraries to save time needed for debugging testing scripts; as far as I finish with my debugging, I'll enable testing of all libraries). However, I've realized that for thorough testing matrix of the variants become really big. Look, right now there are nine runners for Android, and this number is in fact very limited. They differs by target ABI (three arm variants, x86 and x86_64) and version of Android (API level 19 - Android 4.4 and 21 - Android 5.0). However, it has sense to test also on Android 4.0, 4.1, 4.2 and 4.3 since theirs market share is still large (see https://developer.android.com/about/dashboards/index.html) Add to that MIPS target ABI (not yet included to the testing) and multiple by two to have tests running with both default settings and with -std=c++11 - and you'll get really big total number of runners. I'm asking for advice from community. It's not the big problem for us to run all such tests in all variants, but I'm unsure if it will be acceptable for Boost community to see such wide table of runners. I'm afraid it will look like a flood. We also publish Android-only results on https://boost.crystax.net/master/developer/summary.html and we'll definitely display all results from all runners there. Please let me know if the same approach would work for http://www.boost.org/development/tests/master/developer/summary.html or should I limit somehow runners to be uploaded to the Boost FTP. -- Dmitry Moskalchuk

4 5

[githelp] Relative submodule paths..
by Rene Rivera 09 Feb '15

09 Feb '15

I've been trying to clean out the pull requests for the boost super-project and I ran into this one <https://github.com/boostorg/boost/pull/33>. And I don't really know if it makes sense, as I have personally not done a fork of the super-project. Is it a real problem? Should we change all the sub-project references? If yes, what are the likely impacts on others and existing release processes? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 5

[polygon] voronoi diagram in a bounding box
by Dan Chen 08 Feb '15

08 Feb '15

Hi all, I am not sure whether this is the right place to ask this question. Basically, I want to compute the the voronoi diagram of a set of points in a bounding box, and output the voronoi cells. My idea is, after getting the voronoi diagram vd of the point set, for each voronoi cell in vd, compute the intersection of the cell and the bounding box. I am wondering whether this can be done in a better way with the boost libraries. Thanks,Dan

2 1

[voronoi] Issue with boost::polygon::voronoi_diagram<> as class variable
by duke 08 Feb '15

08 Feb '15

For some reason when I have a voronoi_diagram as a class variable (which it needs to be in this case), I get this error on compile: Error 49 error C2248: 'boost::polygon::voronoi_diagram<T>::operator =' : cannot access private member declared in class 'boost::polygon::voronoi_diagram<T>' I'm new to C# so it may be something obvious. - George

2 1

[MPL] Advice on how to proceed with a bugfix pull request
by Bruno Dutra 08 Feb '15

08 Feb '15

Hello everyone, I've found a fix to this bug <https://svn.boost.org/trac/boost/ticket/7769#no3>, which is based on BOOST PP library and thus should be supported across the various platforms, even though I just tested for a specific set up as I mentioned on my comment there. I've added some code snippets, from which it is straightforward to develop a patch, but I guess it would be best if I just issued a pull request myself. Since this is my first time contributing to MPL and to BOOST itself for all that matters, I'd like to first hear some advice on how to do this properly. For instance, to which branch should I issue the pull request? By the way, is this indeed the best way to proceed at all? Kind regards, *Bruno C. O. Dutra*

2 2

A proposal
by Mudit Sharma 08 Feb '15

08 Feb '15

After creating QR,LU and Cholesky for Boost..can we develop algorithms for determining which of QR,LU,Cholesky..etc. should be used in solving linear equations based on analyzing the running time and numerical stability specific to the problem. Is it feasible? Thanks!

2 1

Re: [boost] A proposal
by Ganesh Prasad 08 Feb '15

08 Feb '15

LU is already implemented in UBLAS. As of QR, SVD and Cholesky you might want to spend more time in debugging and testing for any one or two of the algorithms. https://github.com/GnsP/viennacl-dev/tree/master/viennacl/linalg you can find some useful sources here. Best wishes Ganesh

1 0

[c++11] MSVC does not define __cplusplus?
by Oliver Kowalke 07 Feb '15

07 Feb '15

Hi, I encountered that '__cplusplus < 201103L' evaluates on MSVC (14.0 ...) to true?! At least on GCC + CLANG this test works - what about MSVC? best regards, Oliver

4 4

[new libraries] [sort] New Library Check list updated
by Beman Dawes 07 Feb '15

07 Feb '15

As we started through the process of adding the sort library as a module, it became obvious the docs for how to do this were quite out-of-date. The best document for adding new libraries is https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList#New…, and that section has now been updated. Although this document is written from the perspective of release managers, the New Library Checklist section serves as a roadmap for what is expected as a new library goes through the stages of being added to a Boost distribution. Comments and corrections welcome, --Beman

5 6

Serialisation: Is is_trivial<T> a sufficient precondition to bypass serialisation?
by Niall Douglas 06 Feb '15

06 Feb '15

A library user has raised an interesting question at: https://github.com/BoostGSoC13/boost.afio/commit/ac32ebfceb9a08b133e8c d47000d3b4807bc3e42#commitcomment-9574522 Basically, AFIO v1.3 has new pre-serialisation metaprogramming in response to Robert's comments on his Incubator about it being too hard to serialise and deserialise data with AFIO. AFIO will now consume any STL container and will implicitly auto expand to ASIO scatter gather buffers any: 1. Trivial type T 2. C array of trivial type T 3. STL container of trivial type T, including initializer_list. A free function, to_asio_buffers(T), can be specialised by external code to extend this with custom ASIO scatter gather buffers generation. Note that AFIO explicitly and intentionally expects that anyone interested in async file i/o will be doing their serialisation and endian conversion far away from AFIO code, so to_asio_buffers(T) is really for marking extra types to be treated as implicit auto expand. The user asks the question: Is is_trivial<T> a sufficient precondition for this auto expansion to be safe, or should is_standard_layout<T> also be required? The user notes that is_trivial<T> && is_standard_layout<T> == is_pod<T> which seems a little overkill to me. There is also the possibility that is_trivial<T> is too conservative. Some may argue that is_trivially_copyable<T> would be sufficient. Thoughts? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

5 7

[release-mgt] missing library
by Oliver Kowalke 05 Feb '15

05 Feb '15

Hello, some weeks ago we discussed/decided that the C++11-only version of boost.coroutine should be a new lib -> boost.coroutine2. Daniel has already created a git-submodul inf the boostorg-repo and I've added the sources to branches master and develop. Unfortunately I'm missing coroutine2 (link) in <boost>/lib/coroutine2, entries in <boost>/libraries.htm and <boost>/lib/maintainers.txt. File <boost>/website/blob/master/feed/history/boost_1_58_0.qbk already contains announcement of boost.coroutine2. Could you execute the missing steps to add coroutine2 to release 1.58 please? best regards, Oliver

3 3