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

regex_replace with file streams
by louis 23 Aug '05

23 Aug '05

Hi, I am new to the boost library, STL and template programming.. I want to use regex_replace to operate on a potentially large input file and output the results to another file. So, I can't load the entire file into a buffer in memory and pass it in as is done in the examples. I can't seem to figure out how to pass fstream or some other file I/O into regex_replace (ie create the proper iterator). Any help would be greatly appreciated. Louis

2 1

[SPIRIT] Problem with actors
by Stephen Henry 23 Aug '05

23 Aug '05

Hi all, I am having a problem with the following snippet of code. What I want to do is parse a line of alpha numeric characters from a file_iterator and then use the read characters to construct a new object which takes a std::string and integer argument for it's constructor. To do this I am using the statement below: p >> (+alpha_p)[ create_dfa( self.m_dfa, construct_<DFA>( construct_<std::string>( arg1 ), var(500) ) ) ]; This is the code I've got: #include <vector> #include <iostream> #include <boost/spirit/core.hpp> #include <boost/spirit/iterator/file_iterator.hpp> #include <boost/spirit/attribute.hpp> #include <boost/spirit/utility/confix.hpp> #include <boost/spirit/actor.hpp> #include <boost/spirit/phoenix.hpp> using namespace boost::spirit; using namespace phoenix; struct DFA { DFA( std::string s, int i ) : m_name(s), m_i(i) {} std::string m_name; int m_i; }; struct create_dfa_impl { template<typename Container, typename Item> struct result { typedef void type; }; template<typename Container, typename Item> void operator()( Container& c, Item const& item ) const { c.push_back( item ); } }; function<create_dfa_impl> const create_dfa = create_dfa_impl(); struct Script_parser : public grammar<Script_parser> { Script_parser( std::vector<DFA> &dfa ) : m_dfa( dfa ) {} template<typename ScannerT> struct definition { definition( Script_parser const& self ) { p = (*alpha_p)[ create_dfa( self.m_dfa, construct_<DFA>( construct_<std::string>(arg1, arg2), 500 ) ) ]; } typedef rule<ScannerT> rule_t; rule_t p; rule_t const& start() const { return p; } }; std::vector<DFA> &m_dfa; }; typedef char char_t; typedef file_iterator<char_t> iterator_t; int main( int argc, char *argv[] ) { using namespace std; if( argc != 2 ) { cout << "Invalid arguments" << endl; return -1; } iterator_t first( argv[1] ); iterator_t last = first.make_end(); std::vector<DFA> vDFA; Script_parser p(vDFA); parser_info<iterator_t> info = parse( first, last, p ); if( info.hit ) { cout << "Parsing successfull" << endl; } } This doesn't even compile, and I have absolutely no idea why. All the compiler shows is pages and pages of garbage that means absolutely nothing. Please help! Stephen

2 1

Failing date_time "default classic" tests
by Steven Solie 23 Aug '05

23 Aug '05

I'm getting the following output from one of the date_time tests with Boost 1.33.0 on AmigaOS: execute-test ../../../bin/boost/libs/date_time/test/testdate_facet_new.test/gcc/debug/testdate_facet_new.run ====== BEGIN OUTPUT ====== Pass :: to_string & default formats match Pass :: to_string & default formats match FAIL :: default classic date FAIL :: default classic date period Pass :: custom date facet date period ... I've traced it down to the %x date format specifier using the default locale while the tests themselves expect something else. According to the ANSI K&R C book this is correct behaviour because C++ classic locale uses the same format specifiers as the ANSI C strftime() function. So am I correct in assuming these two test cases are broken? --Steven

2 1

[program_options] seg fault on ppc64 / linux / gcc 3.4.4
by Liam Routt 23 Aug '05

23 Aug '05

I've just moved our project across to Boost 1.33, which seems to be working fine on our x86 linux gcc 3.4.4 machine. However, I'm getting seg faults on really basic stuff on the mac G5 we have, running linux with gcc 3.4.4 (Gentoo, using ppc64 kernel and userspace). This machine had no problems under Boost 1.32, I should add. Here is a simple test program (based on one of the early examples): ========= #include <boost/program_options.hpp> namespace po = boost::program_options; int main ( int, char* ) { po::options_description generic("Generic options"); generic.add_options() ("version,v", "print version string"); generic.add_options() ("help", "produce help message"); return ( 0 ); } ========= The seg fault happens on the second add_options() line. If the two lines are combined (as in the original example) it faults somewhere in there, but I think it is the same place. My gdb session: ========= GNU gdb 6.3 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 "powerpc64-unknown-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `a.out '. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libboost_program_options.so.1.33.0...done. Loaded symbols for /usr/lib/libboost_program_options.so.1.33.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/gcc-lib/powerpc64-unknown-linux-gnu/3.4.4/libstdc++.so.6...done. Loaded symbols for /usr/lib/gcc/powerpc64-unknown-linux-gnu/3.4.4/libstdc++.so.6 Reading symbols from /lib/ld64.so.1...done. Loaded symbols for /lib64/ld64.so.1 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/lib/gcc-lib/powerpc64-unknown-linux-gnu/3.4.4/libgcc_s.so.1...done. Loaded symbols for /usr/lib/gcc/powerpc64-unknown-linux-gnu/3.4.4/libgcc_s.so.1 #0 0x000000800005d7a8 in ._ZN5boost6detail17sp_counted_impl_pINS_15program_options18option_descriptionEE7disposeEv () from /usr/lib/libboost_program_options.so.1.33.0 (gdb) up #1 0x0000008000057b90 in ._ZN5boost15program_options29options_description_easy_initclEPKcS3_ () from /usr/lib/libboost_program_options.so.1.33.0 (gdb) up #2 0x0000000010001930 in main () at my1.cc:14 14 generic.add_options() ("help", "produce help message"); (gdb) up #3 0x00000080000d8fa4 in .__libc_start_main () from /lib/libc.so.6 ========= Any advice or suggestions are welcome. We're installing boost 1.33 in our 32-bit ppc chroot environment, and will see if there is any difference there, in case that helps. Also it is worth noting that we have a program that doesn't use the program_options, but does use boost filesystem, and that seems to run fine. Take care, Liam -- Liam Routt Ph: (03) 8344-1315 Research Programmer caligari(a)cs.mu.oz.au Computer Science, Melbourne University (or liam(a)routt.net)

