- Boost - lists.boost.org

como-win32-tools.jam changes broke my builds
by David Abrahams 02 Mar '04

02 Mar '04

The recent changes to como-win32-tools.jam completely broke my ability to use the toolset. Nobody should be calling the "flags" rule on variables indended for user customization. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: boost::ublas and solver
by Michael Stevens 02 Mar '04

02 Mar '04

Dear Loïc, On Tuesday 02 March 2004 00:33, Loïc Joly <loic.actarus.joly(a)wanadoo.fr> wrote: > I was recently trying to convince one of my colleagues that a vector > (mathematical, not stl) and matrix library instead of raw C arrays could > be usefull for his job. An excellent decision! > I naturally turned toward boost::ublas, but then > I had one surprise: One thing I expected to find in such a library was a > collection of solvers (LU, gaussian elimination...), but I found none. The simple answer is in the name 'BLAS'. uBLAS is a library for Basic Linear Algebra. It provides storage for vectors and matrices (dense, packed, and various sparse methods) and basic linear algebra operations. Of course all this is put together in a safe and efficient C++ package! For a more complete answer have a look at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Linear_Algeb… > Is this because they exist, but I could not find them in the > documentation (btw, I have some trouble to understand the doc, too much > code, not enough english to my taste) ? True. Feel free to contribute documentation. I am using the Boost Wiki to organise new introductory information which can eventually be merged into the official uBLAS documentation. > Is is because there was a good design decision not to include them ? > Is it because this is a very touchy domain and poeple could not agree on > generic solutions ? > Is is just an oversight ? Yes, No and No. There is no end to the number of Linear algebra algorithms. uBLAS provide efficient infrastruture for C++ to solve these problems however. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://www.sf.net/Bayes++ ___________________________________

2 1

Review Request:serialization
by Robert Ramey 02 Mar '04

02 Mar '04

I've uploaded serialization17.zip to the boost files section. There is also a copy to be found at www.rrsd.com I am requesting a formal review of this submission. I realize there's a queue. I hope that interested parties can find the time to subject this submission to a preliminary review and that at least two of those persons can second this submission. The feedback I've received from recent prior versions of this library lead me to believe that this will occur. Robert Ramey

3 2

FC++ review
by Dave Gomboc 02 Mar '04

02 Mar '04

I put about a day into looking at FC++ (reading the papers, trying to write some small examples). I didn't have a lot of success -- partly because it has been quite a while since I last programmed in a functional language, and partly because the documentation needs serious work. Therefore, I don't have a full review to provide. Much like the serialization library, I think that this is an ambitious and important library that isn't ready to pass a Boost review on its first time around. If the author is up to it, then I'm sure further work will get it there. Re argument limit of 3: I'm a bit surprised that this has never been a problem. Seeing what boost::preprocessor can do for you is probably a good idea. Naming nit-picks: "Functor" has for years been commonly used to mean "function object" (in addition to its original meaning from category theory). [http://www.dre.vanderbilt.edu/~bala/c++-function-objects.pdf; http://www.sgi.com/tech/stl/functors.html; http://en.wikipedia.org/wiki/Functor] Have no referees of your academic publications brought this up? There is no need to name anew a common concept: therefore, s/functoid/functor globally! (Global search and replace is your friend. :-) A list type is already present in ::std, and means something different. Perhaps lazy_list, or (cringe) llist. Follow the C++ standard's practice for variable naming, e.g. TheActualTypeOfTheLambdaExpressionIsNotConvertibleToItsGivenType should be the_actual_type_of_the_lambda_expression_is_not_convertible_to_its_given _type (example from lambda.hpp)

5 5

FC++: formal review
by Gennadiy Rozental 02 Mar '04

02 Mar '04

