- Boost - lists.preview.boost.org

What happened to Boost.Nowide?
by Alexander Grund 08 Jan '20

08 Jan '20

Hi, I'm a user of (a fork of) Boost.Nowide and already fixed some issues I found and was looking into getting them upstream. I also wanted to know, if it is finally in Boost. Unfortunately this does not seem to be the case. I found https://lists.boost.org/Archives/boost//2017/06/236475.php which accepted it into Boost. This is from mid-2017 and nothing has happened since. Does anyone know what the status of Boost.Nowide is? It seems the filestream parts are now incorporated into Boost.FileSystem. So it seems only cin/cout/cerr, the args wrapper and the C-functions (fopen, ...) are missing. Especially the first 2 are very useful in writing cross-platform code. Might those be integrated into some other Boost Library? Thanks, Alex

4 16

Retirement as Review Wizard
by Ronald Garcia 07 Jan '20

07 Jan '20

Dear Boosters and Boost Steering Committee, After roughly 14 years as a Boost Co-Review Wizard, I feel that the time has come for me to step down from the position, and make room for a new face with fresh ideas. It has been my pleasure to serve in this position for this time alongside first Tom Brinkman and now John Phillips. I look forward to seeing what the next 14+ years of Boost brings! Sincerely, Ron Garcia Boost Co-Review Wizard

8 7

Query on Project Multiprecision/Math GSoC 2020
by Christopher Kormanyos 06 Jan '20

06 Jan '20

Dear Boost Is there a place to post and describe a potentialGSoC 2020 project? We have a potential project for GSoC 2020. It involvessignificantly extending the precision of Boost.Multiprecisionand harmonizing these extensions and tests with Boost.Math.I have the proposal worked out in plain text and would liketo post it or share it. We have discussed this project (in PM) with the knownrecent authors and maintainers of Multiprecision and Math,and interest is strong. On a personal note, my name isChristopher Kormanyos, previous three-time Boost GSoCmentor. In previous years, I have also contributed to bothMath and Multiprecision. Thank you and kind regards, Chris

1 0

Re: [boost] Recommended way of generating documentation
by pbristow＠hetp.u-net.com 06 Jan '20

06 Jan '20

> -----Original Message----- > From: Boost <boost-bounces(a)lists.boost.org> On Behalf Of Richard Hodges via > Boost > Sent: 1 January 2020 12:03 > To: boost(a)lists.boost.org List <boost(a)lists.boost.org> > Cc: Richard Hodges <hodges.r(a)gmail.com> > Subject: Re: [boost] Recomended way of generating documentation > > Treading carefully here as I'm new to boost library maintenance... > > > So that you can cross-reference the Doxygen reference with whatever > > other > documentation you have > > http://www.doxygen.nl/manual/autolink.html suggests that links to external URLs > are recognised by doxygen. Presumably linking to the correct place vis-a-vis > release/developer builds can be controlled with a macro in a generated Doxyfile? > > > And it's Doxygen to XML, XML to Boostbook. Then of course Boostbook to > Docbook, and Docbook to HTML. > > Other than the very pleasing boost documentation styling, is this seemingly > convoluted conversion route necessary? Is it not possible to configure a Doxyfile to > contain the correct styling? > > I have no knowledge of the evolution of boost documentation and have no axe to > grind, but as a newcomer it seems to me that there is a lot of 'unnecessary' > compication in the production of documentation. I appreaciate that there's no real > sense in revisting existing libraries, but for new ones wouldn't it be prudent to > choose the shortest possible path which involves the least learning and > maintenance? It depends on the size of the documentation. For 'trivial' documentation, the Doxygen and Markdown combination is acceptable, but I believe strongly that the best Boost documentation is done using the Quickbook toolchain (including Doxygen syntax comments to provide a references section). A killer feature of Quickbook is the ability to include code snippets from actual C++ examples that can be run, ensuring that what you get is what compiles and runs. As a mark-up language Quickbook is pretty obvious (apart from the gotcha of using indent-spaces as a way to add code sections - a common but quick'n'dirty markup feature that can cause some confusion). Paul

