- Boost-users - lists.boost.org

boost::python and Python 2.4
by Noel Yap 09 Nov '05

09 Nov '05

Is there any work being done to get boost::python to work with Python 2.4? Does anyone see any reasons it won't work (assuming the build is able to work)? Thanks, Noel

3 2

boost1.33.0 on IA64 thread problem
by Andreas Unterkircher 09 Nov '05

09 Nov '05

I'm working on porting a large project to IA64. Therefore I'd like to use the boost thread package on IA64 using gcc 3.2.3 (standard compiler on the SL 3 Linux distribution). There are some problems which I describe below and at the end of the mail I pose my questions. Thanks for any comments ! To test I use the following code: #include <stdlib.h> #include <boost/thread/mutex.hpp> int main() { boost::mutex mut; return 0; } I downloaded boost 1.33.0 & build & install it. When I try to compile it with g++ -g -O2 -pthread -I/opt/boostTest/include/boost-1_33 -L/opt/boostTest/lib -lboost_filesystem-gcc-mt -lboost_thread-gcc-mt -lpthread -lboost_regex-gcc-mt prog.c I get In file included from /opt/boostTest/include/boost-1_33/boost/thread/detail/config.hpp:18, from /opt/boostTest/include/boost-1_33/boost/thread/mutex.hpp:15, from prog.c:2: /opt/boostTest/include/boost-1_33/boost/config/requires_threads.hpp:47:5: #error "Compiler threading support is not turned on. Please set the correct command line options for threading: -pthread (Linux), -pthreads (Solaris) or -mthreads (Mingw32)" [many more "not declared" messages] Now I use "-DBOOST_HAS_THREADS", but this also does not help : g++ -g -O2 -pthread -DBOOST_HAS_THREADS -I/op/boostTest/include/boost-1_33 -L/opt/boostTest/lib -lboost_filesystem-gcc-mt -lboost_thread-gcc-mt -lpthread -lboost_regex-gcc-mt prog.c /usr/bin/ld: cannot find -lboost_thread-gcc-mt collect2: ld returned 1 exit status In the boost mailing list archive I found an IA64 patch posted by Ben Hutchings. Applying this patch and recompiling boost I get: g++ -g -O2 -pthread -I/opt/boostTest/include/boost-1_33 -L/opt/boostTest/lib -lboost_filesystem-gcc-mt -lboost_thread-gcc-mt -lpthread -lboost_regex-gcc-mt prog.c In file included from /opt/boostTest/include/boost-1_33/boost/thread/detail/config.hpp:18, from /opt/boostTest/include/boost-1_33/boost/thread/mutex.hpp:15, from prog.c:2: /opt/boostTest/include/boost-1_33/boost/config/requires_threads.hpp:47:5: #error "Compiler threading support is not turned on. Please set the correct command line options for threading: -pthread (Linux), -pthreads (Solaris) or -mthreads (Mingw32)" But when I use "-DBOOST_HAS_THREADS" everything works fine: g++ -g -O2 -pthread -DBOOST_HAS_THREADS -I/op/boostTest/include/boost-1_33 -L/opt/boostTest/lib -lboost_filesystem-gcc-mt -lboost_thread-gcc-mt -lpthread -lboost_regex-gcc-mt prog.c Here are my questions: Boost 1.33.0 contains the file boost/detail/sp_counted_base_gcc_ia64.hpp, nevertheless thread support seems not to work with gcc3.2.3. Thread support works by applying the patch and using "-DBOOST_HAS_THREADS". What is the status of boost 1.33.0 concerning IA64 ? I guess the patch has not been incorporated into the boost distribution ? On IA32 I can compile and use boost 1.33.0 threads using gcc3.2.3 without using "-DBOOST_HAS_THREADS". Why is this the case ? Ideally I would like to use the same compiler flags to compile a project using boost on IA32 and IA64. For some reasons I'd prefer to use boost 1.32.0 on IA64 but I could not get the thread package to work. Does boost 1.32.0 threads work on IA64/gcc3.2.3 ? Or is it only with boost 1.33.0 + patch that I can use them on IA64 ? Best regards, Andreas

