- Boost - lists.boost.org

ublas test4+5 failures
by Stefan Slapeta 29 Mar '05

29 Mar '05

Please could somebody look into these: http://tinyurl.com/49lg5 http://tinyurl.com/4lvn8 These failures have occured for a long time now. The failing assertions produce popups that are very annoying for tests without the build monitor! Thanks, Stefan

1 0

type_traits: recent changes break EDG compilations
by Ralf W. Grosse-Kunstleve 29 Mar '05

29 Mar '05

The current Boost CVS does not work for compiling Boost.Python with the EDG front-end versions 238, 245, and 303 (and possibly any other EDG). E.g. using icc 8.1: icc -fPIC -DBOOST_DISABLE_THREADS -DNDEBUG -O2 -DBOOST_PYTHON_MAX_BASES=2 -I/net/legless/scratch1/rwgk/hot/boost -I/usr/local_cci/Python-2.4_ticker/include/python2.4 -c -o boost/libs/python/test/args.os /net/legless/scratch1/rwgk/hot/boost/libs/python/test/args.cpp /net/legless/scratch1/rwgk/hot/boost/boost/python/detail/invoke.hpp(75): error: expression must have (pointer-to-) function type return rc(f( BOOST_PP_ENUM_BINARY_PARAMS_Z(1, N, ac, () BOOST_PP_INTERCEPT) )); ^ detected during: The full error messages are here: http://cci.lbl.gov/~rwgk/tmp/edg238_problem_2005_03_27_1250 http://cci.lbl.gov/~rwgk/tmp/edg245_problem_2005_03_27_1250 http://cci.lbl.gov/~rwgk/tmp/edg303_problem_2005_03_27_1250 I've tracked down the failures to this CVS commit: date: 2005/03/23 11:22:25; author: johnmaddock; Modified function testing to make it configuration-friendly, future changes should require no more than a config macro change. If I check out the CVS HEAD, but run this command % cvs -q update -P -D'2005/03/23 11:00 UTC' U config.hpp U is_convertible.hpp U is_function.hpp U is_member_function_pointer.hpp U type_traits_test.hpp U detail/is_function_ptr_helper.hpp U detail/is_function_ptr_tester.hpp U detail/is_mem_fun_pointer_impl.hpp U detail/is_mem_fun_pointer_tester.hpp in boost/boost/type_traits, compilation succeeds again. The full diffs are here: http://cci.lbl.gov/~rwgk/tmp/edg_problem_2005_03_27_1250_type_traits_diffs I noticed that is_convertible.hpp was modified at a later time (2005/03/24 18:18:36), but this change does not make a difference for the EDG failures. Thanks in advance for any help! Cheers, Ralf __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

Threading and Visual C++
by Rasmus Christian Kaae 29 Mar '05

29 Mar '05

Hello, I am currently starting a project using the boost libraries and Visual C++. In this project we wish to minimize the number of DLL's shipped with our final product. However, we have discovered that the boost thread library is fixed to be dynamically loadable, is there any way to get around this? Short: How do i statically link the boost thread library in Visual C++ projects? -- Best regards / Med venlig hilsen Rasmus Christian Kaae - kaae(a)cs.auc.dk or kaae(a)daimi.au.dk Office: E4-119, Aalborg University. Phone: +45 75 88 04 13 Mobile: +45 28 72 04 13

2 1

preprocessor puzzle
by Edward Bishop 29 Mar '05

29 Mar '05

I came up with this great macro called IS_UNSIGNED_CHAR() such that IS_UNSIGNED_CHAR(unsigned char) expands to 1 and IS_UNSIGNED_CHAR(hello world) or any other input, expands to 0. It almost works, but it gets confused by IS_UNSIGNED_CHAR(unsigned world) which expands to garbage: BOOST_PP_IIF_I, EQUALS_42_57, RETURN_0)((42) world_U_I_O_P)); Any suggestions? Here is the code: #include <boost/preprocessor.hpp> #define Q_W_E_R_T_Y_unsigned 42) #define char_U_I_O_P (57 // Transmogrify t #define MOG(t) Q_W_E_R_T_Y_ ## t ## _U_I_O_P // Check if t is (42)(57) #define EQUALS_42_57(t) BOOST_PP_AND(BOOST_PP_EQUAL(42,BOOST_PP_SEQ_ELEM(0, t)), \ BOOST_PP_EQUAL(57,BOOST_PP_SEQ_ELEM(1, t)) ) // return 0 #define RETURN_0(t) 0 #define IS_UNSIGNED_CHAR(t) BOOST_PP_IIF(BOOST_PP_EQUAL(2,BOOST_PP_SEQ_SIZE((MOG(t)))), \ EQUALS_42_57, RETURN_0)((MOG(t))) // Here is some test data: IS_UNSIGNED_CHAR(unsigned char); // should expand to 1 IS_UNSIGNED_CHAR(hello world); // should expand to 0 IS_UNSIGNED_CHAR(unsigned world); // should expand to 0

4 10

[patch] lambda bug with GCC debug mode
by Jonathan Wakely 29 Mar '05

29 Mar '05

