Re: Which libraries in Boost are mature enough to be used in real applications?
David Abrahams wrote:
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
With regard to threads, the problem I had was getting the thread to
terminate gracefully via triggering an event that the thread is aware
of. I have solved this problem for myself satisfactorially, by
rethinking the prevalent models of threads. The effort to solve this
problem lasted about 2-3 days. I then asked a simple question which
should always be asked when designing models - "What is the virtue of
this? Is it persisent? In the case of the new model (which I have not
described), I belied it is." I then looked at the Boost thread model
(very briefly) and other thread models to see if others had done the
same. Because I did not see this element, and because I am convinced
that it is not simply a "nice-to-have" but a necessity for reaching a
regular model, I concluded (for myself) that more work needs to be done
in mulling and rethinking the model befre wrapping the status-quo.
By contrast, I did the same thing with date/time, entirely
independently of Jeff Garland's work, and it was very pleasant so see
that someone else had recognize the importance of nomenclature, and
that there are three, very distinct concepts related to time, and if
the model is to be made regular, one must absolutely not ignore this
I'm pretty sure deque can't be implemented as a red-black tree.
Right, don't know what I was thinking about.
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.
Now I am confused. Why not? I was saying that some models have either
reached or are very close to their steady-state. Some are not. The
ones that are, we should implement them and publish them. The ones
that are not, sometimes it does more harm than good to implement them
and publish them than to admit that they are not yet fully-cooked.
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.
I don't doubt that this is the case. But right now I am looking at the
list of containers at Boost, and I still do not see a tree<> container.
Is there one? And what about STL? This container is arguably
fundamental to scalabale architectures. Where is it?P
Maybe you should stop using "you" and use "I" instead.
....and how does the introduction of versioning "create a steady-
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.
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?
No, not the primitives. For example, I have a "tree<>" class (several
in fact). It is serializable. I doubt that I will change it in the
next 10 years, and if I do, I certainly won't break its serialization.
Note also that I do not mean to criticize Boost, or even the whole
Serialization library, which I mentioned was quite good. I was only
turned-off by the versioning feature.
-Le Chaud Lapin-
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]