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

Statechart serialization
by mbrodeur65 04 Mar '15

04 Mar '15

Hi, I'm looking for a solution to serialize boost::statechart objects. I'm aware that this feature is on the statechart library todo list but was wondering if there are any workaround to achieve this with the latest boost release (1.34) ? thanks for your help ! mbrodeur65 -- View this message in context: http://www.nabble.com/Statechart-serialization-tf4131326.html#a11749139 Sent from the Boost - Users mailing list archive at Nabble.com.

4 4

[Statechart] How to decide between post_event and process_event atrun time ?
by Philippe DAVID 22 Jul '14

22 Jul '14

Hi, I have a method in which I want to post/process an event. The thing is, this method can be called from outside the state machine (so I need to call process_event), or indirectly by a reaction of the state machine (in this case I must call post_event since process_event is not reentrant). I don't want to write 2 distinct methods to do this (one that calls post, and the other process), I would much rather prefer adding a 'if' in my method that tells me if I have to call process_event or post_event (if I'm being called indirectly by the state machine or not). Is there a way to do this with statechart ? regards, Philippe

3 3

[asio] resolver::cancel() problem
by Matthew Edwards 14 Mar '14

14 Mar '14

In my application (and a separate test program) it seems as though the cancel() function on the resolver does not work as intended. For async resolves, the cancel functionality should abort them immediately and pass an 'operation aborted' error code to the callback handler. In my tests, I will resolve an invalid domain (this causes the resolve to take a few seconds, to demonstrate the problem), sleep for 100ms, then call cancel on the resolver object. No cancelling actually occurs, and the callback is simply triggered after a few seconds with a "No host found" error code, not the expected operation aborted. Has anyone experienced this before, or know how I might be using the resolver incorrectly?

3 2

[multi_array] operator= requires resize - why?
by Markus Werle 04 Jun '12

04 Jun '12

