- Boost-users - lists.boost.org

config-files with program_options
by Anselm Kunstein 03 May '05

03 May '05

Hi, I'm trying ro read a config file with the program_options library, but I can't figure out how to read several sections in a config file whithout knowing (the exact) section names. For example I have a config file with N [blockn] sections (n=1...N) in my config file but I don't know N: [block1] name="Name section 1" [block2] name="Name2 section 2" . # there might or might not be more sections with the 'name' option . Is there any support for wildcards in option names so I could write something like options_description Opts_Desc("Config-File Options"); Opts_Desc.add_options() ("*.name", value<string>(), "Name of the block"); or is there a workaround for this problem? Thanks a lot in advance, Anselm Kunstein

3 2

[MPL] is lambda<apply<...> >::type wrong?
by Vladim�r Marko 03 May '05

03 May '05

[using boost 1.32.0 with gcc 3.4.2 (mingw)] It seems to me that is_same< lambda<apply<type-list> >::type, apply<type-list> >::type::value is allways true. Is this intended or a bug? The exercise 1-6 in the MPL tutorial, http://www.boost.org/libs/mpl/doc/tutorial/exercises.html , reads "Build a lambda expression that has functionality equivalent to twice. Hint: mpl::apply is a metafunction!" where twice is defined as template <typename F,typename X> struct twice : apply<F,typename apply<F,X>::type> { }; and I think the obvious solution should be apply<_1,apply<_1,_2> > . The problem is that the expression apply< apply<_1,apply<_1,_2> >, add_pointer<_1>,int >::type doesn't compile at all. This is surprising since for example the expression apply< twice<_1,twice<_1,_2> >, add_pointer<_1>,int >::type yields int**** as expected. Is there some fundamental difference between the metafunctions twice and apply? My tests suggest that the compilation failure is caused by the property of lambda<apply<...> >::type described at the top. This seems pretty odd to me since lambda<T>::type is supposed to have a nested template class "apply" if T is a placeholder-expression and lambda<apply<type-list> >::type::apply refers to the boost::mpl::apply even if the type-list contains a placeholder-expression (making the whole apply<type-list> a placeholder-expression). Did I miss something? Thanks, Vladimir Marko

2 1

dijkstra_visitor
by Andreas Fabri 02 May '05

02 May '05

Hello, I wrote my own dijksta visitor for the shortest path algorithm, and on an event I wanted it to write something in a bundled property of a vertex. However this didn't compile because the graph is a const&. Is there a way to solve this problem? Thanks in advance, andreas

2 1

[conversion] RoundEven odd behaviour
by Vyacheslav E. Andrejev 02 May '05

02 May '05

Hello All I tried to use boost numeric conversion library and faced with strange feature of RoundEven that I can not comprehend or find expanation in the documentation. First I thought that this policy rounds float number to nearest integer, because RoundEven::round_style::value == std::round_to_nearest. But! This policy for example returns 2.0 for 3.0 as argument! cout << boost::numeric::converter< int , double , boost::numeric::conversion_traits<int, double> , boost::numeric::silent_overflow_handler , boost::numeric::RoundEven<double> >::convert(2.9) << endl; cout << boost::numeric::converter< int , double , boost::numeric::conversion_traits<int, double> , boost::numeric::silent_overflow_handler , boost::numeric::RoundEven<double> >::convert(3.0) << endl; cout << boost::numeric::converter< int , double , boost::numeric::conversion_traits<int, double> , boost::numeric::silent_overflow_handler , boost::numeric::RoundEven<double> >::convert(3.1) << endl; Output of the program above will be: 3 2 3 What is the cause of such strange behaviour? This is a bug or there is something that I don't understand? -- Vyacheslav E. Andrejev System Architect, Excelsior, LLC

2 1

How to get type given pointer to base?
by Delfin Rojas 02 May '05

02 May '05

Hello all, I hope somebody can help me with this. What I want to do is the following: Let's say I have a templated class called Foo template<class U> class Foo { public: Foo(U * p) : m_p(p) {} ~Foo() {} U* getP() const { return m_p; } private: U* m_p; }; Now let's say I want to have a collection of pointers to Foo. What should I do? The possibilities I can think of are the following: 1) Create a class FooBase and have Foo inherit from FooBase. FooBase is non-templated so there should be no problem with having a collection of pointers to FooBase where I can put instances of Foo. The problem with this approach is that given a FooBase* in that collection I could not use the getP method because I would not know what type of Foo it holds. 2) Create a boost::variant of all the possible types of Foo<U>* I want to have. Then have a collection of this FooVariant. Using static visitation I can obtain the original type of Foo<U>* in a given FooVariant. The problem with this approach is that I get an ICE from VC++ 7.1 when the type of U gets too complex (shared_ptr to another type for example). Have I overlooked something? Is there a better technique for what I want to achieve? Any help would be great, Thanks Delfin Rojas

3 7

searching boost::teebuf : public std::streambuf
by Elmar Loos 01 May '05

01 May '05

Hello, in the archive of this mailinglist I found some Mails from year 2000, that a teebuf derived from std::streambuf should be inserted into boost. I couldn't find anything like this in the current boost version. Could you tell me something about the status of that class, please? Bye Elmar

2 1

Re: [Boost-users] Re: pimpl and boost
by Gottlob Frege 30 Apr '05

30 Apr '05

