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

program_options error in 1.33.1
by Tino S. 21 Dec '05

21 Dec '05

Hi boosters, i have switch my code from 1.33 to boost 1.33.1 and the program_options is not working anymore. The first program in the example folder have the same error on my maschine. Here my work: System: Suse Linux with 2.6.5-7.111.5-default #1 Wed Nov 17 11:08:17 UTC 2004 i686 athlon i386 GNU/Linux >g++ -o first first.o -L/usr/lib/ -lboost_program_options-gcc gdb backtrace output: Reading symbols from /usr/local/lib/libboost_program_options-gcc-1_33_1.so.1.33.1...done. Loaded symbols for /usr/local/lib/libboost_program_options-gcc-1_33_1.so.1.33.1 Reading symbols from /usr/lib/libstdc++.so.5...done. Loaded symbols for /usr/lib/libstdc++.so.5 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400f889d in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_stri ng () from /usr/lib/libstdc++.so.5 (gdb) backtrace #0 0x400f889d in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_stri ng () from /usr/lib/libstdc++.so.5 #1 0x080503f7 in _Construct<boost::program_options::option, boost::program_options::basic_option<ch ar> > (__p=0x8057198, __value=@0x80573b8) at stl_construct.h:78 #2 0x0805059e in std::__uninitialized_copy_aux<__gnu_cxx::__normal_iterator<boost::program_options: :basic_option<char> const*, std::vector<boost::program_options::basic_option<char>, std::allocator<b oost::program_options::basic_option<char> > > >, boost::program_options::basic_option<char>*> ( __first=Variable "__first" is not available. ) at stl_iterator.h:602 #3 0x08050abd in std::vector<boost::program_options::basic_option<char>, std::allocator<boost::prog ram_options::basic_option<char> > >::operator= (this=0xbfffed70, __x=@0xbfffed50) at stl_uninitialized.h:109 #4 0x08052b7f in boost::program_options::basic_command_line_parser<char>::run (this=0xfffffff4) at parsers.hpp:84 #5 0x08053c9a in boost::program_options::parse_command_line<char> (argc=0, argv=0x0, desc=@0x0, style=-12, ext= {<boost::function_base> = {manager = 0, functor = {obj_ptr = 0x0, const_obj_ptr = 0x0, func_pt r = 0, data = ""}}, static args = <optimized out>, static arity = <optimized out>, invoker = 0}) at function_base.hpp:407 #6 0x0804c95e in main (ac=0, av=0x0) at function_template.hpp:278 Whats wrong with the parse_command funktion? Thanks in advance, Tino ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

1 0

Re: [Boost-users] compilation problems with the boost graph library and dijkstra_shortest_paths
by matthieu.ferrant＠agfa.com 21 Dec '05

21 Dec '05

1 0

Serialization library difficulties moving from 1.32 to 1.33
by Andrew Lin 21 Dec '05

21 Dec '05

Hello all, This is my first message so please forgive me if I've got the wrong list or a like blunder. I have a project using the Boost Serialization library with a custom archive. It works fine under Boost 1.32, but fails to compile under 1.33. A condensed test case: /////////////////////// #include <iostream> #include <boost/archive/detail/common_oarchive.hpp> class TestOArchive: public boost::archive::detail::common_oarchive<TestOArchive> { private: friend class boost::archive::save_access; public: void save_binary(void *address, size_t count); private: void save(int i) {std::cout << "got an int: " << i << '\n';} void save(const char* p) {std::cout << "got a char*: " << p << '\n';} }; int main() { TestOArchive ar; ar << 3; return 0; } /////////////////////// The test case is lifted almost directly from the documentation; it compiles and runs fine under 1.32 but does not compile under 1.33 (g++ 3.4.4 on Linux). The first of several error messages: /usr/local/include/boost-1_33/boost/archive/detail/interface_oarchive.hp p: In member function `const boost::archive::detail::basic_pointer_oserializer* boost::archive::detail::interface_oarchive<Archive>::register_type(const T*)': /usr/local/include/boost-1_33/boost/archive/detail/interface_oarchive.hp p:66: error: invalid use of undefined type `const struct boost::archive::detail::basic_pointer_oserializer' /usr/local/include/boost-1_33/boost/archive/detail/basic_oarchive.hpp:43 : error: forward declaration of `const struct boost::archive::detail::basic_pointer_oserializer' Any advice would be greatly appreciated. Andrew ============================================================================================= Email transmissions can not be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. In addition, the information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it, is strictly prohibited, and may be unlawful. If you are not the intended recipient please delete this email message. ==============================================================================================

2 2

Re: [Boost-users] Graph problem -- solvable using the Boost graph library ?
by matthieu.ferrant＠agfa.com 20 Dec '05

20 Dec '05

2 1

[BGL python binding]
by Yu Huang 20 Dec '05

20 Dec '05