Hi! IMHO the behaviour of operator= for multi_array is a little bit broken. A lot of preconditions required: template <typename ConstMultiArray> multi_array_ref& operator=(const ConstMultiArray& other) { [...] // make sure the dimensions agree assert(other.num_dimensions() == this->num_dimensions()); assert(std::equal(other.shape(),other.shape()+this->num_dimensions(), this->shape())); Besides the fact that I get mad about asserts instead of exceptions (please change this to a way users may choose) why do we have such an odd behaviour here? >From page 1, line 3 of the docs I cite: "The interface design is in line with the precedent set by the C++ Standard Library containers" - this is not true for operator=, since std::<container>::operator= works fine for me all the time _without_ any resize. Could we please change the behaviour of multi_array::operator= to take care of resize where in need to? IMHO operator= should result in a true copy ignoring previous state. Markus

6 18

Newbie question
by Michael Qi 07 Dec '09

07 Dec '09

Hi, I am trying to start to learn boost. Now, I am learning the getting started guide. And try to build a boost regex program in the guide. But Visual C++ 7.1 tell me error: LINK : fatal error LNK1104: Could not open file "D:\Program.obj" Could you help me? Thank you

2 1

[Math Toolkit] Gamma Distribution
by Christian Henning 21 Jul '09

21 Jul '09

Hi there, the documention of the gamma distribution talks about two different forms. How can can generate the second one with shape=1 and scale=1? I know how to get the first form: boost::math::gamma_distribution<> dist( 1, 1 ); I don't see how to get the second one? Thanks, Christian

5 13

Design for boost::serialization of STL iterators.
by Carlo Wood 23 May '09

23 May '09

On Sat, Mar 11, 2006 at 11:45:36PM +0200, Peter Dimov wrote: > Carlo Wood wrote: > > > 1) WHY does boost::serialization not support serialization > > of iterators? > > It's very hard, if not impossible, in general. It is either impossible or possible. When it is possible, it can't be hard :p I think that at the moment of serialization, the actual container needs to be known. So, only concentrating on the syntax of the code that serializes an iterator, the following cannot work: ar & iter; However, the container will be known at that point (or at least, we might as well assume that). Therefore, I could imagine a syntax like: ar & foobar(container, iter); where 'foobar' is some template function (that will be part of boost::serialization in the future). Lets start with the last one (have to start somewhere). In order to deserialize the iterator (and taken into account that we already have the container) -- which makes me think that it might be better to pass a functor to operator& above. In other words, (at least for writing), use: template<class Container> struct Foobar { Foobar(Container const&, typename Container::const_iterator& iter) : M_container(container), M_iter(iter); private: Container const& M_container; Container::const_iterator& M_iter; }; and then assign to M_iter, whatever we find in M_container. > If you have access to the container to which the iterator i refers: > > a) if the container is a map, you can serialize i->first, then on > deserialization look up the key in the map using .find(); > > b) if the container is a sequence, and it has the same contents on > deserialization as it does on serialization, you can serialize the index of > the element - distance( c.begin(), i ). I don't think that it is a requirement that the whole container has to be read: either it's a map or set, in which case later insertions will not invalidate the container, or it is a vector, in which case we use an index, from which we can construct the end iterators before the whole container is reconstructed. Therefore, the following syntax can work imho: ar & FooBar(container, iter); Would you agree? There are a zillion questions and implementation details open - but I'd like to get anyones feedback about this type of interface for iterators before continuing. Current questions: What is a good name for Foobar? Am I right when I think that Foobar needs to be declared in boost::serialization? Now the hard part (for me) is that part that involves the internals of the boost library. At the moment one tries to serialize an iterator, it is possible (though not necessarily) that the object that the iterator points to is already serialized. In the case that we are dealing with an associative container (map or set etc), we don't want to store the contents of the object (or key part, in the case of a map) again: I'd like to just store that once, and store a reference in the archive at the other place. How can I make the library store an object only the first time and the store a reference the second time? This would be for an object of arbitrary type thus. I think that it is only feasible to do this when it's actually the same object (same memory address), which is the case; but while storing the object element of the container, the address of it isn't stored as well, is it? Is there a way to make: std::set<SomeData> s; [...] ar << s; Store the address of s (&s) along with the contents of s? And would that then automatically cause the library to not store that same object again when I do: std::set<SomeData>::iterator iter = s.find(...); [...] ar << *iter; Because then, &*iter would again be the same memory address as what was stored before. -- Carlo Wood <carlo(a)alinoe.com>

3 2

[BGL] citing the Boost Graph Library
by Alejandro Marcos Aragón 06 May '09

06 May '09

Can anyone point me how to cite the Boost Graph Library in a paper? Is there any information in the boost website? Thank you all, Alejandro Aragón

4 3

[date_time] posix_time::time_duration::operator<< fails for hours>23
by Soren Dreijer 04 Feb '09

04 Feb '09

I'm creating a posix_time::time_duration object based on the minutes() helper function. If I specify a large value, such as 2000, I get a time_duration of 33:20:00. Take a look at the following piece of code, though: time_duration td = minutes(2000); cout << to_simple_string(td); // OK cout << td; // Fails with an assertion in VS2008 The latter call fails with the following assertion in strftime.c on line 658: _VALIDATE_RETURN( ( ( timeptr->tm_hour >=0 ) && ( timeptr->tm_hour <= 23 ) ), EINVAL, FALSE) Apparently, operator<< expands to _expandtime(), which doesn't allow values for the hour to be greater than 23. Is this intended behavior, or should I just always use to_simple_string() rather than the convenient operator<< ?

2 1

boost::program_options
by Duy Nguyen 09 Oct '08

09 Oct '08

