- Boost-users - lists.boost.org

[program_options] define precedent options?
by Rui Maciel 09 Nov '06

09 Nov '06

I've just discovered boost's program_options and at first glance it looked exactly what I was searching for, which was a easy to use library which was capable of handling the command line arguments parsing in a fast and efficient way. Unfortunately one of the things which I had my mind set to was the possibility of defining precedent options. To put it in other words, enable the parser to accept some options only if they were casted in a particular order and complain if that order wasn't respected. For example, accepting something like: app --add --file but complain if the arguments are like: app --file --add or app --add One other thing that I was hoping that boost's program_options was capable of handling was some sort of semantic interpretation according to the option's orders. Take this case for example: app --add --file --remove --file What I was hoping for was that program_options was capable of interpreting the first invocation of --file as relating to --add and the second invocation relating to --remove, instead of intepreting as two distinct invocations of --file. So, is it possible to accomplish that with boost's program_options? If so, could anyone be so kind to provide a simple example? Thanks in advance Rui Maciel -- Running Kubuntu 6.10 with KDE 3.5.5 and proud of it. jabber:rui_maciel@jabber.org

1 0

efficient string to numeric conversion (and vice-versa)
by Maitre Bart 09 Nov '06

09 Nov '06

Is there a Boost lib that offers efficient string to numeric type conversion ? What about numeric to string conversion ?

3 2

Ann: Alpha release of Boost.TR1-1.34
by John Maddock 09 Nov '06

09 Nov '06

I've placed an alpha release of the TR1 subset of Boost on the sourceforge download page: https://sourceforge.net/project/showfiles.php?group_id=7586&package_id=1893… Eventually, this package will track Boost-1.34 releases, but until that happens, I wanted to test the water and see how a subset like this would be received, and how best to organise it's packaging etc. So any feedback you have would be most welcome! The subset includes: TR1 Reference Wrappers Shared_ptr result_of mem_fn Function Object Binders Polymorphic Function Wrappers Type Traits Random Numbers Tuples Array Hash Functions Regular Expressions Complex Number Algorithms Enjoy! Regards, John Maddock.

1 0

Add library to link against in Jamfile (building a Boost.python extension)
by Alexander Eisenhuth 09 Nov '06

09 Nov '06

Hello, I'm writing a Boost.python extension, that needs the Boost.thread library. I use the Jamfiles from Boost.python example (works, except of linking), and need to add the thread library. How can I do that? Jamfiele: ---------------------------------------------- # This is the top of our own project tree project-root ; # Include definitions needed for Python modules import python ; # ----- getting_started1 ------- # Declare a Python extension called getting_started1 extension getting_started1 : # sources getting_started1.cpp # requirements and dependencies for Boost.Python extensions <template>@boost/libs/python/build/extension ; ------------------------------------------------- Thanks a lot Regards Alexander

2 1

undefined reference to `boost::read_graphviz
by Teodora Miteva 09 Nov '06

09 Nov '06

Hi, i got this problem when i tried to compile the graphviz.cpp: ------------------------- undefined reference to `boost::read_graphviz(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::subgraph<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_attribute_t, std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::no_property>, boost::property<boost::edge_attribute_t, std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::property<boost::edge_index_t, int, boost::no_property> >, boost::property<boost::graph_graph_attribute_t, std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::property<boost::graph_vertex_attribute_t, std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::property<boost::graph_edge_attribute_t, std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::property<boost::graph_name_t, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::no_property> > > >, boost::listS> >&)' --------------------------------- i saw the explanation and some previous mails but still i have the problem... i built the lib libbgl-viz.a following the instructions ( http://www.cs.brown.edu/~jwicks/boost/libs/graph/doc/read-graphviz.html<http://www.cs.brown.edu/%7Ejwicks/boost/libs/graph/doc/read-graphviz.html>) , but still doesnt work ......... could you tell me what i could i do to salve it? thanks best teodora

1 0

converting a string to a function name
by Fred J. 09 Nov '06

09 Nov '06

Hi is there a way to convert a string to a function name and fire it. like void his_fun(){ cout << "his is here" << endl; } vector<string> vec; vec.push_back("his"); vec.push_back("me"); for(i=0; i<vec.size(); i++) string var = vec[i] + _fun; fire(var); and it will fire the routine "his_fun? is so, how? what whole idea is to avoid typing vector<func_ptr> vec; vec.push_back( &func_1 ); vec.push_back( &func_n ); ... thanks --------------------------------- Everyone is raving about the all-new Yahoo! Mail.

2 1

got a bad_any_cast exception
by ClassyK_Danad 09 Nov '06

09 Nov '06

#include <iostream> #include <boost/any.hpp> template<typename A, typename B> boost::any min(const A& a,const B& b) { return a < b ? a : b; } void main() { //got a bad_any_cast exception ! std::cout << boost::any_cast<int>( min( 1, 1.1)) << std::endl; } how could this happen?

3 3

Re: [Boost-users] Socket and iostream
by Nat Goodspeed 09 Nov '06

09 Nov '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Jakub Stachowski > Sent: Wednesday, November 08, 2006 2:22 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Socket and iostream > > > nothing seems to be written nor readen to/from the socket except for > > the first getline. What am I doing wrong here ? > > Try flushing the stream after each write. [Nat] I wondered about that -- but doesn't std::endl implicitly flush?

3 2

Re: [Boost-users] Sequence of Types, What For?
by james.jones＠firstinvestors.com 09 Nov '06

09 Nov '06

From: "Andrew Holden" <aholden(a)charteroaksystems.com> > 3: Look up the value in the first array, and then look up the code block > number in the second array. > > 4: Go to the pointer you just got. > > The actual blocks of code are laid out in order right after the goto in > step 4, in the same order as the source code. Breaks become goto end of > switch. If you leave out a break, the processor really does JUST fall > through to the next case. > > All in all, if you have a monster switch statement, the > compiler-generated code probably is just about as fast as you can get. > It takes less than a dozen machine instructions to implement it, and it > has constant complexity. Actually this is not particularly good. For one thing, it's O(n), not constant time, because doing an array lookup is O(n). For many switch use-cases this is no big deal, but it certainly isn't unheard of to have a switch with dozens (or more) of cases, each of which does almost nothing (like return a value). In this case, the lookup can actually dominate your runtime. There's a theorem in hash theory (proved by Komlos, one of my old profs) that says that you can always generate a perfect hash function if you know the values you need to hash. That is, you can generate a hash function that requires exactly one lookup in every case. But I don't know any compiler that actually does this. Since all cases are known at compile time, doing this should be a beneficial runtime optimization for large switches (if the generated hash function is sufficiently cheap). Maybe this could be done using the MPL? I don't know TMP well enough to know where to begin on something like this. See http://en.wikipedia.org/wiki/Perfect_hash_function for more detail. - James Jones Administrative Data Mgmt. Webmaster 375 Raritan Center Pkwy, Suite A Data Architect Edison, NJ 08837

5 5

BOOST_FOREACH VC8 warning: change in behavior
by Nico Galoppo 08 Nov '06

08 Nov '06

Hi, I'm getting the following warning in VC8, using BOOST_FOREACH on a container of shared_ptr<>s. The container itself is also a shared_ptr. warning C4686: 'boost::foreach_detail_::make_probe' : possible change in behavior, change in UDT return calling convention The warning happens at the following line shared_ptr<Scene> scene(new Scene()); typedef shared_ptr<Character> character_ptr; BOOST_FOREACH(character_ptr & actor, *scene) { ... } Unfortunately, I can't reproduce it in a simple program, it doesn't give me the warning there. --nico

2 2