2 3

Boost 1.33.1 Beta released
by Douglas Gregor 09 Nov '05

09 Nov '05

Boost 1.33.1 Beta ----------------- Boost 1.33.1 Beta is now available at http://www.boost.org. This is a bug fix release to 1.33.0, containing updates to existing libraries and additional computer support. Updated Libraries * Any Library: Cast to reference types introduced in 1.33.0 is now documented on any_cast documentation page. * Config Library: Don't undef BOOST_LIB_TOOLSET after use. * Boost.Python: o The build now assumes Python 2.4 by default, rather than 2.2 o Support Python that's built without Unicode support o Support for wrapping classes with overloaded address-of (&) operators * Smart Pointer Library: Fixed problems under Metrowerks CodeWarrior on PowerPC (Mac OS X) with inlining on, GNU GCC on PowerPC 64. * Regex Library: Fixed the supplied makefiles, and other small compiler specific changes. Refer to the regex history page for more information on these and other small changes. * Iostreams Library: Improved the interface for accessing a chain's components, added is_open members to the file and file descriptor devices, fixed memory-mapped files on Windows, and made minor changes to the documentation. * Functional/Hash Library: Fixed the points example. * Multi-index Containers Library: Fixed a problem with multithreaded code, and other minor changes. Refer to the library release notes for further details. * Graph Library: Fixed a problem with the relaxed heap on x86 Linux. Fixed problems with cuthill_mckee_ordering and king_ordering producing no results. * Signals Library: Fixed problems with the use of Signals across shared library boundaries. * Thread library: read_write_mutex has been removed due to problems with deadlocks. Supported Compilers Boost is tested on a wide range of compilers and platforms. Since Boost libraries rely on modern C++ features not available in all compilers, not all Boost libraries will work with every compiler. The following compilers and platforms have been extensively tested with Boost, although many other compilers and platforms will work as well. For more information, see the regression test results. New for this release: Support for building with the newest STLport-5.0 was added. The support includes building with MinGW Runtime 3.8 plus STLport-5.0 improved to support wide character operations. Apple GCC 4.0, HP Tru64 C++, and Microsoft Visual C++ 8.0 are supported platforms. We have added an experimental autoconf-like configure script for Unix-like systems: run configure --help for more information. * Apple GCC 3.3, 4.0 on Mac OS X. * Borland C++ 5.6.4 on Windows. * GNU C++ 2.95.3 (with and without STLport), 3.2.x., 3.3.x, 3.4.x, 4.0.x on Windows, Linux and Solaris. * HP C++ for Tru64 UNIX 7.1. * Intel C++ 8.1, 9.0 on Windows, Linux. * Metrowerks CodeWarrior 8.3, 9.4, 9.5 on Mac OS X and Windows. * Microsoft Visual C++ 6.0 (sp5, with and without STLport), 7.0, 7.1, 8.0. Note: Boost does not support the non-standard "Safe" C++ Library shipping with Visual C++ 8.0, which may result in many spurious warnings from Boost headers and other standards- conforming C++ code. To suppress these warnings, define the macro _SCL_SECURE_NO_DEPRECATE. Acknowledgements Douglas Gregor managed this release. A great number of people contributed their time and expertise to make this release possible. Special thanks go to Aleksey Gurtovoy and Misha Bergal, who managed to keep the regression testing system working throughout the release process; David Abrahams, Beman Dawes, Aleksey Gurtovoy, Bronek Kozicki, Rene Rivera and Jonathan Turkanis for greatly improving the quality of this release; Rene Rivera for the new Boost web page design; and Zoltan "cad" Juhasz for the new Boost logo.

1 0

program_options library and mingw
by Thomas Porschberg 09 Nov '05

09 Nov '05