Hi, It was quite difficult to review this submission for several reasons: mostly because (from POV) it has virtually no documentation, no structure, no testing and what is most important no clear defined problem domain, where this library provide a solution (here I mean not the function objects facilities, but namely FP part of the submission). What it does have, is a several interesting ideas. In summary it my opinion this submission is unacceptable and my vote is NO. Problem domain ------------------------------------------------------------------------- Unlike my usual review I would like to start with problem domain discussion. Library position itself as a library to do FP in C++. Namely in this order. Kind of like library for crazy Haskell programmer that for whatever reason decided to use C++. Docs (and papers) in details describe how to do things one could do in Haskell using FPC++ analogs. There is even comparison of performance with Haskell compilers: not to worry we almost as fast. For me as a C++ programmer more important is to see the comparison with the same algorithm implemented with other usual C++ techniques. I did one myself. I took an example used by authors for performance testing and modified it like this: .... here is what is already in test //////////////////////////////////////////////// inline bool is_prime( int i ) { for( int c = 2; c <= i/2; ++c ) { if( i % c == 0 ) return false; } return true; } inline int nth_prime( int N ) { int i = 1; while( N > 0 ) { i++; if( is_prime( i ) ) N--; } return i; } int main() { acc_timer timer; // acc_timer is my timer class based on gettimeoftheday int NUM; cout << "Num primes = "; cin >> NUM; timer.start(); list<int> l = primes(NUM); int i = at( l, NUM-1 ); timer.stop(); cout << i << endl << "took " << timer.elapsed() << " sec" << endl; timer.start(); i = nth_prime( NUM ); timer.stop(); cout << i << endl << "took " << timer.elapsed() << " sec" << endl; } The algorithm I am using similar to the one use by original code. The only difference is that I am not using FC++ abstraction. I was using gcc 3.3.1 under cygwin on my Athlon 2000+ PC. I was using following command for compilation: g++ -O4 -I [list of include directories] tw_primes.cpp Here is the result of several runs: Num primes = 500 3571 took 4.825 sec 3571 took 0.015 sec Num primes = 750 5693 took 11.703 sec 5693 took 0.036 sec In average FC++ solution is 320 times slower. For any practical usage price of an abstraction should not exceed 10-20%. With price as high as FC++ currently shows I wouldn't even start to think in this direction. In general from my experience usage of lazy evaluation quite limited (in FP sense - I do not mean binding the arguments, which is widespread). It may be used sometimes, but I know many more other neat tricks that are more or as useful. IMO authors need to justify need in lazy list as a generic reusable components in C++ (namely in C++ not for FP which says nothing to me), but for now I do not see a place for them. Some papers does try to justify need for FP to implement common design patters in C++. But actually they only shows need for use of polymorphic functors nothing more. Design ------------------------------------------------------------------------- I with almost everything authors says about need of polymorphic functors and the way they design support for result type deduction. But I believe it should be boost-wide solution. With support in both boost::function, boost::bind and boost::lambda. I don't think we need indirect functoids (with their virtual functions and smart_pointers inside). boost::function should be made result_of aware instead. I couldn't comment on design of lazy lists since it does not described in docs. But I still not convinced that there exist a problem to justify need for this construct. Lambda facilities design is also offsite and it's difficult to comment on it by itself and on comparison with boost::lambda. In my personal opinion there should not be two different facilities dedicated to the same cause within boost. If you have any issues with boost::lambda lets resolve them. In other case it would only source of confusion to the users and make them both less useful. Monads are not covered and not commented accordingly. Explicit built-in currying (I prefer term binding) looks like convenient idea and I would vote to include this info boost::function Implicit built-in currying on the other hand like more like a source of confusion than convenience and in my opinion should not be included. It not only may confuse inexperienced user, but also may cause a conflict If I have function polymorphic not only in regards to the type of the arguments but also in regards to their number. I do not understand need for separate notion of thunks. Why couldn't we just bind all function arguments using usual means? Library supply the collection of predefined function object. While I can blindly accept polymorphic counterparts to the STL functional ones, the rest should be documented and discussed one by one (the fact they belong to mythical "prelude" says nothing to me). Also from sources it looks like many of them operate on lazy lists. Why couldn't we have them as a member functions? They are not generic to be used for different kinds of lists (like STL list) and what is an advantage to length ( ll ) vs. ll.length(). Would I need to pass this method anywhere (rare case IMO) I could use an adaptor. Infix syntax: I do not think this feature useful enough to justify weird syntax. Most probably it wouldn't be use for anything other then several functors like plus, minus. Documentation ------------------------------------------------------------------------- There two major problems I have with docs: first they are very scarce on design of the component described and second they are written for Haskell programmer who is learning C++. I believe that at least 90% of C++ practitioners never heard about Haskell. Accordingly it should not be mention in docs AT ALL. The should not be ANY references to Haskell syntax, which instead of clarifying things make it worse and left me with feeling that I did not get something. There should be a short introduction to what is a functional programming paradigm. Comparison with existent C++ paradigms, advantages and disadvantages. I don't say it should be extensive multipage work, but just an introduction for C++ programmer not familiar with FP. There should be reference documentation for any functor supplied by the library. I am not sure there is a need for old (pre boost) references in docs. It absolutely unnecessary for new users. Why existent users may use some kind of transition guide in FC++ website. The rest of docs looks in most part as a "simple overview", while I expect to see a real full documentation. Implementation ------------------------------------------------------------------------- 0. It would be much easier if you would follow recommended boost directory structure 1. BOOST_FCPP_DEFER_DEFINITIONS This does not look like a good solution. What exactly did you try to achieve? 2. definition.cpp What is this? Does it gets compiled by any compiler? 3. All implementations needs to be rewritten using Boost PP to be extendable to more then 3 arguments. 4. Why fullN does not inherit from it's parameter, but keep it as a member instead? 5 What is konst vs. const? 6. When you will eliminate implicit currying implementation became more simple 7. binderNandK...ofM facility does not look extendable. Did you look how boost::bind is implemented? 8. There are still a lot of identifiers that does not follow recommended boost naming policy 9. Why infix syntax implementation is mixed with some library supplied functors? Testing/Examples ------------------------------------------------------------------------- There is a lot of staff in fcpp_clients directory. Since there is no test/examples separation and no Jamfiles I couldn't comment in details how it looks. Regards, Gennadiy.

