- Boost - lists.boost.org

[gsoc2020] New here
by Siddhant Jain 22 Dec '19

22 Dec '19

Hi, my name is Siddhant I am a first year CS student at IIIT Hyderabad. I am interested in learning more about and contributing to boost. I have visited the obvious beginners links but I am unable to grasp the library to the level where I can contribute code. What would be the suggest plan of action to get comfortable with reading and write code used in boost. I am interested in working on Boost.geometry and/or Boost.real. Thanks

1 0

[move][core] boost::swap() vs boost::adl_move_swap()
by Andrzej Krzemienski 21 Dec '19

21 Dec '19

Hi Everyone, I am seeking an advice. I recently got this pull request: https://github.com/boostorg/optional/pull/77 changing the boost::swap() to boost::adl_move_swap() because it should compile faster. Is there any recommendation for Boost libraries which one to prefer and under what circumstances? boost::adl_move_swap() seems to allow moves rather than copies in more cases. On the other hand boost::swap() seems to have other improvements, like BOOST_GPU_ENABLED. Regards, &rzej;

2 1

boost::python::def_visitor alignment / padding crash.
by Janek Kozicki 20 Dec '19

20 Dec '19

I have discovered an alignment related bug in boost::python::def_visitor For a very detailed description see https://gitlab.com/libeigen/eigen/issues/1795 * a minimal failing example: https://gitlab.com/cosurgi/minieigen-real/blob/minimalFailingExample/src/mi… * and the failing CI pipeline: https://gitlab.com/cosurgi/minieigen-real/pipelines/104745741 Initially I thought that it was related with libeigen. But it turns out that it crashes even without libeigen, when just using boost::multiprecision::float128. The code crashes with g++ 8.3.0 and works with g++ 9.2.1 boost version 1.67 is used there. should I open an issue on boost github? best regards -- # Janek Kozicki http://janek.kozicki.pl/

1 1

[appveyor] Really slow turnover
by Edward Diener 20 Dec '19

20 Dec '19

When I started out in computer programming some 40 years ago you could submit a job, with some JCL, on an IBM mainframe computer via an input card reader and you were lucky if you got back the result a day later. How happy I was when I went to microcomputers and could get almost instantaneous results from any programming attempt. Fast forward to now, some 40 years later, and it seems like nothing changes, despite the great advancement in computer technology and online access in our current age. Attempting to run CI using Appveyor literally has jobs queued pending a run for days and days. Surely there must be something better in this day and age than this ridiculously slow internet service. Is it 1979 again ?

7 18

[review][STLInterfaces] review extended to Dec. 23
by Barrett Adair 20 Dec '19

20 Dec '19

The formal review of STLInterfaces is extended to December 23. Please consider submitting a review if you can.

1 0

Re: [boost] Jason is getting MARRIED!
by Bjorn Reese 20 Dec '19

20 Dec '19

On 11/16/19 7:09 PM, Vinnie Falco via Boost wrote: > My JSON library is going to propose to Boost soon, is there anyone who > might be willing and able to function in the role of review manager? Before we get to that point, there are some questions that the community should address. These days there are a huge number of JSON libraries out there. Some focus on features (e.g. binary JSON or JSONPath), others on performance, and others on user-friendliness. What competitive edge should a potential Boost JSON library offer? Which use cases should a potential Boost JSON library support? Should the library work seemlessly with standard algorithms? Should it be possible to create parser combinators? Should there be a JSON archive for Boost.Serialization? Should it replace parts of Boost.PropertyTree? PS: On a procedural note, you need an endorsement of the library before seeking a review manager.

10 68

GSoc 2020
by Aniswar SK 19 Dec '19

19 Dec '19

