January 2008 - Boost-users - lists.preview.boost.org

[multi-index] No constructor that takes allocator only
by Michael Fawcett 30 Jan '08

30 Jan '08

Joaquín, thanks so much for a wonderful library. I was wondering why there is no constructor that simply takes an allocator. This would make multi_index behave more like STD Library containers, which would aid me in allowing flexible storage options for generic algorithms. Is there a technical hurdle that makes this difficult to do? You currently provide: explicit multi_index_container( const ctor_args_list& args_list=ctor_args_list(), const allocator_type& al=allocator_type()); template<typename InputIterator> multi_index_container( InputIterator first,InputIterator last, const ctor_args_list& args_list=ctor_args_list(), const allocator_type& al=allocator_type()); Is it possible to also provide: explicit multi_index_container( const allocator_type& al=allocator_type()); ? Thanks again! --Michael Fawcett

4 5

Boost Format: format strings and character types
by Daniel James 30 Jan '08

30 Jan '08

The documentation states that the same format string used with printf and boost::format should result in the same output in "almost all cases". My colleagues and I have found, though, that when a %d descriptor is used to print a char variable the result is as though a %c descriptor had been used -- printf and boost::format don't produce the same result. That is: int ii(42); char cc(42); printf( "Using printf: ii=%d, cc=%d\n", ii, cc ); cout << boost::format( "Using boost::format: ii=%d, cc=%d" ) % ii % cc << endl; Produces: Using printf: ii=42, cc=42 Using boost::format: ii=42, cc=* So, it seems that boost::format deduces the format to be used for outputting cc from its type and ignores the format explicitly requested in the format. Is this working as intended? If so the documentation seems to me to be misleading. I also note that: cout << boost::format( "As chars: ii=%c, cc=%c" ) % ii % cc << endl; Produces: As chars: ii=4, cc=* That is: the %c descriptor causes the value of ii (42) to be truncated to a single char. Also something of a surprise. My tests were carried out using boost 1.34.1 and Visual Studio 2005 on Windows. Cheers, Daniel.

2 2

[FileSystem] Linker Error on OS X with ICC - common symbols not allowed with MH_DYLIB
by Mike Jackson 30 Jan '08

30 Jan '08

I am trying to compile some code into a dynamic library and I am getting the following linker errors: Linking CXX shared library Bin/libLibTest.dylib xilibtool: executing 'libtool' ld: common symbols not allowed with MH_DYLIB output format with the - multi_module option CMakeFiles/LibTest.dir/LibTest.o definition of common __ZGVZN5boost10filesystem12initial_pathINS0_10basic_pathISbIwSt11char_tr aitsIwESaIwEENS0_12wpath_traitsEEEEERKT_vE9init_path (size 16) CMakeFiles/LibTest.dir/LibTest.o definition of common __ZGVZN5boost10filesystem12initial_pathINS0_10basic_pathISsNS0_11path_tr aitsEEEEERKT_vE9init_path (size 16) CMakeFiles/LibTest.dir/LibTest.o definition of common __ZGVZN5boost10filesystem6detail14remove_all_auxINS0_10basic_pathISbIwSt 11char_traitsIwESaIwEENS0_12wpath_traitsEEEEEmRKT_E7end_itr (size 16) CMakeFiles/LibTest.dir/LibTest.o definition of common __ZGVZN5boost10filesystem6detail14remove_all_auxINS0_10basic_pathISsNS0_ 11path_traitsEEEEEmRKT_E7end_itr (size 16) CMakeFiles/LibTest.dir/LibTest.o definition of common __ZZN5boost10filesystem12initial_pathINS0_10basic_pathISbIwSt11char_trai tsIwESaIwEENS0_12wpath_traitsEEEEERKT_vE9init_path (size 16) CMakeFiles/LibTest.dir/LibTest.o definition of common __ZZN5boost10filesystem12initial_pathINS0_10basic_pathISsNS0_11path_trai tsEEEEERKT_vE9init_path (size 16) CMakeFiles/LibTest.dir/LibTest.o definition of common __ZZN5boost10filesystem6detail14remove_all_auxINS0_10basic_pathISbIwSt11 char_traitsIwESaIwEENS0_12wpath_traitsEEEEEmRKT_E7end_itr (size 16) CMakeFiles/LibTest.dir/LibTest.o definition of common __ZZN5boost10filesystem6detail14remove_all_auxINS0_10basic_pathISsNS0_11 path_traitsEEEEEmRKT_E7end_itr (size 16) libtool: internal link edit command failed make[2]: *** [Bin/libLibTest.dylib] Error 1 make[1]: *** [CMakeFiles/LibTest.dir/all] Error 2 make: *** [all] Err This is on OS X 10.4.11 with Intel C++ compiler version 10.1.007. Maybe I am not using the boost file_system library correctly? A simple reproducible case is to just try to create a library containing any code that includes boost/filesystem/operations.hpp. The same code works on gcc on OS X 10.4.11 (Xcode 2.5 tool set) -- Mike Jackson imikejackson & gmail * com

