February 2008 - Boost - lists.boost.org

[Boost] Compile-time power of a run-time base
by Bruno Lalande 23 Mar '08

23 Mar '08

Hello, I have written for the need of a coworker a function template that computes the compile-time power of a base that is known only at runtime. The original need was just to avoid having to write things like "value*value*value*value*value". Before doing this, I've been searching for such a thing in the Boost documentation and mailing lists, but could only find discussions about an entierely compile-time version (compile-time exponent of compile-time base) intended for use in metaprograms. Is there any reason why the "semi-compile-time" version I describe here hasn't been discussed? Even though it can be viewed as a mere syntactic sugar, it can be very practical when it comes to write by hand a power with a big exponent. In case of interest, here is my code : template <int N> struct positive_power { template <typename T> static float result(T base) { return base*positive_power<N-1>::result(base); } }; template <> struct positive_power<0> { template <typename T> static float result(T) { return 1; } }; template <int N, bool> struct power_if_positive { template <typename T> static float result(T base) { return positive_power<N>::result(base); } }; template <int N> struct power_if_positive<N, false> { template <typename T> static float result(T base) { return 1/positive_power<-N>::result(base); } }; template <int N, typename T> float power(T base) { return power_if_positive < N, boost::mpl::greater_equal < boost::mpl::int_<N>, boost::mpl::int_<0> >::type::value >::result(base); } It supports positive, null and negative integer exponents. Some improvements can surely be done, like allowing to specify the desired return type. Examples of use : power<3>(myValue); power<0>(myValue); power<-5>(myValue); Thanks Bruno

8 37

[filesystem] not_found_error unresolved external symbol on windows platform
by Alexander Arhipenko 17 Mar '08

17 Mar '08

Hi, guys! I had following problem when using boost::filesystem dynamically linked on windows platform: unresolved external symbol boost::filesystem::not_found_error. (By the way, this issue was raised up on users list some time ago, but had no resolution). According to dumpbin utility, mentioned symbol resides in boost_filesystem binary, so, I guess, there is some problem with macro magics (__declspec(dllimport/dllexport) ) in header file (operations.hpp). I'm building test application using Boost.Build: Boost.Build V2 (Milestone 11) Boost.Jam 03.1.16 and boost 1.34.1. Compiler is MSVC 9, but problem is reproducible on MSVC 8. The attached patch fixes the problem by defining BOOST_FILESYSTEM_DYN_LINK in usage requirements (in boost.filesystem's Jamfile.v2), but I'm wondering 1. why all the other symbols are successfully imported when mentioned macro is not defined 2. and why this macro wasn't defined in usage requirements by the author of the library. Could you please shed a light on this issue or correct me if I'm doing something wrong. Thanks. Sasha P.S. In attach there are minimal project that reproduces the problem and patch that fixes the problem.

2 2

filesystem::wpath and Linux
by Johan Ström 15 Mar '08

15 Mar '08

