- Boost - lists.boost.org

Boost.Test: major update
by Gennadiy Rozental 11 May '05

11 May '05

Hi, I would like to take this moment to share with you finally the modifications Boost.Test went through during last couple month. Most of Boost.Test components undergo a major or significant change in both design and implementation. I've strived to keep an interface unchanged as much as possible. The primary goals for this update were: * Make a unit test framework better suited for different 'runners' * Make unit test framework simpler internally by eliminating test cases hierarchy * Make test tools more uniform * Make auto unit test framework as usable as possible Following are details of what updated/changed specifically in each area of Boost.Test: I. Execution Monitor The execution monitor design changes from inheritance to delegation. If previously one needed to inherit from the boost::execution monitor to do a monitored run of a function, now one need to employ an instance of the boost::execution_monitor: boost::execution_monitor em; // register translators for custom user exception em.register_exception_translator<ExceptionType>( my_translator ); em.execute( function_to_execute ); function_to_execute should be any zero arity function or function object. To implement the polymorphic function handling I employ my own class callback (see utilities section). I did not want to introduce a dependency on Boost.Function. But in a future I plan to switch to tr1::function. In addition following features implemented: * Debugger presence detected, in which case catching system errors (SEH) is disabled unless explicitly enabled. For now only works for msvc family * Automatic detection of memory leaks introduced. For now only works for msvc family Unit test framework turns this feature on by default. User could manage it by specifying runtime parameter (in a form of command line argument or environment variable). For example test --detect_memory_leak=<leak_allocation_number> set leak_allocation_number to integer number: 0 - to disable detection of memory leaks; 1 - to enable detection of memory leaks; N>1 - to enable detection of memory leaks and set a system breakpoint at the moment of Nth memory allocation. For more on how to find N and some issues with usage of this feature see documentation II Unit test framework (UTF) This component of Boost.Test undergo a most dramatic changes in both design and implementation. Here are main modifications: 1. UTF doesn't employ test cases hierarchy anymore. There is single class test_case that model one testing unit and class test_suite that model a collection of test units. Previously UTF employed compound test cases (for example parameterized test case) which went through it's components (simple subtests) during testing run time. Now compound test present itself as test case generator which produce a collection if test_case instances during test tree construction time. One consequence of this is that user doesn't need to keep track of compound test case parameters is it used be. test_case now employs a polymorphic callback to a actual test function. As a result of this one could supply any zero arity function as an argument of BOOST_TEST_CASE. SO no extra support needed to be able to create boost::function or boost::bind based tests cases. 2 .Introduced generic mechanism to traverse the test tree. Anyone willing to do so just need to implement test_tree_visitor interface and employ traverse_test_tree. This allows to implement any pre/post processing over test tree. 3. Introduced a notion of framework. The framework is responcible for: a) initializing and providing access to master test suite b) providing access to current test case c) running testing from given test tree node (simple or compound). By default it runs from root - master test suite. Supports both sequential and random order. d) One may register any test observer agent (implements test_observer interface) and framework notifies it of all test events e) providing access to any test case based to unique test unit id Using the framework one could implement different test runners. UTF library supplies one console runner (unit_test_main.cpp). But it's possible to do one winmain based or anything else. For example GUI program that build test tree and then run tests by request from any point in test tree. 4. Unit test log interface changed to single line (used to be begin/end macros). Unit test log formatter interface changed. How it much simpler and straightforward. Two supplied implementation are separated. 5. Notion of unit test result that was responcible for result collection and reporting eliminated. Instead introduced independent notions: results_collector and results_reporter. Results reporting formatter interface made public. Also results_reporter now allows to change an output stream. 6. Progress monitor functionality (which used to be activated in log level log_progress) now is an independent test observer and implemented by class progress_monitor. 7. Test case template interface changed. Now user doesn't need to explicitly register meta class. In addition couple more features implemented: * Added support for test case timing * UTF made __cdecl - safe * Result report include skipped tests * io saver facilities employed to guard against undesirable modification in output streams formatting * template test case automatically generate name that includes type name * --detect_memory_leak and --random cla added III Test Tools The two major changes in Test Tools are: * Test Tools interfaces to provide 3 version for each tool: CHECK- reports an error if assertion failed WARN - reports a warning if assertion failed REQUIRE - reports an error if assertion failed and aborts test case execution * Test Tools implementation completely reworked. All tools implemented now through single vararg function In addition following modifications made: * CHECK_COLLECTION interface changed: it now expect 4 arguments * BITWISE_EQUAL renamed to CHECK_BITWISE_EQUAL; old name still provided, but is deprecated * CHECK_COLLECTION interface changed to use PP_SEQ and as a result support arbitrary(actually maximum is fixed but configurable) number of predicate arguments * most of templates eliminated speeding up test modules compilation * floating-point precision set to include all significant digits (actually the formula may require some rework since it obviously doesn't do a good job sometimes) * BOOST_CHECK/WARN/REQUIRE_SMALL test tool added * old test tools names are *deprecated* IV Auto unit test framework Interesting discussion with Noel Llopis and several user requests lead to several additions to the auto_unit_test.hpp. Here is a short descriptions: * BOOST_AUTO_UNIT_TEST renamed to BOOST_AUTO_TEST_CASE. Old name still provided but deprecated * BOOST_AUTO_TEST_CASE_TEMPLATE provides an ability to write a self-registering test case template * BOOST_FIXTURE_TEST_CASE provides an ability to write a self-registering test case with fixture * BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES provides an ability to specify a number of expected failures in any self-registering test case * BOOST_AUTO_TEST_SUITE and BOOST_AUTO_TEST_SUITE_END provide an ability to structure test cases into self-registering test suites V Included components Implementation moved from source files (.cpp) under lib/test/src into implementation files (.ipp) under boost/test/impl to eliminate dependency of included/minimal components on lib/test/src directory. VI Utilities Basic utilities that may have value outside of Boost.Test now separated into utils subdirectory. If there is an interest to promote any of them onto public boost level I am ready to discuss it. Here is a short descriptions (some of them existed before, but most are new): 1) algorithm.hpp Implements several variations of STL algorithms including 4-arg mismatch 2) assign_op.hpp Hook for overloadable assignment 3) callback.hpp Implements a polymorphic function callback facility (similar to boost::function). 4) class_properties.hpp Simple facility that mimic notion of read-only read-write properties in C++ classes 5) custom_manip.hpp Simple helpers for creating custom output manipulators 6) fixed_mapping.hpp Fixed sized mapping (initialized in constructor ) with specified invalid value. 7) foreach.hpp This is an abridged version of BOOST_FOREACH. The only difference is portability. 8) named_params.hpp Facility for named function parameters support. Even though Dave A. did not see a value in my suggestion during Boost.Parameter review period. I couldn't justify for myself using that inconvenient interface (IMO) and absence of optional parameters. This facility implements an alternative solution with different set of tradeoffs and features. It used in several places in Boost.Test. 9) nullstream.hpp I should probably deprecate this one , but more-io was not accepted. 10) rtti.hpp Simple alternative to compiler RTTI. Provides an access to unique type id at runtime. I plan to extend this to implement type_descr similar to what is described in "C++ template metaprogramming". 11) trivial_singleton.hpp As the name suggest this simple singleton helper. 12) wrap_stringstream.hpp Wraps strstream and stringstream (depends with one is present) to provide the unified interface 13) basic_cstring/ class template basic_cstring wraps raw memory pointers and provide std_string like interface 14) iterator/input_iterator_facade.hpp Helps to build input iterators 15) iterator/token_iterator.hpp Yet another token iterator 16) iterator/istream_line_iterator.hpp Iterate over istream and produce lines 17) runtime/ This is long promised framework for parsing CLA handing environment variable and parsing config files. This is an alternative solution to what boost::program_options present. Unfortunately I did not have enough time to incorporate it completely into Boost.Test main components, so the detailed description will follow once this will happened. Sorry, for babbling for so long. Any comments are greatly appreciated. Regard, Gennadiy