1 1

[FileSystem] Linker Error on OS X with ICC - common symbols not allowed with MH_DYLIB
by Mike Jackson 30 Jan '08

30 Jan '08

I am trying to compile some code into a dynamic library and I am getting the following linker errors: Linking CXX shared library Bin/libLibTest.dylib xilibtool: executing 'libtool' ld: common symbols not allowed with MH_DYLIB output format with the - multi_module option CMakeFiles/LibTest.dir/LibTest.o definition of common __ZGVZN5boost10filesystem12initial_pathINS0_10basic_pathISbIwSt11char_tr aitsIwESaIwEENS0_12wpath_traitsEEEEERKT_vE9init_path (size 16) CMakeFiles/LibTest.dir/LibTest.o definition of common __ZGVZN5boost10filesystem12initial_pathINS0_10basic_pathISsNS0_11path_tr aitsEEEEERKT_vE9init_path (size 16) CMakeFiles/LibTest.dir/LibTest.o definition of common __ZGVZN5boost10filesystem6detail14remove_all_auxINS0_10basic_pathISbIwSt 11char_traitsIwESaIwEENS0_12wpath_traitsEEEEEmRKT_E7end_itr (size 16) CMakeFiles/LibTest.dir/LibTest.o definition of common __ZGVZN5boost10filesystem6detail14remove_all_auxINS0_10basic_pathISsNS0_ 11path_traitsEEEEEmRKT_E7end_itr (size 16) CMakeFiles/LibTest.dir/LibTest.o definition of common __ZZN5boost10filesystem12initial_pathINS0_10basic_pathISbIwSt11char_trai tsIwESaIwEENS0_12wpath_traitsEEEEERKT_vE9init_path (size 16) CMakeFiles/LibTest.dir/LibTest.o definition of common __ZZN5boost10filesystem12initial_pathINS0_10basic_pathISsNS0_11path_trai tsEEEEERKT_vE9init_path (size 16) CMakeFiles/LibTest.dir/LibTest.o definition of common __ZZN5boost10filesystem6detail14remove_all_auxINS0_10basic_pathISbIwSt11 char_traitsIwESaIwEENS0_12wpath_traitsEEEEEmRKT_E7end_itr (size 16) CMakeFiles/LibTest.dir/LibTest.o definition of common __ZZN5boost10filesystem6detail14remove_all_auxINS0_10basic_pathISsNS0_11 path_traitsEEEEEmRKT_E7end_itr (size 16) libtool: internal link edit command failed make[2]: *** [Bin/libLibTest.dylib] Error 1 make[1]: *** [CMakeFiles/LibTest.dir/all] Error 2 make: *** [all] Err This is on OS X 10.4.11 with Intel C++ compiler version 10.1.007. Maybe I am not using the boost file_system library correctly? A simple reproducible case is to just try to create a library containing any code that includes boost/filesystem/operations.hpp. The same code works on gcc on OS X 10.4.11 (Xcode 2.5 tool set) Thanks -- Mike Jackson imikejackson & gmail * com

1 0

Flyweight library
by Martin Fisher 30 Jan '08

30 Jan '08

Took a look at the flyweight library. I'm very much a beginner - so not a formal review, just a couple of comments: I wrote a very simple test program to try flyweight. In essence: vector<boost::flyweight<string> > vec; struct Insert { void operator()(string s) { vec.push_back(boost::flyweight<string>(s)); //vec.push_back(s); } }; void Test() { fstream f("d:\\bible12.txt", ios_base::in); { boost::progress_timer t; for_each(istream_iterator<string>(f), istream_iterator<string>(), Insert()); } } This fails to compile with Borland Turbo C++ (internal compiler error) Under MS Visual C++ (Express 2008) it compiles ok. There is quite a performance hit over a standard vector<string> - 6s -> 80s in debug and 101s in release? From the docs I'd expected to just use copy and back_inserter? However, the showstopper for me at present is this crashes with: Managed Debugging Assistant 'FatalExecutionEngineError' has detected a problem in 'd:\Users\Martin\Documents\Visual Studio 2008\Projects\fly\Debug\fly.exe'. Additional Information: The runtime has encountered a fatal error. The address of the error was at 0x79e7352e, on thread 0x15d0. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack. Windows has triggered a breakpoint in fly.exe. This may be due to a corruption of the heap, which indicates a bug in fly.exe or any of the DLLs it has loaded. This may also be due to the user pressing F12 while fly.exe has focus. The output window may have more diagnostic information. On termination of the program. Have I misunderstood the usage of flyweight, or is there a problem here? Martin

2 2

boost datetime 1_32 like construction
by Chris_AC 30 Jan '08

