May 2005 - Boost - lists.preview.boost.org

[1.33.0] Final destination for 1.33 test results?
by JOAQUIN LOPEZ MU?Z 24 May '05

24 May '05

index.htm as currently in the CVS has the following URL http://www.meta-comm.com/engineering/boost-regression/1_33_0/index.html under the name "Release". Currently, the link fails. Is this the stable URL where 1.33 final results will be stored? I'd like to include this in some of my docs and I guess I'll have to do it "blindly" i.e before the URL gets any actual contents, so I want to make sure. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[test] Turning off signal traps
by Jody Hagins 24 May '05

24 May '05

I have a test that is failing, and I am using the auto tests... #define BOOST_AUTO_TEST_MAIN #include <boost/test/auto_unit_test.hpp> #include "foo.hpp" BOOST_AUTO_UNIT_TEST(blarg) { BOOST_CHECK_EQUAL(do_something(), 0); } However, somewhere a SEGV is happening. How can I turn off the test signal catching for this test so that I can get a core file for debugging?

2 1

Big Integer uploaded to sandbox, volunteer seeked for submission to boost
by christopher diggins 24 May '05

24 May '05

I just uploaded a very simple arbitrary precision unsigned integer class to the sandbox ( http://boost-sandbox.sourceforge.net/vault/index.php ). The class is implemented using naive algorithms and is based on std::vector<bool>. Efficiency was absolutely not a concern, the priority was placed on correctness. Without meaning to undermine the impressive work on the expression template big_integer class I thought perhaps programmers would generally prefer a more portable and quickly compiled class. The interface of the type I posted is: class big_uint { typedef big_uint self; public: big_uint(); big_uint(const self& x); big_uint(const std::vector<bool>& x); big_uint(int x); self& operator=(const std::vector<bool>& x); self& operator<<=(int n); self& operator>>=(int n); self operator++(int); self operator--(int); self& operator++(); self& operator--(); self& operator+=(const self& x); self& operator-=(const self& x); self& operator*=(self x); self& operator/=(const self& x); self& operator%=(const self& x); self operator~() const; self& operator&=(self x); self& operator|=(self x); self& operator^=(self x); bool operator[](int n) const; int size() const; unsigned long to_ulong(); friend self operator<<(const self& x, unsigned int n); friend self operator>>(const self& x, unsigned int n); friend self operator+(const self& x, const self& y); friend self operator-(const self& x, const self& y); friend self operator*(const self& x, const self& y); friend self operator/(const self& x, const self& y); friend self operator%(const self& x, const self& y); friend self operator^(const self& x, const self& y); friend self operator&(const self& x, const self& y); friend self operator|(const self& x, const self& y); friend bool operator==(const self& x, const self& y); friend bool operator!=(const self& x, const self& y); friend bool operator>(const self& x, const self& y); friend bool operator<(const self& x, const self& y); friend bool operator>=(const self& x, const self& y); friend bool operator<=(const self& x, const self& y); }; For acceptance into Boost I would guess that this class would have to be much more efficient (though my view is that something that works is better than nothing that runs fast). Unfortunately I can not spend any significant amount of time optimizing it nor doing a proper submission (I would not have time available until around August), so if someone would like to volunteer to take it over, I would appreciate it. Any comments would be most welcome. -- Christopher Diggins http://www.cdiggins.com

1 0

random.hpp - suggestion for utility function
by christopher diggins 24 May '05

24 May '05

AFAICT the shortest way to emulate the std::rand() function using boost/random.hpp would be as follows: unsigned int longhand_boost_rand() { boost::mt19937 rng; boost::uniform_int<> dist(0, RAND_MAX); boost::variate_generator < boost::mt19937, boost::uniform_int<> > generator(rng, dist); return generator(); } (apologies if I made any mistakes) I was wondering if there would be any reason not to provide a utility function which made it easier to write random number generators. For instance, the following: template<class Dist_T, class Rng_T> typename boost::variate_generator<Rng_T, Dist_T>::result_type generate_rand(Dist_T dist, Rng_T rng) { return boost::variate_generator<Rng_T, Dist_T>(rng, dist)(); } would allow us to rewrite our rand function as follows. unsigned int shorthand_boost_rand() { return generate_rand(boost::uniform_int<>(0, RAND_MAX), boost::mt19937()); } By the way, congratulations on an excellent product to the random.hpp team. -- Christopher Diggins http://www.cdiggins.com

3 3

Intrusive containers: third iteration
by Olaf Krzikalla 24 May '05

24 May '05

Hi, the third version of intrusive containers is available. Beside some bug fixes and minor improvements I have added a real-world example of a triangulation algorithm demonstrating the usefulness of intrusive containers. As usual, you find the file intrusive.zip either in the yahoo file section or here: http://people.freenet.de/turtle++/intrusive.zip Best regards Olaf Krzikalla

2 2

RE: [boost] Re: [1.33.0] Feature freeze reminder
by Martin Bonner 24 May '05

24 May '05

>> Martin Bonner <martin.bonner(a)pitechnology.com> writes: >>> Is it being suggested that "adding backwards compatibility" is a new >>> feature, as opposed to fixing a bug? >>> >>> I think it will be /enormously/ damaging to Boost's reputation for >>> professional quality software if it is not possible to read a 1.32 >>> archive with 1.33. It doesn't take long to build a reputation for >>> "you can never read a file from old versions", and FOREVER to get >>> rid of it. > On May 24, 2005, at 6:45 AM, David Abrahams wrote: >> Yeah, I think this probably falls under "bug fixing," or at least >> "critical feature without which we had better not ship." Douglas Gregor [mailto:doug.gregor@gmail.com] writes: > Yes, it's a bug. I've already given Robert the go-ahead to fix it for > 1.33.0. Thanks Doug. I'd like to take the opportunity to thank you for the job you are doing managing this release. I think you've made the right decision here, and I think you made the right decision on BOOST_FOREACH (even if I would have loved to see that in 1.33). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

RE: [boost] Re: Re: [1.33.0] Feature freeze reminder
by Martin Bonner 24 May '05

24 May '05

----Original Message---- From: Jeff Flinn [mailto:TriumphSprint2000@hotmail.com] Sent: 23 May 2005 14:12 To: boost(a)lists.boost.org Subject: [boost] Re: Re: [1.33.0] Feature freeze reminder > "Martin Slater" <mslater(a)hellinc.net> wrote in message > news:428EBB2F.5060101@hellinc.net... >>> The problem is that I want to add code that will handle the >>> previous pointer version. My concern is that users might want to >>> use 1.33 to read archives created under 1.32 and without this >>> addition this won't be possible. I presume that some numbers of >>> people would be effected by such a situation. If not I could just >>> forget it. >> >> Without backwards compatibility with the old shared pointer >> serialization I for one would not be able to upgrade to the latest >> version until it appears. All a pain really as I was looking forward >> to the new improved version. > > I'll second that. > > Jeff Flinn Is it being suggested that "adding backwards compatibility" is a new feature, as opposed to fixing a bug? I think it will be /enormously/ damaging to Boost's reputation for professional quality software if it is not possible to read a 1.32 archive with 1.33. It doesn't take long to build a reputation for "you can never read a file from old versions", and FOREVER to get rid of it. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

3 2

possible bug?
by Nico Blanke 24 May '05

24 May '05

Hi there! Since I read much documentation, and talked to many people on IRC regarding my Problem, I now post it here, because no one can help me. Here is the Source of my C++ App : #include <boost/python.hpp> #include <iostream> using namespace boost::python; void test() { std::cout << "Hello World!" << std::endl; } BOOST_PYTHON_MODULE(test) { def("test", &test); } int main() { Py_Initialize(); std::cout << "INITIALIZED" << std::endl; init_module_test(); std::cout << "MODULE LOADED" << std::endl; FILE * fp; fp = fopen ("test.py","r"); std::cout << "created fp" << std::endl; PyRun_AnyFile(fp, "test.py"); Py_Finalize(); std::cout << "Called PyRun" << std::endl; fclose(fp); } Running this code results in 'Aborted' on init_module_test() ; here's the GDB Output : GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /home/spellbreaker/c++/test [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 13445)] Program received signal SIGABRT, Aborted. [Switching to Thread 16384 (LWP 13445)] 0xb7cc02b1 in kill () from /lib/libc.so.6 (gdb) bt #0 0xb7cc02b1 in kill () from /lib/libc.so.6 #1 0xb7c4d8b8 in pthread_kill () from /lib/libpthread.so.0 #2 0x00003485 in ?? () #3 0x00000006 in ?? () #4 0xb7c52ff4 in ?? () from /lib/libpthread.so.0 #5 0x00000006 in ?? () #6 0xbfffec40 in ?? () #7 0xb7c4dc21 in raise () from /lib/libpthread.so.0 #8 0x00004000 in ?? () #9 0x00000006 in ?? () #10 0xb7da6ff4 in ?? () from /lib/libc.so.6 #11 0xb7cc0052 in raise () from /lib/libc.so.6 #12 0x00000006 in ?? () #13 0xb7da710c in __fpu_control () from /lib/libc.so.6 #14 0xb7da6ff4 in ?? () from /lib/libc.so.6 #15 0x00000000 in ?? () #16 0xb7cc158a in abort () from /lib/libc.so.6 #17 0x00000020 in ?? () #18 0x00000000 in ?? () #19 0x00000000 in ?? () #20 0x00000000 in ?? () #21 0x00000000 in ?? () #22 0x00000000 in ?? () #23 0x00000000 in ?? () #24 0x00000000 in ?? () #25 0x00000000 in ?? () #26 0x00000000 in ?? () #27 0x00000000 in ?? () #28 0x00000000 in ?? () #29 0x00000000 in ?? () #30 0x00000000 in ?? () #31 0x00000000 in ?? () #32 0x00000000 in ?? () #33 0x00000000 in ?? () #34 0x00000000 in ?? () #35 0x00000000 in ?? () #36 0x00000000 in ?? () #37 0x00000000 in ?? () #38 0x00000000 in ?? () #39 0x00000000 in ?? () #40 0x00000000 in ?? () #41 0x00000000 in ?? () #42 0x00000000 in ?? () #43 0x00000000 in ?? () #44 0x00000000 in ?? () #45 0x00000000 in ?? () #46 0x00000000 in ?? () #47 0x00000000 in ?? () #48 0x00000000 in ?? () #49 0x00000000 in ?? () #50 0x00000000 in ?? () #51 0x00000000 in ?? () #52 0x00000000 in ?? () #53 0x00000000 in ?? () #54 0x00000000 in ?? () #55 0x00000000 in ?? () #56 0x09844246 in ?? () #57 0xbfffece0 in ?? () #58 0xb7fce568 in ?? () #59 0x0804a10c in ?? () #60 0x08048f88 in init_module_test () #61 0xb7e780f4 in std::terminate () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5 #62 0xb7e78296 in __cxa_throw () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/libstdc++.so.5 #63 0xb7fbdb67 in boost::python::throw_error_already_set () from /usr/lib/libboost_python.so.1.32.0 #64 0xb7fb496b in boost::python::objects::function::add_to_namespace () from /usr/lib/libboost_python.so.1.32.0 #65 0xb7fb4a93 in boost::python::objects::function::add_to_namespace () from /usr/lib/libboost_python.so.1.32.0 #66 0xb7fb4c04 in boost::python::objects::add_to_namespace () from /usr/lib/libboost_python.so.1.32.0 #67 0xb7fbe170 in boost::python::detail::scope_setattr_doc () from /usr/lib/libboost_python.so.1.32.0 #68 0x08049165 in boost::python::def<void (*)()> () #69 0x08048f86 in init_module_test () #70 0x08048fa2 in main () I hope someone can help me to solve this problem, since I don't see what I did wrong. Best regards, Nico Blanke

2 1

[shared_ptr] problems with ICC/IA64
by Joaquín Mª López Muñoz 24 May '05

24 May '05

When in GCC compatibility mode, ICC on IA64 does not support asm statements, as shown for instance in http://tinyurl.com/7m3bd. I've googled for this, and the references found seem to confirm this fact. This is currently causing countless test failures in FFT-icc_8.1.30/intel-linux. The proposed patch to boost/detail/sp_counted_base.hpp, though not tested (don't have access to the environment), seems to me will solve the problem: basically, it disables the forwarding to the optimized boost/detail/sp_counted_base_gcc_ia64.hpp on the circumstances described. OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 38c38 < #elif defined( __GNUC__ ) && defined( __ia64__ ) --- > #elif defined( __GNUC__ ) && defined( __ia64__ ) && !defined( __INTEL_COMPILER )

2 2

[serialization] Static data members.
by Rene Rivera 24 May '05

24 May '05

Many of the problems that CodeWarrior, and True64, have with the serialization library stem from the behavior of CW to not call constructors for static data members in one particular class in the library. I've come to think that this is standard conforming behavior. The serialization library relies on a static member of a template class being constructed at global initialization time to figure out what all the serialized classes are. The problem is that the template class is being instantiated implicitly. Which for most compilers also instantiates any static members of that template class. It's my understanding that this violates 14.7.1.7: "The implicit instantiation of a class template does not cause any static data members of that class to be implicitly instantiated." Question I have.. Is my understanding correct? Or is this a bug in CW part? For reference the code in question is in "boost/serialization/void_cast.hpp".. http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/serialization/void_… http://tinyurl.com/9s5jb The template class is void_caster_primitive, and it's instantiated from the void_cast_register function at the bottom. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

3 12