Hi, I try to use the program_options library in a cygwin environment by compiling my application with the -mno-cygwin -mwindows compiler flag. This flag should lead to a pure windows application. I have boost libraries version 1.33 installed(via http://cygwin.com/) I link my application against libboost_program_options-gcc-mt-s which is sufficient under Linux. However under cygwin I get an undefined reference to `_environ' linker error. I did nm /usr/lib/libc.a | grep _environ and got 00000004 B _environ 00000000 I __imp____cygwin_environ 00000000 I __nm____cygwin_environ (but my build environment[GNU Builds tools] seems to ignore the -lc flag at the linker option line) Has someone experience with this library under cygwin/mingw ? Thomas --

1 0

[BGL] adjacency_list with hash_setS: bug ?
by Johan Oudinet 09 Nov '05

09 Nov '05

Is there any example using an adjacency_list with hash_setS for EdgeList ? I think there is a mistake in adjacency_list.hpp:21: // ====================== #if !defined BOOST_NO_HASH #include <hash_set> // instead of <ext/hash_set> ? #endif // ====================== I'm using gcc 4.0.2 with boost 1.33.0 and I can't compile a simple example using adjacency_list with hash_setS: // ====================== # if defined __cplusplus # if defined __GNUC__ && __GNUC__ >= 3 # include <ext/hash_set> # include <ext/hash_map> # if __GNUC__ >= 4 || __GNUC_MINOR__ >= 2 namespace std { using ::__gnu_cxx::hash; using ::__gnu_cxx::hash_set; using ::__gnu_cxx::hash_map; } # endif # else # include <hash_set> # include <hash_map> # endif /* defined __GNUC__ and __GNUC__ == 3 */ # endif /* defined __cplusplus */ #define BOOST_HAS_HASH 1 // for boost::hash_setS #include <boost/config.hpp> #include <boost/graph/adjacency_list.hpp> using namespace boost; int main() { typedef adjacency_list<hash_setS, vecS, bidirectionalS> Graph; Graph g; } // ========================== -- Johan

2 2

Re: [Boost-users] boost::python and Python 2.4
by Nat Goodspeed 09 Nov '05

09 Nov '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Noel Yap > Sent: Tuesday, November 08, 2005 9:14 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] boost::python and Python 2.4 > > I see the problem. Since the location of pyconfig.h depends upon > which compiler was used, it's not located in the same directory as the > rest of the Python header files. [Nat] ? Sorry, I don't understand you at all. On my Windows system I installed Python 2.3 into the default directory, c:\Python23. Likewise Python 2.4 is installed in c:\Python24. The only pyconfig.h files on my system are in 'include' subdirectories of those two directories. They don't seem to be in compiler-dependent locations, and those 'include' subdirs ARE where 300+ other Python header files live. It's worth noting that we build the Boost libraries we use as MSVC 7.1 projects. Those projects (and others) look for a PYTHONDIR environment variable whose value used to be c:\Python23 and is now c:\Python24. > I've tried passing a ':'-separated path as PYTHON_INCLUDES, but that > doesn't work. Anyone have any thoughts on this? I suppose I /could/ > hack around this by using symlinks, but I'd rather find a less hacky > solution. [Nat] So, maybe the reason I don't understand the problem you're having is because you're on a different system with a different compiler.

2 2

[BGL] a.k.a. [Graph] -- bundled properties not compiling for me under MS Dev
by Goldman, Jon 08 Nov '05

08 Nov '05

Hello, I am using Microsoft Development Environment 2002. I am trying to compile a Graph and use bundled properties. The error I am getting: \src\vtkSNL\Applications\RouteViz\rtrGraph.cxx(37) : error C2676: binary '[' : 'SimpleGraph' does not define this operator or a conversion to a type acceptable to the predefined operator \src\vtkSNL\Applications\RouteViz\rtrGraph.cxx(37) : error C2228: left of '.i' must have class/struct/union type The code snippet below exhibits the problem: struct nodeProp { int i; }; struct edgeProp { int i; }; typedef adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, nodeProp, edgeProp> SimpleGraph; void someFunc() { SimpleGraph someGraph(3); Graph::vertex_descriptor v = *vertices(someGraph).first; someGraph[v].i = 7; // This line is where the error is occuring } Anybody familiar with this problem? Thanks for looking this over, -Jon

2 1

What is the way to sort graph vertices?
by Slava 08 Nov '05

08 Nov '05

Hi, I need to find Maxumum Common Subgraph (between two graphs). For that task i need to get all the vertices of the 2 graphs sorted with some property (like vertex label or id). regular std::sort seems not working with vertex iterators (vertices(graph)). What is the way to accomplish this? Thanks

2 1

Re: [Boost-users] [Boost][serialization] Serialization and DLLs
by Topi Mäenpää 08 Nov '05

08 Nov '05

>>> Could this be related to the fact that the low-level type_info pointer >>> for the classes is different in the dll and the exe? > > That sounds like it could explain this. > > >>> (This is also the >>> reason why dynamic_cast doesn't work across dynamic library >>> boundaries.) > > I've never heard of this before. If this is true it would be key indicator > that > something's wrong. Is this a known MSVC bug? That would be very > interesting to know. I'm not a pro on this matter, but at least gcc (and its Windows version, mingw) have similar "feature". I still need to double-check if I have forgotten to include rtti support somewhere, but I have seen a couple of different my::dynamic_cast implementations that try to work around this. The most well known one might be Qt:s qobject_cast. As far as I know, compilers use pointer equivalence to compare type_infos. It seems that the type_info pointer isn't exported from dynamically loaded modules, which makes dynamic type casting (and also certain exceptions) impossible across dll boundaries. I don't know the reason, but I have verified this with three different compilers, on Linux and Windows. > Is it possible to use the non-rtti versions with MSVC > >>> 7.1? > > > I have implemented non-rtti version which is documented and tested - > test_non_rtti. > The test verifies that types which are identified with different runtime > typing systems > can inter-operate. The library includes extended_type_info_no_rtti.cpp (a > mis-nomer > I see now). This runtime typing system uses the BOOST_CLASS_EXPORT key > as the type identifier. So to use this you'll have to fix the > "type_info_implementation" > trait for this type and besure its exported. This hasn't really been used > except in the > testing (as far as I know). As far as using it a derived class defined in a > DLL where > the base class is in some other library? Too bad I found the reason this late. You already had the feature there! > I reviewed the relevant code and have verified that the serialization system > presumes > that type_info returns the same value regardless of whether the type is > implemented > within a an executable, standard library or dll. I can't imagine why it > would be any > other way. I also don't have any other reports of this. Of course, this is > not > a common usage so that probably doesn't mean much. Double check that that > there aren't any differences in things like _cdecl etc. Maybe that might > explain > why the run-time type signatures vary depending up where the type is > implemented. > > I've started written my own test of this situation but its kind of hung up > in some > in trying to get it worked into bjam. So I haven't finished it. > > I'll do what I can. Thanks for a thorough inspection of the matter. I finally managed to work out a temporary hack that does the thing. Here is how: Change tkmap/ktmap multisets to sets. Modify extended_type_info so that it always compares keys literally. Re-export base classes from wherever subclasses are exported. This ensures that the correct key is recorded to extended_type_info even though there are multiple distinct instances. The downside is that one now always needs a key, but I'm assuming it is the only possible way of dealing with shared libs anyway. Phew! I like the design of the library and the ease of use a lot. Good luck this is (at least partially) resolved now, because it would have been a show stopper to me. I hope my findings have some use in developing an even better version of it :) Best regards, Topi (not so frustrated any more, I'm gonna meet the deadline ;)

1 0

Pyste question--how to exclude a constructor?
by Drumheller, Michael 08 Nov '05

08 Nov '05

I would like to be able to exclude a constructor. My situation is precisely analogous to this: http://mail.python.org/pipermail/c++-sig/2004-March/006952.html But the above thread did not seem to terminate with a solution. Does anyone know how to do this? Thanks, MD

1 0