Hello everyone, I am Aniswar Krishnan, a 2nd year Computer Science student at Indian Institute of Technology, Madras. I am have been coding in c++ and python for the past 15 months. I am interested in Mathematics and Algorithms and have done courses on same along with Data Structures, Linear Algebra. I got interested int the projects like Boost.Real and Boost GIL and would like to contribute more to the community. Please guide me and share the relevant resources needed. Will be grateful. Regards, Aniswar Krishnan II Year Computer Science IIT Madras Chennai, Tamil Nadu

3 2

Re: [boost] Proposed legacy macro renaming policy
by Glen Fernandes 18 Dec '19

18 Dec '19

I've fixed the macros in: * boostorg/multi_array * boostorg/iterator * boostorg/parameter * boostorg/polygon Glen

2 1

What to do about Boost libraries which use user-defined macros which are not BOOST_ prefixed
by Niall Douglas 18 Dec '19

18 Dec '19

Acting on guidance given to my recent supply to this list of unprefixed macros, namespaces etc injected into the global namespace by Boost, I have logged a list of all issues with each library, and linked to all those from a single issue logged at https://github.com/boostorg/boost/issues/352. A problem has arisen which requires input from boost-dev. Some Boost libraries define as part of their public API a non-BOOST_-prefixed macro which changes the definition of their header files e.g. PHOENIX_LIMIT (just to be clear, Phoenix is not the only library doing this) If we change such macros to be like BOOST_PHOENIX_LIMIT instead, all existing code using Boost which sets PHOENIX_LIMIT would potentially *silently* break. What we could decide to do instead is: #if defined(PHOENIX_LIMIT) && !defined(BOOST_PHOENIX_LIMIT) #error In Boost 1.xx PHOENIX_LIMIT was renamed to BOOST_PHOENIX_LIMIT. Please upgrade your code to reflect the new name. #endif Or one could just leave PHOENIX_LIMIT named as is. What would Boost developers prefer we do? Niall

8 19

Re: [boost] [review] [STLInterfaces] STLInterfaces review starts today
by Hadriel Kaplan 18 Dec '19

18 Dec '19