Hello list! Im working on an app wich is to run on windows, linux and OSX. I just switched from using filesystem::path to wpath, to be able to use i18n'ed paths on Windows. However this gave me a bunch of problems on Linux. A simple test case: test.cpp #include <iostream> #include <boost/filesystem/path.hpp> #include <boost/filesystem/convenience.hpp> namespace fs = boost::filesystem; int main() { fs::wpath mypath(L"/tmp/some/Directories"); for(int i = 0; i < 10; i++) { try { std::wcout << "Creating " << mypath << " nr " << i; fs::create_directories(mypath); }catch(std::exception&e) { std::cout << e.what() <<std::endl; } } } And Jamfile: import modules ; BOOST_ROOT = [ modules.peek : BOOST_ROOT ] ; use-project /boost : $(BOOST_ROOT) ; project wpathtest : requirements <library>/boost/filesystem//boost_filesystem/<link>static ; exe test : test.cpp : ; Running this in GDB on Linux with gcc 4.1.1, boost 1.34.1 (.0 too): (gdb) % dev1 ~/testcase$ gdb ./bin/gcc-4.1.1/debug/test GNU gdb Red Hat Linux (6.3.0.0-1.143.el4rh) 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 "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /home/johan/testcase/bin/gcc-4.1.1/debug/test Creating /tmp/some/Directories nr 0 *** glibc detected *** double free or corruption (out): 0x0891e858 *** Program received signal SIGABRT, Aborted. 0x001cf7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) where #0 0x001cf7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x002107a5 in raise () from /lib/tls/libc.so.6 #2 0x00212209 in abort () from /lib/tls/libc.so.6 #3 0x00244a1a in __libc_message () from /lib/tls/libc.so.6 #4 0x0024b2bf in _int_free () from /lib/tls/libc.so.6 #5 0x0024b63a in free () from /lib/tls/libc.so.6 #6 0x00654041 in operator delete () from /usr/lib/libstdc++.so.6 #7 0x0065408d in operator delete[] () from /usr/lib/libstdc++.so.6 #8 0x0804e233 in boost::checked_array_delete<char> (x=0x891e858 "\200 \200\200\200\200��\200\200\200\200�\200\200\200\200�\200\200 \200\200p") at /home/common/boost_1_34_1/boost/checked_delete.hpp:41 #9 0x0804e249 in ~scoped_array (this=0xbfefada0) at /home/common/ boost_1_34_1/boost/scoped_array.hpp:65 #10 0x0804f983 in boost::filesystem::wpath_traits::to_external (ph=@0xbfefaf1c, src=@0xbfefadfc) at /home/common/boost_1_34_1/libs/ filesystem/src/path.cpp:96 #11 0x0804af53 in boost::filesystem::basic_path<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::filesystem::wpath_traits>::external_file_string (this=0xbfefaf1c) at /home/common/boost_1_34_0/boost/filesystem/ path.hpp:302 #12 0x0804b917 in boost::filesystem::exists<boost::filesystem::basic_path<std::basic_strin g<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::filesystem::wpath_traits> > (ph=@0xbfefaf1c) at /home/common/ boost_1_34_0/boost/filesystem/operations.hpp:279 #13 0x0804ba6d in boost::filesystem::exists (ph=@0xbfefaf1c) at /home/ common/boost_1_34_0/boost/filesystem/operations.hpp:601 #14 0x0804c06d in boost::filesystem::create_directories<boost::filesystem::basic_path<std: :basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::filesystem::wpath_traits> > (ph=@0xbfefaf1c) at /home/common/boost_1_34_0/boost/filesystem/ convenience.hpp:42 #15 0x0804c219 in boost::filesystem::create_directories (ph=@0xbfefaf1c) at /home/common/boost_1_34_0/boost/filesystem/ convenience.hpp:88 #16 0x0804c1b3 in boost::filesystem::create_directories<boost::filesystem::basic_path<std: :basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::filesystem::wpath_traits> > (ph=@0xbfefaf7c) at /home/common/boost_1_34_0/boost/filesystem/ convenience.hpp:51 #17 0x0804c219 in boost::filesystem::create_directories (ph=@0xbfefaf7c) at /home/common/boost_1_34_0/boost/filesystem/ convenience.hpp:88 #18 0x0804c1b3 in boost::filesystem::create_directories<boost::filesystem::basic_path<std: :basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::filesystem::wpath_traits> > (ph=@0xbfefafc0) at /home/common/boost_1_34_0/boost/filesystem/ convenience.hpp:51 #19 0x0804c219 in boost::filesystem::create_directories (ph=@0xbfefafc0) at /home/common/boost_1_34_0/boost/filesystem/ convenience.hpp:88 #20 0x0804a4c0 in main () at test.cpp:14 (gdb) If I instead remove the for/try stuff (only keep fs::wpath and fs::create_directories(mypath) and the std::wcout, I get this: (gdb) run Starting program: /home/johan/testcase/bin/gcc-4.1.1/debug/test Creating /tmp/some/Directories nr terminate called after throwing an instance of 'boost::filesystem::basic_filesystem_error<boost::filesystem::basic_path <std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::filesystem::wpath_traits> >' what(): boost::filesystem::wpath::to_external conversion error Program received signal SIGABRT, Aborted. 0x001cf7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) where #0 0x001cf7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x002107a5 in raise () from /lib/tls/libc.so.6 #2 0x00212209 in abort () from /lib/tls/libc.so.6 #3 0x006571bb in __gnu_cxx::__verbose_terminate_handler () from /usr/ lib/libstdc++.so.6 #4 0x00654ed1 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.6 #5 0x00654f06 in std::terminate () from /usr/lib/libstdc++.so.6 #6 0x0065504f in __cxa_throw () from /usr/lib/libstdc++.so.6 #7 0x0804b69c in boost::throw_exception<boost::filesystem::basic_filesystem_error<boost:: filesystem::basic_path<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::filesystem::wpath_traits> > > (e=@0xbfeed054) at /home/common/ boost_1_34_0/boost/throw_exception.hpp:39 #8 0x0804f669 in boost::filesystem::wpath_traits::to_external (ph=@0xbfeed1cc, src=@0xbfeed0ac) at /home/common/boost_1_34_0/libs/ filesystem/src/path.cpp:94 #9 0x0804ad15 in boost::filesystem::basic_path<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::filesystem::wpath_traits>::external_file_string (this=0xbfeed1cc) at /home/common/boost_1_34_0/boost/filesystem/ path.hpp:302 #10 0x0804b6d9 in boost::filesystem::exists<boost::filesystem::basic_path<std::basic_strin g<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::filesystem::wpath_traits> > (ph=@0xbfeed1cc) at /home/common/ boost_1_34_0/boost/filesystem/operations.hpp:279 #11 0x0804b82f in boost::filesystem::exists (ph=@0xbfeed1cc) at /home/ common/boost_1_34_0/boost/filesystem/operations.hpp:601 #12 0x0804be2f in boost::filesystem::create_directories<boost::filesystem::basic_path<std: :basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::filesystem::wpath_traits> > (ph=@0xbfeed1cc) at /home/common/boost_1_34_0/boost/filesystem/ convenience.hpp:42 #13 0x0804bfdb in boost::filesystem::create_directories (ph=@0xbfeed1cc) at /home/common/boost_1_34_0/boost/filesystem/ convenience.hpp:88 #14 0x0804bf75 in boost::filesystem::create_directories<boost::filesystem::basic_path<std: :basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::filesystem::wpath_traits> > (ph=@0xbfeed22c) at /home/common/boost_1_34_0/boost/filesystem/ convenience.hpp:51 #15 0x0804bfdb in boost::filesystem::create_directories (ph=@0xbfeed22c) at /home/common/boost_1_34_0/boost/filesystem/ convenience.hpp:88 #16 0x0804bf75 in boost::filesystem::create_directories<boost::filesystem::basic_path<std: :basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::filesystem::wpath_traits> > (ph=@0xbfeed278) at /home/common/boost_1_34_0/boost/filesystem/ convenience.hpp:51 #17 0x0804bfdb in boost::filesystem::create_directories (ph=@0xbfeed278) at /home/common/boost_1_34_0/boost/filesystem/ convenience.hpp:88 #18 0x0804a2f3 in main () at test.cpp:10 The double-delete doesnt look too good, does it? The other problem, this makes wpath pretty useless in crossplatform if it cannot decode itself? Even when its such a simple path.. I've done some googling on wpath but there doesnt seem to be very much usage of it.. Any clues? Thanks! -- Johan Ström Stromnet johan(a)stromnet.se http://www.stromnet.se/