1 0

Boost ASIO
by live man 03 Jan '20

03 Jan '20

Hi, We have been using Boost for our firmware product which runs in ARM processor. However for development we make use of Visual Studio IDE. We also have our own TCP / IP suite which defines its own socket.h file. We are facing issue related to using Boost ASIO in Windows development platform. It seems that the library by default includes windows networking header files - which we do not want. Instead we want Boost ASIO to make our own library socket headers and declaration. We noticed that if we include Boost ASIO and our TCP / IP socket declaration we get re-definition error and compilation fails with lots of errors? Please let us know how we can resolve the issue with the objective mentioned above? Thanks in advance. Regards, Prakash

2 2

Google Summer of Codes 2020
by saloni garg 02 Jan '20

02 Jan '20

Hello, My name is Saloni Garg. I am an undergraduate student of B.tech in computer engineering. Currently, I am in my second year and I am looking forward to participate in this year's Google Summer of code 2020. So, I want to know, if Boost organization is planning to be a part of this year's Google Summer of codes 2020? Thank you! Saloni Garg

1 0

Recomended way of generating documentation
by Alexander Grund 01 Jan '20

01 Jan '20

Hi, I'm currently in the process of generating documentation in a Boost usable format and got a couple questions. The documentation is currently in-source in Doxygen format and has a markdown file for the start page. 1. Which aliases do I need and for what? I've seen boostdoc and boostrelease but couldn't find a description what and why they are 2. Where do the documentation files need to go? It seems using BJam naively outputs them to bin.v2 not to the libraries doc folder which I'd even see useful because generated files should not clobber the source tree 3. What benefit is there going from Doxygen (over multiple conversions) to boostbook? Can't I just go from Doxygen to HTML? 4. If the above: Calling `doxygen mylib.html` in BJam generates a mylib folder and a mylib.html redirecting into that folder. Both hardcoded to go into a subfolder of bin.v2. How is that useful/useable? Wouldn't I want a 'html' folder and an index.html redirecting to the index.html contained or no redirection file at all? 5. As I'm thinking about calling doxygen manually: Do I need to do anything so e.g. mylib shows up in boost/doc/html? Why is only a subset of the libraries there? Thanks for any help or pointers! Alexander Grund

6 5

Boost-GIL GSOC 2020
by Siddhartha Sen 31 Dec '19

31 Dec '19

Hello, I would like to propose an idea for GSOC 2020. I would like to re-implement pre existing features in Boost-GIL for example inverting an image, conversion from black and white to colour and vice versa, etc, but with the usage of parallel programming in order to improve the efficiency and speed things up. This is nothing but an idea merely, as I have some idea with parallel programming beforehand. Could anyone give me some guidance as in how to proceed with this? And also do you all think this is a good enough proposal? I already have built a couple of libraries for image conversion using openmp, but I am not sure whether they are boost compatible or not. Thank You.

2 1

Re: [boost] [review] [STLInterfaces] STLInterfaces review starts today
by Andreas Wass 28 Dec '19

28 Dec '19

This my small review of STLInterfaces, and mainly iterator_interface > - Your name Andreas Wass > - Your knowledge of the problem domain I implement mainly iterators every once in a while, both at work and for personal projects. I have mainly used iterator_interface but used container_interface as well. > - Whether you believe the library should be accepted into Boost (be clear > about this) Yes, it helps cutting down on the amount of boilerplate to write. > In addition, you are strongly encouraged to answer the following questions: > - What is your evaluation of the library's > * Design? The design seems solid > * Implementation? Looks solid as well, only had one issue with container_interface (see below). > * Documentation? It is ok. As someone who isn't implementing containers all that often it would be nice to have signatures as well as expressions listed in the container_interface documentation > - Did you attempt to use the library? If so: > * Which compiler(s)? MSVC 2017 and GCC 9 > * What was the experience? Any problems? One problem with container_interface. See https://github.com/tzlaine/stl_interfaces/issues/12 > - How much effort did you put into your evaluation of the review? About two hours implementing iterators and a container

4 5