30 Jan '08

Please, could someone explain me how i could construct a date like it was possible in boost version 1_32 (date d(2000,1,10); date d("2000-1-10")...) in 1_34 without a cascade of necessary code changes? Thanx a lot Chris -- View this message in context: http://www.nabble.com/boost-datetime-1_32-like-construction-tp15163613p1516… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

Type_traits: is_convertible and std::pair problem
by cp now 30 Jan '08

30 Jan '08

The type_traits library gives me somewhat erroneous answers when dealing with pairs of pairs. The following code produces the errors below, but interestingly, the BOOST_ASSERT actually succeeds. It seems is_convertible thinks a pair<pair<int, int>, int> is convertible to a plain old pair<int, int>, but the compiler (and this coder) takes a different view... #include <utility> #include <boost/assert.hpp> #include <boost/type_traits/is_convertible.hpp> std::pair<int, int> go(std::pair<int, int> p) { return p; } int main() { BOOST_STATIC_ASSERT(( boost::is_convertible< std::pair< std::pair<int, int>, int >, std::pair<int, int> >::value )); std::pair<std::pair<int, int>, int> p1 = std::make_pair(std::make_pair(1,2),3); std::pair<int, int> p2 = go(p1); return 0; } $ g++-4.1.1 test.cpp -I/usr/include/boost-1_33_1 /home/vsekhar/gcc-4.1.1/lib/gcc/i686-pc-cygwin/4.1.1/../../../../include/c++/4.1.1/bits/stl_pair.h: In constructor 'std::pair<_T1, _T2>::pair(const std::pair<_U1, _U2>&) [with _U1 = std::pair<int, int>, _U2 = int, _T1 = int, _T2 = int]': test.cpp:25: instantiated from here /home/vsekhar/gcc-4.1.1/lib/gcc/i686-pc-cygwin/4.1.1/../../../../include/c++/4.1.1/bits/stl_pair.h:90: error: cannot convert 'const std::pair<int, int>' to 'int' in initialization The compiler appears to be attempting a piecewise conversion of the contents of the pair, hence the error about converting pair<int, int> to 'int' rather than an error about converting pair<pair<int, int>, int> to pair<int, int>. Is there a method of converting that is_convertible has in mind when it returns true for the aforementioned conversion? I'm testing here for simple implicit conversion... -v

3 3

Boost Thread: condition.wait()
by Kesseli Pascal 30 Jan '08

30 Jan '08

Hi everyone Recently I was trying to synchronize one of my functions using the following code: // write own data to shared vector... // ... if (++numberOfReadyThreads < numberOfInvolvedThreads) { allChargingDataReady.wait(lock); return; } numberOfReadyThreads = 0; // Only the last thread enters this section. // write data to file... allChargingDataReady.singal_all(); The idea is that all threads submit their data using this function and then wait before reading in the next set of data until all threads have submitted their data. The last thread to submit his data is the one who has to write the collected data to a file. Using this structure, I find it very simple to realize this behavior. However, I know from programming with Java that the VM there sometimes awakens one's threads without any reason, which means that I would have to realize my condition like this instead: // ... while(numberOfReadyThreads < numberOfInvolvedThreads) { allChargingDataReady.wait(lock); } // ... Implementing the same behavior using this snippet is much more complicated though and I would rather avoid it if possible. And that leads us right away to my question: Is the while()-workaround using Boost & C++ needed as well as in Java? Or can I use the much simpler if()-version? Thanks for any reply and best regards Pascal No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.12/1245 - Release Date: 26.01.2008 15:45

2 1

How to compile Boost.Thread with BOOST_HAS_WINTHREADS
by anthony kelly 30 Jan '08

30 Jan '08

Hi Boost Users, I am trying to compile Boost.Thread with BOOST_HAS_WINTHREADS. I compile the library by going to "\libs\thread\build" and running "bjam toolset=gcc-nocygwin -sBOOST_HAS_WINTHREADS=1", but whenever I try to use the library I get undefined references to pthread functions, so I think the macro BOOST_HAS_WINTHREADS is not being defined. Is there a problem with the way I am defining the macro? Is there another way I can try? Thank you, Anthony

1 0

Boost::Thread constructor
by anthony kelly 30 Jan '08

30 Jan '08

Hello Boost Users, I would like to implement a simple threaded class like this: class C { public: void Start(); void Stop(); private: bool running; boost::thread t; void ThreadJob(); } void C::Start() { running = true; t = boost::thread(&C::ThreadJob); } void C::Stop() { running = false; t.join(); } void C::ThreadJob() { while(running); } However, the syntax for this line is wrong: t = boost::thread(&C::ThreadJob); The only examples I can find show starting the thread at the same time it is defined! Is it possible to define the thread as a class member, and start it later? If so, what would the syntax for this line be? If not, can you suggest an alternative structure? Thank you, Anthony

3 4