From: Matthew Wilson (stlsoft_at_[hidden])
Date: 2003-11-19 01:00:07
I'm not entirely sure about what I'm asking here, so please bear with me.
Since John Torjo has twisted my arm to get more Boostified, I was thinking a
good immersion would be to map some stuff over to boost, in the same way
that I've done for the STLSoft libraries.
One thing I have been working on, for my CUJ column, is the recls library
(http://recls.org/), a platform-independent recursive search library, in
C/C++ that is mapped to C++, C#, D, Java, Perl, Python, etc. etc.
I was thinking about doing a boost::recls mapping. Naturally, that would
also be of interest to CUJ readers, since I'm sure many of them are in the
same position as me, ie. not entirely au fait with the Boost way of doing
things (both technically and procedurally). Also, I think the library might
be a nice addition to Boost, since I've found it very convenient when one
wants to do recursive searching, as in:
typedef reclstl::basic_search_sequence<char> search_t;
search_t search("/", "*.h", RECLS_F_RECURSIVE | RECLS_F_FILES |
std::for_each(search.begin(), search.end(), process_entry());
Obviously the syntax is canonical to the point of being boring, but that's
what we want. :-)
[btw, I'm aware of the boost::filesystem lib, and am not suggesting recls
would surplant it. I'm merely using it as an example, and if there was
interest in having a separate recursive search lib, that'd be fine.]
Ok, so here's the meat of the question: The implementation of recls is a set
of cpp files that have nothing to do with Boost. (They rely on the STLSoft
libs, but that's just an implementation detail.) What I'm wondering is how,
in general, does Boost interface with things written in "other than Boost",
or is it a stipulation of all Boost libraries that they are 100% pure Boost?
- If the former, what are the ramifications: how does the separate-library
source get delivered to the Boost users? how does Boost verify the quality
of the separate-library on all platforms (currently recls is only ported to
Win32 and Linux, although it just uses standard Unix readdir() & glob())?
Any and all other issues I'm not aware of ...
- If the latter, I can certainly understand the motivation, but is there a
danger of missing out on good things? (I'm being general here, not implying
that one cannot live without recls, he he ). In this case, a boost::recls
would have to be a full port, which would kind of make the point of the
column - integration - moot.
Maybe there's a middle ground. Things that are not Boost-proper, but
nevertheless wear a Boost hat. Taking my recls example, there'd be a
boost::recls mapping, which talked to the C-API. If this model is supported,
I presume such libs are not part of the distribution, but are available from
the boost site, and have an appropriate level of presence, such that people
can find them?
Anyway, that's me done. (Too many words as usual.) Please advise.
Thanks in advance.
-- Matthew Wilson STLSoft moderator (http://www.stlsoft.org) Contributing editor, C/C++ Users Journal (www.synesis.com.au/articles.html#columns) "But if less is more, think how much more more will be!" -- Dr Frazier Crane ---------------------------------------------------------------------------- ---
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk