- Boost - lists.boost.org

What is Boost?
by David Abrahams 13 Oct '05

13 Oct '05

Hi, Last night I hosted a birds-of-a-feather session at the SD Best Practices conferences here in Boston. I was encouraged that, at a conference that only adopted a C++ track this year, we had 15 people there. It was about evenly split between people who were using Boost and those who just came to find out more about it. Those who were using Boost were really enthusiastic. I was stunned to discover that the rest of them reported that wanted to know what Boost _is_, but that the website doesn't tell them. And when they said that, it hit me like a ton of bricks: they're right! We really need a section at the top of the page titled "What is Boost?" that covers something like the following: * Boost is a collection of C++ libraries - Free for any use - Extensively peer-reviewed - Extensively Tested * When you download Boost, you get the whole collection * There are some dependencies among libraries, but they are not tightly coupled * There is a tool (bcp) for extracting the parts you want and their dependencies. * Many boost libraries can be used just by putting the library collection's top directory in your #include path. Complete instructions for getting started are at: ___ * The important features of the Boost directory structure are: - boost - libs - more - tools (with rough descriptions of each) I'd like to see some discussion of what's missing (or extra) in the list above... and a volunteer to write the introductory passage :) -- Dave Abrahams Boost Consulting www.boost-consulting.com

13 42

Re: [boost] Report from Mont Tremblant C++ Committee meeting
by Thorsten Ottosen 13 Oct '05

13 Oct '05

Gennadiy Rozental <gennadiy.rozental <at> thomson.com> writes: > > >>>String-algo : Interested, but concern over interface and choice of > >>>functions, generic vs basic_string.5.3 separate proposal > >> > >> Any details on this? I love this library, and I would love to see it > >> standardized in some form. Overall I've found the interface and function > >> choices to be excellent (and I'd love to see even more), and I love that > >> it's generic and not limited to basic_string. I use it on vectors and > >> other containers for different kinds of network protocol parsing. > > > > Thorsten Ottosen acted as champion for the paper, but I'll try to recall > > the discussion. > > > > There concern was that at least some of the algorithms were only useful in > > the context of strings, and so it would be an over-generalization to > > supply them as free algorithms. My notes say that the solution that got most support was free-standing functions for "arbitrary strings". So support for stuff like rope was considered important. Let me also recap some other feedback: (a) the algorithms should work directly with string literals as they do today in boost. (b) many requested additional motivation for choosing this particular set of functions. > My point exactly. I believe string_algo library went (completely?) wrong > way. It should never use iterator parameterization, but char type only. If > there exist any algorithm that is useful beyond strings - it doesn't belong > to this library. Well, there are just too many string types out there to base the interface on basic_string<CharT>. Besides, it would not be very c++-ish to preach generic programming yet avoid using it in obvious places in the standard library. -Thorsten

1 0

Re: [boost] [ANN] Phoenix-2 prerelease
by Eric Niebler 13 Oct '05

13 Oct '05

Daryle Walker wrote: > On 10/12/05 7:31 PM, "Eric Niebler" <eric(a)boost-consulting.com> wrote: >> iterator begin, end; >> ... >> boost::make_filter_iterator(arg1 > 5, begin, end); >> // Oops! ---------------------------^ >> >>Isn't that comma going to be Phoenix's overloaded comma? > > > I don't think so. The comma used to separate function (call) arguments > always overrides a comma operator. Yeah, you're right, I figured that out with Joel's help yesterday. C++ is funky. -- Eric Niebler Boost Consulting www.boost-consulting.com

1 0

RTL: Relational Template Library
by Arkadiy Vertleyb 13 Oct '05

13 Oct '05

Hi All. I just uploaded the latest version of Dmitriy Arapov's and my Relational Template Library (RTL) to the Boost file vault, http://tinyurl.com/8lbmg. This version is compatible with Boost 1.33. The RTL was discussed on this list at some time in the past. The early version of RTL is described in the March 2004 issue of CUJ. The main difference from currently discussed RML is that we decided against using SQL - like interface, and use the relational algebra-based interface instead. This choice is caused by our belief that the optimizer -- the module converting SQL query into an optimized relational expression -- is one of the most sophisticated parts of modern database engines. Also, writing a good optimizer in a system like RTL (or RML) would have to be done in large part at compile time, by the means of template meta-programming. This task doesn't seems to be feasible, at least currently. OTOH, writing a primitive optimizer, would, in our opinion do more harm than good. So, the RTL gives its user the possibility to build arbitrary relational expressions by hand. We augment the pure relational algebra with a few things, such as sort order, indexing, groupby, join, etc. We also allow indexing of any relational expressions, not just tables. So, for example, a user can do a selection on some arbitrary complicated criteria, and then index this selection. This would ultimately result in the index storing just keys to these records. This index would be incrementally updated when the underlying table has been changed. Achieving the same effect with conventional approach would require creation of a much larger index on a calculated field. Another example -- you have table of cities, and you need to get all the pairs, such as the distance between them is less than certain number. How would one solve the problem with the conventional SQL approach? This is a self-join. But how to make this query fast? With RTL approach, we could create an index on this self-join. The RTL can currently be compiled with VC7.1 or GCC 3.3+ (although with GCC there might still remain some naming conflicts between MPL and STL, that show up with certain usages) Regards, Arkadiy

6 36

[signals] expected failure markup for como
by Markus Schöpflin 13 Oct '05

13 Oct '05

There are currently two test failures (dead_slot_test, and trackable_test) which are marked as expected for como. The note says: 'The failure is caused by a compiler bug, which has been reported to the compiler supplier (or is already known to them).' Does anyone know the exact circumstances of this compiler bug or even has a small reproducer? Tru64/CXX has the same failures and I would like to submit a bug report to the vendor. Markus

2 3

[signals] usage of any_cast
by Andreas Pokorny 13 Oct '05

13 Oct '05

Hi, We just stumbled across a small problem with Boost.Signals, while playing with the symbol visibility features of gcc-3.4 and gcc-4. That feature is still buggy, but it unveiled some strange code. Somehow gcc failed to turn the type info of the types stored by any into a visible symbol, which is required for using boost::signals across shared libraries. So there are multiple type info objects and the dynamic_casts within signal failed, and the application crashed with a seg fault, since no one expected the cast to fail The code is in signal_template.hpp: template<typename Pair> R operator()(const Pair& slot) const { F* target = const_cast<F*>(any_cast<F>(&slot.second)); return (*target)(BOOST_SIGNALS_BOUND_ARGS); } I dont see why any_cast is used here at all. The type safety is guranteed by the interface of Boost.Signals, so I doubt that someone will be able to abuse the library. I believe the author of that code had the same in mind, since he did not test target != 0 before invoking the target. So in my opinion a simple reinterpret_cast should suffice here. It would also fix our issue, although that one is caused by gcc. Regards Andreas Pokorny

3 5

[mpl] weird interaction between mpl::set and mpl::map headers
by Joaquín Mª López Muñoz 13 Oct '05

13 Oct '05

The following snippet #include <boost/mpl/set/set0.hpp> #include <boost/mpl/map.hpp> int main() { return 0; } produces the following in GCC 3.2: In file included from /usr/local/boost_1_33_0/boost/mpl/map/map0.hpp:18, from /usr/local/boost_1_33_0/boost/mpl/map/map10.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map/map20.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map.hpp:36, from mpl_iterator.cpp:2: /usr/local/boost_1_33_0/boost/mpl/map/aux_/contains_impl.hpp:34: no class template named `apply' in `struct boost::mpl::at_impl<boost::mpl::aux::map_tag>' /usr/local/boost_1_33_0/boost/mpl/map/aux_/contains_impl.hpp:35: `type' is not a class or namespace /usr/local/boost_1_33_0/boost/mpl/map/aux_/contains_impl.hpp:35: ISO C++ forbids declaration of `type name' with no type In file included from /usr/local/boost_1_33_0/boost/mpl/map/aux_/erase_key_impl. hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map/aux_/erase_impl.hpp: 19, from /usr/local/boost_1_33_0/boost/mpl/map/map0.hpp:22, from /usr/local/boost_1_33_0/boost/mpl/map/map10.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map/map20.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map.hpp:36, from mpl_iterator.cpp:2: /usr/local/boost_1_33_0/boost/mpl/map/aux_/has_key_impl.hpp:33: no class template named `apply' in `struct boost::mpl::at_impl<boost::mpl::aux::map_tag>' /usr/local/boost_1_33_0/boost/mpl/map/aux_/has_key_impl.hpp:34: `type' is not a class or namespace /usr/local/boost_1_33_0/boost/mpl/map/aux_/has_key_impl.hpp:34: ISO C++ forbids declaration of `type name' with no type In file included from /usr/local/boost_1_33_0/boost/mpl/map/aux_/begin_end_impl. hpp:20, from /usr/local/boost_1_33_0/boost/mpl/map/map0.hpp:30, from /usr/local/boost_1_33_0/boost/mpl/map/map10.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map/map20.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map.hpp:36, from mpl_iterator.cpp:2: /usr/local/boost_1_33_0/boost/mpl/map/aux_/iterator.hpp:41: parse error before `<' token /usr/local/boost_1_33_0/boost/mpl/map/aux_/iterator.hpp:62: parse error before `<' token but if I reverse the order of the #includes, everything works OK. I suspect this problem is also showing in the GCC 3.4.x family. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Toolset for VC8.0 and stlport
by Thierry Miceli 13 Oct '05

13 Oct '05

Did somebody make a toolset for VC8.0 and stlport? Thanks, Thierry

2 1

[MPL.Math] partial comeback of big_integral
by Cromwell Enage 13 Oct '05

13 Oct '05

I've rewritten mpl::math::big_integral_impl so that, instead of being a heavyweight mpl::vector, the mantissa (formerly magnitude) is treated as a nullary metafunction containing the integral constant expressions digit_0...digit_N, where N is one less than the mantissa size, which is now directly configurable. Arithmetic operations are now much faster as a result. The functionality that converts integral_c et. al. to a big_integral_impl is now moved to mpl::math::enlarge_integral. All I need now is a *much* more efficient division algorithm and, of course, mpl::math::big_integral itself. BTW, there may be extraneous files in the <mpl_math.zip>boost/ directory; ignore them, I was using them for study purposes. Cromwell D. Enage __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

2 2

[concept_check.hpp] unreferenced formal parameter line 227
by Kevin Wheatley 13 Oct '05

13 Oct '05

Hi, I was wondering if anybody has thought about adding a #else to the #if !defined(_ITERATOR) to ignore the unused variable warning in AssignableConcept::const_constraints() you get when compiling on VC7.1 ? (Or am I missing something subtle about the situation) Thanks Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |

3 4