The libstdc++ debug mode doesn't work with forward declarations of std templates (since when using the debug mode std::vector is really __gnu_debug_def::vector, visible in std due to GCC's "strong using" extension) Lambda's boost/lambda/detail/operator_return_type_traits.hpp seems to account for this, but only checks for GCC 3.4 not 4.0, causing the error shown here for GCC 4.x in debug mode (*): http://www.redi.uklinux.net/src/boost/status/cs-Linux-links.html#lambda-con… The workaround on line 876 should be changed to account for GCC 4.x or alternatively, test for the debug mode explicitly. The attached patch does the test explicitly and disables all forward decls of std templates when _GLIBCXX_DEBUG is defined. I don't know whether it's preferred to simply disable the forward decls for non-debug mode as well. jon (*) regression test results for GCC 4.0 & 4.1 on x86_64 GNU/Linux here: http://www.redi.uklinux.net/src/boost/status/cs-Linux.html All toolsets use GCC's concept-checks, the gcc-debug-mode toolset also uses the libstdc++ debug mode. -- "Always Read the Label" - anon.

1 0

[mpl] eval_if has default parameters?
by Andy Little 29 Mar '05

29 Mar '05

The following compiles (VC7.1, gcc3.2), and I am wondering if this is the intended behaviour(boost 1.32) Note the two default parameters to eval_if. here #include <iostream> #include <boost/mpl/eval_if.hpp> int main() { typedef boost::mpl::eval_if< boost::mpl::true_ // whatever nullary metafunction >::type type; std::cout << type::value <<'\n'; // outputs 0 } regards Andy Little

1 1

Re: Serialization issuses under MS VC++ 7.1 ....
by Jason Earl 29 Mar '05

29 Mar '05

If you have look at my original code, it does use BOOST_SERIALIZATION_SPLIT_MEMBER() inside the class (sorry the code doesn't intend with tabs nicely). I also have tried including both... #include <boost/serialization/split_member.hpp> #include <boost/serialization/split_free.hpp> but neither work. I assume that the split free is obviously used by the list data type as it's not intrusive, and the member one is what I should include and have been including. I'll look running the tests later when I get round to figuring out how to run them etc. I'll need to RTFM first though. From the regression thingy, it said MSVC++7.1 worked OK though. I think this could be a little bug in the library (I won't speak too loudly here as I'm still a C++ beginner, and therefore there's a good chance I'm still doing something very dumb), maybe someone else could confirm they get the same problem as me when trying to serialize an class member varaible that is a list of objects using load / save methods that are class members under VS.NET 2003, like in my example.... anotherwords I have class A with separate load/save members, and then I have class B which has a member inside it that is of type std::list<A*>. Sorry in advance if I break the threaded reply structure on this list. I didn't have the list mail me replies. I'm new to all this mailing list stuff. Jason

1 0

Re: [boost] [mpl] float representation
by Cromwell Enage 29 Mar '05

29 Mar '05

--- Andy Little wrote: --- > Why not call this one mixed_number? >> > IMO your fraction \ fraction_c functionality should > be called rational \ rational_c for compatibility > with the runtime boost::rational. Okay. I suppose my choice of names was somewhat pedantic, more appropriate in elementary school than in here. > FWIW IMO with your current 'rational, the extra > parameters extend the range but not indefinitely and > the extra number and especially sign parameters are > cumbersome. You prefer something like the following? rational_c<int,-11,16> mixed_number_c<int,-4,5,8> mixed_number_c<long,0,-6,7> I guess the added readability would be worth the extra logic required to calculate the sign. > Surely better functionality and less namespace > pollution could be had with a big_int parameter to > the two param type. You mean allowing Big Integral Constants as template arguments? This would eliminate the need for big_fraction/big_rational and big_mixed_number, but not the concepts they were meant to model. Shouldn't be too difficult to implement, but I need to cut down the compile times of the other big_integral test programs before testing rationals with such arguments becomes feasible. > However currently the docs state the integral > constant requirement on parameters which IMO is an > unnecessary restriction. Once I attempt to allow template arguments beyond Integral Constants and Big Integral Constants, I risk duplicating the functionality already provided by mpl::divides<>. Any good reason you'd want me to do this? For example, what would a recursive rational provide that dividing the fraction numerator by the fraction denominator would not? > For example a more generic alternative to > abs_integral could be implemented as follows, > which might be a useful mpl function anyway. Come to think of it, mpl::abs<> would be a useful metafunction indeed. I'll work through all of this when I get the chance. I have lots of personal matters to attend to before then. Cromwell D. Enage __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

Brainbench.com testing is free until 4th of April. Let's get the top
by Pavel Chikulaev 29 Mar '05

29 Mar '05

Hi all, This is not an ad. Test your C++ skills! There is no-one booster in the top 25. Let's do that. P.S. Sorry for off-topic. I just wanted to let you know.

3 2

[Boost-bugs] [ boost-Bugs-1169920 ] Generate patches for Graph bugs in 1.32.0
by SourceForge.net 28 Mar '05

28 Mar '05

Bugs item #1169920, was opened at 2005-03-24 09:49 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=1169920&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Generate patches for Graph bugs in 1.32.0 Initial Comment: There are several critical bugs in the BGL in Boost 1.32.0 that have been fixed since the release, but 1.33.0 is too far off for users to wait. We should create a patch of some sort that allows users to get at these bug fixes, without introducing any big changes into the library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1169920&group_… ------------------------------------------------------- This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

6 6