Hi everyone,
Boost C++ is candidating again this year to be part of the Google Summer of
Code 2023.
Each year we are honoured to have students and contributors joining us for
the summer and being sponsored by Google.
Again, this year, I will ask for all the mentors who are interested in ...
well... mentoring a student or contributor, to help us and write their
ideas in this document:
https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code:-2023
It will help our future students to choose, to develop their own proposal
and to be part of our Boost journey.
Best regards,
David
Hi Everyone,
I wanted to share my initial thoughts after reading the docs for the
proposed Boost.Mustache.
If some library docs said "I am implementing JSON", I more-less know what
to expect, because JSON is popular, I used it, so one can reliably predict
what the library delivers.
This is not the case with Mustache. It is the first time I have heard this
name. Apparently, it is a less popular thing. Therefore, I would expect
some more introduction than just an external link. The linked page also
doesn't contain sufficient information but further links. For instance to
https://mustache.github.io/mustache.5.html, but this information also
doesn't help me find answers to my questions:
1. What is considered an "optional part" of mustache? Boost.Mustache says
it only implements the non-optional parts, but docs in mustache(5) do not
indicate the optional parts.
2. It is clear to me that the procedure takes a template (with mustaches)
and the data to be replaced. But what is the range of the acceptable
formats of this data? The examples show that it is JSON, but does it have
to be JSON? Boost.Mustache docs say it could be 'described' classes? But is
that all? How about Boost.PropertyTree? What does the specification for
Mustache say about it?
3. I do not see any specification (neither in Boost.Mustache docc, nor in
the linked mustache(5)) for what is the required behavior when I have
nested mustashes with the same name, or a JSON file with nested elements of
the same name.
Or did I miss this description?
Regards,
&rzej;
Greetings. I am asking if there is any interest in a Boost.Buffers
library, which consists of the following:
* ConstBuffer, MutableBuffer concepts
* ConstBuffers, MutableBuffers concepts
* const_buffer, mutable_buffer types
* DynamicBuffer concept
* `source` and `sink` abstract interfaces used to
define the Source and Sink concepts
* metafunctions for checking all type requirements
* implementations of common buffers and dynamic buffers:
- buffers_pair
- array_of_buffers
- circular_buffer
- dynamic_string_buffer
* Algorithms:
- buffer_copy
- buffer_size
The twist is that this library has no dependency on Asio or Boost.Asio
(but Asio will still recognize them thanks to some template heroics
and a splash of forward declarations). Why am I proposing this? Well,
let me tell you some things...
I am currently working on these two libraries:
Boost.Http.Proto
Boost.Http.Io
The Proto library implements HTTP/1 to a fuller feature set than Beast
and fixes all the design flaws in Beast (but it is completely not API
compatible). This library does not do any network I/O, it is expressed
purely in terms of buffer concepts (i.e. depends on Boost.Buffer and
not Boost.Asio).
The Io library depends on Asio and the Proto library to provide the
network algorithms which use Asio to implement HTTP/1. This is the
equivalent HTTP functionality of what Beast offers today.
Websockets is not included but when I am done with Http I will redo
websockets with improvements and new features, and similarly they will
be developed as two libraries:
Boost.Websockets.Proto
Boost.Websockets.Io
My motivation for splitting libraries this way is as follows:
* Each library is smaller and compiles more quickly
* CI turnarounds are faster
* Separation of concerns
The HTTP Protocol library is designed in a way that much of an
application's HTTP business logic can be expressed independently of
Asio using only the constructs found in Http.Proto. This especially
means fewer templates and faster compilation because Http.Proto is
designed from the ground up to avoid templates whenever possible.
However during the development of Http.Proto I find myself having to
reach for the same buffer algorithms and containers that I developed
for Beast (such as the circular buffer and the dynamic buffer). So
Http.Proto has been steadily growing these things:
<https://github.com/CPPAlliance/http_proto/blob/a3a284f06597ad12ca6cc1782beb…>
Extract this independent buffer functionality into a separate library
Boost.Buffers would bring these benefits:
* Again a smaller library, faster compilation
* Faster CI turnarounds
* Separation of concerns
Additionally, algorithms can be expressed in terms of asio-independent
buffer types and concepts. For example, Boost.JSON could implement the
boost::buffers::sink and boost::buffers::source interfaces which would
enable its use in Boost.Http.Proto and Boost.Requests (an upcoming
HTTP client library from Klemens), without having to depend on either
of those libraries or Asio.
Is this style of development of smaller, fine grained libraries that
separate concerns something that is desirable for Boost? Glad for any
feedback.
--
Regards,
Vinnie
Follow me on GitHub: https://github.com/vinniefalco
Dear all,
Hubert Liberacki wrote this library
https://github.com/hliberacki/cpp-member-accessor
that uses a loophole in the C++ standard which allows one to access private members and methods in classes in external libraries that are not under the control of the library author. Since the loophole is legal, it works with all major compilers and on all platforms. No special compiler flags required nor illegal macros like #define private public.
I think this should be integrated in Boost, is there interest other from myself?
Before you say it is evil, consider all the good that can be done with this in responsible hands. You can add serialisation support to classes that you do not control and you can write efficient Python bindings. I have used this library now in three projects. I used it to add serialisation support and to provide memory views of C++ structures in Python (via the Numpy module), both wouldn't have been possible to do or not would not have been efficient without this.
It is a single-header library with 85 lines of code, some of which are comments. This seems a bit small for a separate library, but I am not sure where it would fit in.
Best regards,
Hans
Hi,
1) What is the status of adding CMakeLists.txt to ublas and odeint
libraries?
That file are essential for using Boost in big companies. Especially it is
crucial for integrating Boost into buld systwms other that b2.
I see there is a https://github.com/boostorg/ublas/pull/142 but no actions
for a year. Please, just merge it.
2) Please, merge the fix https://github.com/boostorg/ublas/pull/153
3) Please, merge the fix https://github.com/boostorg/ublas/pull/153
There are many other PR waiting for merge. I do realise that the
maintainers could be short on time. May be there are some developers that
you trust and write permission could be given to them?
Hello,
I am writing to update you on the recent activities of The C++ Alliance.
Our newest team members include Matt Borland, Ruben Perez. Matt is
developing Boost.Charconv, a C++11 library which polyfills the equivalent
C++17 functionality, and contributing to the maintenance and improvement of
Boost.Math. Ruben is making significant improvements to Boost.MySQL. Our
long-running Boost website project continues to progress and will be
deployed in beta this year.
As some authors and maintainers may have observed, the code coverage
services provided by https://codecov.io have been varying greatly in
quality in terms of the user experience of viewing the reports, with the
experience being typically worse. To mitigate these risks we are
researching the development of a new set of HTML, CSS, and JS templates for
presenting high quality coverage reports in the original style.
In our continuous efforts to improve documentation quality we have
contracted HDoc to explore generating Doxygen compatible XML output so that
we might move away from Doxygen in favor of HDoc. This tool is focused
specifically on C++ and could be a better fit for Boost libraries that
currently use Doxygen.
Our vision for documentation includes a significant investment in Asciidoc
as the choice of markdown. This means rendering Doxygen/HDoc output in
Asciidoc and commissioning a great set of stylesheets for Asciidoc to
replace the stock sheets. In the longer term we are investigating Antora as
a solution for producing documentation that is well integrated into the new
website, to offer a better navigation experience, improved accessibility,
more features such as C++ syntax highlighting and code snippet
interactivity, and others.
We are excited to work on these developments, with the hope they will add
vitality and enhance Boost. We look forward to sharing more updates with
you in the near future.
Best regards
Louis Tatta
CEO
The C++ Alliance
Hi,
For some reason, Container Hash is listed twice on this page:
https://www.boost.org/doc/libs/1_81_0/
The two entries seem equivalent except the "C++ Standard Minimum Level"
entry.
We have Trac in read-only mode after we migrated to Git, but we're
still paying for the server.
Do people still want to preserve any part of the content in some way?
The wiki aside, there are old issues, with comments, and some of them
have patches attached.
Peter had the idea of generating static HTML content from Trac and
hosting that on an archive section on boost.org. (I don't know how
difficult this is to do).
Thoughts? Suggestions?
Glen