HI Doug, The python binding for BGL is great. I tested the version, 0.9 downloaded from http://www.osl.iu.edu/~dgregor/bgl-python/. Unfortunately, it broke. But the version from " svn co https://svn.osl.iu.edu/svn/projects/viz/bgl-python" works though lots of warnings. I compiled it against boost 1.33.1. So i suggest you update the tarball link. Due to the old system on our cluster, i have to use python 2.2. The 'enumerate' is not available in 2.2. So a snip like below is necessary to be added to graph/docstring.py. def enumerate(ls): ls_to_return = [] for i in range(len(ls)): ls_to_return.append((i,ls[i])) return ls_to_return Yu

2 1

compilation problems with the boost graph library and dijkstra_shortest_paths
by matthieu.ferrant＠agfa.com 20 Dec '05

20 Dec '05

2 1

[BGL]: Getting the space used by a graph
by Nicola Vitacolonna 20 Dec '05

20 Dec '05

Hi, how can I accurately measure the memory used by an adjacency_list (per node, per edge, per property, overall)? Best regards Nicola Vitacolonna

2 1

Re: [Boost-users] Mutually exclusive options in boost::program_options?
by james.jones＠firstinvestors.com 20 Dec '05

20 Dec '05

Marshall Clow wrote: > The other one is that program_options, by default, wants to use > double hyphens to define options: > "foo --option1 --option2" > > I'm a lot more comfortable with single hyphens: > "foo -option1 -option2" I don't know about your other problem, but using single hyphens with long options is nonstandard. In most *nix programs, -option1 means the same thing as -o ption1, i.e. a -o with the argument "ption1". Whereas --option1 means what it says. Single hyphens are reserved for single-letter options. - James Jones Administrative Data Mgmt. (v)732-510-1806 375 Raritan Center Pkwy, Suite A (f)732-510-1855 Edison, NJ 08837 Visit us on the web at http://www.firstinvestors.com/

1 0

[variant] Proposal of compile-time checked get for variant
by Zara 20 Dec '05

20 Dec '05

[Note to moderator] I am not surte if previous version of this message will really go through, beacuase I was not yet subscribed to users list. Should that be the case, please forgive me. [End of note to moderator] Dear all, I have been doing a deep redesign of an old SW project, and in the course of it I have changed a typical struct {enum;union;} to boost:variant. This design change has surfaced some problems of the original SW, as there were lots of implicit/explicit casting when accesing the above mentioned struct. To detect and correct all this problems, I have found that boost::get working on boost:variant is not enough, it will only give either a null pointer or a bad_get exception when trying to access a variant with the wrong type. Even in the cases that the wrong type is unaccessible all the time, as it is not included in the variant list of types. IMHO, this should be detected at compile-time, as it denotes a design flaw, not a runtime access error. To cover this cases, I suggest the following addition to variant library, based on get definition: namespace boost { template <typename U, BOOST_VARIANT_ENUM_PARAMS(typename T) > inline typename add_pointer<U>::type checked_get( boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) >* operand BOOST_VARIANT_AUX_GET_EXPLICIT_TEMPLATE_TYPE(U) ) { typedef boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) > Variant; BOOST_STATIC_ASSERT((!is_same< typename mpl::find<typename Variant::types,U>::type, typename mpl::end<typename Variant::types>::type>::value)); typedef typename add_pointer<U>::type U_ptr; if (!operand) return static_cast<U_ptr>(0); detail::variant::get_visitor<U> v; return operand->apply_visitor(v); } } // end of addition to namespace boost And, of course, the rest of the templates needed for const *, ref and const&.. Best regards, -- Zara

1 0

TR: [Boost.Filesystem] Missing inline keywords in I18N branch
by Marc VIALA 20 Dec '05

20 Dec '05

Hi, Ive already sent this email but Ive not seen any reply, maybe Ive missed it. In order to take advantage of the I18N/HEAD CVS merging and after Ive checked that the inline declarations are always missed; I post again my corrections in convenience.hpp for decode_system_message () declaration and fstream.hpp for narrow_path() declaration, see the attached files for diff. Could you confirm these corrections? Best regards, Marc Viala, PhD Directeur Général/Directeur Technique 122 rue de la Roche-de-Lorzier 38430 MOIRANS Tél : +33 (0)4 76 91 37 60 Fax : +33 (0)4 76 35 00 07 <http://www.acticm.com> www.acticm.com <mailto:mviala@acticm.com> mailto:mviala@acticm.com _____ De : Marc Viala Envoyé : mardi 6 décembre 2005 21:54 À : 'boost-users(a)lists.boost.org' Objet : [Boost.Filesystem] Missing inline keywords in I18N branch Hi, Im not really sure but I think there are some missing inline declarations in convenience.hpp and fstream.hpp of Boost.fileystem for the I18N branch. Ive joined the patched files Could you confirm these observations? Marc Viala <http://www.acticm.com> www.acticm.com <mailto:mviala@acticm.com> mailto:mviala@acticm.com

2 1