condensed overview of boost
Hi @boost, recently I've given some lectures about some selected boost libraries. After that the audience expressed the wish to get an overview over all current boost libraries. Thus for my next lecture I sat down and digged through the complete 1.46 for several day. I found a lot of useful stuff, but I also found a lot of obsolete, superseded, replaced or will-be-superseded stuff. Some libraries seems to be sub-libs of other libs. Is there an overview of inner lib relations and the actual lib state wrt. to the overall development? The issues I've found so far: - Compatibility: very narrow. Is it still needed as a public lib? - Functional, MemFun: superseded by Bind - Call Traits, Functional/Forward, Lambda: will be superseded by C++0x - Interval: can this become a sub-lib of ICL? - Meta State Machine / Statechart: whats the actual difference? I.e. which problem is solved by one lib but not by the other? - Fusion & Tuple: how are these related? Could boost::tuple become a typedef to boost::fusion::vector. I know that most of these relations are there for historical reasons and won't be changed. However I wish it had been documented somewhere. That would make an in-depth introduction of boost a lot easier. Best regards Olaf Krzikalla
Hi Olaf, Hallo Dresden,
2011/5/12 Olaf Krzikalla
Hi @boost,
recently I've given some lectures about some selected boost libraries.
Thank you for teaching boost! (boo to the community for not answering for so long ;)
There is an overview on the boost web-site www.boost.org of course in an synoptic quality with short descriptions of each library. As far as I know there is no single documentation on inter library relationships that is maintained, correct me if I'm wrong. Generated dependency graphs were provided by Chrisoph Heindl in December 2008. http://lists.boost.org/Archives/boost/2008/12/146290.php http://picasaweb.google.com/christoph.heindl/BoostDependencies1370 for boost-1.37 but not updated later.
- Interval: can this become a sub-lib of ICL?
boost::numeric::interval is closed interval on numeric types with a focus on interval arithmetic. It is also suitable handle numeric precision problems AFAIK, but I'm not an expert for that. In contrast ICL has a focus on the set character of intervals and their composition in interval containers. Non numeric intervals are possible as long as there is an ordering on the domain_type. I think it is unfortunate that ICL and numeric::interval do not interplay well. One of the main obstacle are the fixed closed borders of numeric::intervals, that lead to problems when adding or subtracting intervals to and from interval containers. There were discussions on this on the list but the authors of numeric::interval seemed not to be active at the time. Since numeric::intervals serve numeric purposes and icl::interval serve more general pusposes I think they can coexist happiely. As long a numeric::interval is not actively maintained, I don't think there is a chanche for change.
- Meta State Machine / Statechart: whats the actual difference? I.e.
Meta State Machine is a library that generates finite state machines completely at compile-time from meta code. MSN is more expensive at compile time but may generate even faster code than a "traditional" FSM. Maybe Christophe can comment on this.
There is no ready made structure or institution within boost for this. But definitely there are people who have similar thoughts, concerns and intentions. It depends if someone is going to contribute and/or is taking the lead for an effort like this. As mentioned above Chrisoph Heindl provided generated dependency graphs. Boris Schäling wrote an online book http://www.highscore.de/cpp/boost/index.html that has been translated by others. Paul Bristow cares on documentation quality for the math stuff. Robert Ramey, Dean Berris and others had initiatives about redesigning the boost web-site, just to mention a few things. So your effort on creating an overview and document on inter library relationships could be an own contribution and other could join in. Thanks again, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
2011/5/23 Chris Cleeland
See http://lists.boost.org/Archives/boost/2010/04/164436.php Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Hi Olaf,
2011/5/24 Olaf Krzikalla
Hi @all (und ein besonderes Hallo nach Offenburg(?) :-),
Berlin!
Am 23.05.2011 15:14, schrieb Joachim Faulhaber:
There is an overview on the boost web-site www.boost.org of course in
[..]
Teaching boost is important. So thank you again for doing this. Boost libraries have a mixed reputation. There is a lot of positive feedback but some find them to be expert friendly, complex and freaked out. Since many if not most boost authors have more fun designing and coding than documenting, the docs are sometimes kind of minimal, sometimes stale. Your approach IMO is the best one. Finding a catchy use case that really communicates the basic ideas and may serve as a little template, both for memorability and for a getting started project is extremely useful. [..]
IMHO icl::closed_interval could model numeric::interval, which eventually would reduce the number of libraries to teach.
thinkable, may be desirable, but ... I don't see this currently. ... But well, why not look for possibilities. From the point of view of users and teachers refactorings and simplifications like this one are desirable.
OTOH I'm aware of the problem that it is not so easy to put a boost lib on an obsolete/superseded list. No author wants to see his lib on such a list.
Which is not the only obstacle.
I'm not sure. Completely relying on meta programming MSM, might be more difficult to understand as State Chart and using MSM with large automata may lead to compile time problems. But I don't want to say too much here because I did not use both of them in real coding projects. Maybe Christophe can comment on this (haaallo, are you there?)
Publishing this kind of material is surely good contribution. BTW, boost usage in Germany (downloads per inhabitants) is higher than in the US ;-) Maybe this is due to people like you, generating appetite for people to use boost by teaching. Anyway the nice thing is, whether big or small, English or German, it'll be a contribution to publish your material via the web. What about setting up a project for students, to translate your slides and improve them for publishing purposes.
I'm sure other people have already given boost lectures too. I'd like to see their approaches to introduce boost as a whole.
Sure, ..., lecturers ... are you there? Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
On Thu, May 26, 2011 at 1:52 PM, Joachim Faulhaber
Boris Schälings book on boost [1] has quite couple of catchy of use-cases. Best regards, Christoph [1] http://www.highscore.de/cpp/boost/titelseite.html
Hello *,
(Grüsse aus München ;)
On Thu, May 26, 2011 at 1:52 PM, Joachim Faulhaber
I see it pretty similar, but the main goal in teaching boost should be to explain the philosophy of boost. How most of the libs are tighten to compile time and might consist of lots of code, but are really well optimized during the compilation and result in robust and safe code. Explaining all the boost libs will make your lecture at least every year obsolete. I remember that boost had last year around 86 libs, how much are they now? There is already a bunch of accepted libs (e.g. logging) which will be taken into boost after the lib undergoes changes identified in the review process. I think you lecture should definitely focus on explaining the boost core philosophy and introduce some meta programming, to better understand the libraries.
MSM is compile time based, but is also limited by the number of states. I remember that Christophe wrote in some release notes that the number of states in the MSM is around 70. I can't say that it is here black or white, since MSM drives compilers to their limits it is possible that for various reasons there will be the requirement to use conventional FSM implementation. Especially if the compiler is not that good with template instantiated code and produces code bloat. With most popular compilers (g++, MSVC) the code size does not grow linearly with every template instantiation. But there needs to be a use case study which FSM implementation is more convenient for the project needs.
On Mon, May 23, 2011 at 3:14 PM, Joachim Faulhaber
Wow 2008...time passes by too quickly. Anyway, I haven't updated the include graphs because uploading all the images to Picasa (the only infrastructure I have access to) was such a pain back then. However, I have made the source code of the 'parser' publicly available [1]. A short usage documentation [2] should get you going. In case the community is interested and anyone can provide image hosting, I could generate inter-project dependencies for current boost releases. Kindest regards, Christoph [1] http://code.google.com/p/rcdp/ [2] http://cheind.wordpress.com/2009/12/05/generic-dependency-parser/
participants (5)
-
Chris Cleeland -
Christoph Heindl -
Joachim Faulhaber -
Olaf Krzikalla -
Ovanes Markarian