3 5

[patch] Memory leak in the thread_specific_ptr implementation in Boost.Threads
by Jeremie Detrey 11 May '05

11 May '05

Hello, It seems to me that there is a possibly huge memory leak in the file boost/libs/thread/src/tss.cpp, as the thread specific data slot vector is allocated (line 120) but never freed. It causes a few bytes' memory leak for each thread, as it appears when using valgrind (see attached files: input program = example.cpp, valgrind output = example.valgrind). I propose here a simple patch to fix this. It works perfectly with my programs, and frankly I cannot see why it should not work. Thanks, Jeremie Detrey.

1 0

Boost.Python embedding/extending example
by Neb Naic 11 May '05

11 May '05

Hello, I have an application that I need to both embed and extend Python. The Python portion is actually an existing plotting utility that I�m trying to leverage in a legacy C++/OpenGL application. The Boost.Python tutorial has helped me successfully expose my C++ classes to Python. However, I�m having difficulty embedding the Python � accessing Python interfaces from C++. The tutorial examples seem to lean toward embedding Python statements rather than actually addressing interface issues (IMHO). Assuming the Python code to embed is in its own file (not actually embedding Python statements), does Boost.Python provide an encapsulated class or functional interface? Documentation/examples? Any help is greatly appreciated. Thanks, Niac __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