[review][STLInterfaces] STLInterfaces review results
by Barrett Adair 26 Dec '19

26 Dec '19

Many thanks are owed to all who participated in the formal review of Zach Laine's STLInterfaces library, especially during this busy holiday season: * Hadriel Kaplan - ACCEPT * Andreas Wass - ACCEPT * Rainer Deyke - ACCEPT * Arthur Gruzauskas - ACCEPT * Krystian Stasiowski - ACCEPT * Daniela Engert - CONDITIONALLY ACCEPT * Gavin Lambert - Technical comments First, a summary of the reviews: 1. Design Reviewers were unanimous in their appreciation for the design. Krystian had the only asterisk about the design, noting that derived class members should ideally be SFINAE-detected, where the library feature would SFINAE where the corresponding required derived feature detection fails. I have a different opinion about this, but we can discuss that elsewhere. 2. Implementation The container_interface destructor and the optional dependency on cmcstl2 were snags for multiple reviewers. Several compile errors were discovered that need to be addressed. 3. Documentation Reviewers found the documentation to be "ok". A common request was for better organization of derived-class requirements, particularly with the container_interface template. Reviewers also lamented the lack of training wheels for the subject matter. 4. Tests Hadriel noted the lack of non-copyable value_type tests, while Daniela noted the lack of Boost.Build support. Hadriel was the only one who commented on the quality of tests ("good"), and the only one who ran them. Arthur did his own testing, to satisfaction. I appreciate the presence of SFINAE-friendliness tests and the continuous integration. 5. Usefulness Reviewers appreciated the usefulness of the library. Arthur is "using it happily", while others found it "very useful", "fairly useful", or of "high" usefulness. However, Krystian's response implied that this library may not be as useful for containers needing extreme performance. The reviews clearly demonstrate a consensus. Accordingly, I'm pleased to announce that STLInterfaces is CONDITIONALLY ACCEPTED as a Boost library. Conditions for acceptance: 1. Remove optional dependency on cmcstl2 (issue #27) 2. Add Boost license comments to all files, including appveyor.yml, .travis.yml, README.md, */CMakeLists.txt (issue #26) 3. Support Boost.Build (issue #25) 4. Replace googletest with Boost equivalent (issue #24) 5. Remove usage of non-existent v2_dtl members in container_interface.hpp (issue #22) 6. Include <tuple> for std::tie usage in C++14 mode (issue #21) 7. Fix dangling parens in container_inteface.hpp:731 (issue #20) 8. Make Concepts usage C++20-conformant (issue #13) 9. Remove the destructor in container_interface (issue #12) 10. Add tests for non-copyable value types (issue #30) Suggestions: 1. Explicitly document the signatures and return types of functions provided by base class templates (issue #23) 2. Mention the C++20 generator pattern in documentation (issue #19) 3. Document the library's interactions with Ranges (issue #18) 4. Remove unnecessary comments (issue #17) 5. Investigate compile error in VS2015 (msvc 19.0.3) due to issues with noexcept() operator in function overloading (issue #16) 6. Rename container_interface to sequence_container_interface (issue #15) 7. Change the 'contiguous' bool to an enum (issue #14) 8. Document the relationship between value_type operator== and containter_interface-defined operator== (issue #11) 9. Improve table/section names for better navigation of container_interface tutorial (issue #10) 10. Clean up BOOST_STL_INTERFACES_DOXYGEN usage (issue #28) 11. Split up fwd.hpp into multiple headers (issue #29) 12. Document optimization trade-offs of proxy_iterator_interface (issue #30) Rationale: 1. Condition #1 is, I feel, the appropriate default as review manager. If Zach feels strongly about keeping the optional dependency on cmcstl2, we should discuss. 2. Unless the library requirements webpage has fallen out of date, new libraries must still support Boost.Build. 3. A not-so-quick grep of current Boost libraries yields no `gtest` results. I assume that we do not allow googletest as the sole test framework in a library. 4. The other conditions should be self-explanatory. Thank you Zach for your contributions, and I look forward to working with you to add this library into Boost. Regards, Barrett Adair

2 2