- Boost - lists.boost.org

[test] Test Execution monitor fate
by Gennadiy Rozental 08 Feb '06

08 Feb '06

Hi, While working on Boost.Test documentation update I've realized that there is no substantial reason anymore to keep this component around. The Unit Test Framework work just as well and does not require any more effort. Here is an example: Using the Test Execution Monitor: ---------------------------------- #include <boost/test/test_exec_monitor.cpp> int test_main( int, char* [] ) { /// your testing is here return 0; } Using the Unit Test Framework: ---------------------------------- #define BOOST_TEST_MAIN #include <boost/test/unit _test.cpp> BOOST_AUTO_TEST_CASE( my_test ) { /// your testing is here } There are monor preferences for either solution (test_main look like main, but require return statement and argument specifications). But from usability standpoint they are similar. I know that many Boost developers are using this component. So I would like to hear community opinion. If nobody speak up I am planning to depricate this component (first from documentation in 1.34, an from source code in 1.36) Regards, Gennadiy

4 3

[serialization] minor fixes
by Vladimir Prus 08 Feb '06

08 Feb '06

JFYI, I've checked in the attached trivial patch. It adds one missing #include (I get compile error without it) and fixes a couple of "signed/unsigned comparison" warnings. - Volodya

1 0

[regex] issue with regex_dll_config_info test?
by Vladimir Prus 08 Feb '06

08 Feb '06

Hello! Looking at libs/regex/test/Jamfile, I'm puzzled by the following part: [ run config_info/regex_config_info.cpp <template>test : : : <test-info>always_show_run_output ] [ run config_info/regex_config_info.cpp <template>test : : : <test-info>always_show_run_output : regex_dll_config_info ] The name of second tests suggests it should somehow test the regex library built as DLL, or something. However, there are no other differences between the tests, and test name does not affect anything at all. I did verify that running the second tests links to a static version of Boost.Regex, and that the generated library has no dynamic links to any boost libraries, just the system ones. So, it looks like tests are completely identical. Is that a bug? Maybe, the second test using be using <template>test-dll? - Volodya

2 2

[tr1] borland config update
by AlisdairM 08 Feb '06

08 Feb '06

Simple update to find the standard library path for Borland compilers using Dinkumware. cvs diff -u -wb -- boost\tr1\detail\config.hpp (in directory E:\sourceforge\devel\boost\) Index: boost/tr1/detail/config.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/tr1/detail/config.hpp,v retrieving revision 1.11 diff -u -w -b -r1.11 config.hpp --- boost/tr1/detail/config.hpp 27 Jan 2006 10:35:38 -0000 1.11 +++ boost/tr1/detail/config.hpp 28 Jan 2006 00:20:48 -0000 @@ -28,6 +28,8 @@ # define BOOST_TR1_STD_HEADER(name) <../include_std/name> # elif defined(__DECCXX) # define BOOST_TR1_STD_HEADER(name) <../cxx/name> +# elif defined(__BORLANDC__) && __BORLANDC__ >= 0x570 +# define BOOST_TR1_STD_HEADER(name) <../include/dinkumware/name> # else # define BOOST_TR1_STD_HEADER(name) <../include/name> # endif -- AlisdairM

2 1

[type traits] Borland 2006 patch
by AlisdairM 08 Feb '06

08 Feb '06

