Re: Which libraries in Boost are mature enough to be used in real applications?
"Le Chaud Lapin" <unoriginal_username@yahoo.com> writes:
Some of the concepts being modeled in Boost are simply undercooked.
For example, I strongly suspect that the thread model should allow for
a thread function to take always an Event argument to tell it when it
should gracefully die. I am not certain that this is true, and my own
thread library is far from cooked, but it seems that, with threads,
this is generally the case. So I would think more mulling is needed
before full-on commitment is made to the library.
So, what you're saying is, you _suspect_ some of the concepts being
modeled in Boost are undercooked. And you're making this assertion
based on a problem you're having that you've never seen solved
satisfactorily.
Isn't that a conundrum for anyone building abstractions? STL
probably
seemed to its creators to be a framework that could handle the domain
of linear sequence processing, but of course despite being a great
set
of abstractions, it constrains the domain. For example, STL doesn't
handle heterogeneous sequences (tuples), and is really inefficient
for
dealing with logically-linear-but-pysically-hierarchical data
structures like std::deque.
True. However, there is a difference here. With implementation of
deque as red-black tree for instance,
I'm pretty sure deque can't be implemented as a red-black tree.
everything is clear. There is no mystery whatsoever. You know what
it is you have, that there are no alternatives, that there will be
trade-offs, what those trade-offs are, the complexity of the
algorithms, essentially everything. The only real problem is
finding someone has the the insight to choose wisely.
I'm not 100% sure I understand what you're saying. If it's that all
problems w.r.t. e.g., deques, or associative containers, are
well-understood and all that remains is to choose wisely from a menu
of solutions, I absolutely disagree.
With under-cooked models however, you do not have a choice, you
generally have something that someone just came up with.
If that's what you think Boost.Threads (or most any Boost library) is,
you really have no concept of how that library was developed. It is
by no means perfect, but even more than most Boost libraries,
Boost.Threads was entirely based on extensive research of
well-established existing practice.
You are not even sure if there is a better alternative. You *hope*
there is not, and you use what you have. The nomenclature in these
cases is often either incorrect or simply confusing.
Maybe you should stop using "you" and use "I" instead.
....and how does the introduction of versioning "create a steady-
state
model" of the serialization domain? Do you honestly believe that not
adding versioning would have made a difference in that regard?
Versioning detracted away from steady-state model (IMO).
Now you're contradicting yourself, AFAICT.
More than anything in programming, I depend on type to create form.
Versioning implies that types are semi-weak.
If versioning in serialized form implies that, then so do revisions of
your type in a version control system. So, basically, once you design
a class, it never evolves?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]