> Date: Fri, 29 Apr 2005 10:56:14 +0200 > From: David Gruener <gruenedd(a)idmt.fraunhofer.de> > Subject: Re: [Boost-users] Re: pimpl and boost > To: boost-users(a)lists.boost.org > Message-ID: <4271F6AE.20509(a)idmt.fraunhofer.de> > Content-Type: text/plain; charset=us-ascii; format=flowed > > Pavel Antokolsky aka Zigmar wrote: > > auto_ptr - compiled with warning about destroying incomplete type > > As i already mentioned, > very little to no benefit here over plain pointer. > > > shared_ptr - compiled and worked - the destructor of > > Yes, but you still have to provide assignment and copy > constructor for your standard cases. So, as i stated, little > benefit here over plain pointer too and an ideological problem that > shared_ptr used in this way, as serveral times suggested, > isn't a shared pointer anymore. > Again, whats needed is a pointer like Griffiths's grin_ptr > or Peter's impl_ptr. I'm looking forward to the > policy pointers. > > --David > I agree, if/when the need next arises, I will find/write an impl_ptr<>. I will also go with the technique mentioned earlier of ONLY putting the data in the impl_ptr, and not forwarding all the functions. (Still think it should be part of the language though. C++ proclaims to enable data-hiding, but it really doesn't. The speed/data-hiding trade-off that C++ originally made was fine for the times, but now that trade-off isn't so necessary...)

2 1

Re: pimpl and boost
by Peter Dimov 30 Apr '05

30 Apr '05

Kyle Alons wrote: >> I wrote such a pointer several years ago: >> >> http://lists.boost.org/MailArchives/boost/msg21930.php >> http://groups.yahoo.com/group/boost/message/15313 >> http://groups.yahoo.com/group/boost/files/impl_ptr/impl_ptr.html >> >> but I never proposed it for Boost. >> >> The reason that I didn't propose it is that I don't use it. :-) > > Is the source code for this still available anywhere? I get > 'document not found' for the links on > http://groups.yahoo.com/group/boost/files/impl_ptr/impl_ptr.html. > Thanks. It's there: http://groups.yahoo.com/group/boost/files/impl_ptr/

1 0

[Mac OS X] Problem compiling boost
by Daniel Lidström 29 Apr '05

29 Apr '05

Hello, I get linking errrors while trying to compile the program_options. Here is the output: Daniels-Monster:/Users/daniellidstrom/Desktop/boost_1_32_0> bjam --with-program_options stage ...found 468 targets... ...updating 4 targets... gcc-Link-action bin/boost/libs/program_options/build/libboost_program_options.dylib/ gcc/debug/shared-linkable-true/libboost_program_options-gcc-d -1_32.dylib g++: unrecognized option `-shared' ld: Undefined symbols: _main set -e DYLD_LIBRARY_PATH=bin/boost/libs/program_options/build/ libboost_program_options.dylib/gcc/debug/shared-linkable- true:$DYLD_LIBRARY_PATH export DYLD_LIBRARY_PATH "g++" -g -fPIC -shared -o "bin/boost/libs/program_options/build/libboost_program_options.dylib/ gcc/debug/shared-linkable-true/libboost_program_options-gcc-d -1_32.dylib" "bin/boost/libs/program_options/build/libboost_program_options.dylib/ gcc/debug/shared-linkable-true/cmdline.o" "bin/boost/libs/program_options/build/libboost_program_options.dylib/ gcc/debug/shared-linkable-true/config_file.o" "bin/boost/libs/program_options/build/libboost_program_options.dylib/ gcc/debug/shared-linkable-true/options_description.o" "bin/boost/libs/program_options/build/libboost_program_options.dylib/ gcc/debug/shared-linkable-true/parsers.o" "bin/boost/libs/program_options/build/libboost_program_options.dylib/ gcc/debug/shared-linkable-true/variables_map.o" "bin/boost/libs/program_options/build/libboost_program_options.dylib/ gcc/debug/shared-linkable-true/value_semantic.o" "bin/boost/libs/program_options/build/libboost_program_options.dylib/ gcc/debug/shared-linkable-true/positional_options.o" "bin/boost/libs/program_options/build/libboost_program_options.dylib/ gcc/debug/shared-linkable-true/utf8_codecvt_facet.o" "bin/boost/libs/program_options/build/libboost_program_options.dylib/ gcc/debug/shared-linkable-true/convert.o" "bin/boost/libs/program_options/build/libboost_program_options.dylib/ gcc/debug/shared-linkable-true/winmain.o" ...failed gcc-Link-action bin/boost/libs/program_options/build/libboost_program_options.dylib/ gcc/debug/shared-linkable-true/libboost_program_options-gcc-d -1_32.dylib... ...skipped <@boost!lib>libboost_program_options-gcc-d-1_32.dylib for lack of <@boost!libs!program_options!build/libboost_program_options.dylib/gcc/ debug/shared-linkable-true>libboost_program_options-gcc-d-1_32.dylib... I'm using gcc 3.2 (the one that came with XCode 1.5). Strange thing is the man page says -static is an option for both gcc and g++. How can I successfully compile the dynamic-link library? The static-link library was compiled successfully though. Also, I added -Wno-long-double to the g++ options, to get rid of an annoying warning. The gcc bjam file says there is no gcc or g++ on Darwin, but there certainly is for me. I'm using Mac OS X 10.3.9 with gcc 3.2 from XCode 1.5 installation. -- Daniel SBG AB

2 1

shipping software depending on boost
by Wieger Wesselink 29 Apr '05

29 Apr '05

Hi, I have written some code for a software package that my group at the university is distributing, and it has dependencies on boost. Now my boss is getting very worried about the extra complications this brings for a user to install the software (note that the dependencies are not only header files). The package is currently installed using an autoconf script. I wonder how others deal with this situation. Is it best to ship the complete boost library as part of the installation, and handle the compilation of the used boost libraries by autoconf? Thanks, Wieger -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze

2 1