When I try to use the boost::program_options library to read a property file, I got the error when I run "make" on Cygwin (I installed Cygwin on WIndows XP). > make g++.exe -I /cygdrive/c/MyTest/Test1/include/boost-1_34_1/ -c TestInit.cpp Test.cpp TestDriver.cpp g++.exe -I /cygdrive/c/MyTest/Test1/include/boost-1_34_1/ -c TestInit.cpp Test.cpp TestDriver.cpp g++.exe -I /cygdrive/c/MyTest/Test1/include/boost-1_34_1/ -c TestInit.cpp Test.cpp TestDriver.cpp g++.exe TestInit.o Test.o TestDriver.o -o "TestDriver" -L/cygdrive/c/MyTest/Test1/lib -lboost_program_options-gcc34-mt-d-1_34_1 -lg2c Info: resolving vtable for boost::program_options::variables_mapby linking to __imp___ZTVN5boost15program_options13variables_mapE (auto-import) Then when I run my program, it does not work. If I comment out the "try ... catch" block which uses the boost::propram_options library then it compiles and works fine. Please show me how to fix it. Thank you.

6 5

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

[boost.iostreams] Can't be able to read gzipped file
by Marc Viala Perso 06 Feb '08

06 Feb '08

Hello, During the implementation of a TARFILE module based on Boost.Iostream, I've faced a problem during reading operation of a boost::iostream::filtering_stream<> with a GZip codec. To illustrate it, you will find hereafter a small code snippet that reproduces my problem: namespace io = boost::iostreams ; namespace fs = boost::filesystem ; const fs::path test_file("test.txt.gz") ; const std::string s("Test..................") ; { io::filtering_stream<io::output> ofilter ; ofilter.push(io::gzip_compressor()) ; ofilter.push(io::file_descriptor_sink( test_file.external_file_string() , std::ios::binary)) ; ofilter << s ; } { io::filtering_stream<io::input> ifilter ; ifilter.push(io::gzip_decompressor()) ; ifilter.push(io::file_descriptor_source( test_file.external_file_string() , std::ios::binary)) ; std::string rs ; ifilter >> rs ; // <- Here process is blocked in file_description.cpp @ line 145 //boost::scoped_array<char> buffer(new char[512]) ; //const std::streamsize count = io::read(ifilter, buffer.get(), 512) ; } The problem occurs during the reading operation @ line: "ifilter >> rs": the process is blocked in boost/iostreams/src/file_description.cpp @ line 145 ("if (!::ReadFile(pimpl_->handle_, s, n, &result, NULL))") when this line is executed. I've tried to use boost::iostream::read() template function without more success. I've checked the file after the writing operation w/ 7z and everything is fine at this point. I've tried the same code snippet w/ ZLib and BZip2 codecs without trouble. My environment is: Visual C++ 7.1 Boost 1.34.1 Windows XP SP2 Is there any bug in GZip decompressor with the file_descriptor_source? Or I've missed something? Any help will be appreciated. Best regards, Marc VIALA

2 5

Thread creation overhead & efficiency
by James Sutherland 05 Feb '08

05 Feb '08

I am a new user of boost::thread. After implementing it I found that it slowed down execution of my code. I suspect that it may be due to the overhead of thread creation. I am creating/destroying thread_group ojects many times (tens of thousands) during code execution. Pardon my naïve question, but is this a problem for performance? I noticed some reference to a thread pool on this list. Is a thread pool the best alternative in this situation? Thanks for any guidance, James

4 6

[Boost Interprocess] - Windows 64-bit / 32-bit mixed process support
by Richard Brown 01 Feb '08

01 Feb '08

