January 2024 - Boost - lists.boost.org

Google Summar of Code 2024 - Collecting Projects & Mentors! 📢
by Inbal Levi 05 Jan '24

05 Jan '24

Hello all! We would like to collect projects & mentors for the GSOC 2024 :) If you would like to volunteer as a mentor and/or have a proposal for a Boost project which you like to collect volunteers for, please fill in the proper tab: https://docs.google.com/spreadsheets/d/1_eUWRsXnhi_JwKZbHZsGQf3WNUESsAPE4lV… Once we have a list of proposed projects, we will upload them to GitHub. Thanks! Best regards, Inbal Levi ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Lead Software Engineer @ Millenium* Isocpp, Boost &"Hamakor" Non-Profits Board Member ISO C++ LEWG Chair & Israeli NB Chair C++Now Program Chair & CoreC++ Conference Organizer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

Recommendations for documentation authors
by Andrzej Krzemienski 04 Jan '24

04 Jan '24

Hi Boost Developers, And a happy New Year (at least for those who recognize the Gregorian calendar). While I consider improving the documentation quality of some Boost libraries, I wonder if there are any tool or workflow recommendations for the library authors regarding the documentation. I know we do not force any specific tool or format, so I am only asking about recommendations. I note that page https://www.preview.boost.org has at https://www.preview.boost.org/doc/contributor-guide/docs/documentation-guid… the following: > The format for documentation on the new website is AsciiDoc Syntax Quick Reference <https://docs.asciidoctor.org/asciidoc/latest/syntax-quick-reference/>. Should I treat it as a recommendation to use AsciiDoc? I note that quite a few new libraries choose it. I also see the advantage: you need no special tool for it: a simple web browser knows how to format it. But I found the documentation of libraries that use adoc to be uncomfortable to read. I do not know if this is the tool itself or maybe the correlation between the choice of the tool and the devotion to documentation quality, or maybe something else. It is quite subjective. The older libraries' documentation (using BoostDoc) seemed more friendly and easier to navigate. But to write and maintain such documentation is a challenge. Last year something broke in my pipeline (QuickDoc, xstlproc) and to this day I am not able to determine what it is. So, relying on too complex flows, which become obsolete over time, also doesn't seem like a good idea. I wonder if any of you have similar thoughts, and if you can recommend something for writing good quality and user friendly documentation. Regards, &rzej;

9 23

[website][string_ref] Broken link to the library docs
by Andrey Semashev 02 Jan '24

02 Jan '24

Hi, In the library list for Boost 1.84: https://www.boost.org/doc/libs/1_84_0/ there is an entry for Boost.StringRef. However, that library was removed from libs/utility/meta/libraries.json. Or, more precisely, it was renamed to Boost.StringView (key: utility/string_view). The problem is that the StringRef entry in the above list has a broken link to the library docs, and the rename was supposed to fix it (by having an entry for StringView instead, linking to its docs). I'm not sure where StringRef comes from, but can it be removed? This has been reported a few times already: https://github.com/boostorg/website/issues/763 https://github.com/boostorg/utility/issues/105

1 0