Hi Everyone,
In connection with the recent discussions on the future of Boost, I would
like to offer a perspective of someone who is a consumer of open-source
(but also commercial) libraries.
In my work I often find myself in a situation where I need to use a new
library for:
* logging
* unit testing
* communication with DB
* parsing requests XML, or simplified XML (without Unicode or less popular
XML features), JSON
* validating requests against XML/JSON schemas
* HTTP communication
* etc...
I do not necessarily need Boost libraries for that. I need libraries that
satisfy my criteria for correctness, safety, performance, and conformance
with a certain programming style (e.g., a library cannot force me to
inherit all my classes from class `Object`). These libraries do not
necessarily have to come from one source. But they have to *interoperate*
with one another.
When I select a new library my concerns are usually the same:
1. Does the author understand the problem of exception safety and failure
safety in general? The declaration "this library is exception safe" is an
indication that the author at least heard about the term, but is still
insufficient. I become convinced when I see a listing: these functions
offer commit-or-rollback guarantee, these functions offer basic
failure-safety guarantee, these functions offer other guarantees, like
never-empty for some implementations of variants.
2. Does the author understand the problem of thread-safety? Similarly here,
the note "this library is thread-safe" at least indicates that the author
is aware of thread-safety problems. I feel more confident when I see the
listing: "these functions can be called simultaneously from multiple
threads", or similar declarations.
3. Does the library use the established patterns in C++, like value
semantics, strong types?
4. Will the library give me the control over resource management? Or will
it allocate like 30 threads behind my back, when I least expect it?
5. Will it interoperate with other libraries that I choose for other tasks?
6. Is the library actively maintained?
7. Is the library *decently* documented? (Not only the repetition of
declarations from the header files.)
8. Did the author study the domain deeply, and has come up with the optimum
concepts and the interface?
Boost is often my first place to go. Because I have a high level of
confidence that my expectations will be satisfied. But I do not always
prefer Boost. For instance for unit tests I go to Google.Test, for
instance, because I strongly disagree with the choice for how the precision
for floating-point comparisons is silently chosen in a non uniform way. My
confidence in boost stems from the review process and the assembly of
experts that I trust. One could say that Boost offers a certification
mechanism, even if informal.
I do not care that much if all libraries come from one source, but I would
love there to be a common certification body (even if informal) that would
say "this library meets a certain set of criteria".
I desperately needed Boost in the past because it offered a really basic
fundamental primitives that were missing from the Standard library, as well
from the language:
optional, variant, tuple, any, shared_ptr, but also BOOST_FOREACH,
BOOST_AUTO.
You could call the types from the list the "vocabulary types": they can be
used in other third party libraries, and therewith different libraries can
interoperate seamlessly owing to these types.
Today, these types from Boost do not necessarily fill this role anymore
because we have the std equivalents. But Boost.ASIO can be thought of as
such a building block: it can be used as a base for many higher-level
libraries that interoperate owing to the same asynchrony model.
If I, a library consumer, were to answer the question what I would like
Boost to be, that would be:
1. The certification role: to educate what a high standard library means,
to offer help and tools for library developers to achieve this level (not
necessarily as a Boost library) and to issue opinions on the libraries.
Boost to a great extent already implements this.
2. To focus on foundational libraries: those that can help other libraries
interoperate. Like the one big decimal library.
An interesting counter example to using vocabulary types is Boost.JSON
implementing its own string type for efficiency. I was already convinced
that it was the right decision to implement a custom string. But it
illustrates something important: we cannot have the one string class. I
guess where there is a need to manage resources (like string manages memory
internally) there cannot be the one vocabulary type.
Regards,
&rzej;