5 9

Minor glitch in ptr_array?
by Daniel Krügler 23 Aug '05

23 Aug '05

I think that there is a typo in the 2nd c'tor of ptr_container_detail::ptr_array_impl<>: Shouldn't it say this->assign( 0 ); instead of the currently written this->assing( 0 ); ?? Greetings from Bremen, Daniel Krügler

2 2

A proposal to make float_hash_value<> more portable
by Daniel Krügler 23 Aug '05

23 Aug '05

Hello, the current implementation function for hashing of floating point types, the function template float_hash_value<> in hash.hpp, is implicitely written for real types where std::numeric_limits<T>::radix == 2. Although base = 2 is probably the most prominent case, it is not the only representation compatible with Our Holy Standard. E.g. base 16 floating types are well-known to exist. The hidden assumption becomes obvious in the formular std::size_t const length = (std::numeric_limits<T>::digits + std::numeric_limits<int>::digits - 1) / std::numeric_limits<int>::digits; which should actually mean (pseudo formular): std::size_t const length = (std::numeric_limits<T>::digits2 + std::numeric_limits<int>::digits - 1) / std::numeric_limits<int>::digits; where the (non-existing) constant digits2 would describe the "Number of base 2 digits that can be represented without change." To my opinion boost itself provides a simple helper class, namely static_log2, which allows the correct implementation by using the extended formular #include <boost/integer/static_log2.hpp> ... std::size_t const length = (std::numeric_limits<T>::digits * boost::static_log2<std::numeric_limits<T >::radix>::value + std::numeric_limits<int>::digits - 1) / std::numeric_limits<int>::digits; Note that the expression boost::static_log2<std::numeric_limits<T>::radix>::value is exactly 1 in the usual base-2 case, but e.g. 4 in case of base-16. My proposed fix is exact in all cases, where radix is a power of 2, in other cases (like base-10) it would at least be a better approximation than the current one. Greetings from Bremen, Daniel Krügler

2 2

Problem building Boost 1.33 .0 under Cygwin
by Clarke, Carus V 23 Aug '05

23 Aug '05

Hi, I am having a problem building Boost 1.33.0 using gcc under the current version of Cygwin. The build aborts after displaying the following messages: Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (and if you don't know what ICU is then you probably don't need it). unknown target type for <@boost!libs!test!build>libboost_prg_exec_monitor.dll Could anyone tell me what I am missing? Version 1.32.0 built on my machine with no problems. Thanks, Carus V. (Bud) Clarke carus.v.clarke(a)boeing.com

4 6

Suggestion for Boost.Thread
by ycc 23 Aug '05

23 Aug '05

Hi, booster, I am using boost.thread in Windows with VC6, it's quite handy and useful. I found it's better if the library can add 2 additional methods. One is the typedef platform_dependent thread_id_type; thread_id_type id() const ; sometimes I want to know what thread is really in the log file. so I can write this: std::cout << thread().id() << std::endl; another one is a way to return the raw thread_handle. typedef platform_dependent thread_handle thread_handle handle() const ; by this, I can suspend, terminate the thread in Windows, or in Posix platform using #ifdef. For example; boost::thread t(...); #ifdef WINDOWS ::TerminateThread(t.handle()); #endif Is this doable? Thanks.

2 2

"failed to write command file!" while installing boost 1.33
by tom gee 22 Aug '05

22 Aug '05

Can anybody help me out? here's my procedures: 1. build bjam from the source. 2. run bjam "-sTOOLS=vc-7_1" "--with-python-root=D:\Python24" install After hundreds of successful items, the process suddenly stop with an error "failed to write command file!". I tried seveal times, with or without compiling python libraries, It stopped ramdonly,sometimes at the python libraries, others at the multi-thread libraries. My system is Windows XP SP2 English, with Visual studio 2003. I have have VC2005 express b2 installed. Previously, I encountered the same problem with boost 1.33b2. but i have no problem with boost 1.32 which I 've been happy with for a long time.

2 1

Does Boost support Windows 98?
by Matt England 22 Aug '05

22 Aug '05

Hello, I realize this is a rather ambiguous question, but I thought I'd start somewhere: Does Boost support Windows 98? If it's only partial support, what is missing? (I realize that there are many Boost libraries, and this answer might be a per-library question.) I see vague references in email lists to win98 support, but I'm hoping to find an official reference. I am managing a software development project based on MinGW/Boost, hoping to not have to support Win98, but I just realized that now we need to do so (support win98). Hence my question comes a bit after the fact. Thanks for any help, -Matt

2 1