- Boost - lists.boost.org

** releasing **
by David Abrahams 26 Sep '04

26 Sep '04

Hi Everyone, This is just a reminder that we are trying very hard to get to a release point. Aleksey has been making an incredible effort in managing this release, so please do everything in your power to be responsive to his requests. Being proactive is even better, so if you can, see if there are any regressions you can fix. Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

3 3

BOOST_STATIC_ASSERT and gcc 3.3
by Mark Purtill 26 Sep '04

26 Sep '04

BOOST_STATIC_ASSERT doesn't produce a useful error message with gcc 3.3. E.g.: #include <boost/static_assert.hpp> BOOST_STATIC_ASSERT(0); produces % g++ -c -o bsa.o bsa.cpp bsa.cpp:3: error: invalid application of `sizeof' to an incomplete type According to <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15337>, this is fixed, but some of use will still be using gcc 3.3 for a while. It turns out the version of BOOST_STATIC_ASSERT used when BOOST_INTEL_CXX_VERSION is defined works for the offending versions of gcc, too: #include <boost/static_assert.hpp> # define BOOST_STATIC_ASSERT_1( B ) \ typedef char BOOST_JOIN(boost_static_assert_typedef_, __LINE__) \ [ ::boost::STATIC_ASSERTION_FAILURE< (bool)( B ) >::value ] BOOST_STATIC_ASSERT_1(0); produces % g++ -c -o bsa.o bsa.cpp bsa.cpp:6: error: incomplete type `boost::STATIC_ASSERTION_FAILURE<false>' does not have member `value' Could that version be used for gcc 3.3 and 3.4.0 in the upcoming boost 1.32? FYI: % gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs Configured with: /var/tmp/portage/gcc-3.3.4-r1/work/gcc-3.3.4/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3 --includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info --enable-shared --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib --enable-languages=c,c++ --enable-threads=posix --enable-long-long --disable-checking --disable-libunwind-exceptions--enable-cstdio=stdio --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext --disable-multilib --enable-__cxa_atexit --enable-clocale=generic Thread model: posix gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) -- ^.-.^ Mark Purtill (("))

2 1

mpl::equal_to changes
by Ian McCulloch 26 Sep '04

26 Sep '04

Hi, Is the following program supposed to compile with the new MPL? It works fine with boost 1.31, but apparantly fails in CVS. But, maybe I was mis-using equal_to ? #include <boost/mpl/equal_to.hpp> #include <boost/mpl/bool.hpp> int main() { boost::mpl::equal_to<boost::mpl::bool_<true>, boost::mpl::bool_<true> > dummy; } Error message from CVS is: (thanks to Matthias Troyer for testing it) ../boost/boost/mpl/aux_/preprocessed/gcc/equal_to.hpp: In instantiation of `boost::mpl::equal_to_tag<mpl_::bool_< true> >': ../boost/boost/mpl/aux_/preprocessed/gcc/equal_to.hpp:72: instantiated from `boost::mpl::equal_to<mpl_::bool_< true>, mpl_::bool_< true> >' test.C:11: instantiated from here ../boost/boost/mpl/aux_/preprocessed/gcc/equal_to.hpp:60: error: no type named `tag' in `struct mpl_::bool_< true>' ../boost/boost/mpl/aux_/preprocessed/gcc/equal_to.hpp: In instantiation of `boost::mpl::equal_to<mpl_::bool_< true>, mpl_::bool_< true> >': test.C:11: instantiated from here ../boost/boost/mpl/aux_/preprocessed/gcc/equal_to.hpp:72: error: no type named `type' in `struct boost::mpl::equal_to_tag<mpl_::bool_< true> >' Cheers, Ian

4 4

[numeric/conversion] fixes for intel-win32-7.1-vc6
by Joaquín Mª López Muñoz 26 Sep '04

26 Sep '04

These are trivial fixes taking care of BOOST_NO_STDC_NAMESPACE. With them, converter_test and udt_support_test (the latter is currently marked as known fail) work for Intel 7.1. OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 33a34 > #if !defined(BOOST_NO_STDC_NAMESPACE) 35a37,38 > #endif > 52a56 > #if !defined(BOOST_NO_STDC_NAMESPACE) 55c59 < --- > #endif 81a86 > #if !defined(BOOST_NO_STDC_NAMESPACE) 82a88,89 > #endif > 97a105 > #if !defined(BOOST_NO_STDC_NAMESPACE) 98a107,108 > #endif > 496a497,498 > > #if !defined(BOOST_NO_STDC_NAMESPACE) 497a500,501 > #endif >

3 5

[Signals] Regressions/crashes on Linux and CodeWarrior
by Aleksey Gurtovoy 26 Sep '04

26 Sep '04