7 9

Win32 regressions
by Beman Dawes 02 Mar '04

02 Mar '04

One of the actions we can take to ease releases is to fix regressions as they occur, rather than waiting until just before the next release. I'm experimenting with some new reports that combine platforms, report regressions only, and make other improvements suggested by various people. Those experiments will take a while because I'm learning xslt in the process, and have some other commitments. In the meantime, I've changed the Win32 table (http://boost.sourceforge.net/regression-logs/cs-win32.html) to show diffs against February 3rd rather than just the prior day's run. Looking at the results, there is lots of good news. Tests now passing, warnings removed, etc. But there are also regressions in a number of libraries: Date-Time - Borland regressions, one VC++ 7.0 regression. Graph - Borland, Metrowerks, VC++ 6.0, one regression each. Interval - Borland, VC++ 6.0, and VC++ 7.0 regressions. Random random-test - Regression on GCC 3.3.1. Regex concept_check - Regression on VC++ 6.0. Test test_tools_test - Regressions on VC++ 6.0 and 7.0. Hopefully the developers will take a look at these soon so the regressions don't hang around until the next release. Thanks, --Beman

5 6

Error while building threads/tutorial folder
by M Shetty 02 Mar '04

02 Mar '04

Hi, I am kind of really new to boost and to jam files. I have built bjam and then libboost_thread.so by executing bjam in the boost-1.30.2/libs/thread/build folder. But building the files in the boost-1.30.2/libs/thread/tutorial folder gives me the following error: ...found 649 targets... ...updating 11 targets... gcc-Link-action ../../../libs/thread/tutorial/bin/helloworld/gcc/debug/runtime-l ink-dynamic/threading-multi/helloworld Undefined first referenced symbol in file logic_error::logic_error(basic_string<char, string_char_traits<char>, __default_ alloc_template<true, 0> > const &)../../../libs/thread/build/bin/libboost_thread .so/gcc/debug/runtime-link-dynamic/shared-linkable-true/threading-multi/libboost _thread.so runtime_error::runtime_error(basic_string<char, string_char_traits<char>, __defa ult_alloc_template<true, 0> > const &)../../../libs/thread/build/bin/libboost_th read.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/threading-multi/libb oost_thread.so ld: fatal: Symbol referencing errors. No output written to ../../../libs/thread/ tutorial/bin/helloworld/gcc/debug/runtime-link-dynamic/threading-multi/helloworl d collect2: ld returned 1 exit status Unable to understand this kindly help. Regards, Manu ___________________________________________________ Check-out GO.com GO get your free GO E-Mail account with expanded storage of 6 MB! http://mail.go.com

1 0

Re: Re: Re: [rational] why is int_type private?
by Bjorn.Karlsson＠readsoft.com 02 Mar '04

02 Mar '04

> From: Jonathan Turkanis [mailto:technews@kangaroologic.com] > > I'd be happy to contribute these changes. My thinking was, however, > that they should wait for a new maintainer of the library. What do you > think? > Yes, that sounds reasonable; I'll contact Paul to get his view (on both this change and future maintenance of Boost.Rational). Bjorn

1 0

shared_array: how to get the number of elements in it?
by Roland Richter 02 Mar '04

02 Mar '04

Boosters, I want to write a function which compares two shared_array's element-wise (operator==() compares for pointer equality). How to get the number of elements a given shared_array contains? At first glance there seems to be no possibility; am I missing something? - Roland

3 2

Re: Re: Re: [rational] why is int_type private?
by Bjorn.Karlsson＠readsoft.com 02 Mar '04

02 Mar '04

> From: Jonathan Turkanis [mailto:technews@kangaroologic.com] > > Okay, here's a patch for boost/rational.hpp. Please let me know if > it's not in a suitable format. > > Jonathan Thanks Jonathan, It would be even better with a patch for the documentation, too. Making these two typedefs public warrants more than just changing private to public in the code, in my opinion. (Note: Context diffs are preferred [diff -c] - see http:://www.boost.org/more/bugs.htm for details.) Bjorn

2 2