There are quite a few more BCB2006 patches to come, but now that Metacomm tests are running I will submit the more important (that affect dependant libraries) New compiler config header will follow tonight - although it is largely the same as for BCB6. First up, is_enum: cvs diff -u -wb -- boost\type_traits\is_enum.hpp (in directory E:\sourceforge\devel\boost\) Index: boost/type_traits/is_enum.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits/is_enum.hpp,v retrieving revision 1.16 diff -u -w -b -r1.16 is_enum.hpp --- boost/type_traits/is_enum.hpp 7 Oct 2005 14:26:38 -0000 1.16 +++ boost/type_traits/is_enum.hpp 18 Jan 2006 06:58:50 -0000 @@ -52,7 +52,7 @@ template <typename T> struct is_class_or_union { -# if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || BOOST_WORKAROUND(__BORLANDC__, <= 0x570)// we simply can't detect it this way. +# if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x581) )// we simply can't detect it this way. BOOST_STATIC_CONSTANT(bool, value = false); # else template <class U> static ::boost::type_traits::yes_type is_class_or_union_tester(void(U::*)(void)); -- AlisdairM

2 1

[type_traits][cw 9.4] test request
by Joaquín Mª López Muñoz 08 Feb '06

08 Feb '06

Hello, Could any kind soul with access to CW 9.4 try to compile the following and report the results? #include <boost/type_traits/is_convertible.hpp> #include <memory> class foo{}; typedef boost::is_convertible< const std::auto_ptr<const foo *>, const foo> type; int main() { bool b=type::value; } I've got reasons to think this will fail, and hence spot a problem with boost::is_convertible in CW. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

[Boost-bugs] [ boost-Bugs-1427230 ] bug in output the range to an ostream
by SourceForge.net 08 Feb '06

08 Feb '06

Bugs item #1427230, was opened at 2006-02-08 12:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1427230&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: iterator Group: None Status: Open Resolution: None Priority: 5 Submitted By: e-poison (e-poison) Assigned to: David Abrahams (david_abrahams) Summary: bug in output the range to an ostream Initial Comment: followed code can't be compiled std::wstring ws(L"test"); boost::iterator_range<std::wstring::const_iterator> wrange(ws); std::wcout << wrange; // compilation error here It seems the implementation of operator << for iterator_range is not correct: File boost/iterator/iterator_range.hpp #ifndef BOOST_OLD_IOSTREAMS template< typename IteratorT, typename Elem, typename Traits > inline std::basic_ostream<Elem,Traits>& operator<<( std::basic_ostream<Elem, Traits>& Os, const iterator_range<IteratorT>& r ) { std::copy( r.begin(), r.end(), std::ostream_iterator<Elem>(Os)); return Os; } .. I guess the function body should be like this: { typedef typename iterator_value<IteratorT>::type ValueType; std::copy( r.begin(), r.end(), std::ostream_iterator<ValueType, Elem, Traits>(Os)); return Os; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1427230&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[optional] BCB2006 patch
by AlisdairM 08 Feb '06

08 Feb '06

Again, just updating workarounds to recognise the latest compiler version. Fixing optional fixes dependant libraries as well. cvs diff -u -wb -- boost\optional\optional.hpp (in directory E:\sourceforge\devel\boost\) Index: boost/optional/optional.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/optional/optional.hpp,v retrieving revision 1.7 diff -u -w -b -r1.7 optional.hpp --- boost/optional/optional.hpp 25 Aug 2005 16:27:21 -0000 1.7 +++ boost/optional/optional.hpp 25 Jan 2006 19:44:52 -0000 @@ -64,7 +64,7 @@ #endif #if !defined(BOOST_OPTIONAL_NO_INPLACE_FACTORY_SUPPORT) \ - && BOOST_WORKAROUND(__BORLANDC__, <= 0x564) + && BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x581) ) // BCB (up to 5.64) has the following bug: // If there is a member function/operator template of the form // template<class Expr> mfunc( Expr expr ) ; @@ -382,7 +382,7 @@ reference_const_type dereference( internal_type const* p, is_reference_tag ) const { return p->get() ; } reference_type dereference( internal_type* p, is_reference_tag ) { return p->get() ; } -#if BOOST_WORKAROUND(__BORLANDC__, <= 0x564) +#if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x581) ) void destroy_impl ( is_not_reference_tag ) { get_ptr_impl()->internal_type::~internal_type() ; m_initialized = false ; } #else void destroy_impl ( is_not_reference_tag ) { get_ptr_impl()->T::~T() ; m_initialized = false ; } -- AlisdairM

1 0

[typeof] gcc and typeof in function return types
by Andy Little 08 Feb '06

08 Feb '06

Hi Arkadiy and Peder et all I have been testing out replacing my return type deduction scheme in signatures with typeof. see code and errors at the end. Unfortunately gcc has major problems with it. compiles fine in VC7.1 Nevertheless I think its an important use case. Looking through the Typeof tests it doesnt seem to be there. I shall of course submit a bug report to gnu about it though maybe I'll wait to the next release assuming it includes Typeof. I dont suppose theres anything you can do about it, but I thought I'd let you know anyway. regards Andy Little #include <boost/typeof/typeof.hpp> #include <iostream> #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() namespace my{ template <typename T> class udt; } BOOST_TYPEOF_REGISTER_TEMPLATE(my::udt,1); namespace my{ template <typename T> class udt{ T m_value; public: T get_value()const{ return m_value;} udt():m_value(0){} explicit udt(T const & in) : m_value(in){} template <typename T1> udt<BOOST_TYPEOF_TPL(T(1) + T1(1))> operator +( udt<T1> const & in)const { typedef udt<BOOST_TYPEOF_TPL(T(1) + T1(1))> result_type; result_type result(m_value + in.get_value()); return result; } }; template <typename T> std::ostream & operator <<(std::ostream& os, udt<T> const & u) { os << "{" << u.get_value() << "}"; return os; } } int main() { my::udt<int> v1(1); my::udt<double> v2(2.4); std::cout << v1 + v2 << '\n'; } gcc 4.0.1 error: test.cpp: In member function 'my::udt<__typeof__ (boost::type_of::ensure_obj(((T)(1) + (T1)(1))))> my::udt<T>::operator+(const my::udt<T1>&) const [with T1 = double, T = int]': test.cpp:26: internal compiler error: in write_type, at cp/mangle.c:1646 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. gcc 3.2 error test.cpp: In instantiation of `my::udt<int>': test.cpp:40: instantiated from here test.cpp:23: invalid use of template type parameter test.cpp:23: confused by earlier errors, bailing out

4 5

[Boost.Test] A possible feature: run only tests from recently modified sources
by Pavel Vozenilek 08 Feb '06

08 Feb '06

For my work I usually write an unit test and want to execute this test immediatelly to see whether and how it passes. If an application has many, many tests running them all would slow me down and disrupt the flow. To deal with this I once wrote small test library which checks timestamps of source files containing tests and runs only tests from recently modified files. (In my case I run tests from files changed during last 10 mins when the application starts.) This way I am able to write a test and run it within mere second(s). Perhaps similar functionality could be considered into Boost.Test (I didn't find it here). The implementation is portable, it uses only __FILE__, stat() and time(). It may be possible to check also source file dependencies for changes (up to some point) but I do not do it and it is not obstacle for me. Syntax I use looks like TEST { ... assert(...); // assert breaks into debugger } .. run_recently_modified_tests() /Pavel

4 10