- Boost - lists.boost.org

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

[Threads] Failures on msvc, msvc-stlport
by Doug Gregor 24 May '05

24 May '05

The Threads library is failing the majority of the regression tests on Visual C++ 6.0, where it was previously supported. Are we continuing to support this compiler in the Thread library? If so, we need to fix these bugs immediately; if not, we need to mark the toolsets unusable with the Thread library. Doug

5 6

RE: [boost] Re: Building from current CVS
by Marcin Tustin 24 May '05

24 May '05

I've managed to use the vc71 .sln files to build the serialization library, but now I have a question that probably seems pretty stupid: How does Visual Studio know which .lib file to try to link against? I'm using the headers from CVS, and Visual studio in compiling my project is trying to link against libboost_serialization-vc71-mt-sgd-1_33.lib, but my project does not mention this file, so I am confused about how to point Visual studio at the library generated from the CVS source. > -----Original Message----- > From: Keith MacDonald [mailto:boost@mailclan.net] > Sent: 22 May 2005 11:05 > To: boost(a)lists.boost.org > Subject: [boost] Re: Building from current CVS > > Here's a batch file that I use to build Boost from CVS with > VC 7.1 on XP: > > ========= build7.bat ========= > REM Build Boost libraries with VC7.1 > SET PYTHON_ROOT=C:\Apps\Python24 > SET PYTHON_VERSION=2.4 > REM First build JAM > CD tools\build\jam_src > CALL build.bat > REM Now use JAM to build BOOST > CD ..\..\.. > @echo "Building Boost with VC 7.1 ..." > tools\build\jam_src\bin.ntx86\bjam > "-sTOOLS=vc-7_1" -sICU_PATH=F:\Dev\icu-3.2 > build7.log @ECHO > "Finished. See build7.log" > ========================== > > I've not figured out how to use bjam with v2 rules, so a > similar batch file for VC 8.0 works but you get a lot of > warnings about unknown and obsolete compiler options. > > Keith MacDonald > > "Marcin Tustin" <mt(a)it-innovation.soton.ac.uk> wrote in > message > news:1F5A05DA40944243A29DC3C135A2E72F19CF6F@mailserver-2.it-in novation.soton.ac.uk... > > > > I'm trying to build from the current CVS (actually about a > week old), > > and it has some weird problem with creating files and directories. > > > > > > When trying to build with a version of Jam from 1.32, it > always falls > > over trying to create a file or directory, normally > mentioning Mkdir1 > > first. > > > > When trying to build the version of Jam that comes with the CVs > > source, it is able to build jam0.exe, but when it comes > time to make > > bin.ntx86 it fails; and if that directory exists, the jam > executable > > is not created; instead an error about "spawn: No such file or > > directory" is emittted. > > > > I am using vc 7.1. > > > > Any ideas for a better way to build the boost libraries? > > > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > > > >

3 2

[type traits] is_abstract expected failures
by Doug Gregor 24 May '05

24 May '05

The following compilers are failing is_abstract_test: - cw-9_5-darwin - gcc-3_3-darwin - cw-9_4 From the list of compilers that are already expected to fail this test (include CW 9.3 and GCC 3.3.x), I think they should be marked as known failures and will do so unless anyone objects. Doug

2 1