- Boost - lists.boost.org

Re: [boost] [Pointer Containers] [Indexed Set]
by JOAQUIN LOPEZ MU?Z 26 Sep '04

26 Sep '04

Hi Bruno, ----- Mensaje original ----- De: Bruno Martínez Aguerre <br1(a)internet.com.uy> Fecha: Viernes, Septiembre 24, 2004 10:44 pm Asunto: [boost] [Pointer Containers] [Indexed Set] > Hi. > > I was wondering if these two libs work together. That is, can > Indexed > Sets take ownership of my pointers? (First of all, the lib was renamed to Boost.MultiIndex.) Indexed containers are no different to STL containers in this respect: you can control ownership issues with some smart pointer, for instance boost::shared_ptr, so that objects pointed to get deleted along with the container. Apart from this, no special provision has been made to work with pointers. Ownership management aside, I'd say one of the key features of Thorsten's pointer containers is that their interface automatically dereference the pointers held so as to create the illusion that it is the actual elements that are being stored in the container. This feature is not supported by Boost.MultiIndex, and I don't think both libs can be used together to implement this artifact. To get something close to that, you can put a "view" on top of a multi_index_container of pointers and get dereferencing access. There are some view libraries out there. > > Also, I couldn't find the docs for neither of the two libs. I > looked here > http://www.boost.org/regression-logs/cs- > win32_metacomm/doc/html/libraries.html > for Indexed Set, The lib was renamed to Boost.MultiIndex, and will ship with Boost 1.32. In the meantime you can consult the docs at www.boost-consulting.com/boost/libs/multi_index > and here > http://boost-consulting.com/boost/more/formal_review_schedule.html > for > Pointer Containers. This Thorsten already anwered. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 6

** 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