- Boost-users - lists.boost.org

program_options and lib64
by Philippe Després 24 Aug '05

24 Aug '05

Hello, I am using linux gcc 4.01, boost-1.33 on an amd 64 machine. I use program_options to retrieve a string from a config file but get a crash like this when I notify(): Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912541228512 (LWP 12633)] 0x00002aaaab14d2eb in std::string::assign () from /usr/lib64/libstdc++.so.6 (gdb) bt #0 0x00002aaaab14d2eb in std::string::assign () from /usr/lib64/libstdc++.so.6 #1 0x0000000000427689 in boost::program_options::typed_value<std::string, char>::notify (this=0x5de300, value_store=@0x5e1a48) at value_semantic.hpp:32 #2 0x00002aaaaafa50c9 in boost::program_options::notify () from /usr/local/lib/libboost_program_options-gcc-1_33.so.1.33.0 Is there known uncompatibilities between boost/gcc4/lib64 ?? Thank you, -- Philippe Després Associate Specialist UCSF Physics Research Lab 185 Berry Street suite 350 San Francisco CA 94107 (415) 353-4501 PGP PUBLIC KEY http://itsa.ucsf.edu/~despres/publickey.txt

3 2

Re: [Boost-users] [BULK] Re: [BULK] Re: [Test] redirecting unit test report
by Sohail Somani 23 Aug '05

23 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Gennadiy Rozental > Sent: Tuesday, August 23, 2005 1:40 PM > To: boost-users(a)lists.boost.org > Subject: [BULK] Re: [Boost-users] [BULK] Re: [Test] > redirecting unit test report > Importance: Low > > Because instances of global_fixure aren't supposed to be > destructed through > abstract pointer. Which is reinforced by protected destructor. Ah. I had a suspicion of this. > > All this could be avoided if you go the route of > BOOST_ASSERT in that > > you can define hooks via some free standing functions. > > What could be avoided and how an alternative would look like? I was thinking of avoiding the need for classes. But since context was snipped I went back and read over the thread again and it seems that you need classes.

1 0

Re: [Boost-users] [BULK] Re: [Test] redirecting unit test report
by Sohail Somani 23 Aug '05

23 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Gennadiy Rozental > Sent: Monday, August 22, 2005 10:26 PM > To: boost-users(a)lists.boost.org > Subject: [BULK] Re: [Boost-users] [Test] redirecting unit test report > Importance: Low > > #include <iostream> > > class global_fixure { > public: > global_fixure() { pointer() = this; } > virtual void setup() = 0; > virtual void teardown() = 0; > > static global_fixure*& pointer() { static global_fixure* > p = 0; return > p; } > > protected: > ~global_fixure() {} > }; Why isnt the destructor virtual? Is it because you will never have an instance of this class? What happens if delete a_global_fixture; is called? [snipped some stuff] All this could be avoided if you go the route of BOOST_ASSERT in that you can define hooks via some free standing functions.

2 1

Another iostreams question
by Lisa Glendenning 23 Aug '05

23 Aug '05

Is it possible to do something like template <typename T> T* Access(int n) { return chain.component<n, T>(); } because my compiler (GCC) doesn't like it. And if not, then how can I access a component without knowing at compile time its index?

3 2

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