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

boost::filesystem exception not caught on MacOS X
by Lothar May 21 Sep '08

21 Sep '08

Hi, I have a strange problem that an exception thrown by a boost::filesystem directory_iterator is not caugth on MacOS X. Please consider the following code: ("const string &dir" is a parameter) bool retVal = true; try { directory_iterator i(dir); directory_iterator end; while (i != end) { // do something ++i; } } catch (...) { retVal = false; } While this works perfectly on Windows and Linux (the exception is caught fine), on MacOS I get the following: terminate called after throwing an instance of 'boost::filesystem::basic_filesystem_error<boost::filesystem::basic_path<std::string, boost::filesystem::path_traits> >' what(): boost::filesystem::basic_directory_iterator constructor Abort trap The program runs fine (withouth the trap) if I comment out the upper lines. I use the boost 1.34.0 lib built as universal binary on MacOS 10.5, according to the instructions at http://svn.boost.org/trac/boost/wiki/CMakeConfigAndBuild I link to the static non-debug mt version of boost_filesystem. Exceptions within my program are caught fine, just this boost exception is not caught. The program is also compiled as non-debug. Any help would be very much appreciated. Regards, Lothar

6 11

Boost Graph Library and Boehm Garbage Collector
by FBSL 08 Sep '08

08 Sep '08

Hello I am having trouble to garbage-collect adjacency_list<>. I have instanciated it with correctly garbage-collected vectors and lists (I have copied vecS and listS definitions, and added Boehm GC's default allocator so that they are garbage-collected). In my application I need to dynamically allocate many graphs, but it does not work, there is a (big) memory leak. Unfortunately, there is no template argument in adjacency_list<> to specify Boehm GC's allocator. Does anyone have a hint ? Snippet code "main.cpp" follows, compiled with Boost Graph Library 1.32, Boehm GC 6.4 and G++ 3.3.5, with command line : $ g++ -o main main.cpp -lgc -lgccpp -- #include <boost/graph/adjacency_list.hpp> #include <gc/gc_allocator.h> #include <gc/gc_cpp.h> #include <iostream> #include <vector> #include <list> using namespace std; using namespace boost; namespace boost { struct collected_vecS {}; struct collected_listS {}; template <class ValueType> struct container_gen<collected_vecS, ValueType> { typedef vector<ValueType,gc_allocator<ValueType> > type; }; template <class ValueType> struct container_gen<collected_listS, ValueType> { typedef list<ValueType,gc_allocator<ValueType> > type; }; template <> struct parallel_edge_traits<collected_vecS> { typedef allow_parallel_edge_tag type; }; template <> struct parallel_edge_traits<collected_listS> { typedef allow_parallel_edge_tag type; }; namespace detail { template <> struct is_random_access<collected_vecS> { enum { value = true }; typedef true_type type; }; } } typedef adjacency_list<collected_vecS, collected_vecS, directedS, no_property, no_property, no_property, collected_listS> graph; int main() { // leaks... while(true){ graph * g=new (UseGC) graph; for(unsigned int i=0; i<100; ++i){ add_vertex(*g); } for(unsigned int i=0; i<100; ++i){ for(unsigned int j=0; j<100; ++j){ add_edge(i,j,*g); } } } }

3 4

[statechart] history transitions make state-local-storage "un-cool"
by Mick Hollins 26 Jun '08

26 Jun '08

Apologies if this has been discussed before, but I couldn't find any mention of it: I am currently using the history facility of boost::fsm. I've discovered that when I re-enter a state, X, via a history transition I don't actually re-enter the same instance of X that I was in before, but instead enter a newly constructed instance of X. I just checked the UML spec regarding history transitions and it says that "Any necessary entry actions are performed", so given that boost::fsm uses constructors to represent entry actions I guess a new instance of X has to be constructed to ensure UML compliance. My actual concern is the effect this has on the "coolness" of state-local-storage (see http://boost-sandbox.sourceforge.net/libs/statechart/doc/faq.html#Whats_so_…) It seems to me that state-local-storage, which I agree is generally cool, is particularly un-cool (and bug-inducing) in the presence of history transitions. I'm not sure what a good alternative is, but just thought I'd raise the discussion. cheers, mick PS: does the history facility display the same semantics in boost::statechart? I plan to move to statechart real soon now ...

4 19

regex lib for Windows Mobile
by Freeman Ng 07 May '08

07 May '08

I'm trying to get the regex library (Boost ver. 1.34.1) working under Visual Studio 7.0 and the Windows Mobile 6 SDK, and have run into the following problems: 1. Need to modify visualc.hpp to define BOOST_NO_STD_LOCALE and BOOST_NO_SWPRINTF. 2. WM6 runtime library doesn't have strxfrm() or wcsxfrm(). 3. regex lib makes direct calls to ansi versions of CreateFile(), LoadLibrary(), FindFirstFile(), and others (i.e. CreateFileA(), etc.) that don't exist on the WM platform. 4. w32_regex_traits.cpp has a pragma that links directly to a library that doesn't exist for WM. (user32.lib) #1 is normal and trivial, of course, but before I tackle #2 and #3 by either writing my own versions of the missing functions or modifying the regex source, and #4 by modifying the regex source (which I really hate to do, but I can't think of any other way around this one) I want to make sure I didn't miss anything. Is there some combination of #defines or project settings that should allow the library to build for VS 7 Windows Mobile? Am I about to do more work than I need to? Thanks. Freeman

3 6

Re: [Boost-users] Applying Boost license to non boost projects
by Robert Marion 22 Apr '08

22 Apr '08

You may wish to consider applying the liberal BSD (http://www.opensource.org/licenses/bsd-license.php) or MIT (http://www.opensource.org/licenses/mit-license.php) licenses. These are both in widespread use for open source, and impose no restrictions, aside from attribution, on the user. Putting the license text at the top of all headers is not strictly necessary, but not a bad idea. Robert Marion http://www.palamida.com > I am interested in adopting the Boost Software license for an open source C++ > library (Castor: http://www.mpprogramming.com/2.html) > > [ snip ] > - Does this same guideline apply to non boost projects ? The need for stating > Boost.org there might confuse some users of non boost prj to think that the > library is supplied by Boost. > - Do all header files in my prj (which is a pure header library) need to > include this text at the top/somewhere in order to adopt the license. > > -Roshan

2 1

[foreach][range] How would BOOST_REVERSE_FOREACH be implemented?
by Pete Bartlett 05 Mar '08

05 Mar '08

Boost.Foreach is such a great piece of kit that once you start using it you just can't stop. Indeed I like working directly with values rather than iterators so much that is feels normal for me to write something like BOOST_FOREACH( value_type x , make_iterator_range( rbegin( seq ) , rend( seq ) ) whenever I wish to reverse iterate over a sequence. My co-workers are not big fans of typing though, so they want a REVERSE_FOREACH. At first naïve glance it looks easy to implement in terms of the original FOREACH: template<typename C> inline iterator_range</* something */> make_reverse_iterator_range(C& c) { return make_iterator_range( rbegin(c) , rend(c) ); } #define REVERSE_FOREACH( x , container ) BOOST_FOREACH( x , make_reverse_iterator_range( container ) ) This works fine when container is an lvalue. But then co-workers, used to the wonders of the original FOREACH, inevitably start to use the new macro with rvalues and get a crash due to dangling references (- the iterator_range's members point to departed quantities.....) and if you could somehow work around that, there is the issue hidden inside the "/* something */" that you have to cope with fact that MSVC has no proper const rvalue detection. Finally the #define MACRO(x,y) ANOTHER_MACRO( f(x) , g(y) ) style is not recommended because they are brittle in the face of x and/or y themselves being macros. ... but all these issues are exactly the ones that BOOST_FOREACH itself solves! Thus surely it is technically possible to write a REVERSE_FOREACH that works with rvalues as well as lvalues, e.g. by essentially copying and pasting the FOREACH implementation and replacing "begin" and "end" by "rbegin" and "rend" in the vital places. However one feels there may be a better way... has anyone had a go at creating a "fully-functional" REVERSE_FOREACH and could offer me any advice? If indeed the task is fairly intricate and requires re-use of foreach internals, would the library author consider including something in the library itself? Many thanks for reading, Pete Bartlett

4 6

[program_options] Named values
by Igor Mikushkin 20 Feb '08

20 Feb '08

Hi! I cannot find in docs how to create named vales for producing output like shown in this example from docs: $bin/gcc/debug/multiple_sources --help Allows options: Generic options: -v [ --version ] : print version string --help : produce help message Configuration: --optimization n : optimization level -I [ --include-path ] path : include path The "--include-path" option shown above has "path" parameter, what I have is "arg".

2 6

Template instantiation, function arguments and Boost.Preprocessor
by Hicham Mouline 19 Feb '08

19 Feb '08

hi, i have a template function, the arguments of which i wish to have depend on a non-type int template argument: template<int n> double f<n>( double arg0, double arg1, ..., double argn ) // ... is not the variadic notation for var number of args { // for(int i=0; i<n; i++) // code return sum; } int main() { return x = f<3>( 1.0, 2.0, 3.0 ); } BOOST_PP_REPEAT can't seem to do the job as the template argument n needs to be known at the preprocessing stage, which happens before the template instantiation stage ( this is part of compilation) PS: I did some perf tests comparing inline f(double a0, double a1, double a2) calls in an intensive loop, vs inline f(double a[3]) // degenrates to pointer with intel compiler and max optim, and the top version is faster... regards,

4 14

[program_options] crash due to bug in ~variables_map ??
by ope 10 Feb '08

10 Feb '08

Hi, the following drives my mad: ---8<--- class CommandLineOptions { public: CommandLineOptions( int argc, char** argv ); bool option( const std::string& arg ) const; ... private: po::options_description generic_options; po::options_description hidden_options; po::options_description usage_options; po::options_description cmdline_options; po::positional_options_description pos_options; po::variables_map vm; }; --->8--- ---8<--- bool CommandLineOptions::option( const std::string& arg ) const { return vm.count( arg ); } --->8--- int main( int argc, char **argv ) { try { CommandLineOptions cmdline( argc, argv ); running using gdb (on return of main()): Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6f826c0 (LWP 16599)] 0x08051cb2 in std::_Rb_tree<std::string, std::string, std::_Identity<std::string>, std::less<std::string>, std::allocator<std::string> >::_S_right (__x=0x11) at /usr/include/c++/4.2/bits/stl_tree.h:510 510 { return static_cast<_Link_type>(__x->_M_right); } (gdb) bt #0 0x08051cb2 in std::_Rb_tree<std::string, std::string, std::_Identity<std::string>, std::less<std::string>, std::allocator<std::string> >::_S_right (__x=0x11) at /usr/include/c++/4.2/bits/stl_tree.h:510 #1 0x0805291d in std::_Rb_tree<std::string, std::string, std::_Identity<std::string>, std::less<std::string>, std::allocator<std::string> >::_M_erase (this=0xbfb95e48, __x=0x11) at /usr/include/c++/4.2/bits/stl_tree.h:1323 #2 0x0805292c in std::_Rb_tree<std::string, std::string, std::_Identity<std::string>, std::less<std::string>, std::allocator<std::string> >::_M_erase (this=0xbfb95e48, __x=0x80c61b0) at /usr/include/c++/4.2/bits/stl_tree.h:1323 #3 0x0805297b in ~_Rb_tree (this=0xbfb95e48) at /usr/include/c++/4.2/bits/stl_tree.h:592 #4 0x080529cb in ~set (this=0xbfb95e48) at /usr/include/c++/4.2/bits/stl_set.h:94 #5 0x08052b83 in ~variables_map (this=0xbfb95e28) at /usr/local/include/boost/program_options/variables_map.hpp:139 #6 0x0805316d in ~CommandLineOptions (this=0xbfb95cac) at src/eda/workbench/CommandLineOptions.hpp:23 #7 0x080515c3 in main (argc=1, argv=0xbfb961c4) at src/eda/workbench/main.cpp:75 writing main() as: ---8<--- int main( int argc, char **argv ) { try { CommandLineOptions cmdline( argc, argv ); if (cmdline.option( "version" )) { std::cout << ... } running using gdb: Starting program: /home/opetzold/Projects/cpp/eda2/eda -v ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6f716c0 (LWP 16883)] 0x08051d7e in std::_Rb_tree<std::string, std::pair<std::string const, boost::program_options::variable_value>, std::_Select1st<std::pair<std::string const, boost::program_options::variable_value> >, std::less<std::string>, std::allocator<std::pair<std::string const, boost::program_options::variable_value> > >::_S_right (__x=0xb0012) at /usr/include/c++/4.2/bits/stl_tree.h:510 510 { return static_cast<_Link_type>(__x->_M_right); } (gdb) bt #0 0x08051d7e in std::_Rb_tree<std::string, std::pair<std::string const, boost::program_options::variable_value>, std::_Select1st<std::pair<std::string const, boost::program_options::variable_value> >, std::less<std::string>, std::allocator<std::pair<std::string const, boost::program_options::variable_value> > >::_S_right (__x=0xb0012) at /usr/include/c++/4.2/bits/stl_tree.h:510 #1 0x08052b9f in std::_Rb_tree<std::string, std::pair<std::string const, boost::program_options::variable_value>, std::_Select1st<std::pair<std::string const, boost::program_options::variable_value> >, std::less<std::string>, std::allocator<std::pair<std::string const, boost::program_options::variable_value> > >::_M_erase ( this=0xbfe2c0a8, __x=0xb0012) at /usr/include/c++/4.2/bits/stl_tree.h:1323 #2 0x08052bae in std::_Rb_tree<std::string, std::pair<std::string const, boost::program_options::variable_value>, std::_Select1st<std::pair<std::string const, boost::program_options::variable_value> >, std::less<std::string>, std::allocator<std::pair<std::string const, boost::program_options::variable_value> > >::_M_erase ( this=0xbfe2c0a8, __x=0xb6fceb2c) at /usr/include/c++/4.2/bits/stl_tree.h:1323 #3 0x08052bfd in ~_Rb_tree (this=0xbfe2c0a8) at /usr/include/c++/4.2/bits/stl_tree.h:592 #4 0x08052c4d in ~map (this=0xbfe2c0a8) at /usr/include/c++/4.2/bits/stl_map.h:94 #5 0x08052cb6 in ~variables_map (this=0xbfe2c0a0) at /usr/local/include/boost/program_options/variables_map.hpp:139 #6 0x0805327f in ~CommandLineOptions (this=0xbfe2bf24) at src/eda/workbench/CommandLineOptions.hpp:23 #7 0x0805170a in main (argc=2, argv=0xbfe2c444) at src/eda/workbench/main.cpp:75 Each time it crash in ~variables_map. Is it a bug?? I'm using gcc-Version 4.2.3 20080114 (prerelease) (Debian 4.2.2-7) Thanks, Olaf

2 3

Crash while using binary_oarchive on Sol86 with Forte 11 and stlport
by Sharad Gaur 07 Feb '08

07 Feb '08

Hi all, Following piece of code is crashing for us on Sol86 with Forte 11 compiler and stlport. Let me know if someone has any idea about this. SunOS insol8614 5.10 Generic_118855-33 i86pc i386 i86pc CC: Sun C++ 5.8 Patch 121018-11 2007/05/02 int main() { using namespace std; const std::string s("Test..................\n") ; ofstream file("hello.gz", ios::binary); boost::iostreams::filtering_ostream ofilter; ofilter.push(boost::iostreams::gzip_compressor()) ; ofilter.push(file); boost::archive::binary_oarchive oar(ofilter) ; oar << s; } Here is the stack trace. std::basic_streambuf<char,std::char_traits<char> >::pubsync(0x8046730) boost::iostreams::detail::flush_device_impl<boost::iostreams::ostream_tag>::flush<std::basic_ostream<char,std::char_traits<char> > >(t = CLASS) boost::iostreams::flush<std::basic_ostream<char,std::char_traits<char> > >(t = CLASS) boost::iostreams::detail::close_impl<boost::iostreams::any_tag>::close<std::basic_ostream<char,std::char_traits<char> > >(t = CLASS, which = 24) boost::iostreams::close<boost::reference_wrapper<std::basic_ostream<char,std::char_traits<char> > > >(t = CLASS, which = 24) boost::iostreams::detail::mode_adapter<boost::iostreams::output,std::basic_ostream<char,std::char_traits<char> > >::close(this = 0x80f56d8, which = 24) boost::iostreams::detail::close_impl<boost::iostreams::closable_tag>::close<boost::iostreams::detail::mode_adapter<boost::iostreams::output,std::basic_ostream<char,std::char_traits<char> > > >(t = CLASS, which = 16) boost::iostreams::close<boost::iostreams::detail::mode_adapter<boost::iostreams::output,std::basic_ostream<char,std::char_traits<char> > > >(t = CLASS, which = 16) boost::iostreams::detail::device_wrapper_impl<boost::iostreams::any_tag>::close<boost::iostreams::detail::mode_adapter<boost::iostreams::output,std::basic_ostream<char,std::char_traits<char> > >,boost::iostreams::detail::linked_streambuf<char,std::char_traits<char> > >(dev = CLASS, _ARG2 = (nil), which = 16) boost::iostreams::detail::concept_adapter<boost::iostreams::detail::mode_adapter<boost::iostreams::output,std::basic_ostream<char,std::char_traits<char> > > >::close<boost::iostreams::detail::linked_streambuf<char,std::char_traits<char> > >(this = 0x80f56d8, which = 16, dev = (nil)) boost::iostreams::detail::indirect_streambuf<boost::iostreams::detail::mode_adapter<boost::iostreams::output,std::basic_ostream<char,std::char_traits<char> > >,std::char_traits<char>,std::allocator<char>,boost::iostreams::output>::close(this = 0x80f56a0, which = 16) boost::iostreams::detail::chain_base<boost::iostreams::chain<boost::iostreams::output,char,std::char_traits<char>,std::allocator<char> >,char,std::char_traits<char>,std::allocator<char>,boost::iostreams::output>::close(b = 0x80f56a0, m = 16) boost::iostreams::detail::chain_base<boost::iostreams::chain<boost::iostreams::output,char,std::char_traits<char>,std::allocator<char> >,char,std::char_traits<char>,std::allocator<char>,boost::iostreams::output>::closer::operator()(this = 0x8046470, b = 0x80f56a0) std::for_each<std::_List_iterator<boost::iostreams::detail::linked_streambuf<char,std::char_traits<char> >*,std::_Nonconst_traits<boost::iostreams::detail::linked_streambuf<char,std::char_traits<char> >*> >,boost::iostreams::detail::chain_base<boost::iostreams::chain<boost::iostreams::output,char,std::char_traits<char>,std::allocator<char> >,char,std::char_traits<char>,std::allocator<char>,boost::iostreams::output>::closer>(__first = STRUCT, __last = STRUCT, __f = STRUCT) boost::iostreams::detail::chain_base<boost::iostreams::chain<boost::iostreams::output,char,std::char_traits<char>,std::allocator<char> >,char,std::char_traits<char>,std::allocator<char>,boost::iostreams::output>::chain_impl::close(this = 0x80b13e0) boost::iostreams::detail::chain_base<boost::iostreams::chain<boost::iostreams::output,char,std::char_traits<char>,std::allocator<char> >,char,std::char_traits<char>,std::allocator<char>,boost::iostreams::output>::chain_impl::~chain_impl(this = 0x80b13e0) boost::checked_delete<boost::iostreams::detail::chain_base<boost::iostreams::chain<boost::iostreams::output,char,std::char_traits<char>,std::allocator<char> >,char,std::char_traits<char>,std::allocator<char>,boost::iostreams::output>::chain_impl>(x = 0x80b13e0) boost::detail::sp_counted_impl_p<boost::iostreams::detail::chain_base<boost::iostreams::chain<boost::iostreams::output,char,std::char_traits<char>,std::allocator<char> >,char,std::char_traits<char>,std::allocator<char>,boost::iostreams::output>::chain_impl>::dispose(this = 0x80b26a8) boost::detail::sp_counted_base::release(this = 0x80b26a8) boost::detail::shared_count::~shared_count(this = 0x80466c8) boost::shared_ptr<boost::iostreams::detail::chain_base<boost::iostreams::chain<boost::iostreams::output,char,std::char_traits<char>,std::allocator<char> >,char,std::char_traits<char>,std::allocator<char>,boost::iostreams::output>::chain_impl>::~shared_ptr(0x80466c4) boost::iostreams::detail::chain_base<boost::iostreams::chain<boost::iostreams::output,char,std::char_traits<char>,std::allocator<char> >,char,std::char_traits<char>,std::allocator<char>,boost::iostreams::output>::~chain_base(0x80466c4) boost::iostreams::chain<boost::iostreams::output,char,std::char_traits<char>,std::allocator<char> >::~chain(0x80466c4) boost::iostreams::detail::filtering_stream_base<boost::iostreams::chain<boost::iostreams::output,char,std::char_traits<char>,std::allocator<char> >,boost::iostreams::public_>::~filtering_stream_base(0x80466b8, 0x80b07b4) boost::iostreams::filtering_stream<boost::iostreams::output,char,std::char_traits<char>,std::allocator<char>,boost::iostreams::public_>::~filtering_stream(this = 0x80466b8) main()

2 1