Howdy, For this review I've really only tried out the iterator_interface part. I'm sorry I can't provide feedback on the container_interface nor view_interface, as I just don't have the free cycles. > - Your name Hadriel Kaplan > - Your knowledge of the problem domain I've been using boost's iterator_facade and adaptor for a long time; I've written my own custom iterators as well, of both traditional and proxy-types. The usual stuff. > - Whether you believe the library should be accepted into Boost (be clear about this) Definitely. It could use word-smithing and minor cleanup stuff, but presumably that happens later. (?) > - What is your evaluation of the library's > * Design? Good overall. > * Implementation? Good. I've got some nitpicks, but honestly none are a big deal. minor nitpicks: 1) I didn't use the proxy_iterator_interface one, only looked at the code. The proxy_arrow_result storing a local T value that it only returns a pointer to, means it's not optimal in some cases. Obviously for something like std::vector<bool> it won't matter, but some value-types are not so lightweight. On the other hand, it looks like we can specialize this for our type (or not even use proxy_arrow_result to begin with)? 2) Can the stuff in fwd.hpp be split out? I could be wrong, but I don't think most of it is needed/used by iterator_interface, and only used by the other two, correct? Reducing what gets included would be nice, for people who don't need the container/view stuff. The old boost iterator_facade/adaptor headers included so much that it drove some people to stop using them; for example see the comments here: https://github.com/facebook/folly/blob/master/folly/detail/Iterators.h 3) This lib hasn't been tested for C++20, and obviously can't be yet, but it makes assumptions that it can safely replace some of its internals with C++20's new ones. Things like concepts and ranges. I'm not sure that's advisable, until all the major compilers support them and can be tested. It would be a shame if people using this lib can't upgrade to C++20 because it breaks this lib, until they upgrade boost as well. (not a big deal, just more noting it) 4) The files use a macro to control doxygen output. Is this still required for boost libs? Doxygen has had the cond/endcond commands for a long, long time. It's kinda ugly to see these macros, and kinda silly that everyone's compiler will be evaluating them all the time. (I know that's super-nitpicky) 5) I assume all the _has_include(<stl2/ranges.hpp>) checks will be removed, since that's a thirdparty header? 6) This lib requires C++14, but I don't see a macro checking that anywhere and providing a simple error to the user. 7) I can't decide if the BOOST_STL_INTERFACES_STATIC_ASSERT_ITERATOR_TRAITS() thing is a good idea or a waste of time. I tried it, it passed. But of course it did, because it's just checking that I got the API that I told iterator_interface to create, no? This just seems like needless repetition to me. I mean if I screwed it up to begin with, I'll screw it up in this macro too, no? But maybe I'm missing something obvious. (could be - it's getting late) > * Documentation? It's OK. I enjoyed some of the humor. :) It's missing some info for things that are customization points. For example base_reference() is shown in an example, but not really documented anywhere as far as I can tell. The tables aren't as useful/explanatory as one would hope. I mean I knew what they meant, but I'm not sure someone newer to this area would. (but then again, that's what blogs/articles are for I guess) I think it might also help if there were some explanation for what happens under-the-hood, in terms of what public methods get auto-generated from what, for which iterator types. For example, it's surprising that for a bidirectional iterator the user defines operator==(), but not for random-access iterator. (that particular case happens to be mentioned in a note, but you get my point) There are also typos and such, but I presume that gets checked later. > * Tests? Good. I copied them over and ran them as well. (but not the v2 tests, nor the ones for container_interface or view_interface) I think it would be better if there were some tests for iterator_interface with non-copyable value-types. Testing it only for `int`s is cheating. :) Also, random question: for the container_interface, did you try using it with the boost::fixed_string (or static_string, or whatever it's called)? I mean that _is_ a contiguous container, and it's in boost review too, so might it be a good test candidate? :) > * Usefulness? Very useful. iterator_facade/adaptor were showing their age. It's time for something new and shiny. I was happy that it reduced the number of functions we needed to implement in our current usages from 5 to 3. > - Did you attempt to use the library? Yup. I replaced three existing boost::iterator_facade usages in my company's code-base with this one, to try it out. Ran our unit tests with and without valgrind as well. But to be honest these weren't very complicated iterators. I did _not_ try replacing boost::iterator_adaptor, but I hope to try that eventually. > * Which compiler(s)? (old ones, so I could build my employer's codebase and run all their unit tests...) 1) gcc 7.3.1 with c++17 2) clang 5.0.0 with C++17, using gcc's libstdc++ Both using boost 1.55 (sorry!), with the stl_interfaces headers copied over manually, without using the CMake files in the github repo. Neither compiler has the early Concepts support. > * What was the experience? Any problems? Not really. The hardest part was figuring out the new model of what the derived had to define, compared to iterator_facade. (i.e., I was so used to the old model that it took me a bit to grok this one) > - How much effort did you put into your evaluation of the review? Only a few hours, maybe 4-5 total. Sorry, I wish I had more free time. :( > - Do you like the name container_interface? sequence_container_interface > is more precise, but seems a bit long. I'm not sure the length matters much for this use-case, as it's a one-time thing (generally), and not used by users of the actual container; and can anyway be aliased. (I mean, the "stl_interfaces" sub-namespace is annoying too, but it's not a big deal in my opinion) > - Would you use something like container_interface, but for associative > containers? If so, should it assume a node-based interface, a la std::map > and std::set? This assumption would preclude alternative associative > container-like types, such as flat_map. Yes I think so, depending on what it did... but for *unordered* ones (i.e., hash-maps/sets), rather than rb-trees. I often find myself encapsulating them, and then having to write a lot of boilerplate public member functions. And several functions can be boiled down for hash-maps. For example count() and contains() can just use find(). I don't know why an unordered_container_interface wouldn't be do-able, including heterogenous lookups, for various hash-map/set flavors. (except, of course, that boost::unordered_map/set's API is different than std's for heterogeneous lookup; which is unfortunate) -hadriel

1 0