4 5

[filesystem] imbue for path_traits
by Alexei Alexandrov 15 Mar '08

15 Mar '08

Hi, Currently filesystem::path_traits doesn't have imbue() method while wpath_traits has. Thus, there is explicit assumption that external and internal encodings for path are the same. But this is not true sometimes. For example, currently it doesn't seem to be possible to use filesystem::path conveniently on Linux in cases when internal encoding of the application is UTF-8 while system encoding might differ from UTF-8 (GB2312, for example).

2 2

[mpi] BOOST_HAS_LONG_LONG but no is_mpi_datatype<long long>
by Number Cruncher 13 Mar '08

13 Mar '08

I'm trying to send a class with a uint64_t member and although my compiler (gcc 4.0.2), MPI library (OpenMPI 1.2.5) and boost library (SVN branches/release) all support "long long" natively on 32-bit i386, I noticed the necessary code is "#if 0" undefined in boost/mpi/datatype.hpp Just wondering why? #if 0 #ifndef BOOST_NO_INTRINSIC_WCHAR_T BOOST_MPI_DATATYPE(wchar_t, MPI_WCHAR, builtin); #endif #ifdef BOOST_HAS_LONG_LONG BOOST_MPI_DATATYPE(long long, MPI_LONG_LONG_INT, builtin); BOOST_MPI_DATATYPE(unsigned long long, MPI_UNSIGNED_LONG_LONG, builtin); #endif #endif Cheers, Simon

3 2

[announce] Dynamic object factory v3
by Marco Costalba 13 Mar '08

13 Mar '08

Yet another object factory announce! Sorry to announce another version, but I think "this is the last one" (tm) ;-) Small, easy to read, self-contained, feature complete, compiler friendly, and really really nice (at least for my coding style taste). I spent a lot of time polishing this toy. IMHO could be an example of C++ template programming for beginners/intermediate users. Interested people could find it in boost vault under the name factory_24_2_08.zip, of course any feedback is welcomed. Thanks for your attention Marco

3 4

[python] BOOST_PYTHON_MODULE() causing .lib generation?
by Robert Dailey 13 Mar '08

13 Mar '08

Hi, I'm currently using MSVC 9 with Boost 1.34.1. When I create a boost module using BOOST_PYTHON_MODULE(), I notice that my application is generating a .lib and .exp files when my application is a .exe (I'm embedding python, not extending into a library). I have no need for my application to generate a .lib file, is there a way I can disable the generation of this library file? Thanks.