2 1

[interfaces] would the following work?
by Joaquín Mª López Muñoz 11 May '05

11 May '05

Is (the proposed) Boost.Interfaces lib able to handle the following scenario? template<typename T> interface IIterator { T& operator*()const; ... }; template<typename T> interface IContainer { IIterator<T> begin(); IIterator<T> end(); ... }; It is not the issue of specifying an operator as part of the interface IIterator (this'll be taken care of in the future according to the docs), but the fact that IContainer::begin is required to return an object implicitly convertible to IIterator<T>. Can Boost.Interfaces do that? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo PS: Just for motivation, I' thinkthi s idiom could be taken advantage of in a possible implementation of a dynamic multi-index container.

1 0

Re: [mpl] Math sublibrary: new version.
by Cromwell Enage 11 May '05

11 May '05

--- Andy Little wrote: > > There may be an implementation of gcd<> that is > > more efficient even if it works solely on > > big_integral<> numbers. > > Surely it would make sense to specialise this for > big_integral. Yes. > > Or there may not, but for now, I shouldn't rule out > > anything that promises to make big_integral<> > > operations less expensive. > > But these operations will now be unneccessarily > expensive for small_int types. Then there should be a gcd specialization for them, too, right? One that doesn't require recursive apply2<> calls? > Your version of gcd looks is obviously optimised > for big_integral. Really? I haven't even taken advantage of anything that's specific to big_integral<>, but okay... ...if I ever get big_integral<> to work. > However my requirements on rational would be for a > large number of smallint types. I hope you will take > this into account in the design and favour the > implementation more towards small_int types as well. Okay. > OK maybe that would be quicker, and give better error > messages. But you will need a tag dispatch mechanism > anyway wont you?, to avoid a large number of > specialisations. Yes. Like I said, I'll do that. Cromwell D. Enage Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html

1 0

[patch, boost.regex] Kill warning when compiling without exceptions
by larsbj＠gullik.net 11 May '05

11 May '05

This is the only warning I get when compiling the subset of boost that is included in LyX. Would be nice to see this in 1.33. This is with gcc 3.3.3. diff -ru --exclude=CVS boost/boost/regex/v4/basic_regex_parser.hpp lyx-upboost/boost/boost/regex/v4/basic_regex_parser.hpp --- boost/boost/regex/v4/basic_regex_parser.hpp 2005-05-09 10:35:34.000000000 +0200 +++ lyx-upboost/boost/boost/regex/v4/basic_regex_parser.hpp 2005-05-10 22:27:37.124642889 +0200 @@ -147,6 +147,8 @@ template <class charT, class traits> void basic_regex_parser<charT, traits>::fail(regex_constants::error_type error_code, std::ptrdiff_t position) { + // Avoid warnings when compilinging without exceptions. + (void)position; if(0 == this->m_pdata->m_status) // update the error code if not already set this->m_pdata->m_status = error_code; m_position = m_end; // don't bother parsing anything else -- Lgb

2 1

[mpl] Math sublibrary: new version.
by Cromwell Enage 11 May '05

11 May '05

--- Dan Perry wrote: > I need some sort of compile time float type that > supports multiplication and division. I found your > comments on the gmane.comp.lib.boost.devel newsgroup > via google but I can't access your mpl_math.zip > file. Could you send me your source? Thanks. The file has a new home. Go to <http://boost-sandbox.sourceforge.net/vault/>, look under the subdirectory "expaler", and download from there. Major issues: 1. The big_integral<> numeric "metatype" is still a compiler resource hog. If I could use list<> instead of vector<>, I may be able to make it more efficient. To do so, I would need to know how to iterate through two lists "concurrently" instead of one list at a time. Aleksey Gurtovoy, any pointers? 2. The most recently added numeric metafunctions, which are square_root<>, exponent<>, sine<>, cosine<>, arctangent<>, hypersine<>, and hypercosine<>, are either insufficiently tested or not tested at all. 3. The numeric_caster_rt facility probably needs a more appropriate name. It is untested with wrt boost::rational as the ResultType. It is also non-functional wrt complex_number<>, at least until I figure out how to use std::complex. 4. Documentation should be available in the next version. For now, the source code, examples, and test programs will have to suffice. Andy Little wrote: > Why not call this one mixed_number? Okay, your suggested name changes have been applied. Also, except for big_integral<>, the NumberSign parameter is now removed. Examples: rational<int_<11>,integral_c<long,16> > rational_c<long,-9,5> mixed_number<long_<2>,int_<54>,integral_c<int,100> > mixed_number_c<int,0,-2,5> The following expressions are currently illegal: rational<int_<1>,int_<0> > rational_c<long,9,-5> mixed_number<long_<3>,int_<-1>,integral_c<int,2> > mixed_number_c<int,0,6,5> I'm currently debating with myself about whether to make aux::rational2mixed_number<> part of the public interface; and if so, whether to rename it to something more legible; or if not, whether mixed_number<> and mixed_number_c<> should take default parameters. > IMO the rational Concept should hold independent of > the exact parameters. The types used for the > parameters are a trade off between using small_ints > and having a relatively quick compile with the > possibility of everflow, as against big_integers with > long compile (and posibly run) times. Actually only the relationship between the concept and the implementation models was dependent on the parameter "metatypes". But I know what you meant, so don't worry about it. > However in a large number of cases a rational has > known bounds, so an inbuilt int has ample range. Yeah. It's when you try things like the square_root<> example program (included in the zip file) that the inbuilt range becomes not enough. > I am wondering if the more lazy implementation > possible by moving away from integral constant > expansion might improve matters. OTOH perhaps it > will make matters worse. (I am no expert on 'lazy' > programming...but it must have some benefit?) I'll try to implement some lazy versions of both big_integral<> and the new numeric metafunctions in the next version. > It is merely one among several possible compile time > types that Might be useful as parameters. Other > possibilities are the aforementioned big_int and a > complex, should One not try to make the thing generic > as possible? I dont think anything is lost by it. > Even if the helper functions like gcd and abs are not > useful for this they may come in useful somewhere > else. I've reimplemented rational<> so that it accepts any numeric constants M and N for which modulus<M,N> is a valid expression. That should improve its genericity. Cromwell D. Enage __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

2 3

[serialization] gcc 3.4.3 / ld / serialization issue?
by Christoph Ludwig 10 May '05

10 May '05

Hi, this post belongs to the thread <url:http://lists.boost.org/MailArchives/boost/msg76063.php> but I don't have that thread in my local archive anymore. I face the same problem as Curtis Spencer did. Linking an application built with g++ 3.4.3 against boost_serialization-gcc-mt produces warnings from the linker: g++ -pthread -g -O2 -pthread -o testsuite-LaRed testsuite-LaRed.o ReductionTestdata.o testcase-Testdata.o testcase-Matrix.o testcase-GS.o testcase-LLL.o testcase-BKZ.o testcase-RSR.o -L/home/cludwig/Cxx/gcc3.4/LaRed-0.1-BUILD/src /home/cludwig/Cxx/gcc3.4/LaRed-0.1-BUILD/src/.libs/liblared_ntl.a /home/cludwig/Cxx/gcc3.4/LaRed-0.1-BUILD/src/.libs/liblared.a -lboost_unit_test_framework-gcc-mt -lboost_serialization-gcc-mt -lboost_filesystem-gcc-mt -L/home/cludwig/Cxx/gcc3.4/usr/lib/ -lntl /usr/lib/libgmp.a `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' referenced in section `.rodata' of /home/cludwig/Cxx/gcc3.4/usr/lib//libboost_serialization-gcc-mt.a(basic_iarchive.o): defined in discarded section `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' of /home/cludwig/Cxx/gcc3.4/usr/lib//libboost_serialization-gcc-mt.a(basic_iarchive.o) (There are similar warnings from basic_text_iprimitive.o and xml_grammar.o. The compiler / Boost configuration are reported at the bottom of this post.) The linker generates an executable anyway and it _seems_ to work. However, I observe infrequent crashes of the application that I don't observe on a machine where I built Boost and the application (without any warnings) with gcc 3.4.2 / ld 2.14.90.0.5. Thus I suspect that the warning is there for a reason and points to the problem causing the crashes. Has anyone an idea what to do about this? I am not sure the problem is caused by the serialization library, but Googling araound I found that it is often exposed by boost_serialization-gcc-mt. There is already a gcc bugreport (PR #16625) w.r.t a similar problem but it seems neither specific to gcc 3.4.3 nor do I see a resolution. Thanks Christoph I built both Boost and my application with gcc 3.4.3: cludwig@cdcNT56:~/Cxx/gcc3.4/LaRed-0.1-BUILD> LC_ALL=C g++ -v Reading specs from /opt/gcc/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/opt/gcc/gcc-3.4.3 --enable-threads=posix --enable-version-specific-runtime-libs --enable-languages=c,c++ --enable-__cxa_atexit --enable-c-mbchar --enable-libstdcxx-debug --enable-c99 --enable-libstdcxx-pch Thread model: posix gcc version 3.4.3 The linker is: cludwig@cdcNT56:~/Cxx/gcc3.4/LaRed-0.1-BUILD> ld -v GNU ld version 2.15.91.0.2 20040727 (SuSE Linux) Boost was built using the following script: cludwig@cdcNT56:~/Cxx/gcc3.4/LaRed-0.1-BUILD> cat ~/Cxx/boost_1_32_0/build-boost_gcc34.sh #!/bin/bash bjam -d2 --with-pydebug \ --prefix=$HOME/Cxx/gcc3.4/usr \ --builddir=$HOME/Cxx/gcc3.4/boost-1.32.0-build \ -sTOOLS=gcc \ -sBUILD="debug release <threading>multi" \ install bjam -d2 --without-python \ --prefix=$HOME/Cxx/gcc3.4/usr \ --builddir=$HOME/Cxx/gcc3.4/boost-1.32.0-build \ -sTOOLS=gcc \ -sBUILD="debug release <define>BOOST_DISABLE_THREADS <threading>single" \ install -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

2 2

Re: [dynamic_bitset] Stream extraction failures on CodeWarrior 9.4
by Gennaro Prota 10 May '05

10 May '05

--- Doug Gregor <dgregor(a)cs.indiana.edu> wrote: > The stream extraction operators for dynamic_bitset are failing on > CodeWarrior 9.4. See: http://tinyurl.com/addko > Is anyone familiar enough with the quirks of Metrowerks' iostreams to > fix this issue? Hi Doug, Jeremy and Howard unfortunately, due to a series of vicissitudes that would be too long to tell, I have no home connection at the moment (a situation that lasts from several months) and thus I can't work on CVS. Howard Hinnant is probably the person who knows Metrowerks compiler and library best. Howard? -- Genny. Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

2 2

[1.33.0] We're moving in the right direction...
by Doug Gregor 10 May '05

10 May '05

Since the last time I sent out status information, we've cleared up about 500 failures. Way to go! Let's keep on chipping away at those failures. Doug

1 0