Ion, I have a server process and multiple client processes which successfully share a managed_shared_memory vector as well as two message_queues. All processes are 32-bit, and run under both Windows XP and 64-bit XP Server (using 32-bit Wow emulation). However I am trying to take advantage of the Windows XP 64-bit OS, so I have attempted to build the Server process as 64-bit, while leaving the client processes at 32-bit (unfortunately I'm stuck with some 32-bit libraries and cannot move the client processes to x64 at this time). Both the server and clients (64 bit and 32 bit respectively) can see the shared memory file that Interprocess creates, and my class members use fixed-sized datatypes (__int32, __int64), but after walking some of the code it became apparent that Interprocess is having issues with mixing the different processes. Example: message_queue::do_receive(block_t block, void *buffer, std::size_t buffer_size, std::size_t &recvd_size, unsigned int &priority, const boost::posix_time::ptime &abs_time) ... ... //Thre is at least message ready to pick, get the top one detail::msg_hdr_t *top_msg = p_hdr->top_msg(); //Paranoia check if (top_msg == 0) { throw interprocess_exception(); } //Get data from the message recvd_size = top_msg->len; priority = top_msg->priority; ... ... The contents of top_msg appear to be "shifted", such that "top_msg->len;" now returns a 0. Obviously much of this is due to std::size_t being sized differently on the server process (at 64-bit) vs. the client (32-bit) processes. II thought of doing a bit of experimentation, whereby I could replace all instances of std::size_t in the library with something windows specific - like "unsigned __int64", but I have no idea if variations in data type size are the only issue. Should I give it a try or perhaps a different approach would be better? Thanks, Rich Brown if (Nabble.searchterms != null && Nabble.searchterms.length > 0) { Nabble.hilt(Nabble.searchterms, Nabble.get("nabble.msgtxt15191825")); }  //Nabble.gquery = 'test'; //Nabble.topicDumpSearch = true; if (Nabble.gquery!=null) { if (Nabble.topicDumpSearch) { Nabble.get('nabble.searchResults').innerHTML = '<h1> Other threads matching \"<strong>'+Nabble.gquery+'</strong>\":</h1>'+ '<p style=\"margin-left: 3em;\">looking for matching threads...</p>'; Nabble.loadScript('/forum/TopicDump$SearchJs.jtp?query='+encodeURIComponent(Nabble.gquery)+'&post=15191825'); Nabble.setVar('prev',null); } else { Nabble.setVar('prev', '<big><a id="nabble.prev_search" href="/forum/Search.jtp?query='+encodeURIComponent(Nabble.gquery)+'">Search Nabble for "<b>'+Nabble.gquery+'</b>"</a>' ); } } if( Nabble.prev ) Nabble.writeReturnToLink(Nabble.prev);

2 1

Question about Boost Interfaces
by Martin de Lasa 01 Feb '08

01 Feb '08

Hi, Does anyone know the status of the Boost.Interfaces Library proposed by Chris Diggins in 2004? I have found a few references to it on the internet, including one on the Boost Wiki, but it seems to not have ever made it into the official Boost library. I am interest in exploring how Aspect-Oriented Programming techniques might be incorporate into an existing code-base, and would prefer to use a library based solution, rather than a special preprocessor (eg. apsectc++). Since Boost has come to the rescue in the past (with elegant solutions), in this respect, I thought I would start here. If boost.interfaces is dead, does anyone have any suggestions for C++ library-based AOP solutions that have worked for them. Thanks in advance. Martin

2 3

Boost 1.34.1 build fails on openSUSE 10.3
by Christoph Duelli 01 Feb '08

01 Feb '08

Trying to build Boost 1.34.1 on OpenSuse 10.3 fails for me: soft@mxt2:/tmp/boost_1_34_1> ./configure Building Boost.Jam with toolset gcc... tools/jam/src/bin.linuxx86/bjam Detecting Python version... 2.5 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... not found. Generating Boost.Build configuration in user-config.jam... Generating Makefile... soft@mxt2:/tmp/boost_1_34_1> make ./tools/jam/src/bin.linuxx86/bjam --user-config=user-config.jam /bin/sh: line 1: 15631 Segmentation fault ./tools/jam/src/bin.linuxx86/bjam --user-config=user-config.jam Not all Boost libraries built properly. soft@mxt2:/tmp/boost_1_34_1> cat /etc/*release LSB_VERSION="core-2.0-noarch:core-3.0-noarch:core-2.0-ia32:core-3.0-ia32" openSUSE 10.3 (i586) VERSION = 10.3 I have built Boost (both this and older versions) on other machines before, so I assume the "./configure; make" should work (although I usually do specify a --prefix). Does anyone know (the cause of) this error? Thank you in advance and best regards Christoph

2 2