4 12

[python] Crash when running variant=debug-python libraries
by Robert Dailey 13 Mar '08

13 Mar '08

Hi, First off I am using Boost 1.34.1 and I have built the libraries myself using the following command line. My compiler is MSVC 9.0. *bjam --toolset=msvc --layout=system link=shared threading=multi variant=debug-python stage* The code I'm running has worked fine using *variant=debug*, however it crashes with an "access violation" against NULL with *variant=debug-python*, which I had assumed defined BOOST_DEBUG_PYTHON. My goal was to get the debug Boost.Python library to link against the debug python25 shared library (it seemed to work). Below is the code I'm compiling. BEGIN CODE --------------------------------------------- #define BOOST_PYTHON_DEF( func ) boost::python::def( #func, func ) using namespace boost::python; static char const* PrintHelloWorld() { return "Hello World!"; } BOOST_PYTHON_MODULE(Script) { BOOST_PYTHON_DEF( PrintHelloWorld ); } object GetNamespace( char const* mod ) { object theModule = import( mod ); return theModule.attr( "__dict__" ); } void BeginPythonTest() { try { Py_Initialize(); initScript(); object main = GetNamespace( "__main__" ); object sys = GetNamespace( "sys" ); list path( sys["path"] ); path.insert( 0, "python" ); sys["path"] = path; main["Script"] = import( "Script" ); main["rocket"] = import( "rocket" ); exec_file( "pythontest.py", main, main ); Py_Finalize(); } catch( error_already_set const& /*err*/ ) { PyErr_Print(); } catch( std::invalid_argument const& /*err*/ ) { PyErr_Print(); } } --------------------------------------------- END CODE And, for your reference, the callstack at the time of the crash (note that it may be a little bit mangled): *> boost_python-mt-gy.dll!boost::python::objects::function::function(const boost::python::objects::py_function & implementation={...}, const boost::python::detail::keyword * const names_and_defaults=0x7ffdb000, unsigned int num_keywords=3435973836) Line 104 + 0xb bytes C++ 0012f520() boost_python- mt-gy.dll!boost::detail::function::void_function_ref_invoker0<void (__cdecl*)(void),void>::invoke(boost::detail::function::function_buffer & function_obj_ptr={...}) Line 191 C++ boost_python-mt-gy.dll!boost::function0<void,std::allocator<boost::function_base> >::operator()() Line 692 + 0x11 bytes C++ boost_python-mt-gy.dll!boost::python::handle_exception_impl(boost::function0<void,std::allocator<boost::function_base> > f={...}) Line 26 C++ boost_python-mt-gy.dll!boost::python::handle_exception<void (__cdecl*)(void)>(void (void)* f=0x00474695) Line 29 + 0x2c bytes C++ boost_python-mt-gy.dll!boost::python::detail::init_module(const char * name=0x0055ea08, void (void)* init_function=0x00474695) Line 39 + 0x9 bytes C++ rocket_test_Debug.exe!initScript() Line 15 + 0x30 bytes C++ rocket_test_Debug.exe!BeginPythonTest() Line 34 C++*

2 2

Problem linking Boost Unit Test Library on windows (1.33.0)
by Duft Markus 11 Mar '08

11 Mar '08

Hi! I have a problem linking our application on windows. Somebody added test cases using the boost unit test library, and since then windows won't link anymore. The problem is, that the boost library contains a "main" and doesn't seem to contain a "init_unit_test_suite" function (am I missing a library?). It works on all other systems, is windows unsupported there? Is there any more information I should gather for you to see the problem, or is this a known issue (I remember seeing something on the list about this, but I think it was about a newer boost version. Can any eventually made changes be expressed as a patch for 1.33.0 so I can locally fix the issue, and won't need an upgrade)? Cheers, Markus

3 2

[signals/threadsafe version] Atomic disconnects
by Johan Torp 09 Mar '08

09 Mar '08

I'm wondering if the new thread safe implementation of signals guarantees atomic disconnects. line1: signal<void(), multi_threaded> sig; line2: thread t(sig); // Start a new thread which will emit "sig" line3: sig.connect(&some_func); line4: sig.disconnect(&some_func); line5: ... Am I guaranteed that some_func isn't called at line 5 or afterwards? If disconnect is blocking, how do you prevent the following dead-lock during signal emission? - Emitting thread tries to acquire a mutex X via a slot - Disconnect calling thread is holding X and gets blocked on disconnect Best Regards, Johan Torp -- View this message in context: http://www.nabble.com/-signals-threadsafe-version--Atomic-disconnects-tp154… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 12