Boost logo

Boost :

From: Sean Parent (sparent_at_[hidden])
Date: 2006-07-03 15:09:04

Hi Jeff,
> I'll just say a public thanks to yourself, Adobe, and the folks
> behind ASL for
> dipping their toe in the open source water. I think it will take
> several
> years to see the full effect, but it's very exciting to me to see
> you guys
> getting a chance to bring these ideas out into the world.
Probably more than several years (given that it isn't clear the
Generic Programming has caught on yet) :-(
> > I will also support anyone who would like to borrow portions of ASL
> > to contribute them to Boost.
> This is really great -- it seems there is much common activity with
> other
> things happening in Boost (see below).
> > Some libraries that I think would be interesting to get into Boost
> > with some comments about what I see as still needing to be done.
> >
> > Forest <
> group__asl__tutorials__forest.html>
> > .....
> We have an active SOC project to build a generic tree...
Are there links to these on port 80? I can't get to 8443 from inside
> > Range Based Algorithms (using the boost range library) <http://
> >>
> >
> Eric Niebler has written some range algorithms in the vault -- be
> nice to see
> if he's covered all the ones you'all have:
> &direction=0&order=&directory=Algorithms
There is some nice work here to specialize for the standard
containers - something I hadn't considered and isn't part of my
library. Thanks for the pointer!
> > ZUIDs <>
> Hmm, I guess I would think zuid should be its own little library.
> There is
> already a GUID in the vault which again might benefit from
> collaboration here:
> --
Interesting - this is not quite a conforming GUID (deviates in many
of the same ways that ZUIDs do from the specification but I try to be
honest and not call them GUIDs...


AFAICT the node ID in the boost code is purely dependent on the clock
- this makes the entire ID uniqueness of the ID a function of time
(making for a fairly high probability of collision). The ZUID code
includes machine specific and process specific information in the
node generation and has code to synchronize threads to avoid
collisions from requesting IDs from separate threads at the same time.

Anybody know how to contact Andy Tompkins to see if he wants to
> I don't know if we've really found an active maintainer for
> Boost.Threads....library abandonment is starting to become a much
> bigger issue
> for Boost as time goes on :-(
Maintenance for any large library is problematic. I ask that for each
release, my developers improve one existing library (both
documentation and code) - we release once a month so this helps to
keep things from stagnating. Right now I don't mandate _which_
library is improved but at some point I'll have to start dictating
the priority. Of course, the folks working for me aren't quite
volunteers so I can get away with that. But some possible suggestions
for boost -

1. Speed up the release cycle - I would try to get two two releases a
year at a minimum. Just upping the release pace will help avoid

2. Make maintenance part of the cost of admission - "We're really
happy to take your GIL submission, but part of contributing to Boost
is to assist with the general maintenance. Here's a short list of
tasks we'd like you to take on..." (Sorry Lubomir!)

I'm constantly looking at ways that we can improve this with ASL -
honestly the library as it stands today is large enough that I could
burn my entire team just maintaining and improving the current
libraries without ever adding any more (at least for the next few
years). Balancing this with adding new libraries and showing forward
progress is very difficult.
> > regular_object <
> > classadobe_1_1regular__object.html>
> > This is a generalization of value_t (and boost any) - the idea is to
> > be able to parameters an "any" object by concept. Mat Marcus has
> been
> > doing a fair amount of work with this library. Needs better docs and
> > tutorial.
> Interesting. Don't know of any current Boost work here.
We're currently putting a fair amount of emphasis on this work - the
general idea is that the requirement of polymorphism comes from the
requirement to apply algorithms to heterogeneous collections of
objects. Hence - runtime polymorphism should be based on Concepts and
cannot be properly described by intrusive means (such as
inheritance). I'm currently collaborating on a paper on the topic
that I'm hoping to have ready for LCSD <>
> > Copy-On-Write <
> > classadobe_1_1copy__on__write.html>
> I guess the ever-languishing policy_pointer is the closest Boost work.
A key simplification here was realizing that copy-on-write deals with
values, not pointers.
> > XML Parser <
> > classadobe_1_1xml__parser__t.html>
> There is a Boost xml, but I haven't seen much Boost activity here.
> Property
> tree does some too, but full XML support is hard enough that it
> will be hard
> to do in Boost.
> direction=0&order=&directory=Progamming%20Interfaces
We're getting close to a complete XML parser - this is not a DOM, the
idea is that a DOM would be a separate library that could be used
with the parser - but the parser can be used just fine without a DOM.
> Hopefully people will make you very busy :-)
Already you've given me some nice references. Thanks.


Boost list run by bdawes at, gregod at, cpdaniel at, john at