Half of the signals tests on Linux -- on both Intel and GCC -- crash with access violation; for instance (from http://tinyurl.com/6esxs) Run output []: /boost/head-regression/boost/boost/test/minimal.hpp(127): exception "signal: memory access violation" caught in function: 'int main(int, char **)' **** Testing aborted. **** 1 error detected EXIT STATUS: 201 Same for CodeWarrior 8.3 on Windows. Could somebody with access to the environment take a look at it, please? -- Aleksey Gurtovoy MetaCommunications Engineering

4 4

[random] intel-win32-8.0 failures
by Aleksey Gurtovoy 26 Sep '04

26 Sep '04

Could somebody take a look/comment on this one (from http://tinyurl.com/4k3f2) "C:\Programme\Intel\CPP\Compiler80\Ia32\bin\icl" /Zm800 -nologo /EHsc -c /Z7 /Od /Ob0 /EHsc /GR /MDd /Op /Zc:forScope /Zc:wchar_t /Qwn5 /Qwd985 -Qoption,c,--arg_dep_lookup /Qansi_alias -D_NATIVE_WCHAR_T_DEFINED /Qvc7.1 -I"C:\boost_regression\results\bin\boost\libs\random\test" -I"C:\Programme\Microsoft Visual Studio .NET 2003\VC7\include" -I"C:\boost_regression\boost" -Fo"C:\boost_regression\results\bin\boost\libs\random\test\random_demo.test\intel-win32-8.0\debug\threading-multi\random_demo.obj" -Tp"C:\boost_regression\boost\libs/random/random_demo.cpp" random_demo.cpp C:\boost_regression\boost\libs/random/random_demo.cpp(122): error: no operator "<<" matches these operands operand types are: std::ofstream << base_generator_type file << generator; ^ compilation aborted for C:\boost_regression\boost\libs/random/random_demo.cpp (code 2) ? It seems like Intel 8.0 for Windows is the only compiler that has this problem (the one for Linux is OK). -- Aleksey Gurtovoy MetaCommunications Engineering

3 6

Python again
by Stefan Slapeta 26 Sep '04

26 Sep '04

Anybody an idea what is the reason for the "new" white cells (Intel-win32, cw, vc*)? I can find nothing about these tests in bjam.log but a single line in the list at the beginning boost-test(COMPILE) "python/select_arg_to_python_test" : "libs\python\test\select_arg_to_python_test.cpp" ...so it very much looks like they are not compiled at all! Stefan

3 3

Please, comment design decision of simple FSM
by Alexander Nasonov 25 Sep '04

25 Sep '04

After playing with my overloads library and trying to apply it to FSM I realized that some metaprogramming can be replaced with natural overload resolution rules. After realizing it, I come to conclusion that simple FSM can be implemented as a set of call operators and a list of states. Each call operator represents a transition and follows this pattern: NewState operator()(State,Event) const; Transition functions are generated in process_event function on first call (in a constructor of static variable, for example). Each function extracts current state from StatesAsVariant (boost::variant of all states): template<class StatesAsVariant, class State, class Event> void transition(FSM& fsm, StatesAsVariant states, Event event) { states = fsm( get<State>(states), event); // select best transition // according to overload // resolution rules } The only metaprogramming algorithm is for_each<States> to initialize transition table for the event. Comments? -- Alexander Nasonov

3 13

Re: CW 9.3 results (or lack thereof) - uBLAS fails
by Michael Stevens 25 Sep '04

25 Sep '04

Stefan Slapeta wrote: > I've noticed that once again all ublas test cases threw a gpf in the > last run or CW 9.3. I think I used the latest sources, but at the moment > I've switched back to non-incremental builds and thus we can be sure > tomorrow. I suspect we have some real problem. The failure conditions are interesting. In all cased the first test set which is instantiated with double is successful. Then when instantiated with std::complex<double> the same test fails. Generally this failure is in a swap operation. test4 is however interesting. The first test only constructs two vectors and then destructs them on function return. It also fails with std::complex<double>. So I am suspecting some memory management problem related to complex<double>. If anyone has the time I would to see a call trace at the point of failure. Thanks, Michael

2 1

Re: [boost] [multi_index + mpl + bind] Regression?
by JOAQUIN LOPEZ MU?Z 25 Sep '04

25 Sep '04

Vladimir, I don't have my compiler handy right now, but I think this is due to an overlook when doing the adaptation to the new MPL. In particular, the line 50 in boost/multi_index/detail/node_type.hpp: typedef typename IndexSpecifierIterator::type index_specifier; should be changed to typedef typename mpl::deref<IndexSpecifierIterator>::type index_specifier; (also, the corresponginf #include <boost/mp/defer.hpp> must be inserted) Could you please try this locally and report the results? If the problem is solved, I'll commit something along this line next Monday. I don't know the rationale for having to use deref, since I thought these two expressions are equivalent, but there must be some difference, for Alexsey changed some of the code in multi_index to do that when mergien the new MPL. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ----- Mensaje original ----- De: Vladimir Prus <ghost(a)cs.msu.su> Fecha: Sábado, Septiembre 25, 2004 2:41 pm Asunto: [boost] [multi_index + mpl + bind] Regression? > > The attached code, which use the multi_index library, produces > screens of > errors from mpl. The STLfilted log is attached too. > > Commenting out #include <boost/bind/arg.hpp> makes the error go > away, as well > as including it after multi_index. > > This happens with: > gcc version 3.3.4 (Debian 1:3.3.4-6sarge1) > gcc version 3.4.1 (Debian 3.4.1-4sarge1) > > The code used to work some time ago, but I can't give the exact date. > > I've tried too look at the problem, but got lost in MPL internals. > > - Volodya > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1